大讲堂
上周跟某城商行的数据中心负责人喝酒，他吐槽到一半把杯子顿得哐当响：”去年花300万上的实时数仓，到现在一半的任务还是跑批，合着我钱花了，两套代码还是各管各的？”
这不是个例。
从2016年Flink开源把实时计算的门槛打下来开始，”流批一体”这个词就在行业里转了快8年。从最早的技术圈沙龙，到后来厂商的发布会，再到现在企业的招标要求，好像谁家没个流批一体的方案，都不好意思说自己是做数据的。但真落地的有多少？
别被厂商的宣传骗了，流批一体根本不是”写一套代码跑所有”
很多人对流批一体的认知，从一开始就歪了。
传统架构里，流处理和批处理是完全割裂的两套系统：流处理负责算实时的、有时间窗口的增量指标，比如当前每分钟的直播间GMV；批处理负责算全量的、精度优先的历史指标，比如上个月的全平台用户留存。两套系统用不同的计算引擎，不同的存储路径，甚至连元数据的字段定义都不一样。
你要问业务部门最烦什么？永远是两个系统算出来的数对不上。实时看板显示今天上午卖了1200万，下午离线复盘跑出来是1170万，差了30万，谁也说不清楚差在哪——流引擎会丢一部分网络抖动产生的日志，批引擎能从冷存储里把这些日志捞回来，两边的口径从根上就不一样。
那什么才是真的流批一体？
不是给原来的Flink引擎套个”支持批任务”的壳，也不是把Spark和Flink的界面凑到一个控制台里就算打通。真正的流批一体，是底层存储、计算引擎、元数据管理三个层完全无边界打通——同一份存在湖仓里的数据，你要算毫秒级的实时指标，直接拉增量窗口跑；要算全量的历史复盘，不用导数据、不用改代码，直接在同一张表上跑批。最核心的校验标准特别简单：同一段业务逻辑的代码，不做任何参数调整，既可以输出低延迟的实时结果，也可以跑出和离线全量计算精度完全一致的结果。
听着简单。
多少厂商现在的所谓流批一体，本质上还是”流批拼接”——实时任务扔给Flink跑，批任务扔回Spark跑，最后在控制台做个统一的展示界面，就算给客户交差了。算出来的数差个1%-2%是常事，业务部门根本不敢拿这个数做决策。
现在吹得最凶的赛道，其实卡在最不性感的环节
这两年流批一体的技术进展其实不算慢。从最早的引擎层打通，到现在的湖仓一体存储配套，头部厂商的计算性能已经摸到了瓶颈上限——同样的计算量，比5年前的架构快了至少10倍，资源成本降了60%。
但为什么大部分企业还没落地？
因为卡点根本不在计算性能上，在最不性感的历史数据迁移上。
举个最现实的例子：某头部电商平台攒了6年的用户行为日志，存在老的HDFS集群上，中间因为业务迭代改了19版表结构，元数据散在13个不同的业务系统里，甚至有3张核心表的口径，已经找不到当年写代码的人了。要把这些数据迁到统一的湖仓存储层，光做数据清洗、口径对齐、异常值排查，就得拉2个数据团队干8个月。
成本不低。
但真跑通的客户，收益也是实打实的。比如某头部外卖平台，之前算实时订单超时率，是流引擎跑实时指标，批引擎每天凌晨跑前一天的全量数据做校验，两边的数经常差1.5%——流引擎捞不到那些因为弱网没上报的用户点击日志，批引擎能从冷存储里把这些日志补回来。打通流批一体之后，流任务直接用批的全量历史数据做自动校准，现在每天的实时指标和离线校验的误差压到了0.1%以内，光这一项就省了2个专门做数据对账的运维团队，一年省下来的人力成本就有200多万。
不过话说回来，这种级别的落地，根本不是中小公司能玩得起的。你连自己有多少张核心业务表、每个表的字段是啥都说不清楚，谈什么流批一体？
落地的坑，从来不是技术问题，是组织问题
很多人以为上了流批一体平台，只要技术团队把系统搭好就完事了。错。
我见过至少5家企业，花了几百万上了流批一体平台，最后用不起来，本质上是组织架构没跟上。
原来的团队怎么分？实时计算团队算实时指标，归技术中心管；离线数仓团队算离线指标，也是归技术中心管。两个团队本来就各算各的KPI，平时交集不多。现在要把流和批的流程打通，首先遇到的冲突就是能力不匹配：实时团队的开发习惯是快速迭代，代码能跑就行，经常因为写的任务不规范把集群跑挂；离线团队的开发习惯是写一次性的跑批脚本，从来没考虑过高可用、低延迟的要求，现在要写能同时跑实时任务的代码，完全是两套能力模型。
之前接触过的某区域零售企业，去年硬上了流批一体平台，一开始直接把两个团队合并成了”统一计算组”，结果半年内走了3个核心开发——离线团队的老员工根本适应不了实时开发的要求，写的任务上线就报错，实时团队的年轻人又受不了离线团队繁琐的评审流程，提个需求等一周。最后平台还是拆回了两套系统，钱打了水漂。
现在真正把流批一体用出价值的行业，其实特别集中：电商的大促实时监控、金融的实时反欺诈、物流的动态路径调度。这些行业的共同点是，数据驱动已经刻到业务流程里了，实时数据的价值能直接换算成收入。反而很多传统制造业，花了大价钱上系统，最后就是把原来每天跑一次的生产报表，改成每5分钟跑一次，根本没挖掘到实时数据的增量价值，纯粹是为了追技术热点而上系统。
对吧？
当然，流批一体不是万能药，坑真的不少。
第一个坑是数据合规风险。原来流处理和批处理是两套权限体系：实时数据是开放给一线业务部门看的，权限管控松；离线数据是锁在数仓核心区的，只有核心开发能看。现在系统打通之后，如果权限配置没跟上，很容易出现普通员工直接拉到全量用户敏感数据的情况，这个合规责任，谁也担不起。
第二个坑是资源抢占的跷跷板效应。比如大促当天，实时任务要占70%的集群资源，本来计划跑的月度财务报表批任务，就会被挤到队列后面，延迟十几个小时才能出结果。之前某社交平台就出过这个事：大促当天实时监控任务把集群资源吃满，导致第二天的用户月度账单晚了8小时发送，收到了几万条用户投诉。
聊到最后，很多人问我，流批一体接下来3年到底会成啥样？
说三个实在的判断，不吹不黑。
第一，流批一体永远不会是所有公司的必选项。年营收10亿以下的公司，根本没必要折腾——你一年的总数据量，还没人家一个大促的实时增量数据多，用个MySQL加个定时任务就能搞定所有报表需求，上了流批一体纯属给自己增加运维负担。
第二，未来3年的竞争核心，根本不是谁的计算引擎跑得快。客户真正愿意掏钱的，是能帮他降低迁移成本的工具——能不能不中断现有业务，把老集群的历史数据平滑迁到统一存储层；能不能把原来写了好几年的Spark、Flink代码，自动转换成兼容流批一体的格式，不用让客户的开发团队从头写一遍代码。这才是能拿到订单的关键。
第三，最后能在这个赛道跑出来的玩家，肯定不是纯技术出身的团队。你光给个计算引擎没用，得能给客户配套对应的组织流程改造方案——怎么拆团队，怎么定统一的指标口径，怎么平衡实时任务和批任务的资源占比，怎么规避之前踩过的坑。不然就算你的技术参数再好看，客户用不起来，也是白搭。
技术从来都不是目的。
能帮业务真的省钱、真的少出错，才是真的有用。
作者|大讲堂
排版|大讲堂
审核|阿辰