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

小白分享官
157 阅读9分钟

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

1. Apache Flink 概述

1.1什么是大数据

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

  • 特点：

    • Volumes海量化：数据量与规模大

    • Variety多样化：数据源和数据种类多样化

    • Velocity快速化：数据产生和处理速度快

    • Value价值化：数据价值密度低但整体价值高

1.2大数据架构发展史

（发展资料：www.csdn.net/tags/MtTacg…

  image.png

1.3为什么需要流式计算

  • 大数据的实时性价值更大（如监控场景、经融风控、实时推荐等业务需数据的实时性）

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

image.png

1.4 为什么 Flink 会脱颖而出

  •  流式计算引擎对比

image.png

  •  ApacheFlink是一个分布式处理引擎，具有有边界数据集和无边界数据集的数据流API（接口），Flink的流水线运行时系统可以执行批处理和流处理程序。

      优点：

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

  状态容错能力Checkpoint

  Dataflow编程模型

  Window等高阶需求支持友好

  流批一体的能力

2. Flink 整体架构

2.1 Flink 分层架构

按功能分层架构图：

image.png

  •  SDK层：提供三类接口（SQL/Table、DataStream、Python）

  •  执行引擎层（DAG API）：执行引擎层提供了统一的DAG（逻辑执行图），用来描述数据处理的Pipeline，不管是流还是批，都会转化为DAG图

    调度层（DAG Schedule）：再把DAG转化成分布式环境下的Task，Task之间通过Shuffle传输数据

  •  状态存储层（State Backend）：负责存储算子的状态信息

  •  资源调度层（Resource Manager）：目前Flin可以支持部署在多种环境

2.2 Flink 整体架构

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

  •  JobManager（JM）：负责整个任务的协调工作，包括：调度Task、触发协调Task做Checkpoint、协调容错恢复等；（相当于项目经理）

     -Dispatcher：接收作业，拉起JobManage来执行作业，并在JobMaster挂掉之后恢复作业；

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

 -ResourceManager：负责slot资源的管理和调度，TaskManager拉起之后会向ResourceManager注册；

    image.png

  •  TaskManager（TM）：负责执行一个DataFlow Graph（数据流图）的各个task以及data streams（数据流） 的buffer和数据交换。（相当于员工）

2.3 Flink 作业示例

流式的WordCount示例：从Kalfka中读取一个实时数据流，每10秒统计一次出现次数。

  • 1. 将业务逻辑转换为一个Streaming DataFlow Graph：

image.png

  •  2.分布式处理的并发度，转成并发执行图

    假设作业的sink算子的并发配置为1，其余算子并发为2

    紧接着会将上面的Streaming DataFlow Graph转化Paraller Dataflow（内部叫Execution Graph逻辑执行图）

    image.png

  • 3. 分布式执行优化（chain操作）

    Flink会尽可能地将不同的operator链接（chain）在一起形成Task，这样每个Task 可以在一个线程中执行，内部叫做OperatorChain，如下图的Source和map算子可 以Chain在一起 （source执行后立马执行map，source和map在一个线程里执 行）

    image.png

  •  4.最后将上面的Task调度到具体的TaskManager中的slot中执行，一个Slot只能运行同一个task的subTask

    一个TM中有几个Slot用户可以自定义

    每个slot是一个单独的线程在执行

    将Task放到Slot里面，TM中的Slot的资源如cpu没有隔离，内存有部分隔离

    一个TaskManager是一个进程

image.png

3. Flink 如何做到流批一体

3.1为什么要流批一体

  • 业务需求

    • 某些业务的实时统计需要应用批处理

    • 某些业务按周期计统计数据需应用批处理

  •  流批分开处理的架构存在痛点

    • 人力成本较高：流、批两套系统，相同逻辑需开发两遍

    • 数据链路冗余：本身计算内容一致，因有两套链路，相同逻辑需运行两边

    • 数据口径不一致：两套系统、两套算子、两套UDF、通常会产生不同程度误差，给业务方带来非常大的困扰

3.2流式和批式计算的特点和区别

image.png image.png

3.3为什么Flink可以做到流批一体

有界数据：批式数据

无界数据：流式数据

无边界数据集可以按时间切段成一个个有边界的数据集（流式-->批式），有界数据集是一种特殊数据流，批式计算是流式计算的特例，因此可以用一套引擎架构来流、批计算。

Flink可以天然地支持有边界数据集和无边界数据集，这是Flink支持流批一体的基础。Flink从上面的API到底层的处理机制都是统一的，是真正意义上的流批一体。

3.4 Flink如何做到流批一体

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

1. SQL层

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

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

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

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

  • 流批一体的Scheduler（调度）层

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

    •  Flink在1.12版本之前，支持以下两种调度   image.png

      EAGER模式：若要多个Task一起调度，则这些Task必须集齐所有slot资源，整个 作业才能正在运行起来。

