这是我参与「第四届青训营 」笔记创作活动的的第2天
一、Flink概述
Apache Flink的背景
- 大数据的实时性带来的价值更大：监控场景、金融风控、实时推荐
- 实时性需求带来了大数据技术框架的改变：批式处理变为流式处理
Flink为什么能脱颖而出
- 业内对大数据实时性产生了巨大的需求
- Dataflow编程模型对流计算起到了重大影响。
二、Flink整体架构
1.Flink的分层架构
- SDK层：SQL/Table、DataStream、Python；
- 执行引擎层：提供了统一的DAG，用来描述数据处理的Pipline，不管是流还是批，都会转换为DAG图，调度层再把DAG转换为分布式环境下的Task，Task通过Shuffle传输数据。
- 状态存储层：负责存储算子的状态信息
- 资源调度层：Flink可以部署在多种环境
2.Flink整体架构
俩个核心组件：
- 1.JobManager：负责整个任务的协调工作
- 2.TaskManager：负责执行DataFlow Graph的各个task以及data streams的buffer和数据交换。
3.Flink作业示例
lines=env.addSource(new FlinkKafkaConsumer<>(...)) #指定数据源
events=lines.map((line)->parse(line)); #拆解数据
stats=events.keyBy.... #处理数据
stats.addSink(new BucketingSink(path)); #输出数据
4.Flink如何做到流批一体
为什么需要流批一体
- 短视频的实施播放、点赞数；
- 抖音的播放量、收入、评论量
流批一体的挑战
- 流式计算：无限数据集、低延迟，业务会感觉到
- 批式计算：有限数据集、实时性要求不高，只关注产出时间
Flink如何做到流批一体
可以用一套数据框架解决流批数据处理。把批式数据看作一种特殊的steam。 不管是有边界数据流还是有边界数据集，Flink都可以支持。
流批一体的Scheduler层
**负责将DAG转换为Task**
Flink支持两种调度模式：
- EAGER：申请一个作业所需的全部资源，同时调度全部Task，Task之间采用Pipeline方式通信。
- LAZY：先调度上有，等上游产生数据或结束后在调度下游，类似Spark的Stage模式。
最新调度机制：
Pipeline Region：不管流数据还是批作业，都是按照Pipeline Region粒度申请资源和调度任务。
流批一体的Shuffle Service层
Shuffle：在分别是计算中，用来连接上下游数据交互的过程。
Flink的目标是提供统一的Shuffle框架。
三、Flink架构优化
1.流/批/OLAP业务场景概述
OLAP：在做推广活动时，运营需要对一些产出的数据实时多维数据分析，为以后活动做策略。要求高并发，延迟在秒级。
2.为什么三种场景可以用一套引擎解决
OLAP可以看作批式计算的特例。
特点：短查询，高并发，极致处理性能
3.Flink的OLAP的优化之路
Flink做OLAP的优势
引擎统一、既有优势、生态支持
Flink OLAP场景的挑战
- 秒级和毫秒级小作业
- 作业频繁的启停，资源碎片
- Latency+QPS的要求
Flink在OLAP架构的问题与设想
架构与功能模块:
- JobManager与ResourceManager在一个进程内启动，无法对JobManager进行水平扩展
- Gateway与Flink Session Cluster互相独立,无法进行统一管理。
作业管理及部署模块:
- JobManager处理和调度作业时,负责的功能比较多,导致单作业处理时间长、并占用了过多的内存
- TaskManager部署计算任务时，任务初始化部分耗时严重,消耗大量CPU
资源管理及计算任务调度:
- 资源申请及资源释放流程链路过长
- Slot作为资源管理单元，JM管理slot资源，导致JM无法感知到TM维度的资源分布，使得资源管理完全依赖于ResourceManager
