本文首发于泊浮目标语雀: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 这个框架能够解决的,须要整个大数据生态来一起演进,走向流批一体。
在文章的最初,感激余空同学的交换与领导,咱们一起写出了这篇文章。