ClickHouse 是近年来备受关注的开源列式数据库，次要用于数据分析（OLAP）畛域。目前国内社区炽热，各个大厂纷纷跟进大规模应用：

• 今日头条 外部用 ClickHouse 来做用户行为剖析，外部一共几千个 ClickHouse 节点，单集群最大 1200 节点，总数据量几十 PB，日增原始数据 300TB 左右。
• 腾讯外部用 ClickHouse 做游戏数据分析，并且为之建设了一整套监控运维体系。
• 携程外部从 18 年 7 月份开始接入试用，目前 80% 的业务都跑在 ClickHouse 上。每天数据增量十多亿，近百万次查问申请。
• 快手外部也在应用 ClickHouse，存储总量大概 10PB，每天新增 200TB，90% 查问小于 3S。
  在国外，Yandex 外部有数百节点用于做用户点击行为剖析，CloudFlare、Spotify 等头部公司也在应用。

特地值得一提的是：国内云计算的领导厂商阿里云率先推出了本人的 ClickHouse 托管产品，产品首页地址为云数据库 ClickHouse，能够点击链接申请加入收费公测，一睹为快！

在社区方面，github star 数目增速惊人。

在 DB-engines 排名上，如下图中红色曲线所示。ClickHouse 开源工夫虽短，然而增势迅猛。

为何 ClickHouse 取得了如此宽泛的关注，失去了社区的青眼，也失去了诸多大厂的利用呢？本文尝试从技术视角进行答复。

1、OLAP 场景的特点

读多于写

不同于事务处理（OLTP）的场景，比方电商场景中加购物车、下单、领取等须要在原地进行大量 insert、update、delete 操作，数据分析（OLAP）场景通常是将数据批量导入后，进行任意维度的灵便摸索、BI 工具洞察、报表制作等。

数据一次性写入后，分析师须要尝试从各个角度对数据做开掘、剖析，直到发现其中的商业价值、业务变化趋势等信息。这是一个须要重复试错、一直调整、继续优化的过程，其中数据的读取次数远多于写入次数。这就要求底层数据库为这个特点做专门设计，而不是自觉采纳传统数据库的技术架构。

大宽表，读大量行然而少量列，后果集较小

在 OLAP 场景中，通常存在一张或是几张多列的大宽表，列数高达数百甚至数千列。对数据分析解决时，抉择其中的多数几列作为维度列、其余多数几列作为指标列，而后对全表或某一个较大范畴内的数据做聚合计算。这个过程会扫描大量的行数据，然而只用到了其中的多数列。而聚合计算的后果集相比于动辄数十亿的原始数据，也显著小得多。

数据批量写入，且数据不更新或少更新

OLTP 类业务对于延时（Latency）要求更高，要防止让客户期待造成业务损失；而 OLAP 类业务，因为数据量十分大，通常更加关注写入吞吐（Throughput），要求海量数据可能尽快导入实现。一旦导入实现，历史数据往往作为存档，不会再做更新、删除操作。

无需事务，数据一致性要求低

OLAP 类业务对于事务需要较少，通常是导入历史日志数据，或搭配一款事务型数据库并实时从事务型数据库中进行数据同步。少数 OLAP 零碎都反对最终一致性。

灵便多变，不适宜事后建模

剖析场景下，随着业务变动要及时调整剖析维度、开掘办法，以尽快发现数据价值、更新业务指标。而数据仓库中通常存储着海量的历史数据，调整代价非常昂扬。事后建模技术尽管能够在特定场景中减速计算，然而无奈满足业务灵便多变的倒退需要，保护老本过高。

2、ClickHouse 存储层

ClickHouse 从 OLAP 场景需要登程，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稠密索引、数据 Sharding、数据 Partitioning、TTL、主备复制等丰盛性能。以上性能独特为 ClickHouse 极速的剖析性能奠定了根底。

列式存储

与行存将每一行的数据间断存储不同，列存将每一列的数据间断存储。示例图如下：

相比于行式存储，列式存储在剖析场景下有着许多低劣的个性。

