这是我参与「第四届青训营」笔记创作活动的第2天
课程目录
01.Flink概述
为什么会有流式计算的需求，为什么Flink能够脱颖而出，Flink当前的开源生态
02.Flink整体架构
Flink当前的整体架构介绍，一个Flink作业如何调度和运行起来，Flink如何做到流批一体
03.Flink架构优化
流/批/OLAP三种业务场景描述，Flink如何支持OLAP场景需求，需要做哪些架构上的优化
04.精选案例讲解
选择两个字节内部真实的案例场景，介绍Flink在流批一体以及OLAP上的实践
01.Flink概述
1.1 Apache Flink的诞生背景
1.1.1 什么是大数据
大数据（Big Data）:指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合。
1.1.2 大数据计算架构发展历史
1.1.3 为什么需要流式计算
大数据的实时性带来价值更大，比如:
1.监控场景:如果能实时发现业务系统的健康状态，就能提前避免业务故障;
2.金融风控:如果实时监测出异常交易的行为，就能及时阻断风险的发生;
3.实时推荐:比如在抖音，如果可以根据用户的行为数据发掘用户的兴趣、偏好，就能向用户推荐更感兴趣的内容;
4....
大数据实时性的需求，带来了大数据计算架构模式的变化
1.2 为什么Apache Flink 会脱颖而出
1.2.1 流式计算引擎发展历程
大数据如果从Google对外发布MapReduce论文算起，已经前后跨越将近二十年，业内常用的计算框架演化历史(红框是流式计算框架)
1.2.2 流式计算引擎对比
1.2.3 Why Flink
Apache Flink是一个开源的流处理框架，应用于分布式、高性能、高可用的数据流应用程序。可以处理有限数据流和无限数据，即能够处理有边界和无边界的数据流。无边界的数据流就是真正意义上的流数据，所以Flink是支持流计算的。有边界的数据流就是批数据，所以也支持批处理的。不过Flink在流处理上的应用比在批处理上的应用更加广泛，统一批处理和流处理也是Flink目标之一。Flink可以部署在各种集群环境，可以对各种大小规模的数据进行快速计算。
1.3 Apache Flink开源生态
Flink社区的开源生态
02.Flink整体架构
2.1 Flink分层架构
▪️ Flink各个模块的用途
一个Flink集群，主要包含以下两个核心组件:
- JobManager (JM) :负责整个任务的协调工作，
包括:调度task、触发协调Task做Checkpoint、协调容错恢复等;
- TaskManager (TM)
负责执行一个DataFlow Graph的各个task以及data streams的buffer和数据交换。
2.2 Flink整体架构 - JobManager职责
1）Dispatcher:接收作业，拉起JobManager来执行作业，并在JobMaster挂掉之后恢复作业;
2）JobMaster:管理一个job的整个生命周期，会向ResourceManager申请slot, 并将task调度到对应TM上;
3）ResourceManager:负责slot资源的管理和调度，Task manager拉起之后会向RM注册;
2.3 Flink作业示例
流式的WordCount示例，从kafka中读取一个实时数据流，每10s统计一次单 词出现次数，DataStream 实现代码如下:
业务逻辑转换为一个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.在抖音中，按天统计创造者的一些数据信息，比如昨天的播放量有多少、评论量多少、广告收入多少;
上述架构有一些痛点: 1.人力成本比较高:批、流两套系统，相同逻辑需要开发两遍;
2.数据链路冗余:本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费;
3.数据口径不一致:两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。
2.4.2 流批一体的挑战
流和批业务场景的特点如下表：
批式计算相比于流式计算核心的区别如下表：
2.4.3 Flink如何做到流批一体
为什么可以做到流批一体呢？
1.批式计算是流式计算的特例，Everything is Streams,有界数据集(批式数据)也是一种数据流、一种特殊的数据流;
因此，理论上我们是可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。
站在Flink 的角度，Everything is Streams,无边界数据集是一种数据流， 一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集(批式数据)也是一种数据流 。
因此，不管是有边界的数据集（批式数据)还是无边界数据集，Flink 都可以天然地支持，这是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模式
1）12个task会一起调度，集群需要有足够的资源
● LAZY模式
1）最小调度-个task即可，集群有1个slot资源可以运行
● 由Pipeline的数据交换方式连接的Task构成为一一个Pipeline Region;
● 本质上，不管是流作业还是批作业都是按照Pipeline Region粒度来申请资源和调度任务。
● ALL EDGES BLOCKING: 1）所有Task之间的数据交换都是BLOCKING模式; 2）分为12个pipeline region;
● ALL EDGES PIPEL INED: 1）所有Task之间的数据交换都是PIPELINE模式; 2）分为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之间的差异:
-
Shuffle 数据的生命周期:流作业的Shuffle数据与Task是绑定的，而批作业的Shuffle数据与Task是解耦的;
-
Shuffle 数据存储介质:流作业的生命周期比较短、而且流作业为了实时性，Shuffle 通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里;
-
Shuffle 的部署方式:流作业Shuffle服务和计算节点部署在一起，可以减少网络开销，从而减少latency,而批作业则不同。
Flink对于流和批提供两种类型的Shuffle,虽然Streaming和Batch Shuffle在具体的策略上存在一定的差异，但本质上都是为了对数据进行Re-Partition,因此不同的Shuffle 之间是存在一定的共性的。
所以Flink的目标是提供一套统一的Shuffle架构，既可以满足不同Shuffle在策略上的定制，同时还能避免在共性需求上进行重复开发。
▪️ 在Streaming和OLAP场景 1）为了性能的需要，通常会使用基于Pipeline的Shuffle模式 ▪️ 在Batch场景 1）一般会选取Blocking的Shuffle模式
为了统一Flink在Streaming和Batch模式下的Shuffle架构，Flink 实现了一个Pluggable的Shuffle Service框架，抽象出-些公共模块。
对于Shuffle Service，Flink 开源社区已经支持:
-
Netty Shuffle Service:既支持pipeline又支持blocking, Flink 默认的shuffle Service策略;
-
Remote Shufle Service:既支持pipeline 又支持blocking,不过对于pipeline 模式，走remote反而会性能下降，主要是有用在batch的blocking场景，字节内部是基于CSS来实现的RSS。
2.4.6 Flink流批一体总结
经过相应的改造和优化之后，Flink 在架构设计上，针对DataStream层、调度层、Shuffle Service层，均完成了对流和批的支持。
至此，业务已经可以非常方便地使用Flink解决流和批场景的问题了。
03.Flink架构优化
3.1 流/批/OLAP业务场景概述
在实际生产环境中，针对不同的应用场景，我们对数据处理的要求是不同的:
1.有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高，典型的应用是搜索引擎构建索引;
2.有些场景下，需对数据进行实时分析，要求每条数据处理延迟尽可能低，典型的应用是广告推荐、金融风控场景。
举个例子:
1.在抖音中，实时统计一一个短视频的播放量、点赞数，也包括抖音直播间的实时观看人数等;
2.在抖音中，按天统计创造者的一些数据信息，比如昨天的播放量有多少、评论量多少、广告收入多少;
3.在抖音的一-些推广活动中，运营同学需要对一些实时产出的结果数据做一些实时多维分析，来帮助后面活动的决策。
三种业务场景的特点比对如下表：
三种业务场景的解决方案的要求及带来的挑战是：
3.2 三种业务场景为什么可以使用一套引擎解决
通过前面的对比分析，可以发现:
1.批式计算是流式计算的特例，Everything is Streams,有界数据集( 批式数据)也是一种数据流、一种特殊的数据流;
2.而OLAP计算是一-种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。
因此，理论.上，我们是可以用一套引擎架构来解决上述三种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。
Apache Flink从流式计算出发，需要想支持Batch和OL AP场景，就需要解决下面的问题:
3.3 Flink的OLAP的优化之路
3.3.1 Flink做OLAP的优势
3.3.2 Flink OLAP场景的挑战
3.3.3 Flink OLAP架构现状
● Client: 提交SQL Query;
● Gateway
1）接收Client提交的SQL Query,对SQL进行语法解析和查询优化，生成Flink作业执行计划，提交给Session集群;
● Session Cluster
1）执行作业调度及计算，并返回结果。
架构与功能模块:
-
JobManager 与ResourceManager在一个进程内启动，无法对JobManager进行水平扩展;
-
Gateway 与Flink Session Cluster互相独立，无法进行统一管理。
作业管理及部署模块:
-
JobManager 处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存;
-
TaskManager 部署计算任务时，任务初始化部分耗时严重，消耗大量CPU。
资源管理及计算任务调度:
1.资源申请及资源释放流程链路过长
2.Slot 作为资源管理单元，JM管理slot资源，导致JM无法感知到TM维度的资源分布，使得资源管理完全依赖于ResourceManager
其他:
1.作业心跳与Failover机制，并不合适AP这种秒级或毫秒级计算场景;
2.AP目前使用Batch算子进行计算，这些算子初始化比较耗时;
Apache Flink最终演进到结果如下：
04.Flink使用案例
4.1 电商流批一体实践
抖音电商业务原有的离线和实时数仓架构如下图:
Flink社区的现状
目前电商业务数据分为离线数仓和实时数仓建设，离线和实时数据源，计算引擎和业务代码没有统一，在开发相同需求的时候经常需要离线和实时对齐口径，同时，由于需要维护两套计算路径，对运维也带来压力。
从数据源，业务逻辑，计算引擎完成统一，提高开发和运维效率。
演进目标
▪️ Flink OLAP场景实践
Flink的OLAP在字节内部的场景主要是HTAP场景。
Millisecond Level Delay
字节内部一个业务实践:
1）上面是原来的链路;
2）下面是走HTAP之后的链路，Flink 直接提供数据查询与分析的能力。
课程总结
- Flink 概述
1）流式计算场景及流式计算框架发展历程
2）业内主要流式计算框架对比、为什么Flink能够脱颖而出;
- Flink 整体架构
1）Flink 的分层架构、Flink 当前的整体架构介绍;
2）一个Flink作业如何调度和运行起来;
3）Flink 如何做到流批一体;
- Flink 架构优化
1）流/批/OL AP三种业务场景概述;
2） Flink如何来支持OL AP场景需求，需要做哪些架构上的优化;
4.精选案例讲解
