TL;DR

CostBench 测得，与 Snowflake、Databricks、BigQuery 和 Redshift Serverless 相比，ClickHouse Cloud 的每美元端到端性能高出 412 倍至 1,996 倍。

本文将通过图文并茂的方式带您了解 ClickHouse Cloud，从准备传入数据到快速查询和弹性伸缩。我们将解释这些机制如何相互增强，并展示它们为实时应用和智能体带来的能力，并附上客户在生产环境中运行这些应用的示例。

本文是当前 CostBench 系列的收官之作。此前部分：方法论 · Snowflake · Databricks · BigQuery · Redshift

“市面上没有任何产品能与 ClickHouse 竞争” #

这是 Tesla 高级主任软件工程师 Alon Tal 对 ClickHouse 的描述。在一次为期 11 天的负载测试中，Tesla 每秒摄入十亿行数据，累计超过一千万亿行。

在 Cloudflare，这种规模体现在查询侧。工程高级总监 Jamie Herre 演示了查询在不到两秒内返回结果，无论查询覆盖一整天的活动数据——1.61 千万亿个事件——还是整整一年。

这两个示例都要求整个分析路径上的高效性。传入事件必须在查询持续运行于不断增长的数据集之上的同时，变得可供分析。组织这些事件并维护最新汇总本身就有成本，并决定了每个查询还剩多少工作要做。

CostBench 将这种准备和查询执行一起衡量。我们将 1132 亿条股市报价流式传输到 ClickHouse Cloud、Snowflake、Databricks、BigQuery 和 Redshift Serverless 中，在整个摄入过程中同时运行分析查询。我们跟踪了汇总新鲜度、准备成本、查询成本和查询运行时。

在四项对比中，ClickHouse Cloud 均实现了最低的准备成本、查询成本和累计查询运行时间。这些优势共同带来了每美元端到端性能提升 412 倍至 1,996 倍。

基准测试代码、查询、配置、测量结果以及复现结果的说明均可在 CostBench 仓库中获取。

前面的文章通过各提供商的架构追踪了其结果。这篇最终文章将带您深入了解 ClickHouse Cloud 的内部机制，追踪新数据从到达至分析答案的全过程。我们解释高效的准备、并行化查询执行和 Cloud 扩展如何塑造 CostBench 的结果，以及它们为实时应用和智能体带来了什么。

无与伦比的每美元端到端性能 #

CostBench 的端到端评分将 ① 准备新数据的成本与 ② 查询服务成本相结合，然后将该总计乘以 ③ 累计查询运行时间。越低越好：高效的准备和快速的查询执行都能改善结果。

ClickHouse Cloud 的每美元端到端性能比 Snowflake 好 412 倍，比 Databricks 好 752 倍，比 BigQuery Capacity 好 438 倍，比 Redshift Serverless 好 1,996 倍。

相同的工作负载和准备要求。所有系统接收相同的数据，并按相同的时间表运行相同的查询。原始数据和每日预聚合使用匹配的排序键或聚簇键。

查询计算：尽可能对齐。某些平台动态分配计算资源。可配置的规格可能在 CPU 数量上有所不同，或在相同核心数下提供不同数量的 RAM。我们在可能进行有意义匹配的地方对齐了查询计算。

摄取和准备：尽可能降低成本。对于可配置服务，我们使用了在校准期间维持目标速率且保持数据可查询的最小测试配置。在平台控制摄取或维护计算的情况下，其原生分配和费用仍作为比较的一部分。

比较这些支出所带来的效果。额外的查询计算可以换来更快的答案。在持续准备上的支出可以减少查询的工作量，从而降低其运行时间和成本。CostBench 使用一个自动权衡结果查询速度与准备和查询服务总成本的评分，按每美元端到端性能对系统进行排名。更昂贵的配置必须提供足够快的答案来证明其更高成本的合理性。

第 1 部分解释了完整的方法论。

下面的细分展示了在数据到达过程中这一领先优势是如何形成的。在所有对比中，ClickHouse 结合了最低的准备成本、最低的查询成本和累计查询运行时间。

来源：测量与方法论

ClickHouse Cloud 通过其完整的高可用摄取服务，以 28.69 美元摄取并准备了全部 1132 亿行数据。此处展示的概览记录了 ClickHouse 约 0.05 美元的总查询成本和累计 1.03 分钟的查询运行时间，同时其每日汇总与原始数据保持同步更新。

