获课：xingkeit.top/5570/

跨越实时与交互的鸿沟：Structured Streaming双写MySQL与ClickHouse的架构哲思

在流计算的世界里，Apache Spark的Structured Streaming（结构化流）像是一个被严格约束的“永动机”——它用DataFrame的静态语义，去封装底层无底洞般的实时数据流。然而，在真实的业务落地中，最折磨人的往往不是流计算逻辑本身，而是“水流”停下来之后的去向。当我需要在实战中将实时数据同时同步到MySQL和ClickHouse时，我深刻体会到：这绝不仅是配置两个Sink（输出端）的技术问题，而是一场关于数据一致性、系统容错与资源博弈的架构修行。

首先，我们需要打破一个认知幻觉：Structured Streaming提供了优雅的端到端Exactly-Once（精确一次）语义，但这其实是个“局部真理”。这种精确一次，仅仅保证在Spark内部的微观批处理中，数据不会因为重试而重复计算。一旦数据要跨出Spark的边界，写入外部系统，神坛就跌落了。

在双写MySQL和ClickHouse的场景中，这是最让人头疼的痛点。为什么我们要同时写这两个系统？从业务视角看，它们承担着截然不同的使命：MySQL代表着“状态的锚点”，我们需要它来存储实时计算的最新聚合结果（比如某个商品的当前秒杀库存），以支撑高频的、强事务的上下游查询；而ClickHouse则代表着“历史的切片”，它需要源源不断地接收明细数据或预聚合数据，以支撑BI大盘复杂的多维实时分析。

在我的实战哲学中，面对这种“一拖二”的异构输出，最愚蠢的做法就是直接在同一个流里开启两个独立的ForeachBatch Writer，让Spark傻傻地先写MySQL，再写ClickHouse。这种“无脑双写”看似简单，却埋下了巨大的隐患。如果MySQL写入成功，但ClickHouse因为网络抖动或者Part合并失败报错，Structured Streaming的任务就会回滚重试，导致MySQL中可能出现脏数据或者不一致的状态。

为了破解这个死局，我个人的核心主张是：将“计算态”与“持久态”解耦，引入可靠的“跳板”。

在具体的实战路径上，我逐渐摒弃了直接对接业务库的做法，而是让Structured Streaming将处理后的数据，以微批的形式，优先写入一个高可用的消息队列（如Kafka）作为中间层。这个中间层不仅是数据的缓冲带，更是Exactly-Once语义的物理化身。随后，通过Flink CDC或者独立的消费者服务，分别从Kafka消费数据写入MySQL和ClickHouse。

你可能会问，这不是多绕了一圈吗？但这正是架构中的“退一步海阔天空”。通过引入中间层，我们剥夺了Spark直接操控异构数据库的权力，把一致性校验的重担转移到了更擅长处理消息去重的下游服务上。对于MySQL，我们可以结合业务主键做INSERT ON DUPLICATE KEY UPDATE；对于ClickHouse，我们可以利用其ReplacingMergeTree引擎在后台异步去重。

其次，在直接对接的层面，必须深刻敬畏两个系统的物理性格。MySQL是行级数据库，极其害怕高频的小批量写入，在ForeachBatch中，我必须手动控制写入频率，积累到一定条数后使用JDBC Batch批量提交，否则会瞬间打垮数据库的连接池和磁盘IO。而ClickHouse恰恰相反，它天生为海量批量写入而生，但它又极其讨厌频繁的小文件Part产生。因此，在向ClickHouse输出时，不仅要攒批，还要精心调控微批的间隔时间，确保每次写入都能在ClickHouse底层形成足够大的Data Part，避免触发令人闻风丧胆的Merge风暴。

回过头来看，Structured Streaming整合MySQL与ClickHouse的实战，本质上是在回答一个经典的分布式命题：如何让数据在流转中既保持实时的敏捷，又具备落盘的沉稳。它教会我不再盲目迷信单一计算引擎的无所不能，而是接受不同存储系统的物理局限，用“异步解耦”和“批量妥协”的智慧，在实时的风暴与事务的严谨之间，架起一座真正坚固的桥梁。