2. Clickhouse玩转每天千亿数据-趣头条

《Clickhouse玩转每天千亿数据-趣头条》王海胜总结 趣头条在使用ClickHouse处理每日千亿数据时的实践总结，主要内容如下： 1. 问题及解决方案 1.1 ClickHouse数据目录限制 • 问题 ClickHouse的数据目录不支持多盘存储，单盘容量限制大。 • 解决方案 - 推荐机器内存128G+。 - 使用软连接将表分布到不同盘，提高单机存储能力。 - 利用冷热数据分离特性优化存储。 1.2 索引排序问题 • 问题 按时间和事件类型索引（order by (timestamp, eventType)）导致累时指标查询耗时过长（600亿+数据），时间索引失效，需全盘扫描。 • 解决方案 - 调整索引顺序，选择基数较低的列。 - 配置max_bytes_before_external_group_by、max_bytes_before_external_sort。 - 使用uniq、uniqCombined、uniqHLL12聚合函数。 - Join时，小表放在右边，实现右表广播。 1.3 ZooKeeper问题 • 问题 快照文件过大、ZooKeeper压力过大，导致clickhouse表只读、插入失败。 • 解决方案 - 分盘存储快照和日志文件，推荐SSD存储。 - 快照存储盘不低于1T。 - 建多套ZooKeeper集群服务clickhouse集群。 - 限制znode数量在400万以下，监控请求队列和延迟。 1.4 内存限制问题 • 问题 单查询内存超出限制（如9.37 GiB），导致失败。 • 解决方案 - 配置max_memory_usage_for_all_queries，控制内存使用。 - 使用max_bytes_before_external_group_by、max_bytes_before_external_sort和聚合函数优化内存。 - Join时优化小表位置。 1.5 集群配置问题 • 问题 早期集群配置（16核64G、1.7T SSD）存在内存、存储、CPU限制问题。 • 解决方案 - 提升机器内存到128G+。 - 使用多盘存储，分散表数据。 - 合理规划分区，了解数据特性，避免merge延迟。 1.6 查询进程崩溃问题 • 问题 max_memory_usage_for_all_queries默认值为0，导致内存超限，进程被kill。 • 解决方案 - 配置max_memory_usage_for_all_queries，限制内存使用，避免进程被终止。 2. 引擎选择 • 推荐使用ReplicatedMergeTree引擎 - 数据安全，保障业务安全。 - 支持业务无感知升级。 - 提升查询并发度。 总结：趣头条在ClickHouse运维过程中遇到并解决了存储、索引、ZooKeeper、内存和配置等多方面问题，提供了实际的优化方案。