共计 2015 个字符，预计需要花费 6 分钟才能阅读完成。
本文首发于泊浮目标语雀:https://www.yuque.com/17sing
| 版本 | 日期 | 备注 |
|---|---|---|
| 1.0 | 2022.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 比起其余的流解决框架，更优在两点：
- 遵循 Dataflow 模型，在编程模型上对立流批一体
- 改良 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 这个框架能够解决的，须要整个大数据生态来一起演进，走向流批一体。
在文章的最初，感激余空同学的交换与领导，咱们一起写出了这篇文章。
