这是我参与「第四届青训营 」笔记创作活动的的第2天.
课程内容
01.Flink概述
02.Flink整体架构
03.Flink架构优化
04.精选案例讲解
01.Flink概述
- Apache Flink的诞生背景
大数据（big data）：指无法在一定时间内用常规软件工具对其进行存取、存储、管理和处理的数据集合。
大数据的特点：海量化，价值化（价值密度低，但整体价值高），快速化（数据产生的速度），多样化。
大数据的特点
大数据计算架构的发展历史
需要流式计算的原因：大数据的实时性带来的价值更大
- 为什么Apache Flink会脱颖而出
Native：数据一条一条地处理
mini-batch：微小的批处理，把批处理切割成很小的一批模仿流处理
At least/Most once：只能保证数据至少被处理一次
StateFul:状态处理，No表示需要借助外部存储，Yes表示不需要借助外部系统，有自己状态的支持系统
Flink的容错特性将会在后续课程展开
- Apache Flink开源生态
DAG：Directed acyclic graph，无回路有向图，用DAG来描述数据处理的Pipeline，是大数据中抽象的逻辑表达
02.Flink整体架构
- Flink 分层架构
graph TD
SDK层//Flink有三类SDK --> 执行引擎层//统一的DAG用来描述数据处理的pipeline//流和批转化成DAG图//DAG转化成分布式环境下的Task-->状态存储层//存储算子的状态信息-->资源调度层//支持部署在多种环境
- Flink 整体架构
一个Flink集群，主要包含两个核心组件：JobManager、TaskManager
JM：负责整个任务的协调工作，调度task，触发协调task做checkpoint，协调容错恢复等
TM：负责执行一个Dataflow Graph的各个task以及data streams的buffer和数据交换
如上图所示：Flink Program模块，根据编程代码，由优化器或图像构造器生成DAG，逻辑图，再由client发送给JM，JM把逻辑图转化成物理图，再进行task调度
- Flink 作业示例
一个Flink作业在Flink中的处理流程，DataFlow Model的设计思想
分布式处理的并发处理：
优化，operator chain：减少线程的切换，将source和map操作合为一个线程
可以组成operator chain的算子需要满足一定的条件（去文档找Apache Flink Documentation | Apache Flink）
6. Flink 如何做到流批一体
6.1 为什么业内有流批一体的业务需求： ①流式处理：视频实时播放量，点赞数；②批式处理：按天统计创造者的数据信息（昨天的播放量，评论量，广告收入）。
实时数仓（流）和离线数仓（批）的架构：
倘若采用流式和批式分离的处理方式，①人力成本高，相同的逻辑需要开发两套系统；②数据链路冗余，本身计算内容一致时，两套链路导致相同逻辑需要运行两倍，造成资源浪费；③数据口径不一致，两套系统，两套算子，两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。
6.2 流批一体面临的挑战：
6.3 Flink怎么做到的：
Flink对处理方式进行了抽象，“Everything is Streams”，将批式计算视作流式计算的特例，有界的数据集看做是一种特殊的数据流。
6.3.1 流批一体调度层
版本1.12以前，Flink有两种处理模式，如下图所示，直线的两端，即pipeline region的两端的两个调度，在版本1.12以后的Flink利用pipeline抽象出了一个概念，能够兼容两种操作模式，在调度层统一了流式和批式的调度：
流批一体中的两种数据交换模式，倘若数据交换模式都是pipeline模式，就是pipeline region scheduler。blocking的意思是写入磁盘（落盘），pipeline模式，每一算子产生的结果在内存中存储，计算结果传递给下一个算子后不再保留：
6.3.2 流批一体Shuffle Service层
Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle。实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为Shuffle。
Shuffle的主要两个实现形式：
流和批Shuffle之间的差异：
Streaming Shuffle 和 Batch Shuffle在具体策略上存在差异，但本质都是为了对数据进行Re-partition，因此不同的Shuffle存在共性。Flink的目标就是提供一套统一的Shuffle架构，该架构可以满足不同Shuffle在策略上的定制，同时还能避免在共性需求的重复开发。
03.Flink架构优化
- 流/批/OLAP业务场景概述
- 为什么三种场景可以用一套引擎来解决
批式计算是流式计算的特例，而OLAP计算是一种特殊的批式计算，它除了对并发和实时性要求更高，其他情况与普通批式作业没有特别大的区别。因此，理论上，我们是可以用一套引擎架构来解决上述三种场景，只不过需要对不同的场景支持相应的扩展性，并允许做不同的优化策略。
4. Flink如何支持OLAP场景
OLAP场景需求：①短查询作业场景；②高并发支持；③极致处理性能
Flink做OLAP场景的优势：
Flink的进化之路：
