这是我辅导的同学遇到的一个面试问题，关于Doris等OLAP的生产环境最佳实践在未来数据开发的面试占比逐渐变高。
你可能有要意识的收集一下这方面的生产环境最佳实践。
这个问题只要你用Doris，生产环境大概率会用到，面试官问你也理所应当。
关于Doris Compaction 优化的原理可以参考：《Apache Doris Compaction优化百科全书》。
理论是我们进行优化的基础，除了上面文章提到的关于Compaction的基础外，你还需要了解的知识点有两个：
第一，Doris本身的优化以及新版本中的变化
这些内容你可以在Doris的官方文档中找到，其中重点的内容如下，我直接复制过来：
Doris 通过类似 LSM-Tree 的结构写入数据，在后台通过 Compaction 机制不断将小文件合并成有序的大文件，同时也会处理数据的删除、更新等操作。适当的调整 Compaction 的策略，可以极大地提升导入效率和查询效率。Doris 提供如下几种 compaction 方式进行调优：
Vertical compaction
Vertical compaction 是 Doris 1.2.2 版本中实现的新的 Compaction 算法，用于解决大宽表场景下的 Compaction 执行效率和资源开销问题。可以有效降低 Compaction 的内存开销，并提升 Compaction 的执行速度。
实际测试中，Vertical compaction 使用内存仅为原有 compaction 算法的 1/10，同时 compaction 速率提升 15%。
Vertical compaction 中将按行合并的方式改变为按列组合并，每次参与合并的粒度变成列组，降低单次 compaction 内部参与的数据量，减少 compaction 期间的内存使用。
开启和配置方法 (BE 配置)：
enable_vertical_compaction = true可以开启该功能vertical_compaction_num_columns_per_group = 5每个列组包含的列个数，经测试，默认 5 列一组 compaction 的效率及内存使用较友好vertical_compaction_max_segment_size用于配置 vertical compaction 之后落盘文件的大小，默认值 268435456(字节)
Segment compaction
Segment compaction 主要应对单批次大数据量的导入场景。和 Vertical compaction 的触发机制不同，Segment compaction 是在导入过程中，针对一批次数据内，多个 Segment 进行的合并操作。这种机制可以有效减少最终生成的 Segment 数量，避免 -238（OLAP_ERR_TOO_MANY_SEGMENTS）错误的出现。Segment compaction 有以下特点：
可以减少导入产生的 segment 数量
合并过程与导入过程并行，不会额外增加导入时间
导入过程中的内存和计算资源的使用量会有增加，但因为平摊在整个导入过程中所以涨幅较低
经过 Segment compaction 后的数据在进行后续查询以及标准 compaction 时会有资源和性能上的优势
开启和配置方法 (BE 配置):
enable_segcompaction = true可以使能该功能segcompaction_batch_size用于配置合并的间隔。默认 10 表示每生成 10 个 segment 文件将会进行一次 segment compaction。一般设置为 10 - 30，过大的值会增加 segment compaction 的内存用量。
如有以下场景或问题，建议开启此功能：
导入大量数据触发 OLAP_ERR_TOO_MANY_SEGMENTS (errcode -238) 错误导致导入失败。此时建议打开 segment compaction 的功能，在导入过程中对 segment 进行合并控制最终的数量。
导入过程中产生大量的小文件：虽然导入数据量不大，但因为低基数数据，或因为内存紧张触发 memtable 提前下刷，产生大量小 segment 文件也可能会触发 OLAP_ERR_TOO_MANY_SEGMENTS 导致导入失败。此时建议打开该功能。
导入大量数据后立即进行查询：刚导入完成、标准 compaction 还没有完成工作时，此时 segment 文件过多会影响后续查询效率。如果用户有导入后立即查询的需求，建议打开该功能。
导入后标准 compaction 压力大：segment compaction 本质上是把标准 compaction 的一部分压力放在了导入过程中进行处理，此时建议打开该功能。
不建议使用的情况：
导入操作本身已经耗尽了内存资源时，不建议使用 segment compaction 以免进一步增加内存压力使导入失败。
单副本 compaction
默认情况下，多个副本的 compaction 是独立进行的，每个副本在都需要消耗 CPU 和 IO 资源。开启单副本 compaction 后，在一个副本进行 compaction 后，其他几个副本拉取 compaction 后的文件，因此 CPU 资源只需要消耗 1次，节省了 N - 1 倍 CPU 消耗（ N 是副本数）。
单副本 compaction 在表的 PROPERTIES 中通过参数 enable_single_replica_compaction 指定，默认为 false 不开启，设置为 true 开启。
该参数可以在建表时指定，或者通过 ALTER TABLE table_name SET("enable_single_replica_compaction" = "true") 来修改。
Compaction 策略
Compaction 策略决定什么时候将哪些小文件合并成大文件。Doris 当前提供了 2种 compaction 策略，通过表属性的 compaction_policy 参数指定。
size_based compaction 策略
size_based compaction 策略是默认策略，对大多数场景适用。
"compaction_policy" = "size_based"
time_series compaction 策略
time_series compaction 策略是为日志、时序等场景优化的策略。它利用时序数据具有时间局部性的特点，将相邻时间写入的小文件合并成大文件，每个文件只会参与一次 compaction 就合并成比较大的文件，减少反复 compaction 带来的写放大。
"compaction_policy" = "time_series"
time_series compaction 策略在下面 3 个条件任意一个满足的时候触发小文件合并：
未合并的文件大小超过 time_series_compaction_goal_size_mbytes (默认 1GB)
未合并的文件个数超过 time_series_compaction_file_count_threshold (默认 2000)
距离上次合并的时间超过 time_series_compaction_time_threshold_seconds (默认 1小时)
上述参数在表的 PROPERTIES 中设置，可以在建表时指定，或者通过 ALTER TABLE table_name SET("name" = "value") 修改。
Compaction 并发控制
Compaction 在后台执行需要消耗 CPU 和 IO 资源，可以通过控制 compaction 并发线程数来控制资源消耗。
compaction 并发线程数在 BE 的配置文件中配置，包括下面几个：
max_base_compaction_threads：base compaction 的线程数，默认是 4
max_cumu_compaction_threads：cumulative compaction 的线程数，默认是 10
max_single_replica_compaction_threads：单副本 compaction 拉取数据文件的线程数，默认是 10
第二，数据生产侧的优化
数据生产侧的优化十分容易被忽略，这个点就是面试官判断候选人是否有真实生产环境经验的重要依据！
因为Doris compaction是后台执行，前台的导入任务提交频率过高很容易引起后台的写入放大，compaction合并跟不上写入速度导致异常。那么如何优化也十分简单：
提高batch数据量，减少commit频率
对应的参数包含：
sink.buffer-flush.max-bytes，单个批次最多写入的字节数，默认值是10M，生产环境这个参数建议调整到100M以上
sink.buffer-flush.interval，异步刷新缓存的间隔，默认值是10s，生产环境这个参数建议调整到60秒以上
这个问题的回答思路就如上所述了。
如果这个文章对你有帮助，不要忘记 「在看」 「点赞」 「收藏」 三连啊喂！
Flink CDC我吃定了耶稣也留不住他！| Flink CDC线上问题小盘点
380
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
