ClickHouse Sink：生产级高可用写入方案｜得物技术

一、背景与痛点

业务场景

在实时大数据处理场景中，Flink + ClickHouse 的组合被广泛应用于：

• 日志处理：海量应用日志实时写入分析库。
• 监控分析：业务指标、APM 数据的实时聚合。

这些场景的共同特点：

• 数据量大：百万级 TPS，峰值可达千万级。
• 写入延迟敏感：需要秒级可见。
• 数据准确性要求高：不允许数据丢失。
• 多表写入：不同数据根据分表策略写入不同的表。

开源 Flink ClickHouse Sink 的痛点

Flink 官方提供的 ClickHouse Sink（flink-connector-jdbc）在生产环境中存在以下严重问题：

痛点一：缺乏基于数据量的攒批机制

问题表现：

展开

代码语言：Java

自动换行

AI代码解释

// Flink 官方 JDBC Sink 的实现
public class JdbcSink<T> extends RichSinkFunction<T> {
    private final int batchSize;  // 固定批次大小
    @Override
    public void invoke(T value, Context context) {
        bufferedValues.add(value);
        if (bufferedValues.size() >= batchSize) {
            // 只能基于记录数攒批，无法基于数据量
            flush();
        }
    }

带来的问题：

1. 内存占用不可控：100 条 1KB 的日志和 100 条 10MB 的日志占用内存差距 100 倍。
2. OOM 风险高：大日志记录（如堆栈转储）会迅速撑爆内存。
3. 写入性能差：无法根据记录大小动态调整批次，导致小记录批次过大浪费网络开销。

痛点二：无法支持动态表结构

问题表现：

展开

代码语言：Java

自动换行

AI代码解释

// Flink 官方 Sink 只能写入固定表
public class JdbcSink {
    private final String sql;  // 固定的 INSERT SQL
    public JdbcSink(String jdbcUrl, String sql, ...) {
        this.sql = sql;  // 硬编码的表结构
    }
}

带来的问题：

1. 多应用无法隔离：所有应用的数据写入同一张表，通过特定分表策略区分。
2. 扩展性差：新增应用需要手动建表，无法动态路由。
3. 性能瓶颈：单表数据量过大（百亿级），查询和写入性能急剧下降。

痛点三：分布式表写入性能问题

问题表现：

代码语言：Java

自动换行

AI代码解释

// 大多数生产实现直接写入分布式表
INSERT INTO distributed_table_all VALUES (...)

ClickHouse 分布式表的工作原理：

带来的问题：

1. 网络开销大：数据需要经过分布式表层转发，延迟增加。
2. 写入性能差：分布式表增加了路由和转发逻辑，吞吐量降低。
3. 热点问题：所有数据先到分布式表节点，再转发，造成单点瓶颈。