投入上百人、经历多次双11，Flink已经足够强大了吗？

采访嘉宾｜王峰（莫问） 作者 | Tina

作为最活跃的大数据项目之一，Flink 进入 Apache 软件基金会顶级项目已经有八年了。

Apache Flink 是一款实时大数据分析引擎，同时支持流批执行模式，并与 Hadoop 生态可以无缝对接。2014 年，它被接纳为 Apache 孵化器项目，仅仅几个月后，它就成为了 Apache 的顶级项目。

对于 Flink 来说，阿里有非常适合的流式场景。作为 Flink 的主导力量，阿里从 2015 年开始调研 Flink，并于 2016 年第一次在搜索场景中上线 Flink。在落地的同时，阿里对 Flink 进行大量的修改和完善，让其适应超大规模业务场景。2017 年，阿里已成为 Flink 社区最大规模用户，Flink 团队也达上百人。这其中的一些早期改进，阿里在 2018 年的文章《Flink 已经足够强大了吗？阿里巴巴说：还不够》中已有详尽解读。

2019 年，阿里宣布收购了 Flink 背后的企业，并正式开源内部 Flink 版本 Blink，贡献了超百万行代码，极大地推动了社区的良性发展。在 2021 年双 11 中，Flink 承载的实时计算峰值达到了每秒 40 亿条记录，数据体量也达到 7 TB 每秒，相当于一秒钟需要读完 500 万本《新华字典》。

这几年，Flink 社区在国内外技术会议上不断宣传推广，让 Flink 得到大量采用，各种应用场景也变得更加广泛，生态快速发展。Flink 已经变得强大，其设计目标也不再仅仅是流计算引擎，而是让绝大部分数据分析师都可以利用 Flink 流批一体 API 搭建实时数据集成、分析、风控和在线机器学习场景解决方案。

2022 年 11 月 26-27 日，Flink Forward Asia 2022 于线上召开，这是一次总结最近发布的重要功能的机会。这一次，Flink 流式数仓功能更加成熟，CDC 也能够接入多种数据库......InfoQ 趁此机会，采访了 Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（花名莫问），解读 Flink 核心技术的进展，并了解 Flink 的未来规划。

从流计算到流批一体计算打败 Storm 和 Spark Streaming 之后，Flink 成为了流计算的唯一标准，技术上已经没有了竞争对手。

Flink 诞生之初能够快速打败上一代流计算引擎 Storm，凭借的是“有状态的流计算”这个核心理念和特色。通过合流式计算和状态管理两项技术，Flink 不仅提供了高性能的纯流式计算，同时也在框架层通过分布式一致性快照技术，为用户提供了数据精准一致性保证。在莫问看来，这是 Flink 出道后迅速成为流计算领域新主流的关键原因。

虽然 Spark Streaming 通过借助强大的 Spark 生态也能够成为一些流计算场景的选择，但其本质依然是基于 Spark Batch 引擎构建的，非纯流执行模式还是会限制其执行性能和流语义表达。

而在批计算方面，Flink 已经完成绝大部分工作，并日益成熟。“目前 Flink 已经能够完整跑通批处理标准测试集 TPC-DS，而且性能也非常不错，已经达到主流批处理引擎水平，接下来 Flink 在批处理的成熟度上会持续完善和打磨，并结合自身流处理的天然优势，力求给用户带来业界最好的流批一体计算体验。”

为什么我们需要流批一体？为什么基于 Flink 的流批一体更有技术优势？

我们先从业务视角看待这个问题，早期企业基本都是离线业务，基于批处理一天运行一次报表，但数字世界在不断进化演进，对实时的需求会越来越多。实时风控、实时 BI 统计、实时推荐、实时监控，这些都不能等到晚上进行（到了晚上可能商品已经卖完了，用户也走了），实时化的数据分析才能给用户带来价值。逐渐离线和实时就会成为两条平行割裂的链路，并随着实时数据业务量占比持续提升，会有越来越多的任务要重复开发两遍，开发者会开始面临开发效率问题。

此外，实时和离线链路割裂还会存在业务口径一致性的问题，在之前的技术方案下，实时和离线相当于用了两套工具干活，使用不同的语言、不同的引擎，数据口径也无法一致，这样的分析结果就会干扰业务决策，甚至会误导决策失误。

这时候流批一体自然而然就成为了解决实时离线割裂的“新手段”。用一套计算引擎开发出的实时离线两个业务流程，天然是一致的，不会存在误差。尤其在一些高时效的业务场景中，如搜索、推荐、广告，数据平台中的营销分析，对流批一体的需求自然就会比较高。而且，在搜索推荐场景中，还能将 Flink 流批任务与在线任务混部到一起，共用一个资源池，进行统一调度，从而最大化利用服务器资源，这在业界也是比较先进的实践方式。