规模化实践中的更低成本：Buildkite 的迁移展示了这些经济性如何转化为生产环境：将工作负载迁移到 ClickHouse Cloud 后，净基础设施支出每月减少了五位数，同时事件摄取量翻了两番。

要了解这一优势的来源，请跟随数据流经 ClickHouse Cloud 的过程——从准备传入事件到回答下一次查询。

通往查询就绪数据的最快、最低成本路径 #

实时分析依赖于保持新数据随时可供下一次查询使用。CostBench 测量了在查询持续运行的同时，摄取报价流、排序原始历史数据以及维护每日汇总的工作量。

ClickHouse 在数据准备方面的领先优势 #

ClickHouse Cloud 是唯一一个每日汇总在其原始数据就绪时即可查询的测试系统。其零延迟线表明，新写入的原始行始终与其汇总保持同步。

来源：测量与方法论

ClickHouse 在插入期间更新预聚合，因此原始数据和汇总同步推进。其他测试系统在原始数据写入后异步刷新预聚合，从而产生了上图所示的延迟。

保持原始历史和每日汇总均可查询的同时，准备成本最低。在 ClickHouse Cloud 中准备全部 1132 亿行数据花费 28.69 美元，相比之下，Snowflake 约为 79 美元，BigQuery Capacity 为 243 美元，Redshift Serverless 为 522 美元，Databricks 为 696 美元。

来源：测量与方法论

其他受测技术栈涉及额外的摄取或维护服务，通常需要单独收费。ClickHouse 在同一个引擎内完成了全部三个准备步骤——列式存储、排序和预聚合——这些工作已包含在摄取服务成本中。

领先背后的引擎内幕 #

ClickHouse 通过在数据仍驻留内存时对其进行排序和预聚合，将准备开销保持在较低水平。

在内存中对传入数据进行排序和预聚合 #

传入数据以直接接收的客户端批次或异步插入缓冲区的形式进入内存。随后，ClickHouse 按原始表的排序键（股票代码和时间）对原始报价进行排序，并使用增量物化视图计算每日汇总，再按汇总表的排序键（代码和日期）对汇总进行排序。两者随后作为已排序、压缩的列式数据部分写入磁盘，避免了为初始准备而进行的单独写入再读取循环。原始数据和汇总从同一传入数据同步推进。

其他受测路径将原始数据的排序以及汇总的预聚合和排序留到初始写入之后的独立异步阶段。新的原始行在其汇总刷新之前就已可用，因此这些路径无法保证两者之间零延迟。下方的动画展示了这两个阶段如何落后于数据摄取。

这些阶段从存储中读回数据，增加了准备工作量和 I/O。新写入的原始行可能仍在等待排序，而其有序汇总则落后更多。

用 ClickHouse Cloud 进行测试

在您自己的数据上体验高效的数据准备和并行化查询执行如何运作。用您的实时工作负载探索 ClickHouse Cloud。

在数据仍驻留内存时进行准备可将开销保持在较低水平。ClickHouse 还通过并行化执行来加速这项工作。

ClickHouse 旨在将硬件性能推向极限 #

ClickHouse 会尽可能利用底层基础设施提供的全部算力。其引擎在节点、CPU 核心和 SIMD 通道之间并行化数据准备和查询执行。我们将从数据准备开始，然后展示同样的方法如何贯穿到查询执行中。

不同节点可以并发处理不同的插入操作，无需任何同步。在 ClickHouse 中，并发插入操作彼此隔离。每次插入都会写入新的数据 part，每个 part 都有自己的稀疏主索引和元数据。因此，节点可以在不重写现有数据、不更新表级共享索引的情况下准备数据。

在每个节点内部，ClickHouse 会跨 CPU 核心并行执行排序和预聚合。聚合使用可合并的部分聚合状态：每个 CPU 核心可以聚合自己负责的行子集，这些状态可以合并为正确的结果。ClickHouse 为其 200 多个聚合函数及其组合器使用这一模型。在数据摄取期间，这些状态会被写入汇总表。我们的 GROUP BY 演练展示了具体示例。

在每个核心内部，ClickHouse 以批处理方式处理列式数据（向量化执行），并使用 SIMD 指令对多个值一次性执行受支持的操作。

