Flink流批一体 | 青训营笔记

鳄鱼儿

发布于 2024-05-21 21:24:37

1390

发布于 2024-05-21 21:24:37

文章被收录于专栏：鳄鱼儿的技术分享

Flink如何做到流批一体

流批一体的理念

2020年，阿里巴巴实时计算团队提出“流批一体”的理念，期望依托Flink框架解决企业数据分析的3个核心问题，理念中包含三个着力点，分别是一套班子、一套系统、一个逻辑。

一套班子：统一开发人员角色，现阶段企业数据分析有两个团队，一个团队负责实时开发，一个团队负责离线开发，在流批一体的理念中，期望促进两个团队的融合。
一套系统：统一数据处理技术，不管实时开发，还是离线开发都是用Flink框架进行，如非必要，尽可能少用其它系统。
一个逻辑：当前企业数据分析，有两套班子，两套技术体系，两套计算模式，导致实时数据和离线数据经常对不上，期望通过Flink SQL的方式，让离线和实时计算逻辑保持一致。

流批一体的理念即使用同一套 API、同一套开发范式来实现大数据的流计算和批计算，进而保证处理过程与结果的一致性。

何时需要流批一体

举例：

在抖音中，实时统计一个短视频的播放量、点赞数，也包括抖音直播间的实时观看人数等(流)
在抖音中，按天统计创造者的一些数据信息，比如昨天的播放量有多少、评论量多少、广告收入多少（批）

这些场景下的具体实现如下图

从用户的角度来看，上诉流、批独立实现方案存在一些痛点：

人力成本比较高。由于流和批是两套系统，相同的逻辑需要两个团队开发两遍。
数据链路冗余。在很多的场景下，流和批计算内容其实是一致，但是由于是两套系统，所以相同逻辑还是需要运行两遍，产生一定的资源浪费。
数据口径不一致。这个是用户遇到的最重要的问题。两套系统、两套算子，两套 UDF，一定会产生不同程度的误差，这些误差给业务方带来了非常大的困扰。这些误差不是简单依靠人力或者资源的投入就可以解决的。

流和批业务场景的特点

Flink中认为所有一切都是流组成，即批式计算是流式计算的特列，有界的数据集是一种特殊的数据流。不管哪种数据的集合，Flink认为都是流，所以理论上Flink可以用一套引擎架构来解决上述的两种场景的。

Apache Flink主要从以下模块来实流批一体化：

1.SQL层：支持bound和unbound数据集的处理；

2.DataStream API层统一，批和流都可以使用DataStream ApI来开发；

3.ScheDuler 层架构统一，支持流批场景;

4.Failover Recovery层架构统一，支持流批场景；

5.Shuffle Service 层架构统一，流批场景选择不同的Shuffle Service。

流批一体的Scheduler层

Scheduler主要负责将作业的DAG转化为在分布式环境中可以执行的Task，在1.12之前的版本，Flink就支持EAGER和LAZY两种模式的调换：

举例：EAGER模式下，12个task会一起调度，集群需要有足够的资源

举例：LA ZY模式下：最小调度一个task即可，集群中有一个slot资源就可以运行。

在新版本的Flink中用一个新的概念Pipeline Region来处理。

由Pipeline的数据交换方式连接的Task构成为一个Pipeline Region 。本质上，不管是流作业还是批作业，都是按照Pipeline Region粒度来申请资源和调度任务。

流批一体的Shuffle Service层

Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle。一般，分布式计算中所有涉及到上下游衔接的过程，都可以理解为Shuffle。

针对不同的分布式计算框架，Shuffle通常有几种不同的实现：

基于文件的Pull Based Shuffle，比如Spark或MR；它的特点是具有较高的容错性，适合较大规模的批处理作业由于是基于文件的，它的容错性和稳定性会更好一些；
基于Pipeline的Push Based Shuffle,比如Flink、Storm、Presto等，它的特点是低延迟和高性能，但是因为数据没有存储下来，如果是batch任务的话，就需要进行重跑恢复。

流和批之间Shuffle是有差异：

Shuftle数据的生命周期：流作业的Shuffle数据与Task是绑定的，而批作业的Shuffle数据与Task是解耦的；
Shute数据存储介质：流作业的生命周期比较短、而且流作业为了实时性，shuffle通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里；
Shufte的部署方式：流作业Shuffle服务和计算节点部署在一起，可以减少网络开销，从而减少latency，而批作业则不同。

Flink对于流和批提供两种类型的Shuffle ,虽然Streaming和Batch Shuffle在具体的策略上存在一定的差异,但本质上都是为了对数据进行Re- Partition，因此不同的Shuffle 之间是存在一定的共性的。所以Flink的目标是提供一套统一的Shufle架构,既可以满足不同Shufle在策略上的定制,同时还能避免在共性需求上进行重复开发。

场景选择

Streaming和OL AP场景

为了性能的需要，通常会使用基于Pipeline的Shuffle模式

Batch场景

一般会选取 Blocking的Shuffle模式

为了统一 Flink 在Streaming和Batch模式下的Shuffle架构，Flink实现了一个Pluggable的ShuffleService框架，抽象出一些公共模块。

对于Shuffle Service，Flink 开源社区已经支持

Netty Shuffle Service ：既支持pipeline又支持blocking , Flink默认的shuffle Service策略;
Remote Shuffle Service ：既支持pipeline又支持blocking，不过对于pipeline模式，走remote反而会性能下降，主要是有用在batch的blocking场景,字节内部是基于CSS来实现的RSS。