Tim ShenETL这块我做了快十年，从最早写SQL存储过程做每日凌晨批量同步，到后来用Sqoop拉数，再到现在团队全面转向实时数仓，中间踩过的坑可以说相当多。最近正好在做一次系统性的架构复盘，把从批处理到实时流处理的整个演进路径捋了一遍，发现很多决策回头看是对的，但也有不少弯路。这篇文章就把我个人的实战经验整理出来，从设计思路、组件选型到具体的踩坑记录，一次说清楚。
1. 为什么非要从批处理走向实时流处理
先说个很现实的场景。早些年做报表，业务方提需求都是“昨天全国的销售数据出来没有”，我们凌晨2点跑批，早上8点之前把T-1的数据准备好，大家皆大欢喜。但大概从2018年开始，运营那边开始频繁问“今天实时数据怎么样”“这个活动上线半小时了转化率多少”，批处理链路根本扛不住这种诉求。
批处理的本质是“按固定时间窗口拉取全量或增量数据”，它的延迟取决于调度周期，T+1是最常见的。就算你缩短到每15分钟跑一次增量，那也只能叫“微批”，离真正的实时还有距离。而且批处理链路越长，出问题的概率越大，凌晨跑批挂了，白天业务看的全是脏数据，排查起来痛苦得要命。
实时流处理的本质完全不同，数据一旦产生就立刻进入管道，经过处理、清洗、关联之后写入目标存储，延迟从“小时级”压缩到“秒级甚至毫秒级”。但这里要泼一盆冷水：实时流处理不是银弹，它的复杂度、运维成本、数据一致性挑战都比批处理高一个量级。所以架构演进的核心不是“把批处理扔掉换成流处理”，而是让两条链路共存，按业务场景选择合适的技术路径。
我个人的判断标准很简单：如果业务对数据延迟的容忍度在小时级以上，批处理仍然是成本最低的方案；如果延迟要求在分钟级甚至秒级，就必须上实时链路；如果是“既要又要”的场景，那就走Lambda架构，实时和批量双跑，最终在服务层做合并。这个判断标准，我在下面整体设计里还会细说。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体设计与方案选型的底层逻辑
2.1 先盘点旧架构到底卡在哪里
我们团队原有的批处理架构，简单描述就是这样一条链：业务库MySQL/Oracle -> Canal监听binlog（其实到后期才引入的）-> 定时Sqoop或DataX抽取 -> 落地到Hive分区表 -> 调度系统（Azkaban）编排任务 -> 数仓分层（ODS/DWD/DWS/ADS）-> 报表服务读取。
这个架构在数据量每天几百万、几十张表的阶段非常稳定。但一旦业务量上来，几个痛点会变得特别突出。
第一是调度依赖复杂。Azkaban上挂着上千个任务，任务之间互相依赖，某一张源表的人为变更可能导致下游整个链路重跑。第二是数据延迟固定。不管紧急不紧急，都得等下一个调度周期。第三是资源利用率不均衡，凌晨集群资源被占满，白天资源又空转。第四是排查问题困难，链路又长又深，一个字段解析错误要一层一层往下找。
所以当初做架构演进，第一个动作不是急着引入Flink，而是把问题清单拉出来，按影响面分类。只有明确了旧架构哪些痛点是不可忍受的，才谈得上设计新架构。
2.2 技术选型对比：Flink、Spark Streaming还是Kafka Streams
这一节我直接给结论和比对，因为网上讲原理的都很多，我讲讲实际选型时怎么取舍。
- Flink：状态管理强、精确一次语义（exactly-once）支持好、窗口机制灵活，适合复杂的事件处理、实时数仓分层加工。缺点是学习曲线陡，运维成本偏高。
- Spark Streaming：本质是微批，吞吐量大，能和Spark生态无缝衔接，但延迟最低也在秒级，做不了真正的逐条事件驱动。如果你团队Spark已经很熟，对延迟要求是秒级而不是毫秒级，选它也没毛病。
- Kafka Streams：轻量级流处理库，不依赖独立集群，部署在业务服务内部。它适合处理相对简单的流式逻辑，但它偏“库”而不是“平台”，如果要做复杂的多流join和窗口聚合，维护成本会变得很高。
我们最终选了Flink，核心理由有两条：一是我们的实时场景确实需要精确一次语义，比如交易金额、库存扣减这类数据绝对不能重复计算；二是我们规划了实时数仓分层，Flink SQL在分层加工上写起来比DataStream API高效太多。这里补充一下，Flink SQL上线之后，团队里原来写惯了Hive SQL的同学上手压力