1. 如前所述，剖析场景中往往须要读大量行然而少数几个列。在行存模式下，数据按行间断存储，所有列的数据都存储在一个 block 中，不参加计算的列在 IO 时也要全副读出，读取操作被重大放大。而列存模式下，只须要读取参加计算的列即可，极大的减低了 IO cost，减速了查问。
2. 同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节俭了大量的存储空间，升高了存储老本。
3. 更高的压缩比意味着更小的 data size，从磁盘中读取相应数据耗时更短。
4. 自在的压缩算法抉择。不同列的数据具备不同的数据类型，实用的压缩算法也就不尽相同。能够针对不同列类型，抉择最合适的压缩算法。
5. 高压缩比，意味着等同大小的内存可能寄存更多数据，零碎 cache 成果更好。

官网数据显示，通过应用列存，在某些剖析场景下，可能取得 100 倍甚至更高的减速效应。

数据有序存储

ClickHouse 反对在建表时，指定将数据依照某些列进行 sort by。

排序后，保障了雷同 sort key 的数据在磁盘上间断存储，且有序摆放。在进行等值、范畴查问时，where 条件命中的数据都严密存储在一个或若干个间断的 Block 中，而不是扩散的存储在任意多个 Block，大幅缩小须要 IO 的 block 数量。另外，间断 IO 也可能充分利用操作系统 page cache 的预取能力，缩小 page fault。

主键索引

ClickHouse 反对主键索引，它将每列数据依照 index granularity（默认 8192 行）进行划分，每个 index granularity 的结尾第一行被称为一个 mark 行。主键索引存储该 mark 行对应的 primary key 的值。

对于 where 条件中含有 primary key 的查问，通过对主键索引进行二分查找，可能间接定位到对应的 index granularity，防止了全表扫描从而减速查问。

然而值得注意的是：ClickHouse 的主键索引与 MySQL 等数据库不同，它并不用于去重，即使 primary key 雷同的行，也能够同时存在于数据库中。要想实现去重成果，须要联合具体的表引擎 ReplacingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree 实现，咱们会在将来的文章系列中再进行具体解读。

稠密索引

ClickHouse 反对对任意列创立任意数量的稠密索引。其中被索引的 value 能够是任意的非法 SQL Expression，并不仅仅局限于对 column value 自身进行索引。之所以叫稠密索引，是因为它实质上是对一个残缺 index granularity（默认 8192 行）的统计信息，并不会具体记录每一行在文件中的地位。目前反对的稠密索引类型包含：

• minmax: 以 index granularity 为单位，存储指定表达式计算后的 min、max 值；在等值和范畴查问中可能帮忙疾速跳过不满足要求的块，缩小 IO。
• set(max_rows)：以 index granularity 为单位，存储指定表达式的 distinct value 汇合，用于疾速判断等值查问是否命中该块，缩小 IO。
• ngrambf_v1(n, size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)：将 string 进行 ngram 分词后，构建 bloom filter，可能优化等值、like、in 等查问条件。
• tokenbf_v1(size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)：与 ngrambf_v1 相似，区别是不应用 ngram 进行分词，而是通过标点符号进行词语宰割。
• bloom_filter([false_positive])：对指定列构建 bloom filter，用于减速等值、like、in 等查问条件的执行。

数据 Sharding

ClickHouse 反对单机模式，也反对分布式集群模式。在分布式模式下，ClickHouse 会将数据分为多个分片，并且散布到不同节点上。不同的分片策略在应答不同的 SQL Pattern 时，各有劣势。ClickHouse 提供了丰盛的 sharding 策略，让业务能够依据理论需要选用。

1）random 随机分片：写入数据会被随机散发到分布式集群中的某个节点上。2）constant 固定分片：写入数据会被散发到固定一个节点上。3）column value 分片：依照某一列的值进行 hash 分片。4）自定义表达式分片：指定任意非法表达式，依据表达式被计算后的值进行 hash 分片。

数据分片，让 ClickHouse 能够充分利用整个集群的大规模并行计算能力，疾速返回查问后果。

更重要的是，多样化的分片性能，为业务优化关上了设想空间。比方在 hash sharding 的状况下，JOIN 计算可能防止数据 shuffle，间接在本地进行 local join；反对自定义 sharding，能够为不同业务和 SQL Pattern 定制最适宜的分片策略；利用自定义 sharding 性能，通过设置正当的 sharding expression 能够解决分片间数据歪斜问题等。

另外，sharding 机制使得 ClickHouse 能够横向线性拓展，构建大规模分布式集群，从而具备解决海量数据的能力。

