01、Flink概述
1.1Apache Flink诞生背景
(1)什么是大数据
指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据
特点：价值化、海量化、多样化、快速化
(2)大数据计算架构发展史
06年之前(史前阶段)：传统数仓、Oracle、单机、黑箱使用
Hadoop：分布式、Map-Reduce、离线计算
Spark：批处理、流处理、SQL高阶API、内存迭代计算
Flink：流计算、实时，更快、流批一体、Streaming/Batch SQL
(3)为什么需要流式计算
大数据的实时性带来的价值更大，比如：
1、监控场景：实时发现业务系统的健康状态，提前避免业务障碍
2、金融风控：实时监测出异常交易行为，及时阻断风险产生
3、实时推荐：应用根据用户的行为数据发掘用户的兴趣、偏好，向用户推荐更感兴趣的内容 ...
大数据实时性的需求，带来了大数据计算架构模式的变化
批式计算(以前)： 离线计算(非实时)， 静态数据集， 小时/天等周期性计算
流式计算(现在)： 实时计算，快速、低延迟， 无限流、动态、无边界， 7*24h持续运行， 流批一体
1.2、为什么Apache Flink会脱颖而出
(1)流式计算引擎发展历程
如果从Google对外发布MapReduce论文算起，已经前后跨越将近二十年，业内常用的计算框架演化历史
(红框是流式计算框架)
(2)流式计算引擎对比
框架对比：
(3)Flink官方介绍
Apache Flink是一个可以基于无界和有界数据集之上有状态计算的框架和分布式处理引擎
关于Flink：Exactly-Once(精确一次的计算语义)、状态容错(Checkpoint)、Dataflow(Window等高阶需求支持友好)、流批一体
1.3、Apache Flink开源生态
02、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和数据交换
2.2、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(new MyWindowAggregationFunction()); //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如何做到流批一体
(1)为什么需要流批一体
例如抖音实时统计短视频播放量、点赞数、直播实时人数等
上述架构有一些痛点：
1、人力成本较高：批、流两套系统，相同逻辑需开发两遍
2、数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两边，产生一定的资源浪费
3、数据口径不一致：两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰
(2)流批一体的挑战
流和批业务场景的特点如下表：
批式计算相比于流式计算核心的区别如下表：
(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
(4)流批一体的Scheduler层
Scheduler主要负责将作业的DAG转化为在分布式环境中可执行的Task
在1.12之前的Flink版本中，Flink支持以下两种调度模式：
EAGER模式
16个task会一起调度，集群需要有足够的资源
LAZY模式 最小调度一个task即可，集群有1个slot资源可以运行
由Pipeline的数据交换方式连接的Task构成为一个Pineline Region
本质上，不管是流作业还是批作业，都是按照Pipeline Region粒度来申请资源和调度任务
ALL_EDGES_BLOCKING:
所有Task之间的数据交换都是BLOCKING模式;
分为12个pipeline region;
ALL_ENDGES_PIPELINED:
所有Task之间的数据交换都是PIPELINE模式;
分为1个pipeline region;
(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开源社区已经支持：
1、Netty Shuffle Service：既支持pipeline又支持blocking，Flink默认的Shuffle Service策略;
2、Remote Shuffle Service：既支持pipeline又支持blocking，不过对于pipeline模式，走remote反而会性能下降，主要是有用在batch的blocking场景，字节内部是基于CSS来实现RSS
Flink流批一体总结：
经过相应的改造和优化之后，Flink在架构设计上，针对DataStream层、调度层、Shuffle Service层，均完成了对流和批的支持，至此，业务已经可以非常方便地使用Flink解决流和批场景的问题了
03、Flink架构优化
3.1、流/批/OLAP业务场景概述
在实际生产环境中，针对不同的应用场景，我们对数据处理的要求是不同的
1、有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高，典型的应用是搜索引擎构建索引
2、有些场景下，需对数据进行实时分析，要求每条数据处理延迟尽可能低，典型的应用是广告推荐、金融风控场景
三种业务场景的特点比对如下表：
三种业务场景的解决方案的要求及带来的挑战是：
3.2、三种业务场景为什么可以用一套引擎来解决
通过前面的对比分析，可以发现：
1、批式计算是流式计算的特例，Everything is Streams,有界数据集(批式数据)也是一种数据流、一种特殊的数据流
2、而OLAP计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大的区别
因此，理论上，我们是可以用一套引擎架构来解决上述三种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略
Apache Flink从流式计算除法，需要想支持Batch和OLAP场景，就需要解决下面的问题：
3.3、Flink的OLAP的优化之路
(1)、Flink做OLAP的优势
(2)、Flink OLAP场景的挑战
(3)、Flink OLAP架构现状
Client：提交SQL Query;
Gateway
接收Client提交的SQL Query,对SQL进行语法解析和查询优化，生成Flink作业执行计划，提交给Session集群
Session Cluster
执行作业调度及计算，并返回结果
架构与功能模块：
1、JobManager与Resource在一个进程内启动，无法对JobManager进行水平扩展;
2、Gateway与Flink Session Cluster互相独立，无法进行统一管理
作业管理及部署模块： 1、JobManager处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存;
2、TaskManager部署计算任务时，任务初始化部分耗时严重，消耗大量CPU
资源管理及计算任务调度：
1、资源申请及资源释放流程链路过长
2、Slot作为资源管理单元，JM管理slot资源，导致JM无法感知到TM维度的资源分布，使得资源管理完全依赖于ResourceManager
其它：
1、作业心跳与Failover机制，并不合适AP这种秒级或毫秒计算场景;
2、AP目前使用Batch算子进行计算，这些算子初始化比较耗时间;
3.3.5总结：
Apache Flink最终演进到结果如下：
04、Flink使用案例
4.1、电商流批一体实践
抖音电商业务原有的离线和实时数仓架构如下图：
Flink社区现状
目前电商业务数据分为离线数仓和实时数仓建设，离线和实时数据源，计算引擎和业务代码没有统一，在开发相同需求的时候经常需要离线和实时对齐口径，同时，由于需要维护两套计算路径，对运维也带来压力
从数据源，业务逻辑，计算引擎完成统一，提高开发和运维效率
演进目标
4.2、字节Flink OLAP实践
Flink的OLAP在字节内部的场景主要是HTAP场景
字节内部的一个业务实践：
上面是原来的链路;
下面是走HTAP之后的链路，Flink直接提供数据查询与分析的能力