从批处理到实时流处理：数据架构演进与Flink实战踩坑全记录

ETL这块我做了快十年，从最早写SQL存储过程做每日凌晨批量同步，到后来用Sqoop拉数，再到现在团队全面转向实时数仓，中间踩过的坑可以说相当多。最近正好在做一次系统性的架构复盘，把从批处理到实时流处理的整个演进路径捋了一遍，发现很多决策回头看是对的，但也有不少弯路。这篇文章就把我个人的实战经验整理出来，从设计思路、组件选型到具体的踩坑记录，一次说清楚。

1. 为什么非要从批处理走向实时流处理

先说个很现实的场景。早些年做报表，业务方提需求都是“昨天全国的销售数据出来没有”，我们凌晨2点跑批，早上8点之前把T-1的数据准备好，大家皆大欢喜。但大概从2018年开始，运营那边开始频繁问“今天实时数据怎么样”“这个活动上线半小时了转化率多少”，批处理链路根本扛不住这种诉求。

批处理的本质是“按固定时间窗口拉取全量或增量数据”，它的延迟取决于调度周期，T+1是最常见的。就算你缩短到每15分钟跑一次增量，那也只能叫“微批”，离真正的实时还有距离。而且批处理链路越长，出问题的概率越大，凌晨跑批挂了，白天业务看的全是脏数据，排查起来痛苦得要命。

实时流处理的本质完全不同，数据一旦产生就立刻进入管道，经过处理、清洗、关联之后写入目标存储，延迟从“小时级”压缩到“秒级甚至毫秒级”。但这里要泼一盆冷水：实时流处理不是银弹，它的复杂度、运维成本、数据一致性挑战都比批处理高一个量级。所以架构演进的核心不是“把批处理扔掉换成流处理”，而是让两条链路共存，按业务场景选择合适的技术路径。

我个人的判断标准很简单：如果业务对数据延迟的容忍度在小时级以上，批处理仍然是成本最低的方案；如果延迟要求在分钟级甚至秒级，就必须上实时链路；如果是“既要又要”的场景，那就走Lambda架构，实时和批量双跑，最终在服务层做合并。这个判断标准，我在下面整体设计里还会细说。

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的同学上手压力小很多，这是个非常实际的选型收益。

2.3 数据管道设计：为什么选Kafka作为中枢

实时链路里消息队列是绝对的中枢，我们选的是Kafka，这个基本没什么悬念，它已经是事实标准。我们的设计是：业务库 -> Canal/Debezium -> Kafka Topic（ODS层）-> Flink消费 -> 处理 -> 写Kafka（DWD层）-> Flink消费 -> 汇总 -> 写Doris/ClickHouse（ADS层）。

Kafka在这里做了两件事。第一是削峰填谷，业务大促时流量瞬间上来，Flink消费能力跟不上没关系，Kafka先扛着，消费者按照自己的节奏处理。第二是解耦，上游只需要保证写入Kafka，下游的Flink任务、实时数仓的写入任务各自独立演进，互不阻塞。

这里有个很多人容易犯的错：以为Kafka里Topic建得越多越好，结果Topic爆炸到几百个，管理成本巨大，而且监控报警根本看不过来。我们的经验是Topic按“业务域+数据等级”来划分，同域的表尽量合并到同一个Topic或者同一个Topic的多个分区里，用表名做消息的key去路由，这样既保证了吞吐，又控制了运维复杂度。

3. 核心环节拆解与实操实现

3.1 实时链路的完整架构图景

我画一下我们最终落地的那版架构（这里不放图，文字描述清楚）：

数据源层：MySQL（业务主库）、Redis（缓存）、埋点日志（Nginx -> Kafka）
采集层：Canal监听MySQL binlog，日志用Logstash/Filebeat采集
消息层：Kafka，按域拆Topic，分区数按流量预估
计算层：Flink 集群（YARN/K8s部署），主要跑实时ETL、维度关联、窗口聚合
存储层：Kafka（临时结果）-> Doris（明细/汇总），部分场景用Redis做维表缓存
服务层：数据服务API，实时大屏，OLAP分析，报警触发

这套链路从源端到存储端，端到端延迟正常情况下在3到5秒之间。如果你的业务链路比这个简单，比如只是把MySQL的数据同步到ES或者ClickHouse，那甚至不需要走到Flink，直接用Canal写MQ、然后通过Connector到存储就行，没必要把架构搞得过大。这个“拒绝过度设计”的原则，后面我还会强调。

