使用 ClickHouse、Grafana 和 WarpStream 实现可预测成本的大规模日志记录

在生产环境中运行任何复杂的技术堆栈而没有适当的可观测性，就如同在没有仪表的情况下驾驶飞机。虽然这可以奏效，飞行员也为此接受过培训，但风险/回报率远非有利，并且它应该始终是最后才考虑的情况。

作为可观测性的初始支柱，集中式日志记录可用于多种目的：从调试生产事件、解决客户支持工单、缓解安全漏洞，甚至了解客户如何使用产品。

任何集中式日志存储最重要的功能是能够快速聚合、分析和搜索来自不同来源的大量日志数据。这种集中化简化了故障排除，使其更容易查明服务中断的根本原因。Elastic、Datadog 和 Splunk 就是很好的例子，它们已经利用这种价值主张取得了巨大的成功。

随着用户对价格越来越敏感，并且发现这些开箱即用的产品的成本相对于它们带来的价值而言过高且不可预测，成本效率高且可预测的日志存储（查询性能可以接受）比以往任何时候都更有价值。

在本文中，我们介绍了 CGW 堆栈（ClickHouse、Grafana、WarpStream 或“万无一失”）并演示了它如何为典型的日志数据提供超过 10 倍的压缩率，当与存储和计算分离相结合时，允许 ClickHouse Cloud 开发层实例舒适地托管超过 1.5TiB 的日志数据（假设列数与我们的示例数据相似，约为 50 亿行）：将其压缩到 100GiB 以下。完全并行化的查询执行引擎，加上底层优化，确保查询性能在这些卷上对于大多数典型的 SRE 查询保持在 1 秒以下，正如我们的基准测试所证明的那样。

在我们的基准测试中，压缩率高达 14 倍，这个集群（允许高达 1TiB 的压缩数据）有可能存储高达 14 TiB 的未压缩日志数据。如果查询性能不太关键，用户可以使用此剩余容量来进一步提高存储密度，或者，或者，只是简单地使用它来延长数据保留时间。我们展示了与 Elastic 和 Datadog 等其他解决方案相比，节省的成本非常显著，对于相同的数据量，后两者的成本是前者的 23 倍到 42 倍。

虽然 ClickHouse 可以独立用作日志存储引擎，但我们理解用户通常更喜欢数据首先在 Kafka 中缓冲，然后再插入到 ClickHouse 中的架构。这提供了许多好处，主要是能够吸收流量峰值，同时保持 ClickHouse 上的插入负载恒定，并允许数据转发到其他下游系统。为了在我们提出的架构中尽可能降低成本和运营，我们考虑了一种也分离存储和计算的 Kafka 实现：WarpStream。我们将其与我们对 OTEL 用于日志收集和 Grafana 用于可视化的标准建议相结合。

作为高性能 OLAP 数据库，ClickHouse 用于许多用例，包括时间序列数据的实时分析。其用例的多样性促使了大量分析函数的出现，这些函数有助于查询大多数数据类型。这些查询功能和非常高的压缩率（源于面向列的设计和可定制的编解码器）越来越多地导致用户选择 ClickHouse 作为日志数据存储。通过分离存储和计算，并利用对象存储作为其主要数据存储，ClickHouse Cloud 进一步提高了成本效率。

虽然我们历史上已经看到大型 CDN 提供商使用 ClickHouse 存储日志，但随着日志记录解决方案的成本日益受到关注，我们现在越来越看到中小型企业也开始考虑将 ClickHouse 作为日志存储的替代方案。

WarpStream 是一个与 Apache Kafka® 协议兼容的数据流平台，它直接在任何商品对象存储之上运行。与 ClickHouse 一样，WarpStream 从一开始就为分析用例而设计，旨在以尽可能经济高效的方式帮助管理大量的机器生成数据流。

WarpStream 没有 Kafka 代理，而是有“代理”。代理是无状态的 Go 二进制文件（没有 JVM！），它们使用 Kafka 协议，但与传统的 Kafka 代理不同，任何 WarpStream 代理都可以充当任何主题的“领导者”，提交任何消费者组的偏移量，或充当集群的协调器。没有哪个代理是特殊的，因此根据 CPU 使用率或网络带宽自动扩展它们是微不足道的。

