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

《流/批/OLAP 一体的 Flink 引擎介绍》第四届字节跳动青训营

本章课程目录

课前预习

Apache Flink 概述

• 大数据的发展背景及面临的问题，大数据解决方案的三驾马车；

• Hadoop 发展历史：MapReduce 的概念；

• 流式计算概念；

• Apache Flink 是什么？

流批一体的 Apache Flink 架构

• Flink 架构的概念：

  • JobManager、TaskManager；
  • Task、Slot、Operator；
  • Dataflow、DAG、JobGraph；

• 分布式计算系统概念及作用：

  • 调度器；
  • Shuffle Service；
  • HA；
  • Failover Recovery；

• 流批一体：

  • 流式计算与批式计算；

---

课中

Apache Flink 概述

Apache Flink 诞生背景

• Hadoop 诞生背景，Hadoop 解决了什么问题？（大数据十年回顾：浪潮之巅数英雄大数据宋词_InfoQ精选文章）

• 实时计算的业务场景需求、为什么会出现流式计算

  • 数据实时价值更大；
  • 大数据批式处理分钟级、小时级、天极，部分业务场景无法接受；

• 流式计算特点：

  • 实时计算、快速、低延迟；
  • 无限流、动态、无边界；
  • 7*24 持续运行；

为什么 Flink 会脱颖而出

• 流式计算引擎发展历史

• 

  • • Storm API 的 low-level 以及开发效率低下；
    • 一致性问题：Storm 更多考虑到实时流计算的处理时延而非数据的一致性保证；

  • Spark Streaming：

    • Spark Streaming 相比于 Storm 的低阶 API 以及无法正确性语义保证，Spark 是流处理的分水岭：第一个广泛使用的大规模流处理引擎，既提供较为高阶的 API 抽象，同时提供流式处理正确性保证。

  • Flink：从产品技术来看，Flink 作为一个最新的实时计算引擎，具备如下流计算技术特征：

    • 完全一次保证：故障后应正确恢复有状态运算符中的状态；
    • 低延迟：越低越好。许多应用程序需要亚秒级延迟；
    • 高吞吐量：随着数据速率的增长，通过管道推送大量数据至关重要；
    • 强大的计算模型：框架应该提供一种编程模型，该模型不限制用户并允许各种各样的应用程序在没有故障的情况下，容错机制的开销很低；
    • 流量控制：来自慢速算子的反压应该由系统和数据源自然吸收，以避免因消费者缓慢而导致崩溃或降低性能；
    • 乱序数据的支持：支持由于其他原因导致的数据乱序达到、延迟到达后，计算出正确的结果；
    • 完备的流式语义：支持窗口等现代流式处理语义抽象；
    • Google Dataflow Model 的开源引擎实现。

• 主要的流式计算引擎能力对比

Apache Flink 开源生态

Apache Flink 在开源生态上的能力比较强大，可以支持：

1. 流批一体：支持流式计算和批式计算；
2. OLAP：Flink 可以支持 OLAP 这种短查询场景；
3. Flink ML：pyFlink、ALink、AIFlow 等生态支持 Flink 在 ML 场景的应用；
4. Gelly：图计算；
5. Stateful Function：支持有状态的 FAAS 场景；

Flink 整体架构

为什么要流批一体

如何做到流批一体

• 为什么需要流批一体

  • 一些业务场景，除了实时的数据统计需求，为了确认运营或产品的效果，用户同时还需要和历史数据做比较，比如，抖音一些直播数据的统计；

  • 这种架构有一些痛点：

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

• 流批一体的挑战

  

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

    • 无限数据集 --> 有限数据集；
    • 低延迟 --> 实时性要求不高；

• Flink 如何做到流批一体

  

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

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

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

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

• 流批一体的 Scheduler 层

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

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

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

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

Flink 架构优化

流/批/OLAP 业务场景概述

• 三种业务场景的特点

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

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

• 场景上对比发现：

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

Flink 如何支持 OLAP 场景

• Flink 做 OLAP 的优势

  

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

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

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

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

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

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

• Flink OLAP 场景的挑战

  • 秒级和毫秒级的小作业；

  • 作业频繁启停、资源碎片；

    • Flink OLAP 计算相比流式和批式计算，最大的特点是 Flink OLAP 计算是一个面向秒级和毫秒级的小作业，作业在启动过程中会频繁申请内存、网络以及磁盘资源，导致 Flink 集群内产生大量的资源碎片；

  • Latency + 高 APS 要求；

    • OLAP 最大的特点是查询作业对 Latency 和 QPS 有要求的，需要保证作业在 Latency 的前提下提供比较高的并发调度和执行能力，这就对 Flink 引擎提出了一个新的要求。

• Flink OLAP 架构现状

  • Client：提交 SQL Query；

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

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

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

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

  • 架构与功能模块：

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

  • 作业管理及部署模块：

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

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

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

作者：青训营官方账号 链接：juejin.cn/post/712275…

\