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

serendipity__
123 阅读9分钟

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

99999.png

流/批/OLAP 一体的 Flink 引擎介绍

一、Flink概述

1、Apache Flink 概述

1.1 Apache Flink诞生背景

1.1.1 大数据概念

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

image.png

1.1.2 大数据计算架构发展历史

image.png

1.1.3 为什么需要流式计算

大数据的实时性带来价值更大，比如:

1.监控场景:如果能实时发现业务系统的健康状态，就能提前避免业务故障;

2.金融风控:如果实时监测出异常交易的行为，就能及时阻断风险的发生;

3.实时推荐:比如在抖音，如果可以根据用户的行为数据发掘用户的兴趣、偏好，就能向用户推荐更感兴 趣的内容;

1.2 为什么Apache Flink会脱颖而出

1.2.1 流式计算引擎发展历程

image.png 注：红框是流式计算框架

1.2.2 流式计算引擎对比

image.png

image.png

1.3 Apache Flink开源生态

image.png

二、Flink整体架构

2.1 Flink分层架构

image.png

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

2.2 Flink总体架构

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

    1. JobManager (JM) :负责整个任务的协调工作，
  • 包括:调度task、触发协调Task做Checkpoint、
  • 协调容错恢复等;
    1. TaskManager (TM) :负责执行一个DataFlow
  • Graph的各个task以及data streams的buffer和
  • 数据交换。

Flink总体架构-JobManager职责

image.png

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

2.3 Flink作业实例

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

image.png

  • 假设作业的sink算子的并发配置为1,其余算子并发为2紧接着会将上面的Streaming DataFlow Graph转化Parallel Dataflow (内部叫Execution Graph) : image.png

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

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

2.4 Flink架构优化

2.4.1 为什么需要流批一体

image.png

上述架构优点：

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

2.4.2 流批一体的挑战

流和批业务场景

image.png

image.png

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

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

  • 站在 Flink 的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流。因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink 都可以天然地支持，这是 Flink 支持流批一体的基础。并且 Flink 在流批一体上，从上面的 API 到底层的处理机制都是统一的，是真正意义上的流批一体。

image.png

  • Apache Flink 主要从以下几个模块来做流批一体：
  1. SQL 层；
  2. DataStream API 层统一，批和流都可以使用 DataStream API 来开发；
  3. Scheduler 层架构统一，支持流批场景；
  4. Failover Recovery 层 架构统一，支持流批场景；
  5. Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service；

2.4.4 流批一体的 Scheduler 层

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

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

image.png EAGER模式：12个task会一起调度，集群需要有足够的资源 LAZY模式：最小调度一个task即可，集群有1个slot资源可以运行

image.png

2.4.5 流批一体的Shuffle Service层

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

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，而批作业则不同。

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

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

  1. Netty Shuffle Service:既支持pipeline又支持blocking, Flink 默认的shuffle Service策略;
  2. Remote Shuffle Service:既支持pipeline 又支持blocking,不过对于pipeline模式，走remote反而会性能下降，主要是有用在batch的blocking场景，字节内部是基于CSS来实现的RSS。

三、Flink架构优化

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

  • 三种业务场景的特点

image.png

image.png

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

  • 场景上对比发现：

    • 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
    • OLAP 计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。

image.png

image.png

3.3 Flink 如何支持 OLAP 场景

- 3.3.1 Flink 做 OLAP 的优势

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

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

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

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

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

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

3.3.2 Flink OLAP 场景的挑战

  • 秒级和毫秒级的小作业；
  • 作业频繁启停、资源碎片；
  • Flink OLAP 计算相比流式和批式计算，最大的特点是 Flink OLAP 计算是一个面向秒级和毫秒级的小作业，作业在启动过程中会频繁申请内存、网络以及磁盘资源，导致 Flink 集群内产生大量的资源碎片；
  • Latency + 高 APS 要求；
  • OLAP 最大的特点是查询作业对 Latency 和 QPS 有要求的，需要保证作业在 Latency 的前提下提供比较高的并发调度和执行能力，这就对 Flink 引擎提出了一个新的要求。

3.3.3 Flink OLAP 架构现状

  • Client：提交 SQL Query；
  • Gateway
    • 接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群；
  • Session Cluster：
    • 执行作业调度及计算，并返回结果。
  • JobManager 管理作业的执行，在接收到 Gateway 提交过来的作业逻辑执行计划后，将逻辑执行计划转换为物理执行计划，为每个物理计算任务分配资源，将每个计算任务分发给不同的 TaskManager 执行，同时管理作业以及每个计算任务执行状态；
  • TaskManager执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。

image.png

3.3.4 Flink 在 OLAP 架构上的问题与设想

  • 架构与功能模块：

    • JobManager 与 ResourceManager 在一个进程内启动，无法对JobManager 进行水平扩展；
    • Gateway 与 Flink Session Cluster 互相独立，无法进行统一管理；

  • 作业管理及部署模块：

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

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

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

  • 其他：

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

3.3.5 总结

image.png

四、Flink使用案例

4.1 电商流批一体实践

  • 抖音电商业务原有的离线和数据仓架构：

image.png

  • Flink社区现状:

image.png

4.2 字节Flink OLAP实践

image.png

image.png

avatar
文章
阅读
粉丝