这成为可能的原因是 WarpStream 将计算与存储以及数据与元数据分离开来。每个 WarpStream“虚拟集群”的元数据都存储在一个自定义元数据数据库中，该数据库从头开始编写，旨在以最有效和最具成本效益的方式解决这个确切的问题。

WarpStream 使用对象存储作为主要且唯一的存储，没有本地磁盘，这一事实使其在分析数据方面优于其他 Apache Kafka 实现。

具体来说，WarpStream 使用对象存储作为存储层和网络层，以完全避免可用区之间的带宽成本，而这些费用很容易占传统 Apache Kafka 实现工作负载总成本的 80%。此外，代理的无状态特性使得将工作负载扩展到 GiB/s 的数据成为可能（甚至很容易）。

这些特性使 WarpStream 非常适合日志记录解决方案，在日志记录解决方案中，吞吐量通常很大，价格敏感性至关重要，并且几秒钟的交付延迟是可以接受的。

对于希望部署 WarpStream 进行测试的用户，您可以按照 这些说明将测试集群部署到 Fly.io，或者按照 这些说明部署到 Railway。

ClickHouse Cloud 允许用户部署分离存储和计算的 ClickHouse。虽然用户可以控制分配给生产层的服务的 CPU 和内存，或者允许它自动动态扩展，但开发层为我们的经济高效的日志存储提供了理想的解决方案。此实例类型建议存储限制为 1TiB，计算限制为 4 个 CPU 和 16 GiB 内存，每月费用不会超过 193 美元（假设使用了所有 1TiB）。对于其他用例，由于服务在不使用时能够空闲，因此成本通常低于此值。我们假设日志摄取的持续性意味着这是不可行的。尽管如此，考虑到 ClickHouse 实现的预期 14 倍压缩率，此服务对于需要存储高达 14TiB 原始日志数据的用户来说是理想的日志存储服务。

请注意，开发层使用比生产层更少的副本节点 - 2 个而不是 3 个。这种可用性级别对于日志记录用例也足够了，在日志记录用例中，2 的复制因子通常足以满足 SLA 要求。最后，有限的 TiB 压缩数据存储允许开发简单的成本模型，我们将在下面介绍。

为了基准测试 ClickHouse Cloud 中开发层实例的日志记录用例，我们需要一个具有代表性的数据集。为此，我们使用公开可用的 Web 服务器访问日志数据集。虽然此数据集的架构很简单，但它等同于常用的 nginx 和 Apache 日志。

54.36.149.41 - - [22/Jan/2019:03:56:14 +0330] "GET /filter/27|13%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,27|%DA%A9%D9%85%D8%AA%D8%B1%20%D8%A7%D8%B2%205%20%D9%85%DA%AF%D8%A7%D9%BE%DB%8C%DA%A9%D8%B3%D9%84,p53 HTTP/1.1" 200 30577 "-" "Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)" "-"
31.56.96.51 - - [22/Jan/2019:03:56:16 +0330] "GET /image/60844/productModel/200x200 HTTP/1.1" 200 5667 "https://www.zanbil.ir/m/filter/b113" "Mozilla/5.0 (Linux; Android 6.0; ALE-L21 Build/HuaweiALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.158 Mobile Safari/537.36" "-"
31.56.96.51 - - [22/Jan/2019:03:56:16 +0330] "GET /image/61474/productModel/200x200 HTTP/1.1" 200 5379 "https://www.zanbil.ir/m/filter/b113" "Mozilla/5.0 (Linux; Android 6.0; ALE-L21 Build/HuaweiALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.158 Mobile Safari/537.36" "-"

此 3.5GiB 数据集包含大约 1000 万行日志行，涵盖 2019 年的 4 天。更重要的是，列的基数和数据的循环模式代表了真实数据。利用 公开可用的脚本，我们将此数据集转换为 CSV* 以简化插入。各个文件的大小仍然相当。生成的 ClickHouse 架构如下所示

