Clickhouse 的缘起
Clickhouse 最初是为 Yandex.Metrica 这个世界上第二大的Web分析平台开发的，并且一直是这个系统的核心组件。ClickHouse在Yandex.Metrica中的主要任务是使用非聚合数据在在线模式下构建报告，使用374台服务器组成的集群，在数据库中存储的数据超过20.3万亿行，压缩后的数据量约为2PB，未压缩的数据量(TSV格式)大约17PB。
Clickhouse 是一款面向数据仓库提供实时计算的产品，传统数仓普遍存在计算效率低、查询和写入延时高、投资和运维成本高等缺陷。Clickhouse 放弃了很多传统数据仓库习以为常的设计，致力于充分发挥单机性能优势，提供低成本、高效率的实时数据仓库环境。今天我们就来分析，Clickhouse 是如何通过精妙的存储引擎和计算引擎来实现这些目标的。
Clickhouse 为什么这么快
向量化的存储引擎
Clickhouse 是一款列式存储数据库。数据库表通常包含数十甚至数百的列，而分析计算只会使用其中的几个列。行存读取时将整行数据读取到内存中，然后再选择相关的列进行计算，而列式存储仅读取需要参与计算的列，因此列存能够极大的降低数据分析过程中需要读取的数据量。
而在计算引擎设计上，Clickhouse 首次使用了向量化计算引擎，借助于CPU提供的SIMD(Single Instruction Multiple Data，单指令多数据流)技术，可以充分发挥现代计算机体系架构的优势，最大限度的压榨单机性能。在实际使用中，百亿以下的单表基本上使用单机就可以处理，这种处理能力已经可以满足绝大多数企业的需求，也在很大程度上解决了传统数据仓库系统效率低和成本高的问题。
高比例的数据压缩
列存为Clickhouse 带来另一个非常明显的优势是大幅提高了数据压缩空间。列存是将同一列数据存储在连续的空间上，字段类型都是相同的，数据相似度更高，相比于行存数据，能够提供更高的数据压缩比，从而大幅减少压缩后的数据大小，降低磁盘的I/O时间。
实际项目中，Clickhouse 的数据压缩比能够达到8:1，即8T数据压缩后只需要1T的存储空间。Yandex.Metrica 未压缩数据17PB，压缩后2PB，压缩比也接近8:1。
高效的I/O优化
超高的压缩比例为Clickhouse 带来了更低的数据存储成本和I/O访问开销，同时也带来了额外的计算开销 – 数据解压缩。数据压缩后存储到磁盘上，访问时需要进行解压还原数据，之后才能参与分析和计算。如何最大程度减少解压时间，甚至在数据被程序读取前就过滤掉不相干的数据，成为具备压缩能力引擎的一大挑战。
Clickhouse 底层存储引擎使用MergeTree，为了应对海量数据查询和管理需求，Clickhouse 使用了一种和B树索引完全不同的索引结构 – 稀疏索引。
Clickhouse 批量数据插入形成一个最小的存储单元，称为Part，每个Part中的数据按照主键排序，表是由多个Part组成的。
ClickHouse 的表通常都比较大，因此表中的数据通常都是先按照分区键被划分为多个分区，分区键常采用日期的方式，比如下图中按照月份分区。分区表的Part归属于某一个分区，为了实现高效的数据存储，ClickHouse会在后台定期对归属于同一个分区的Part进行合并。
每个数据Part被逻辑上拆分为多个颗粒(granules)，granules是Clickhouse访问时读取的最小数据集，不可分割。granules中的第一行用该行的主键值来标记，这个标记保存在 Part 的索引文件中，Clickhouse 会为每个granules创建独立的索引文件。不仅仅是主键，每一列都会存储类似的标记，可以通过这些标记直接在列文件中查找数据。
和B树索引主键和数据一一对应的结构不同，稀疏索引的数据并没有精确到行，而是通过索引文件中的Mark快速定位到数据所在的granules；然后将定位到的候选granules以并行流的方式加载到ClickHouse引擎，找到最终匹配的数据。这种索引最大的好处是主键索引占用的存储空间很小，扫描的效率也很高，非常适合海量数据分析中的范围查询。
简单举例
以下是一个简单的数据查询过程，通过这个过程我们可以了解到如何从Clickhouse中获取到最终数据。
select count(distinct action) where date=toDate(2020-01-01) and city=’bj’
- 查找primary.idx并找到对应的Mark集合（即数据block集合）;
- 对于要读取的每个列根据.mrk文件定位到Mark对应在数据文件.bin中的数据offset；
- 读取到对应的数据，供后续计算。
Clickhouse 的不足
天下没有免费的午餐，ClickHouse在提供超强查询性能的同时，也会在其他方面做一些取舍。
- 没有完全成熟的事务能力；
- 对于已存在的数据，缺乏高效的数据修改和删除能力；
- 稀疏索引使得ClickHouse在按键值检索单行的点查询时效率不高。
写在最后
任何架构都不是万能的，都有其自身的优点，在获取这些优点的同时也存在局限。尽管ClickHouse还存在着些许的不足，使得其并不适合作为OLTP型的数据库，但并不妨碍其成为优秀的MPP架构数据仓库。
国内诸如字节跳动、腾讯、携程、滴滴出行等众多头部互联网公司，都在使用ClickHouse作为分析查询引擎，提供业务决策、用户画像等场景。在当前基础架构国产化的背景下，还有一众公司基于ClickHouse推出了自己的数据仓库产品，将ClickHouse的产品和理念推广到更广阔的领域。
