ClickHouse最佳实践

Power Your Data

新浪-⾼高鹏-2018年年10⽉月
 19 台服务器器

300亿 /天 数据量量

存量量数据1.5万亿
800w /天 有效查询

平均查询时间 200ms
核⼼心监控查询平均 40ms 截⽌止2018年年09⽉月03⽇日
Content
• Why ClickHouse

• How it works

• Best practice
About me
MySQL DBA

数据分析
About Me AIOps

Visualization Monitoring
MySQL DBA
Analytics Data Science
数据分析
Big Data
AIOps Back
APP Net DB LB End
About Data
• 我们做什什么数据？ Web APP

• 量量级
数据库 CDN 云存储
• 实时性
• 查询需求 主机 负载均衡 DNS

• 接⼊入
⽹网络
About Data

• 业务状态
• 了了如指掌

图：某APM数据
About Data

• 业务状态
• 了了如指掌

图：某后端服务质量量监控
About Data

• 数据分析 产⽣生洞洞⻅见
• 探索未知纬度与组合

CDN1 CDN2

图：某CDN质量量数据 gif动图
About Data

• 数据可视化
• 直观⾼高效
图：某业务在不不同机房质量量数据分布

图：某地⽤用户CDN流量量分布
About Data

• 精细化运维
• 服务质量量⾃自证

图：Redis请求分析
About Data

• 助⼒力力AIOps 图：某域名响应时间⽆无阈值异常监控

• 异常检测

图：某域名访问量量⽆无阈值异常监控
About Data

• 助⼒力力AIOps
图：5XX错误根因纬度分析

• 根因分析

图：某KPI恶化根因纬度排查
About Data
让业务放开写⽇日志

海海量量、实时、

多维、多级

精细化运维和AIOps
数据

数据驱动业务
Why ClickHouse
Before ClickHouse

DATA

• 典型架构
Why ClickHouse
Before ClickHouse

1.链路路太⻓长

2.ES查询、ES存储

3.Hive太慢

4.Spark太重

5.实时⽅方式需要舍弃原始数据

6.BI⼯工具少，分析师崩溃
Why ClickHouse 俄罗斯搜索巨头Yandex开源

异步复制 OLAP
最终⼀一致
SQL
统计函数 压缩
PB级别
列列式存储

集群
驱动丰富

updated in real time

超⾼高性能 线性扩展

跨数据中⼼心
Why ClickHouse

图：ClickHouse线上⼀一些SQL gif动图
注：该配置为4台低配服务器器，⾮非后⽂文的机型
Why ClickHouse
⼀一个体量量超级⼤大的

SQL超级快的

关系型数据仓库
Why ClickHouse
With ClickHouse

• 准实时⼊入库
• 原始数据随⽤用随查
• 缩短数据处理理路路径
• ETL进程易易扩容、通⽤用化
• 资源使⽤用⼤大⼤大降低

图：ClickHouse架构数据流程
Why ClickHouse
对⽐比 ES⽅方案 CK⽅方案 Hive⽅方案

数据接⼊入 较多开源插件 ⾃自研 ⾃自研

实时性 准实时 准实时 离线

DSL语⾔言
 ⽀支持复杂SQL

数据查询 SQL规范，但是很慢
SQL⽀支持有限 执⾏行行快

硬件成本 CPU密集型 CPU密集型 需要Hadoop⽣生态

存储成本 资源占⽤用多 ES的1/24 资源占⽤用⼀一般

通⽤用性 ⽐比较通⽤用 需要定义schema 需要定义schema

⻓长期保留留成本⾼高
 提供物化视图

原始数据 可⻓长期保留留
特殊场景需要预聚合 内部聚合
How it works
Client ODBC Python Node.js Scala Rust Perl HTTP

PHP JDBC Golang R Julia C++ Ruby .NET

Data Type SQL Access Quotas Functions

SummingMergeTree Kafka
Cluster
• CK架构 MergeTree Buffer
ReplacingMergeTree
Memory
MaterializedView ReplicatedMergeTree Log
Distributed
Data Storage
How it works