Lazy模式：最小调度一个Task即可，只要有一个slot资源就可以运行，可以一个 一个Task运行。

    •  Flink在1.13版本后，结合前两种模式新增了Pipeline Region模式

        由Pipeline的数据交换方式连接的Task构成为一个Pipeline Region；

  本质上，不管是流还是批作业都是按照Pipeline Region粒度来申请资源和调度任务。使Scheduler层架构统一，做到将流、批作为同一种模式调度。

    传统的批处理方式（ALL_EDGES_BLOCKING）：所有的Task之间的数据交换都是BLOCKING 模式（Task间的数据不是实时传递的，需先写入磁盘），有多少个Task就被切成多少 个pipeline region.

    新的批处理方式（ALL_EDGES_PIPELINED）:所有的Task之间的数据交换都是PIPELINE模 式，所有Task当成一个pipeline region.

  •  流批一体的Shuffle Service层

    Shulle：在分布式计算中，用来连接上下游数据交互（上下游衔接的过程）的过程叫做 Shuffle。

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

      1. 基于文件的Pull Based Shuffle：其特点是具较高的容错性，适合较大规模的批处理作业，由于是基于文件，其容错性和稳定性更好，比如Spark或MR。

      2. 基于Pipeline的Push Based Shuffle：其特点是低延迟和高性能，但是因为shuffle数据没有存储下来，如果是batch（批）任务的话，就需要进行重跑恢复。

    • 流和批Shuffle之间的差异：

      1. Shuffle数据的生命周期：流作业的Shuffle数据与Task是绑定的（Task销毁了则Shuffle也没了），批作业的Shuffle数据与Task是解耦的（上游Task跑完了释放掉产生的Shuffle生命周期还在）

      2. Shuffle数据的数据存储介质：流作业为了实时性Shuffle存储在内存中，批作业为了容错性存储在磁盘。

      3. Shuffle数据的部署方式：流作业Shuffle服务和计算节点部署在一起（减少网络开销），批作业Shuffle服务是多个远程服务部署（数据多存储防止机器宕机作业重跑）。

    Flink对于流和批提供两种类型的shuffle，虽然Streaming和Batch Shuffle在具体的策略上存在差异，但本质上都是为了对数据进行Re-Partition，因此不同Shuffle间存在一定共性。

    所以Flink的目标是提供统一的Shuffle架构。

  •   在Streaming和OLAP场景：通常使用基于Pipeline的Shuffle模式

  在Batch场景：通常选取Blocking的Shuffle模式

  为了统一Flink在Streaming和Batch模式下的Shuffle架构：Flink实现了一个Pluggable的Shuffle Service框架。

  -  对于Shuffile Service,Flink开源社区已经支持:

      1. Netty Shuffle Service:既支持pipeline又支持blocking，Flink默认的shuffle Service 策略;

      2. Remote Shufle Service:既支持pipeline又支持blocking，不过对于pipeline模式，走remote反而会性能下降，主要是有用在 batch的blocking场景。

4.Flink 架构优化

4.1流/批/OLAP 三种场景一套引擎

  • 三种业务场景的特点对比：   image.png image.png

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

    流式计算-->批式计算-->OLAP

    批式计算是特殊的流式，OLAP是一种特殊的批式计算，所以理论上可以用一套引擎解决这三种场景。

4.2 Flink 做 OLAP 的优化之路

  •  Flink做OLAP的优势

image.png

  •  Flink做OlAP的挑战

      秒级和毫秒级的小作业

  作业频繁启停、资源碎片

  Latence+QPS的要求

  •  Flink OLAP架构现状

    image.png

     Client:提交SQL Query

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

 session Cluster：执行作业调度及计算，并返回结果。

  •  Flink OLAP架构的问题 

    •    架构与功能模块:

      1.JobManager与ResourceManager在一个进程内启动，无法对JobManager进行水平扩展;

      2.Gateway 与Flink Session Cluster互相独立，无去进行统一管理。

    • 作业管理及部署模块:

      1.JobManager处理和调度作业时，负责的功剧比较多，导致单作业处理时间长、并占用了过多的内存;

      2.TaskiManager 部普计算任务时,任务初始化部分耗时严重,消耗大量CPU.

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

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

      2.Slot 作为资源管理单元，JM管理slot资源,导致JM无法威知到TM维度的资源分布，使得资源管理完全依赖于ResourceManager

    • 其他:

      1.作业心跳与Failover机制,并不合适AP这种秒级或宅秒级计算炀录;

      2.AP目前使用Batch算了进行计算,这些算子初始化比较耗时;

5.Flink使用案例

5.1电商流批一体

原本实时数仓和离线数仓分开为两条链路，现状实现流批一体统一链路。

image.png

5.2 Flink OLAP的HATP实践

由原本需将线上数据同步到离线数据库才能进行后续处理（在线和离线隔离开了），到现在走HATP链路Flink可直接提供数据查询和数据分析功能（实现交互式分析）。

image.png

avatar
文章
阅读
粉丝