滴滴基于 Clickhouse 构建新一代日志存储系统

ClickHouse 是2016年开源的用于实时数据分析的一款高性能列式分布式数据库，支持向量化计算引擎、多核并行计算、高压缩比等功能，在分析型数据库中单表查询速度是最快的。2020年开始在滴滴内部大规模地推广和应用，服务网约车和日志检索等核心平台和业务。本文主要介绍滴滴日志检索场景从 ES 迁移到 CK 的技术探索。

背景

此前，滴滴日志主要存储于 ES 中。然而，ES 的分词、倒排和正排等功能导致其写入吞吐量存在明显瓶颈。此外，ES 需要存储原始文本、倒排索引和正排索引，这增加了存储成本，并对内存有较高要求。随着滴滴数据量的不断增长，ES 的性能已无法满足当前需求。

在追求降低成本和提高效率的背景下，我们开始寻求新的存储解决方案。经过研究，我们决定采用 CK 作为滴滴内部日志的存储支持。据了解，京东、携程、B站等多家公司在业界的实践中也在尝试用 CK 构建日志存储系统。

挑战

面临的挑战主要来自下面三个方面：

1. 数据量大：每天会产生 PB 级别的日志数据，存储系统需要稳定地支撑 PB 级数据的实时写入和存储。

2. 查询场景多：在一个时间段内的等值查询、模糊查询及排序场景等，查询需要扫描的数据量较大且查询都需要在秒级返回。

3. QPS 高：在 PB 级的数据量下，对 Trace 查询同时要满足高 QPS 的要求。

为什么选 Clickhouse

• 大数据量：CK 的分布式架构支持动态扩缩容，可支撑海量数据存储。

• 写入性能：CK 的 MergeTree 表的写入速度在200MB/s，具有很高吞吐，写入基本没有瓶颈。

• 查询性能：CK 支持分区索引和排序索引，具有很高的检索效率，单机每秒可扫描数百万行的数据。

• 存储成本：CK 基于列式存储，数据压缩比很高，同时基于HDFS做冷热分离，能够进一步地降低存储成本。

架构升级

旧的存储架构下需要将日志数据双写到 ES 和 HDFS 两个存储上，由ES提供实时的查询，Spark 来分析 HDFS 上的数据。这种设计要求用户维护两条独立的写入链路，导致资源消耗翻倍，且操作复杂性增加。

在新升级的存储架构中，CK 取代了 ES 的角色，分别设有 Log 集群和 Trace 集群。Log 集群专门存储明细日志数据，而 Trace 集群则专注于存储 trace 数据。这两个集群在物理上相互隔离，有效避免了 log 的高消耗查询（如 like 查询）