• 列列式存储，异步merge，集群模式

• 向量量引擎+SIMD，超越tight loop

• CK为什什么这么快？ • ⽀支持有限的delete操作

• 数据压缩，减少IO

• 不不⽀支持事务

• 引擎给⼒力力
How it works

• MergeTree的Merge

类似LSM Tree，但是没有内存表，不不记录事务⽇日志
图：LSMTree原理理图、LevelDB原理理图
How it works
Parts

• MergeTree的Merge
Parts
• block

• part
Parts
• partition

Partition

图：ClickHouse Merge示意图
How it works

• MergeTree的Tree

图：MergeTree引擎原理理
How it works
集群⼯工作⽅方式

ck-xx.sina.com.cn

读 聚合返回

读取真实数据
读取真实数据

dist_table dist_table dist_table

base_table base_table base_table

图：ClickHouse集群配置
图：ClickHouse集群读数据示意图
How it works
数据复制

多源、多主、多向复制

数据‘互通有⽆无’
ZK
⾃自带检测机制

⾃自带同步机制（物理理复制） base_table base_table base_table base_table

依赖ZK

⾮非多数派写

图：ClickHouse数据复制示意图
How it works
1-1 N-1

1-2 N-2

• 令⼈人苦恼的复制架构 ……

1-3 N-3

1-4 N-4

Cluster 1 Cluster N
图：ClickHouse数据复制示意图
How it works

• 令⼈人苦恼的复制架构

34⻚页PPT掌握ClickHouse的数据复制 图：ClickHouse数据复制示意图
Best practice
CK架构 管理理
暂时不不使⽤用复制架构，仅使⽤用分⽚片架构
sql_top⼯工具，定位性能瓶颈
多个⼩小集群架构
慢查询kill⼯工具
scale out, not scale up

监控 备份

基于Prometheus+clickhouse_exporter进⾏行行监控 配置⽂文件备份
关注读写量量、merge情况 表结构备份
增加基于system库的数据展示
Best practice

图：ClickHouse SQL实时监控⼯工具 gif动图

Best practice

• ⼀一个悲伤的故事
max_execution_time
Best practice
• 资源限制 • 配额限制
Best practice

• 监控
 31

Best practice 32
41

42
33

43
11 34

12 44
35

13 45
36

14 46
37

Cluster 1X
47
38

Cluster 3X Cluster 4X
Best practice

11 ck11.xxxx.sina.com

12 ck12.xxxx.sina.com
ck1x.xxxx.sina.com 13 ck13.xxxx.sina.com

⽤用于读写负载均衡 14 ck14.xxxx.sina.com

Cluster 1X
⽤用于集群配置，⽅方便便切换

图：ClickHouse域名负载均衡示意图
Best practice
OS
硬件
1. 强制部分内存空闲
1. 合理理的硬件配置，⻅见后⽂文 2. 禁⽤用swap
2. 全内存数据，要考虑内存条的数量量 3. 开启超线程

参数 应⽤用
1. 调⼤大后台merge线程数：background_pool_size
1. 使⽤用Golang驱动写数据
2. 其他参数能明确的尽量量明确，不不要⽤用默认值
2. batch insert 5-10w起步
3. 调⼤大连接数、最⼤大并发查询数 2. 禁⽌止业务select *
4. 调⼤大⽤用户最⼤大可⽤用内存数 3. 合理理设置主键
5. 开启query_log
6. ⽇日志trace级别
7. 启⽤用集群DDL
Best practice
CPU E5-2650 v4 超线程 = 48core

内存 8*16G = 128G

磁盘 12*4T Raid5 = 40T

⽹网卡 双千兆bond0 = 2000Mbps

Best practice 不不要低于这个型号

CPU E5-2650 v4 超线程 = 48core

内存 内存条数也很关键 8*16G = 128G

确保IO性能：1. 磁盘数量量 2. Raid 条带⼤大⼩小

磁盘 12*4T Raid5 = 40T

写⼊入量量⼤大，注意带宽跑满

⽹网卡 双千兆bond0 = 2000Mbps

Best practice