CREATE TABLE logs
(
  `remote_addr` String,
  `remote_user` String,
  `runtime` UInt64,
  `time_local` DateTime,
  `request_type` String,
  `request_path` String,
  `request_protocol` String,
  `status` UInt64,
  `size` UInt64,
  `referer` String,
  `user_agent` String
)
ENGINE = MergeTree
ORDER BY (toStartOfHour(time_local), status, request_path, remote_addr)

这代表了一个朴素的、未优化的架构。可以进行进一步的优化，这可以将压缩率提高 我们在测试中得到的 5%。但是，以上代表了新用户的入门体验。因此，我们使用最不利的配置进行测试。替代架构可以在 此处找到，其中显示了压缩方面的变化。

我们复制了这些数据以涵盖一个月的时间段，以便我们可以预测更典型的保留间隔。虽然这会导致任何固有数据模式的重复，但这被认为足以满足我们的测试，并且类似于日志记录用例中常见的每周周期性。

这个月的数据包含 6600 万行和 20GiB 的原始 CSV/日志数据。为了复制这些数据以进行更大的测试并保留其数据属性，我们使用了一种简单的技术。我们没有简单地复制数据，而是将现有数据与副本合并，副本的顺序已被随机化。这涉及一个 简单脚本，该脚本逐行迭代权威文件和随机文件。来自随机文件和权威文件的行被复制到目标文件中。“配对行”都分配了来自权威文件的日期。这确保了上面显示的循环模式得以保留。这与简单地复制行形成对比，简单地复制行会导致重复的行彼此相邻放置。这将有利于压缩并提供不公平的比较 - 随着我们复制数据而变得更糟。下面，我们显示了使用上述技术复制的相同数据，分别用于 1.33 亿、5.34 亿和 10 亿行日志行。

*在生产场景中，我们建议使用 OTEL 等收集器来实现此目的。

我们的基准测试使用的所有文件都可以在 S3 存储桶 s3://datasets-documentation/http_logs/ 中下载，以便用户复制测试。为了方便起见，此数据为 CSV 格式。对于希望将此数据加载到代表性环境中的用户，我们提供了以下实用程序。这会将数据推送到 WarpStream 实例，如下所示。

clickpipes -broker $BOOTSTRAP_URL -username $SASL_USERNAME -password $SASL_PASSWORD -topic $TOPIC -file data-66.csv.gz
wrote 0 records in 3.5µs, rows/s: 0.000000
generated schema: [time_local remote_addr remote_user runtime request_type request_path request_protocol status size referer user_agent]
wrote 10000 records in 63.2115ms, rows/s: 158198.854156
wrote 20000 records in 1.00043025s, rows/s: 19991.397861
wrote 30000 records in 2.000464333s, rows/s: 14996.517996
wrote 40000 records in 3.000462042s, rows/s: 13331.279947
wrote 50000 records in 4.000462s, rows/s: 12498.556286

为了从 WarpStream 使用此数据，用户可以反过来使用 ClickPipes，ClickHouse Cloud 的本机摄取工具，将此数据插入到 ClickHouse 中。我们在下面演示了这一点。

对于只想执行 ClickHouse 测试的用户，可以使用单个命令从 ClickHouse 客户端加载示例数据文件，如下所示。

INSERT INTO logs FROM INFILE 'data-66.csv.gz' FORMAT CSVWithNames

为了评估 ClickHouse 的存储效率，我们展示了具有越来越多的日志事件的表的未压缩大小和压缩大小（对于上述数据集）。此处的未压缩大小可以被认为类似于 CSV 或原始日志格式中的原始数据量（尽管略少）。

SELECT
	table,
	formatReadableQuantity(sum(rows)) AS total_rows,
	formatReadableSize(sum(data_compressed_bytes)) AS compressed_size,
	formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed_size,
	round(sum(data_uncompressed_bytes) / sum(data_compressed_bytes), 2) AS ratio
FROM system.parts
WHERE (table LIKE 'logs%') AND active
GROUP BY table
ORDER BY sum(rows) ASC

