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会一起调度，集群需要有足够的资源

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

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

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

流批一体的Shuffle Service层

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

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

  1. 基于文件的Pull Based Shuffle，比如Spark或MR；它的特点是具有较高的容错性，适合较大规模的批处理作业由于是基于文件的，它的容错性和稳定性会更好一些；

<!---->

  1. 基于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 开源社区已经支持

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

Flink架构优化

在实际生产环境中，针对不同的应用场景,我们对数据处理的要求是不同的:

  1. 有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高,典型的应用是搜索引擎构建索引;

  2. 有些场景下，需对数据进行实时分析，要求每条数据处理延迟尽可能低,典型的应用是广告推荐、金融风控场景。

举个例子:

  1. 在抖音中，实时统计一个短视频的播放量、点赞数，也包括抖音直播间的实时观看人数等; （流式场景）

  2. 在抖音中，按天统计创造者的一些数据信息，比如昨天的播放量有多少、评论量多少、广告收入多少; （批式场景）

  3. 在抖音的一些推广活动中，运营同学需要对一些实时产出的结果数据做一些实时多维分析，来帮助后面活动的决策。 （OLAP场景）

通过前面的对比分析，可以发现:

  1. 批式计算是流式计算的特例，Everything is Streams，有界数据集(批式数据)也是一种数据流、一种特殊的数据流;
  2. 而OLAP计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。

理论上，我们是可以用一套引擎架构来解决上述三种场景,只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。

流/批/OLAP业务场景概述

OLAP的典型特征是高并发查询，查询返回时间有很严格的时延要求，需要高性能支持。

image-20220810111344470

Flink做OLAP优势

统一引擎：流处理、批处理、OLAP统一使用Flink引擎

  • 降低学习成本，仅需要学习一个引擎
  • 提高开发效率，很多SQL是流批通用
  • 提高维护效率，可以更集中维护好一个引擎

既有优势：利用Flink已有的很多特性，使OLAP使用场景更为广泛

  • 使用流处理的内存计算、Pipeline
  • 支持代码动态生成
  • 也可以支持批处理数据落盘能力

相互增强：OLAP能享有现有引擎的优势，同时也能增强引擎能力

  • 无统计信息场景的优化
  • 开发更高效的算子
  • 使Flink同时兼备流、批、OLAP处理的能力，成为更通用的框架

Flink支持的应用场景

Apache Flink支持的3种典型应用场景：

  1. 事件驱动的应用
  • 反欺诈
  • 基于规则的监控报警
  1. 流式Pipeline
  • 数据ETL
  • 实时搜索引擎的索引
  1. 批处理&流处理分析
  • 网络质量监控
  • 消费者实时数据分析

Flink电商流批一体实践

目前电商业务数据分为离线数仓和实时数仓建设，离线和实时数据源，计算引擎和业务代码没有统一 ,在开发相同需求的时候经常需要离线和实时对齐口径，同时，由于需要维护两套计算路径，对运维也带来压力。

从数据源,业务逻辑，计算引擎完成统一，提高开发和运维效率。

Flink OLAP实践

下图中：上面是原来的链路;下面是走HTAP之后的链路，Flink直接提供数据查询与分析的能力。

image-20220810112612462