全网最细~ Clickhouse 之 merge 工作原理&性能优化《大力仑出品必属精品》

标题Merges 工作原理与性能优化

标题工作原理

• 数据写入和初始存储: 当数据写入 ClickHouse 时，数据先存储在内存中，并以较小的块（parts）写入磁盘。 这些小的块最初写入磁盘时没有进行排序和压缩，称为初级数据片段。
• 合并触发: 合并过程由 ClickHouse 后台自动管理。后台进程会监控表中的数据片段，并根据预设的规则和阈值触发合并操作。 合并操作的触发条件包括：数据片段数量超过阈值、片段大小等。
• 合并操作: 后台进程选择若干个较小的数据片段进行合并。这个过程包括排序、去重和压缩。 合并过程中，ClickHouse 会读取选中的片段，将数据按主键排序，合并成一个新的更大的片段，然后将这个新片段写回磁盘。
• 删除旧片段: 新的合并片段创建并写入磁盘后，旧的、小的片段会被删除。 这个过程确保磁盘空间的有效利用，同时提升查询性能，因为查询时需要扫描的片段数量减少了。
• 并行和优先级: ClickHouse 支持并行合并操作，但会根据系统负载和资源情况调整合并操作的优先级，以避免对在线查询性能的影响。 用户可以配置合并操作的并发度和资源使用情况。

标题性能优化

