这是我参与「第四届青训营」笔记创作活动的第2天

Lect02. 流/批/OLAP 一体的 Flink 引擎介绍

01. Flink概述

1.1 Apache Flink诞生背景

1.1.1 什么是大数据

大数据：指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合

海量化（Volumes）
多样化（Variety）：数据源、数据种类
快速化（Velocity）
价值化（Value）

1.2 Flink为什么脱颖而出

1.2.1 流式计算引擎发展历程

Spark本来是批处理。spark streaming--->流处理解决

Why Flink

基于有界、无界数据集，都抽象成stream ---> 流批一体
有状态的，提供了状态一致性处理
Exactly-Once精确一次的计算语义
Checkpoint状态容错
Dataflow编程模型、Window等高阶支持

1.3 Flink开源生态

02. Flink整体架构

2.1 Flink分层架构

SDK层：SQL/Table、DataStream、pyFlink
执行引擎层(Runtime)

2.2 Flink整体架构

两个核心组件：

JobManager(JM)：负责整个任务的协调工作
TaskManager(TM)：负责执行一个DataFolw Graphd

2.3 Flink作业

2.4 流批一体

维度	流式计算	批式计算
数据流	无限数据集	有限数据集
时延	低延迟、业务会感知运行中的情况	实时性要求不高，只关注最终结果产出时间

2.4.3 Flink如何做到流批一体

Everything is Streams，批式计算是流式计算的特例。有界数据集也是一种数据流。

理论上可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。

流和批的shuffle service不同，可以走不同的suffle service

不同的维度：

SQL层
DataStream API层统一。（一些SQL无法达到的功能）
Scheduler层统一
Failover Recovery层统一
Shuffle Service层统一

2.4.4 流批一体的Scheduler层

Scheduler主要负责将作业的DAG转化为在分布式环境中可以执行的Task

模式	特点	场景
EAGER	集群需要有足够的资源，全部的task会一起调用	Bash
LAZY	集群有一个slot资源就可以运行，最小调度一个task（因为数据是无限的，永远都用不完）	Stream

由Pipeline的数据交换方式连接的Task构成一个Pipeline Region
本质上，不管是流作业还是批作业，都是按照Pipeline Region粒度来申请资源和调度任务。
Resource-Performance为单调递增的函数

例两种模式：

ALL_EDGES_BLOCKING：会落盘，所有Task之间的数据交换是BLOCKING模式
ALL_EDGES_PIPELINED：不落盘，所有Task之间的数据交换是PIPELINED模式

Flink实现了一些可插拔的Shuffle Service，抽象了一些公共接口

2.4.6 Flink流批一体总结

03. Flink架构优化

3.1 流/批/OLAP 业务场景概述

业务场景：

有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高，典型的应用是搜索引擎构建索引;
有些场景下，需对数据进行实时分析，要求每条数据处理延迟尽可能低，典型的应用是广告推荐、金融风控场景。

3.2 三种业务场景为什么可以用一套引擎解决

批式计算是流式计算的特例，而OLAP是一种特殊的批式计算。

OLAP场景

3.3 Flink的OLAP的优化之路

3.3.1 Flink做OLAP的优势

引擎统一
- 降低学习成本
- 提高开发效率
- 提高维护效率
既有优势
- 内存计算
- Code-gen
- Pipeline Shuffle
- Session模式的MPP架构
生态支持
- 跨数据源查询支持
- TCP-DS 基准测试性能强

3.3.2 Flink OPAL场景的挑战

秒级和毫秒级的小作业
作业频繁启停，资源碎片
Latency + QPS的要求

3.3.3 Flink OLAP架构现状

Client：提交SQL Query
Gateway：接收Client提交的SQL Query，对SQL进行语法解析和查询优化，生成FLink作业执行计划，转化成DAG图，提交给Session集群
Session Cluster：执行作业调度及计算，并返回结果。提前创建出集群，无需申请TM，GM有资源直接进行调度，很适合OLAP

3.3.3 Flink 在OLAP架构的问题和设想

架构与功能模块：

JobManager与ResourceManager在一个进程内启动，无法对JobManager进行水平扩展
Gateway与Flink Session Cluster互相独立，无法进行统一管理

作业管理及部署模块:

JobManager处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存;
TaskManager部署计算任务时，任务初始化部分耗时严重，消耗大量CPU。

资源管理及计算任务调度:

资源申请及资源释放流程链路过长
Slot作为资源管理单元，JM管理slot资源，导致JM无法感知到TM维度的资源分布，使得资源管理完全依赖于ResourceManager

其他:

作业心跳与Failover机制，并不合适AP这种秒级或毫秒级计算场景;
AP目前使用Batch算子进行计算，这些算子初始化比较耗时;

流/批/OLAP 一体的 Flink 引擎介绍 ｜ 青训营笔记