下面的动画从摄取节点放大到一个节点的 CPU 核心，再放大到一个核心的 SIMD 通道。

在持续插入的同时，ClickHouse 会跨 CPU 核心并发运行多个后台 part 合并。在汇总表中，这些合并通过组合来自不同批次的部分聚合状态，延续插入时开始的预聚合，逐步将聚合工作从查询时转移到后台合并时。它们还会将原始数据和汇总数据整合为更少、更大的 part，同时保持每张表的 ORDER BY 顺序。查询会组合剩余状态以返回当前答案，而无需扫描最近的原始事件来追赶进度。我们的 VLDB 架构论文描述了这一设计。

引擎性能数据 #

在基准测试运行期间，我们通过内置的 ClickHouse Cloud 高级仪表盘监控了摄取服务的吞吐量、资源使用、数据缩减和后台合并，

CostBench 向每个系统流式写入了 1132 亿条股票市场报价，目标是在分析查询运行的同时达到每秒 100 万条传入行。ClickHouse Cloud 是唯一一个其每日汇总数据与原始数据同时可查询的受测系统。

其高可用摄取服务有两个节点，每个节点有两个 CPU 核心和 8 GiB 内存——总共四个核心和 16 GiB。这些核心使传入批次可查询，并将剩余 CPU 容量用于并行后台合并，包括对汇总数据的持续预聚合，而查询则在单独的读取服务上运行。下面测得的速率描述的是该工作负载，而不是四个核心的最大摄取容量。28.69 美元的准备成本是所有受测系统中最低的，涵盖了摄取节点及其后台工作。

如下方动画所示，并行摄取和后台合并共同处理了约 430 MB/s 的未压缩数据，同时使用了四个可用 CPU 核心中的约 3.2 个——每个已用核心约 135 MB/s。这一处理能力可以通过增加 CPU 核心和摄取节点来扩展。稍后，我们将展示 ClickHouse Cloud 如何独立于查询计算来扩展摄取计算。

来源：测量与方法论

在摄取期间，同样的四个核心还在所有受测系统中实现了最佳的原始数据压缩，将 7.08 TB 原始数据缩减至 491.2 GB（14.4 倍）。

来源：测量与方法论

在约 1132 亿条报价下，ClickHouse Cloud 在所有五个被测系统中记录的原始数据大小最小，如下方对比所示。

来源：测量与方法论

到摄取结束时，ClickHouse 维护的每日汇总行数比原始报价历史少约 60,000 倍。下图比较了所有五个被测系统中每日汇总的存储大小。

来源：测量与方法论

月度存储估算使用基准测试区域的公开列表价格，适用时采用 Enterprise 计划。

存储价格：ClickHouse · Snowflake · BigQuery · Databricks (S3) · Redshift。

原始数据和每日汇总合计的估计月度存储费用为：ClickHouse Cloud 12.43 美元，Snowflake 14.61 美元，Databricks 15.16 美元，BigQuery 20.06 美元，Redshift Serverless 90.44 美元。这些月度费用也有助于解释为什么 CostBench 将数据库存储排除在其端到端评分之外。在基准测试的短持续时间内，与摄取和准备新数据以及服务查询的综合成本相比，存储增加的成本很少。在更长的保留期内，存储成本会变得更加显著。

压缩减少了读取原始历史所需的字节数；预聚合减少了回答重复分析问题所需的行数。

摄取 CPU 工作分解：

解析占摄取 CPU 工作的最大份额；排序约占 19%，预聚合约占 3%。下图将解析、排序、预聚合、压缩和其他摄取工作分开显示。客户端通过异步插入发送 CSV 编码的批次；解析将它们转换为 ClickHouse 的类型化列式数据。“其他摄取工作”包括构建稀疏主索引和 part 元数据，以及配置时的列统计信息和二级索引。此图涵盖摄取工作；后台合并单独显示在下方。

减少服务器端解析：

ClickHouse 支持 70 多种输入格式，包括 Native，其由客户端准备的列式块可减少服务端解析和转换。我们的 FastFormats 研究和交互式仪表板探讨了格式、批处理和压缩的影响。

后台合并与持续预聚合：

