这是我参与「第四届青训营 」笔记创作活动的的第36天
Flink引擎介绍
Map-Reduce 中间结果需要落盘，性能较差
流式计算（实时性）：监控、金融风控、实时推荐
批式计算：等到数据全到位再计算（小时/天为单位）
流式计算：水龙头，数据源无限流
Spark是批处理模式，后面又出现了Spark Streaming将批作业划分为很小时间间隔的n个作业(mini-batch)，如10s，实现流式处理
- everything is stream(unbounded and bounded)：既可以处理流数据也可以处理批数据
- Checkpoint 状态容错
- Dataflow编程模型
- 流批一体
Flink整体架构
JobManager：整个任务的协调工作
TaskManager：执行一个DataFlow Graph
代码 -> 逻辑的执行图DAG图 -> Client端提交给JM -> JM转化其变为可执行的物理图 -> JM将物理图的task分配给taskmanager
WordCount案例
Flink会尽可能将不同的operator链接在一起形成Task，每个Task可以在一个线程中执行，如Source和map可以chain在一起
每个slot在TM中是一个线程在执行，内存没有严格隔离，一个slot只能运行同一个task的subTask
client端抽象为一个graph，JM
流批一体
抖音中，实时统计一个短视频的播放量、点赞数（流式处理）
抖音中，按天统计创造者的创作信息（批处理）
如何实现流批一体
Flink对Stream的抽象，有界数据集也是一种数据流
SQL层，有边界和无边界的数据集处理
批和流都可以使用DataStream API开发
调度层Scheduler
-
将作业的DAG转化为可以执行的Task
-
调度模式
-
EAGER：申请所有资源（流处理）
- keyBy根据hash值分发到不同结点
-
LAZY：最小调度一个task即可（批处理）
-
ALL_EDGES_BLOCKING模式：A1产出的数据需要经过落盘，再存在B1
-
ALL_EDGES_PIPELINE模式：A1的数据从内存直接传入B1，然后再释放该资源，12个结点相当于1个pipeline region
-
容错、恢复层
Shuffle Service，流批场景选择不同的Shuffle Service
-
用来连接上下游数据交互的过程叫做Shuffle
-
两种实现
- 基于文件：批处理，容错性高
- 基于Pipeline：流处理，低延迟高性能
-
生命周期
- 流作业Shuffle与Task绑定
- 流作业Shuffle存储在内存
- 流作业Shuffle和计算节点部署在一起，减少网络开销；批作业会有远端的Shuffle服务，保证安全性
-
Flink
- Netty：既支持pipeline又支持blocking
- Remote：
OLAP
交互式分析（OLAP）场景
高并发查询，秒级查询，极致处理性能
Flink如何支持OLAP
- online业务，用户数据变更update MySQL，离线业务，通过binlog同步到Hive，一般是以天/小时为单位，再放到ClickHouse，进行Query
- 通过HTAP，实现秒级处理