┌─table─────┬─total_rows─────┬─compressed_size─┬─uncompressed_size─┬─ratio─┐
│ logs_66   │ 66.75 million  │ 1.27 GiB    	   │ 18.98 GiB     	   │ 14.93 │
│ logs_133  │ 133.49 million │ 2.67 GiB    	   │ 37.96 GiB     	   │ 14.21 │
│ logs_267  │ 266.99 million │ 5.42 GiB    	   │ 75.92 GiB     	   │	14 │
│ logs_534  │ 533.98 million │ 10.68 GiB   	   │ 151.84 GiB    	   │ 14.22 │
│ logs_1068 │ 1.07 billion   │ 20.73 GiB   	   │ 303.67 GiB    	   │ 14.65 │
│ logs_5340 │ 5.34 billion   │ 93.24 GiB   	   │ 1.48 TiB      	   │ 16.28 │
└───────────┴────────────────┴─────────────────┴───────────────────┴───────┘

我们大约 14 倍的压缩率保持不变，与数据量无关。我们最大的数据集包含超过 50 亿行和 1.5TiB 的未压缩数据，具有更高的压缩率。我们将此归因于数据中更大的重复，这是最初 1000 万行样本大小有限的结果。请注意，通过 进一步的架构优化，可以使磁盘上的数据总大小提高约 5%。

重要的是，即使是我们最大的数据集，也只消耗了我们开发服务不到 10% 的存储空间，不到 100GiB。如果需要，用户可以以最小的成本增加保留十个月的数据（请参阅下面的 成本分析）。

对于可视化，我们建议使用 Grafana 和官方 ClickHouse 插件。为了在代表性的查询负载下基准测试 ClickHouse 性能，我们利用了以下仪表板。它包含 7 个可视化效果，每个可视化效果都混合使用了聚合

1. 显示一段时间内日志的折线图
2. 显示入站 IP 地址总数的指标
3. 显示访问次数最多的 5 个网站路径的条形图
4. 一段时间内的状态代码（多线图）
5. 一段时间内的平均响应时间和第 99 百分位数响应时间（多线图）
6. 按每个 HTTP 请求类型传输的数据（条形量规）
7. 按计数排列的 IP 地址前几名的条形图

每个可视化效果背后的完整查询可以在此处找到。

然后，我们使此仪表板受到一系列用户向下钻取的考验，复制用户诊断特定问题的过程。我们捕获生成的查询，并将这些查询用于我们下面的基准测试。操作顺序如下所示。所有过滤器都是累积的，因此复制了用户向下钻取的过程

• 打开仪表板，显示最近 6 小时的数据。
• 通过向下钻取 404 状态代码（即 status=404）查找错误
• 通过为 request_path 添加额外的过滤器来隔离错误。
• 通过使用 remote_addr 列过滤到特定 IP 来隔离受影响的用户。
• 通过记录响应时间超过 4 秒的访问来评估 SLA 违规。
• 缩小到整月以识别一段时间内的模式。

虽然这些行为是人为的，没有识别出特定的事件，但它们旨在复制 SRE 对集中式日志记录解决方案的典型使用模式。完整的生成查询可以在此处找到。

下面，我们评估这些查询在不同日志量下的性能。

包含 7 个可视化效果和总共 6 次向下钻取，这总共产生了 42 个查询。这些查询的执行方式就好像正在使用仪表板一样，即同时运行 7 个查询，并具有适当的向下钻取功能。在运行任何查询负载之前，我们确保删除任何缓存（包括文件系统缓存）。每个查询执行 3 次。我们展示了每个不断增加的数据量的平均性能，但完整结果包含在此处。

所有测试都可以使用 此存储库中提供的脚本进行复制。下面，我们显示了不断增加的日志量的平均性能、第 95 百分位数性能和第 99 百分位数性能。

行数（百万）	未压缩数据 (GiB)	第 95 百分位数	第 99 百分位数	平均值
66.75	18.98	0.36	0.71	0.1
133.5	37.96	0.55	1.04	0.14
267	75.92	0.78	1.72	0.21
534	151.84	1.49	3.82	0.4
1095.68	303.67	5.18	8.42	1.02
5468.16	1515.52	31.05	47.46	5.48

在所有查询中，平均性能都保持在 1 秒以下，最多可达 10 亿行。如图所示，由于 ClickHouse 的稀疏索引，大多数查询的查询性能不会随着卷的增长而显著下降，甚至优于线性性能。

