ClickHouse：起源和架构

前言

数据可视化蹂躏了一年，Opentsdb，Influxdb都算是接触使用过了，唯独觉得ClickHouse 甚是抢眼，特别在监控中有需要 Group By 某个高维 Tag 进行 Aggregate 运算，此时 Opentsdb 性能和 ClickHouse 的比照完全是 CK 对其他时序的降维打击，正因为觉得如此神奇才决定深入了解下。

Domain 理解

笔者没有这么宏观认知去阐述 ClickHouse 的前世今生，但是常见的一些理念还是能刚帮助理解。

OLTP vs OLAP

早先的文章有不少都是对 Mysql 特性，SQL使用的梳理，原因在当时的业务系统中所有的数据统计均基于业务 Mysql 进行汇聚。对于千万行级别数据，基本没有太大负担。如果数据量级膨胀呢？
最初接触数据库都会有一个基本认知，Mysql & PG 之类都是关系型数据库，可以理解为核心使用点就是在业务密集型系统中，处理复杂业务变更，更为贴切的定义是面向OLTP(Online Transactional Processing) 联机事物处理。相对的 OLAP(Online Analytical Processing)联机分析处理。OLTP最重要的特性是面向事务性的系统，OLAP则是面向数据处理分析类的系统，特别是海量数据统计分析为决策提供数据依据，海量的数据分析，商业智能 BI (Business Intelligence) 催生了OLAP。

多维数据分析

OLAP 联机分析又称为多维数据统计，最早在1933年由关系型数据库之父埃德加•科德（Edgar Frank Codd） 提出，所谓多维数据统计，即是指从不同纬度对数据进行统计分析，For Example：Server1，Server2 分别是2个不同服务，对应有监控指标 QPS1，QPS2

• 下钻：数据从高层次统计向低层次穿透，Server1 的 QPS1 指定部署集群 Cluster1，则会得出统计量 QPS1_Cluster1
• 上卷：与下钻相反，低层次数据向高层次数据汇聚，Server1，Server2 总流量之和
• 切片：固定某个纬度，数据在某个层面的体现，Server1 的 QPS1 在指定部署机房DC1 中不同部署集群Cluster，流量分布
• 切块：固定多个纬度，数据在某个层面的体现，Server1 的 QPS1 在指定部署机房，指定QPS状态码为200的固定纬度下，不同部署集群Cluster，流量分布
• 旋转：多维数据按另一纬度进行旋转

OLAP 分类

为了实现上面是多维的数据分析，最早数据的载体就是在 关系型数据库中。

• ROLAP(Relational OLAP)，利用关系型数据库存储数据，进行不同纬度关联查询统计
• MOLAP(Multidimensional OLAP)，当数据纬度不断增多，ROLAP的性能就会不断衰减，可以对常用纬度统计进行提前汇聚，加快查询
• HOLAP (Hybrid OLAP) ，ROLAP 和 MOLAP 混合，当数据纬度不断增多，MOLAP 会不断增加数据存储成本，对于一个 10 维的数据，整个 MOLAP 的数据膨胀就会有 2^10，混合 ROLAP 和 MOLAP 搭配使用

ClickHouse 演进

ClickHouse的由来是 俄罗斯 Yandex 公司的研发开源。Yandex 的核心业务是搜索引擎，迄今都是最大的俄语搜索引擎～ 对于此类产品非常依赖流量和在线广告转化，因而多数此类公司都会有自身实时数据分析系统，Google Analytics ，Yandex Metrica 就是这样的产品，而正是 Yandex Metrica 的一代代演进催生出了现如今的 ClickHouse。

1. 早期的 Yandex Metrica 使用 Mysql 的 MyISAM 作为数据存储查询，因为MyISAM性能相比 Innodb 略优一些，不需要支持事务。但是随着业务增长，截止2011年，Mysql中数据行已超越 5亿行，数据统计 Yandex 将 90% 的数据统计优化置 26s 以内完成，但是已经是力不从心。
2. 由于上述性能问题，Yandex 开始迁移底层存储，从 Mysql 转入 NoSQL，以 KV Store 配合 LSM-Tree (Log Structured Merge Tree)，通过上述存储转变，Data Cube 预处理数据的策略，很好解决了 Mysql 时的查询性能问题，5亿行数据，9成基本都维持在 1s 内完成，这便是Yandex Metrica 第二代 Metrage。但是 MOLAP 带来的额外存储开销也在已存储换性能的策略下，逐步转变为新的矛盾点。
3. 历经上述2个版本后，Yandex Metrica 开始自研 OLAPServer，结合之前两代长处。模型上从 KV 换会关系型的模型，因为关系型描述更为优质，更容易理解数据关系，查询则选用群众基础较好的 SQL，存储结构划分上谏纳 Mysql 的索引和数据的处理手段，数据和索引分离，索引上采用LSM Tree 用到的稀疏索引，数据存储则是段内有序。不仅如此为了更好的带来存储性能的优化，和数据压缩，整体数据存储选用列存结构，为每个字段使用单独索引文件和数据文件。OLAPServer 可以视作是在 Metrage 上的重构和整体拔高，也奠定了整体基础。相比 Mysql，OLAPServer只能算作是一个数据库，不能算作 DBMS(数据库管理系统)，因为他不具备类似 Mysql 完备的 DDL 功能，且数据存储的类型只有一种类型即固定长度数值型。
4. Clickhouse 诞生，历经了3代的演进发展，最终对数据统计OLAPServer验证了相较 Metrage MOLAP的理念，实时汇聚更为合理，因而 OLAPServer 需要的只是支持不同数据类型和一个完备的 DBMS 管理。Yandex Metrica 的初心就是一款面数据分析工具，面向 Yandex 网站用户的搜索行为，从数仓中进行数据分析。数据的来源则是页面的用户 click 点击触发数据 event，因而：
   ClickHouse = Click + DataWareHouse

