背景
此前,滴滴日志主要存储于 ES 中。然而,ES 的分词、倒排和正排等功能导致其写入吞吐量存在明显瓶颈。此外,ES 需要存储原始文本、倒排索引和正排索引,这增加了存储成本,并对内存有较高要求。随着滴滴数据量的不断增长,ES 的性能已无法满足当前需求。
在追求降低成本和提高效率的背景下,我们开始寻求新的存储解决方案。经过研究,我们决定采用 CK 作为滴滴内部日志的存储支持。据了解,京东、携程、B站等多家公司在业界的实践中也在尝试用 CK 构建日志存储系统。
挑战
面临的挑战主要来自下面三个方面:
- 数据量大:每天会产生 PB 级别的日志数据,存储系统需要稳定地支撑 PB 级数据的实时写入和存储。
- 查询场景多:在一个时间段内的等值查询、模糊查询及排序场景等,查询需要扫描的数据量较大且查询都需要在秒级返回。
- QPS 高:在 PB 级的数据量下,对 Trace 查询同时要满足高 QPS 的要求。
为什么选 Clickhouse
- 大数据量:CK 的分布式架构支持动态扩缩容,可支撑海量数据存储。
- 写入性能:CK 的 MergeTree 表的写入速度在200MB/s,具有很高吞吐,写入基本没有瓶颈。
- 查询性能:CK 支持分区索引和排序索引,具有很高的检索效率,单机每秒可扫描数百万行的数据。
- 存储成本:CK 基于列式存储,数据压缩比很高,同时基于HDFS做冷热分离,能够进一步地降低存储成本。