文章目录
ClickHouse 是俄罗斯Yandex在2016年年开源的一个单进程多线程分析型列式存储数据库，主要面向OLAP场景。
一、适用场景
- 大多数是读请求
- 数据批写入（1000条以上）
- 不修改已添加的数据
- 查询为多行少列
- 存储宽表
- 较少的查询(单台100qps左右)
- 对于简单查询，允许延迟大约50毫秒
- 无大字段(例如，每个URL 60个字节)
- 单查询行数较大
- 无事务要求，对数据一致性要求低
- 数据被过滤或聚合后能够被盛放在单台服务器的内存中
- 处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）
- 每一个查询除了一个大表外都很小
二、读写性能
单个大查询的吞吐量
吞吐量可以使用每秒处理的行数或每秒处理的字节数来衡量。如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以2-10GB／s（未压缩）的速度进行处理（对于简单的查询，速度可以达到30GB／s）。如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以400MB／s的速度读取数据，并且数据压缩率是3，则数据的处理速度为1.2GB/s。这意味着，如果提取一个10字节的列，那么它的处理速度大约是1-2亿行每秒。
处理短查询的延迟时间
如果一个查询使用主键并且没有太多行(几十万)进行处理，并且没有查询太多的列，那么在数据被page cache缓存的情况下，它的延迟应该小于50毫秒(在最佳的情况下应该小于10毫秒)。 否则，延迟取决于数据的查找次数。如果你当前使用的是HDD，在数据没有加载的情况下，查询所需要的延迟可以通过以下公式计算得知： 查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量。
处理大量短查询的吞吐量
在相同的情况下，ClickHouse可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。因此我们建议每秒最多查询100次。
数据的写入性能
建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。如果您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个INSERT进行并行写入，这将带来线性的性能提升。
三、读写限制
1、不支持事务
2、不适用高频率，低延迟的更新和删除，仅支持批量删除、修改
3、稀疏索引，不适合点查询
4、多表查询性能较差
四、资源消耗
ClickHouse默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数。CPU一般在50%左右会出现查询波动，达到70%会出现大范围的查询超时，CPU是最关键的指标，要非常关注。
五、与kafka、hive对接方式
kafka to clickhouse
1、在ClickHouse中创建表，选择表引擎为Kafka()
2、通过物化视图将kafka数据导入ClickHouse
hive to clickhouse
Waterdrop是一个非常易用，高性能，能够应对海量数据的实时数据处理产品，它构建在Spark之上。Waterdrop拥有着非常丰富的插件，支持从Kafka、HDFS、Kudu中读取数据，进行各种各样的数据处理，并将结果写入ClickHouse、Elasticsearch或者Kafka中。
六、数据批量流式写入方式
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QzbR1lwd-1605791184674)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20201119164831907.png)]
七、ClickHouse存储方式
列式存储
- IO消耗低，加速查询
- 数据压缩效果明显
数据有序存储
ClickHouse支持在建表时，指定将数据按照某些列进行order by
主键索引
ClickHouse支持主键索引，它将每列数据按照index granularity（默认8192行）进行划分，对于where条件中含有primary key的查询，通过对主键索引进行二分查找，能够直接定位到对应的index granularity，避免了全表扫描从而加速查询
稀疏索引
ClickHouse支持对任意列创建任意数量的稀疏索引。其中被索引的value可以是任意的合法SQL Expression，并不仅仅局限于对column value本身进行索引。之所以叫稀疏索引，是因为它本质上是对一个完整index granularity（默认8192行）的统计信息，并不会具体记录每一行在文件中的位置。目前
数据Sharding
ClickHouse支持单机模式，也支持分布式集群模式。在分布式模式下，ClickHouse会将数据分为多个分片，并且分布到不同节点上。不同的分片策略在应对不同的SQL Pattern时，各有优势。ClickHouse提供了丰富的sharding策略，让业务可以根据实际需求选用。
1） random随机分片：写入数据会被随机分发到分布式集群中的某个节点上。
2） constant固定分片：写入数据会被分发到固定一个节点上。
3）column value分片：按照某一列的值进行hash分片。
4）自定义表达式分片：指定任意合法表达式，根据表达式被计算后的值进行hash分片。
数据分片，让ClickHouse可以充分利用整个集群的大规模并行计算能力，快速返回查询结果。
数据Partitioning
ClickHouse支持PARTITION BY子句，在建表时可以指定按照任意合法表达式进行数据分区操作。
数据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的查询热点问题；
八、ClickHouse计算方式
多核并行
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实现了向量执行引擎，对内存中的列式数据，一个batch调用一次SIMD指令（而非每一行调用一次），不仅减少了函数调用次数、降低了cache miss，而且可以充分发挥SIMD指令的并行能力，大幅缩短了计算耗时。向量执行引擎，通常能够带来数倍的性能提升。
动态代码生成Runtime Codegen
ClickHouse实现了Expression级别的runtime codegen，动态地根据当前SQL直接生成代码，然后编译执行。对于Expression直接生成代码，不仅消除了大量的虚函数调用，而且由于在运行时表达式的参数类型、个数等都是已知的，也消除了不必要的if-else分支判断。
近似计算
近似计算以损失一定结果精度为代价，极大地提升查询性能。在海量数据处理中，近似计算价值更加明显。
九、ClickHouse查询原理
MergeTree存储在收到一个select查询时会先抽取出查询中的分区键和主键条件的KeyCondition，KeyCondition类上实现了以下三个方法，用于判断过滤条件可能满足的Mark Range。
索引检索的过程中首先会用分区键KeyCondition裁剪掉不相关的数据分区，然后用主键索引挑选出粗糙的Mark Range，最后再用Skipping Index过滤主键索引产生的Mark Range。用主键索引挑选出粗糙的Mark Range的算法是一个不断分裂Mark Range的过程，返回结果是一个Mark Range的集合。起始的Mark Range是覆盖整个MergeTree Data Part区间的，每次分裂都会把上次分裂后的Mark Range取出来按一定粒度步长分裂成更细粒度的Mark Range，然后排除掉分裂结果中一定不满足条件的Mark Range，最后Mark Range到一定粒度时停止分裂。这是一个简单高效的粗糙过滤算法。
使用Skipping Index过滤主键索引返回的Mark Range之前，需要构造出每个Skipping Index的IndexCondition，不同的Skipping Index聚合函数有不同的IndexCondition实现，但判断Mark Range是否满足条件的接口和KeyCondition是类似的。
数据Sampling
经过上一小节的索引过滤之后，我们已经得到了需要扫描的Mark Range集合，接下来就应该是数据扫描部分了。这一小节插入简单讲一下MergeTree里的数据Sampling是如何实现的。它并不是在数据扫描过程中实现的，而是在索引检索的过程中就已经完成，这种做法是为了极致的sample效率。用户在建表的时候可以指定主键中的某个列或者表达式作为Sampling键，ClickHouse在这里用了简单粗暴的做法：Sampling键的值必须是数值类型的，并且系统假定它的值是随机均匀分布的一个状态。如果Sampling键的值类型是Uint32，当我们设定sample比率是0.1的时候，索引检索过程中会把sample转换成一个filter条件：Sampling键的值 < Uint32::max * 0.1。用户在使用Sampling功能时必须清楚这个细节，不然容易出现采样偏差。一般我们推荐Sampling键是列值加一个Hash函数进行随机打散。
数据扫描
MergeTree的数据扫描部分提供了三种不同的模式：
- Final模式：该模式对CollapsingMergeTree、SummingMergeTree等表引擎提供一个最终Merge后的数据视图。前文已经提到过MergeTree基础上的高级MergeTree表引擎都是对MergeTree Data Part采用了特定的Merge逻辑。它带来的问题是由于MergeTree Data Part是异步Merge的过程，在没有最终Merge成一个Data Part的情况下，用户无法看到最终的数据结果。所以ClickHouse在查询是提供了一个final模式，它会在各个Data Part的多条BlockInputStream基础上套上一些高级的Merge Stream，例如DistinctSortedBlockInputStream、SummingSortedBlockInputStream等，这部分逻辑和异步Merge时的逻辑保持一致，这样用户就可以提前看到“最终”的数据结果了。
- Sorted模式：sort模式可以认为是一种order by下推存储的查询加速优化手段。因为每个MergeTree Data Part内部的数据是有序的，所以当用户查询中包括排序键order by条件时只需要在各个Data Part的BlockInputStream上套一个做数据有序归并的InputStream就可以实现全局有序的能力。
- Normal模式：这是基础MergeTree表最常用的数据扫描模式，多个Data Part之间进行并行数据扫描，对于单查询可以达到非常高吞吐的数据读取。
接下来展开介绍下Normal模式中几个关键的性能优化点：
- 并行扫描：传统的计算引擎在数据扫描部分的并发度大多和存储文件数绑定在一起，所以MergeTree Data Part并行扫描是一个基础能力。但是MergeTree的存储结构要求数据不断mege，最终合并成一个Data Part，这样对索引和数据压缩才是最高效的。所以ClickHouse在MergeTree Data Part并行的基础上还增加了Mark Range并行。用户可以任意设定数据扫描过程中的并行度，每个扫描线程分配到的是Mark Range In Data Part粒度的任务，同时多个扫描线程之间还共享了Mark Range Task Pool，这样可以避免在存储扫描中的长尾问题。
- 数据Cache：MergeTree的查询链路中涉及到的数据有不同级别的缓存设计。主键索引和分区键索引在load Data Part的过程中被加载到内存，Mark文件和列存文件有对应的MarkCache和UncompressedCache，MarkCache直接缓存了Mark文件中的binary内容，而UncompressedCache中缓存的是解压后的Block数据。
- SIMD反序列化：部分列类型的反序列化过程中采用了手写的sse指令加速，在数据命中UncompressedCache的情况下会有一些效果。
- PreWhere过滤：ClickHouse的语法支持了额外的PreWhere过滤条件，它会先于Where条件进行判断。当用户在sql的filter条件中加上PreWhere过滤条件时，存储扫描会分两阶段进行，先读取PreWhere条件中依赖的列值，然后计算每一行是否符合条件。相当于在Mark Range的基础上进一步缩小扫描范围，PreWhere列扫描计算过后，ClickHouse会调整每个Mark对应的Granule中具体要扫描的行数，相当于可以丢弃Granule头尾的一部分行。