为什么阿里云要做Apache Flink

流批一体已经从理论走向实践，并在 2020 年迎来落地元年。

短短 5 年，Apache Flink（下称 Flink）从一个突然出现在大数据舞台的“萌新”系统，迅速成长为人人皆知的流计算引擎。

在伴随 Flink 发展掀起的这波实时计算浪潮里，阿里是国内走得最前、做得也最多的一个，“流批一体”是它的新赛道。今年双 11， Flink 流批一体开始在阿里最核心的数据业务场景崭露头角，并抗住了 40 亿条／秒的实时计算峰值。

这是第一次有互联网超级大厂真正在核心数据业务上规模化落地流批一体技术。同时，这也意味着 Flink 在阿里的发展已经进入第二个阶段，从全链路实时化进阶到全链路流批一体化。

恰逢 2020 年 Flink Forward Asia 大会召开之际，InfoQ 对 Apache Flink 中文社区发起人及阿里云实时计算负责人王峰（花名莫问）、阿里云实时计算团队资深技术专家杨克特（花名鲁尼）、天猫大数据负责人黄晓锋进行了独家专访，希望从多个角度更完整地还原 Flink 流批一体在阿里落地的过程和背后的技术挑战，并深入探讨这个新赛道对于阿里云的价值和未来发展方向。

1 从理论到落地

流批一体的技术理念最早提出于 2015 年，它的初衷是让开发人员能够用同一套接口实现大数据的流计算和批计算，进而保证处理过程与结果的一致性。随后，大数据厂商 / 框架们如 Spark、Flink、Beam 等，都陆续提出了自己的解决方案，虽然实现方式各不相同，但在一定程度上说明流批一体的思想已经在业界得到广泛认可。

然而，流批一体要真正从理论走到落地，尤其是在企业的核心数据业务场景规模化落地，往往面临技术和业务的双重挑战。在莫问看来，这也是为什么流批一体出现的很早，厂商落地案例却不多见。

从技术层面来看，流计算和批计算从计算方式、支撑模块、资源调度策略到流程规划等都存在差异，不管是批流一体还是流批一体，都有不少技术问题要解决。这其中关乎研发资源投入，但大前提是需要有一个统一的计算引擎。虽然 Spark 是最早提出流批一体理念的计算引擎之一，但由于其本质还是基于批（mini-batch）来实现流，在流计算语义和延迟上存在硬伤，难以满足复杂、大规模实时计算场景的极致需求，因此目前很多厂商的数据业务还是选择将流和批分开来做，流用 Flink、批用 Spark。这就导致前面说的大前提无法满足，在核心场景落地流批一体更加无从谈起。

从业务层面来看，如果企业有非常重的历史包袱或者在流批一体架构下不能取得足够多业务价值，那它也不会有足够的动力去做流批一体的改造和落地。

但对于阿里来说，恰恰是在技术和业务两个因素共同推动之下，流批一体才得以在双 11 核心业务场景正式亮相。

技术上，阿里 2019 年收购 Flink 的创始公司 Ververica 后，投入近百名工程师到 Flink 技术研发和社区工作中，在 Flink 基于流实现批计算的能力上做了非常多工作，其中有一些特性优先在双 11 落地，后续也会全部推进到社区里。

业务上，今年大促期曾经面临离线和实时数据统计口径不一致的问题，这类潜在问题会影响广告、商务甚至公司运营决策，这是真正的“秒秒钟几百万上下”，强电商属性和大业务体量倒逼着流批一体技术必须在阿里核心业务落地，方能解决痛点。

莫问提到，当前流批一体已经在许多业务场景成为刚需，而不是一个技术噱头。这次双十一就像一场“转正”考试，意味着在阿里巴巴业务场景中流批一体技术从理论走向落地，同时也标记着 Flink 在阿里开始从全链路实时化步入全链路流批一体化的新阶段。

2 路走对了，就不怕远

2015 年，针对搜索推荐业务做新的大数据计算引擎选型时，阿里云实时计算团队对流批一体的技术方向就已经有初步设想。

在经过深度调研、可行性验证和对未来可能遇到的问题进行推演之后，团队最终决定引入 Flink。鲁尼表示，虽然当时 Flink 整个系统还不是特别成熟，但团队认为 Flink 以流计算为核心的设计理念更符合未来数据计算实时化发展的大趋势。在阿里内部有一句土话，叫“路走对了，就不怕远”，从后续这几年的发展情况来看，Flink 确实进展顺利，甚至超过团队当时的预期。

