如何实现ClickHouse文件完整性监控？执行OPTIMIZE后分区是否不再合并？

核心结论 #

执行OPTIMIZE TABLE .. FINAL后，只要该分区不再有新数据写入、也不触发手动合并/ALTER类修改操作，这个分区不会再发生自动合并，完全可以基于此时的文件状态计算MD5哈希来做完整性校验。

原因说明 #

ClickHouse的后台自动合并触发逻辑只针对两种场景：

• 分区内有新增数据写入，产生了新的小数据片段
• 分区内的小文件数量达到启发式合并的阈值
  当执行FINAL优化后，目标分区会被合并为每个列对应一个数据文件（.bin）和标记文件（.mrk）的最小结构，且后续无新写入的情况下，后台合并进程不会再对该分区进行任何操作。

MD5哈希方案落地步骤 #

1. 确认分区写入停止：确保该天分区已经没有任何新的日志写入操作。
2. 执行分区级FINAL优化：用指定分区的优化命令更高效，避免全表操作：

   OPTIMIZE TABLE your_log_table FINAL PARTITION '2024-05-20';
   

3. 计算核心文件哈希：找到该分区的存储目录（默认路径为/var/lib/clickhouse/data/your_db/your_log_table/[partition_id]/），仅对其中的.bin（数据文件）、.mrk（标记文件）、.meta（元数据文件）这类核心存储文件计算MD5，排除临时文件、日志文件等无关文件。
4. 保存哈希值：将计算得到的哈希集合存储到安全的第三方存储（比如本地加密文件、其他数据库），用于后续校验。
5. 定期校验：后续需要验证时，重新计算对应分区文件的哈希值，与保存的哈希集合对比，若不一致则说明文件被篡改。

注意事项 #

• 执行OPTIMIZE操作时，要确保该分区无并发写入，避免合并过程中文件状态变动导致哈希计算不准确。
• 后续绝对不能对该分区执行任何修改操作（比如手动OPTIMIZE、ALTER TABLE、数据写入），否则文件结构会再次变化，之前的哈希值失效。

内容的提问来源于stack exchange，提问作者Yu Wang