第二节：流_批_OLAP一体的Flink引擎|青训营笔记这是我参与「第四届青训营」笔记创作活动的第 2 天!是关于流_

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

1、Flink概述

大数据

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

流式计算的需求（实时计算的业务场景）

批式计算：

流式计算：

Flink：从产品技术来看，Flink 作为一个最新的实时计算引擎，具备如下流计算技术特征：

从 Storm 到 SparkStreaming 再到 Flink 流式计算处理实时数据能力、功能愈加强大。

开源生态非常强大：支持流批一体，OLAP，Gelly图计算等

SDK层：Flink 的 SDK层目前主要有三类，SQL/Table、DataStream、Python；
执行引擎层（Runtime）:执行引擎层提供了统一的 DAG，用来描述数据处理的 Pipeline，不管是流还是批，都会转化为 DAG 图，调度层再把 DAG 转化成分布式环境下的 Task，Task 之间通过 Shuffle 传输数据；
状态存储层：负责存储算子的状态信息
资源调度层：目前Flink可以支持部署在多种环境。

JobManager（JM）

负责整个任务的协调工作，包括：调度 task、触发协调 Task 做 Checkpoint、协调容错恢复等，核心有下面三个组件：

TaskManager（TM）

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

为什么要做流批一体呢？因为有时在一个系统中同时需要批处理和流处理，同样一套处理逻辑，但是由于架构不同，则需要重新走一遍。浪费资源。而且如果两套最后运行结果有误差也不好进行分析。

可以将批式运算看做流式计算的特例。站在 Flink 角度，有边界数据集和无边界数据集都是数据流，所以 Flink 天然支持两者，这是 Flink 支持流批一体的基础。并且 Flink 在流批一体上，从上面的 API 到底层的处理机制都是统一的，是真正意义上的流批一体。

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

Scheduler层

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

1.12 之前的 Flink 版本，Flink 支持两种调度模式：

EAGER（Streaming 场景）：申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信；

调度所有资源

调度一点资源

Pipeline Region Scheduler 机制

由 Pipeline 的数据交换方式连接的 Task 构成一个 Pipeline Region。流和批作业都是根据 Pipeline Region 粒度来申请资源和调度任务。

Shuffle Service 层

Shuffle 分类：

基于文件的 Pull Based Shuffle，比如 Spark 或 MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些；
基于 Pipeline 的 Push Based Shuffle，比如 Flink、Storm、Presto 等，它的特点是低延迟和高性能，但是因为 shuffle 数据没有存储下来，如果是 batch 任务的话，就需要进行重跑恢复；

流和批 Shuffle 之间的差异：

Shuffle 数据的生命周期：流作业的 Shuffle 数据与 Task 是绑定的，而批作业的 Shuffle 数据与 Task 是解耦的；
Shuffle 数据存储介质：流作业的生命周期比较短、而且流作业为了实时性，Shuffle 通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里；
Shuffle 的部署方式：流作业 Shuffle 服务和计算节点部署在一起，可以减少网络开销，从而减少 latency，而批作业则不同。