Flink 引擎介绍 || 青训营
这是我参与「第四届青训营 」笔记创作活动的的第2天
一、Flink概述
1.1Apache Flink的诞生背景
（1）什么是大数据
1.价值化（value）
2.海量化（volumes）
3.快速化（velocit）
4.多样化（variety）
1.1.2大数据计算架构发展历史
1.1.3为什么需要流式运算
1.可以用户的爱好可以推荐用户的爱好，也因为如此带来了大数据架构，模式的变化 也因此从离线变成流失运算。
1.2为什么Apache Flink会脱颖而出
1.2.2流式计算引擎对比
Streaming Model :
一致性保证：能不能做出一次性判断的能力。
延迟：计算框架的延长性是什么样的
容错：能不能恢复到之前的样子。
sql支持，能不能支持简单的SQL语句,提高业务迭代的水平
1.2.3 什么是Flink
Apache Flink是一个框架和分布式处理引擎，用于在无界和有界数据流上进行有状态计算。Flink被设计为在所有常见的集群环境中运行，执行内存速度和任何规模的计算。
对业内流式框架提供了友好的发展
`1.Exactly-Once(精确一次的计算语义)
2.状态容错（Checkpoint）
3.Dataflow编程模型Window等高阶需求支持友好
4.流批一体`
1.3 Apache Flink开源生态
FLink是计算框架，没有存储能力但是对存储引擎有很好导入，
Resource Manager 部署在框架或实体机或虚拟机。
GElly（Graph）关于图计算的框架
Flink ML对ML调度的框架
Statteful Function对于function存储框架的解决方案
二、FInk整体架构
2.1 Flink分层架构
SDK层：Flink的SDK目前主要有三类：SQL/Table、DataStream、PyFlink；
SQL/Table：用户对SQL的表达
DataStream：基于对sql表达能力不强运用java补充；
PyFlink：提供支持pyhton的支持
执行引擎层：执行引擎层提供了同一栋DAG用来描述数据处理的Pipeline，不管是流还是批，都会转化哪位DAG图，调度层再把DAG转化为分布式环境下的Task，Task之间通过Shuffle传输数据；
状态存储层：负责存储算子的状态信息；
资源调度层：目前Flink可以支持部署在多种环境；
2.2Flink整体架构
两个核心组件
`1.JobManager（JM）：负责整个任务的协调工作，包括：调度task、触发协调Task做checkpoint、协调容错恢复等；`
`2.TaskManager（TM）：负责执行一个DataFlowGraph的各个task以及data streams的buffer和数据交换；`
FinkProgarm
`所有的代码都会存储在这里然后转化为逻辑执行图然后发送给jobManager`
JobManager
`将转化到的执行图然后分达到各个部门执行`
1.Dispatcher:接收作业，拉起JobManager来执行作业，并在JobMaster挂掉之后恢复作业；
2.JobMaster:管理一个job的整个生命周期，会向ResouceManager申请slot，并将task调度到对于TM上；
3.ResouceManager:负责slot资源的管理和调度，Taskmanager拉起之后会向RM注册；
从Client存入Dispatcher然后JobMaster会向ResouceManager申请资源然后拉起的两个tm资源给JobMaster在分配到相应的节点上
2.3 Flink作业示例
Source：节点
map（）：解析
keyBY（）、window（）APPly（）：窗口的概念，对这些数据做出来
Sink：写出去
Source分为两个为子Source,map1可到1和2最后Sink keyby最后都会合并到SInk
把source和map结合一起Flink做了一个优化OPerator链接（chain）在一起形成一个Task，这样可以不用单点运行这样省略一个哈希表；
每一个solt都是一个线程。
2.4 Flink如何做到流批一体
实时统计主播的观看人数等。 可以看到播放量评论多少。
2.4.1为什么需要流批一体
流批一体的痛点：
1.人力成本搞：流批两套系统，相同逻辑需要开发两遍；
2.数据链余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费；
3.数据口径不一致：两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。
2.4.2流批源头的挑战
流式计算 批式计算
实时计算 离线计算
延迟在秒级以内 处理时间为分钟到小时级别，甚至天级别
0~1s 10s-1h+
广告推进、金融风控 搜索引擎构建索引。批式数据分析
`计算核心的区别`
维度 流式计算 批式计算
数据流 无限数据集 有限数据集
时延 低延迟、业务会感知运行中的情况 实用性要去不高，只关注最终结果产出时间
2.4.3 Flink如何做到流批一体
1.SQL层；
2.DataStream Apl层统一，批和流都可以使用.DataStream Apl来开放
3.Scheduler层架构统一，支持流批场景；
4.Failover Recovery层架构统一，支持流批场景；
5.Shuffle Service层架构统一，流批场景选择不同的Shuffle Service
2.4.4 流批一体的Scheduler层
Scheduler主要负责将作业的DAG转化为在分布式环境中可以执行的Task
在1.2之前的Flink版本中,Flink支持以下两张调度模式：
模式 特点 场景
EAGER 申请一个作业所需要的全部资源，然后同时调度这个作业的全部Task，所有task之间采取Pipeline的方式进行通信
Stream作业场景
EAGER需要所有task一起调用才可以运行
模式 特点 场景
LAZY 先调度上游，等待上游产生数据或结束后再调度下游，类似Spark的Stage执行模式
Batch作业场景
LAZY最少需要一个task一起调用才可以运行
ALL_EDGES_BLOCKING;
所有task之间的数据交换都是BLOCKING模式；
分为12pipeline region；
ALL_EDGES_PIPELINED;
所有task之间的数据交换都是PIPELINE模式；
分为1个pipeline region；
2.4.5 流批一体的Shuffle Service层
Shuffle：在分布式计算中，用来连接上下游数据交换的过程叫做Shuffle。 实际上，分布式计算中所有涉及到上下游衔接的过程都可以理解为SHuffle。
针对不同的分布式计算框架，Shuffle通常有几种不同的实现：
1.基于文件的Pull Based Shuffle，比如Spark或MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些；
2.基于Pipeline的Pull Based Shuffle，比如Flink、Storm、Presto等，它的特点是低延迟和高性能，但是因为shuffle数据没有存储下来，如果是batch任务的话，，就需要进行重跑恢复；
流和批shuffle的差异：
1.shuffle数据的生命周期：流作业的shuffle数据与task是绑定的，而批作业的shuffle数据与Task是解耦的；
2.shuffle数据存储介质：流作业的生命周期比较短、而且流作业为了实时性，Shuffle通常存储在内存中，批因为数据量比较打以及容错的需求，一般会存储在磁盘里；
3.shuffle的部署方式：流作业shuffle服务和计算节点部署在一起，可以减少网络开销，从而减少latency，而批作业则不同。
对于shuffle service，福利你看开源社区已经支持
1.Netty shuffle service：即支持pipeline又支持blocking，Flink默认的shuffle service策略；
2.Remote shuffle service：即支持pipeline又支持blocking，NG对于pipeline模式，走remote反而会性能下降，主要是有用在batch的blocking场景，字节内部是基于css来实现的Rss。
三、FInk架构优化
3.1 流/批/OLAP业务场景概述
1.有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高，典型的应用是搜索引擎构建索引；
2.有些场景下，需对数据进行实时分析，要求每条数据处理延迟尽可能低，典型的应用是广告推进、金融风控场景。
3.2 为什么三种场景可以用一套引擎来解决
1.批式技术是流式计算的特例，Everything IS streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
2.而OLAP技算是一种特殊的批式技术，它对并发和实时性要求很高，其他情况与普通批式作业没有特别大区别；
OLAP Engine 特殊的批式计数，要求速度快，可以用不同的方式优化。
OLAP场景需求；
短查询作业场景
高并发支持；
极致处理性能；
3.3 Flink如何支持OLAP场景
3.3.1Flink做OLAP的优势
3.1.2Flink OLAP场景的挑战
3.1.3Flink OLAP架构现状
Gateway：接受Client提交的SQL QUERY，对SQL进行语法解析和查询优化，生成Flink作业只想计划，提交给Session集群
Session Cluster：执行作业调度及计算，并返回结果；
提前把集群创建出来，不需要重新去申请资源，可以减少申请资源的过程
非常适合解决olap的问题
3.1.4Flink在OLAP架构的问题与设想
`架构和功能模块：`
1.JObManager与ResourceManager在一个进程内启动，无法对JobManager进行水平扩展；
2.Gateway与Flink Session Cludster相互独立，无法进行统一管理
`作业管理及部署模块：`
1.jobmanager处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存
2.TaskManager部署计算任务时，任务初始化部分耗时严重，消耗大量CPU
`资源管理及计算任务调度`
1.资源申请及资源释放流程链路过长
2.Slot作为资源管理单元，JM管理slot资源，导致JM无法感知到TM维度的资源分布，使得资源管理完全依赖于ResourceManager
`其他`
1.作业心跳与Failover机制，并不合适AP这种秒级或毫秒级计算场景；
2.AP目前使用Batch算子进行计算，这些算子初始化比较耗时；
总结
四、精选案例讲解
1.电商流批一体实践
`流批一体`
2.字节FLink OlAP实践
前面是在线后面是离线可以做到实现越低；