流批一体新架构能够带来的收益是明显的，但也并不是说它就是“放之四海而皆准”的一种技术架构。莫问认为，“如果当前数据业务基本都在离线数仓，尚未有一定规模的实时化业务，那也没有必要过早去做流批一体改造，因为这样收益并不大。当实时业务量日益成为主流，相对离线占比日益增大，或者对数据一致性有越来越强一致的要求的话，那么流批一体架构就是面向未来的必然选择。”

流式数仓：基于流批一体的新数仓架构流批一体是一个技术理念。

Flink 在 SQL 层提供了流批一体语义表达能力，即用户可以写一套 SQL，从而同时用在实时和离线两个场景，从而得到全增量一体化的数据开发体验。

这是流批一体理念的终点吗？显然还不够。因为在数据存储链路上，还是存在很大的复杂性，例如：在实时链路上，Flink 需要将数据写入 Kafka 等流式存储中，在离线链路上，Flink 往往要将数据写入到 Hive/Iceberg/Hudi 等批式存储中。两条存储链路是割裂的，用户依然要同时维护两条数据链路，造成较大的管理难度。

然而目前我们要同时维护两套存储的原因主要是业界目前没有一个较为生产可用的流批一体存储，同时支持高效的流读、流写、批读、批写能力，用户为了满足不同业务需求（时效性，可分析性等）只能通过多条链路的组合来拼接，甚至还要在不同存储间同步数据，这必然会让整个链路变得日益复杂。

那目前业界是否已经存在可用的流批一体存储来解决这个问题呢？大家可能会想到 Apache Hudi 的这个主流湖存储项目，Hudi 也确是目前业界流批一体存储能力上相对最完善的技术，但 Hudi 在存储结构的设计上，并不适合大规模更新。因此，Flink 社区下一个阶段的重点方向就是要去解决这个用户痛点，将流批一体理念进一步完善，提供真正可用的流批一体存储技术，从而基于流批一体计算和存储推出完整的流式数仓新架构，这也是 2021 年底 Flink 社区推出 Flink Table Store 独立子项目的背景。

2022 年，Flink Table Store 已经完成了从 0 到 1 的孵化，并发布了 2 个 release 版本，除了阿里巴巴，包括字节跳动在内的多家公司都已经参与了这个项目的贡献，并有不少公司开始试用。Flink 社区接下来的重点演进方向就是流式数仓新架构， 为用户提供更加简洁、实时化的数仓架构，并提供更加一体化的体验，这也是 Flink 多年来倡导的流批一体理念的完整落地场景，流批一体计算和存储的完美结合。

在今天的 Flink Forward Asia 2022 上，莫问给大家展示了一个完整的产品化 Demo，基于阿里的实时计算平台，在 TPC-H 业务背景下跑通了完整的流批一体数据处理和分析流程，包括从数据库源头开始的 Flink CDC 数据入湖（写入 Table Store）、Flink SQL 实时流式分析（订阅 Table Store）以及批量数据订正和实时交互查询，给大家呈现了一个完整的流式数仓新架构成果。此外，Flink 流式数仓架构也是开放的体系，支持对接其他一切具备流批一体能力的存储系统，例如阿里云的 Hologres，阿里也在内部完成了 Flink SQL + Hologres 的企业级自研流式数仓产品，不久也将正式对外发布。

基于 Flink 的全增量一体化数据集成

数据集成是实时流处理平台中非常重要的一个应用场景，这在 Garnter 2022 年 1 月发布的流处理平台市场引导报告中也可以得到印证，从全球市场看大概 1/3 的流处理场景是和实时数据集成相关的，即通过流处理能力将各种不断变化数据源中的数据同步到分析数据库，数据仓库和数据湖中，从而确保用户可以实时分析到最新的数字世界。

随着实时化数据分析技术的普及，用户的数据同步需求也在进一步升级，期望能够使用一套一体化的全量数据同步工具，一键实现数据同步。但在传统数据集成技术体系下，全量和实时数据同步往往需要两套工具（基于批和流的），并且用户需要在两套工具之间进行协同，因此要真正实现全增量同步流程的无缝对接并保证数据一致性，这个难度和挑战是非常大的。但如果能够利用上 Flink 流批一体融合特性，那实现全增量一体化的实时数据集成就变得可行了。

此外，Flink 本身也具备了丰富的 Connector 生态，能够连接业界各种主流存储，以及优秀的分布式集成框架，包括容错和分布式一致性快照等能力。因此在 Flink 的基础上做全增量一体化数据集成，相当于“站在巨人肩膀上”，会更快更容易。

这就是 Flink CDC 项目诞生的背景，其大量借助了 Flink 自身的优势，利用流批一体执行模式实现了全增量同步自动切换，基于 Flink Checkpointing 能力实现了数据同步断点续传特性，并基于增量快照一致性读取算法保证了数据同步全程对在线数据库无锁操作，这样对生产业务不会产生任何影响。