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

一、本堂课重点内容：

1.1 Flink概述

为什么会有流式计算的需求，为什么Flink能够脱颖而出，Flink当前的开源生态

1.2 Flink整体架构

Flink当前的整体架构介绍，一个Flink作业如何调度和运行起来，Flink如何做到流批一体

1.3 Flink架构优化

流/批/OLAP三种业务场景概述，Flink如何来支持OLAP场景需求，需要做哪些架构上的优化

1.4 精选案例讲解

选择两个字节内部真实的案例场景，介绍Flink在流批一体以及OLAP上的实践

二、详细知识点介绍：

2.1 Flink概述

2.1.1 Apache Flink的诞生背景

2.1.1.1 什么是大数据

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

4V特点：价值化（Value）、海量化（Volumes）、多样化（Variety）、快速化（Velocity）

2.1.1.2大数据计算架构发展历史

史前阶段（~2006）	Hadoop	Spark	Flink
传统数仓	分布式	批处理	流计算
Oracle	Map-Reduce	流处理	实时，更快
单机	离线计算	SQL高阶API	流批一体
黑箱使用		内存迭代计算	Streaming/Batch SQL

2.1.1.3为什么需要流式计算

大数据的实时性带来价值更大，比如：

1、监控场景：实时发现业务系统的健康状态，提前避免业务障碍

2、金融风控：实时监测出异常交易行为，及时阻断风险产生

3、实时推荐：应用根据用户的行为数据发掘用户的兴趣、偏好，向用户推荐更感兴趣的内容 ...

大数据实时性的需求，带来了大数据计算架构模式的变化：

2.1.2 为什么Apache Flink会脱颖而出

2.1.2.1 流式计算引擎发展历程

大数据如果从Google对外发布MapReduce论文算起，已经前后跨越将近二十年，业内常用的计算框架演化历史（红框是流式计算框架）

2.1.2.2 流式计算引擎对比

流式计算框架对比：

	Storm	Spark Streaming	Flink
Streaming Model	Native	mini-batch	Native
一致性保证	At Least/Most Once	Exactly-Once	Exactly_Once
延迟	低延迟（毫秒级）	延迟较高（秒级）	低延迟（毫秒级）
吞吐	Low	High	High
容错	ACK	RDD Based Checkpoint	Checkpoint(Chandy-Lamport)
StateFul	No	Yes(DStream)	Yes(Operator)
SQL支持	No	Yes	Yes

2.1.2.3 Why Flink

Apache Flink是一个可以基于无界和有界数据集之上有状态计算的框架和分布式处理引擎，Flink可以在所有常见的集群环境中运行，以内存速度和任何规模执行计算。

Flink介绍：Exactly-Once(精确一次的计算语义)、状态容错(Checkpoint)、Dataflow编程模型(Window等高阶需求支持友好)、流批一体

2.1.3 Apache Flink开源生态

2.2 Flink整体架构

2.2.1 Flink 分层架构

1、SDK层：分三类：SQL/Table、DataStream、Python;

2、执行引擎层(Runtime层) ：执行引擎层提供了统一的DAG,用来描述数据处理的Pipeline,不管是流还是批，都会转化为DAG图，调度层再把DAG转换成分布式环境下的Task，Task之间通过Shuffe传输数据

3、状态存储层：负责存储算子的状态信息

4、资源调度层：目前Flink可以支持部署在多种环境

2.2.2 Flink总体架构

一个Flink集群，主要包含一下两个核心组件：

JobManager(JM)：负责整个任务的协调工作，包括：调度task、触发协调Task做Checkpoint、协调容错恢复等；
TaskManager(TM)：负责执行一个DataFlowGraph的各个task以及data streams的buffer和数据交换。

JobManager的职责：

Dispatcher：接收作业，拉起JobManager来执行作业，并在JobMaster挂掉之后恢复作业；
JobMaster：管理一个job的整个生命周期，会向ResourceManager申请slot，并将task调度到对应TM上；
ResourceManager：负责Slot资源的管理和调度，Task manager拉起之后向RM注册。

2.2.3 Flink如何做到流批一体

Apache Flink主要从以下几个模块来做流批一体：

SQL层
DataStream API层统一，批和流都可以使用DataStream API来开发
Scheduler层架构同意，支持流批场景
Failover Recovery层架构统一，支持流批场景
Shuffe Service层架构统一，流批场景选择不同的Shuffe Service

2.3 Flink架构优化

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

三种业务场景的特点比对如下表：

流式计算	批式处理	交互式分析
实时计算	离线计算	OLAP
延迟在秒级以内	处理时间为分钟到小时级别，甚至天级别	处理时间秒级
0~1s	10s~1h+	1~10s
广告推荐、金融风控	搜索引擎构建索引、批式数据分析	数据分析BI报表

三种业务场景的解决方案的要求及带来挑战是：

模块	流式计算	批式计算	交互式分析（OLAP）
SQL	Yes	Yes	Yes
实时性	高、处理延迟毫秒级别	低	高、查询延迟在秒级，但要求高并发查询
容错能力	高	中，大作业失败重跑代价高	No，失败重试即可
状态	Yes	No	No
准确性	Exactly Once，要求高，重跑需要恢复之前的状态	Exactly Once，失败重跑即可	Exactly Once，失败重跑即可
扩展性	Yes	Yes	Yes

2.3.2 Flink如何支持OLAP场景

2.3.2.1 Flink做OLAP的优势

2.3.2.2 Flink OLAP场景的挑战

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

2.3.2.3 Flink OLAP架构现状

Client：提交SQL Query;
Gateway
- 接收Client提交的SQL Query,对SQL进行语法解析和查询优化，生成Flink作业执行计划，提交给Session集群
Session Cluster
- 执行作业调度及计算，并返回结果

2.3.2.4 Flink在OLAP架构的问题与设想

架构与功能模块：

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

作业管理及部署模块：

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

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

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

其它：

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

2.3.2.5 总结

Apache Flink最终演化到结果如下：

三、实践练习例子：

【作业二】简易流计算系统设计 - 飞书文档 (feishu.cn)

四、课后个人总结：

本章我觉得那个Flink在OLAP架构的知识点还是比较难理解的，我之前学过Flink对其基本流程还是挺熟悉的，但是后面对于流批一体、交互式分析还是一种新的概念，但是结合所学还有实际需求还是能大概了解的。

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