本文首发于泊浮目的语雀:https://www.yuque.com/17sing
| 版本 | 日期 | 备注 |
|---|---|---|
| 1.0 | 2022.3.16 | 文章首发 |
由于早期的流处理框架并不支持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比起其他的流处理框架，更优在两点：
- 遵循Dataflow模型，在编程模型上统一流批一体
- 改进Chandy-Lamport算法，以更低的代价保证精准一次的实现
在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。
上面描述的是在数据源要考虑的容错条件。在数据已经全部流入任务时，容错机制也需要重新考虑——尽量避免重复读取数据源以及上游任务的重算。因此社区引入了可插拔的Shuffle Service来提供Shuffle数据的持久用以支持细粒度的容错恢复——FLIP-31: Pluggable Shuffle Service。
2. 剩下的问题：数据来源不统一 上述流批衔接的前提是数据源被分为了流数据源和批数据源。那么口径便是不统一的，这会带来一些对接成本。
目前流行的方案会采用数据湖（如IceBerg、Hudi、DeltaLake）来做流批数据的统一，并且由于大多数据湖都支持
Time Travel，离线数据的可重复读问题也顺带解决。另外，Pravega这种以流批一体存储为设计目标的软件可能也是解决方案之一。
3. 小结 在本文中，笔者和大家一起了解了流批一体的来源，以及Flink社区在流批一体中做出的努力。此外，我们也看到了有些问题并不是Flink这个框架可以解决的，需要整个大数据生态来一起演进，走向流批一体。
在文章的最后，感谢余空同学的交流与指导，我们一起写出了这篇文章。
