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

二粒砂
145 阅读11分钟

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

1.Flink概述

为什么会有流式计算的需求，为什么Flink能够脱颖而出，Flink当前的开源生态

①Apache Flink的诞生背景

  1. 什么是大数据

    • 大数据：指无法在一时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合
    • 特点：价值化、海量化、多样化、快速化

  2. 大数据架构发展历史 image.png

  3. 为什么需要流式计算

    大数据的实时性带来价值更大：监控场景、金融风控、实施推荐

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

②为什么Apache Flink会脱颖而出

  1. 流式计算引擎发展历程 image.png

  2. 流式计算框架对比

image.png

一致性：Storm可以保证每一条数据至多/至少被处理一次

SQL可以提高业务迭代速度，降低业务迭代成本

3. Why Flink

  • Exactly-Once：精确一次的计算语义
  • 状态容错：Checkpoint
  • 流批一体：支持有边界和无边界数据集
  • Dataflow编程模型：Window等高阶需求支持友好

③Apache Flink开源生态

image.png

2.Flink整体架构

Flink当前的整体架构介绍，一个Flink作业如何调度和运行起来，Flink如何做到流批一体

①Flink分层架构

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

②Flink总体架构

image.png

客户端会生成一个逻辑执行图，交给JM生成物理执行图，然后交给TM真正执行

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

  1. JobManager（JM）：负责整个任务的协调工作，包括：调度task、触发协调Task做Checkpoint、协调容错恢复等

    JobManager职责：

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

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

    ResourceManager：负责slot资源的管理和调度，Task manager拉起后会向RM注册，随后JobMaster将任务部署到资源上

  2. TaskManager（TM）：负责执行一个DataFlowGragh的各个task以及data streams的buffer和数据交换

③Flink作业示例

流式的WordCount示例，从kafka中读取一个实时数据流，每10s统计一次单词出现次数，DataStream实现代码如下：

image.png

假设作业的sink算子的并发配置为1，其余算子并发为2，紧接着会将上面的Streaming DataFlow Gragh 转化Parallel DataFlow（内部叫Execution Gragh）以下为物理执行图

image.png

为了更高效的分布式执行，Flink会尽可能地将不同的operator链接（chain）在一起形成Task。这样每个task可以在一个线程中执行，内部叫OperatorChain，如下图地source和map算子可以Chain在一起

TODO：operator chain的条件

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

④Flink如何做到流批一体

痛点

  • 人力成本比较高：批、流两套系统，相同逻辑需要开发两遍
  • 数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费
  • 数据口径不一致：两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰

流和批业务场景的特点：

image.png

批式计算相比于流式计算核心的区别：

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

  1. 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流，一种特殊的数据流

    因此，理论上我们是可以用一套引擎架构来解决上述这两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略

  2. 站在Flink的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流

    因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink都可以天然的支持，这是Flink支持流批一体的基础。并且Flink在流批一体上，从上面的API到底层的梳理机制都是统一的，是真正意义上的流批一体

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

  1. SQL层：输入可以流式数据也可以是批式数据
  2. DataStream API层统一，批和流都可以使用DataStream API来开发
  3. Scheduler层架构统一，支持流批场景
  4. Failover Recovery层架构统一，支持流批场景
  5. Shuffle Service层架构统一，流批场景选择不同的Shuffle Service

流批一体的Scheduler层

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

  • 讲逻辑执行图转成物理执行图并进行调度

  • 在1.12之前的Flink版本中，Flink支持一下两种调度模式

    • EAGER模式

      12个task要一起调度，才能运行起来，集群需要有足够的资源

    • LAZY模式

      最小调度一个task即可，集群有一个slot资源可以运行

    • Flink1.12后全新的调度模式：Pipeline Region

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

      本质上，不管是流作业还是批作业，都是按照Pipeline Region粒度来申请资源和调度任务

      ALL_EAGER_BLOCKING

      所有task之间的数据交换都是BLOCKING（一个task执行完后将数据存入磁盘，下一个task从磁盘读取数据）模式，分为12个pipeline region

      ALL_EAGERS_PIPELINED

      所有的Task之间的数据交换都是PIPELINE（中间数据不落盘）模式，分为一个pipeline region

