这是我参加「第四届青训营」笔记创作的第2天

流/批/OLAP 一体的 Flink 引擎

01. Flink 概述

1.1 Apache Flink 的诞生背景

什么是大数据
- 大数据：指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合。
- 拥有数据海量化、数据多样化、数据产生快速化、数据价值密度低但总价值高等特点。
大数据计算框架发展历史

为什么需要流式计算
- 大数据的实时性带来的价值更大，比如：
  - 监控场景：如果能够实时发现业务系统的监控状态，就能提前避免业务的故障；
  - 金融风控：如果实时监测出异常交易行为，就能及时阻断风险的发生；
  - 实时推荐：比如在抖音，可以根据用户的行为数据发掘用户的兴趣、偏好，就能向用户推荐更感兴趣的内容；
- 大数据的实时性的需求，带来了大数据计算框架模式的变化：

1.2 为什么 Apache Flink 会脱颖而出

1.2.1 流式计算引擎发展历程

大数据如果从 Google 对外发布 MapReduce 论文算起，已经前后跨越将近二十年，业内常用的计算框架演化历史（红框是流式计算计算框架）

1.2.2 流式计算引擎对比

流式计算框架对比：

1.2.3 为什么是 Flink

Apache Flink 是一个有状态的、可以用于有边界和无边界数据流的分布式处理引擎。Flink 可在所有的数据环境、任何的数据范围内的内存级的计算。

1.3 Apache Flink 开源生态

02. Fink 整体架构

2.1 Flink 分层架构

SDK 层：Fink 的：SDK 目前主要有三类，SQL/Table、DataStream、Python;
执行引擎层（Runtime 层）：执行引擎层提供了统一的DAG，用来描述数据处理的Pipeline，不管是流还是批，都会转化为DAG 图，调度层再把 DAG 转化成分布式环境下的Task，Task 之间通过 shuffle 传输数据；
状态存储层：负责存储算子的状态信息；
资源调度层：目前 Flink 可以支持部署在多环境。

2.2 Flink 总体架构

一个Flink集群，主要包含以下两个核心组件：

JobManager(JM)：负责整个任务的协调调度工作，包括：调度task、触发协调Task做Checkpoint、协调容错恢复等；
TaskManager(TM)：负责执行一个DataFlow Graph的各个task以及data streams 的buffer和数据交换。

2.3 Flink 作业实列

流式的 WorkCount实列，从kafka中读取一个实时数据流，每10s统计一次单词出现次数，：DataStream实现代码如下：

2.4 Flink 如何做到流批一体

2.4.1 为什么需要流批一体

上述框架有一些疼点：

人力成本比较高：流、批两套系统，相同逻辑需要开发两遍；
数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费；
数据口径不一致：两套系、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方面带来很大的困扰。

2.4.2 流批一体的挑战

流和批业务场景的特点如下表：

批式计算相比于流式计算核心的区别如下表：

2.4.3 Flink 如何做到流批一体

为什么可以做到流批一体呢？

批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流;
因此，理论上我们可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做哦不同的优化策略。

站在Flink的角度， Everything is Streams,无边界数据集是一种数据流，一个无边界的数据流可以时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流。因此，不管有边界的数据集（批式数据）还是无边界的数据集，Flink都可以天然地支持，这是Flink支持流批一体的基础，并且在流批一体上，从上面的API到底层的处理机制都是统一的，是真正意义上的流批一体。

Apache Flink主要从以下几个模块来做流批一体：

SQL层
DataStream API层同一，批和流都可以使用DataStream API来开发；
Scheduler层架构统一，支持流批场景；
Failover Recovery层架构统一，支持流批场景；
Shuffle Service 层架构统一，流批场景选择不同的Shuffle Service。

2.4.4 流批一体的Scheduler层

Scheduler 主要将作业的DAG(有向无环图)转化为在分布式环境中可执行的Task。

在1.12之前的Flink版本中，Flink支持以下两种调度模式：

EAGER模式
- 16个task会一起调度，集群需要有足够的资源

LAZY模式
- 最小调度一个task即可，集群有1个slot资源就可以运行

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

ALL_EDGES_BLOCKING:
- 所有Task之间的数据交换都是BLOCKING模式（结果先到磁盘，下一任务再从磁盘中读取上一任务的结果）
- 分为12个pipeline region;
ALL_EDGES_PIPELINED:
- 所有Task之间的数据交换都是PIPELINE模式；
- 分为1个pipeline region；

2.4.5 流批一体的Shuffle Service层

Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle。

实际上，在分布式计算中所有涉及到上下游衔接的过程，都可以理解为Shuffle。

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

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

流批Shuffle之间的差异：

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

Flink对流和批提供两种类型的Shuffle，虽然Streaming和Batch Shuffle在具体的策略上存在一定的差异，但是本质上都是为了对数据进行Re-Partition，因此不同的Shuffle之间是存在一定的共性的。

所以Flink的目标是提供一套统一的Shuffle架构，既可以满足不同的Shuffle在策略上的定制，同时还可以避免在共性需求上进行重复开发。

在Streaming和OLAP场景
- 为了性能的需要，通常会使用基于Pipeline的Shuffle模式
在Batch场景
- 一般会选取Blocking的Shuffle模式

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

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

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