较高的百分位数可以归因于冷查询，我们的基准测试没有预热时间。如下所示，这些较慢的查询也与我们的最终向下钻取行为相关联，我们在其中可视化了 30 天的数据。这种类型的访问通常不频繁，SRE 主要关注较窄的时间范围。尽管如此，即使对于我们最大的 1.5TiB 测试，平均性能仍然低于 6 秒。

下面，我们显示了仪表板可视化效果在不同向下钻取和数据量下的平均性能。

在 6600 万行或 19GiB 时，所有查询的平均性能都低于 0.1 秒。

将数据量增加到我们之前测试的 4 倍，显示了 2.67 亿行或 76GiB 的性能。尽管数据量增加，但所有查询的性能与之前的测试相比仍然相当。

如果我们将数据量再增加 4 倍，达到 300GiB 或大约 10 亿行，则所有查询的平均性能仍然低于 1 秒。

对于我们的最终测试，我们将数据量增加到 1.5TiB 的未压缩数据或 53 亿行。与首次打开仪表板相关的查询（在此期间，除了时间之外没有应用其他过滤器）代表最慢的查询，大约为 1.5 到 3 秒。所有涉及向下钻取的查询都在一秒内舒适地完成。

精明的读者会注意到，我们没有包括上面与用户“缩小”以覆盖整个月相关的最后一组查询的性能。这些代表最昂贵的查询，它们的计时会扭曲上面的图表。因此，我们在下面单独介绍这些查询。

如图所示，此操作的性能在很大程度上取决于正在查询的数据量，平均性能在 5 秒以下，直到更大的 1.5TiB 负载。我们预计这些覆盖完整数据集的查询并不频繁，也不是典型的 SRE 工作流程。但是，即使这些查询很少见，我们也可以采取措施使用 Clickhouse 功能来提高其性能。我们将在下面在更大的数据集的背景下探讨这些功能。

以上结果显示，我们大多数仪表板查询的平均性能都在几秒钟以下。“缩小”查询（我们的 SRE 尝试识别整月的趋势）最多需要 50 秒。虽然这不是完全的线性扫描，因为我们仍在应用过滤器，但此特定查询是 CPU 密集型的，我们开发服务中的每个节点只有两个内核。默认情况下，查询仅在查询的接收节点上执行。因此，这些查询将受益于在集群中的所有节点之间分配计算，从而允许将四个内核分配给聚合。

在 ClickHouse Cloud 中，可以通过使用并行副本来实现这一点。此功能允许聚合查询的工作分散在集群中的所有节点上，从同一个单分片读取。此功能虽然是实验性的，但已在 ClickHouse Cloud 中的某些工作负载中使用，预计很快将普遍可用。

下面，我们显示了在启用并行副本以将完整集群资源用于作为最终缩小步骤一部分发出的所有查询时的结果。此处的结果适用于最大的 1.5TiB 数据集。完整结果可以在 此处找到。

	一段时间内的简单计数	一段时间内按状态计数	remote_addr 的唯一计数	按计数排列的 request_path	按计数排列的 remote_addr	一段时间内传输的平均响应时间和第 99 百分位数响应时间	按 request_type 传输的总字节数
启用并行副本	24.8	10.81	10.84	9.74	9.75	9.31	8.89
未启用并行副本	52.46	31.35	40.26	20.41	15.14	25.29	23.2
加速	2.12	2.9	3.71	2.1	1.55	2.72	2.61

如图所示，启用并行副本平均可将我们的查询速度提高 2.5 倍。这确保我们的查询最多在 24 秒内响应，大多数查询在 10 秒内完成。请注意，根据我们的测试，只有当需要聚合大量行时，并行副本才会提供好处。对于其他较小的数据集，分布的成本超过了好处。在 ClickHouse 的未来版本中，我们计划使此功能的使用更加自动化，而不是依赖用户根据数据量手动应用适当的设置。

利用 ClickHouse Cloud 开发层的成本主要由计算单元决定，并为存储的数据额外收费。相对而言，由于在 ClickHouse Cloud 中使用了对象存储，此工作负载的存储成本非常低。因此，鼓励用户延长数据保留时间，而不必担心成本累积。

