xiaohack's Blog - ClickHouse
type: channel
link: https://blog.xiaohack.org/tag/clickhouse/
items: Flink ClickHouse Sink：生产级高可用写入方案｜得物技术
items: 快手：从分散存储到统一分析，Apache Doris 在万亿规模广告场景的应用
items: 自建埋点分析系统的成本对比（含 ClkLog 开源方案）
items: ClickHouse 数据库渗透测试指南
items: ClickHouse 完成由 Dragoneer 领投的 4 亿美元 D 轮融资，加速其在分析与 AI 基础设施领域的扩张
items: 拒绝造轮子：高频金融数据流的管道搭建实践
items: 从 OTel 到 Rotel：每秒处理量提升 4 倍的 PB 级追踪系统

Flink ClickHouse Sink：生产级高可用写入方案｜得物技术
type: item
date: 2026-02-10T11:29:05+08:00
description: 一、背景与痛点业务场景在实时大数据处理场景中，Flink + ClickHouse 的组合被广泛应用于：日志处理： 海量应用日志实时写入分析库。监控分析： 业务指标、APM 数据的实时聚合。这些场景的共同特点：数据量大：百万级 TPS，峰值可达千万级。写入延迟敏感： 需要秒级可见。数据准确性要求高：不允许数据丢失。多表写入： 不同数据根据分表策略写入不同的表。开源 Flink ClickHouse Sink 的痛点Flink 官方提供的 ClickHouse Sink（flink-connector-jdbc）在生产环境中存在以下严重问题：痛点一：缺乏基于数据量的攒批机制问题表现：// Flink 官方 JDBC Sink 的实现 public class JdbcSink<T> extends RichSinkFunction<T> { private final int batchSize; // 固定批次大小 @Override public void invoke(T value, Context context) { bufferedValues.add(value); if (bufferedValues.size() >= batchSize) { // 只能基于记录数攒批，无法基于数据量 flush(); } }带来的问题：内存占用不可控： 100 条 1KB 的日志和 100 条 10MB 的日志占用内存差距 100 倍。OOM 风险高： 大日志记录（如堆栈转储）会迅速撑爆内存。写入性能差： 无法根据记录大小动态调整批次，导致小记录批次过大浪费网络开销。痛点二：无法支持动态表结构问题表现：// Flink 官方 Sink 只能写入固定表 public class JdbcSink { private final String sql; // 固定的 INSERT SQL public JdbcSink(String jdbcUrl, String sql, ...) { this.sql = sql; // 硬编码的表结构 } }带来的问题：多应用无法隔离： 所有应用的数据写入同一张表，通过特定分表策略区分。扩展性差： 新增应用需要手动建表，无法动态路由。性能瓶颈： 单表数据量过大（百亿级），查询和写入性能急剧下降。痛点三：分布式表写入性能问题问题表现：// 大多数生产实现直接写入分布式表 INSERT INTO distributed_table_all VALUES (...)ClickHouse 分布式表的工作原理：带来的问题：网络开销大： 数据需要经过分布式表层转发，延迟增加。写入性能差： 分布式表增加了路由和转发逻辑，吞吐量降低。热点问题： 所有数据先到分布式表节点，再转发，造成单点瓶颈。生产级方案的核心改进针对以上痛点，本方案提供了以下核心改进：改进一：基于数据量的攒批机制public class ClickHouseSinkCounter { private Long metaSize; // 累计数据量（字节） public void add(LogModel value) { this.values.add(value); this.metaSize += value.getMetaSize(); // 累加数据量 } } // 触发条件 private boolean flushCondition(String application) { return checkMetaSize(application) // metaSize >= 10000 字节 || checkTime(application); // 或超时 30 秒 }优势：内存可控： 根据数据量而非记录数攒批。精确控制： 1KB 的记录攒 10000 条 = 10MB，1MB 的记录攒 10 条 = 10MB。避免OOM： 大日志记录不会撑爆内存。改进二：动态表结构与分片策略public abstract class ClickHouseShardStrategy<T> { public abstract String getTableName(T data); } //日志侧实现为应用级分表 public class LogClickHouseShardStrategy extends ClickHouseShardStrategy<String> { @Override public String getTableName(String application) { // 动态路由：order-service → tb_logs_order_service return String.format("tb_logs_%…

