ClickHouse Better Practices

前言

经过一个月的调研和快速试错,我们的ClickHouse集群已经正式投入生产环境,在此过程中总结出了部分有用的经验,现记录如下。看官可去粗取精,按照自己项目中的实际情况采纳之。(版本为19.16.14.65)

因为我们引入ClickHouse的时间并不算长,还有很多要探索的,因此不敢妄称“最佳实践”,还是叫做“更佳实践”比较好吧。

表相关事项

数据类型
  • 建表时能用数值型或日期时间型表示的字段,就不要用字符串——全String类型在以Hive为中心的数仓建设中常见,但CK环境不应受此影响。
  • 直接用DateTime表示时间列,而不是用整形的时间戳。因为CK中DateTime的底层就是时间戳,效率高,可读性好,且转换函数丰富。
  • 官方已经指出Nullable类型几乎总是会拖累性能,因为存储Nullable列时需要创建一个额外的文件来存储 NULL的标记,并且Nullable列无法被索引。因此除非极特殊情况,应直接使用字段默认值表示空,或者自行指定一个在业务中无意义的值(例如用-1表示没有商品ID)。
分区和索引
  • 事实表必须分区,分区粒度根据业务特点决定,不宜过粗或过细。我们当前都是按天分区,按小时、周、月分区也比较常见(系统表中的query_log、trace_log表默认就是按月分区的)。
  • 必须指定索引列,在绝大多数查询的 WHERE语句中都会用到的列适合作为索引。CK的索引非MySQL的B树索引,而是类似Kafka log风格的稀疏索引,故不用考虑最左原则,但是建议日期列和区分度较低的列在前,区分度较高的列在后。

订正:根据稀疏索引的规律,建议 查询中更经常用做查询条件(WHERE谓词)的列在前,较不经常用做查询条件的列在后。如果有两列在WHERE谓词中出现的频率大致相同,则 基数较大的列(即区分度较高的列)在前,基数较小的列(区分度较低的列)在后。另外, 基数特别大的列(如订单ID等)不建议直接用作索引。

ClickHouse Better Practices_第1张图片
  • 表的索引粒度 index_granularity不建议调整,保持默认值8192即可。
表参数
  • 生产环境中提供线上服务的表均采用复制表与分布式表相结合,即Replicated*MergeTree+Distributed引擎。分布式表的表名为本地表名加上 _all后缀。
  • 如果表中不是必须保留全量历史数据,建议指定TTL,可以免去手动过期历史数据的麻烦。TTL也可以通过 ALTER TABLE语句随时修改。
  • 建议指定 use_minimalistic_part_header_in_zookeeper = 1设置项,能够显著压缩表元数据在ZooKeeper中的存储。该项也可以写入config.xml中的一节。

查询相关事项

单表查询
  • 所有应用层查询禁止 SELECT *
  • 查询分区表必须指定分区(所谓partition pruning),不能全表查询。
  • 大规模数据集上的ORDER BY要加LIMIT限制。
  • 结果集上的简单运算(例如 SELECT pv, uv, pv / uv as ratio...中的ratio)可以在前端展示时再进行,减少SQL中不必要的虚拟列。
  • 业务场景非强制要求100%准确的基数计量,应该用uniq()函数而不是uniqExact()函数或DISTINCT关键字。uniq()底层采用HyperLogLog实现,能够以低于1%的精度损失换来极大的性能提升。
  • 能够重用的模式化查询(如固定刷新的BI报表、热力图等)一定要做成物化视图,并在物化视图上查询出结果,可以避免大量的重复计算。关于其用法,可参见之前写过的 《物化视图简介与ClickHouse中的应用示例》。