当然，从初步设想到实现相对完善的流批一体能力，需要一个循序渐进的过程。

从技术本身演化的角度来看，Flink 经历了流批一体 API 从无到有、从有到更优两个阶段。在早期的 Flink 版本中，Flink 的流和批无论在 API 还是在 Runtime 上都没有达到彻底的统一。但从 1.9 版本开始，Flink 加速在流批一体上进行完善和升级，Flink SQL 作为用户使用的最主流 API，率先实现了流批一体语义，用户只需学习使用一套 SQL 就可以基于 Flink 进行流批一体的开发，降低了开发的门槛。

最初 SQL 实现流批一体的做法是将流作业和批作业分别翻译成 Flink 底层的两个原生 API，包括处理流计算需求的 DataStream 和处理批计算需求的 DataSet，相对来说有些简单粗暴，当时也引发了一系列问题，包括开发链路过长导致迭代效率不高等。因此 Flink 社区又对底层架构做了一些重构，并引出了 DAG API，Flink 分布式运行层针对 DAG 做了一系列优化，包括增加流批一体的调度器、可插拔的 Shuffle 插件等。这样一来，Flink 的分布式运行层也开始逐渐形成了流批一体的 DAG 描述能力和调度执行能力。

目前 Flink 的流批一体方案仍然在持续改进当中。虽然现在开发者已经可以很方便地基于 SQL API 来执行流批一体作业，但 SQL 并不能解决所有需求。一些逻辑特别复杂或定制化程度较高的作业还是需要继续使用 DataStream API。DataStream API 虽然能更加灵活地应对流计算场景的各种需求，但却缺乏对批处理的高效支持。

因此，Flink 社区在完成 SQL 流批一体升级之后，从 1.11 版本开始投入大量精力完善 DataStream API 的流批一体能力，在 DataSteam API 上增加批处理的语义，同时结合流批一体 Connector 的设计，让 DataStream API 能够在流批融合场景下对接 Kafka 和 HDFS 等不同类型流批数据源。在刚刚发布的 1.12 版本中，大家就可以体验到 DataStream 流批一体的原生支持。接下来流批一体的迭代计算 API 也将被引入到 DataStream 中，进一步解锁一系列机器学习场景。

此外，在当前 Flink 主版本中，不管是 SQL 还是 DataStream API，在流批一体概念上都还是流计算和批计算功能的结合体。用户虽然只需要编写一套代码，但需要在代码中选择使用流的方式跑，还是批的方式跑，执行模式比较单一。但有些业务场景已经提出更高的要求，即流批混合，需要在批和流之间自动切换，Flink 也将在后续支持更加智能的流批融合场景和动态切换能力。

当然，流批一体不只是一个技术问题，最终还是业务落地的问题，Flink 的流批一体能力也是通过大规模业务锻造出来的。

虽然选型之初，阿里云的技术团队看中的就是 Flink 优秀的流计算能力，但当时这个能力并未经过大规模线上业务验证。为了快速试错，团队决定开辟一个 Flink 的内部分支（即后来为大家熟知的 Blink），最大目的是快速增加当时急缺的功能并在线上业务验证，这也是在业务早期的选择。

经过团队一年的努力，基于 Flink 的搜索推荐实时计算平台成功支持了 2016 年的搜索双 11，保证了搜索推荐全链路实时化。在这之后，Flink 开始在阿里集团内部服务于更多实时数据业务，在更大规模的业务场景验证并优化其流计算能力和稳定性。2017 年，Flink 成功支持了全集团双 11 的实时数据业务，包括 GMV 大屏等最核心的数据业务场景。

在实时计算能力经过充分验证之后，团队开始补充和完善 Flink 的批计算能力，并在搜索推荐的索引构建、机器学习特征工程和样本生成等业务场景中进行验证。

经过大规模作业验证之后，团队对 Flink 的流批一体能力更加有底，也是在这个时候，团队开始酝酿 Blink 的开源。后面的进展很多人都已经有所了解：2018 年 12 月阿里宣布开源 Flink 的内部分支 Blink；2019 年 1 月起，阿里逐步将内部在 Blink 沉淀的能力推回 Flink 开源社区；到 2019 年 11 月发布的 Flink 1.10 版本前瞻，Blink 全部功能都已经进入 Flink。2020 年双 11 天猫营销决策核心系统的这场“大考”，Flink 流批一体技术又得到了更进一步的锤炼。