数据 Partitioning

ClickHouse 反对 PARTITION BY 子句，在建表时能够指定依照任意非法表达式进行数据分区操作，比方通过 toYYYYMM() 将数据按月进行分区、toMonday() 将数据依照周几进行分区、对 Enum 类型的列间接每种取值作为一个分区等。

数据 Partition 在 ClickHouse 中次要有两方面利用：

• 在 partition key 上进行分区裁剪，只查问必要的数据。灵便的 partition expression 设置，使得能够依据 SQL Pattern 进行分区设置，最大化的贴合业务特点
• 对 partition 进行 TTL 治理，淘汰过期的分区数据。

数据 TTL

在剖析场景中，数据的价值随着工夫流逝而一直升高，少数业务出于老本思考只会保留最近几个月的数据，ClickHouse 通过 TTL 提供了数据生命周期治理的能力。ClickHouse 反对几种不同粒度的 TTL：

1）列级别 TTL：当一列中的局部数据过期后，会被替换成默认值；当全列数据都过期后，会删除该列。2）行级别 TTL：当某一行过期后，会间接删除该行。3）分区级别 TTL：当分区过期后，会间接删除该分区。

高吞吐写入能力

ClickHouse 采纳类 LSM Tree 的构造，数据写入后定期在后盾 Compaction。通过类 LSM tree 的构造，ClickHouse 在数据导入时全副是程序 append 写，写入后数据段不可更改，在后盾 compaction 时也是多个段 merge sort 后程序写回磁盘。程序写的个性，充分利用了磁盘的吞吐能力，即使在 HDD 上也有着优异的写入性能。

官网公开 benchmark 测试显示可能达到 50MB-200MB/ s 的写入吞吐能力，依照每行 100Byte 估算，大概相当于 50W-200W 条 / s 的写入速度。

无限反对 delete、update

在剖析场景中，删除、更新操作并不是外围需要。ClickHouse 没有间接反对 delete、update 操作，而是变相反对了 mutation 操作，语法为 alter table delete where filter_expr, alter table update col=val where filter_expr。

目前次要限度为删除、更新操作为异步操作，须要后盾 compation 之后能力失效。

主备同步

ClickHouse 通过主备复制提供了高可用能力，主备架构下反对无缝降级等运维操作。而且相比于其余零碎它的实现有着本人的特色：

1）默认配置下，任何正本都处于 active 模式，能够对外提供查问服务；2）能够任意配置正本个数，正本数量能够从 0 个到任意多个；3）不同 shard 能够配置不提供正本个数，用于解决单个 shard 的查问热点问题

；

3、ClickHouse 计算层

ClickHouse 在计算层做了十分粗疏的工作，竭尽所能榨干硬件能力，晋升查问速度。它实现了单机多核并行、分布式计算、向量化执行与 SIMD 指令、代码生成等多种重要技术。

多核并行

ClickHouse 将数据划分为多个 partition，每个 partition 再进一步划分为多个 index granularity，而后通过多个 CPU 外围别离解决其中的一部分来实现并行数据处理。

在这种设计下，单条 Query 就能利用整机所有 CPU。极致的并行处理能力，极大的升高了查问延时。

分布式计算

除了优良的单机并行处理能力，ClickHouse 还提供了可线性拓展的分布式计算能力。ClickHouse 会主动将查问拆解为多个 task 下发到集群中，而后进行多机并行处理，最初把后果汇聚到一起。

在存在多正本的状况下，ClickHouse 提供了多种 query 下发策略

随机下发：在多个 replica 中随机抉择一个；

• 最近 hostname 准则：抉择与以后下发机器最相近的 hostname 节点，进行 query 下发。在特定的网络拓扑下，能够升高网络延时。而且可能确保 query 下发到固定的 replica 机器，充分利用零碎 cache。
• in order：依照特定程序一一尝试下发，以后一个 replica 不可用时，顺延到下一个 replica。
• first or random：在 In Order 模式下，当第一个 replica 不可用时，所有 workload 都会积压到第二个 Replica，导致负载不平衡。first or random 解决了这个问题：当第一个 replica 不可用时，随机抉择一个其余 replica，从而保障其余 replica 间负载平衡。另外在跨 region 复制场景下，通过设置第一个 replica 为本 region 内的正本，能够显著升高网络延时。