流批一体的Shuffle Service层

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

    实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为Shuffle

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

    1.基于文件的Pull Based Shuffle：比如Spark或MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的（BLOCKING）,它的容错性和稳定性会好一点

    2.基于Pipeline的Push Based Shuffle，比如Flink、Storm、Presto等，它的特点是低延迟和高性能，但是因为Shuffle数据没有存储下来，如果是batch任务的话，就需要进行重跑恢复

  • 流和批Shuffle之间的差异

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

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

    3.Shuffle的部署方式：流作业Shuffle服务和计算节点部署在一起，可以减少网络开销，从而减少latency，而批作业则不同，支持remote Shuffle Service，允许备份多份数据，以保证更高的容错性，因为批处理重跑的代价高

  • Flink对于流和批提供两种类型的Shuffle，虽然Streaming和Batch Shuffle在具体的策略上存在一定的差异，但本质上都是为了对数据进行Re-Partition，因此不同的Shuffle之间是存在一定的共性的；所以Flink的目标是提供一套统一的Shuffle架构，既可以满足不同Shuffle在策略上的定制，同时还能避免在共性需求上进行重复开发

  • 为了统一Flink在Streaming和Batch模式下的Shuffle架构，Flink实现了一个Pluggable的Suffle Service框架，抽象出一些公共模块

    在Streaming和OLAP场景：为了性能的需要，通常会使用基于PIpeline的Shuffle模式

    在Batch场景：一般会选取Blocking的Shuffle模式

  • 对于Shuffle Service，Flink开源社区已经支持

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

    2.Remote Shuffle Service：既支持pipeline又支持blocking，不过对于Pipeline模式，走remote反而会性能下降（网络开销），主要是用在batch的blocking场景

Flink流批一体总结

  • 经过相应的改造和优化之后，Flink在架构设计上，针对DataStream层、调度层、Shuffle Service层，均完成了对流和批的支持。至此，业务已经可以很方便地使用Flink解决流和批场景的问题了

3.Flink架构优化

流/批/OLAP三种业务场景概述，Flink如何来支持OLAP场景需求，需要做哪些架构上的优化

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

三种业务场景的特点对比

image.png

三种业务场景的解决方案的要求及带来的挑战

image.png

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

  1. 批式计算是流式计算的特例，有界数据集（批式数据）也是一种数据流，一种特殊的数据流

  2. OLAP计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大的区别

    因此，理论上，可以用一套引擎架构来解决上述三种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略

  3. Apache Flink从流式计算出发，需要支持Batch和OLAP场景，就需要解决下面的问题

③Flink如何支持OLAP场景

  1. Flink做OLAP的优势

image.png

  1. Flink OLAP场景的挑战

    秒级和毫秒级的小作业；作业频繁启停，造成资源碎片；Latency+QPS的要求

  2. Flink OLAP架构现状

    Client：提交SQL Query

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

    Session Cluster：执行作业调度及计算，并返回结果（Flink Session Cluster节省了TM调度时间）

  3. Flink在OLAP架构的问题与设想

    架构与功能模块

    • JM与ResourceManager在一个进程内启动，无法对JM进行水平扩展（OLAP的并发能力要求）（设想：多个JM一个RM）
    • Gateway与Flink Session Cluster互相独立，无法进行统一管理

    作业调度和部署模块

    • JM处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并且占用了过多的内存
    • TM部署计算任务时，任务初始化部分耗时严重（OLAP场景需要频繁的创建新的任务），消耗大量CPU

    资源管理及计算任务调度

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

    其他

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

4.精选案例讲解

选择两个字节内部真实的案例场景，介绍Flink在流批一体以及OLAP上的实践

Flink现状

image.png

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

数据源统一，业务逻辑方面，Flink Batch和Flink Stream的UDF都相同，只是调度方式不同

image.png

image.png 原本都是对基于Hive对离线数据进行分析

5.总结

  1. 概述

    • 流式计算场景及流式计算框架发展历程
    • 业内主要流式计算框架对比，为什么Flink能够脱颖而出

  2. Flink整体框架

    • Flink的分层结构、Flink当前的整体架构介绍
    • 一个Flink作业如何调度和运行起来
    • Flink如何做到流批一体

  3. Flink架构优化

    • 流/批/OLAP三种业务场景概述
    • FLink如何来支持OLAP场景需求，需要做哪些架构上的优化

  4. 精选案例讲解

avatar
文章
阅读
粉丝