ClickHouse 不适用场景

世上没有银弹，ClickHouse 的初心及演进历史已经定位其长处在于数据的统计汇聚，其是一个高性能数仓。因此其也有不试用的场景：

1. 没有事务，不要试图用 CK 做一些事务性的场景应用
2. 不擅长按行进行查询数据，虽然支持但是这个从自身总体设计的存储特性决定，按行进行数据查询性能远不及列查询
3. 不擅长按行删除

ClickHouse 架构

上文已经简单介绍了 ClickHouse 基本演进，总体看CK就是一个 MPP(Massive Parallel Processing) 架构列存数据库，并且具备完善的 DBMS 管理能力，SQL查询一般的GROUP BY，ORDER BY，JOIN，IN 等操作均支持。并且在整体分层设计上，也很类似 Mysql，封装了不同的存储引擎，拥有 MergeTree，内存，文件，接口等 6 类20多种不同的表引擎。

基本特性

列式存储

CK的核心设计，都是为了让查询变得更快，如果想让查询变快，要么就是 Scan 更少的数据，要么就是传输体量更少的数据。
传统 Mysql 都是行存，即便 Select Table 中的部分字段，也是整行数据 Load 至系统而后摘取其中需要字段，可以理解在 Scan 过程中就没法有选择性的丢弃更多无效数据的 Loading。当数据表纬度较低，Column 较少时不会凸显查询的开销，当列数较多此种方式则会有明显区别。这是行存数据库在大范围列扫描时不可避免劣势于列存的，就像 CK 不擅长行操作一样。
如果在固定数据 Scan 量的情况下，更高的数据压缩，则意味着更少的数据传输。CK 选用列存的一个核心原因也是，同一列是同一个类型的数据，方便使用更优质的压缩算法对数据进行压缩。压缩的实质是重复数据的替换，For Example：

// source string
"abcdefhijklmn, abcdeflni"
// 压缩后
"abcdefhijklmn, (13,6)lni"

压缩后 (13,6) 表示当前位置开始往前13个偏移量后，跨度6个长度的字符串为重复出现在当前的位置。CK 是用的是 LZ4 无损压缩 数据压缩算法对数据进行压缩，实际生产中数据压缩比能够达到 8:1

向量化执行 SIMD

大家日常 Coding 基本有一定认知有时软件优化往往不如资源堆砌来的立竿见影，但是往往过了原始野蛮生长时期，都会历经资源利用率提升的压榨过程。也就是说，往往硬件层面的优化，能够带来性能上质的提升。如果希望在同一个时间片段内进行更多的数据运算，可以借助 CPU 的 SIMD(Single Instruction Multiple Data) 指令来进行单指令数据批量计算

多线程，分布式和多主

SIMD 指令再强大也只能在单 Core 层面去压榨性能，更高的性能要求必须要求系统往过多资源分布上去均摊存储和计算的压力。CK也是，通过多线程去利用硬件的多 Core能力，分布式去缓解单点的压力。整个分布式设计中，对于计算的搬迁远比数据的搬迁成本低的多，利用分布式做数据设计，首先则是对数据进行分布存储，再将数据的获取汇聚下推到各个节点上。ClickHouse 在整体设计上数据纵向进行分区 Partition ，横向则是利用数据分片Shard。纵向利用的是单机多Core的能力，横向则是利用集群化水平拓展的能力。
那么对于一个分布式的ClickHouse，如果设置了一张 Table 为分布式 Engine，则实际这张 Distribution 的表是不进行任何数据存储的，实质只是一个Proxy，对应是由多接点的 本地 local 表进行实际的数据存储计算。
实际生产中，往往一个Shard，也不会是单节点的，多数是会有 Replica 的存在，避免单机故障访问异常和数据丢失，在多副本的结构中，CK没有主从的概念，每个节点都可以进行数据的读写，虽说也有主节点，但是各个 Replica 地位基本一致。

整体架构

这部分只能是捉襟见肘的稍作梳理

• Column 和 Field：CK 的列存模式，在实际运行中，内存中一列数据以 Column 对象表示，提供了数据读取能力，某具体的其中列集合中的一行元素则是 Feild 对象
• DataType：负责对数据进行序列化和反序列化
• Block 和 Block 流：CK中数据面向 Block 操作，Block 对象由 Column，DataType 和 列名字符串组成，整合了Column的数据读取能力以及 DataType 的序列化能力。对应的 IBlockInputStream 和 IBlockOutStream 则是对 Block 流式的封装
• Table：实际 CK 中没有 Table 的概念，由 IStorage 完成 DDL 的功能封装
• Parse & Interpreter：类似 Mysql，查询的分析器和解析器，对SQL进行分析和解析
• Function & Aggregate：Function 类的函数封装是一些常用函数诸如日期转化， 字符串处理等，Aggregate 则是对数据进行聚合运算

ClickHouse 强悍性能的测试报告可以在其管网站查看banchmark报告
本节主要梳理了 ClickHouse 的一些基础概念，ClickHouse MergeTree 参见下一篇。