这是我参与「第四届青训营 」笔记创作活动的第1天
一、概述
1. 大数据计算架构发展
Hadoop（分布式，MapReduce) Spark(SQL高阶API, improve MapReduce, 表达更多语义) Flink(对实时性要求更高，流/批支持SQL)
2. WHY 需要流式计算？
【大数据的实时性带来更大价值】
a. 监控场景：实时发现业务系统的健康状态，提前避免故障
b. 金融风控：实时监测出异常交易的行为，及时阻断风险的发生
c. 实时推荐：eg抖音
etc..
【大数据实时性的需求，带来了大数据计算架构模式的变化】
批式 vs 流式
| 批式 | 流式 |
|---|---|
| 离线计算 | 实时计算 |
| 静态数据集 | 无限流、动态、无边界 |
| 小时/天等周期性计算 | 7*24持续运行 |
| 流批一体 |
3. 流式计算引擎对比
*** WHY Flink
a. Exactly-Once 精确一次的计算语义
b. Check Point 状态容错, 可以把出错前的状态恢复出来
c. Dataflow编程模型 Windows等高阶需求支持友好
d. 流批一体
4. Apache Flink开源生态
二、Flink 整体架构
1. Flink 分层架构 - 各个模块作用
2. Flink 总体架构
a. 在Client端，将用户的代码抽象为一个逻辑执行图，并提交给JM
b. 在JM，将这个逻辑执行图转化为物理执行图，将这个物理执行图的作业逻辑以及一些相关的task调度到不退worker执行
2.1 JM 的职责
3. Flink 作业示例 - 一个作业在Flink中的处理流程
a. 环境变量 - 从哪个地方读一个资源
b. map解析 - map为一对一解析处理，每一行调用一个parse，parse把空格拆开，拆成event格式
c. 窗口处理 - 统计单词出现的次数，keyby；apply，计算
d. 把数据写到某个地方
3.1 并发度
注：source拆为source1、source2， etc.
3.2 OperatorChain
a. 为了更高效地分布执行，Flink会尽可能地将不同的operator链接在一起形成task
b. 这样每一个task可以在一个线程中执行，内部叫做OperatorChain
c. 下图的source和map算子可以链接在一起
a. 可以减少线程切换、减少序列化与反序列化
b. 减少数据在TM缓冲区的交换
c. 提高了整体的吞吐力
a. 几个slot可以由用户定义
b. 每一个slot在TM里是由一个单独的线程执行
c. TM相当于一个进程
d. 每一个slot资源没有严格隔离，但是内存有一部分做了一些隔离
4. Flink 如何做到流批一体 - 流批一体的场景挑战
4.1 为什么需要流批一体
a. 实时统计 - 流
b. 一天的播放量 - 批
4.2 流批一体的挑战
痛点
流/批特点
4.3 Flink如何做到流批一体
批式是特殊的流式
具体操作:
a. SQL- 支持有边界/无边界处理
b. DataStream - 更多业务逻辑处理
c. etc..
4.4 流批一体的Scheduler层
Scheduler主要负责将作业的DAG转化为在分布式环境中可以执行的Task
Eager模式
Lazy模式
最新调度机制
Blocking: A1先执行，执行完成后存储，资源释放，B1再执行
Pipeline: A1产生的数据直接发给B1，不做落盘
4.5 流批一体的Shuffle Service层
Shuffle的形式
流和批Shuffle之间的差异
Flink的目标
Flink开源社区
三、Flink 架构优化
1. 流/批/OLAP 业务场景概述
不同场景对数据处理的要求不同
2. 为什么三种场景可以用一套引擎来解决
批是流的特例 ｜ olap是批的特例
olap短查询
3. Flink 如何支持OLAP场景
Flink做OLAP的优势
Flink OLAP场景的挑战
Flink OLAP架构现状
Flink在OLAP架构的问题与设想
