这是我参与「第四届青训营 」笔记创作活动的的第2天。
本节课程主要分为 4 个方面：
1.Flink概述
2.Flink整体架构
3.Flink架构优化
4.精选案例讲解
一. Flink概述
1.1.1.什么是大数据：
大数据(Big data)：指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合。
1.1.3.为什么需要流式计算：
大数据的实时性带来价值更大，如：
1.监控场景，2.金融分控，3.实时推荐......
大数据实时性的需求，带来了大数据计算架构模式的变化。
1.2.2.流式计算引擎对比：
1.3.Apache Flink开源生态
Apache Flink 在开源生态上的能力比较强大，可以支持：
1.流批一体：支持流式计算和批式计算；
2.OLAP：Flink 可以支持 OLAP 这种短查询场景；
3.Flink ML：pyFlink、ALink、AIFlow 等生态支持 Flink 在 ML 场景的应用；
4.Gelly：图计算；
5.Stateful Function：支持有状态的 FAAS 场景；
二.Flink整体架构
2.1.Flink分层架构：
1).SDK层：Flink的SDK目前主要有三类，SQL/Table、DataStream、Python;
2).执行引擎层(Runtime层)：执行引擎层提供统一的DAG，用来描述数据处理的Pipeline,不管是流还是批，都会转化为DAG图，调度层再把DAG转化成分布环境下的Task,Taak之间通过Shuffle传输数据；
3).状态存储层：负责存储算子的状态信息；
4).资源调度层：目前Flink可以支持部署在多种环境。
2.2.Flink整体架构：
一个Flink集群，主要包含以下两个核心组件。
(1.)JobManager(JM)：负责整个任务的协调工作，包括:调度task、触发协调Task做Checkpoint、协调容错恢复等；
(2.)TaskManager(TM)：负责执行一个DataFlow Graph的各个task以及data streams 的buffer和数据交换。
2.2.1.JobManager职责
Ⅰ.Dispatcher：接受作业，拉起JobManager来执行作业，并在JobManager挂掉之后恢复作业；
Ⅱ.JobManager：管理一个job的整个生命周期，会向ResourceManager申请slot,并将task调度到对应TM上；
Ⅲ.ResourceManager：负责slot资源的管理的调度，Task manager拉起之后会向RM注册。
2.4.Flink如何做到流批一体
2.4.2.流批一体的挑战:
流式计算：1).实时计算
2).延迟在秒级以内
3).0~1s
4).广告推荐、金融风控
批式计算：1).离线计算
2).处理时间为分钟到小时级别，甚至天级别
3).10s~1h+
4).搜索引擎构建索引、批式数据分析
数据流：流式计算：无限数据集
批式计算：有限数据集
时延：流式计算：低延迟、业务会感知运行中的情况
批式计算：实时性要求不高，只关注最终结果产出时间
2.4.3.Apache Flink主要从以下几个模块来做流批一体：
1.SQL层；
2.DataStream API层统一，批和流都可以使用DataStream API开卡法；
3.Scheduler层架构统一，支持流批场景；
4.Failover Recovery层架构统一，支持流批场景；
5.Shuffle Service层架构统一，流批场景选择不同的Shuffle Service
2.4.4.流批一体的Scheduler层：
Scheduler主要负责将作业的DAG转化为在分布式环境中可以执行的Task
□ EAGER模式 12个task会一起调度，集群需要有足够的资源
□ LAZY模式 最小调度一个task即可，集群有1个slot资源可以运行
由Pipeline的数据交换方式连接的Task构成一个Pipeline Region;
□ ALL_EDGES_BLOCKING: 所有Task之间的数据交换都是BLOCKING模式； 分为12个pipeline region;
□ ALL_EDGES_PIPELINED: 所有Task之间的数据交换都是PIPELINED模式； 分为1个pipeline region;
2.4.5.流批一体的Shuffle Service层：
(1.)Shuffle:在分布计算中，用来链接数据交互的过程叫做Shuffle
◆ 基于文件的Pull Based Shuffle，比如Spark或MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一点；
◆ 基于Pipeline的Pull Based Shuffle，比如Flink、Storm、Presto等，它的特点是低延迟和高性能，但是因为shuffle数据没有存储下来，如果是batch任务的话，就需要进行重跑恢复。
(2.)流和批shuffle之间的差异：
○ Shuffle数据的生命周期：流作业的Shuffle数据与Task是绑定的，二批作业的Shuffle数据与Task是解耦的；
○ Shuffle数据存储介质：流作业的生命周期比较短、而且流作业为了实时性，Shuffle通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里；
○ Shuffle的部署方式：流作业的Shuffle服务和计算节点部署在一起，可以减少网络开销，从而减少latency,而批作业则不同；
(3.)Flink对于流和批提供两种类型的Shuffle，虽然Streaming和Batch Shuffle在具体的策略上存在一定的差异，但本质 上都是为了对数据进行Re-Partition,因此不同的Shuffle之间存在一定的共性的。
● 在Streaming和OLAP场景：
为了性能的需求，通常会使用基于Pipeline的Shuffle模式
●在Batch场景：
一般会选取Blocking的Shuffle模式
三.Flink架构优化
3.1流/批/OLAP业务场景概述
(1.)三种业务场景的特点对比如下：
(2.)三种业务场景的解决方案的要求及带来的挑战是：
3.2.三种业务场景为什么可以用一套引擎来解决:
1).批式计算是流式计算的特列，Everything is Streams，有界数据集(批式数据)也是一种数据流、一种特殊的数据流；
2).而OLAP计算是一种特殊的批式计算，它队并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。
3.3.Flink如何支持OLAP场景
3.3.1.Flink做OLAP的优势:
◎ 引擎统一：流处理、批处理、OLAP 统一使用 Flink 引擎；
◎ 既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；
◎ 生态支持：OLAP 能享有现有引擎的优势，同时也能增强引擎能力
3.3.2.Flink OLAP场景的挑战:
◎ 秒级和毫秒级的小作业
◎ Latency+QPS的要求
OLAP 最大的特点是查询作业对Latency和QPS有要求的，需要保证作业在Latency的前提下提供比较高的并发调度和执行能力，这就对Flink引擎提出了一个新的要求。
◎ 作业频繁启停，资料碎片
Flink OLAP 计算相比流式和批式计算，最大的特点是Flink OLAP计算是一个面向秒级和毫秒级的小作业，作业在启动过程中会频繁申请内存、网络以及磁盘资源，导致Flink集群内产生大量的资源碎片。
四.Flink使用案列
4.1电商流批一体实践
4.2Flink OLAP场景实践