• 数据⽂文件10GB
• 32G内存 VS 128G内存

图：Intel CPU内部架构示意图
Best practice
物化视图 集群规划 system库

聚合数据 容量量规划
query_log
NULL引擎 merges
算⼒力力规划
parts
replicas
processes

字典 管理理 虚拟集群

映射关系 扩容、升级
特殊场景需求
分区删除的tips
Best practice 数据写⼊入

idc, domain, http_code

• 物化视图
• 内部的pipeline

原始数据表
• 极⼤大提速

• 统计压⼒力力放在平时

• 注意多写带来的压⼒力力

• 原始表可以为NULL

物化视图1 物化视图2 物化视图3

• 选择合适的物化视图引擎

select ts, http_code, count(*) select ts, count(*) select ts, domain, count(*)
group by ts, http_code group by ts group by ts, domain

图：物化视图逻辑图
Best practice
• 映射类的数据怎么办？

• 放⼊入宽表：浪费空间

• 单独建表：需要join，不不利利于维护

• 字典

• File/HTTP/ODBC

• MySQL/PG/MongoDB/ClickHouse/MS-SQL

• 举例例

• 数仓中存储中⽂文，⽅方便便分析师查看

• MySQL中存储ISO-Code映射关系

• 查询时，映射为ISO-Code来绘制地图

图：MySQL表字典数据
• 避免条件过滤中，使⽤用词典 type为软删除标记
Best practice
• 系统库
• 进程
图：clusters详情

• 复制状态

• Merge状态

• 数据表统计

• 集群

• query log

图：统计merge情况
Best practice
• 系统库
• 进程

• 复制状态

• Merge状态

• 数据表统计

• 集群

• query log

图：统计压缩⽐比
Best practice
• 系统库
• 进程

• 复制状态

• Merge状态

• 数据表统计

• 集群

• query log

图：统计part数量量、容量量
Best practice
• 系统库
• 进程

• 复制状态

• Merge状态

• 数据表统计

• 集群

• query log

图：query log分析
Best practice 直接查数据⽂文件

clickhouse-client
--query="SELECT partition, count() AS
number_of_parts,
回写MySQL formatReadableSize(sum(bytes)) AS
sum_size FROM xxx
WHERE xxxxx ;"
INSERT INTO FUNCTION --external --file=test.sql --name=parts
mysql('host:port', 'db', 'tb', 'user', 'passwd', 1) --structure='partition UInt16,name
SELECT xxx String,table String,engine String'
-h 127.0.0.1

直接查MySQL数据
Limit 10 by date
CREATE TABLE xxxx GROUP BY
ENGINE = MergeTree ORDER BY id AS xxxx
SELECT * ORDER BY
FROM mysql('host:port', 'db', 'tb', 'user', 'password') xxxx
LIMIT 10 BY date, city;
Best practice
其他问题

1. 写分布式表，对端本地表被删，导致数据来回重传

2. 多parts下，mlocate的updatedb进程，造成⾼高IO

3. 多次OOM

4. hang死

5. 版本混跑，出现乱码
Best practice

• Q1：DB::Exception: DDL background thread is not initialized • Q6：HDFS数据导⼊入

• Q2：DB::Exception: Memory limit (for query) exceeded • Q7：多磁盘

• Q3：DB::Exception: Unknown table function mysql • Q8：数据更更新、⾃自定义分区

• Q4：DB::Exception: Merges are processing significantly • Q9：写分布式表带来的⼀一个问题：连接数暴暴增

slower than inserts • Q10：ClickHouse最⼤大⽀支持多少并发

• Q5：Kafka引擎 • Q11：扩/缩容问题
Future • ⽀支持更更多机器器学习算法
• 更更加复杂的Join
• 对接Tableau
• ⽀支持update
• ⽀支持多磁盘
• 谓词下推
• 集群管理理
Summary
⽤用的好

⽤用不不好
 Summary

别总是讨论能不不能替代Hadoop

别总是⽤用OLTP的标准来要求

别拿⼀一些⽆无意义的SQL来做压测
“⼯工具选的好，下班回家早”