使用 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 作为日志数据存储库。通过分离存储和计算，并利用对象存储作为其主要数据存储，ClickHouse Cloud 进一步提高了这种成本效益。

虽然我们以前已经看到大型 CDN 提供商使用 ClickHouse 存储日志，但随着日志解决方案成本越来越受到关注，我们现在越来越多地看到中小企业也考虑使用 ClickHouse 作为日志存储替代方案。

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

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

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

WarpStream 使用对象存储作为主要存储，并且仅使用对象存储，不使用任何本地磁盘，这使其在分析数据方面优于其他 Apache Kafka 实现。

具体而言，WarpStream 使用对象存储作为存储层和网络层，完全避免了跨 AZ 带宽成本，而对于使用传统 Apache Kafka 实现的负载，这些费用很容易占总成本的 80%。此外，代理的无状态特性使其能够 (甚至很容易) 将负载扩展到 GiB/s 的数据。

这些特性使 WarpStream 成为日志解决方案的理想选择，在日志解决方案中，吞吐量通常很大，价格敏感度至关重要，几秒钟的延迟是可以接受的。

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

ClickHouse Cloud 允许用户部署 ClickHouse，并将存储与计算分离。虽然用户可以控制为生产层分配的 CPU 和内存，或者允许其动态自动扩展，但开发层为我们的经济高效的日志存储提供了理想的解决方案。对于存储，推荐限制为 1TiB，而计算则限制为 4 个 CPU 和 16 GiB 内存，因此这种实例类型的成本不会超过每月 193 美元 (假设使用了所有 1TiB)。对于其他用例，由于服务可以在不使用时处于空闲状态，因此成本通常低于此值。我们假设日志摄取的持续性意味着这种做法不可行。尽管如此，对于需要存储高达 14TiB 的原始日志数据的用户而言，这种服务仍然是日志存储的理想选择，因为预计 ClickHouse 的压缩率将达到 14 倍。

请注意，开发层使用比生产层更少的副本节点 - 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。用户可以选择保留 10 个月的数​​据，成本增加极小（请参阅下面的 成本分析）。

为了可视化，我们建议使用 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。
• 评估 SLA 违规，方法是记录响应时间超过 4 秒的访问。
• 放大，以查看整个月的数据，以识别随时间的模式。

虽然这些行为是人为的，没有识别出特定的事件，但它们旨在复制 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 云中使用了对象存储，因此此工作负载的存储成本微不足道。因此，鼓励用户在不担心积累成本的情况下，更长时间地保留数据。

• 每小时 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.5 TiB 未压缩数据的最大测试用例，仅花费了 3 美元。

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

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

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

以上使用 Fly.io 2x 共享 CPU-1x，内存为 2 GiB

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

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

以下列出了不同日志量情况下 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 收集器（或等效工具）的成本，我们假设这些收集器将在边缘运行，并且开销可以忽略不计。

为了提供一些相对的比较元素，我们决定将 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 的增长倍数达到 x23，Datadog 的增长倍数达到 x42。

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

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

在这篇文章中，我们介绍了 CGW 堆栈，这是一种基于 ClickHouse Cloud、WarpStream 和 Grafana 的日志解决方案。如果使用 ClickHouse Cloud 开发服务，此堆栈提供了一种高效的方式，每月可以以不到 300 美元的价格存储高达 14 TiB 的未压缩数据。与同等配置的 Elastic Cloud 部署相比，这在成本上高效 23 倍，与相同数据量的 DataDog 相比，成本低至 42 倍。