采访嘉宾|王峰(莫问)
作者 | 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 能力实现了数据同步断点续传特性，并基于增量快照一致性读取算法保证了数据同步全程对在线数据库无锁操作，这样对生产业务不会产生任何影响。
作为流批一体的另一个创新应用场景，CDC 项目发展速度也非常快，网易、腾讯、Oceanbase、哔哩哔哩、Xtransfer 等公司都参与了社区贡献，GitHub Star 目前已经突破 3000，生态上支持了很多主流数据库，包括 MySQL、Oracle、PostgreSQL、MongoDB、TiDB、PolarDB 和 OceanBase 等。莫问表示，Flink CDC 会进一步利用 Flink 社区的创新成果，接入更多的数据源，成为新一代全增量一体化的数据集成引擎。
云原生时代的 Flink
随着云原生的普及，越来越多的企业应用进行了容器化迁移，并通过 K8s 进行编排管理。最近几年，大数据领域的 Spark、Kafka 等都开始支持 K8s，使得大数据应用从传统的 Yarn 时代转变为云原生时代。
Flink 社区很早以前就开始基于云原生来设计了，包括 Flink 的资源调度、流式 Shuffle，都是天然适合云原生的。Flink 作为一个流式计算引擎，数据的 Shuffle 不需要落盘，都是流式的进行数据传输，分布式计算之间数据的流动都是通过网络加内存，不依赖本地盘，因此天然就是存算分离的架构。另外，Flink 自带了一个状态存储，计算的算子和状态访问是一体的，在算子内部就支持状态访问，这个其实也在朝着存算分离方向去演进，也就是说 Flink 随时可以关掉 RocksDB 服务，把状态数据 SnapShot 到持久化的 HDFS 或者是云存储上。
Flink 作为云原生架构下的产物，本身也一直朝着云原生架构去设计，社区在五六年前就开始做 Flink on K8s。支持 K8s 之后，对 Flink 有很大的帮助，比如部署不依赖 Hadoop 了：只要有 K8s，就可以部署 Flink，也没有任何依赖。运维方案也非常标准化，K8s 的运维体系也会运维 Flink。同时，Flink 也可以基于容器来进行部署，容器给 Flink 带来了更好的隔离性，包括任务之间的隔离、多租户的管理，甚至下一步做 Serverless，也会更加自然和容易。
在云原生的发展趋势下，自适应性非常重要。更好的资源弹性让业务的波动也变得更加灵活，而云上的资源也是海量的，用户可以根据业务的需求不断弹性调资源规模。特别是 Serverless 的环境下，用户甚至不需要去考虑机器资源了。Flink 自身也会去增加更多的自适应的能力，实现自动化的任务并发管理和状态数据管理，从而让 Flink 能更好地使用云上的弹性机制。
Apache Flink 正在蓬勃发展，并在广大的大数据分析生态中变得不可或缺，逐渐成为了企业数据战略的关键支柱。但对于一些传统企业来说，如果没有很强大的大数据技术团队，用开源软件自建一个数据分析平台还是比较困难的。所以提供产品化服务，降低技术门槛，也是阿里云 Flink 技术团队正在做的事情。
阿里云已经推出了一款云原生的实时计算 Flink 产品，提供了以 Flink SQL 为核心的开发运维平台，将阿里内部积累的 Flink 生产运维经验和企业级能力都通过产品化的形式开放给广大中小企业，提供实时数仓、实时数据集成、实时风控和实时特征工程等解决方案，帮助数字化企业加速大数据技术实时化升级。
另外，阿里云提供的 Flink 产品也采用了最先进的 Serverless 架构，用户只要按需购买计算资源就可以运行方便使用 Flink，让实时计算更加普惠。莫问表示，未来几个月之内，基于 Flink 的多云 PaaS Serverless 服务也将在全球范围公测，作为推动 Flink 社区不断技术创新的核心研发团队，阿里云希望把 Flink 技术生态进一步推向全球
采访嘉宾简介
王峰，花名“莫问”，阿里巴巴研究员，2006 年北航毕业加入阿里巴巴，目前负责阿里云开源大数据平台，并担任阿里巴巴开源委员会大数据与 AI 方向副主席。2015 年开始将萌芽状态的 Apache Flink 引入中国，基于 Flink 推动阿里大数据进入全链路实时化时代，并以此为标杆效应带动了 Flink 在全球各个行业的快速普及和发展，让 Flink 成为了大数据实时计算领域的事实标准。阿里积极拥抱开源，也主动贡献开源。迄今，阿里已累计对外开源了上百个优秀项目，在 GitHub 上 Star 总数超百万。
（免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。 ）
