Clickhouse 在快手的架构和技术内幕
先说下Clickhouse - 越来越多的新型OLAP数据库涌现，无论是 Clickhouse还是Apache Doris都在逐渐变得流行。其背后一定是有原因的。
Hadoop那套组件众多，运维压力越来越大，因此新型OLAP相对不依赖hadoop生态，简介的架构的特性就很吸引人。
ClickHouse 是俄罗斯Yandex在2016年开源的性能分析型SQL数据库，主要面向OLAP场景。开源之后，凭借优异的查询性能，受到业界的青睐。
官网风格清新
直观感受有多快：
如图一，clickhouse官网做了很多压测，比较了 MySQL、hive、greenplum、vertica、clickhouse
clickhouse 比 hive 快百倍（这个很正常，大家都想得到），而比 vertica 快几倍，比 greenplum 20倍左右。
快的一骑绝尘
Clickhouse的快速主要是因为 存储和计算都快，这里有一些关键特性。
图二：存储快速的原因： 主键存储、列式、块索引、数据分区、本机存储、多重索引
图三：计算快速的原因： 分布式、多线程、向量化、LLVM、RuntimeCodegen
快手使用Clickhouse的规模，截至2019年底。 （图四）
- 存储了 10PB数据；
- 每天新增200TB数据；
- 每天查询 50w；
- 查询的时延（P90) < 3s
快手使用Clickhouse的场景：
这个都比较常见，无非是 BI系统、报表系统、监控系统、ABTEST和用户分析系统
（小编注：
- 报表系统一般指的是传统的、类似Excel的多表头复杂中国式报表，一般每一个单元格都是有单独计算逻辑；
- BI一般是在数据仓库建设完成后，可以通过BI软件自助分析的图表；
- 监控系统一般是一个酷炫的大屏）
图五，快手Clickhouse的部署架构；
多集群是必须的，通过一个路由进行分流，做一些类似“切面”“网关”做的工作。
数据则是通过 mapreduce（无论是 hive、sparksql 还是其他） 和 flink 进入clickhouse。
Clickhouse在单表的情况下性能比多表join好很多，快手因此总结了一些最佳实践。见图六。
如果是普通企业，到此也差不多了，快手由于业务量大，仍遇到了一些问题难以解决，针对问题，快手提出了Clickhouse on Hdfs 的方案，即存储和计算分离，存储使用hadoop hdfs。自己基于接口重写了 HdfsMergeTree实现。
架构示意
自研HdfsMergeTree 存储引擎
具体涉及的优化点很多，细节相对有深度，这里就不多说了，看一下图九的总结。
欢迎 点赞、转发 ！
您的支持是我更新的动力！
