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

1. Flink概述

1.1. Apache Flink诞生的背景

1.1.1. 什么是大数据

大数据（Big Data）：指无法在一定时间内用常规软件工具对其进行获取、存储和处理的数据集合

如下为大数据的四大特点：

1.1.2. 大数据计算架构的发展历史

1.1.3. 为什么要使用流式计算：

大数据实时性的要求，带来了大数据架构的变化：批式计算 -> 流式计算

1.2. 为什么Apache Flink会脱颖而出

1.2.1. 流式引擎发展过程

1.2.2. 流式计算引擎对比：

1.2.3. 为什么选择Flink

Apache Flink是一个可以基于无界和有界数据集之上有状态计算的框架和分布式处理引擎
--Apache Fink社区

1.3.Apache Flink开原生态

2. Flink整体架构

2.1. Flink分层架构

1、SDK层：分三类：SQL/Table、DataStream、Python;

2、执行引擎层(Runtime层) ：执行引擎层提供了统一的DAG,用来描述数据处理的Pipeline,不管是流还是批，都会转化为DAG图，调度层再把DAG转换成分布式环境下的Task，Task之间通过Shuffe传输数据

3、状态存储层：负责存储算子的状态信息

4、资源调度层：目前Flink可以支持部署在多种环境

2.2. Flink总体架构

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

1、JobManager(JM)：负责整个任务的协调工作，包括：调度task、触发协调Task做Checkpoint、协调容错恢复等；

2、TaskManager(TM)：负责执行一个DataFlowGraph的各个task以及data streams的buffer和数据交换

Flink总体架构——JobManager职责

Dispatcher：接收作业，拉起JobManager来执行作业，并在JobMaster挂掉之后恢复作业
JobMaster：管理一个job的整个生命周期，会向ResourceManager申请slot，并将task调度到对应TM上;
ResourceManager：负责slot资源的管理和调度，Task manager拉起之后会向RM注册;

2.3. Flink作业示例

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

DataStream<String> lines = env.addSource(new FlinkKafkaConsumer<>(...)); //Source  
DataStream<Event> events = lines.map((line) -> parse(line)); //Transformation 
DataStream<Statistices> stats = events 
                        .keyBy(event -> event.id) 
                        .timeWindow(Time.second(10))
                        .apply(newMyWindowAggregationFunction()); //Transformation 
stats.addSink(new BucketingSink(path)); //Sink

业务逻辑转换为一个Streaming DataFlow Graph

假设作业的Sink算子的并发配置为1，其余算子并发为2，紧接着会将上面的Streaming DataFlow Graph转化Parallel Dataflow(内部叫Execution Graph)：

为了更高效地分布式执行，Flink会尽可能地将不同的operator链接(chain)在一起形成Task。

这样每个Task可以在一个线程中执行，内部叫做OperatorChain，如下图地source和map算子可以Chain在一起

最后将上面的Task调度到具体地TaskManager中的slot中执行，一个slot只能运行同一个task的subTask

2.4. Flink如何做到流批一体

2.4.1. 为什么要做到流批一体

举个例子：

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

传统的解决架构：

上述架构有一些痛点： 1、人力成本较高：批、流两套系统，相同逻辑需开发两遍

2、数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两边，产生一定的资源浪费

3、数据口径不一致：两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰

2.4.2. 流批一体的挑战

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

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

2.4.3. Flink如何做到流批一体

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

1、批式计算是流式计算的特例，Everythine is Streams，有界数据集(批式数据)也是一种数据流、一种特殊的数据流;

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

站在Flink角度，Everything is Stream，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集(批式数据)也是一种数据流

因此，不管是有边界的数据集(批式数据)还是无边界的数据集，Flink都可以天然地支持，这是Flink支持流批一体的基础，并且Flink在流批一体上，从上面的API到底层的处理机制都是统一的，是真正意义上的流批一体。

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

1、SQL层

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

3、Scheduler层架构同意，支持流批场景

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

5、Shuffe Service层架构统一，流批场景选择不同的Shuffe Service

2.4.4. 流批一体的Scheduler层

Scheduler主要负责将作业的DAG转化为在分布式环境中可执行的Task

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

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

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

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

为了适应eager和lazy两种场景，产生了Pipeline Region Scheduler

ALL_EDGES_BLOCKING:
- 所有Task之间的数据交换都是BLOCKING模式;
- 分为12个pipeline region;
ALL_ENDGES_PIPELINED:
- 所有Task之间的数据交换都是PIPELINE模式;
- 分为1个pipeline region;

2.4.5. 流批一体的Shuffle Service层

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

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

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

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

2、基于Pipeline的Push Based Shuffle，比如Flink、Storm、Presto等，它的特点是低延迟和高性能，但是因为Shuffle数据没有存储下来，如果是batch任务的话，就需要进行重跑恢复

流和批Shuffle之间的差异：

1、Shuffle数据的生命周期：流作业的Shuffle数据与Task是绑定的，而批作业的Shuffle数据与Task是解耦的

2、Shuffle数据存储介质：流作业得到生命周期比较短，而且流作业为了实时性，Shuffle通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里

3、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策略;
Remote Shuffle Service：既支持pipeline又支持blocking，不过对于pipeline模式，走remote反而会性能下降，主要是有用在batch的blocking场景，字节内部是基于CSS来实现RSS

2.4.6. 流批一体总结

经过相应的改造和优化之后，Flink在架构设计上，针对DataStream层、调度层、Shuffle Service层，均完成了对流和批的支持，至此，业务已经可以非常方便地使用Flink解决流和批场景的问题了

3. Flink架构优化

3.1. 流/批/OLAP业务场景概述

三种业务场景的特点比对如下表：

三种业务场景的解决方案的要求及带来的挑战是：

3.2. 为什么三种业务场景为什么可以用一套引擎来解决

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

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

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

Apache Flink从流式计算除法，需要想支持Batch和OLAP场景，就需要解决下面的问题：

3.3. Flink的OLAP的优化之路

3.3.1. Flink做OLAP的优势

3.3.2. Flink OLAP场景的挑战

3.3.3. Flink OLAP架构现状

Client：提交SQL Query;
Gateway
- 接收Client提交的SQL Query,对SQL进行语法解析和查询优化，生成Flink作业执行计划，提交给Session集群
Session Cluster
- 执行作业调度及计算，并返回结果

3.3.4. Flink在OLAP架构的问题与设想

架构与功能模块

JobManager与Resource在一个进程内启动，无法对JobManager进行水平扩展;
Gateway与Flink Session Cluster互相独立，无法进行统一管理

作业管理及部署模块

JobManager处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存;
TaskManager部署计算任务时，任务初始化部分耗时严重，消耗大量CPU

资源管理及计算任务调度

资源申请及资源释放流程链路过长
Slot作为资源管理单元，JM管理slot资源，导致JM无法感知到TM维度的资源分布，使得资源管理完全依赖于ResourceManager

其它

作业心跳与Failover机制，并不合适AP这种秒级或毫秒计算场景;
AP目前使用Batch算子进行计算，这些算子初始化比较耗时间;

3.3.5. 总结

Apache Flink最终演进到结果如下：

4. 经典案例

4.1. 电商流批一体实践

抖音电商业务原有的离线和实时数仓架构如下图：

Flink社区现状

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

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

演进目标

4.2. 字节Flink OLAP实践

Flink的OLAP在字节内部的场景主要是HTAP场景

字节内部的一个业务实践：

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

流/批/OLAP 一体的 Flink 引擎介绍 | 青训营笔记