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

阿韩很菜
106 阅读5分钟

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

这是我参与「第四届青训营 」笔记创作活动的的第2天，本篇笔记主要是关于第二次大数据课程《流/批/OLAP 一体的 Flink 引擎介绍》的课堂笔记

批式计算&流式计算

批式计算：
    离线计算，非实时
    静态数据集
    小时/天等周期性计算
流式计算：
    实时计算，快速，低延迟
    无限流、动态、无边界
    7*24h 持续运行
    流批一体

几种流式计算的对比

image.png

  • Exactly-Once：精确计算一次
  • Checkpoint：状态容错
  • Dataflow编程模型：Window等高阶需求支持友好
  • 流批一体

Flink分层架构

image.png

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

Flink整体架构

两个核心组件：

1. JobManager（JM）：负责整个任务的协调工作：调度task、触发协调Task做Checkpoint、协调容错恢复等。
2. TaskManager（TM）：负责执行一个DataFlow Graph的各个task以及data streams的buffer和数据交换。

JobManager细分：

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

image.png

  • 上图的具体流程： Client提交一些job，Dispacher接收后拉起JobMaster来执行作业，JobMaster会向ResourceManager来申请一些资源——插槽slot，ResourceManager调用API拉起一些资源——TaskManager，之后会向JobManager注册，让JobManager知道有资源就可把资源分配给JobMaster，JobMaster再把task部署到TaskManager结点上。

Flink作业示例：

image.png image.png

  • 为了更高效地分布式执行，Flink 会尽可能地将不同的operator链接( chain )在一起形成Task，这样每个Task可以在一个线程中执行 ，内部叫做OperatorChain，如下图的source和map算子可以Chain在一起。
Flink 如何做到流批一体：
  • 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
  • 站在 Flink 的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流。因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink 都可以天然地支持，这是 Flink 支持流批一体的基础。并且 Flink 在流批一体上，从上面的 API 到底层的处理机制都是统一的，是真正意义上的流批一体。
Apache Flink 主要从以下几个模块来做流批一体:
  1. SQL层;
  2. DataStream API层统一，批和流都可以使用口ataStream API来开发;
  3. Scheduler 层架构统一,支持流批场景;
  4. Failover Recovery层架构统一， 支持流批场景;
  5. Shuffle Service层架构统一 ,流批场景选择不同的Shuffle Service ;
  • Scheduler层： Scheduler主要负责将作业的DAG转化为在分布式环境中可以执行的Task

image.png

Shuffle Service层：

  • Shuffle: 在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle。实际上,分布式计算中所有涉及到。上下游衔接的过程, 都可以理解为Shuffle。

    针对不同的分布式计算框架，Shuffle 通常有几种不同的实现:

  1. 基于文件的Pull Based Shuffle，比如Spark或MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一-些 ;
  2. 基于Pipeline的Push Based Shuffle，比如Flink、Storm、 Presto 等，它的特点是低延迟和高性能,但是因为shuffle数据没有存储下来,如果是batch任务的话，就需要进行重跑恢复;
流和批Shuffle之间的差异:
  1. Shuffle 数据的生命周期:流作业的Shuffle数据与Task是绑定的，而批作业的Shufle数据与Task是解耦的;
  2. Shufle 数据存储介质:流作业的生命周期比较短、而且流作业为了实时性, Shuffle通常 存储在内存中，批作业因为数据量比较大以及容错的需求, -般会存储在磁盘里;
  3. Shufle 的部署方式:流作业Shufle服务和计算节点部署在一起，可以减少网络开销,从 而减少latency，而批作业则不同。

流/批/OLAP 的三种业务场景为什么可以用一套引擎来解决？ image.png

Flink做OLAP 的优势：
  • 统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎；
  • 既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；
  • 相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力；
avatar
文章
阅读
粉丝