快手：从分散存储到统一分析，Apache Doris 在万亿规模广告场景的应用
type: item
date: 2026-02-02T12:01:30+08:00
description: 导读：面对万亿级广告数据存量、日均 3 亿行增量及数千个复杂查询模板的挑战，快手广告数据平台如何突破性能瓶颈、实现架构统一与体验跃升？本文系统介绍了快手广告团队从 ClickHouse on ES 混合架构，全面迁移至 Apache Doris 的统一分析实践，最终实现查询性能提升 20～90%，写入吞吐提升 3 倍，存储效率提升 60%。本文整理自快手高级计算引擎研发工程师 周思闽 在 Doris Summit 2025 中的演讲内容，并以演讲者第一视角进行叙述。快手是国内日活过亿的短视频平台，其广告投放平台是商业化外部广告主与快手电商商家进行广告投放的主要阵地，支持客户在平台上进行广告物料搭建、物料管理、策略变更、数据查看等操作，这对底层数据系统的存储、计算与查询性能提出了极高要求。要支撑如此大规模的广告投放与实时分析，底层数据架构面临巨大挑战。当前，快手的广告数据包括：由投放系统产生的物料数据以及用于数据分析的效果数据，这些数据呈现出三个显著特征：数据存量巨大：广告物料累计已达千亿级别，且随业务发展正向万亿规模迈进，存储体量位居公司前列，对架构扩展性提出极高要求。数据增长迅猛：仅 2025 年第一季度，日均新增广告物料数据同比激增 3.5 倍，要求底层引擎具备强大的实时写入与弹性扩展能力。数据模型复杂：整个数据体系涵盖约 700 个核心字段，涉及物料、投放、用户、效果等多个维度；同时，为应对多样化分析场景，沉淀的查询模板已超 4000 个，对查询引擎的兼容性与性能均是严峻考验。架构演进：从分散存储到统一分析01 早期架构及挑战早期存储架构中，物料数据由 MySQL、Elasticsearch 协同存储；效果数据主要存储与 Clickhouse 中。数据分析时，将分散在 MySQL、Elasticsearch 中的物料数据与 ClickHouse 中的效果数据进行高效关联查询，从而为广告主提供完整、及时的投放效果洞察。在如上所说的 ClickHouse on ES 架构中，用户提交的查询通常包含 Elasticsearch 外表（a）与 ClickHouse 内表（b）。ClickHouse 会解析查询中外表部分，将其转换为 Elasticsearch 查询语句，通过 HTTP 请求获取数据并封装为 Block，最后在引擎内部完成与内表的关联计算。然而，随着 Elasticsearch 中数据量持续增长，该架构逐渐暴露诸多问题：查询性能恶化：慢查询率上升至 35%，平均查询耗时达到 1.4 秒；存储瓶颈：Elasticsearch 单分片难以支撑 10 亿级以上数据量，扩容与数据重分布成本高；运维复杂度高：数据链路依赖组件多，运维与监控成本显著上升；问题定位困难：缺少 ClickHouse 与 Elasticsearch 之间的全链路可观测手段，出现查询延迟、数据不一致等问题时，需跨系统排查，耗时较长。02 选型目标及调研基于上述问题及挑战，我们为新架构设定了明确目标：慢查询率低于 5%；运维排查耗时降低至分钟级；支持单表万亿级别数据存储；保障数据实时性，延迟低于 5 分钟。基于以上目标，我们对 Apache Doris、ClickHouse、Elasticsearch 等主流 OLAP 引擎进行了全面的调研与性能压测。测试涵盖了写入吞吐、查询延迟、存储压缩率、全文检索性能等关键维度。在这过程中，ClickHouse 首先被排除，因其不支持唯一键模型，而广告物料数据存在大量更新场景，要求引擎具备主键更新能力。因此，重点在 Elasticsearch 与 Apache Doris 之间进行对比。综合测试结果，Apache Doris 在写入性能、查询效率、存储成本及运维复杂度等方面均表现优异，不仅能够满足既定架构目标，还在多个场景下显著优于 Elasticsearch。因此，我们最终选定 Apache Doris 作为下一代广告数据分析引擎。03 基于 Apache Doris 的统一分析引擎在实际应用中，我们引入 Apache Doris（计算引擎） 替换了原先架构中的 Elasticsearch、ClickHouse，设计了统一分析引擎 Bleem。通过在外部表模块中引入数据缓存层与元数据服务层，有效提升了跨源查询效率，使数据湖外表的查询性能接近内表水平，实现了关键的性能突破。具体来看，Bleem 架构自下而上分为 5 层：存储层：数据湖中的 Hive/Hudi 数据存储于 HDFS；存算分离模式下的内表数据存放于对象存储 BlobStore；存算一体模式下的内表数据则存储于本地磁盘。缓存层：将 Hive/Hudi 外部表数据缓存至 Alluxio，保障 I/O 稳定性，提升数据读取效率。计算层：Apache Doris…

