本文字数19026估计阅读时间48 分钟作者Tom Schreiber, Mark Needham and Lionel PalacinTL;DR实时分析的基准测试需要端到端地衡量系统包括新数据摄入、查询就绪数据的维护、快速响应查询以及维持整个路径运行的成本。这正是 CostBench 所衡量的。它综合评估了持续摄入、数据维护和查询执行的成本与延迟因为不同的系统在工作分配上有所侧重。对静态数据集进行的只读基准测试可以展示数据准备就绪后查询的返回速度。但它无法揭示将数据转化为查询就绪状态的成本也无法评估在新数据持续到达并并行维护的同时查询能否保持快速响应。在本文中我们将使用 CostBench 来比较 Snowflake 和 ClickHouse Cloud 在完整的实时分析路径上的表现。想观看视频演示本次网络研讨会将以视频形式呈现相同的基准测试内容并深入探讨结果背后的机制包括端到端路径的成本性能、持续变化的数据以及 ClickHouse 为何能够在数据摄入时即达到查询就绪状态以及物化视图如何与基表保持同步。查看媒体链接https://www.youtube.com/watch?v_b-FD39YF5At3s实时分析并非从查询运行开始实时分析始于新数据的到达。在仪表板、用户或 AI 代理获得快速响应之前系统已经完成了大量工作包括摄入新行、对数据进行组织以方便剪枝、维护派生表、确保数据新鲜度并保持读取容量以支持低延迟查询。CostBench 旨在衡量的就是这条完整路径它衡量的不仅是最终的读取查询而是将新数据转化为快速响应的整个运行系统。这也是我们 之前关于查询就绪数据的基准测试 的核心思想。我们衡量了这条路径的一个重要方面即持续摄入数据并对原始数据进行物理组织以支持快速分析读取的成本效益。Snowflake 对该基准测试做出了回应提出了一系列建议包括使用不同的摄取方法、使用更大的数据仓库进行加载操作以及在可用时使用 Snowflake 更新的实时功能。其中一些建议旨在改进 Snowflake 的设置。另一些则关注不同的问题例如当目标是最大吞吐量而非持续查询就绪性时Snowflake 批量加载数据的速度如何。但所有这些都殊途同归指向我们最初秉持的同一原则实时分析系统应作为一条完整路径进行基准测试而非孤立地进行数据摄取、维护或读取测试。这正是本文所做的工作。我们使用 CostBench 将该比较作为端到端基准测试重新运行涵盖了持续数据摄取 (continuous ingest)、原始数据组织 (raw-data organization)、预聚合数据新鲜度 (pre-aggregation freshness) 以及持续查询服务 (continuous query serving)。我们测试了两种 Snowflake 路径广泛可用的标准表设置 (standard-table setup) 和更新的 Interactive Tables (交互式表) 设置。所有基准测试代码和结果均可在 CostBench repository 获取。股票报价数据集需要 单独的数据许可因此数据本身无法再分发。CostBench 衡量完整的分析路径加载静态数据集、多次运行每个查询并报告最快的热缓存 (hot-cache) 结果并不能反映实时分析系统 (real-time analytics system) 的真实性能或成本。大多数数据库基准测试仅加载一次静态数据集让系统对其进行充分准备然后多次运行每个查询并报告最快的热缓存结果。这种方式衡量的是对稳定且已准备好数据的重复读取性能。但它无法体现使新鲜数据达到查询就绪 (query-ready) 状态所需的时间和成本也无法展现当查询持续运行在不断变化的数据之上时它们的表现如何尤其是在数据摄取、维护和刷新工作同时进行且缓存视图从未稳定于单一静态状态的情况下。这正是我们创建 CostBench 的初衷。CostBench 从成本-性能角度衡量完整的分析路径具体包括① 新鲜数据持续到达。② 系统写入数据并使其达到 查询就绪 状态。③ 原始数据以有序布局进行存储以便后续查询能够跳过表的大部分内容而非全表扫描。④ 系统维护预聚合数据从而使延迟最低的查询在执行时读取的数据量更小。⑤ 最后系统必须针对持续变化的数据不间断地提供快速响应同时后台的数据摄取、维护和刷新工作也必须持续进行。CostBench 并非批量加载或回填基准测试CostBench 模拟了一个实时分析系统 (real-time analytics system)其中新数据在源端持续生成并且必须在到达时立即可供查询 (query-ready)。它并非旨在衡量系统加载已有数据速度的批量加载 (bulk-load) 或回填 (backfill) 基准测试 (benchmark)。在本文中我们将这一方法应用于 Snowflake 和 ClickHouse。我们的首次基准测试衡量了什么立即可查询的原始数据我们的 首次基准测试 衡量了完整 实时分析 路径中的一个重要环节持续地将新写入的原始数据转化为立即可查询原始数据的成本。下文将展示原始设置并附带 Snowflake 提出的主要评论这些评论有助于阐明一些问题。① 数据集和排序键 (ordering key)我们使用了 ClickBench 网络分析数据集该数据集包含 100 多个列并使用了 ClickBench 工作负载所用的原始多列排序键 (sorting key)。这一选择是深思熟虑的。许多 ClickBench 查询得益于 ClickHouse 中的这种排序方式因此为了确保后续查询性能测量的公平性我们在 Snowflake 中使用了等效的聚簇键 (clustering key)。Snowflake 的评论使用一个更简单的聚簇键并避免通过重复原始 ClickBench 数据集来达到千亿行数据量所带来的人为数据到达模式。我们认为此评论是合理的并将在下文的扩展基准测试中处理这两点。但实际上它们回答了不同的问题数据如何到达以及系统需要为工作负载 (workload) 维护何种物理布局。② 固定速率持续数据摄入我们以每秒大约 100 万行或每秒约 1 GB 未压缩数据的速度持续摄入数据。这并非一场旨在测试最大吞吐量的加载测试。我们有意将数据摄入速率固定以模拟新数据持续不断抵达的实时工作负载。目标是使用最小、成本最低的 Snowflake 配置使其在保持该速率的同时确保数据表始终处于可查询状态。Snowflake 的评论建议使用 COPY INTO、Snowpipe Streaming、更大的数据仓库以及 Gen2 数据仓库。这些对于其他数据摄入测试来说是合理的选择。然而在本次基准测试中加载机制并非重点。我们关注的并非 Snowflake 能多快完成 1000 亿行数据的加载而是如何在常见的实时分析场景下以固定的实时摄入速率持续处理数据所需的成本。③ 查询就绪的原始数据而非预聚合首次基准测试主要关注基础表即新写入的原始数据进入并以查询就绪的原始数据形式输出。此次测试并未涵盖物化视图 (materialized views) 的性能。Snowflake 的评论更全面的生产环境设置应该涵盖数据管道的更多环节。同意。这正是 CostBench 下一步将要增加的测试内容在数据摄入和原始数据组织的同时涵盖派生数据 (derived-data) 的维护、新鲜度以及读取。④ 加载完成后测量读取在数据表达到 1000 亿行后我们运行了一次 ClickBench 查询工作负载以验证其查询性能。因此首次基准测试并未衡量在数据摄入、集群、刷新或其他维护工作于后台持续进行时系统所提供的持续服务能力。Snowflake 的评论建议使用 Interactive Tables 和 Interactive Warehouses 来实现高并发、低延迟的服务。这一点很合理。在首次基准测试中我们没有采用 Interactive Tables因为该测试使用的是大多数客户实际能够使用的 Snowflake 方案即带有集群的标准表。Interactive Tables 是一项较新的功能目前仅在部分区域可用。因此在扩展基准测试中我们将对两种方案进行测试一是采用标准表和物化视图的广泛可用的 Snowflake 配置二是在受支持区域内进行的 Interactive Tables 配置。扩展基准测试旨在解决更广泛的问题在 Snowflake 发布其回应之前我们便已开始将新的 CostBench 方法应用于 一项更全面的全链路基准测试。这次我们特意从一个相对简单的场景入手采用更简单的数据集和排序键更清晰的数据写入模式以及在数据持续更新的同时进行连续读取。这一设置规避了Snowflake在原始ClickBench测试中曾提出异议的多个因素。稍后我们将使用更大的数据集重复此测试。但首先我们希望在最理想的场景下评估整个数据链路的性能。① 更简单的数据集时间戳有序写入我们使用一个从数据提供商处获得授权的真实股票市场报价数据集其中包含数百亿行数据。与ClickBench相比该数据集的结构要简单得多它包含12列一个由两列构成的简单排序键并天然按照时间戳顺序排列。我们以每秒100万行的稳定速率严格按照时间戳顺序写入数据。按照这个速率系统每28小时将接收到1000亿行新增数据。② 简单聚簇键这次排序/聚簇键仅由两列组成(sym, t)即股票代码和时间戳。这已是极致的自然和简洁。ClickHouse 通过这些列对原始表进行排序而 Snowflake 则通过这些列对原始表进行聚簇。③ 包含预聚合与原始基准测试不同本次测试包含了持续维护的预聚合。这意味着我们不仅衡量了持续有新数据写入的情况下保持衍生数据实时更新所需的开销。④ 针对对应数据布局的持续查询本次测试中查询操作在持续有新数据写入的同时不间断地进行。该工作负载包含两种查询类型一种是针对预聚合数据的仪表盘查询另一种是针对原始数据且过滤器与原始表排序/聚簇键相匹配的下钻查询。我们保持系统缓存开启。在涉及静态数据的基准测试中我们通常会禁用查询结果缓存以避免将内存查找的开销计入而是专注于衡量纯粹的引擎性能。然而在本场景中数据持续变化因此缓存的效用大大降低保持缓存开启能更好地反映实际使用场景。我们每轮执行一次查询。这模拟了这些查询在实际中的使用方式无论是仪表盘刷新、用户下钻还是探索性的即席查询都只针对数据的最新状态执行一次。这更直接地模拟了实时场景数据摄入、系统维护、数据新鲜度保障和数据读取所有操作都同时进行。ClickHouse Cloud 设置对于 ClickHouse Cloud我们为数据摄入和读取分别使用了独立的服务从而使写入路径和查询路径彼此隔离。① 客户端设置该客户端基准测试驱动程序被特意设计得非常简洁它在 ClickHouse 和 Snowflake 上执行相同的工作。它直接从现有的 Parquet 文件中以二进制形式读取 Parquet 行组将这些行组组合成大小约为 100 万行的批次并将这些批次发送到目标系统。客户端不进行任何解码、解压缩、编码和压缩操作。这一点很重要因为 Snowflake 在第一次基准测试的回应中指出客户端成本是一个被忽略的因素。在此配置下两个系统的客户端工作是相同的并且只占用极少的 CPU 和内存资源因此客户端成本不再是一个有意义的差异化因素。② 摄入服务数据摄入服务运行在专用的 ClickHouse Cloud 服务上该服务由 2 个节点组成每个节点配备 2 个 CPU 和 8 GiB 内存。这足以持续摄入每秒 100 万行的数据流对传入数据进行排序并更新预聚合数据同时通过持续后台合并将所有表中活跃数据分区的总数始终保持在 60 左右。这种效率在实际应用中同样重要它使我们能够经济高效地运行像 StockHouse 这样的演示其所用的市场数据与本次基准测试中使用的相同且这些数据能够实时流入并随之变得可供查询 (query-ready)。③ 排序的原始数据和物化视图ClickHouse 使用 MergeTree 表将原始数据以 排序形式 直接写入磁盘。该表用于处理原始数据的钻取 (drill-down) 工作负载。与此同时当新行到达时一个增量物化视图 (materialized view) 会在 AggregatingMergeTree 表中维护预聚合 (pre-aggregated) 数据。该表用于处理仪表盘 (dashboard) 工作负载。代码原始 MergeTree 表、AggregatingMergeTree 表 和 增量物化视图。在整个基准测试期间原始 MergeTree 表始终保持排序以实现快速钻取AggregatingMergeTree 表存储用于仪表盘查询的预聚合数据与基础表 (base table) 保持同步没有数据滞后 (freshness gap)。这两个表始终保持最新并 可供查询。④ 读取服务读取查询运行在具有 1 个节点和 16 个 CPU 的 独立 ClickHouse Cloud 服务上。我们为 Snowflake 配置了相同数量的读取计算资源以确保不同系统之间的读取侧容量保持一致。注意根据普遍 共识AWS 上的 Snowflake Gen2 Small 仓库 (warehouse) 使用 16 个 AWS Graviton3 核心 (cores)。ClickHouse Cloud 在 AWS 部署中同样采用 AWS Graviton3 核心因此本次比较使两个读取路径都在相同 CPU 代的 16 个核心上保持对齐。⑤ 持续查询工作负载为模拟持续的读取工作负载我们在整个基准测试期间定期运行两种类型的查询。每隔 10 分钟我们对预聚合表执行 4 个仪表盘查询。每小时我们对原始表执行 2 个即席下钻查询。这些下钻查询使用与原始表排序顺序匹配的过滤器。我们在 Snowflake 上运行相同的查询调度并采用等效的物理布局原始数据按相同的键进行聚簇聚合数据也以相同方式进行预聚合。Snowflake 设置 1标准表和 materialized views (物化视图)首个 Snowflake 设置沿用了目前大多数 Snowflake 客户所使用的方案标准表、标准 materialized views 和 Gen2 warehouses。① 客户端设置客户端 设置即基准测试驱动程序与 ClickHouse 设置相同。它直接以二进制形式读取 Parquet row groups将其组合成大约 100 万行的批次并将这些批次发送到 Snowflake。这一次客户端使用COPY INTO命令将 Parquet 数据加载到原始表中。如前所述客户端不执行任何解码、解压缩、编码或压缩操作。因此其执行的客户端侧工作量与 ClickHouse 完全相同。② 摄取仓库对于数据摄取我们再次选择了能够维持每秒 100 万行固定摄取速率的最小 Snowflake warehouse。但这一次根据 Snowflake 的建议我们采用了 Gen2 硬件具体而言是一个配备 8 核 CPU 的 Gen2 X-Small warehouse。目标仍不是追求最大加载吞吐量。目标是寻求一种最低成本的设置使其能够在固定摄取速率下稳定运行以模拟新数据持续抵达的实时工作负载。③ Serverless clustering (无服务器聚簇)原始数据被写入一个标准的 Snowflake table 中。该表用于处理每小时的原始数据下钻工作负载。数据排序工作由 Snowflake 的 无服务器集群服务 在后台处理与原始基准测试保持一致。这样做的目的是确保原始表能够针对向下钻取查询保持物理优化。Code: raw Snowflake table.④ 物化视图刷新为了在端到端基准测试中包含预聚合我们使用了基于原始表的 Snowflake 物化视图 (materialized view)。仪表板工作负载会查询这个视图。物化视图是 Snowflake 的企业版专属功能。刷新工作由 Snowflake 的 无服务器物化视图刷新服务 在后台处理。Code: Snowflake materialized view.⑤ 读取仓库与 ClickHouse 的设置类似我们使用独立的仓库分别处理数据摄取 (ingest) 和数据读取 (reads)从而将写入路径和查询路径彼此隔离。对于读取操作我们使用一个配备 16 个 CPU 的 Gen2 Small 仓库。这与 ClickHouse 中用于读取的 CPU 数量相匹配。⑥ 持续查询工作负载我们运行与 ClickHouse 中相同的持续查询计划。每隔 10 分钟我们都会针对 预聚合数据执行 4 个查询以模拟仪表板刷新操作。每小时我们都会针对原始表执行 2 个原始数据向下钻取查询。Snowflake 设置 2交互式表第二种 Snowflake 设置对原始数据和预聚合数据都使用了 交互式表 (Interactive Tables)。交互式表目前 仅在选定区域可用。为了进行测试我们必须在一个受支持的区域创建 Snowflake 账户。因此我们提供了两种 Snowflake 配置方案一种是广泛可用的、采用标准表和物化视图的设置另一种是在可用区域中采用更新的交互式表的设置。① 客户端设置该客户端与 ClickHouse 设置和第一个 Snowflake 设置中的客户端相同。它直接以二进制形式读取 Parquet 行组将它们组合成大约 100 万行的批次并使用COPY INTO将数据加载到 Snowflake。客户端不执行任何解码、解压缩、编码或压缩操作。② 摄取仓库与之前相同数据摄取使用能够维持每秒 100 万行固定摄取速率的最小 Snowflake 仓库。我们使用一个配备 8 个 CPU 的 Gen2 X-Small 仓库。③ 原始数据刷新传入数据首先进入一个标准的 Snowflake 表。原始的交互表Interactive Table随后由用户管理的仓库从该源表进行维护刷新按需触发以满足设定的目标延迟。这与标准的交互表模式相对应。我们为原始交互表设置了 10 分钟的目标延迟该表用于处理每小时的下钻工作负载。通过 Snowflake 管理的摄取路径可以直接将数据摄取到交互表中。我们单独讨论这种情况因为它不涵盖此处测量的预聚合路径。代码和文档标准 Snowflake 表、原始交互表、目标延迟刷新行为以及仅插入限制。④ 预聚合数据刷新预聚合数据也存储在交互表Interactive Table中。在此刷新仓库会定期传输自上次刷新以来的新行对其进行聚合并将结果合并到预聚合的交互表Interactive Table中。我们使用 1 分钟的目标延迟这是可用的最小目标延迟。 由于此表承载着仪表板工作负载我们配置了 Snowflake 允许的最新的预聚合路径。这样我们就能将其与 ClickHouse 增量物化视图它们在数据摄取路径上更新进行比较并衡量在 Snowflake 中尽可能接近该新鲜度模型所需的成本。Snowflake 还提供交互式物化视图 (Interactive Materialized Views)我们将 单独测试 该路径。由于 Small、Medium 和 Large 仓库都无法可靠地将预聚合刷新保持在 1 分钟的目标延迟内我们转而使用 Gen2 X-Large 仓库来执行刷新操作。代码和文档预聚合交互式表、聚合查询、目标延迟行为、交互式物化视图 和 刷新大小比较。⑤ 交互式读取仓库对于读取操作我们使用一个配备 16 个 CPU 的 Small Interactive Warehouse。这与 ClickHouse 和首次 Snowflake 设置中用于读取的 CPU 数量保持一致。与标准仓库不同Interactive Warehouse 还配备了一个 大型缓存。对于 Small Interactive Warehouse该缓存大约为 600 GB使交互式表的工作集能够驻留在内存中。值得注意的是Interactive Warehouses 具有 1 小时的最短计费时长并且自动暂停的最小设置为 24 小时。在此基准测试中此计费模型与工作负载相匹配我们正在衡量一个持续运行的实时分析服务其中包含持续的数据摄取、刷新和查询。⑥ 持续查询工作负载我们沿用与之前相同的持续查询计划。每隔10分钟我们会对预聚合数据运行4次查询以模拟仪表盘刷新。每小时我们对原始 Interactive 表运行2次原始数据钻取查询。结果ClickHouse 对比 Snowflake 标准表首先我们将 ClickHouse 与大多数客户目前可用的 Snowflake 配置进行比较标准表 (standard tables)、标准物化视图 (materialized views)、无服务器集群 (serverless clustering)、无服务器 MV 刷新 (serverless MV refresh) 和 Gen2 仓库 (Gen2 warehouses)。性能持续数据摄入下的延迟与数据新鲜度在这些测量中两个系统都使用相同的读取端计算资源16个AWS Graviton3核心。查询计划也保持一致。仪表盘查询预聚合仅在保持最新时才发挥作用这张图表展示了我们每隔10分钟对预聚合数据执行的4次仪表盘查询。X轴表示摄入到原始表中的行数从运行开始到大约28小时后达到1000亿行。Y轴表示查询延迟。所有各次查询的运行详情都可在 CostBench 存储库中获取ClickHouseSnowflake。随着原始表的增长ClickHouse 的性能表现几乎完全平稳仪表盘查询延迟保持在个位数毫秒范围内。这是因为 ClickHouse 在数据摄入过程中同步更新预聚合表从而持续保持最新并处于查询就绪状态。Snowflake 的标准物化视图 (materialized-view) 配置表现截然不同。其查询延迟明显更高且波动剧烈较简单的仪表盘查询延迟维持在数秒左右而负载较高的仪表盘查询则跃升至高个位数甚至数十秒的范围。症结在于数据的新鲜度。即便 Snowflake 物化视图 (materialized view) 本身存在滞后它仍能返回最新摄入数据的结果。在这种情况下Snowflake 必须在查询时将物化视图与原始表中缺失的行进行合并。对于仪表盘工作负载而言这意味着刷新速度不仅会变慢还会变得不可预测。新鲜度滞后慢速仪表盘背后的隐性成本下图直接展示了底层的新鲜度滞后。我们通过每分钟使用SHOW MATERIALIZED VIEWS命令轮询 (polling) Snowflake 的物化视图元数据来测量此滞后。详细的新鲜度样本可在此处获取请参阅behind_by列。ClickHouse 能够保持数据最新是因为其物化视图在数据摄入路径上是同步更新的。Snowflake 的物化视图通过一个无服务器 (serverless) 后台服务进行刷新该服务没有新鲜度服务等级协议 (SLA)用户也无法控制其运行时间或所消耗的计算资源。在本次测试中Snowflake 物化视图持续处于滞后状态其滞后时间反复达到约 60 到 72 分钟。钻取查询聚类有所帮助但无法维持稳定延迟下图展示了我们每小时针对原始数据运行的两个钻取查询。其中x 轴表示从测试开始到约 28 小时后原始表中摄入的行数最高达 1000 亿行y 轴则表示查询延迟。所有每次查询的运行详情均可在 CostBench 仓库中获取ClickHouseSnowflake。这些查询使用了与原始表的排序/聚簇键相匹配的过滤器。换句话说两个系统都获得了相同的物理布局优势ClickHouse 依照该键进行排序而 Snowflake 则依据相同的键进行聚簇。即便如此其模式与我们首次读性能基准测试中的结果一致随着数据集的增长不同系统的表现开始出现差异。ClickHouse 的性能基本保持平稳数据规模对其影响不大。而 Snowflake 则变得越来越慢在测试结束时响应时间达到了数秒。成本数据摄入、维护与读取在成本方面我们采用了 AWS us-east 区域的企业版定价。该定价模式使 Snowflake 能够使用需要企业版才能提供的物化视图Materialized Views而 ClickHouse 的物化视图即使在开源版本中也可用。实时数据路径成本确保数据可查询下图展示了测试运行前 28 小时内实时数据路径的总成本该过程以每秒 100 万行总计 1000 亿条的持续速率摄入新数据同时保持原始数据已排序/聚簇并维护预聚合数据。对于 ClickHouse数据摄入服务使用了 2 个节点每个节点配备 2 颗 CPU 和 8 GiB 内存。根据ClickHouse Cloud 定价这相当于 2 个计算单元 (compute units)。在 28 小时的运行期间其成本为2 个计算单元 × 28 小时 × $0.3903/小时 $21.86。对于 Snowflake数据摄入仓库采用了 Gen2 X-Small warehouse。以每小时 1.35 个积分 (credits) 和每积分 3 美元的价格计算数据摄入仓库的成本为1.35 个积分/小时 × 28 小时 × $3/积分 $113.40。Snowflake 剩余的写入相关成本来自于无服务器服务 (serverless services)。我们从 Snowflake 系统表中提取消耗的积分并以相同的每积分 3 美元价格进行计算无服务器聚簇 (serverless clustering) 成本为 54.12 积分 × $3 $162.37无服务器物化视图刷新 (serverless materialized-view refresh) 成本为 3.60 积分 × $3 $10.8。综上所述Snowflake 的实时数据路径总成本为$286.58。在不计入查询成本的情况下Snowflake 的标准设置在保持新鲜数据可供查询方面的成本已高出约13 倍。查询成本执行相同的调度任务最后我们衡量读取侧的表现在 28 小时运行期间每个系统需要多少运行时长和查询成本来处理相同的连续查询调度。对于查询成本我们采用与最初的 读取侧基准测试 方法论中相同的 简化即 累积查询运行时长 × 读取侧计算价格如同查询计算以完美的每秒粒度计费一样。实际上Snowflake 和 ClickHouse Cloud 都会持续 计费直到达到可配置的空闲超时时间。但这种标准化方法直接比较了查询引擎的效率在给定量的付费计算时间内系统能够完成多少查询工作下方图表展示了结果。每个查询的运行详情均可在 CostBench 代码仓库中查阅ClickHouse 的 仪表板查询 和 钻取查询以及 Snowflake 的 仪表板查询 和 钻取查询。为了计算查询成本我们使用连续读取工作负载的累计运行时长再乘以读取侧计算的价格。ClickHouse 使用一个配备 16 个 CPU 和 64 GiB RAM 的读服务相当于 8 个计算单元 (compute units)8 个计算单元 × $0.3903/小时 × 70.4 秒 $0.061Snowflake 使用一个配备 16 个 CPU 的 Gen2 Small 读仓库 (read warehouse)。按照每小时 2.7 credits (积分) 且每 credit 3 美元计算即每小时 $8.102.7 credits/小时 × $3/credit × 5,017 秒 $11.288这使得 ClickHouse 在处理此工作负载的查询计算时成本降低了约 185 倍这还不包括新鲜数据路径的成本。成本-性能全路径得分如何在每美元投入中获得最优的全路径实时性能为了直接比较全路径实时成本效益我们将成本和性能整合成一个单一的衡量指标该指标值越低表示表现越好。该指标的计算公式为(新鲜数据路径成本 查询成本× 总查询运行时间这个指标体现了基本的成本-性能权衡系统若能保持路径低廉并快速响应查询则得分更优。昂贵的系统得分较差运行缓慢的系统得分亦差。当一个系统既昂贵又迟缓时这两个负面影响还会叠加放大。Snowflake 的标准配置得分高出 969 倍。这正是叠加效应Snowflake 需要支付更多成本来维持数据路径运行并且仍需要更长的运行时间来处理相同的持续查询调度。更何况这还未计入预算差异。若按照 Snowflake 的支出水平ClickHouse 甚至可以扩展至更大规模的服务进一步降低延迟而总成本依然低于 Snowflake。结果ClickHouse 与 Snowflake 交互式表对比在上一节中我们针对 Snowflake 广泛可用的标准表路径对 ClickHouse 进行了基准测试。接下来我们将针对 Snowflake 的 Interactive Tables 设置 重复运行相同的 CostBench 工作负载。工作负载、客户端行为、数据摄取速率、查询调度以及读取端 CPU 核心数均保持不变。唯一变化的是 Snowflake 的服务路径原始数据和预聚合数据现在存储在 Interactive Tables 中由用户管理的仓库进行刷新并通过一个带有大容量缓存的 Interactive Warehouse 提供服务。值得注意的是在这些测量中两个系统都使用了相同的读取侧计算资源16 个 AWS Graviton3 核心。性能Interactive Tables 提升了读取性能但未能消除差距这些图表沿用了上述相同的格式x 轴表示摄入的原始行数在大约 28 小时后累计达到 1000 亿行y 轴则表示查询延迟。仪表盘查询Interactive Tables 速度更快但平稳性仍有不足对于仪表盘查询Interactive Tables 结合交互式仓库 (interactive warehouse)显著改善了 Snowflake 的延迟优于标准的物化视图 (materialized-view)配置。然而尽管使用了相同的读取端 CPU 资源ClickHouse 的延迟仍然更低且波动更小。所有查询的运行详情均可在 CostBench 仓库中查阅ClickHouseSnowflake。交互式预聚合结果存在一个刷新周期的滞后即使 Snowflake 仪表盘查询能够快速返回它们也是从一个预聚合的 Interactive Table 中读取数据该表存在 1 分钟的目标延迟。ClickHouse 保持更快的速度和实时的数据因为其预聚合发生在数据摄取路径上。数据新鲜度调度刷新必须跟上下一张图表展示了在 Interactive Tables 方案中保持预聚合数据新鲜度所需的措施。我们通过每分钟对 Snowflake 的 INFORMATION_SCHEMA.INTERACTIVE_TABLE_REFRESH_HISTORY 表进行轮询 (polling)来测量此延迟相关结果请参见此处。ClickHouse 在整个运行过程中保持数据实时因为当新行插入时其物化视图 (materialized views)会同步更新。原始 Interactive Table 的表现符合预期在 10 分钟的刷新目标下它在所有测试的仓库规模中都保持在该目标范围内。这足以满足每小时钻取工作负载对原始表的数据新鲜度要求。更具挑战性的部分是预聚合的 Interactive Table。如前所述我们使用了 Snowflake 允许的最小刷新间隔即 1 分钟因为该表服务于股票报价仪表盘的工作负载并且是 Snowflake 能达到的最接近 ClickHouse物化视图 (materialized views)的效果。Gen2 Small 刷新仓库在大约 3 小时后开始出现延迟Gen2 Medium 在大约 8 小时后而 Gen2 Large 则在大约 15 小时后。图中的红色交叉标记了每种配置无法将预聚合的交互式表 (Interactive Table) 更新保持在配置的 1 分钟目标内的时间点。这并非因为 Snowflake 在每次刷新时都重新聚合整个原始表。正如我们通过系统表查询所确认的对预聚合的交互式表的刷新是增量的。即便如此刷新仓库仍需处理新行、对其进行聚合并将结果合并到目标表所有这些都必须在下一次刷新开始前完成。因此最终设置采用了 Gen2 X-Large 刷新仓库。它在最初的 24 小时内成功使两个交互式表的更新都保持在配置的目标范围内。预聚合的延迟仍在缓慢增加。虽然在第一天没有超出 1 分钟的目标但曲线并未趋于平稳。对于更长时间的运行Snowflake 将需要更多的刷新计算资源或者一个更宽松的新鲜度目标。钻取查询交互式仓库缓存有所帮助但扩展性挑战依然存在对于钻取查询相较于标准表设置交互式表显著提升了 Snowflake 的性能。每次查询的运行详情均可在 CostBench 仓库中获取ClickHouseSnowflake。然而随着数据量的增长这种性能提升未能保持平稳。尽管在最初的 1000 亿行数据范围内工作集仍能完全载入交互式仓库缓存中但 Snowflake 的延迟随着数据量的增加而上升。ClickHouse 则保持平稳得多即使没有交互式仓库缓存。对于其中一个钻取查询当数据量达到约 500 亿行时Snowflake 的速度已低于 ClickHouse而到测试结束时两个钻取查询的延迟都已达到或超过 ClickHouse 的水平。核心观点 即使在一个轻量级数据集上仅经过约一天的持续数据摄取速率为每秒 100 万行规模适中Snowflake 交互式表 (Interactive Tables) 在下钻查询工作负载方面的延迟已达到或超过 ClickHouse。扩展性说明关键在于即使工作集尚能完全放入交互式仓库 (Interactive Warehouse) 缓存中查询延迟便已开始增加。这引出了下一个关于扩展性的问题当工作集大到即使是最大可用交互式仓库缓存也无法容纳时又会发生什么Snowflake 的交互式仓库模型 (Interactive Warehouse model) 也存在一个固定的 5 秒查询超时限制。一旦查询时间超过此阈值Snowflake 便建议使用备用仓库 (fallback warehouse)。这引入了额外的成本考量备用仓库必须在需要时随时可用而且用户所感知的运行时将包含失败的首次尝试以及在备用计算资源 (fallback compute) 上的重试时间。成本摄取与刷新相较于标准的 Snowflake 配置交互式表降低了查询路径的成本但代价是刷新操作的成本随之增加。实时数据路径成本刷新成为主要开销对于 ClickHouse 而言实时数据路径保持不变相同的摄取服务负责数据摄取、排序、合并以及物化视图 (materialized-view) 更新。如前所述其成本为2 个计算单元 × 28 小时 × $0.3903/小时 $21.86。对于 Snowflake 而言摄取仓库 (ingest warehouse) 同样保持不变。Gen2 X-Small 型摄取仓库的成本为1.35 credit/小时 × 28 小时 × $3/credit $113.40。主要差异体现在刷新环节。为了将预聚合 Interactive Table 的数据新鲜度保持在 Snowflake 设定的最小 1 分钟刷新目标刷新仓库 (refresh warehouse) 必须几乎持续运行。最终的配置方案采用了 Gen2 X-Large 型刷新仓库。按照 21.6 credit/小时和 $3/credit 的费率计算其成本为21.6 credit/小时 × 28 小时 × $3/credit $1,814.40。综上所述Snowflake 交互式表 (Interactive Tables) 的实时数据路径成本为 $1,927.80。在不计查询成本的情况下为维持实时数据路径的查询就绪状态其成本大约是 ClickHouse 的 88 倍。查询成本交互式表读取成本逐渐接近对于查询成本我们沿用了标准设置部分中描述的每秒运行时标准化方法。下图展示了 Interactive Tables 读取工作负载的总累计运行时间与查询成本。所有查询运行的详细信息均可在 CostBench 仓库中获取ClickHouse 的仪表盘查询和钻取查询以及 Snowflake 的仪表盘查询和钻取查询。ClickHouse 仍使用与之前相同的读取服务配置16 颗 CPU 和 64 GiB 内存即 8 个计算单元。8 个计算单元 × $0.3903/小时 × 70.4 秒 $0.061Snowflake 采用一个小型 Interactive Warehouse (交互式仓库)。按每小时 1.2 credit、每 credit $3 计算即每小时 $3.60。1.2 credit/小时 × $3/credit × 144 秒 $0.144在查询计算方面即便使用相同的读取端 CPU 数量ClickHouse 仍然快约2 倍成本便宜约2.4 倍。成本与性能全路径得分现在我们可以直接比较整个路径即保持数据实时更新并可供查询的成本以及系统为持续工作负载提供服务所需的运行时间。与标准设置相比Interactive Tables 显著提升了 Snowflake 的性能得分。然而整体路径的运行成本仍然高昂得多。Snowflake 的 Interactive Tables 设置的表现差了 180 倍。这一差距意义重大ClickHouse 用户即使投入更多计算资源也能在延迟方面大幅超越 Interactive Tables并且其总成本仍将低于 Snowflake。为何数据新鲜度机制至关重要上述结果还揭示了在新数据持续写入时各个系统如何保持派生数据实时更新的更根本差异。①新数据持续写入。这是整个基准测试的起点基础表数据不断变化因此预聚合必须跟上实时数据流而不是静态数据集。②Snowflake 实体化视图 (Materialized View) 异步刷新。这正是标准 Snowflake 配置所展现的情况当数据持续写入时实体化视图反复比基础表滞后 60 到 72 分钟。尽管 Snowflake 仍能通过在查询时将实体化视图与原始表中缺失的数据行相结合来返回最新的查询结果但这正是导致仪表盘延迟变得缓慢且不可预测的原因。③Snowflake Interactive Tables 使用计划刷新 (scheduled refresh)。Interactive Tables 提升了新鲜度控制能力但它们仍通过计划刷新机制运作。对于预聚合最小目标延迟为1 分钟。这意味着刷新仓库成为连续写入路径的一部分它必须在数据写入期间以该频率运行并且需要根据负载配置资源确保每次刷新都能在下一次刷新开始前完成。如果无法做到延迟便会累积。随着表的增长维持 1 分钟的刷新目标将成为一个可扩展性和成本方面的挑战。④ClickHouse 增量实体化视图 (incremental materialized views) 在数据写入时更新。ClickHouse 采取了不同的策略当新数据插入时实体化视图会同步更新。因此预聚合表始终与基础表保持一致无需等待独立的刷新周期。⑤这将改变实时应用场景的可能性。对于仪表盘应用1 分钟的刷新目标或许可以接受。然而对于亚分钟级 (sub-minute) 的决策工作负载特别是在金融服务和欺诈检测等领域其有效新鲜度窗口是以数百毫秒来衡量的此时计划刷新机制就已经太迟了。在这些场景中数据的新鲜度直接决定了系统是否能够支持此类工作负载。存储占用非基准测试的决定性因素为求完整我们还测量了每个系统的存储占用。存储在运营中固然重要但它并非本次基准测试的决定性因素。ClickHouse Cloud 和 Snowflake 都将持久化数据存储在低成本的对象存储 (object storage) 上。在此工作负载中每月存储费用与持续数据摄入、维护查询就绪的数据布局、刷新派生数据以及响应查询的成本相比显得微不足道。下图展示了在持续摄入数据最初的31.4 小时后测得的存储占用空间。截至那时每个系统已以每秒100 万行的速度摄入了大约1130 亿行股票报价数据即每秒约75 MB。测量查询ClickHouseSnowflake。该图表采用了测试区域当前的官方存储价格ClickHouse Cloud 的价格为每 TB/月$25.30而 Snowflake 在 AWS US East 区域的价格为每 TB/月$23.00。ClickHouse 原始数据362 GiB × 2^30 / 10^12 × $25.30 $9.83/月Snowflake 标准原始数据701 GiB × 2^30 / 10^12 × $23.00 $17.31/月Snowflake 交互式原始数据2.9 TiB × 2^40 / 10^12 × $23.00 $74.12/月预聚合表 (pre-aggregated tables) 也采用了相同的计算方法。这也揭示了 Snowflake Interactive Tables 带来的一个值得注意的存储方面的影响。原始 Interactive Table 的大小约为 Snowflake 标准原始表的4.2 倍约为 ClickHouse 原始表的8.2 倍。这与 Snowflake 的文档内容一致交互式表可能比同等的标准表更大这归因于数据编码的差异以及额外的索引。如果以相同的摄取速率持续整月730 小时月底的存储容量将大致按如下方式变化Data pathAfter 31.4hCost at that sizeProjected after 730hCost at projected sizeClickHouse 原始数据362 GiB$9.83/月~8.2 TiB~$229/月Snowflake 标准原始数据701 GiB$17.31/月~15.9 TiB~$402/月Snowflake 交互式原始数据2.9 TiB$74.12/月~67.4 TiB~$1,724/月需要注意的是我们并不确定交互式表的存储大小是否线性增长这仅是我们的假设。尽管如此与 CostBench 中测量的计算和刷新成本相比绝对存储成本依然很低。整个链路的成本性能差距主要由运行系统决定包括摄取计算、集群或刷新工作以及在新数据不断到达时的查询执行。展望更多路径和更重工作负载CostBench 是一个用于在不同系统设计下测试完整实时分析链路的框架。托管摄取路径我们计划测试的下一个变体是 Snowflake 的托管摄取路径。在该路径下Snowpipe Streaming 可以直接写入原始数据交互式表但无法直接维护预聚合数据。对应的 ClickHouse 路径是 ClickPipes。这样我们就可以在无需借助本次基准测试中用于直接写入数据的轻量级客户端的情况下对双方的托管摄取能力进行比较。更高查询并发我们还将利用相同的框架加大读取端的压力独立扩展查询工作负载并在新数据不断抵达的同时测试更高的并发性。更繁重的实时数据集如开篇所述本次测试特意从较为简单的场景入手采用小规模、窄表数据集搭配简单的排序键以及一种对 Snowflake 有利的数据写入模式。接下来我们将在另一个极端场景重复测试使用一个更宽、更繁重的数据集这种数据形态在 ClickHouse 实时分析工作负载中极为常见。这将展示两种极端情况既有最有利于 Snowflake 发挥性能的理想场景也有 ClickHouse 擅长应对的复杂场景。当然我们也欢迎 Snowflake 提出其他需要测试的配置方案。该框架具有灵活性关键在于比较需涵盖完整路径。结论完整路径将改变结果Snowflake 的回应帮助我们厘清了问题。许多建议都是有效的优化措施例如简化集群、将读取操作迁移至交互式表 (Interactive Tables)或调优刷新路径。然而实时系统是端到端的完整路径系统。优化其中一个阶段可能会将成本转嫁到其他环节例如更快的读取可能需要更多的刷新计算资源更及时更新的预聚合可能需要一个持续运行的刷新数仓而更好的物理数据组织则可能增加维护工作量。因此我们对整个端到端过程进行了衡量。部分测试结果有所改善。交互式表 (Interactive Tables) 使得 Snowflake 的读取速度远超标准实体化视图 (materialized-view) 配置。但当我们衡量了完整路径——包括数据摄取、物理组织、预聚合新鲜度、刷新成本以及持续查询服务——这些权衡取舍变得更为清晰。在最初的查询就绪数据基准测试中ClickHouse 的写入侧成本效益比 Snowflake 高出28 倍。在此次扩展基准测试中ClickHouse 的成本效益比 Snowflake 的标准实体化视图配置高出969 倍比 Snowflake 的交互式表配置高出180 倍。核心要点在于实时分析并非仅仅追求查询速度它更关乎于确保新数据随时可供查询、保持衍生数据同步更新并持续提供低延迟查询服务同时避免刷新操作成为主要的成本负担。对于亚分钟级决策工作负载 (sub-minute decisioning workloads) 而言数据新鲜度模型的重要性愈发凸显。在所有测试路径中唯有 ClickHouse 的增量实体化视图 (incremental materialized views) 能够使预聚合数据与基表 (base table) 持续保持同步且几乎零延迟。ClickHouse 专为实现全路径、高成本效益的实时分析而设计。MergeTree 表 (MergeTree tables) 能够确保原始数据有序且随时可供查询。AggregatingMergeTree 表 (AggregatingMergeTree tables) 则能使预聚合数据持续保持新鲜实现无缝刷新。此外其查询引擎在数据量不断增长的同时依然能保持低延迟。我们最新的 迁移案例 展示了生产环境中同样的端到端效率。Appcues 将面向客户的实时分析从 Snowflake 迁移到 ClickHouse Cloud处理了高达1.31 PB 的数据和 4100 亿个事件。迁移后P95 查询延迟从 20 多秒降至 2 秒以内摄取延迟从 10 多分钟缩短至约 5 秒即使新增了工作负载分析成本也随之降低。这正是 CostBench 旨在评估的优化路径。我们将继续测试更多的系统、更丰富的摄取路径、更庞大的数据集以及更高的并发性。敬请期待。关于我们ClickHouse 是面向 AI 时代打造的高性能实时分析数据库能够以极致性能处理海量数据分析任务。凭借高并发、低延迟和云原生架构ClickHouse 广泛应用于可观测性、数据仓库、实时分析及 AI 数据基础设施等场景。我们致力于帮助企业在公有云平台上构建安全、弹性且高性价比的实时分析与 AI 数据平台加速释放数据价值推动智能化创新与数字化转型。目前Trip.com、DiDi、Meta、Sony、Netflix、Deutsche Bank、Sierra、Cloudflare 等全球领先企业均在使用 ClickHouse 支撑其关键业务和数据分析平台。