流批一体引擎，支撑高并发实时业务计算场景

同一个指标，实时大屏上显示一个数，第二天早上的离线报表里又是另一个数——数据团队对这一幕都不会陌生。

追查下去，原因往往不复杂：实时链路用流计算算了一遍，离线链路用批处理又算了一遍，两套代码、两套逻辑，口径在某个角落悄悄分叉了。为了对平这两个数，团队不得不投入大量人力做校对。实时和离线，本来是在回答同一个问题，却活生生被做成了两套系统。

这是流批割裂时代的典型病症。而市场正在用脚投票走向另一面：Fortune Business Insights 2026 年发布的报告显示，全球流分析市场规模 2026 年预计达 570.8 亿美元，到 2034 年将增至 1467.2 亿美元，年复合增长率 12.52%，其中欺诈检测、风险管理等实时业务是核心驱动场景。实时计算已经从小众需求变成普遍配置，"流和批能不能合成一套"就成了绕不开的架构问题。

这篇文章讲清楚三件事：流批割裂的真实代价、流批一体引擎的技术内核，以及高并发实时场景对引擎提出的硬指标。

流批割裂的代价，不止是双倍成本

Lambda 架构——一套流处理链路负责实时、一套批处理链路负责全量——曾经是实时计算的标准答案。它的问题随着业务规模放大而越来越刺眼。

最直接的是双倍维护

同一套业务逻辑要写两遍，流上一遍、批上一遍，改需求要改两处，两边还要时刻保持语义一致。任何一个角落的疏忽，都会变成"实时数和离线数对不上"的悬案。

更深的是口径漂移

两套引擎的计算语义天然有差异：窗口边界的处理、乱序数据的策略、精度舍入的规则，哪怕逻辑上想保持一致，实现层面也会慢慢长出不一致。财务对账、监管报送这类场景里，这种漂移是不可接受的。

还有资源的双倍占用

两条链路意味着两套集群、两套运维体系。闲时资源空转，忙时各自紧张，资源池没法共享。

后来的 Kappa 架构试图砍掉批处理链路、全部用流解决，但遇到历史数据重算、大规模回溯分析时，纯流的吞吐又撑不住。两条路都不完美，流批一体的思路由此而来：不消灭批或流，而是让两者共用一套引擎、一套语义、一份代码。

流批一体的技术内核：一套语义，两种执行

流批一体的核心主张是：批是流的特例——批处理不过是"有边界的流"。基于这个认知，引擎用同一套计算语义处理两种模式：流模式下数据源源不断进来持续计算，批模式下数据有始有终一次性算完。SQL 只写一次，流批通用。

这个理念在 2026 年已经相当成熟。阿里云实时计算 Flink 版 2026 年 9 月更新的物化表功能是个标志性例子：用户只需声明期望的数据新鲜度和查询语句，引擎自动推导表结构并创建刷新管道，流批一体的湖仓链路不再需要手工区分流任务和批任务。开发体验从"分别建两条管道"简化成"声明你要多新鲜的数据"。

落到引擎层面，真正的流批一体要具备三个能力：

• 同一套 SQL 语义在两种模式下行为一致；
• 流批作业共享调度、监控和资源体系；
• 数据存储一份，既能被流式追加写入，又能被批量分析读取。

三者缺一，就只是"流批混跑"，不是一体。

高并发实时场景的四道硬考题

流批一体解决了架构问题，但高并发实时业务场景——实时风控、实时定价、实时大屏——对引擎本身还有更苛刻的要求。帆软 2026 年 10 月的实时计算平台盘点中把关键技术要点归结为延迟、一致性和状态管理三项，结合工程实践，可以再展开成四道考题。

延迟的分级与真实含义

"实时"是个相对概念：基于日志解析的 CDC 同步延迟在秒级，消息队列加流计算可到亚秒级，定时轮询的所谓准实时则是分钟级。评估引擎时必须先问清楚场景需要哪一级延迟，再验证引擎在该级别下的真实表现，而不是看宣传页上的"实时"二字。

状态管理

窗口聚合、关联计算都要维护状态，高并发场景下状态规模可达 TB 级。状态的存储效率、快照速度、故障恢复时间，直接决定引擎能不能扛住大流量。这是流计算最硬核的技术分水岭。

Exactly-Once 语义