3 流批一体的双 11“大考”

在莫问看来，Flink 流批一体技术从最初应用于搜索推荐场景，到今年双 11 在天猫核心数据业务落地，升级的是业务的重要程度，而不是简单的计算规模。

在流计算场景上，天猫大数据团队已经跟实时计算团队配合了很多年，但之前一直没有在批计算场景上线。鲁尼透露，天猫的批处理作业优先级在集团内属于级别最高的那一档，因此在架构升级上会更慎重。

天猫分析场景下的报表大部分分为实时和离线两种，商家、小二、管理层通过实时数据和历史数据进行不同维度、不同时间周期的比对，从而对当前的活动情况作出判断，这些数据是业务决策的重要判断依据。

以前天猫整体的数据架构使用的是 Lambda 架构，数据分析需求基于流、批两套计算引擎产出，这种分离的架构不仅会带来两套开发成本，也导致数据逻辑和口径难以对齐。另外，产品搭建数据报表的时候，过程繁琐，容易出现问题。这些痛点促使天猫大数据团队开始调研流批一体的技术方案。

流批一体的技术方案主要分两种，一种是跨引擎的流批一体，比如更早以前 Storm 和 Spark 结合使用，批交给 Spark 执行，流交给 Storm 执行；另一种就是一个引擎本身就具备流批一体的能力，比如 Spark 和 Spark streaming、Flink 等。鉴于 Flink 的流计算能力已经在阿里集团内部经过大规模业务应用的验证，以及 Flink 流批一体技术的不断成熟，天猫大数据团队决定尝试基于 Flink 的流批一体能力升级技术架构。

除了计算层，团队也调研了存储层的流批一体方案，最终确定云原生实时数仓 Hologres 可以满足天猫点查和 OLAP 分析这两个场景的需求。团队首先设计了一个 POC 流程对整套方案进行可行性验证，发现这套方案是 work 的，的确能对研发效能和数据质量带来了比较大的提升。

黄晓锋告诉 InfoQ，从决定在双 11 大促中规模化使用 Flink 流批一体到最终落地，天猫大数据团队和实时计算团队并肩作战了 5 个月，整个改造过程大致可以划分为四个关键阶段。

第一个阶段是设计。首先需要拆解和梳理天猫实际情况，完成流批一体模型的统一。然后需要在平台这一侧把源数据打通，实现用户只写一套代码，平台自动翻译成 Flink Batch 任务和 Flink Stream 任务，同时写到一张 Holo 表，完成计算层表达的统一。

第二个阶段是落地。流批一体需要依赖离线的调度，因此需要对 MaxCompute平台做一定程度的打通。

第三个阶段是优化。包括语义层表达的优化，比如以前写的趋势图逻辑可能针对流场景做了针对性优化，但在批上面不起作用甚至可能存在问题，这些特殊场景需要做语义对齐；也包括性能的优化，以保证在双 11 可以达到性能目标。

第四阶段是稳定性。由于整条链路改动比较大，双 11 场景对稳定性的要求又特别高，因此团队重点展开了数据全链路的压测，以保证 Flink 本身流批计算性能、Hologres 的查询性能和上层 BI 层的查询性能，都能够满足双 11 的 QPS 诉求。

在整个过程中，团队也遇到了几个核心挑战。

其中一个挑战来自性能。这是流批一体第一次大规模使用，不同系统的数据打通做的还不是非常完备。比如 MaxCompute 和 Flink 之间的数据中转是通过 Tunnel 管道的方式来做的，但在规模化应用的过程中才发现 Tunnel 有连接数的限制，会极大地影响规模化推广。后来团队通过在 Flink 这一层做相应的优化，先一次性读取再在 Flink 内部做分发，极大地降低了连接数并优化了读取性能，问题得以解决。

另一个挑战来自流批一体的语义统一。在某些场景下，开发人员对流批语义的理解和 Flink Runtime 翻译出来的流批一体语义之间存在差异，可能会导致同一套 SQL 跑出来的流批结果跟业务理解的不一样，比如对于 Index Join 和 Primarykey Join 的处理方式在流批上面的差异。后来两个团队联合修复了这个问题。

除此之外，天猫大数据团队也联合 Hologres 开发团队对 Hologres 进行了非常深度的优化，包括优化器、排队机制、数据 Shard 的划分规则、计算层的数据 shuffle 机制都做了针对性的优化。

事实上，Flink 流批一体成功落地双 11 天猫核心数据场景，不仅更好地提升了开发团队成员的技术能力，在业务上的实践效果也非常喜人。

