Databricks 为何在实时分析上难敌 ClickHouse Cloud

所有基准测试代码和结果均可在 CostBench 仓库 中获取。股票报价数据集需要 单独的数据许可，因此数据本身无法再分发。

为解释该结果，我们沿循与数据相同的路径：先讲准备阶段，再讲查询服务。

ClickHouse Cloud 如何准备传入数据

该基准测试使用了一个专用的 ClickHouse Cloud 摄取服务，配备 两个 2-CPU 节点以实现高可用性，这是在校准期间能够维持目标速率的最小 HA 配置。共享客户端通过 异步插入 发送行数据，该机制内置于每个节点。

下图展示了这些相同的节点如何在 总共四个 CPU 核心 上处理 ① 列式存储、② 对原始数据排序、③ 有序预聚合，以及后台合并。

① 按列存储并 ② 对数据排序： 当摄取节点刷写其异步插入缓冲区时，它会按 MergeTree 表的 (sym, t) 键（股票代码和事件时间戳）对原始报价进行排序，并写入一个有序的 数据部分。

③ 对数据排序并预聚合： 同一节点在内存中对传入的数据块运行 增量 MV 查询，计算聚合状态，并按 AggregatingMergeTree 表的 (sym, day) 键对结果排序，然后写入一个包含汇总信息的有序部分。

后台合并 会合并两个表中的部分。

结果是：原始数据和预聚合 同步推进，来自同一个已刷写的插入块，无需单独的刷新周期。

四核摄取服务处理了多少工作量？（点击展开） ClickHouse writer-utilization 结果 显示摄取与后台维护同时进行。CPU 使用率保持在 4 个可用核心中的约 3.1 个，跟踪的内存保持在容量范围内，后台合并每秒处理数百万行，每个分区的最大活跃部分数保持在 100 左右。这些诊断信息描述了本次比较中复用的 ClickHouse 源运行。

两个节点均被保留以实现高可用性，因此准备成本包含完整的双节点部署。

现在，通过 Databricks 来追踪相同的三项准备任务，其中摄取、聚类和 MV 刷新使用不同的服务。

Databricks 如何准备传入数据

该基准测试使用了 Zerobus Ingest，这是 Databricks 通过 Arrow Flight 流将行直接推入 Delta 表的托管路径。

如下所示，Zerobus 处理 ① 列式存储；异步无服务器聚类处理 ② 对原始数据排序；一个独立的无服务器 MV 管道处理 ③ 预聚合。

① 按列存储： Zerobus 缓冲传入的行，并将其发布到由列式 Parquet 文件支持的托管 Delta 表。持久性确认表明 Zerobus 已持久地接受数据；它并不保证数据在表中立即可见。

② 对数据排序： 原始表在 (sym, t) 上使用了 liquid clustering，与 ClickHouse 的排序键匹配。 Predictive Optimization 在无服务器计算上异步运行聚类，因此新发布的文件可以在该布局工作完成之前被查询。

③ 对数据排序并预聚合： 一个独立的 无服务器管道 增量刷新每日汇总，按 (sym, day) 聚类。 测试的定义 使用了 REFRESH POLICY INCREMENTAL STRICT 和 TRIGGER ON UPDATE AT MOST EVERY INTERVAL 1 MINUTE。该触发器使用 Databricks 支持的最小间隔 1 分钟；它限制的是刷新启动时间，而不是完成时间。

为什么选择这些摄取路径，以及它们是如何缓冲的？（点击展开） 相同的摄取问题

应用程序产生频繁写入，这些写入必须转化为高效的存储写入。两个目标都使用了直接应用程序到表的摄取，并配有托管缓冲。测量路径中未添加 Kafka 代理、文件落地阶段或 Auto Loader 作业。

DATABRICKS 的托管路径

已接受的运行器 使用了 Zerobus Arrow Flight DoPut 接口，具有 16 个并发流和 50,000 行的客户端批次。流每十分钟轮换一次；启用了 SDK 恢复和有界重试。Zerobus 摄取计算与聚类、MV 刷新和 SQL 服务分开分配和计价。

CLICKHOUSE 的原生路径

启用 async_insert 的普通 INSERT 请求在每个接收节点上被缓冲。一个 自适应刷写超时 响应传入流量。排序和预聚合在摄取节点上运行；专用的 摄取服务 与独立扩缩的读取服务共享存储。

共享节奏

两个适配器读取相同的 Parquet 数据集，并在相同的目标速率模型下解码相同的 schema。并行度和客户端批次大小根据每个目标的 API 进行调整；并未强制要求它们完全相同。

CLICKHOUSE 批次

客户端通过异步插入发送 3,000 行的批次。默认缓冲在三个阈值中第一个达到时刷写：缓冲 100 MiB、50 毫秒到 1 秒之间的自适应超时，或 450 个排队的插入查询。

