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

狂野的拉布拉多哎
134 阅读8分钟

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

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

关键词：Flink

Apache Flink 是为分布式、高性能、随时可用以及准确的流处理应用程序打造的开源流处理框架

flink

1 Flink概述

1.1 大数据背景下的必然性

随着互联网时代的发展，大数据越趋向于完善，不断有新的要求提成，然后产出一个相应的“解题模板”，对于现在很多数据实时性要求的不断提高，便诞生了流式计算。

大数据的实时性要求，大数据的计算架构也开始从批式计算到流式计算发展。

1.2 Flink的脱颖而出

Apache Flink是一个开源的流处理框架，应用于分布式、高性能、高可用的数据流应用程序。可以处理有限数据流和无限数据，即能够处理有边界和无边界的数据流。无边界的数据流就是真正意义上的流数据，所以Flink是支持流计算的。有边界的数据流就是批数据，所以也支持批处理的。不过Flink在流处理上的应用比在批处理上的应用更加广泛，统一批处理和流处理也是Flink目标之一。Flink可以部署在各种集群环境，可以对各种大小规模的数据进行快速计算。

随着大数据技术在各行各业的广泛应用，要求能对海量数据进行实时处理的需求越来越多，同时数据处理的业务逻辑也越来越复杂，传统的批处理方式和早期的流式处理框架也越来越难以在延迟性、吞吐量、容错能力以及使用便捷性等方面满足业务日益苛刻的要求。其中流式计算的典型代表是Storm和Flink技术。它们数据处理的延迟都是亚秒级低延迟，但是Flink相比Storm还有其他的一些优势，比如支持exactly once语义，确保数据不会重复。 Storm支持at least once语义，保证数据不会丢失。保证数据不会重复的代价很高，比如数据下游操作属于幂等操作。另外从测试结果来看，Flink在低延迟的基础上还能保证高吞吐，优势明显。

在这种形势下，新型流式处理框架Flink通过创造性地把现代大规模并行处理技术应用到流式处理中来，极大地改善了以前的流式处理框架所存在的问题。

1.3 Flink的特性

  1. 支持高吞吐、低延迟、高性能的流处理
  2. 支持带有事件时间的窗口（Window）操作
  3. 支持有状态计算的 Exactly-once 语义
  4. 支持高度灵活的窗口（Window）操作，支持基于 time、count、session，以及 data-driven 的窗口操作
  5. 支持具有 Backpressure 功能的持续流模型
  6. 支持基于轻量级分布式快照（Snapshot）实现的容错
  7. 一个运行时同时支持 Batch on Streaming 处理和 Streaming 处理
  8. Flink 在 JVM 内部实现了自己的内存管理
  9. 支持迭代计算
  10. 支持程序自动优化：避免特定情况下 Shuffle、排序等昂贵操作，中间结果有必要进行缓存

1.4 Flink的基石

  • 检查点 checkpoint 轻量级
  • 状态 state keyedstate operatorstate
  • 时间 time EventTime（业务时间） ingestion time（摄取时间） processing time（处理时间）
  • 窗口 windows 滚动时间、滑动时间、会话窗口、计数窗口

2 Flink整体架构

2.1 分层架构

image-20220727165952593

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

2.2 总体架构

image-20220727170610863

  • Dispatcher：接收作业，拉起JobManager来执行作业，并在JobMaster挂掉之后恢复作业
  • JobMaster：管理一个job的整个生命周期（调度task、触发协调task做checkpoint、协调容错恢复等），会向ResourceManager申请slot，并将task调度到对应的TM上
  • TaskManager（TM）：负责执行一个DataFlow Graph和各个task以及data streams的buffer和数据交换
  • ResourceManager：负责slot资源的管理和调度，TaskManager拉起之后会向RM注册

2.3 工作示例（Dataflow Model）

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

image-20220727171845034

将业务逻辑转化为Streaming DataFlow Graph（假设作业的sink算子并发为1，其余算子的并发为2）

image-20220727172059156

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

image-20220727172602481

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

image-20220727172750685

2.4 Flink如何做到流批一体

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

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

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

    • SQL 层
    • DataStream API 层统一，批和流都可以使用 DataStream API 来开发
    • Scheduler 层架构统一，支持流批场景
    • Failover Recovery 层 架构统一，支持流批场景
    • Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service

image-20220727175635906

  • 流批一体的 Scheduler 层：

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

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

      • EAGER（Streaming 场景）：申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信
      • LAZY（Batch 场景）：先调度上游，等待上游产生数据或结束后再调度下游，类似 Spark 的 Stage 执行模式

  • 流批一体的 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 在策略上的定制，同时还能避免在共性需求上进行重复开发

image-20220727181233051

3 Flink架构优化

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

  • 三种业务场景的特点

image-20220727202810869

  • 三种业务场景面临的挑战

image-20220727203142886

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

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

3.3 Flink如何支持OLAP场景

image-20220727204153588

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

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

    • JobManager 管理作业的执行，在接收到 Gateway 提交过来的作业逻辑执行计划后，将逻辑执行计划转换为物理执行计划，为每个物理计算任务分配资源，将每个计算任务分发给不同的 TaskManager 执行，同时管理作业以及每个计算任务执行状态；
    • TaskManager执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。

\

avatar
文章
阅读
粉丝