向量化执行与 SIMD

ClickHouse 不仅将数据按列存储，而且按列进行计算。传统 OLTP 数据库通常采纳按行计算，起因是事务处理中以点查为主，SQL 计算量小，实现这些技术的收益不够显著。然而在剖析场景下，单个 SQL 所波及计算量可能极大，将每行作为一个根本单元进行解决会带来重大的性能损耗：

1）对每一行数据都要调用相应的函数，函数调用开销占比高；2）存储层按列存储数据，在内存中也按列组织，然而计算层按行解决，无奈充分利用 CPU cache 的预读能力，造成 CPU Cache miss 重大；3）按行解决，无奈利用高效的 SIMD 指令；

ClickHouse 实现了向量执行引擎（Vectorized execution engine），对内存中的列式数据，一个 batch 调用一次 SIMD 指令（而非每一行调用一次），不仅缩小了函数调用次数、升高了 cache miss，而且能够充分发挥 SIMD 指令的并行能力，大幅缩短了计算耗时。向量执行引擎，通常可能带来数倍的性能晋升。

动静代码生成 Runtime Codegen

在经典的数据库实现中，通常对表达式计算采纳火山模型，也行将查问转换成一个个 operator，比方 HashJoin、Scan、IndexScan、Aggregation 等。为了连贯不同算子，operator 之间采纳对立的接口，比方 open/next/close。在每个算子外部都实现了父类的这些虚函数，在剖析场景中单条 SQL 要解决数据通常高达数亿行，虚函数的调用开销不再能够忽略不计。

另外，在每个算子外部都要思考多种变量，比方列类型、列的 size、列的个数等，存在着大量的 if-else 分支判断导致 CPU 分支预测生效。

ClickHouse 实现了 Expression 级别的 runtime codegen，动静地依据以后 SQL 间接生成代码，而后编译执行。如下图例子所示，对于 Expression 间接生成代码，不仅打消了大量的虚函数调用（即图中多个 function pointer 的调用），而且因为在运行时表达式的参数类型、个数等都是已知的，也打消了不必要的 if-else 分支判断。

近似计算

近似计算以损失肯定后果精度为代价，极大地晋升查问性能。在海量数据处理中，近似计算价值更加显著。

ClickHouse 实现了多种近似计算性能：近似估算 distinct values、中位数，分位数等多种聚合函数；建表 DDL 反对 SAMPLE BY 子句，反对对于数据进行抽样解决；

简单数据类型反对

ClickHouse 还提供了 array、json、tuple、set 等复合数据类型，反对业务 schema 的灵便变更。

5、结语

近年来 ClickHouse 发展趋势迅猛，社区和大厂都纷纷跟进应用。本文尝试从 OLAP 场景的需要登程，介绍了 ClickHouse 存储层、计算层的次要设计。ClickHouse 实现了大多数以后支流的数据分析技术，具备显著的技术劣势：

• 提供了极致的查问性能：开源公开 benchmark 显示比传统办法快 100~1000 倍，提供 50MB~200MB/ s 的高吞吐实时导入能力）
• 以极低的老本存储海量数据：借助于精心设计的列存、高效的数据压缩算法，提供高达 10 倍的压缩比，大幅晋升单机数据存储和计算能力，大幅升高应用老本，是构建海量数据仓库的绝佳计划。
• 简略灵便又不失弱小：提供欠缺 SQL 反对，上手非常简略；提供 json、map、array 等灵便数据类型适配业务疾速变动；同时反对近似计算、概率数据结构等应答海量数据处理。

相比于开源社区的其余几项剖析型技术，如 Druid、Presto、Impala、Kylin、ElasticSearch 等，ClickHouse 更是一整套欠缺的解决方案，它自蕴含了存储和计算能力（无需额定依赖其余存储组件），齐全自主实现了高可用，而且反对残缺的 SQL 语法包含 JOIN 等，技术上有着显著劣势。

相比于 hadoop 体系，以数据库的形式来做大数据处理更加简略易用，学习成本低且灵便度高。以后社区仍旧在迅猛发展中，置信后续会有越来越多好用的性能呈现。

本文作者：Roin123

原文链接：https://developer.aliyun.com/…_content=g_1000161683

本文为阿里云原创内容，未经容许不得转载。