DATABRICKS 批次

每个 Arrow Flight 流发送 50,000 行的批次，并禁用 IPC 压缩。目标速率基于逻辑源行数，确认的持久进度与表可见性分开记录。这些批次并未暂存为文件以供后续批量加载。

批次大小边界

这些是客户端投递批次大小。两个系统都会将投递缓冲为存储写入，因此 3,000 和 50,000 行并不指定最终部分或 Parquet 文件的大小。

重试与对账

Zerobus 使用了持久流偏移量和 SDK 恢复。 最终验证 确认了精确的行对账，且没有重复盈余。ClickHouse 支持重试时的插入去重，包括依赖的物化视图。最终行检查验证的是投递，而非摄取期间汇总的新鲜度是否相同。

增量维护

原始 Delta 表启用了行跟踪、变更数据馈送和删除向量。MV 通过了增量资格检查，并使用了 INCREMENTAL STRICT。 刷新证据在采集到的运行中，包括摄入后观察期在内，记录了 1,028 次增量组聚合刷新和零次完整刷新。

测试内容

服务层为 Serverless SQL X-Small。工作区中不提供 Lakehouse//RT，因此未对其进行测试。本文描述的是已采用的配置及其结果，而非对不可用的服务产品进行性能预测。

结果：Databricks 可以在聚类完成之前就暴露原始数据，而其预聚合则通过单独的刷新周期推进。

这对新鲜度和准备成本意味着什么

预聚合延迟

ClickHouse 在插入期间更新摘要；Databricks 异步刷新它们。下图跟踪 Databricks 的刷新节奏：观测到的已完成刷新平均间隔约为 1.8 分钟，在绘制的趋势中达到约 2.0 分钟。

这些是观测到的刷新完成之间的间隔，而非对每个摘要落后原始表多少的精确测量。在刷新之间，针对 Databricks MV 的查询可能返回较旧的摘要。

预聚合新鲜度是如何测量的？（点击展开） DATABRICKS 系列

该新鲜度历史每分钟轮询一次。绘制的指标是不同观测到的已完成刷新 ID 之间的时间：floor(当前 completed_at − 先前观测到的 completed_at)，单位为秒。选定的活跃摄入证据包含 1,021 个此类间隔；紧凑轮询可能会遗漏中间完成项。

平滑与读数

居中 61 个观测值的滚动平均值在间隔观测中平均约为 1.8 分钟。额外的 11 个观测值显示均值和保形插值产生约 2.0 分钟的绘制峰值。读数遵循该显示曲线。这是刷新间隔的代理指标，而非直接轮询的原始到 MV 水位线延迟或每查询的陈旧行计数。

CLICKHOUSE 基线

零线是基准语义基线，而非单独轮询的提供商指标。原始表和增量 MV 消费相同的已刷新插入块，它们之间没有独立的摘要刷新间隔。它并不声称源到查询的摄入延迟为零。

ClickHouse 在摄入期间保持摘要最新；Databricks 观测到的刷新间隔约为 1.8 分钟，使查询能够读取较旧的摘要。

这种新鲜度差异会跟随数据进入查询。首先，下一张图表说明了每条准备路径的成本。

保持传入数据可查询的成本

ClickHouse 在其引擎内处理 ① 列式存储、② 原始数据排序和 ③ 有序预聚合。Databricks 将这些工作分散到摄入、无服务器聚类和 MV 刷新中。下图比较了它们累积的准备成本。

ClickHouse 的完整摄入服务成本为$28.69。Databricks 的建模准备成本合计为$695.60：$428.58用于 Zerobus 摄入（①），$59.23用于异步聚类（②），以及 $207.80用于 MV 刷新（③）。摄入和刷新使用分配的 DBU 用量；折叠的定价说明给出了边界。

在此次运行中，ClickHouse 以低 24.2 倍的准备成本处理了列式存储、排序和预聚合。

现在跟随原始数据和摘要进入查询服务。

ClickHouse Cloud 如何服务查询

有序原始数据让下钻可以跳过无关行；预聚合让交互式聚合可以组合已准备好的结果，而不是从单个报价重新计算它们。下图展示了通过 ClickHouse Cloud 读取服务的两条路径：一个具有 16 个 CPU 和 64 GiB 内存的节点，与 Databricks 的 X-Small 工作节点 CPU 数相匹配。

下钻： 查询在 事件级 MergeTree 表中修剪有序原始数据。按 symbol（其 (sym, t) 排序键的前导列）进行过滤，让读取服务可以跳过无关报价。

交互式聚合： 查询从 当前预聚合中读取 AggregatingMergeTree 表，从一组小得多的每日摘要行中组合已准备好的计数、总和、最小值和最大值。没有需要等待的独立刷新。

结果：下钻修剪有序原始数据；交互式聚合读取在摄入期间保持最新的摘要。

