擎创技术流 | clickhouse如何加速merge？（合并任务）

本文内容来源：公众号ID-ClickHome

作者：禹鼎侯（擎创科技资深开发工程师）

原文翻译自：https://kb.altinity.com/altinity-kb-setup-and-maintenance/altinity-kb-aggressive_merges/

前言

大家在使用clickhouse的过程中，往往会发现一个奇怪的现象：明明机器性能很强，如36core，1TB内存，但是merge的时候资源却并不能充分利用。原因如下↓

大多数情况下，要想使资源充分利用上，需要改变并行度来进行实现。

这里提供几个有效的配置，用来增加merge的并行度，提高merge的效率：

background_pool_size

实际进行合并的线程。如果不进行查询，那么可以将所有核数都用来合并，比如将该参数设置为36，那么最大可以有36个线程将用来合并。

如果是副本模式的集群，那么所有的节点都需要相同的配置，并确保max_replicated_merges_in_queue的值相同。

background_merges_mutations_concurrency_ratio

每个线程分配多少个任务用于合并，默认是2。该参数的设置需要根据实际场景进行设置，如果小合并比较多，那么意味着一次合并并不能吃满一个CPU，那么此时一个线程分配两个合并任务，将有助于加速小part的merge，最典型的比如实时插入的场景。

如果每次插入的batch比较大，单个part比较大，那么意味着单次合并有可能将整个CPU跑满，此时如果还给单个线程分配2个合并任务，那么反而会拖累合并性能，此种场景建议值是1。

最终的合并任务个数 = background_pool_size * background_merges_mutations_concurrency_ratio。

您可以通过 SELECT metric, value FROM system.metrics WHERE metic LIKE '?ckground%'进行查看。

number_of_free_entries_in_pool_to_lower_max_size_of_merge

该配置属于merge_tree的设置。应该与background_pool_size一起更改。

当用于合并的线程任务池空闲的个数小于该值时，对比较大的part的合并暂时忽略不处理，这样做的目的是防止大part合并将线程池占满，无剩余资源用于小part合并，最终导致小part越积越多，出现"Too many parts(N)"错误。

要想充分发挥其威力，起到真正加速merge的作用，可以将该值设置为线程池的90%~95%。

此外，你可以设置下面这些参数配合使用：

合并后多大的part可以称之为一个大part（由参数max_bytes_to_merge_at_max_space_in_pool控制，默认150G）。

在大合并中禁用直接IO（由参数min_merge_bytes_to_use_direct_io控制，默认10G），因为直接IO会绕过页缓存，因此通常会比较慢。

在merge比较慢，但是网络传输比较快的副本集群上，可以尝试使用execute_merges_on_single_replica_time_threshold配置。该配置是仅在其中一个副本上执行merge，另一个副本会隔execute_merges_on_single_replica_time_threshold时间后再去拉取同步副本数据。

根据实际情况来决定，看是水平合并更好，还是垂直合并更佳。所谓水平合并，就是同时合并所有列。而垂直合并，是先merge表中的ORDER BY 列，然后再逐个merge其他列。这种合并方式会占用更少的内存，打开更少的文件，但与水平合并相比，需要更复杂的计算。

如果表特别多，还可以为调度程序提供更多的资源。这里所说的调度程序，就是指分配merge和一些内部管理的组件，主要是调整background_schedule_pool_size和background_common_pool_size。

检查表的schema，尤其是某些列的压缩算法，它虽然可以减小存储的空间，但是会严重影响merge的速度。

在进行插入时，尽量一个批次多插入，使每个part本身就足够大。需要参考以下配置：min_insert_block_size_bytes / min_insert_block_size_rows / max_insert_block_size。

检查是使用宽模式还是紧凑模式。宽模式指每个列都在一个单独的文件中，紧凑模式指多个列混合在一个文件中（可以从system.parts表查看）。默认情况下，min_bytes_for_wide_part=10，即part大于10（百万行），使用宽模式，否则使用紧凑模式。但有的时候，即使是较大的part（有特别多相对较小的列），使用紧凑格式也是有益的；或者相反，即使是较小的part（有少量的胖列），使用宽格式也是有益的。

考虑使用最近发布的 clickhouse 版本 - 它们默认使用压缩标记，这有利于减少 i/o

以上只是一些理论层面的建议，对于这些配置的优化，所有的调整和性能优化都应通过一些可重现的 "基准 "来控制，这样你就能确保这些优化是否真的如我们所期望的那样。毕竟生产环境千变万化，有些优化并不一定绝对有效。同时还要监控系统资源，包括CPU，内存，IO以及zookeeper的使用情况，以及merge线程池的使用情况。

select * from system.metrics where metric like '%PoolTask'

以上这些建议并不是无脑通用的。对于有些同时要求实时插入和大查询压力的系统，这些优化可能就会显得过于激进，因为上述调整其实是牺牲了查询性能的。因此，不同的设置模板适用于不同的集群场景，不能一概而论。

以下是一个优化设置模板，仅供参考：

cat /etc/clickhouse-server/config.d/aggresive_merges.xml <clickhouse> <background_pool_size>36</background_pool_size> <background_schedule_pool_size>128</background_schedule_pool_size> <background_common_pool_size>8</background_common_pool_size> <background_merges_mutations_concurrency_ratio>1</background_merges_mutations_concurrency_ratio> <merge_tree> <number_of_free_entries_in_pool_to_lower_max_size_of_merge>32</number_of_free_entries_in_pool_to_lower_max_size_of_merge> <max_replicated_merges_in_queue>36</max_replicated_merges_in_queue> <max_bytes_to_merge_at_max_space_in_pool>161061273600</max_bytes_to_merge_at_max_space_in_pool> <min_merge_bytes_to_use_direct_io>10737418240</min_merge_bytes_to_use_direct_io>  </merge_tree> </clickhouse> cat /etc/clickhouse-server/users.d/aggresive_merges.xml <clickhouse>  <profiles> <default> <background_pool_size>36</background_pool_size> <background_schedule_pool_size>128</background_schedule_pool_size> <background_common_pool_size>8</background_common_pool_size> <background_merges_mutations_concurrency_ratio>1</background_merges_mutations_concurrency_ratio> </default> </profiles> </clickhouse>

擎创科技，Gartner连续推荐的AIOps领域标杆供应商。公司专注于通过提升企业客户对运维数据的洞见能力，为运维降本增效，充分体现科技运维对业务运营的影响力。