• 每小时 0.2160 美元。假设我们的服务始终处于活动状态，则约为 0.2160 美元 x 24 x 30 = 155.52 美元
• 每 TiB 压缩数据每月 35.33 美元

基于此，我们可以使用简单的计算来估算早期卷的成本。

未压缩大小 (GiB)	压缩大小 (GiB)	行数（百万）	保留成本（1 个月）计算费用 ($)	存储成本 ($)	每月总成本 ($)
18.98	1.37	66.75	155.52	0.05	155.57
37.96	2.96	133.49	155.52	0.1	155.62
75.92	5.42	267	155.52	0.19	155.71
151.84	10.68	534	155.52	0.37	155.89
303.67	20.73	1070	155.52	0.72	156.24
1515.52	93.24	5370	155.52	3.22	$158.74
14336	1024	58976	155.52	35.33	$190.85

如前所述，此处的未压缩大小可以被认为等同于 CSV 和非结构化格式的原始日志格式。很明显，我们的存储成本非常低，对于包含 1.5TiB 未压缩数据的最大测试用例，仅消耗了 3 美元。

上表中的最后一行将预测如果我们使用开发层提供的全部 1TiB 压缩存储的成本。这可以通过更长时间的数据保留或更大的每月卷来实现，这相当于超过 580 亿行数据和 14TiB 未压缩日志。这每月仍然只花费 190 美元。由于对象存储的成本较低，这仅比存储我们最大的 1.5TiB 未压缩测试用例多 32 美元！

WarpStream 的定价练习更简单，无需运行复杂的查询。在这种情况下，WarpStream 充当经济高效且可扩展的缓冲区。我们假设网络上的压缩率显著降低，为 4 倍，因为数据不是以列式方式组织的，并且客户端可能会生成或使用小批量数据，具体取决于其配置。最后，我们还假设 48 小时的保留时间就足够了，因为 WarpStream 只是充当 ClickHouse 前面的临时缓冲区，而不是最终目的地。下面介绍了完整 14TiB 的成本。

未压缩大小 (GiB)	吞吐量 MiB/秒	代理的计算成本 ($)	存储成本（2 天）($)	S3 API 成本	每月总成本 ($)
18.98	1.8Kib/秒	$21.4	$0.007	$58	$80
37.96	3.6KiB/秒	$21.4	$0.014	$58	$80
75.92	7KiB/秒	$21.4	$0.028	$58	$80
151.84	14KiB/秒	$21.4	$0.057	$58	$80
303.67	29KiB/秒	$21.4	$0.116	$58	$80
1515.52	146KiB/秒	$21.4	$0.58	$58	$80
14336	1.38 MiB/秒	$21.4	$5.49	$58	$85

以上使用 Fly.io 2x shared-cpu-1x，配备 2GiB 内存

请注意，WarpStream 计算和 S3 API 成本是相对“固定”的成本，工作负载大小可以进一步增长 5-10 倍，而这些成本都不会增加。这是因为我们需要运行至少两个代理以实现高可用性。但是，即使是此设置中的两个小型代理也可以轻松容忍 10-20MiB/秒的写入量，这比最高行大一个数量级以上。因此，计算成本保持不变。

此外，S3 API 成本也大多是固定的，因为代理必须每 250 毫秒生成一个文件，而与负载无关。但是，随着写入量的增加，批处理也会增加，并且成本保持不变，直到工作负载的总写入吞吐量超过 8MiB 的最大摄取文件大小。

下面，我们介绍了 CGW 堆栈在不同日志量下的每月总成本。

未压缩大小 (GiB)	WarpStream 每月成本 ($)	ClickHouse 每月成本 ($)	总成本 ($)
18.98	80	155.57	235.57
37.96	80	155.62	235.62
75.92	80	155.71	235.71
151.84	80	155.89	235.89
303.67	80	156.24	236.89
1515.52	80	158.74	238.74
14336	85.43	190.85	276.28

以上不包括 OTEL 收集器（或等效物）的成本，我们假设 OTEL 收集器将在边缘运行，并且开销可忽略不计。