时效性上，面对 58.3 万笔 / 秒的交易峰值和上亿 / 秒的无线流量洪峰，天猫的所有任务都达到了秒级延时，整个实时计算集群峰值 TPS 达到 40 亿条 / 秒。同时，集群资源利用率也得到了大幅提升，批任务可以错峰执行。

准确性上，流批任务的业务口径做到了完全一致，数据质量问题不复存在，成为大促期间重要的业务雷达。流批模型也实现了完全统一，产品搭建效率提升 400%。

灵活性上，流批一体实现了多个计算处理模式也只需要撰写一套代码，需求迭代效率提升 2 倍，大促当天紧急需求承接效率提升 5 倍。同时，实时数仓 +OLAP 场景结合，也使得变更成本大幅下降，能更好地满足分析师按需取数场景的需要。

在黄晓锋的整体规划里，Flink 流批一体成功落地双 11 天猫核心数据场景，仅仅只是走出了阳光大道的第一步。接下来，天猫大数据团队计划继续探索存储层的流批一体，而在更长远的未来，团队希望推动流批一体往“湖仓一体”方向去演进，并把经过内部打磨的技术架构和平台，如 DataPhin、QuickBI、Flink、Hologres 整合的场景，输出到云上服务更多外部用户。

4 下一个规模化落地场景什么时候到来？

阿里在核心数据业务上真正规模化落地“流批一体”无疑给业界开了个好头。

近几年，大数据领域逐渐开始拥抱“融合”（或所谓“一体化”）演进的新方向，不管是今年刚成为热议话题的“湖仓一体”，还是更早提出的“流批一体”，其实都是这一思路的阶段性成果。对于新的技术思路，大众在一开始肯定会有质疑和观望情绪。莫问表示，团队希望通过这次成功打样的案例向业界证明，Flink 流批一体是真正能够落地核心业务并为业务创造价值的。这或许能让更多企业和团队打消观望情绪，并使 2020 年成为流批一体落地的元年。

在黄晓锋看来，流批一体将成为阿里集团内部数据技术升级的新赛道。因为天猫的业务体量和业务场景的复杂度，在整个集团里非常具有代表性，Flink 流批一体在天猫业务上的成功应用，会推动整个集团在流批一体这个赛道上的投入，也会推动更多业务去升级到流批一体架构，以解决业务上的痛点。

除了在阿里内部推动更多业务落地 Flink 流批一体，莫问提到，未来还会将更多精力和焦点放在开源社区。下一步，阿里云实时计算团队会把在阿里业务场景下打磨出来的核心技术积累，在 Flink 未来的 1 到 2 个版本中逐步推回开源社区，让更多企业都能够用上 Flink 流批一体的能力。

当然，在 Flink 流批一体推广和大规模落地的道路上也充满挑战。

流批一体技术本身的挑战在于，原来是一个单一引擎解决单一问题（批或者流），现在需要一个引擎同时解决流 + 批的问题，如果未来流和批的概念逐渐淡化，那么引擎本身就需要具备针对不同场景和需求智能化选择流批模式的能力，这在技术上是非常大的挑战。不过鲁尼认为，机遇和挑战是一并存在的，如果用户能够把更多精力从选择引擎、维护引擎中解放出来，就可以更专注于业务本身，既能加快迭代效率也能利用流批一体引擎的灵活性解锁更多有价值的业务场景。

另一个挑战在于改变用户的心智，莫问表示，流批一体需要用户转变原来固有的流批分离的思维模式，这并不是一件简单的事情，企业在做相关的决策时肯定会更加谨慎，需要逐步试点和推进。另外，当前很多互联网公司离线计算团队和实时计算团队是两个独立的团队、两套独立的体系，如果要做流批一体，就需要两个团队密切合作和共建，组织架构上的挑战不亚于技术上的挑战。但莫问相信，只要方向对了，一切只是时间问题。

据了解，目前 Flink 社区中字节跳动、快手、小米等几家头部公司都已经开始探索基于 Flink 的流批一体架构，或正在规划当中。

展望 2021 年，Flink 流批一体或将迎来快速发展期。随着更多大型互联网公司成功落地并向业界输出经验，相信会推动更多中小企业选择跟进和尝试流批一体架构。

责任编辑：xj

原文标题：为什么阿里云要做流批一体？

文章出处：【微信公众号：算法与数据结构】欢迎添加关注！文章转载请注明出处。