Databricks 使用相同的两条查询路径，但异步准备改变了查询可以读取的内容。

Databricks 如何服务查询

下图展示了一个 X-Small Serverless SQL 仓库同时服务两个工作负载，固定为一个集群，具有 16 个工作节点 vCPU。

为什么没有包含 LAKEHOUSE//RT？（点击展开） Lakehouse//RT 目前处于 Beta 阶段。我们已请求访问权限，但尚未获得。

一旦 Lakehouse//RT 正式可用且我们获得访问权限，我们计划使用 Lakehouse//RT 服务查询来重复完整的 CostBench 工作负载并发布结果。

下钻： 查询直接读取 Delta 表并按 symbol 过滤。在 (sym, t) 上的 Liquid 聚类有助于在聚类运行后跳过无关文件，但新发布的文件在异步维护跟上之前可能保持未聚类状态。

交互式聚合： 查询从 增量 MV中读取每日摘要。它们看到的是最后一次完成的刷新快照；更新的原始行不会在查询时自动与其组合。因此答案可能遗漏已经到达原始表的数据。

两条路径所展示的区别： 下钻可以扫描聚类尚未完成的数据；交互式聚合可以读取刷新尚未完成的摘要。两者都源于与摄入分开推进的准备过程。

DATABRICKS 的刷新和可见性保证意味着什么？（点击展开） 快照契约

一次 刷新从其源表更新 MV。被测聚合查询直接读取该物化结果。它们没有在每次查询前强制同步刷新，也没有将原始表增量合并到答案中。因此，测得的延迟包含了 Databricks 对陈旧摘要的原生允许。

触发契约

TRIGGER ON UPDATE在上游数据变化时调度刷新。AT MOST EVERY INTERVAL 1 MINUTE 对触发之间施加最小间隔，而不是对数据时效或刷新完成施加一分钟的最大值。

增量契约

INCREMENTAL STRICT 控制维护方法：符合条件的变更以增量方式处理，而不是静默回退到完全重建。它不会将物化视图的可见性绑定到每个摄取的数据块，也不会使物化视图持续保持最新。

可见性契约

运行器的 raw_rows 记录了已确认的持久摄取进度。Zerobus 可以在行被发布到 Delta 表之前持久地接受行。因此，按持久摄取进度对齐的一对查询并不能证明两个查询看到了完全相同的原始行数或同样新鲜的汇总快照。

比较边界

该核心结果保留了经过测试的物化视图服务路径，包括其新鲜度行为。强制刷新或查询并重新聚合原始表的设计会有不同的延迟和成本特征；那项工作不包含在此结果中。

结果是：Databricks 的下钻可能扫描新到达的、未聚簇的数据；交互式聚合可能读取较早刷新的摘要。

这对查询性能和成本意味着什么

对有序原始数据的下钻

两个系统都使用 (sym, t) 键，但 ClickHouse 在插入期间对行排序，而 Databricks 异步地对文件进行聚簇。D1 和 D2直接查询一只股票不断增长的历史：小时价格摘要以及风险与流动性画像。下图遵循该原始数据路径，绕过物化视图。

ClickHouse Cloud 为黄色；Databricks 为红色。

查询延迟和累积结果是如何比较的？（点击展开）查询定义

第 1 部分描述了 A1–A4 和 D1–D2。两个系统使用相同的分析工作负载和时间表，SQL 针对每个引擎进行了适配。计数、求和和极值被精确比较；D2 的近似百分位数部分使用了契约中的显式容差。物化视图的新鲜度未被假定为相同。

缓存策略

查询结果缓存被禁用。Databricks 的紧凑查询证据报告，被接受的查询没有结果缓存命中。底层数据缓存被允许正常预热；基准测试未在查询之间清空它们。

计时

Databricks 延迟使用查询历史 total_duration_ms ÷ 1,000，不包括结果拉取时间。ClickHouse 使用其记录的查询持续时间。这些计时约定保留在归一化查询成本中。中位数、P99 和最大值统计汇总了截至 1000 亿行的未经平滑的逐查询观测值；P99 使用线性插值。

延迟图表

每个系统按其自身观测到的摄取进度绘制。总体趋势使用居中的七次观测滚动中位数；下钻使用五次观测，边缘窗口收缩。未移除任何离群值。曲线为显示平滑；统计数据和累积总计使用原始记录的持续时间。

交互式读数

图表下方的值遵循所选行数处显示的趋​​势。对数刻度使毫秒和秒可一起读取；线性显示绝对差异。每个图表都有自己的播放和行位置控件。

已接受的累积工作负载

该已接受的选择包含每个系统 189 个四查询聚合批次和 32 个双查询下钻批次：756 + 64 = 820 次执行。ClickHouse 观测值与 Databricks 持久性进度对齐，聚合达到 1128.49 亿行，下钻达到 1116.49 亿行。首次全数据集观测及之后摄取后的样本被排除。

