砍掉61分钟延迟，外卖巨头省了57%

61分钟和1.2秒之间，隔着一整套数据架构的代际更替。

Delivery Hero，全球最大的外卖配送平台之一，把广告效果度量管道从小时级批处理整体迁移到了 Amazon Managed Service for Apache Flink 上。结果有两句话：事件发生到被记录的间隔，从61分钟压缩到1.2秒；月度运维成本下降约57%。一个讲体验，一个讲钱包，两个数字凑在一起，比任何‘实时数仓白皮书’都更有说服力。这篇文章就拆一拆：这61分钟是怎么省下来的，实时化为什么反而更便宜，以及它对整个数据基础设施市场意味着什么。

📋 先把事实和推演摆清楚

在拆解之前，先交代信息边界。本文案例数据来自 AWS 官方客户案例（Delivery Hero × Amazon Managed Service for Apache Flink）【信源1】，以及 Delivery Hero 工程团队的公开技术分享【信源2】。为避免“案例神话化”，先把能确认的事实和属于本文推演的部分分开：

下面进入正文。凡属推演，行文以“可以推演”“合理的解释是”“据从业者反馈”等表述明确区分。

🚀 广告预算等不起一个小时的批处理

任何一个在外卖平台投过广告的商家，都体验过那种‘盲投’的焦虑。

广告位竞价是分钟级的事：中午11点的 lunch rush，一条广告素材在首页入口跑得好不好，10分钟内就见分晓。可如果效果数据一小时才出一版，投手的每一次出价调整，参考的都是上一个小时的世界。高峰期一个小时足够烧掉一天的预算，等报表刷新发现某个渠道ROI崩了，钱已经花完了。

Delivery Hero 的老管道正是如此【案例事实】：业务事件先落库归集，每小时跑一次批处理，产出广告曝光、点击、转化的聚合指标。事件从发生到出现在报表里，平均要等61分钟【信源1】。这个数字听起来不算夸张，但对一个竞价广告系统来说，61分钟意味着投放策略永远滞后于市场一个‘时区’。

改造之后，事件从产生到被度量系统记录，间隔是1.2秒【信源1】。1.2秒是什么概念？【推演】广告曝光到用户下单的转化链路本身都要跑几秒，度量延迟已经压到了几乎与业务同步——延迟优化的收益在这一点之后就边际递减了。

多位做过广告归因系统的架构师私下都讲过同一个感受【从业者经验，非案例事实】：批处理时代的‘准实时’（比如5分钟微批）是能优化出来的，但从61分钟到1.2秒这种数量级的跳跃，靠调参做不到，只能换架构。

产业逻辑很清楚：在广告这种‘数据本身就是生产资料’的场景里，度量延迟直接等于预算效率。延迟不是技术指标，是钱。

🏗️ 从批到流，动的不只是引擎

金句先行：批转流最大的坑，是把换引擎当成换架构。

这次改造的载体是 Apache Flink——流计算领域事实上的开源标准，并且 Delivery Hero 选择的是 AWS 的托管服务 Amazon Managed Service for Apache Flink，而不是自建Flink集群【信源1】。新老两条管道的形态，可以直观对比一下：

改造前的批处理管道：

改造后的实时管道：

两条链路的差别，表面上是从‘每小时跑一次’变成‘来一条算一条’，但真正的工程量在水面之下（以下三点中，第一、二点是Flink的公开技术特性【信源4】，第三点中“选择托管服务的动机”属本文推演）：

其一，状态管理【技术事实】。广告度量要做归因，需要把曝光、点击、转化在时间窗口内关联起来，这些中间状态要从外部存储搬进Flink的状态后端，由引擎统一管理checkpoint。这恰恰是Flink相对传统批处理引擎的核心能力。

其二，一致性语义【技术事实】。小时批时代，重跑一个分区就能修复数据；流模式下乱序、迟到、重复事件是常态，Exactly-once不再是可以关掉的选项，而是架构的一部分。

其三，运维模式变了【前半为技术事实，后半“这也是选择托管服务的关键动机”为推演】。批任务失败了重跑即可，流作业是7×24常驻进程，一次反压、一次checkpoint超时都可能拖垮下游。托管服务把扩缩容、快照恢复、版本升级这些‘脏活’交还给云厂商——考虑到57%的降本发生在‘运维成本’口径上，这很可能是 Delivery Hero 决策权重最高的一项，但官方案例未逐条披露决策过程。

💰 实时反而更便宜？反直觉但有道理

‘实时化=更贵’，是数据团队里流传最广的经验法则。流计算集群要常驻、要保障可用性，账单理应比按小时拉起的批任务高。

Delivery Hero 的结果恰恰相反：相比原方案，月度运维成本下降约57%【信源1】。需要说明：官方案例确认了降本幅度和“用托管Flink替代原批处理方案”这一事实，但没有公布成本构成的逐项明细。下面这张表的后三行是把两条管道的架构差异翻译成成本语言的结构化推演，不是官方披露的账单拆解：

