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

今天笔记主要分为四个部分：

Flink概述

1. 大数据

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

2. 特点：价值化、海量化、快速化、多样化

2. 流式计算的重要性：

大数据的实时性价值更大。

3. 批式计算和流式计算对比：

1. 批式计算：

• 离线及时，非实时

• 静态数据集

• 小时/天等周期性计算

2. 流式计算：

• 实时计算，快速，低延迟

• 无限流、动态、无边界

• 随时在持续运行

• 流批一体

4. 经典流式框架对比：

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

5. Flink优点

• 精确一次的计算语义

• 状态容错

• Dataflow编程模型、windows等高阶需求支持友好

• 流批一体

Flink整体架构

1. Flink分层架构

1. SDK层：分为三类：SQL/Table\DataStream\Python

2. 执行引擎层（Runtime层）：Runtime层提供统一的DAG，用来描述数据处理的流水线，不管是刘还是批，都会转换为DAG图，调度层再把DAG转换成分布式环境下的Task,Task之间通过Shuffle传输数据

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

4. 资源调度层：目前Flink可以指出部署在多种环境

2. Flink总体架构

JobManager(JM)；负责整个任务的协调工作，包括调度task、触发协调Task做Checkpoint、协调容错恢复。

• Dispatcher:接受作业，拉起JobManager来执行作业，并在JobMaster挂掉之后恢复作业。

• JobMaster:管理一个job的整个生命周期，会向ResourceManager申请slot,并将task调度到对应TM上。

• ResourceManage：负责slot资源的管理和调度，Task manager拉起之后会向RM注册。

TaskManager(TM):负责执行一个DataFlow Graph的各个task以及data streams 的buffer和数据交换。

3. Flink如何让做到流批一体

1. 业务需求

数据有需要实时处理的，比如广告统计，金融风控；也有一些周期处理的，比如批式数据集。

2. 挑战

• 数据流层面：流式计算是无限数据集，批式计算是有限数据集。

• 时延层面：流式计算低延迟，批式计算实时性要求不高。

3. How to do?

批式计算是流式计算的特例，理论上可使用一套引擎，只是策略不同。

主要从下面几个模块进行流批一体：

1. SQL层

2. DataSteam API层统一，批和流都可以使用DataSteam API开发

3. Schedler层架构统一，支持流批场景

4. Failover Recovery层架构统一，支持流批场景

5. Shuffle Service层架构统一，根据不同场景选择不同服务

4. Schedler层

主要负责将作业的DAG转换为在分布式环境中可执行的task。

Flink1.12版本前。支持两种调度模式：

模式	特点	场景
EAGER	申请一个作业所需的所有资源，同时调度这个作业的所有task，task之间采用pipeline通信	Stream作业场景
LAZY	先调度上游，等待上游产生护具或结束后再调度下游，类似Spark的STAGE执行模式	Batch作业场景

5. Shuffle Service层

实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为Shuffle.

• 基于文件的Pull Based Shuffle.具有较高容错性，适合大规模批处理作业，容错性更好。比如spark或MR。

• 基于Pipeline的Push Based Shuffle，具有低延时高性能，比如Flink,Storm。

流和批Shuffle之间的差异：

• Shuffle的生命周期：流作业Shuffle数据与Task绑定，批作业和Shuffle是解耦的

• Shuffle数据存储介质：流作业的Shuffle存储在内存，批作业的Shuffle存储在磁盘

• Shuffle的部署方式：流作业的Shuffle服务和计算节点部署在一起，可以减少网络开销，从而减少延迟，批作业不同

Flink架构优化

三种场景对比：

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

Flink做OLAP优势：

1. 引擎统一

2. 既有优势

1. 内存计算

2. Code-gen

3. Pipeline Shuffle

4. Session模式的MPP架构

3. 生态支持

1. 跨数据源查询支持

2. TCP-DS基准测试性能强

Flink做OLAP的挑战：

1. 秒级和毫秒级的小作业

2. 对Latency+QPS的要求高

3. 作业频繁启停，资源碎片

FlinkOLAP架构现状：

• Client:提交SQL Query

• Gateway:接受Client提交的SQL Query，对SQL进行语法解析和查询优化，生成Flink作业执行计划，提交给Session集群

• Session Cluster:执行作业调度及计算，并返回结果。

FlinkOLAP架构存在的问题与设想：

1. 架构与功能模块：

• JM与RM在一个进程内启动，无法对JM进行水平扩展。

• Gateway与Flink Session Cluster互相独立，无法进行统一管理。

2. 作业管理及部署模块

• JM处理和调度作业时，负责的功能比较多，导致单作业处理时间长，并占用过多内存。

• TM部署计算任务时，任务初始化部分好事严重，消耗大量CPU。

3. 资源管理及计算任务调度

• 资源申请及计算任务调度

• 资源申请及资源释放流程链路过长

• Slot作为资源管理单元，JM管理slot资源，导致JM无法感知到TM维度的资源分布，是的资源管理完全依赖于RM。

4. 其他

• 作业心跳与Failover机制，并不适合AP这种秒级或毫秒级计算场景

• AP目前使用Batch算子进行计算，这些算子初始化比较耗时。

精选样例讲解

电商流批一体实践