同样的四个核心每秒合并数百万行。这些合并整合了已排序的原始数据部分，并继续跨批次组合摘要的聚合状态，减少了查询剩余的工作量。随着数据集增长，每个分区的最大活动部分数保持在 100 左右。

CPU 使用率保持在四个可用核心中的约 3.1 个核心，跟踪内存保持在服务的 16 GiB 容量范围内。28.69 美元的准备工作成本包括两个节点及其后台工作。

来源：测量与方法

这在实践中带来了什么 #

在 CostBench 中，ClickHouse 以最低的准备工作成本使摘要与摄入的原始数据保持同步。有序、压缩的历史和紧凑的摘要为后续查询留下更少的工作量，因此应用程序可以从当前数据回答重复性问题，同时仍可调查单个事件。

实践中的快速准备：Appcues 用物化视图替换了其基于 Snowflake 的分析栈中的 Airflow 汇总，在插入时计算计数和求和。它消除了 Airflow 基础设施，并将事件到达 Appcues 到可查询的时间从十多分钟缩短到大约五秒。

下一节将跟随这些准备好的数据进入查询引擎。

以最低成本获得最快的查询结果 #

高效的准备减少了每个查询背后的工作量。为了衡量收益，CostBench 在负载下测试了整个路径，在摄入和准备新报价的同时，每十分钟在每个系统上运行相同的四个交互式聚合查询，每小时运行相同的两个选择性下钻查询。第 1 部分详细解释了查询工作负载。

ClickHouse 在查询处理方面的领先优势 #

在全部四项对比中，ClickHouse Cloud 累计的查询运行时间最短，查询成本最低。

来源：测量与方法论

所有系统均禁用了查询结果缓存，因此每个被测量的查询都实际执行了。底层数据缓存保持预热状态，以反映持续运行的情况。

对于聚合查询，Snowflake 和 BigQuery 在查询时需要额外工作，因为它们的预聚合落后于原始数据。它们将汇总结果与更新的原始行合并，以返回当前答案。Databricks 和 Redshift 读取最近完成的汇总结果，因此其答案可能遗漏较新的报价。ClickHouse 的预聚合始终是最新的，使其聚合查询可以直接读取准备好的汇总结果。

来源：测量与方法论

在约 1000 亿原始行的规模下，图示的聚合查询在 ClickHouse 中约 15 毫秒即可返回当前答案，而 Snowflake 需要 16 秒，BigQuery 需要 4.6 秒。

这一领先优势背后的引擎内幕 #

预处理减少了每个查询需要处理的数据量。预聚合让聚合查询可以读取紧凑的汇总结果，而排序则帮助带有合适过滤条件的查询跳过无关的数据范围。与数据预处理一样，ClickHouse 通过并行化剩余工作来加速查询。

跨节点方面，单个查询可以使用多个节点上的 CPU 核心。参与的节点可以并发处理不同的行子集，并将各自的部分结果合并为一个答案。

在每个节点内部，ClickHouse 将待处理的行分配给可用的 CPU 核心，使每个核心可以并发处理自己的部分。

ClickHouse 为其 200 多个聚合函数及其组合器使用可合并的部分聚合状态：每个 CPU 核心可以聚合自己的行子集，这些状态随后被合并为正确的答案。原始数据下钻在查询时构建这些状态；对汇总结果的查询则合并摄取和后台合并期间已准备好的状态。我们的 GROUP BY 演练通过具体示例解释了其机制。

在每个核心内部，ClickHouse 通过向量化执行以批处理方式处理列式数据，从而提高 CPU 缓存局部性。SIMD 指令可对多个值同时执行支持的操作。

下面的动画展示了相同数据如何先跨节点划分，再跨单个节点的 CPU 核心划分，最后跨单个核心内的 SIMD 通道划分。

每个核心上的聚合工作也受益于底层选择。ClickHouse 根据分组键和数据从 30 多种专用哈希表变体中进行选择。Alexey 的 Building for Fast 讨论展示了此类选择背后的实验，包括预测哈希表容量。

多年来，ClickHouse 引入了一系列分层优化来大幅减少 I/O。这些技术构成了其速度和效率的基础。

在准备阶段建立的原始数据和汇总数据的排序，使 ClickHouse 的稀疏主索引能够跳过不相关的范围。Projections 通过替代数据排序及其自身的索引扩展了这种方法。

