Clickhouse 在快手的架构和技术内幕

大家好，短视频软件，快手现在风头正盛，面对如此大的用户量，今天带来 《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 存储引擎

具体涉及的优化点很多，细节相对有深度，这里就不多说了，看一下图九的总结。

欢迎 点赞、转发 ！

您的支持是我更新的动力！