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

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

01 Flink概述

1.1 Flink诞生背景

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

1.1.2 为什么需要流式计算

1. 对业务的实时性要求比较大

1.2 Flink为什么脱颖而出

1.2.1 流式计算引擎发展历程

1. 红色圈出来的是流式计算框架，其中kafka原来是消息队列，后来提出kafaka Stream，基于此可以做一些简单的流式计算。（spark也是有一个 Spark Streamming，把无限流切分成无限小的批数据，如每分钟/每10秒作为一个批。）

1.2.2 流式计算引擎的对比

1. 重要的指标

1. 1. 一致性

At Least Once（至少处理一次）:Storm之前由于ACK机制， 数据至少被处理一次。如果数据传输过程中某个部分发生故障，数据会重新发送，所以数据可能会多处理。

At Most Once（最多处理一次）: 数据只会往下游发一次，如果下游没处理完或者发生故障也不会再次发送。保证下游最多执行一次。

Exactly-Once: 精确一次的计算语义

1. 2. 延迟
   3. 吞吐
   4. 容器
   5. StateFul

系统内部状态支持。

1. 6. SQL支持

非常重要的功能，SQL化对业务支持更好。

1.2.3 Why Flink

1. Apache Flink社区的介绍

2. Dataflow编程模型思想对流式计算发展提供了理论基础。
3. 流批一体，基于无边界和右边界的数据集最基本的抽象，更好的提供流批一体的能力。

1.3 Apache Flink 开源生态

1. 生态的支持-数据引擎（Flink只是计算框架）

1. 1. 消息队列: Kafka、RocketMQ、RabbitMQ
   2. key-value数据库：Redis
   3. 离线的数据源：HDFS、Hive
   4. OLAP型数据库：clickhouse （可以从Kfaka导入clikchouse里面）

2. 部署

1. 1. Standalone: 单机部署
   2. Yarn
   3. K8s

3. 其他计算框架的支持

1. 1. Gelly(graph)：用于图计算
   2. Flink ML：机器学习
   3. Stateful Function

02 Flink整体架构

2.1 Flink 分层架构

1. SDK层：

1. 1. SQL/Table：用户使用SQL进行流计算处理
   2. DataStream：定制化需求场景，基于Flink的DataStream的Java API来进行流计算
   3. pyFlink：pythonSDK的支持，支持ML

2. 执行引擎层：

将上层转为抽象的DAG的图（逻辑的表达方式），用于描述数据、业务处理的pipeline。在调度阶段转为将DAG转换为Task，将Task分发到不同的WorkNode，Task之间涉及到数据交换使用Shuffle传输。

3. 状态存储层
4. 资源调度层

2.2 Flink 总体架构

1. 这里的DataFlowGarph就是我们上面说的DAG图。
2. JobManager职责

2.3 Flink 作业示例

2.3.1 wordcount示例

1. 流程

1. 1. source：添加数据源（从Kfaka读数据）
   2. Transformation: 转换，对数据做一些处理
   3. Sink: 下沉，存储数据。

2. 并发度

3. 优化：将一些任务放在一个线程执行。内部叫做OperatorChain，source和map之间没有hash和shuffle操作，不涉及数据交换，可以放在一个线程执行。当做一个Task（算子）。

算子的Chain规则：需要去Apache flink官网源码看。

4. 一个Task Slo是一个线程，一个TaskManager是一个进程。

2.4 Flink如何做到流批一体

2.4.1 为什么需要流批一体

1. 实施统计信息：流处理
2. 按天统计一些信息：批处理

3. 统一抽象为Streams

2.4.2 Flink如何做到流批一体

下面着重从Scheduler层和Shuffle Service层来介绍Flink如何做到流批一体的。

2.4.3 流批一体的Scheduler层

1. 功能：负责将作业的物理DAG转换为分布式环境中可以执行的task

2. EAGER调度模式

3. LAZY模式

只需要一个task作业即可开始执行。

4. Pipeline Region

\

5. Blocking模式与Pipeline模式

1. 1. Blocking:

中间数据会有写入磁盘的操作。ALL_EDGES_BLOCKING就像前面举的LAZY模式的调度。task之间交互使用Blocking，就会划分为不同的pipeline region。

1. 2. Pipeline:

数据在内存中，没有写入磁盘操作。

pipeline region对流批不同处理模式进行了一个抽象，在一个调度器对流和批进行相应的调度，在调度层做到了统一。

\

2.4.5 流批一体的 Shuffle Service层

1. 明确shuffle的定义：

分布式计算中，用来连接上下游数据交互的过程叫做shuffle。

2. shuflle的分类

1. 1. 基于文件的：将数据写入文件中（flink中Blocking模式）
   2. 基于Pieline：

\

3. Pluggeable Shuffle Service架构图

\

2.4.6 小结

03 Flink架构优化

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

\

\

OLAP要求高并发，低延迟

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

\

3.3 Flink如何支持OLAP场景

\

\

• 挑战---对JM进行扩展，多个JM，一个RM。针对Flink JM某一个组件进行扩展，支持更大的QPS，实现Flink高并发。
• GateWay对SQL解析，与Flink版本强相关的

\

\

\

• 总结

04 精选案例讲解

• 流批分离

\

4.1 电商流批一体实践

\

4.2 字节Flink OLAP实践

• HATP：AP和TP混合
• Flink负责AP查询部分

• 分界之间是一个同步后的离线数据，离线的业务是基于Hive来处理的；在线、离线完全隔离开的。

\

05 总结