自建埋点分析系统的成本对比（含 ClkLog 开源方案）
type: item
date: 2026-01-26T15:06:21+08:00
description: 很多团队在业务发展到一定阶段后，都会认真评估一次：用户行为分析系统，是继续用现成产品，还是自己搭一套？实际上，当企业需要埋点分析时，往往已经没有太多时间成本可投入。业务方希望尽快看到数据结果，管理层关注投入产出比，而完全从零自建埋点系统，周期长、风险高、不可控。因此，基于成熟开源方案快速上线，再按需求自己二开，是目前更常见、也更可控的一种选择。这篇文章不讨论“埋点的重要性”，只做一件事：以自建埋点分析系统为参照，给出一个成本参考，并对比基于 ClkLog 开源方案的实际投入。完全自建一套埋点分析系统成本通常在几十万，且建设周期长、不可控因素多。基于ClkLog开源方案搭建首期成本可控制在几万，最快一周完成部署集成，可以快速交付使用，并具备持续扩展的能力。一、自建埋点分析系统，通常需要哪些模块？很多团队低估了“自建”的工作量，下面只列最基础、不可回避的部分：1.数据采集层（SDK + 埋点规范）这个阶段往往被低估，但实际上 SDK 会长期伴随业务演进，需要持续维护。2.数据接入与处理层核心目标是稳定接住数据：常见技术栈包括接入服务 + Kafka / MQ。3.数据存储层通常会选择 ClickHouse / Doris / Druid 这类分析型数据库，同时需要设计分区、冷热数据策略。4.复杂分析计算这是自建中最耗精力的部分，很多团队会发现：统计不难，难的是保证分析口径正确且性能可用。5.管理后台与可视化这部分前端和交互成本往往被严重低估。6.运维与长期维护系统上线只是开始，后续还包括各项调优、异常排查等运维工作。二、为什么很多团队不会选择「完全自建」？问题不在“能不能做”，而在是否划算。●早期业务验证阶段，数据系统很难直接创造业务价值●自建系统容错成本高，试错周期长因此，越来越多团队会选择：在成熟的开源埋点分析系统基础上建设，而不是从零开始。三、ClkLog开源方案能解决什么问题？ClkLog提供了一套可直接落地的开源埋点分析方案，不依赖第三方SaaS服务。全面覆盖了埋点系统中最重、最复杂的核心能力：1.数据采集层支持神策SDK与自研鸿蒙SDK2.数据接受层进行日志数据接收与存储3.数据处理层进行数据处理、归档等服务4.数据存储层使用clickhouse进行大量数据查询5.数据可视化内置多种成熟分析模型，开箱即用企业无需从零搭建底层能力，只需要围绕自身业务场景完成部署、运维和少量定制，即可形成一套可用的自有埋点分析系统。四、基于 ClkLog，企业实际需要投入哪些成本？1. 基础运行环境（参考）以 ClkLog 社区版为例，在 1万日活应用规模下，采用Docker方式部署，单台服务器即可满足基础使用需求。推荐配置参考：8核CPU；32GB内存在常见的云厂商环境中，约1-2万/年，即可覆盖服务器、云盘、流量、备份等成本。2. 软件部署与集成●获取ClkLog代码（Github/Gitee）●自行部署ClkLog服务（docker部署最快10分钟完成）●接入埋点SDK（兼容web/小程序/iOS/安卓等）●常规运维数据库和服务整体实施周期短，最快一天即可完成部署并交付使用。3. 业务层面的工作●埋点规范梳理●事件与指标定义●少量业务定制ClkLog已经内置十几种行业标准分析模型，可供业务直接开箱使用。若还有更多定制业务需要分析，可以通过自定义事件或二次开发来实现，与完全自建相比，省去的是部门团队沟通、大量底层系统设计与长期维护成本。五、写在最后对于大多数团队来说，先把系统跑起来、用起来、产生价值，比一开始追求完美更重要。如果团队希望：●完全掌控数据●又不想长期投入基础设施研发●把精力更多放在业务分析而不是系统本身那么，基于成熟开源方案搭建自己的埋点分析系统，是一个性价比较高、风险更可控的选择。