累积图表

查询持续时间在对应的摄取计数处作为阶跃和相加，不进行平滑或将未来执行插值到较早位置。准备成本线按行进度按比例分配完整摄取总计；它们不是按时间计量的成本轨迹。得分对查询持续时间求和，而不是对经过的摄取时间求和。

ClickHouse Cloud：

• 722.5 毫秒中位数 - 比 Databricks 快 22.1 倍
• 1.15 秒 P99 - 快 42.7 倍
• 1.18 秒最大值 - 快 48.2 倍

累积运行时间为46.07 秒，跨 32 个双查询批次。随着表增长，有序原始数据路径使两个下钻都保持在或低于一秒。

Databricks：

• 15.99 秒中位数
• 49.11 秒 P99
• 56.90 秒最大值

累积运行时间为18.88 分钟，跨相同的 32 个批次。曲线显示读取不断增长的原始表所花费的时间明显更多；异步聚簇可能使新文件对符号过滤器的组织程度较低。

在下钻工作负载中，ClickHouse Cloud 总体快 24.6 倍。

对有序预聚合数据的交互式聚合

每日预聚合让A1–A4组合准备好的计数、求和以及价格最小值和最大值。A1–A2 按符号过滤摘要；A3–A4 跨所有符号读取。ClickHouse 读取在插入期间维护的摘要；Databricks 读取最后刷新的快照。下图比较摄取持续进行时的延迟。

ClickHouse Cloud：

• 13 毫秒中位数 - 比 Databricks 快 60.2 倍
• 42 毫秒 P99 - 快 48.4 倍
• 111 毫秒最大值 - 快 47.7 倍

累积运行时间为10.31 秒，跨 189 个四查询批次。

Databricks：

• 782 毫秒中位数
• 2.02 秒 P99
• 5.30 秒最大值

累积运行时间为10.22 分钟，跨相同的 189 个批次。这些查询读取物化视图快照，而不等待其下一次刷新。即使通过原始数据插入路径维护摘要，ClickHouse 也更快；Databricks 所测得的​​速度并未伴随相同的新鲜度。

在交互式聚合工作负载中，ClickHouse Cloud 总体快 59.5 倍，且摘要在插入期间维护。

累积查询成本和运行时间

两条查询路径的加总方式不同：下钻占 Databricks 累积运行时间的大部分。下图合并两个工作负载，并使用基准测试的读取侧成本模型为其记录的持续时间计价。

ClickHouse Cloud 累积56.39 秒的查询运行时间，Databricks 为29.10 分钟它们归一化后的查询服务成本分别约为 0.05 美元和 2.65 美元。这些是查询工作的成本，而非完整的仓库账单。

在整个查询工作负载中，ClickHouse Cloud 总体快 31 倍，归一化查询成本低 54.2 倍。

来自现场：Gala

Gala 从 Databricks 迁移到 ClickHouse Cloud，展示了以更低成本实现更快分析的生产效益：可用于分析的数据更多，自助分析可供更多团队使用。在 AWS 上，该团队增加了来自更多数据源的持续摄取，并推出了 Metabase，以便业务团队可以自行探索数据。到迁移结束时，它已停用 Databricks。

由于新布局从一开始就配置正确，之前在未优化表上的查询从数分钟缩短到 不到 1 秒。迁移期间可用于分析的数据从 3 TB 增长到 9 TB，而初始成本降低了 30%。“我们不再那么多地考虑数据基础设施了，”Gala 的首席数据分析师 Mike Rexford 说。阅读 Gala 的迁移故事。

Databricks 在实时分析方面无法与 ClickHouse Cloud 匹敌

当新数据不断到达时，ClickHouse Cloud 在完整的测试路径上全面领先：

① 准备成本：低 24.2 倍，用于摄取、排序和预聚合。 ② 归一化查询成本：低 54.2 倍，针对这些查询。 ③ 累计查询运行时间：低 31 倍，跨两个查询工作负载。

最后一张图将这些结果汇总在一起，在新数据到达时，将合并的准备成本和归一化查询成本与累计查询运行时间进行对比。

向上表示总建模成本更低；向右表示累计查询运行时间更低。

ClickHouse Cloud 在持续摄取数据并提供查询服务的同时，实现了每美元 752 倍更好的端到端性能，并且在插入期间保持摘要为最新。

差异从数据到达时就开始了。ClickHouse 在插入路径上准备好有序原始数据和当前摘要。Databricks 增加了单独的聚类和刷新服务，其查询可能会遇到未完成的布局工作或较旧的摘要。在此工作负载中，这些服务的运行成本更高，而且两条查询路径都仍然耗时更长。

这就是为什么 Databricks 在实时分析方面无法与 ClickHouse Cloud 匹敌。