2-3 基于 EMR OLAP 的开源实时数仓解决方案之 ClickHouse 事务实现

现状

• 需要ClickHouse写事务的原因：许多用户通过Flink+ClickHouse构建“用户画像”、“实时BI报表”等业务，有较高的数据准确性要求；FlinkExactlyOnce需要Sink端支持；ClickHouse社区暂时没有对事务的支持。
• ClickHouse当前写入机制：按照Paritition拆分Block，写入拆分后的PartitionedBlock成为临时DataPart，重命名这个临时DataPart为正式的DataPart，加入到MergeTreeData的DataPartindex中，并对用户可见。

整体方案

• 整体流程：通过事务状态机管理事务的提交和回滚，确保数据的一致性。
• ClickHouse事务状态机：定义了事务的不同状态，如BEGIN、RUNNING、COMMIT、ROLLBACK等。
• ClickHouse写事务处理：在写入过程中，通过事务状态机控制数据的临时存储和正式提交。

测试结果

• 并发对写事务的性能影响：测试结果表明，随着并发度的增加，写事务的性能有所下降，但仍然能够保持较高的吞吐量。
• 数据大小对写事务性能的影响：数据大小的增加对写事务性能有较大影响，但通过优化ShardingKey可以提高性能。
• FlinkExactlyOnce性能：测试结果表明，FlinkExactlyOnce在ClickHouse上的性能表现良好，能够满足实时数据处理的需求。

ShardingKey优化

• case1: 计算UV场景，将相同uid写入到同一shard分片：通过将相同uid写入到同一shard分片，可以提高查询效率，减少数据倾斜。
• case2: IN子查询：通过优化IN子查询的ShardingKey，可以提高查询性能，减少数据传输量。
• case3: Join查询：通过优化Join查询的ShardingKey，可以提高查询性能，减少数据倾斜。
• JDBCShardingKey优化：直接在task级别计算shardId= key % shardNum，打到对应的local shard上，可以提高查询效率，但需要更多的task内存。

未来规划

• 支持分布式事务：未来将支持分布式事务，以进一步提高数据的一致性和可靠性。
• ShardingKey支持FlinkExactlyOnce导入：未来将优化ShardingKey，以支持FlinkExactlyOnce导入，进一步提高数据处理性能。
• MetaServer：未来将引入MetaServer，以进一步提高系统的可扩展性和管理效率。