跳过在执行期间继续进行。PREWHERE 在加载额外列之前应用过滤条件。针对 Top-N 等常见查询模式的优化进一步减少了 ORDER BY … LIMIT 所需的工作，跳过无法改善结果的数据。惰性物化可以将输出列的读取推迟到结果行已知之后。

ClickHouse 还在多个层级使用缓存，以避免重复获取元数据和数据、解压缩和解码列，或评估相同的过滤条件。

这些只是 ClickHouse 查询优化的一部分。统计信息指导查询规划，查询重写会在执行前消除冗余计算。其他技术包括对频繁使用的表达式进行即时编译，以及利用现有数据顺序来满足 ORDER BY 而无需额外排序，或简化聚合。我们的 VLDB 研究论文更详细地描述了这些技术和更广泛的引擎架构。

引擎性能数据 #

我们还在查询执行期间监控了读取服务（通过内置的 ClickHouse Cloud 高级仪表板），跟踪处理吞吐量以及 CPU 和内存使用情况。

如前所述，在所有四项比较中，ClickHouse Cloud 累计的查询运行时间最短，查询成本最低。查询计算在可能的情况下保持一致；在存在差异的地方，评分显示了任何额外的查询速度是否证明了额外计算成本的合理性。

ClickHouse 使用一个独立的单节点读取服务实现了这些结果，该服务具有 16 个 CPU 核心和 64 GiB 内存，同时新的报价继续被摄取和准备。在 1132 亿条报价下，四个交互式聚合查询平均返回响应时间约为 15 毫秒，而两个原始数据下钻查询平均约为 1 秒。

两个全历史聚合 A3 和 A4 从准备好的汇总中回答，有效聚合吞吐量约为每秒 6 万亿条报价。该速率衡量的是其汇总所代表的原始报价历史在每秒查询执行中的量。

来源：测量与方法论

下一张图表展示了这些查询执行背后的并行化数据处理吞吐量。在 1132 亿条报价的端点处，ClickHouse 对下钻查询处理了约 3.25 GB/s 的未压缩数据，对交互式聚合处理了 2.05 GB/s。

来源：测量与方法论

按使用的 CPU 核心计算，相应的处理速率约为下钻查询 374 MB/s、交互式聚合 307 MB/s。在所示端点处，查询执行期间 CPU 使用率平均约为 53%，留有 47% 的余量。每次查询的平均峰值内存约为下钻查询 19.8 MiB、交互式聚合 13.2 MiB。

为了测试这种并行执行模型如何随 CPU 核心数扩展，我们在每个查询可用 2、4、8、16、30 和 59 个 CPU 核心的情况下重新运行了两个原始数据下钻查询。全部 1132 亿条报价均已加载并准备就绪。这是与上述持续摄入测量分开的独立实验。

在 59 个核心下，热缓存吞吐量达到约 15.56 GB/s，冷缓存为 9.85 GB/s。热缓存允许普通数据缓存和查询条件缓存；冷缓存绕过数据缓存并禁用查询条件缓存。两种情况下查询结果缓存均保持禁用。加速并非完全线性：合并部分结果会增加工作量，即使该合并工作被并行化，且某些查询阶段无法完全并行化。

来源：测量与方法论

NVIDIA Vera 上的并行执行：相同的并行执行模型也会自动利用更大的机器。在具有 176 个 CPU 核心的双路 NVIDIA Vera 系统上，ClickHouse 引擎交付了我们测量过的最快 ClickBench 结果。我们的 Vera 性能演示显示，一个 CPU 密集型聚合在 176 个核心下比单核快约 164 倍。这接近完美线性扩展的 176 倍加速：合并部分结果会增加开销，且某些查询阶段无法完全并行化。另一项过滤测试处理了约 900 GB/s，进一步的扩展受内存带宽限制。该演示还展示了 SIMD 如何加速每个核心内受支持的操作。

这在实践中带来什么 #

CostBench 显示，在单个 16 核查询节点上，聚合答案达到毫秒级，下钻查询约为一秒，且在新鲜数据持续到达时仍有 CPU 余量。ClickHouse 在四项比较中还具有最低的查询成本和累计运行时间，使得频繁的分析查询在不断增长的历史数据上变得可行。

