经验分享 | ClickHouse核心技术解析

热文回顾：☞ 大数据领域全景解析

分享嘉宾：和君 阿里云

出品平台：数据仓库与Python大数据

导读：2021年ClickHouse就是一批黑马，成功脱颖而出，在各大互联网都受到青睐，头条、腾讯、快手、阿里都在使用ClickHouse，下面我们一起来学习一下阿里巴巴在ClickHouse中的经验分享。

目录

 1、ClickHouse技术解析

• 整体介绍

• 存储引擎

• 计算引擎
  

 2、云数据库ClickHouse

• 社区痛点

• 自建对比

整体介绍

在给大家分享ClickHouse技术之前，我们先了解一下ClickHouse整体状况。大家可以看到👆上面四张图，通过这四张图我们可以清晰的看出来ClickHouse现在发展的势头特别良好。

• 左上角的图：DB-Engines Ranking排名基本上是下面的那一条蓝线，直线接窜上去的势头。

• 右上角的图：ClickHouse的排名在DB-Engines Ranking一年的时间内排名上升了9位，能够在众多开源产品之间，一年实现排名上升9位也是一个非常了不起的成绩。

• 下面两张我们是根据github的情况进行说明，我们可以看到右下角的图，ClickHouse开源了3年的时间，他的star数量已经达到了11.6k，相较于presto这种已经开源6年的数据产品他的star也只有10.9k。这就说明ClickHouse在更短的时间实现了更好的成绩。

• 另外一点要说的是，ClickHouse他的开发语音是c++写的，所以他的开发社区相比于现在大数据惯用的java技术来说属于小众一点，那么即便是小众的开发者，在更短的时间上，他还能拿到如此多的star数目，说明他的社区是非常受欢迎的。

为什么各大互联网都在使用ClickHouse，以及为什么ClickHouse能够在更短的时间取到如此好的成绩呢？我认为在如下几个方面可以找到答案：

• 大宽表查询性能优异，他的主要分析都是大宽表的sql聚合，ClickHouse整个的聚合耗时都非常小，性能好，并且具有量级的提升

• 我们在使用中发现ClickHouse单表性能分析以及分区对其的join计算都能取得很好的性能优势。

存储引擎

下面我们从整体上来做一下介绍，ClickHouse是如何达到这样的性能优势的，当前ClickHouse既可以做单机运行，也可以做分布式运行。

• 在单机部署的情况，我们一般是云盘+ECS运行ClickHouse的进程

• 在分布式情况下，ClickHouse是分为多个shard，shard之间是完全隔离的，没有任何关系，一般我们都是通过random的hash来做shard，我们可以根据业务的特点去做选择。

• 另外在每个shard内部，我画了两个replica（实际上可以任意拓展多个），他们是互为副本的，那副本与副本之间的数据是完全一致的，那副本的作用能够保证集群的高可用，针对查询热点问题，我们可以针对某个shard指定多个replica副本，来缓解这个shard查询热点的压力

ok，这个就是我们看到的ClickHouse的整体系统架构，那么在查询响应示意图这边，我们可以看到，假设用户的quary通过SLB进来，路由器给其中任何一个ClickHouse节点（初始节点），这个节点对针对查询SQL会拆解分为多个子sql，这个子sql会给其他ClickHouse节点执行，每个节点会把自己统计的结果返回过给初始节点，然后汇总结果返回给用户，这个就是查询的示意图，那么写入也是非常类似的。

一个写入请求进来，每个节点都可能会成为初始节点，节点会根据写入请求拆分为多个子sql，然后把子sql发给对应的节点，进行数据落盘，事实上ClickHouse的整个架构跟我们遇到的其他数据库引擎还是有点像的，唯一的区别就是很大数据库引擎他们会有前端机和后端机存在差异，但事实上ClickHouse他的前端和后端都是对等的，也就是每一个节点都可以承载查询请求和写入请求，每个节点他也可以进行后台的数据计算和操作。

计算引擎

上面是我们整个建标语句，其中包含如下几个部分：

• 支持28种表引擎，每种表引擎有各自不同的用途，今天我们使用的是MergeTree引擎

• 支持按照date创建分区，我们可以根据年、月、日设置分区，他的主要作用就是结合TTL做过数据生命周期管理。

• 支持按照字段order by 排序，提升查询性能

• 支持按照字段做primary key 主键索引，提升查询性能

• 支持ttl

• 支持灵活的参数配置 settings，可以自动调节数据颗粒和block的块大小，假如我们的业务单行数据特别大，可以在settings中做调整。

• 除了mergetree引擎之外，他还支持log family 、integrations（链接其他数据组建）、special

• 还支持物化视图，如果我们sql比较固定的，可以通过物化视图提升查询速度。

我们来看一下mergetree的存储引擎的逻辑视图，他主要分如下几个部分：

1. 首先集群有个一个大的distribute table

2. 然后分步到每个节点都会有自己的local table 他是实际存储数据的

3. local table 会根据日期做分区

4. 每个分区表都有自己对应的data part

5. 我每次批次写入会生成data part，多个data part做异步merge

物理视图，看ppt就行了，写的非常清楚😄

clickhouse稀疏索引我重点介绍一下，正常block大小为：8192，我们今天假设block大小为8，我们的主键位counterid 和date，我们每8个数据位一个mark，下面对应marks number，前八个counterid和date他们的最小值是（a,1）以此类推（a,2）、（a,3）、（b,3）、（e,2）、（e,3）等等。当我们查询counterid in ('a','h')的时候，会直接命中Mark[0,3)和[6,8)

clickhosue的join模式跟doris非常类似。

• allow模式，是shuffle模式，网络io影响join性能

• global模式，是广播模式，小表广播到本地，提高join性能

• lcoal模式，是本地join模式，可以做本地shuffle，优势避免网络io传输做shuffle
  

这个我就不赘述了，面试必问的考点，大家在了解clickhouse优势的同时，也要知道他的不足，这样你才可以更好的去运用。

学习资料

关注公众号回复："09"，即可获得ClickHouse资料合集。