这是我参与「第四届青训营 」笔记创作活动的第2天
Flink
计算架构发展历史：史前阶段~2006 (单机，传统数仓) →\rightarrow→ Hadoop (分布式，Map-Reduce，离线计算) →\rightarrow→ Spark (批处理、流处理) →\rightarrow→ Flink (流计算、实时、流批一体)
优点
- 精确一次的计算语义 Exactly-Once
- 状态容错 Checkpoint
- Dataflow 编程模型，Window 等高阶需求支持友好
- 流批一体
Flink分层架构
- SDK层：SQL/TABLE，DataStream，Python
- 执行引擎层：提供统一的DAG，调度层把DAG转化成分布式环境下的Task，Task之间通过Shuffle传输数据
- 状态存储层：存储算子的状态信息
- 资源调度层：Yarn等资源调度
Flink总体架构
Client 端将用户的数据处理逻辑 pipeline 的内容转换为 DAG（有向无环图）的逻辑执行图并提交给 JM，JM 将其转化为具体的物理执行图，并 JM 根据物理执行图相关逻辑和对应的任务调度把 task 调度到不同的 TaskManager 中去执行。
- JobManager（JM） 主要负责调度 Job 并协调 Task 做 checkpoint，以 Task 的单元调度到各个 TaskManager 去执行
- TaskManager（TM） 中每个 slot 能启动一个 Task，接受+处理数据
流批一体
为什么需要流批一体？
- 实时统计短视频的播放量、点赞数和直播间观看人数
- 按天统计UP主的数据信息，如昨日播放量、评论数、广告收入等
缺点
- 开发逻辑重复
- 数据计算冗余，资源浪费
- 数据口径不一致：两套系统，算子，UDF，通常会产生不同的误差，会给业务开发造成麻烦
Flink在流批一体上，上层API和底层的处理机制都吃统一的，所以是真正意义上的流批一体
实现 Apache Flink 主要从以下几个模块来做流批一体：
- SQL层
- DataStream API 层
- Scheduler层
- Failover Recovery 层
- Shuffle Service层
Flink架构优化
OLAP（联机分析处理）：基于数据仓库实现的面向分析的各类操作集合。交互式分析(OLAP) 实时性高、查询延迟在秒级，但要求高并发查询。
批式计算是特殊的流式计算，而OLAP计算又是一种特殊的批式计算，所以理论上可以用Flink实现上述三种场景