实践中快速的查询速度与低成本：Mintlify 使用 ClickHouse Cloud 中的增量物化视图为客户提供文档分析。在替换其基于 PostHog 的设置后，仪表板加载时间从数十秒降至一秒以内，而工程经理 Nicholas Khami 估计相同工作负载的成本降低约 60%。这转化为积极的客户体验，其净推荐值提高了 30%，表明满意度很高。

这些优势在规模扩大时会叠加 #

ClickHouse 引擎能够高效地准备新数据批次，从而减少每个查询的工作量，并高效地执行剩余工作。

高效的准备和快速的查询执行都能提升每美元的端到端性能，因此它们的收益会叠加。

准备与查询执行相互促进 #

之前的查询侧对比从已准备好的数据开始，测得 ClickHouse 的每美元性能优势为 23×–101×。CostBench 测试了更广泛的持续摄入路径，在准备和查询服务同时运行的情况下测得 412×–1,996× 的优势。

来源：测量与方法

独立扩展摄入和查询计算 #

ClickHouse Cloud 为该高效引擎增加了弹性和工作负载隔离。SharedMergeTree 将表存储与计算分离，Shared Catalog 集中管理数据库元数据，分布式缓存使热数据在计算变更之间可复用。这一基础让无状态计算节点能够访问相同的表，而无需在容量变化时重新分布存储的数据。

计算-计算分离让摄入、仪表盘和调查运行在独立规模的 services 上，每个服务都有自己的 CPU Cores 和内存。CostBench 将其摄入和查询服务使用了这种分离。

在 CostBench 设置之外，On-Demand Compute 允许符合条件的查询通过现有服务请求临时无状态 workers。这些 workers 提供额外的查询容量，而无需永久增加服务的规模。

共享数据架构还支持多种分布查询工作的方式：

• 并行副本将读取和聚合分布到各节点。

• 索引分片将索引分析分布到各节点。

• 多阶段执行动态地将大型连接和高基数聚合分布到各节点。

摄入节点、读取节点和临时无状态查询 workers 都运行相同的 ClickHouse 引擎。

数据准备（包括插入时转换）、并行化查询处理以及上述分布式执行机制均已内置其中。

ClickHouse Cloud 可以按工作负载独立扩展计算资源，同时保留通用的 SQL 函数、数据类型和执行机制。对开发者而言，这提供了一组一致的构建模块，用于理解和调试完整的分析路径。对共享引擎代码的改进可以使使用它的每个角色受益。

下图展示了在共享数据和缓存之上，摄取和查询计算资源独立地增长和收缩。查询侧的虚线工作节点框代表按需计算（On-Demand Compute）的临时无状态工作节点。

下图展示了一个在完整加载的英国房产价格数据集上进行的独立实验。一个查询按县、镇和区对 1 万亿原始行进行分组，计算计数、求和和平均值。它使用 1 到 100 个节点，每个节点 89 个 CPU 核心，无需预聚合或重新分布已存储的数据。

数据处理吞吐量从单节点的 6.49 GB/s 提升到 100 个节点的 519.18 GB/s。图中每个点都是该配置下十次运行中最快的一次。

同一篇文章还演示了一个更简单的聚合：在 1000 亿原始行上按镇对价格求和。它在 0.414 秒内完成，每秒处理 2418 亿行，即 1.45 TB/s。下面的录屏展示了该查询的实际运行。

这些原始数据实验展示了在已加载数据上的分布式执行。CostBench 衡量的是不同的工作负载：持续准备最新报价并服务查询，在其性价比评分中包含了这两个阶段。

来源：测量与方法论

实践中的弹性扩展：HighLevel 将这种弹性应用于一个服务超过 90,000 家代理机构和 300 万家小型企业的营销平台。它使用 ClickHouse Cloud 进行线索活动、工作流日志、通知和收入分析。存储与计算分离使团队能够随着需求增长而增加查询容量。正如 Staff Engineer Pragnesh Bhavsar 所解释的：“如果我们的流量在增长，我们只需添加副本就可以了。”

这对实时应用意味着什么 #

高效的数据准备和并行化查询执行使应用能够在毫秒内基于最新摄取的数据获得答案，并利用这些答案来决定下一步做什么。这些答案必须在应用的响应预算内到达，并且在历史数据增长、请求反复发起时保持经济性。

