头图

读Flink源码谈设计:流批一体的实现与现状

泊浮目
English

本文首发于泊浮目的语雀:https://www.yuque.com/17sing

版本日期备注
1.02022.3.16文章首发

0.背景:Dataflow之前

在Dataflow相关的论文发表前,大家都往往认为需要两套API来实现流计算和批计算,典型的实现便是Lambda架构。

由于早期的流处理框架并不支持Exactly Once,导致流处理的数据并不精准。在这个基础上,一旦数据出现问题,则要导致大量的数据重放——这是因为事件往往是有时序要求的。因此,Lambda往往会通过流处理框架获取不是特别精准的结果,同时也会定时运行批处理程序,来获取更精准的结果——当更精准的结果出来时,我们就不需要前者了。

但这也带来的新的问题,所有的视图都需要流、批处理层各做一次,代码也要写两套,这带来了数据口径不同。可以说是在计算机资源以及人力资源上至少加了两倍的开销。

Kappa提出了将所有数据落到Kafka上,将存储模型与计算模型统一,但牺牲了时间——当数据量大时,回溯计算的压力巨大。

直到The dataflow model: a practical approach to balancing correctness, latency, and cost in massive-scale, unbounded, out-of-order data processing发表后,流与批有望在编程模型上统一, 上述相关的问题得以缓解

1. Flink的实现

Flink比起其他的流处理框架,更优在两点:

  1. 遵循Dataflow模型,在编程模型上统一流批一体
  2. 改进Chandy-Lamport算法,以更低的代价保证精准一次的实现

1.1 编程模型统一的背后

编程模型的统一具体体现在Flink SQL以及DataStream上。我们可以用相同的SQL or 几乎相同的代码跑流与批的任务。尤其是SQL,比起DataStream在声明式上更甚。因此用户在使用它们时,仅仅需要描述自己想要什么,而不是自己要做什么。具体做什么的事,Flink框架会帮你搞定。

在Flink框架上,目前主要解决了以下问题:

  • IO模型:批处理会更加关注吞吐,因此是pull模型;而流处理更加关注实时性,因此是push模型。基于这个条件,Source算子需要同时支持两种模型来适应不同的计算模式。详细见 FLIP-27: Refactor Source Interface
  • 调度策略:批处理的算子并不需要同时在线,前一批的算子完成后再调度后一批算子即可——由于计算资源往往比存储资源昂贵,这是一个很不错的优化方案。当然在资源充足的情况下,追求性能也可以不考虑这种策略;但流处理的作业需要作业启动时就全部被调度。因此,StreamGraph需要同时支持这两种模式——即LazyScheduling和EagerScheduling。
  • 批流的衔接:假如我们要分析近30天的数据,大多数情况下都是29天的离线数据加上最近一天的实时数据,如何保证衔接时数据不多也不少,其实是个麻烦的事情,在不少工程实践中会用一些比较hacks的方法。好在Flink1.4中引入了 Hybrid Source来简化这件事—— FLIP-150: Introduce Hybrid Source

1.2 Checkpoint不是银弹

Checkpoint是Flink框架中重要的容错机制,它的一个前提要求是数据源可重复读。在数仓场景下,虽然绝大多数情况下数据都不会发生变化——但也会有冷数据处理机制以及一些merge发生。这将对数据可重读造成一定的挑战。另外,在笔者负责的产品QMatrix中,对数据库做全量迁移时也会遇到类似的挑战:T1时刻读到的全量数据为集合1,而T2时刻读到的全量数据则为集合2。而MVVC也只能维持在一个session中。

上面描述的是在数据源要考虑的容错条件。在数据已经全部流入任务时,容错机制也需要重新考虑——尽量避免重复读取数据源以及上游任务的重算。因此社区引入了可插拔的Shuffle Service来提供Shuffle数据的持久用以支持细粒度的容错恢复——FLIP-31: Pluggable Shuffle Service

2. 剩下的问题:数据来源不统一

上述流批衔接的前提是数据源被分为了流数据源和批数据源。那么口径便是不统一的,这会带来一些对接成本。

目前流行的方案会采用数据湖(如IceBerg、Hudi、DeltaLake)来做流批数据的统一,并且由于大多数据湖都支持Time Travel,离线数据的可重复读问题也顺带解决。

另外,Pravega这种以流批一体存储为设计目标的软件可能也是解决方案之一。

3. 小结

在本文中,笔者和大家一起了解了流批一体的来源,以及Flink社区在流批一体中做出的努力。此外,我们也看到了有些问题并不是Flink这个框架可以解决的,需要整个大数据生态来一起演进,走向流批一体。

在文章的最后,感谢余空同学的交流与指导,我们一起写出了这篇文章。
阅读 1.7k

泊浮说
作者是个热爱分享交流的人,所以有了这个专栏。你的点赞是我最大的更新动力。

ZStack Committer、Flink Contributor,患有严重的代码洁癖症。致力于构建可靠、可维护、可扩展的软件系...

4.8k 声望
1.3k 粉丝
0 条评论

ZStack Committer、Flink Contributor,患有严重的代码洁癖症。致力于构建可靠、可维护、可扩展的软件系...

4.8k 声望
1.3k 粉丝
文章目录
宣传栏