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

• 语言: 中文（简体）
• 格式: .pdf
• 来源: github.com/ClickHouse-China

摘要

本文介绍了趣头条在使用Clickhouse处理每天千亿数据时的实践经验。文档详细描述了业务背景、集群现状以及在实际应用中遇到的问题，并提出了相应的解决方案。通过优化机器配置、改进Zookeeper集群规划以及选择合适的引擎，趣头条成功实现了高效的数据处理和稳定的系统运行。

AI总结

# ClickHouse在趣头条每天千亿数据分析实践总结

## 业务背景
趣头条基于Storm的实时指标计算存在以下问题：
1. 指标口径（SQL）与实时任务的衔接问题。
2. 数据回溯困难。
3. 系统稳定性不足。

需求目标：
1. 实现实时指标SQL化。
2. 数据便于回溯，支持快速恢复。
3. 运维简单。
4. 计算高效，满足周期内完成所有指标计算。

## 集群现状
- **集群规模**：100+台32核128G服务器。
- **性能指标**：
- 每天处理1000亿数据。
- 80%查询1秒内完成。
- 复杂查询30秒内完成。
- 每天21万次查询。
- **技术架构**：
- 使用ClickHouse集群。
- 配套Presto集群。
- 整合HDFS、Flink实时任务管理平台、Kafka集群。
- 引擎推荐：`Replicated*MergeTree`。

## 遇到的问题及解决方案

### 1. 机器配置问题
- **问题**：
- 内存不足，大查询易报错。
- 存储限制，磁盘报警频繁。
- CPU资源不足，大表处理困难。
- **解决方案**：
- 推荐配置：128G+内存。
- 使用软连接实现多盘存储。
- 利用最新版本的“冷热数据分离”特性。
- 提升`max bytes before external sort`参数。
- 小表右表广播优化。

### 2. Zookeeper相关问题
- **问题**：
- Snapshot文件过大导致Follower同步超时。
- Zookeeper压力过大，ClickHouse进入只读模式。
- **解决方案**：
- 分盘存储Snapshot和Log文件（推荐SSD）。
- Snapshot存储盘不低于1T。
- 规划多套Zookeeper集群服务。
- 控制Znode数量在400w以下。
- 监控Zookeeper指标（排队请求、处理延迟等）。

### 3. 引擎选择建议
- 推荐引擎：`Replicated*MergeTree`。
- 优势：
- 数据安全。
- 业务无感知升级。
- 提升查询并发度。

## 总结
趣头条通过ClickHouse实现了每天千亿数据的高效处理，解决了实时指标计算、数据回溯和系统稳定性等问题。未来将持续优化硬件配置、存储架构和Zookeeper集群规划，进一步提升系统性能和稳定性。