这是我参与「第四届青训营」笔记创作活动的第2天。
课程目录
1. Flink概述
2. Flink整体架构
3. Flink架构优化
4. 精选案例讲解
1.Flink概述
1.1 Apache Flink诞生背景
1.1.1 什么是大数据
- Value 价值化
- Volumes 海量化
- Velocity 快速化
- Variety 多样化
1.1.2 大数据计算架构发展历史
- 史前阶段~2006：传统数仓、Oracle、单机、黑箱使用
- Hadoop：分布式、Map-Reduce、离线计算
- Spark：批处理、流处理、SQL高阶API、内存迭代计算
- Flink：流计算、实时、更快、流批一体、Streaming/Batch SQL
1.1.3 为什么需要流式计算
大数据的实时性带来的价值更大，大数据的实时性的需求，带来了大数据计算架构模式的变化。
graph LR
批式计算--> 流式计算
- 批式计算：离线计算，非实时；静态数据集；小时/天等周期性计算
- 流式计算：实时计算，快速、低延迟；无限流、动态、无边界；7*24h持续运行；流批一体
1.2 为什么Apache Flink会脱颖而出
1.2.1 流式计算引擎发展历程
1.2.2 流式计算引擎对比
流式计算框架对比
1.2.3 Why Flink
Flink是一个可以基于有界数据集和无界数据集之上的有状态计算的分布式处理框架。
1.3 Apache Flink开源生态
Flink社区的开源生态图
2.Flink整体架构
2.1 Flink分层架构
Flink各个模块的用途
- SDK层：SQL/Table\DataStream\Python
- 执行引擎层（Runtime层）：执行引擎层提供了统一的DAG，用来描述数据处理的Pileline，不管是流还是批，都会转化为DAG图，调度层再把DAG转化成分布式环境下的Task，Task之间通过Shuffle传输数据
- 状态存储层：负责存储算子的状态信息
- 资源调度层：目前Flink可以支持部署在多种环境
2.2 Flink整体架构
- JobMannager（JM）：负责整个任务的协调工作，包括：调度task、触发协调task做Checkpoint、协调容错恢复等
- TaskManager（TM）：负责执行一个DataFlow Graph的各个task以及data streams的buffer和数据交换
- JobMannager职责 个人理解：Client端将用户代码抽象为逻辑执行图（DAG图），提交给JobMaster，JobMaster将逻辑执行图转化为物理执行图，JobMaster向ResourceManager申请slot，TaskManager拉起后会向ResourceManager注册，ResourceManager反馈给JobMaster,JobMaster将物理执行图的作业逻辑以及相关的Task调度到不同的Worker节点去执行。
2.3 Flink作业示例
2.4 Flink如何做到流批一体
2.4.1 为什么需要流批一体
痛点
- 人力成本比较高
- 数据链路冗余
- 数据口径不一致
2.4.2 流批一体的挑战
特点
区别
2.4.3 Flink如何做到流批一体
主要从以下几个模块来做流批一体
- SQL层
- DataStream API层统一，流和批都可以使用DatsStream API来开发
- Scheduler层架构统一，支持流批场景
- Failover Recovery层架构统一，支持流批场景
- Shuffle Service层架构统一，流批场景选择不同的Shuffle Service
2.4.4 流批一体的Scheduler层
Scheduler主要负责将作业的DAG转化为在分布式环境中可以执行的Tast
在1.12之前的Flink版本支持的调度模式
| 模式 | 特点 | 场景 | |
|---|---|---|---|
| EAGER | 申请一个作业所需要的全部资源，然后同时调度这个作业的全部Task，所有的Task之间采取Pipekine的方式进行通信 | Stream作业场景 | 12个task会一起调度，集群需要有足够的资源 |
| LAZY | 先调度上游，等待上游产生数据或结束后再调度下游，类似Spark的Stage执行模式 | Batch作业场景 | 最少调度一个task即可，集群有一个slot资源可以运行 |
- ALL_EDGES_BLOCKING：所有Task之间的数据交换都是BLOCKING模式，分为12个pipeline region
- ALL_EDGES_PIPELINED：所有Task之间的数据交换都是PIPELINE模式，分为1个pipeline region
2.4.5 流批一体的Shuffle Service层
在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle。
针对不同的分布式计算框架，Shuffle有不同的实现：
- 基于文件的Pull Based Shuffle：比如Spark或MR；特点：具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，容错性和稳定性更好
- 基于Pipeline的Pull Based Shuffle：比如Flink、Storm、Presto等；特点：低延迟，高性能，但是因为shuffle的数据没有存储下来，如果是batch任务的话，就需要进行重跑恢复
流和批Shuffle的差异
- Shuffle数据的生命周期
- Shuffle数据存储介质
- Shuffle的部署方式
-
在Streaming和OLAP场景：为了性能的需要通常会使用基于Pipeline的Shuffle模式
-
在Batch场景：一般会选取Blocking的Shuffle模式
2.4.6 Flink流批一体的总结
Flink在架构设计上针对DataStream层、调度层、Shuffle Service层均完成了对流和批的支持。
3.Flink架构优化
3.1 流/批/OLAP业务场景概述
三种业务场景的特点比对
三种业务场景的解决方案的要求及带来的挑战
3.2 三种业务场景为什么可以用一套引擎来解决
3.3 Flink的OLAP的优化之路
3.3.1 Flink做OLAP的优势
- 既有优势：内存计算、Code-gen、Pipeline Shuffle、Session模式的MPP架构
- 引擎统一：较低成本、提高效率
- 生态支持：跨数据源查询、TCP-DS基准测试性能强
3.3.2 Flink OLAP场景的挑战
- 秒级和毫秒级的小作业
- Latency + QPS的要求
- 作业频繁启停，资源碎片
