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

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这个框架可以解决的，需要整个大数据生态来一起演进，走向流批一体。

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