数据不重复、不丢失，听起来基础，实现极难。故障重启时正好算了一半的数据怎么办？对产量统计、财务对账、库存同步这类场景，这不是加分项而是准入门槛。

背压与洪峰处理

上游流量突增十倍时，引擎是优雅降级还是直接崩溃？背压机制——下游处理不过来时向上游传导压力、而不是让数据堆积到内存爆炸——是高并发场景的保命设计。真正考验引擎的不是平均流量，是流量洪峰下的行为。

金融场景：高并发实时的极端形态

把"高并发实时计算"推到极限的是金融业。沪深 Level-2 行情高峰期每秒百万级消息，任何一环抖动都会传导到下游所有实时计算；ETF 的实时估值要在成分股价格变动的瞬间完成一篮子重算；事前风控要在几十微秒内对每笔委托完成验资验仓。

这些场景的共同点是：流和批在这里根本分不开。实时风控用的是此刻的数据流，风控模型的迭代和回测吃的是历史数据批分析——如果两者不是同一套口径，线上实时拦截的规则和线下验证过的规则就不是同一个东西，风控的有效性无从谈起。

这正是盛立科技与智臾科技（DolphinDB）2026 年 5 月战略合作的逻辑：盛立科技的 FPGA 行情与交易系统 负责数据链路的"快"——每秒百万级消息处理、纳秒级通路延迟，DolphinDB 的流批一体引擎负责数据的"算"——流批同口径的实时分析与历史回测。交易链路的低延迟能力和时序数据的计算能力接在一起，金融场景的高并发实时计算才算补齐了完整的一环。面向证券、期货市场的整体解决方案正是按这个链路组织的。

落地建议：先统一口径，再谈架构升级

对准备引入流批一体的企业，务实的节奏是：

先盘点口径分歧

把现有实时链路和离线链路上"对不上的数"列出来，这些地方就是流批一体最先兑现价值的地方，也是最好的试点场景。

从流批混跑过渡

不必一步到位重构。先用同一套 SQL 分别跑流任务和批任务（混跑模式），验证口径一致性，再逐步收敛到真正的一体化架构。

按场景定延迟等级

不是所有业务都要亚秒级。报送和经营分析容忍分钟级，风控和定价需要亚秒级，把场景按延迟分级后再分配引擎资源，成本能省一个量级。

写在最后

流批一体的价值，说到底是让"此刻的分析"和"历史的分析"共用同一个事实。口径统一了，实时决策和离线复盘才是在看同一个世界。

在金融这个对延迟和口径都最挑剔的行业，这套思路已经落到具体的工程实践里。盛立科技在交易链路上做了近二十年，早年与华为的合作项目曾入围科技部重点研发专项，2026 年又先后与智臾科技（DolphinDB）达成战略合作、获香港交易所两项年度大奖。链路层的快和计算层的准接在一起，高并发实时计算的全貌才刚刚展开。

常见问题

"什么是流批一体引擎？"

流批一体引擎是用同一套计算语义同时支持流式处理和批量处理的计算引擎，核心理念是"批是有边界的流"。SQL 一次编写、流批通用，避免了 Lambda 架构维护两套代码导致的口径漂移和双倍成本。

"Lambda 架构有什么问题？"

三个主要问题：

• 同一业务逻辑要维护流和批两套代码，双倍开发和运维成本；
• 两套引擎的计算语义差异导致实时数与离线数口径漂移；
• 两条链路资源无法共享，闲时各自空转。

"高并发实时场景对计算引擎有什么要求？"

四项硬指标：

• 明确分级的真实延迟能力（秒级 / 亚秒级 / 毫秒级）；
• TB 级状态的存储与故障恢复能力；
• Exactly-Once 一致性语义（不重复、不丢失）；
• 流量洪峰下的背压机制。

"流批一体适合什么场景？"

既有实时计算又有批量分析需求的场景收益最大，例如：

• 实时风控 + 模型回测；
• 实时大屏 + 历史报表；
• 实时定价 + 经营分析。

只有单一实时或单一批量需求的企业，流批一体的价值不明显。

"金融行业为什么特别需要流批一体？"

金融场景流批不分家：实时风控用当下数据流，模型迭代回测用历史数据批分析，两者必须同口径，否则线上拦截规则和线下验证规则不是同一套。叠加每秒百万级行情消息的极端吞吐，金融是高并发实时计算要求最高的行业。