3.2 采集层：Canal消费binlog的细节与坑

Canal这个东西，本质是把自己伪装成MySQL的从库，然后接收binlog事件流。我们最开始踩过最狠的一个坑是binlog格式没设置对——MySQL必须设置binlog_format=ROW才能拿到完整的前后镜像，否则你只有SQL语句，根本没法精确知道哪一列被改成了什么值。

另外，Canal的位点（offset）管理极其重要。默认Canal会记录自己消费到binlog的哪个位置，但如果服务器重启、或者你手动做数据订正时误删了位点元数据，那就会导致要么重复消费，要么跳过一段数据。我们在生产环境做了两件事：一是定期把位点信息备份到外部存储，二是每次发布Canal客户端版本前，强制核对位点一致性。

再说Debezium和Canal的选择。如果你们是Java技术栈为主，用Canal确实更顺滑；如果是异构技术栈，Debezium在Schema演进和社区活跃度上要更好一些。对我们来说Canal足够稳定，所以一直没换。这里提醒一句，不管用哪个，对源库的权限控制一定要严格，毕竟binlog里是全量字段值，属于敏感数据，需要走审批流程。

3.3 计算层：Flink作业的核心参数配置

Flink作业写起来本身不算难，难的是参数调优和生产环境稳定性。我们每个实时ETL任务的模板参数大致如下：

yaml复制job.name: ods_to_dwd_order_detail
parallelism.default: 8
state.backend: rocksdb
state.checkpoints.dir: hdfs:///flink/checkpoints
state.checkpoint.interval: 60s
state.checkpoint.min-pause: 30s
state.checkpoint.timeout: 10min
restart-strategy: fixed-delay
restart-strategy.fixed-delay.attempts: 3
restart-strategy.fixed-delay.delay: 10s
execution.checkpointing.mode: EXACTLY_ONCE

这里几个参数为什么这么设，我补充下思考逻辑。

并行度8是根据我们单topic的分区数定的——Kafka一个分区最多被一个并行度消费，如果你并行度大于分区数，多出来的并行度是空的，白白占用资源。RocksDB作为状态后端，是处理大状态场景下的理性选择，因为内存状态后端在状态量超过可用内存时会出现Full GC甚至OOM。Checkpoint间隔60秒，既保证了恢复粒度不会太粗，又不会因为频繁checkpoint导致性能下降。EXACTLY_ONCE模式必须开，财务对账、库存扣减这类场景不允许重复计算。

常见问题是：Flink任务重启后状态恢复失败。这类问题九成出在checkpoint目录的权限、或者任务拓扑对算子UID的修改上。所以上线前我们强制要求：所有算子必须显式设置uid，否则代码一改，算子uid变了，状态根本对不上。

3.4 存储层：Doris写入的调优与降级

实时计算完的结果最终要落到查询快的存储上。我们调研过ClickHouse和Doris，最后选了Doris。原因很朴素：Doris对主键更新模型支持得更好，适合实时链路上频繁的upsert场景；而且Doris的MySQL协议兼容性好，后端做BI报表的人员几乎零学习成本。

写入Doris的Flink连接器配置里，有几个参数很关键：

yaml复制sink.properties.column_separator: '\t'
sink.properties.max_bytes_per_row: 4194304
sink.enable.batch-mode: true
sink.max-retries: 3

批模式必须打开，否则每条数据都发一次HTTP请求到Doris的FE节点，吞吐会非常难看。批量提交的SIZE一般控制在1000到5000行之间，或者攒够一定时间（比如5秒）统一刷一次。这个参数要结合你们下游查询的实时性来权衡——刷得太频繁，Doris导入小文件太多影响查询性能；刷得太慢，数据可见性延迟加大。

另外一定要配置好降级方案。我们有一次Flink任务因为Doris集群滚动升级，短暂不可用，结果整个实时链路都阻塞了。后来加了重试和熔断机制，当Doris连续失败达到阈值时，数据先写到一个备份Kafka Topic，等Doris恢复后再回放。这一步对保障整体可用性非常重要。

3.5 从批处理到双跑的平滑迁移路径

很多人以为架构演进是一次性切换，其实最稳妥的方式是双跑。我们当时花了整整一个多月时间，让批处理和实时链路同时运行，每天对账。