• background_pool_size 后台任务线程池的大小。后台任务包括数据同步、合并数据片段、删除旧数据、处理突变（mutations）等 GET_PART — 从另一个副本获取分片. ATTACH_PART — 附加的部分, 可能来自我们自己的副本(如果在 detached 文件夹中找到). 您可以将其视为具有一些优化的 GET_PART , 因为它们几乎相同. MERGE_PARTS — 合并分片. DROP_RANGE — 删除指定分区内指定编号范围内的分片. CLEAR_COLUMN — 注意：已弃用. 从指定分区删除特定列. CLEAR_INDEX — 注意：已弃用. 从指定分区删除特定索引. REPLACE_RANGE — 丢弃一定范围的零件并用新零件替换它们. MUTATE_PART — 对分片应用一个或多个突变. ALTER_METADATA — 根据全局 /metadata 和 /columns 路径应用alter修改. 老版本默认该参数配置是8 线程数过小 在加上数据复制同步任务死循环 导致其他任务处于等待状态 可以优化到16 24.3.3.102新版本默认值是:16 ClickHouse 出现 “找不到活跃的 part” 错误通常是因为数据丢失或数据分片不一致引起的。这可能与以下几个方面有关： 数据损坏或丢失：当 ClickHouse 期望在特定的分片中找到数据，但实际上数据丢失或损坏时，就会报错。这可能是由于磁盘故障、人为操作错误或其他原因导致的数据丢失。 分布式表配置不一致：如果在分布式表的不同分片中配置不一致，可能会导致某些分片认为它们应该具有的数据在其他分片中找不到，从而引发此错误。这可能是由于数据不一致的复制、分片键配置错误或拓扑变更等原因导致的。 分布式表元数据不一致：如果元数据状态不同步，例如某个节点认为分片仍处于活动状态，而其他节点认为该分片已不再活动，可能导致类似的问题。 数据过期或删除：如果在 ClickHouse 中进行了数据过期或删除操作，而某些查询仍在尝试访问已删除的数据，就可能会出现此类错误。
• max_replicated_merges_in_queue 用于限制每个分片副本上队列中待处理的最大合并任务数量。这个参数对优化 ClickHouse 集群中的性能和资源利用率至关重要，特别是在处理具有大量数据和高并发操作的场景中 22版本默认值是:2 24.3.3.102新版本默认值是:1000 按照现场写入merge 情况优化参数
• min_rows_for_wide_part 和 min_bytes_for_wide_part 最小行和最小字节触发合并操作 22版本默认值:1024 行 10485760(10MB) 24.3.3.102新版本默认值是:0 行 10485760(10MB) 适应小文件的写入可优化成0行 100 字节
• max_bytes_to_merge_at_max_space_in_pool 合并调度程序会定期分析分区中分块的大小和数量，如果池中有足够的可用资源，则会启动后台合并。合并会一直进行，直到源分块的总大小大于 24.3.3.102新版本默认值是:150G
• max_bytes_to_merge_at_min_space_in_pool 定义在可用磁盘空间不足（池中）的情况下可以合并的部分的最大总大小。这对于减少小部分的数量和Too many parts出错的可能性是必要的。合并通过将合并部分的总大小加倍来预订磁盘空间。因此，在可用磁盘空间较少的情况下，可能会发生这样的情况：有可用空间，但该空间已被正在进行的大型合并所预订，因此其他合并无法启动，并且每次插入时小部分的数量都会增加 24.3.3.102新版本默认值是:1048576 (1 MB)
• number_of_free_entries_in_pool_to_execute_mutation 当池中的空闲条目数少于指定数量时，不要执行部分变更。这是为了留出空闲线程进行常规合并，避免“Too many parts” Default value: 20
• number_of_free_entries_in_pool_to_execute_optimize_entire_partition 当池中的可用条目数小于指定数量时，不要在后台执行优化整个分区（此任务在设置min_age_to_force_merge_seconds并启用时生成min_age_to_force_merge_on_partition_only）。这是为了留出空闲线程进行常规合并，避免“Too many parts” Default value: 25 该设置的值number_of_free_entries_in_pool_to_execute_optimize_entire_partition应小于background_pool_size * background_merges_mutations_concurrency_ratio的值。否则，ClickHouse 将引发异常
• parts_to_throw_insert 如果单个分区中活动部分的数量超过该parts_to_throw_insert值，INSERT则会中断并引发Too many parts (N). Merges are processing significantly slower than inserts异常。 Default value: 3000 23.6 版本之前都是：300
• max_parts_in_total 如果表的所有分区中活动部分的总数超过了该max_parts_in_total值，INSERT则会中断并引发Too many parts (N)异常。 Default value: 100000
• background_merges_mutations_concurrency_ratio 设置线程数与可并发执行的后台合并和突变数之间的比率。例如，如果比率等于 2 并 background_pool_size设置为 16，则 ClickHouse 可以并发执行 32 个后台合并。这是可能的，因为后台操作可以暂停和推迟。这是为了给小合并提供更多的执行优先级。您只能在运行时增加此比率。要降低它，您必须重新启动服务器。可以从配置文件中应用与background_pool_size设置相同的设置以实现向后兼容 每个线程分配多少个任务用于合并，默认是2。该参数的设置需要根据实际场景进行设置，如果小合并比较多，那么意味着一次合并并不能吃满一个CPU，那么此时一个线程分配两个合并任务，将有助于加速小part的merge，最典型的比如实时插入的场景。 如果每次插入的batch比较大，单个part比较大，那么意味着单次合并有可能将整个CPU跑满，此时如果还给单个线程分配2个合并任务，那么反而会拖累合并性能，此种场景建议值是1。 最终的合并任务个数 = background_pool_size * background_merges_mutations_concurrency_ratio。 您可以通过 SELECT metric, value FROM system.metrics WHERE metric LIKE ‘%background%’; 进行查看。
• 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’;

标题TTL 参数优化

• ttl_only_drop_parts 当ttl_only_drop_parts设置为true时，ClickHouse 只会在部分中的所有行根据 TTL 配置已过期时删除整个数据部分。这意味着混合了过期和未过期行的部分将不会被删除；只有每行都已达到其 TTL 过期时间的部分才会被删除。 当ttl_only_drop_parts设置为false（默认值）时，ClickHouse 会正常处理 TTL 操作，这可能涉及删除过期的行并重写部分内容，即使只有部分行过期。