产业动态

投入上百人、经历多次双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能力实现了数据同步断点续传特性,并基于增量快照一致性读取算法保证了数据同步全程对在线数据库无锁操作,这样对生产业务不会产生任何影响。

  作为流批一体的另一个创新应用场景,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总数超百万。