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

sora997
92 阅读6分钟

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

课程目录

1. Flink概述

2. Flink整体架构

3. Flink架构优化

4 .精选案例讲解

思维导图

OLAP 一体的Flink引擎.png

1. Flink概述

从下图可以看出Flink为什么能够在流式计算框架中脱颖而出

Image.png

Flink本身不提供存储，只提供计算，但是可以很好的集成外部组件，可以集成kafka等MQ，Redis等存储。可以部署在yarn，k8s等

2. Flink整体架构

2.1 Flink分层架构

SDK

  • SQL/Table
  • DataStream
  • PyFlink

执行引擎（runtime）层

  • 提供了统一的DAG，批流数据都会转换成DAG
  • 调度层把DAG换行成Task

状态存储层

  • 存储算子状态信息
  • RocksDB的性能好一点

资源调度层

  • Flink支持部署在多种环境：yarn、k8s等

2.2 Flink总体架构

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

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

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

DataFlow Graph可以理解为DAG的一张图

Flink作业示例

Image.png

Image.png

Image.png

Flink会尽可能的将不同的operator链接（chain）在一起形成task，这样可以在一个线程中执行task，不用多余线程，减少线程之间数据传输（序列化与反序列化）与切换。

  • 具体哪些算子可以chain一起，具体可以到官网查看相关内容

Image.png

2.3 Flink如何做到流批一体

image.png

批式计算是流式计算的特例

2.3.1 流批一体的scheduler层

  • 将作业的DAG转换成Task

  • 调度模式：pipeline region

    • 流批一体： 所有的task的shuffle交互为pipeline region

    • ALL_EDGES_BLOCKING：

      • task的交互均为blocking模式，（产生的数据需要落盘：批处理），分为N个pipeline region

    • ALL_EDGES_PIPELINED：

      • 所有task交互均为pipeline模式，分为1个pipeline region

2.3.2 流批一体的shuffle service层

  • shuffle： 在分布式计算中，用来连接上下游数据交互的过程

  • shuffle的不同实现：

    • 基于文件的pull Based shuffle：spark，MR
    • 基于pipeline的push Based shuffle：flink，presto

  • 批流shuffle之间的差异：

    • 1.Shuffle 数据的生命周期:流作业的 Shuffle 数据与 Task 是绑定的，而批作业的 Shuffle 数据与 Task 是解耦的;

    • 2.Shuffle 数据存储介质:流作业的生命周期比较短、而且流作业为了实时性，Shuffle 通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里;

    • 3.Shuffle 的部署方式:流作业 Shuffle 服务和计算节点部署在一起，可以减少网络开销，从而减少 latency，而批作业则不同。

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

所以 Flink 的目标是提供一套统一的 Shuffle 架构，既可以满足不同 Shuffle 在策略上的定制，同时还能避免在共性需求上进行重复开发。

2.3.3 shuffle的选择

在streaming和OLAP场景：

  • 为了性能需求，通常用pipeline的shuffle模式

在batch场景：

  • 一般选Blocking的shuffle模式

3. Flink架构优化

3.1 流/批/OLAP业务场景介绍

  • 三种业务场景的特点如下表 image.png

  • 三种业务场景的解决方案的要求以及带来的挑战： image.png

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

  • 批式计算是流式计算的一种特例
  • OLAP计算是一种特殊的批式计算（数据有限），对并发要求和实时性要求更高

3.3 Flink如何支持OLAP场景

3.3.1 Flink 做 OLAP 的优势

  • 统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎；

    • 降低学习成本，仅需要学习一个引擎；
    • 提高开发效率，很多 SQL 是流批通用；
    • 提高维护效率，可以更集中维护好一个引擎；

  • 既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；

    • 使用流处理的内存计算、Pipeline；
    • 支持代码动态生成；
    • 支持批处理数据落盘能力；

  • 相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力

    • 无统计信息场景的优化；
    • 开发更高效的算子；
    • 使 Flink 同时兼备流、批、OLAP 处理的能力，成为更通用的框架。

3.3.2 Flink OLAP场景的挑战

  • 秒级和毫秒级的小作业
  • 作业频繁启停、资源碎片
  • Latency + 高 APS 要求

3.3.3 Flink OLAP 架构

  • Client：提交 SQL Query
  • Gateway：接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群
  • Session Cluster：执行作业调度及计算（JM和TM），并返回结果

3.3.4 Flink在OLAP架构的问题和设想

  • 架构与功能模块

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

    设想：希望能多个JM可配对一个RM： 原1个JM包含1个RM,这样可以提高OLAP的QPS，高并发的需求

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

  • 作业管理及部署模块

    • JobManager 处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存；
    • TaskManager 部署计算任务时，任务初始化部分耗时验证，消耗大量 CPU

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

    • 资源申请及资源释放流程链路过长；
    • Slot 作为资源管理单元，JM 管理 slot 资源，导致 JM 无法感知到 TM 维度的资源分布，使得资源管理完全依赖于 ResourceManager；

  • 其他

    • 作业心跳与 Failover 机制，并不合适 AP 这种秒级或毫秒级计算场景；
    • AP 目前使用 Batch 算子进行计算，这些算子初始化比较耗时

Flink最终设想如下： image.png

4 .精选案例讲解

电商流批一体实践

实时数仓和离线数仓架构图如下：

image.png

目前电商业务数据分为离线数仓和实时数仓建设，离线和实时数据源，计算引擎和业务代码没有统一，在开发相同需求的时候经常需要离线和实时对齐口径，同时，由于需要维护两套计算路径，对运维也带来压力。

演进目标如下

image.png

从数据源，业务逻辑，计算引擎 完成统一，提高开发和运维效率。

Flink OLAP 场景实践

OLAP 场景主要是HTAP场景 image.png

总结与思考：了解了Flink的整体架构，以及为什么 Flink 可以做到支持流/批/OLAP三种业务场景。以及Flink如何做到流批一体的？批计算可以看成特殊的流计算，而OLAP计算可以看成特殊的批计算，在Flink的调度层做到流批一体的调度schedule，还有流批一体的shuffle service。

avatar
文章
阅读
粉丝