多表查询
  • 当两表关联查询只需要从左表出结果时,建议用IN而不是JOIN,即写成 SELECT ... FROM left_table WHERE join_key IN (SELECT ... FROM right_table)的风格。
  • 不管是LEFT、RIGHT还是INNER JOIN操作,小表都必须放在右侧。因为CK默认在大多数情况下都用hash join算法,左表固定为probe table,右表固定为build table且被广播。
  • CK的查询优化器比较弱,JOIN操作的谓词不会下推,因此一定要先做完过滤、聚合等操作,再在结果集上做JOIN。这点与我们写其他平台SQL语句的习惯很不同,初期尤其需要注意。
  • 两张分布式表上的IN和JOIN之前必须加上GLOBAL关键字。如果不加GLOBAL关键字的话,每个节点都会单独发起一次对右表的查询,而右表又是分布式表,就导致右表一共会被查询N 2次(N是该分布式表的shard数量),这就是所谓的查询放大,会带来不小的overhead。加上GLOBAL关键字之后,右表只会在接收查询请求的那个节点查询一次,并将其分发到其他节点上。
负载均衡

对于循环复制拓扑的集群,查询分布式表的负载均衡策略(即 load_balancing)设为first_or_random是最优的,能够充分利用机器page cache的同时,在有replica失败时也能尽量保证负载平均分配。详情可见 这个issue。

写入相关事项

  • 写入分布式表的底表,而不直接写分布式表。在之前的 《ClickHouse复制表、分布式表机制与使用方法》一文中已有说明。
  • 不要做小批量零碎的写入,每批次至少千条级别,避免给merge造成太大压力。
  • 不要同时写入太多个分区,或者写入过快(官方给出的阈值为1秒1次),容易因为merge的速度跟不上parts生成的速度而报出"too many parts"的错误。如果正常情况下还会出现此错误,建议在CPU资源允许的情况下适当调大后台任务线程数 background_pool_size,默认值为16。

运维相关事项

CPU

CK的“快”与其对CPU的积极利用密不可分,所以CPU的单核性能和多核性能都要尽量好一点,16核32线程左右且带较高的睿频比较合适。CK设置中的 max_threads参数控制单个查询所能利用的CPU线程数,默认与本机CPU的物理核心数相同,如果服务器是CK独占的,那么就不用改,否则就改小些。

在监控集群时,CPU指标也是最重要的。实测当单个CK Server节点的CPU使用率超过70%时,服务就不太稳定了。

内存

官方文档建议单机物理内存128G左右。实测CK在我们的应用场景下内存占用并不激进,每线程对应1G内存非常绰绰有余,即 max_threads设为20的话, max_memory_usage参数设为20G(懒得打辣么多0了)。为了不干扰系统的正常运行,也应配置所有查询能利用的最大内存参数 max_memory_usage_for_all_queries,取物理内存的80%左右即可。

另外,CK在执行GROUP BY聚合逻辑的过程中很有可能超出内存限制,因此也建议设置 max_bytes_before_external_group_by参数。在内存占用超出此阈值之后,就会spill到磁盘继续操作,且性能没有降低特别多。官方建议将它设置为 max_memory_usage的一半。

存储

CK不太挑存储介质,普通7200rpm SATA HDD都可以用,也可以配置磁盘阵列,建议RAID10或者RAID6。但是如果为了快速响应,或者多数查询的数据量都很大,还是建议上SSD(我们就是如此)。另外,CK还支持基于配置文件的多盘存储、冷热数据分离和存储策略(storage policy)设置,在特定场景下可能会很有用。我们未实操过,不多讲了。

ZooKeeper

千万要调教好ZooKeeper集群,一旦ZK不可用,复制表和分布式表就不可用了。ZK的数据量基本上与CK的数据量成正相关,所以一定要配置自动清理:

  autopurge.purgeInterval = 1
autopurge.snapRetainCount = 5

另外,ZK的log文件和snapshot文件建议分不同的盘存储,尽量减少follower从leader同步的磁盘压力,且余量必须要留足,毕竟硬盘的成本不算高。

The End

上文中还涉及到一些比较重要的知识点,如MergeTree索引的结构,JOIN语句的执行过程,CK与ZK的交互等等,今后有时间会分别写文章详细讲解。

618之前事情一直都会比较多,希望一切顺利。今天先这样吧。

民那晚安晚安。

你可能感兴趣的:(clickhouse,better,practices)