CostBench 的股票市场报价数据集提供了一个具体示例。设想一个交易应用在批准交易前检查风险。最近的市场变动可能会改变决策，因此分析查询需要最新摄取的报价。假设该查询有 100 毫秒的预算：即使报价历史不断增长，截止时间也保持不变。

下面的动画将 CostBench 测得的摘要新鲜度与聚合查询延迟放在一起，在新报价不断到达的情况下，将响应时间与这一示意性截止时间进行比较。对于所示的聚合查询，只有 ClickHouse 在 1000 亿条报价下，将当前数据与答案结合，并在 100 ms 预算内返回结果。

来源：测量与方法

在 1000 亿行数据下，ClickHouse Cloud 大约在 15 ms 内返回查询结果，每日摘要与已摄入的原始数据保持同步。新鲜度和低延迟共同提供了应用在做出下一个决策之前所需的分析依据。

当这些决策在用户和工作流中反复触发查询时，经济性就变得重要。当前摘要使重复性问题能够以低成本得到回答，而有序的原始历史数据则支持详细调查。较低的准备成本和查询成本有助于在应用增长时保持两者的实用性。

实践中的实时决策：在 Buildkite，分析查询有助于确定下一次 CI 构建如何运行。该平台每年摄入一万亿次测试执行的结果，并使用 ClickHouse Cloud 进行智能测试拆分、不稳定测试检测以及测试历史的交互式分析。物化视图为重复性问题维护统计信息，而原始数据仍可用于详细调查。这些查询位于关键路径上：快速获得答案有助于数千台机器更早完成测试，并加速下一次构建。

为面向智能体的分析时代而构建 #

智能体越来越多地代表人们向数据库提问，每个答案都有助于决定它们接下来调查什么。

数据库研究员、ClickHouse Labs 副总裁 Andy Pavlo 预计，“数据库面临的查询量和查询数量可能会增加 10 到 100 倍。”

这种增长给整个分析路径带来了压力。传入事件必须持续变为可查询状态，同时智能体并发地提出后续问题并开展调查。

设想一个智能体帮助安全团队调查正在发生的事件。它可能会将近期活动与历史模式进行比较，识别受影响账户，并检查单个事件。情况可能在调查过程中发生变化，因此每个后续查询都需要访问新摄入的证据。

ClickHouse 的持续准备使摘要与已摄入的原始数据保持同步，而有序的原始历史数据则支持详细调查。随着新证据到达，智能体可以在摘要和单个事件之间切换。

每个答案都可能决定下一个问题，使数据库延迟直接进入调查循环。在典型的 ClickHouse 工作负载中，每个查询所需的时间都少于模型典型的首 token 时间。这意味着智能体实际上不必等待数据库。

数据库成本还包括得出结论所需的每一次查询。这些成本会在后续问题和并发调查中不断累积，因此随着智能体使用量的增长，高效的查询执行变得越来越有价值。

在每天摄入量达到 PB 级或更高的情况下，智能体仍然需要最新的证据以及快速、经济的后续查询。ClickHouse 的持续准备减少了每个答案背后的工作量，而 ClickHouse Cloud 让摄入和查询容量能够随着事件量和调查需求的增长独立扩展。ClickHouse 在这方面做得恰到好处。

实践中的智能体调查：Artemis 使用 ClickHouse Cloud 持续检查传入的安全日志，同时调查智能体针对历史数据探索可疑活动。通过物化视图提取频繁查询的字段，将一次调查查询从 12 秒缩短到 200 毫秒。另外，将检测规则合并为共享扫描，使生产环境中超过 100 条规则的批次能在不到一秒内执行完毕。高效地准备数据并减少重复查询工作，既支持及时调查，也支持持续检测。

实时分析，大规模下成本高效 #

让传入数据保持可查询、高效作答并随需求扩展，是整个分析路径上相互关联的要求。在 CostBench 中，高效的准备和查询执行共同为 ClickHouse Cloud 带来了无与伦比的端到端每美元性能：在四项比较中提升了 412 倍至 1,996 倍。对于实时应用和智能体而言，随着请求数量成倍增长，这种效率变得越来越有价值。

“市面上没有任何产品能与 ClickHouse 竞争”——Alon Tal，Tesla 高级主任软件工程师

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：ClickHouse Blog

原创地址：https://clickhouse.com/blog/why-clickhouse-cloud-wins-at-real-time-analytics