OLAP场景之利器ClickHouse

OLAP场景的关键特性：

大多数数据库访问都是读请求。
数据总是以批量形式写入数据库（每次写入大于10001行）。
已添加的数据一般无需修改。
每次查询都从数据库中读取大量的行，但是同时又仅需少量的列。
数据表多为宽表，即每个表均包含大量的列。
查询量一般较少（非高并发，通常每台服务器每秒有数百个查询或者更少）。
对于简单查询，允许的延迟大约为50毫秒（响应时间要迅速）。
列中的数据相对较小，一般为数字或者短的字符串。
处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）。
事务不是必须的。
对数据一致性要求低。
查询结果明显小于源数据（数据被过滤或者聚合后能够被存放在单台服务器内存中）。

可以看出，OLAP业务场景与其他业务场景如OLTP等有很大的不同，使用OLTP数据库或KeyValue数据库去处理分析查询业务将会获得非常差的性能，而且没有意义。另外相比行式数据

库，列式数据库则更适用于OLAP场景，因为对于大多数的查询而言，列式数据库的处理速度要比行式数据库快100倍。二者的性能差别很大，列式数据库明显占优，可以从以下几个方面解释：

对于分析类查询，通常只需要读取数据表中的一小部分列，使用列式数据库可以很轻松实现，而使用行数据库却需要读取全部的列，这就带来了性能的损失。
列式数据库按列存储数据，使得数据更容易被压缩，可以降低I/O传输的体积，从而使查询速度加快。
由于I/O体积的降低，可以使得更多的查询数据被系统缓存，进一步加快了查询的速度。
另外，执行一个查询一般需要处理大量的行，在整个列向量上执行所有操作将比在每一行上执行所有操作更加高效，而且还可以更加充分的利用CPU资源，从而提升了查询的性能。

ClickHouse特性：

相比其他的列式数据库，ClickHouse的以下特性决定了它更适用于OLAP场景。

数据压缩：ClickHouse会自动对插入的数据进行压缩，这对于性能的提升起到了至关重要的作用。
磁盘存储：ClickHouse被设计为工作在传统磁盘上，这意味着数据存储的成本较低。
多核心并行处理：ClickHouse会利用服务器的一切必要资源，从而以最自然的方式并行化处理大规模查询。
分布式查询：在ClickHouse中，数据可以保存在不同的分片上（shard），查询可以分布在所有分片上并行处理。
支持SQL:ClickHouse的查询语言大部分情况下是与SQL标准兼容的，更容易上手。
向量引擎：ClickHouse采用了列向量引擎技术，可以更为高效的使用CPU资源。
实时数据更新：ClickHouse使用MergeTree引擎对数据进行增量排序，数据可以持续不断的写入到表中并进行合并，而且在整个过程中不会存在任何加锁行为。
支持索引：ClickHouse按照排序键对数据进行排序并支持主键索引，可以使其在几十毫米内完成对特定值或特定范围的查找。
支持近似计算：ClickHouse提供了许多在允许牺牲数据精度的情况下对查询进行加速的方法。

ClickHouse不足：

不支持事务。
不擅长根据主键按照行粒度进行查询（虽然支持，但不友好）故不能把ClickHouse当作Key-Value数据库来使用。
不擅长按行删除数据。

这些弱点并不能视为ClickHouse的缺点，事实上其他高性能的OLAP数据库同样也不擅长上述方面。因为对于OLAP数据库而言，上述这些能力并不是重点，只能说这是为了极致查询性能所做的权衡。

ClickHouse之列式存储与数据压缩：

俗话说的好，要想让查询变得更快，最简单且有效的方法就是减少数据扫描范围和数据传输时的大小，列式存储和数据压缩即能帮助我们实现上述两点，对于一款高性能数据库来说也是必不可少的特性。

一般来说，列式存储是数据压缩的前提。按列存储与按行存储相比，前者可以有效减少查询时所需扫描的数据量，举例如下：

index	F01	F02	F03	F04	F05	F06	F07	F08	F09	F10
1	√	√	√	√	√	*	*	*	*	*
2	√	√	√	√	√	*	*	*	*	*
3	√	√	√	√	√	*	*	*	*	*
4	√	√	√	√	√	*	*	*	*	*
5	√	√	√	√	√	*	*	*	*	*

假设一张数据表有10个字段F01~F10,以及100行数据。现在需要查询前5个字段进行数据分析，则可以用如下SQL实现：

SELECT F01,F02,F03,F04,F05 FROM TABLE_A

如果数据按行存储，数据库首先会逐行扫描，并获取每行数据的所有10个字段，再从每一行数据中返回F01~F05这5个字段。不难发现，尽管只需要前面5个字段，但由于数据是按行进行组织的，实际上还是扫描了所有的字段。如果数据按列存储，就不会发生这样的问题。由于数据按列组织，数据库可以直接获取F01~F05这5列的数据，从而避免了多余的数据扫描。

按列存储相比按行存储的另一个优势是对数据压缩的友好性。

压缩前：abcdefghi_bcdefghi

压缩后：abcdefghi_（9，8）

可以看到，压缩的本质是按照一定步长对数据进行匹配扫描，当发现重复部分的时候就进行编码转换。如上述示例中（9，8），表示如果从下划线开始向前移动9个字节，会匹配到8个字节长的重复项，即这里的bcdefghi。真实的压缩算法自然比这个示例更为复杂，但压缩算法的实质就是如此。数据中的重复项越多，则压缩率越高；压缩率越高，则数据体量越小；而数据体量越小，数据在网络中传输越快，对网络带宽和磁盘IO的压力也就越小。一般来说，同一个列字段的数据，因为拥有相同的数据类型和现实语义，具备重复项的特性自然也就更高。

ClickHouse是使用列式存储的数据库，数据按列进行组织，属于同一列的数据就会被保存在一起，列与列之间也会由不同的文件分别保存（主要指MergeTree表引擎）。数据默认使用LZ4算法压缩。同时，列式存储除了降低IO和存储压力之外，还为向量化执行做好了铺垫。

ClickHouse在数据存取方面，既支持分区（纵向扩展，利用多线程原理），也支持分片（横向扩展，利用分布式原理）