操作步骤大概是这样的：

1. 选取一条核心链路做试点，比如订单事实表。
2. 保留原有批处理任务不动，新起一套实时Flink任务。
3. 每天凌晨跑完批处理后，写一个对账程序，对比批处理产出的结果表和实时链路产出的结果表，做全量或抽样比对。
4. 差异低于阈值（比如万分之五）后，才把报表服务的数据源逐步切到实时结果上。
5. 实时链路稳定运行两周后，再下线对应的批处理任务。

这个过程中最大的坑在于窗口边界。批处理常用自然日作为分区，而流处理用事件时间窗口，两者天然存在对不齐的问题——23:59:59进来的事件，批处理可能算在今天，流处理可能算在明天。最后我们统一规定：以事件时间为准，允许迟到5秒，超过5秒的数据走侧输出流做修正，这样两边才能对上。

4. 性能调优与成本控制经验

4.1 从资源利用率反推并行度设置

关于并行度，我上面已经讲了一点。这里再补充一个我自己常用的估算公式：单个Kafka分区平均写入速率 * 单条数据经过处理的CPU耗时系数 / 单核处理能力 ≈ 需要的并行度。这是一个粗略公式，实际操作中还要考虑状态大小和反压情况。

如果Flink UI上看到某个算子反压百分比长期超过80%，基本说明这个算子成了瓶颈。首先检查是不是并发度太低，如果不是加并行度能解决的，就要看是不是数据倾斜——Key分布严重不均会导致某个子任务特别忙，其他子任务空闲。我们遇到过一次订单表按用户ID做key，结果某个大客户的数据量比普通用户高了三个数量级，那个子任务直接被打爆。解决方案是用“用户ID+随机数”做加盐key，先做局部聚合，再按真实key做全局聚合。

4.2 资源成本怎么压下来

实时链路比批处理贵，这是共识。但很多成本是可以优化的。

第一，按流量削峰调度Flink任务。比如夜间流量低，可以把一些非核心的实时任务并行度调小，白天再调大。这个我们用K8s的HPA加自定义指标实现，Flink的弹性伸缩在K8s上比YARN上要好做很多。

第二，数据压缩不能省。Kafka的Topic开启压缩（lz4或zstd），Doris导入也用压缩传输。压缩率通常在4到5倍之间，对传输带宽和存储成本改善非常可观，对CPU的额外开销几乎可以忽略。

第三，冷热数据分离。实时数仓的明细数据，超过一定时间（比如30天）就转到对象存储，查询频率低的数据没必要一直占着Doris的高性能存储资源。Doris本身支持冷热分层，把冷数据放到S3或者HDFS上，成本能省一大截。

4.3 延迟目标拆解：每个环节该花多少时间

要保证端到端延迟5秒内，需要知道时间都花在哪里。我们当时实测的延迟分布大概是这样：

如果哪一天端到端延迟突然到了10秒以上，我会按这个链路逐段排查。最常见的超时点是Doris导入堆积和Flink背压。另外要特别强调，端到端延迟指标必须和吞吐量指标放在一起看，否则会出现一种假象：延迟很低，但吞吐低得可怜，完全是空转。

5. 实战中的常见问题与避坑手册

5.1 数据重复怎么处理

实时链路不可避免会遇到重复消费。Kafka at-least-once语义下，消费者宕机重启，可能会重复拉取部分数据。如果目标存储没有去重机制，就会出现数据翻倍。

我们的处理方式是分场景：

• 场景一：Doris主键模型。主键相同的数据会覆盖，天然去重，所以写Doris的链路不太担心重复。但是要注意，如果你的写入顺序乱了，旧数据覆盖新数据，那就麻烦了。所以对于有状态的计算，Flink要保证数据按事件时间有序输出，不能简单按处理时间写出去。
• 场景二：写入Redis做计数。这种场景必须用Lua脚本做原子性的“先读后写”或者直接用INCRBY这种原子命令，避免并发加两次。

5.2 字段变更和Schema演进

实时链路里最恶心的就是上游表加字段或者改字段类型。批处理可以今天改了明天全量重跑，实时链路可没法回溯。

我们的做法是：

1. 消息统一封装一层“变更事件”，里面包含schema_version字段。
2. Canal采集到变更时，先对比schema_version，如果发现版本不一致，新的数据打标放到“待处理缓冲区”，同时触发一次全量订正。
3. 全量订正用批处理的逻辑把离线表重建一遍，然后基于快照再把增量追平，最后重新启用实时链路。