为了提供一些相对比较元素，我们决定将我们的 CGW 堆栈的成本与日志记录领域的两个领先解决方案（即 Datadog 和 Elastic Cloud）进行比较。

读者应该记住，我们在这里没有进行精确的苹果对苹果的比较，因为 Elastic 和 Datadog 都提供了超出主要存储/查询功能的全面日志记录用户体验。另一方面，所提出的两种替代解决方案都不包括 Kafka 或 Kafka 兼容的排队机制。

但是，从功能角度来看，主要目标是相同的，并且 CGW 是核心日志记录用例的有效替代方案。我们根据公开可用的定价计算器中的数据以及以下假设，在下表中显示了成本差异

• CGW 每月成本：包括上述 Warpstream + ClickHouse Cloud 成本，并假设使用 Grafana Cloud 免费层实例。
• Elastic Cloud 每月成本：假设 Elastic 标准层（最低）在通用硬件配置文件上运行，具有 2 个可用区和 1 个免费 Kibana 实例。我们还假设 1 比 1 的数据压缩率。
• Datadog 每月成本：假设仅保留 30 天，并承诺每年付款（30 天是在 datadoghq.com/pricing 上列出的具有公开定价的最长期间）
• 此外，所提出的两种替代解决方案都不包括 Kafka 或 Kafka 兼容的排队机制，这些机制必须单独部署和评估。我们已排除替代解决方案的此成本。

未压缩大小 (GiB)	压缩大小 (GiB)	行数（百万）	CGW 每月成本 ($)	Elastic Cloud 每月成本 ($)	Elastic Cloud / CGW 倍数	Datadog 每月成本 ($)	Datadog / CGW 倍数
18.98	1.37	66.75	241	$82	x 0.3	$143	x 0.6
37.96	2.96	133.49	241.05	$82	x 0.3	$143	x 0.6
75.92	5.42	267	241.14	$131	x 0.5	$234	x 1.0
151.84	10.68	534	241.32	$230	x 1.0	$415	x 1.7
303.67	20.73	1070	241.67	$428	x 1.8	$776	x 3.2
1515.52	93.24	5370	244.17	$3,193	x 13.1	$5,841	x 23.9
14336	1024	58976	276.28	$6,355	x 23.0	$11,628	x 42.1

如上所示，对于任何小型工作负载（<150 GiB 未压缩数据），CGW 堆栈几乎静态的成本并非真正合理，替代解决方案更具吸引力。然而，超过此阈值后，我们很快观察到，替代解决方案的成本增长速度高于管理的数据量，对于 1.5 TiB 的日志数据，Elastic Cloud 的成本达到 23 倍，Datadog 的成本达到 42 倍。

根据以上结果，我们得出结论，CGW 堆栈提供了一种经济高效的替代方案，可以轻松扩展到多 TB 级别，而不会增加成本。成本的可预测性为期望系统增长并希望避免未来出现意外的用户带来了明显的优势。超出此规模，用户始终可以决定升级到生产级 ClickHouse Cloud 服务，以跟上不断增长的数据量。我们预计在这种情况下，随着数据量超过 100TiB 甚至 PiB，成本节省将更加可观，大型 CDN 提供商使用 ClickHouse 处理日志就证明了这一点。

除了成本效益之外，访问功能齐全的现代分析存储意味着您可以将用例扩展到基本的日志存储和检索之外，并受益于 ClickHouse 的充满活力的集成生态系统。一个例子是，您可以决定使用 S3 表函数将大量日志以 Parquet 格式存储在远程对象存储桶中以进行存档，从而扩展您的数据保留能力。

在这篇文章中，我们介绍了 CGW 堆栈，这是一种基于 ClickHouse Cloud、WarpStream 和 Grafana 的日志记录解决方案。如果使用 ClickHouse Cloud Development 服务，此堆栈提供了一种经济高效的方式，每月可以存储多达 14TiB 的未压缩数据，费用不到 300 美元。与同类 Elastic Cloud 部署相比，这的成本效益高出 23 倍，与 DataDog 相比，对于相同的数据量，价格最多便宜 42 倍。