第一，重算的隐性成本【推演】。批处理管道里，一个广告活动的指标往往要被多个下游任务重复扫描和聚合，数据每多一层依赖，存储和计算就多一份开销。流式增量计算一条数据只算一次，链路缩短本身就是在省钱。

第二，运维人力是成本大头【推演，与57%口径相容】。维护一套自建流计算或复杂批调度体系，需要专职团队值班排障。托管服务把这部分转换成了按量付费，‘运维成本’被外包成了‘云成本’，而云成本是弹性的。注意：这里的57%是运维成本口径的降幅，不是含人力在内的TCF总成本，两者的差别在向管理层汇报时必须讲清楚。

第三，失败代价【推演】。批任务跑挂了重跑，高峰期资源要按峰值预留；流作业从checkpoint恢复是分钟级的事，资源曲线平滑得多。

所以这57%不是奇迹，最合理的解释是把批架构里那些‘为了容忍延迟而付出的冗余’一次性清掉了。一个可以推演的判断是：当实时架构的成本曲线降到批处理之下，‘为了省钱继续用批’的最后一个理由也消失了。

⚠️ 别急着all in，实时化有三道隐形门槛

泼一盆冷水：这不是一个‘照抄就能成’的方案。而且要明确——以下三道门槛均来自行业普遍经验，不是 Delivery Hero 案例中披露的教训。官方案例讲的是成功结果，落地过程中的坑需要读者自己补课。

第一道门槛是场景筛选【行业经验】。Delivery Hero 挑的是广告度量——一个延迟直接兑换成收益的场景。如果业务对T+1完全不敏感，把它实时化只会徒增复杂度。据多位接近大型数据平台的工程师反馈，实时化项目失败最多的原因不是技术，而是‘为了实时而实时’，改造完业务没人用秒级数据。

第二道门槛是数据质量的攻防转换【行业经验】。批时代数据错了，第二天发现再修；流时代错误在1.2秒内就被下游消费掉了，污染是即时的。告警、熔断、回溯修复的整套机制必须前置建设，这在很多团队的预算里是空白。

第三道门槛是组织能力【行业经验】。流作业的心智模型（状态、水位线、反压、savepoint）和批作业完全不同。托管服务能免掉机器运维，免不掉团队的学习曲线。Flink社区多年积累的复杂度并没有消失，只是被托管层吸收了一部分。

📈 流批之争，可能正在走向终点

把这次改造放进十几年的产业时间线里看，脉络很清晰：

批处理统治了数据仓库的黄金年代，Kafka带来了‘流数据可用’，Flink让‘流计算可靠’，而云托管服务解决了最后一公里——‘流计算用得起、养得起’。三个条件在 Amazon Managed Service for Apache Flink 这类产品上会合，才有了 Delivery Hero 这种量级玩家的整体切换。

一个务实的观察是：当头部平台用真金白银投票，把核心收入链路（广告）从批搬到流，并且成本不升反降时，‘Lambda架构里流是补充’的叙事就基本失效了。对国内的数据平台团队和云厂商来说，值得关注的不是Flink本身，而是这个信号背后的取舍标准——延迟、成本、运维三者可以被同时优化，前提是架构选得对、场景挑得准。

需要保留一分清醒：单个公开案例由云厂商发布，天然带有示范营销属性；57%的降本发生在特定场景（广告度量）和特定起点（61分钟级批处理）上，直接外推到所有数据链路是危险的。它证明的是‘此类场景下流式架构的可行性’，而不是‘批处理已死’。

真正的问题已经不是‘要不要实时’，而是‘哪条链路先实时’。

结语

61分钟到1.2秒，57%的降本，Delivery Hero 这次改造最动人的地方在于它同时兑现了性能和成本的承诺，打破了‘实时化必然更贵’的执念。可以预见，托管流计算会加速从广告、风控这类刚需场景向通用数仓渗透，流批边界会越来越模糊。对还在批处理惯性里的团队，这是一份值得认真对照的路线图——先算清楚延迟值多少钱，再决定架构往哪走。

信源

1. AWS 官方客户案例：Delivery Hero × Amazon Managed Service for Apache Flink（aws.amazon.com/solutions/case-studies/），核心数据：延迟从约61分钟降至约1.2秒、月度运维成本较原方案降低约57%、新管道采用托管 Flink。

2. Delivery Hero 工程团队公开技术分享：关于广告度量实时化的架构实践（工程博客/技术会议演讲）。

3. Delivery Hero 公开业务信息：投资者关系页面与年报披露的市场覆盖与商家规模。

4. Apache Flink 官方文档：状态管理、checkpoint、Exactly-once 语义等引擎能力描述（nightlies.apache.org/flink）。

“注：文中所有标注【推演】【行业经验】的内容，均为作者基于公开信息的分析与从业者访谈，非案例官方披露；官方案例未披露的部分（老管道完整组件栈、精确事件量、迁移起止时间、成本逐项明细）已在正文中明确标出。