ClickHouse 数据库渗透测试指南
type: item
date: 2026-01-21T17:38:44+08:00
description: ClickHouse 数据库渗透测试指南目录1概述2信息收集3权限评估4文件读取利用5文件写入利用6命令执行利用7SSRF 利用8云环境利用9横向移动10防御绕过11常见限制与绕过12工具与脚本概述什么是 ClickHouseClickHouse 是由 Yandex 开发的开源列式数据库管理系统，专为在线分析处理（OLAP）场景设计。它能够高效处理大规模数据集，支持快速查询和实时数据分析。默认配置配置项默认值HTTP 端口8123TCP 端口9000MySQL 协议端口9004配置目录/etc/clickhouse-server/数据目录/var/lib/clickhouse/用户脚本目录/var/lib/clickhouse/user_scripts/用户文件目录/var/lib/clickhouse/user_files/渗透测试目标1 信息泄露：获取敏感数据、配置信息2 文件读取：读取系统敏感文件3 文件写入：写入 webshell、脚本、配置文件4 命令执行：实现 RCE（远程代码执行）5 横向移动：利用 SSRF 或数据库连接攻击内网信息收集1. 版本信息2. 用户与权限3. 数据库与表4. 服务器配置5. 集群信息6. 查询历史（敏感信息）7. 可用函数权限评估关键权限检查权限等级权限级别可执行操作只读用户SELECT 查询普通用户SELECT、INSERT、部分表函数DDL 权限CREATE、DROP、ALTERSOURCES 权限url()、mysql()、postgresql() 等管理员全部权限文件读取利用1. file() 函数读取2. 路径穿越（低版本可能有效）3. 软链接绕过（需要命令执行权限）如果有命令执行权限，可以创建软链接绕过目录限制：然后读取：文件写入利用1. INTO OUTFILE2. 写入脚本到 user_scripts 目录命令执行利用方法1：UDF 配置文件（需要配置文件写入权限）步骤1：创建 UDF 配置文件创建 /etc/clickhouse-server/cmd_function.xml：关键参数说明：● execute_direct=0：command 通过 sh -c 执行● execute_direct=1：command 在 user_scripts 目录查找脚本步骤2：确保 config.xml 包含步骤3：重启服务后执行方法2：带参数的交互式 ShellUDF 配置：执行命令：方法3：executable() 表函数方法4：Executable 表引擎方法5：Executable DictionarySSRF 利用1. url() 表函数2. 常见内网服务探测3. 批量内网扫描4. 其他 SSRF 函数云环境利用AWS阿里云腾讯云Google Cloud横向移动1. MySQL 连接2. PostgreSQL 连接3. remote() 连接其他 ClickHouse4. JDBC 连接（需要 JDBC Bridge）防御绕过1. 编码绕过2. 字符串拼接3. 使用变量常见限制与绕过托管环境限制限制状态绕过方法INTO OUTFILE 禁用常见无直接绕过，尝试其他写入方式Executable DDL 禁用常见尝试配置文件方式路径穿越阻止常见软链接（需命令执行）url() 内网限制少见DNS 重绑定配置文件只读常见无绕过工具与脚本1. 信息收集一键脚本2. Python SSRF 扫描脚本3. 批量端口扫描 SQL 模板.lakex-default-theme{--lakex-editor-background:#fff;--lakex-editor-background-primary:#fff;--lakex-editor-background-primary-hover:#EFF0F0;--lakex-editor-background-primary-hover-light:#E7E9E8;--lakex-editor-background-secondary:#FAFAFA;--lakex-editor-background-tertiary:#F4F5F5;--lakex-editor-background-foreground:#fff;--lakex-editor-border-light:rgba(0, 0, 0, 0.04);--lakex-editor-code-background:#0000000f;--lakex-editor-column-background-highlight:#D9EAFC7F;--lakex-editor-icon-secondary:#585A5A;--lakex-editor-selection:rgba(27…

ClickHouse 完成由 Dragoneer 领投的 4 亿美元 D 轮融资，加速其在分析与 AI 基础设施领域的扩张
type: item
date: 2026-01-20T10:03:35+08:00
description: 公司收购 Langfuse，正式进军 LLM 可观测性 (LLM observability) 领域，并推出原生 Postgres 服务，以统一事务型与分析型工作负载。旧金山 — 2026 年 1 月 16 日 — 实时分析、数据仓库、可观测性 (observability) 以及 AI/ML 领域的领导者 ClickHouse 今日宣布完成 D 轮融资，融资金额达 4 亿美元。本轮由 Dragoneer Investment Group 领投，Bessemer Venture Partners、GIC、Index Ventures、Khosla Ventures、Lightspeed Venture Partners、T. Rowe Price Associates, Inc. 管理的账户，以及 WCM Investment Management 共同参与。此次融资正值 ClickHouse 持续且加速增长之际。目前，公司通过全托管服务 ClickHouse Cloud 已服务超过 3,000 家客户，年度经常性收入 (ARR) 同比增长超过 250%。在过去三个月中，Capital One、Lovable、Decagon、Polymarket 和 Airwallex 等客户开始采用该平台或扩大了现有部署。这些新客户加入了 ClickHouse 已建立的客户群体，其中包括 Meta、Cursor、Sony 和 Tesla 等 AI 创新者及全球知名品牌。“ClickHouse 的初衷就是为最严苛的数据工作负载提供卓越的性能和成本效率，而今天的增长势头正是这一战略的最好证明，”ClickHouse 首席执行官 Aaron Katz 表示。“面向未来，我们正在支持统一的事务型与分析型工作负载，让开发者能够在坚实的技术基础之上构建各种由 AI 驱动的应用。同时，我们也在拓展产品能力，引入 LLM 可观测性，帮助 AI 应用构建者在进入生产阶段时，更好地评估 AI 输出的质量和行为。新的资金支持，加上持续的产品执行力，使我们有能力在 AI 时代打造领先的数据与 LLM 可观测性平台。”对大规模数据基础设施与 AI 的高度确信投资Dragoneer 成立于 2012 年，由 Marc Stad 创立，采用高度精选、以研究为核心的方法，专注于与少数具有品类定义意义的公司建立长期合作关系。过去十年中，该公司投资了多家领先的数据平台以及多家基础性的 AI 公司。随着 AI 系统逐步从实验走向生产，对底层数据基础设施提出了更高要求。AI 驱动的应用会产生远高于以往的查询量，对延迟更加敏感，同时还需要持续的评估能力和可观测性。在这样的背景下，真正的价值正越来越集中到那些能够支撑大规模、数据密集型生产工作负载的基础设施平台之上。“每一次重大的平台变革，最终都会回馈那些最贴近生产环境的基础设施公司，”Dragoneer Investment Group 合伙人 Christian Jensen 表示。“当模型能力不断提升，真正的瓶颈就转移到了数据基础设施上。ClickHouse 的突出之处在于，它能够在大规模 AI 系统运行时，提供所必需的性能、效率和可靠性。”在严谨的评估过程中，Dragoneer 认为 ClickHouse 已成为现代数据技术栈中具有品类定义意义的领导者。该平台广泛支持关键任务级的实时工作负载，深度嵌入于始终在线、面向客户以及 AI 驱动的系统之中。ClickHouse 的增长不仅来自对现有系统的替代，更来自对全新工作负载的支持。通过在大规模场景下实现高性价比的实时分析，ClickHouse 让许多过去因延迟或成本受限而无法落地的应用场景成为可能。与主要服务内部分析团队的许多数据基础设施平台不同，ClickHouse 经常直接嵌入到面向终端用户的产品中，在这些场景下，性能和可靠性会直接影响用户体验。“我们寻找的是在系统绝不能停机时依然值得客户信赖的平台，而 ClickHouse 一直展现出这样的能力，”Jensen 补充道。LLM 可观测性：ClickHouse 通过收购 Langfuse 进入该市场ClickHouse 正式宣布收购开源 LLM 可观测性平台 Langfuse。与关注系统健康和性能指标的传统可观测性不同，LLM 可观测性关注的是如何确保非确定性、日益复杂的 AI 系统能够输出准确、安全且符合用户意图的结果。随着 AI 系统不断深入生产工作流，LLM 可观测性已成为构建和运营 AI 应用团队不可或缺的一环。Langfuse 开源项目增长迅速，截至 2025 年底，已获得超过 2 万个 GitHub Star，每月 SDK 安装量超过 2,600 万次。“我们之所以在 ClickHouse 之上构建 Langfus…

拒绝造轮子：高频金融数据流的管道搭建实践
type: item
date: 2026-01-19T12:16:10+08:00
description: 做量化交易系统的后端开发，最头疼的不是策略算法（那是 Quants 的事），而是数据管道（Data Pipeline）的健壮性。特别是处理历史 Tick 数据时，我们面临的是一个典型的“高并发写入+高精度时序”场景。在早期的架构设计中，我经常因为低估了 Tick 数据的体量和复杂性，导致系统在回放时出现“幽灵交易”——即数据到达顺序与交易所撮合顺序不一致。工程上的三个拦路虎时间戳的绝对真理： 在分钟线级别，这一秒和下一秒区别不大。但在 Tick 级别，毫秒级的乱序就是灾难。工程上必须严格依赖 Exchange Timestamp 而不是本地接收时间。分页与流量控制： 也就是 Pagination。一次请求拉取全天 Tick 是不现实的，HTTP 响应体过大会导致超时或内存溢出。异构数据源： 历史归档数据通常是冷存储结构，而实时流是 WebSocket 热数据，如何用一套代码兼容这两种接口？高效的解决方案为了解决这些 IO 密集型任务，我的思路是：将数据获取层（Ingestion Layer）完全解耦。不要尝试自己在应用层去清洗原始报文。目前比较成熟的做法是直接对接第三方聚合 API。以我目前使用的 AllTick API 为例，它在服务端已经做好了清洗和标准化。这就相当于把复杂的 ETL 过程外包了出去，我们只需要通过简单的 HTTP 请求拿到 JSON 格式的结构化数据。这样，我们的工程重心就可以从“怎么抓数据”转移到“怎么用数据”上。代码实现：构建数据拉取器下面是一个基于 Python requests 库构建的简单拉取器原型。注意看参数中的 limit 和时间窗口设置，这是处理大流量数据的关键：import requests API_KEY = "YOUR_API_KEY" BASE_URL = "https://api.alltick.co/v1/market/tick/history" params = { "symbol": "AAPL.US", "market": "US", "start_time": "2024-01-02 09:30:00", "end_time": "2024-01-02 09:31:00", "limit": 1000 } headers = { "Authorization": f"Bearer {API_KEY}" } resp = requests.get(BASE_URL, params=params, headers=headers) data = resp.json() for tick in data.get("data", []): ts = tick["timestamp"] price = tick["price"] volume = tick["volume"] print(ts, price, volume)架构师视角的补充在实际生产环境中，这段代码拉下来的数据，我不建议直接进 Pandas 分析，而是应该先进入消息队列（如 Kafka）或者写入 ClickHouse 这样的列式数据库。为什么？因为历史 Tick 的价值在于高保真回放。标准化的接口解决了“源头”问题，而合理的存储架构解决了“流转”问题。这才是构建低延迟交易系统的正确姿势。

从 OTel 到 Rotel：每秒处理量提升 4 倍的 PB 级追踪系统
type: item
date: 2026-01-08T12:04:28+08:00
description: 今天这篇博客文章由 Streamfold 的 Mike Heffner 和 Ray Jenkins 撰写。他们是 Rotel 的维护者，该项目是一个用 Rust 编写的开源工具，致力于实现高性能、资源高效的 OpenTelemetry 数据采集。TLDR;大规模系统中的效率至关重要：哪怕是资源消耗的小幅下降，也可能带来显著的成本节约和效率提升。OTel + ClickHouse 的基准测试：我们构建了一套数据管道，用于评估将流式追踪数据写入 ClickHouse 的性能。Rotel 实现了 4 倍性能提升：我们展示了如何将 OTel Collector 每核每秒处理 13.7 万个追踪跨度 (trace span) 提升到 Rotel 的 46.2 万个，并详细说明了多项关键的性能优化。工具和资源：文末提供了我们在基准测试中所用的工具清单。引言在 PB 级规模下运营一个可观测性平台，需要持续关注资源利用效率。即便是每核性能或内存使用上的细微改进，也能大幅降低基础设施开销。本文源自我们在丹佛举办的一场 ClickHouse 技术见面会的演讲。在会上，我们分享了我们对 Rotel 的开发工作。Rotel 是一个面向大规模系统的高性能 OpenTelemetry 数据平面 (data plane)。得益于其高压缩比和良好的成本效益，ClickHouse 越来越多地被用于大规模的 OpenTelemetry 负载中。而在这些系统中，OTel Collector 往往是整条数据管道中成本最高的部分。最近，ClickHouse 发布了一篇关于大规模系统中效率重要性的文章（https://clickhouse.com/blog/scaling-observability-beyond-100pb-wide-events-replacing-otel），并介绍了他们在内部平台 LogHouse 上运行 OTel 的实际经验。其中有个细节引起了我们的注意：“OTel Collector：使用超过 800 个 CPU 核传输每秒 200 万条日志。”按每核每秒约 2500 条日志计算，对于典型的日志行来说，这意味着一个 8 核服务器每秒仅能传输约 10MB，远远低于现代硬件的处理能力。而 ClickHouse 每核每秒最多可处理超过 1.25 万条 OTel 事件，吞吐能力是前者的五倍以上。因此，当前的瓶颈在数据采集端，而非存储端。尽管我们无法复现 ClickHouse 内部的 LogHouse 平台，但我们认为，对现代 OpenTelemetry 数据管道进行基准测试仍具有重要意义。因此，我们希望借此次演讲探讨一个核心问题：将追踪数据发送到 ClickHouse 时，不同的 OpenTelemetry 数据平面表现如何？本文将逐步介绍我们构建的基准测试流程，比较 OpenTelemetry Collector 和 Rotel 的性能。我们搭建了一套合成的追踪数据管道，先通过 Kafka 传输追踪跨度，再写入 ClickHouse。在 OTel Collector 达到 110 万跨度/秒的基准测试后，我们展示了通过以下几项优化如何让 Rotel 在相同硬件上实现最高 370 万跨度/秒的处理能力：实现 JSON 的二进制序列化、分析 Tokio 任务调度性能 (perf analysis of Tokio task management)、以及引入改进的 LZ4 压缩算法。文末我们还列出了用于此次基准测试的框架和工具。基准测试框架在进入测试结果之前，我们先介绍一下评估 OpenTelemetry Collector 和 Rotel 所采用的测试方法。如果你感兴趣，也可以直接跳转到结果部分，链接见这里。追踪数据管道我们此次基准测试的重点是将追踪跨度 (trace span) 写入 ClickHouse，因为在大型系统中，追踪数据增长极快。我们参考了一个高度可靠的流处理管道进行建模，选用 Kafka 作为日志流层。测试目标是模拟这样一种场景：大量边缘采集器将数据发送至 Kafka 流，由少数几个核心采集器批量写入 ClickHouse。在这个管道中，Rotel 和 OTel Collector 使用相同的 Kafka Protobuf 编码，因此两者可以互换使用。评估方法我们希望找出在固定硬件条件下，单个采集器能够稳定支持的最大吞吐量，重点关注的是采集效率，而非系统扩容能力。测试的关键是观察单节点在不降级的前提下可以被“压榨”到什么程度，同时也控制在我们的评估预算范围内。我们选择网关采集器作为测试核心组件，因为它直接将数据输出至 ClickHouse，而后者在处理大批量数据插入时效率最高。为实现更高的批处理效率，部署少量、但能力更强的网关采集器是理…