编者按
ClickHouse自从2016年开源以来便备受关注，主要应用于数据分析（OLAP）领域，各个大厂纷纷跟进大规模利用。百分点科技在某国家级项目建设中完成了多数据中心的ClickHouse集群建设，日增千亿数据量，在此基础上举行优化与本能调优，能够更好地解决部署规模扩大和数据量扩容等问题。本文结合项目的数据规模及营业场景，重点介绍了百分点大数据技术团队在ClickHouse国家级项目建设中的本能优化理论。
一、概览
2020年4月，百分点大数据技术团队结合某国家级多数据中心的Clickhouse集群建设，发表了“ClickHouse国家级项目最佳理论”，该文介绍了Clickhouse的特点、适用场景与核心概念，以及百分点科技在大规模Clickhouse集群建设与运营方面的理论经验。为部署到更多的城市，解决当前城市数据量扩容问题，Clickhouse集群的设计优化与本能调优成为重点工作：
数据量增加了5倍多：数据量达到每天千亿的级别；
查问周期更长：即时查问周期从7天增加到30天；
数据种类更多：营业数据类型增加了1倍；
集群规模增加了400多台，聚拢节点压力变大；
聚拢查问值列举空间大：部分字段的值列举空间在几百万和几十亿之间，聚拢可能内存溢出。
在做了大规模的尝试后，我们发现沿用集群版本和规划不能满足需求。Clickhouse的很多新特性V1.1.5版本都不支持。经过一系列的版本对比尝试，集群规划变更及参数调优，成功将版本升级到V20.1.16，同时也升级了Clickhouse指标采集与监控系统，满足了数据规模的增长和营业需求的变化。整个升级涉及很多内容，本文仅就Clickhouse本能调优理论举行重点介绍。
二、调优思路
Clickhouse本能主要由CPU、IO、Memory驱动，无论是索引优化、列编码与压缩算法，还是配置的调优，主要是围绕着这三个方面举行。索引改变了数据保存和读取的顺序，编码和压缩改变数据保存与传输的大小，服务配置影响着ClickHouse的资源分配和执行行为。
首先通过版本升级，利用ClickHouse的新特性来提升单条SQL的查问速度，如采用跳数索引、列编码及新的压缩算法，这些都是在新版本中出的新特性。
其次，改变了整个集群的写入方式，在数据写入的时候对集群按照营业概念进入逻辑划分，减少了集群写入压力。
三、理论经验
1. 主键的选择
1.1 生产中如何建主键索引
理论中，时间对于营业是必查字段，因此选用时间字段作为主键，同时将几个重要字段也加入了主键。总体来说，ClickHouse索引的长度没有明确的限制，需要根据实际营业和数据的结构来综合考虑。
提升查问本能
加在索引中的列如果能跳过比拟长的一段数据，则能很好的提升查问本能。
提高数据压缩率
根据主键排序的时候，数据一致性越高，压缩比越高，这两点在下面的尝试用例中会很明显的看到。另外，较长的索引会影响索引的内存利用量，不过对于目前普遍的大数据机器配置来说，以及ClickHouse稀疏索引的特性，四五个字段的长索引，对内存的占用还是很有限的。
1.2 尝试表结构
在项目建设前期，表的主键基本上只有营业时间一个字段，于是我们做了下面的尝试，利用其他比拟重要的字段作为主键开头。
下面四张尝试表字段一致，只有主键不同。其中表2和表3数据一致，各有70亿数据；表28和表29数据一致，各有643575000数据，为了避免分区part数量的影响，所有表的分区都merge比拟彻底，尝试表的分区数也一致。
1.6 看上去log_local29的压缩效果更好，但是为什么不用这种组合索引呢？
实际营业中是多字段开放式查问，found_time是必查字段，无论查什么字段，都要带上found_time字段，利用s_city开头的主键看上去这几个字段得到极大的优化效果，但是在不查问这几个字段的时候，会因为found_time没有得到较好的优化而查问效果变差。
如果是要对每天的数据做类似于数仓的ETL，原始数据层利用这种索引组合则会因为降低比拟多的保存而好很多。
2. 跳数索引
2.1 ClickHouse跳数索引类型
生产中，主要是利用MergeTree系列的引擎，目前，MergeTree系列引擎共支持5种跳数索引，分别是minmax、set和ngrambf_v1和tokenbf_v1、bloom_filter。实际生产中我们只选用了bloom_filter跳数索引，这个是由百分点科技实际营业的数据分布所决定的，后面会分析为什么只用了bloom_filter索引。
在生产中只对列举值比拟多的字段用了bloom_filter跳数索引，其他索引没有利用，因为bloom_filter的索引文件不至于太大，同时对于值比拟多的列又能起到比拟好的过滤效果。因为经过尝试发现对于列举值较少的字段，不建索引查问速度就已经很快，因为列举少，本身在压缩的时候压缩比很高，读取速度很快，但是建了索引之后，要么不能过滤掉数据，要么确实过滤掉一部分数据，但是因为读取的数据块不一致又会导致从原先的大块读取的顺序IO退化为随机IO，反而得不偿失。而列举值较多的情况比如ip字段，在利用ngrambf_v1索引的时候，ngram size和bloom filter大小的选择对索引的大小和效果影响很大。
另外，通过上面的表格也能看出来，有些字段的bloom_filter跳数索引还是非常占用保存的，查问的时候跳数索引的IO也需要考虑。因此，实际中才会出现日志中确实过滤掉了数据，但是查问速度反而慢了的情况。最后，选择什么索引以及索引的参数怎么设置，都要结合营业数据的分布特点也举行，数据的排序方式、散列程度都会影响索引效果。
在生产中，我们调整了一些字段的类型，有的从String变为Int，有的从较大取值范围的类型调整为较小范围的类型；还有一些不常用和压缩后size非常大的字段采取了较高的压缩算法；对于一些列举值较少的String利用了LowCardinality(String)，但由于这个特性在所用版本中有bug，因此在生产中改成了String。
4. 数据分区
4.1 数据分区规则
不指定分区键
如果建表时不指定分区键，则数据默认不分区，所有数据写到一个默认分区all里面。
ClickHouse的聚拢过程大致如下图(这里只画了数据返回流程)。在ClickHouse的聚拢查问中，每个机器都会把自己的聚拢的中间状态返回给分布式节点，也就是说，即使你只是想要Top100，每台机器也会把自己所拥有的所有列举值都返回给分布式节点举行进一步的聚拢。
返回给分布式节点22条数据，分布式节点对着22条数据举行进一步的聚拢，最后得出想要的结果。
再看两个查问的不同之处，能明显看出查问处理的数据量不一样，原查问直接查问原表15.5亿的数据，利用物化视图后，物化视图查问的是存在自己视图表里的数据，数据重组后的数据量差异是两者查问速度差异的根本原因。
6.4 物化视图在理论中的利用
因为营业查问条件的不固定，所以在实际营业中没有利用物化视图，不过在对ClickHouse的监控中利用到了，比如每天新增、每小时新增数据量，每天的流量情况以及慢SQL的查问等，这里就不详细展开了。
总结与展望
通过调优，在生产环境中，95%的查问小于1S响应、98%查问小于3秒响应、99%查问小于5秒响应。
文中的优化思路和方法总体上非常的通用，但具体怎么设计和利用需要结合实际的营业场景来举行。比如，在百分点科技项目中数据的保存是随机写到一定数量机器上的，在了解的不少公司理论中，比拟推荐的都是对数据按照一定规则举行hash举行让相同的数据落到同一台机器上，我们没有这样做，主要有三点原因：一是数据从源头进来的时候就没有举行hash，二是如果在数据流中举行hash会大大的降低数据流的处理速度，三是数据倾斜问题。
另外，对于项目中存在的一些问题我们也举行了反思，比如选用的版本，还不是很稳定和比拟优的版本，选择一个版本需要花费时间和精力举行各种尝试，这个版本也只是在当时匆忙的时间与多个版本中综合妥协的选择。现在，ClickHouse的大版本已经更新到21.X，在此版本后，又出现了很多新功能，比如对于小表的wide part功能、SQL的explain功能、mysql同步数据到ClickHouse、开窗函数，以及利用S3等作为ClickHouse底层保存举行存算分离等，需要学习和理论的还有很多。
文章的最后，就以开窗函数作为彩蛋吧！
开窗函数
开窗函数这个功能在21.3中出现实验性功能，利用这个功能需要设置allow_experimental_window_functions
= 1。
实例：求过去10分钟每分钟都出现并连续出现3次的活跃ip。
可以看出，利用开窗函数后不但SQL简洁不少，执行速度也快很多。开窗函数对于数仓的朋友来说，简直就是福音。
说明：文中所做尝试用的均是尝试数据，与生产会有一定偏差，但总体不影响本文中的相关结论；尝试机器利用的RAID5，具体IO行为与SSD会有差别。