大数据开发都在卷实时计算，但批处理才是你该深耕的方向？

打开招聘软件，你会发现大数据开发岗位要求里永远逃不开 Flink、Kafka、Spark Streaming。各种技术社区里也全是"实时数仓终将取代离线数仓"的论调。我自己做大数据开发六年，从 Hadoop MapReduce 干到 Spark，再被迫去啃 Flink，说实话见过太多团队一窝蜂上实时计算，结果做出来的东西既不稳定又不省钱，最后灰溜溜迁回批处理。这不是说实时计算没用，而是大多数业务场景根本不配用实时计算。

我当年在杭州一家电商公司做数仓，领导看见隔壁部门搞了个实时大屏，非让我们也做一套。结果呢？Kafka 消息积压、Checkpoint 失败、状态后端内存爆炸，运维同学每天半夜被报警叫醒。折腾了三个月，压测数据延迟从150ms漂到6秒，业务方反而说还不如直接用离线报表，反正他们看的是日报。后来我们冷静下来分析，真正有实时需求的不过是几条核心链路，比如订单异常监控、秒杀峰值看板，剩下的离线 T+1 完全够用。实时计算的隐性成本很多人根本不会算：除了要维护一套更复杂的集群，还要处理乱序数据、延迟数据、精确一次语义，这些都会消耗大量的人力去调优和排查。

很多人觉得批处理简单，其实是把"跑数"和"写逻辑"混为一谈了。批处理真正的难点在于数据质量的血缘治理和分区策略的合理设计。我见过最离谱的同事，写一个 Spark SQL 把历史全量数据每天都重跑一遍，没有分区过滤，跑一个任务要1小时40分钟，40亿条数据硬扫，而且从来不校验数据量。后来我帮他改成按天分区增量加 merge，跑完只要11分钟，再加上源表行数和目标表行数的比对，以及主键唯一性校验，失败时自动告警。你觉得这些很基础？可大多数项目恰恰死在基础问题上。批处理这个"慢"反而给了你去审视数据质量的时间——你可以在跑完凌晨的任务后，检查这一天的数据是否比昨天少了12%，可以回溯某张明细表里业务类型code是不是被上游改了含义，这些在实时管道里完全做不了，因为太迟了。

再聊聊流批一体被吹上天的事。Flink 官方说用同一套 SQL 逻辑跑流和批，听着很理想，但实际你切换执行模式时看看自己的 SQL，是不是暗藏了许多隐式状态依赖？比如你用 Proctime 做窗口，批模式下到底拿什么当时间？比如你写了 left join 一个维表，流模式必须开 lookup join 加 ttl，批模式倒是无所谓，但你能保证结果语义一致吗？我参与过一家金融公司的流批一体改造，最后连负责这个项目的架构师都承认，他只是为了在技术汇报上有个词可以讲。业务系统里真正的痛点是 Kafka 中的消息吞吐峰值是平时的15倍，而离线清洗出的宽表又晚点了3小时，因为上游接口在凌晨2点超时重试。这些事，不靠调参，靠你的架构取舍能力。

所以我的观点很反主流：如果你刚入行，不要急着学 Flink 的 state 和窗口高级用法。老老实实把 Spark 批处理做到极致——学会处理维度表缓慢变化，学会设计均衡的桶数，学会写干净的反压驱动的存储过程，甚至学会用 Python 脚本补数据。只要你能把一张24小时产出的大宽表压缩到2小时内且正确率到达99.99%，你就有资格去谈论实时化。实时计算只是把批处理中你了解的那部分语义压缩到几百毫秒内再实现一遍，而你连离线语义都搞不清楚的话，实时做出来就是车祸现场。我见过某公司的实时订单金额比线下订单金额每天少2万块，原因是浮点精度和去重逻辑在流处理里用了不同的状态，这类问题，批处理只需要一个 group by 就能规避。

最后建议你选方向时，看看自己所在行业的业务性质。如果你是做游戏运营数据，那实时推荐偏重，用户在线时长统计必须用流计算；如果你是做银行对账或人力资源薪酬，T+1 的批处理加严格质量校验，反而能避免法律风险。千万别被厂商的白皮书带着走。我并不是贬低实时，而是希望你别盲目跟风。大数据开发行业里最稀缺的不是会写 Flink 的人，而是能判断哪些数据应该放弃秒级产出、哪些任务值得上实时却没人敢拍板的人。这个判断力，只能在批处理的单调日常中慢慢沉淀。