这个方案保证数据不丢不乱，但需要额外开发一些代码，不过我认为这套机制是必须的。没有它，你随时可能被一次上游加字段搞得焦头烂额。

5.3 数据倾斜与热点问题

上面提到过Key加盐解决倾斜，这里再补充一个案例。我们有一个实时大屏统计各城市订单量，结果北上广深四个城市占掉了80%的数据流量。如果直接按城市分组做窗口聚合，那四个子任务长期瓶頸，其他几十个子任务空闲。

解决方法是：第一层按“城市+随机数”做预聚合，第二层再按“城市”做最终聚合。通过这种两阶段聚合方式，热点被均匀打散到了所有子任务上。这个思路和MapReduce里的Combine非常像，处理热点问题永远有效。

5.4 监控告警体系搭建

实时链路比批处理更需要监控，因为它是7x24小时跑的。监控指标我建议至少包含下面这些：

• Kafka消费积压量：消费者Lag超过阈值就报警，这是最直接的健康指标。
• Flink Checkpoint耗时和成功率：成功率连续低于阈值说明任务已经处于不健康状态。
• Flink反压指标：长时间反压意味着处理能力跟不上。
• Doris导入失败率：如果导入任务连续失败，必须立刻排查。
• 端到端数据延迟：用数据自带的时间戳和到达目标时间戳做差，这个指标最贴近业务感知。

报警渠道我们用的是钉钉机器人和电话告警，晚上只推P0级别告警，否则太频繁没人看，狼来了喊多了就失效了。这点做运维的同学都懂——告警不是越多越好，而是越准越好。

5.5 常见问题速查表

6. 架构演进的落地顺序建议

如果你也想做从批处理到实时流处理的演进，不要一上来就铺开全部链路，我建议按这个顺序推进：

1. 先跑通一条最简单的链路：MySQL -> Canal -> Kafka -> Flink -> Doris。目的不是实现多复杂的业务逻辑，而是让团队把每环的部署、监控、报警都跑熟。
2. 再选择1到2个核心业务场景做试点，比如实时订单大屏、实时库存监控、实时风控。边做边积累经验，形成团队内部的标准模板和踩坑文档。
3. 然后把标准模板推广到更多业务域，同时逐步建设数据质量监控、全链路对账、资源成本管理这些配套能力。
4. 最后再考虑是否要在批处理侧做减法，关停部分离线任务。这里一定要谨慎，很多旧链接还承担着历史数据修复和全量对账职责，不能盲目下掉。

从组织角度来说，实时化改造不只是技术问题，还涉及数据团队和使用方的工作方式变化。业务方以前看T-1报表，现在要接受实时链路的数据可能偶尔抖动一下，这个预期管理也很重要。

7. 最后分享几个我在实操中反复强调的细节

第一，修改Flink作业时永远不要改动算子uid。哪怕你只是重构了一下算子逻辑，只要uid变了，状态就对不上了。这个坑我踩了不止一次，现在团队代码评审里专门有一条就是检查uid。

第二，Kafka Topic的分区数要预留余量。分区数是创建后不能轻易减少的，而后期的并行度提升又依赖分区数，所以宁可建的时候多建一点，也不要后面想扩容发现分区数不够，那就要重建Topic，麻烦得很。我们线上核心Topic的分区数都是预估值的三倍。

第三，Doris的表模型要提前选好。Duplicate、Aggregate、Unique三种模型各有用途。实时明细查询用Duplicate，汇总指标用Aggregate，更新的业务实况用Unique。如果表已经建好再改模型，那是很痛苦的事情。这个和离线数仓建模是一样的逻辑——模型选型决定了下游所有应用的开发体验。

第四，建议每个实时任务上线前都做一次故障演练。比如把Kafka集群某个broker直接杀掉、把Doris FE节点重启一次，看任务能不能自动恢复，数据会不会丢。演练时候的样子，就是将来真实故障的样子，提前练过至少心里有底。

从批处理到实时流处理，我最大的感受是：架构演进没有一劳永逸的方案，只有不断根据业务需要去调整平衡点。批处理不会消失，流处理也不是万能，两者协同才能构建一个真正稳健、灵活的数据架构。希望这篇文章能帮你少踩一些坑。