【大数据专场 学习资料一】第四届字节跳动青训营

字节跳动青训营
10,331 阅读26分钟

第四届字节跳动青训营讲师非常用心给大家整理了课前、中、后的学习内容，同学们自我评估，选择性查漏补缺，便于大家更好的跟上讲师们的节奏，祝大家学习愉快，多多提问交流～

第一节：SQL 查询优化器浅析

概述

本节课程主要分为 4 个方面：

  1. 大数据体系和 SQL；
  1. 常见的查询优化器；
  1. 查询优化器的社区开源实践；
  1. SQL 相关的前沿趋势。

课前（必须）

大数据体系和 SQL

  • 了解生产系统中的大数据体系

    • 可以看一下市场上云厂商（火山引擎，阿里云，腾讯云，华为云，Google Cloud，Microsoft Azure）提供的大数据相关的产品，包括计算、存储、调度、应用等
    • 批式计算、流式计算、交互分析引擎、YARN、Kubernetes 等
  • 了解 SQL 的基本用法和关系代数基础知识（选择、 投影、连接、集合操作等）

  • 了解编译原理相关的基础知识

    • 词法分析（Lexical Analysis）
    • 语法分析（Syntactic Analysis）
    • 抽象语法树（Abstract Syntax Tree，AST）

  • 了解 SQL 里的执行计划

    • 逻辑计划（Logical Plan）
    • 物理计划（Physical Plan）
    • 分布式执行计划：Plan Fragment
    • Left-deep tree

  • 了解 SQL 执行的基本流程

    • 任务调度：DAG

  • 了解分布式系统中 shuffle 的实现方式

    • Broadcast shuffle vs. Repartition shuffle
    • 参考 MapReduce 和 Spark 系统

  • 了解 SQL 中 group-by 和 join 的执行方式

    • Hash-based vs. Sort-based

常见的查询优化器

  • Top-down Optimizer
  • Bottom-up Optimizer

  • Rule-based Optimizer，RBO

    • Rule
    • Pattern

  • Cost-based Optimizer，CBO

    • 动态规划
  • 交换律、结合律、传递性

  • RBO 优化规则

    • 列裁剪
    • 谓词下推
    • 传递闭包
    • Runtime Filter（min-max filter，in-list filter，bloom filter）
    • Join 消除
    • 谓词合并

  • CBO 相关概念

    • 统计信息

      • Number of Distinct Value，NDV
      • Selectivity
      • Cardinality

    • 代价模型

查询优化器的社区开源实践

  • Apache Calcite
  • Orca

  • Volcano/Cascade 框架

    • Memo
    • AND/OR Graph
    • Expression group
    • Group expression
    • Pattern
    • Rule
    • Branch-and-Bound Pruning
    • Winner

SQL 相关的前沿趋势

  • 存储计算分离
  • HSAP, HTAP, HTSAP
  • Cloud Native, Serverless
  • 数据仓库，数据湖，湖仓一体，联邦查询
  • 智能化：AI4DB，DB4AI

课中

大数据体系和 SQL

  1. 大数据体系全景图

  1. 为什么 SQL 如此流行？

    1. 有 MySQL、Oracle 之类使用 SQL 作为交互语言的数据库

    2. 有 JDBC、ODBC 之类和各种数据库交互的标准接口

    3. 有大量数据科学家和数据分析师等不太会编程语言但又要使用数据的人

    4. 多个大数据计算引擎都支持 SQL 作为更高抽象层次的计算入口

      1. MapReduce -> Hive SQL
      2. Spark -> Spark SQL
      3. Flink -> Flink SQL

  1. SQL 的一生

    2. Parser

      1. 把文本变成抽象语法树结构（AST）
      2. 涉及词法分析阶段（拆分字符串，提取关键字，字符串，数值等）和语法分析阶段（把词条按照定义的语法规则组装成抽象语法树结构）
      3. 和编译原理课程里的“前端”知识相关

    3. Analyzer

      1. 访问库/表元信息并绑定
      2. 判断 SQL 是否合理，比如数据库，表和列名是否存在，列的数据类型是否正确
      3. 将 AST 转换成逻辑计划树（在某些系统中这个工作由一个 Converter 完成）

  1. 逻辑计划树

    2. 所谓逻辑计划树，可以理解为逻辑地描述一个 SQL 如何一步步地执行查询和计算，最终得到执行结果的一个分步骤地计划。树中每个节点是是一个算子，定义了对数据集合的计算操作（过滤，排序，聚合，连接），边代表了数据的流向，从孩子节点流向父节点。之所以称它为逻辑的，是因为算子定义的是逻辑的计算操作，没有指定实际的算法，比如对于逻辑的排序算子，逻辑计划树里没有指定使用快排还是堆排。

  1. 查询优化

    1. SQL 是一种声明式语言，用户只描述做什么，没有告诉数据库怎么做

    2. 查询优化的目标是为 SQL 找到一个正确的且执行代价最小的执行计划

    3. 查询优化器是数据库的大脑，最复杂的模块，很多相关问题都是 NP 的

    4. 一般 SQL 越复杂，Join 的表越多，数据量越大，查询优化的意义就越大，因为不同执行方式的性能差别可能有成百上千倍

      1. 类比 gcc/g++ 编译程序时的编译级别（-O1, -O2, -O3），经过编译优化的程序运行效率更高

  1. 物理执行计划

    2. 优化器的输出是一个分布式的物理执行计划。
    3. 分布式物理执行计划的目标是在单机 Plan 的基础上最小化数据移动和最大化本地 Scan，生成 PlanFragment 树。
    4. 一个 PlanFragment 封装了在一台机器上对数据集的操作逻辑。每个 PlanFragment 可以在每个 executor 节点生成 1 个或多个执行实例，不同执行实例处理不同的数据集，通过并发来提升查询性能。
    5. Plan 分布式化的方法是增加 shuffle 算子，执行计划树会以 shuffle 算子为边界拆分为PlanFragment。

  1. Executor

    1. Executor 按照物理执行计划扫描和处理数据，充分利用机器资源（CPU 流水线，乱序执行，cache，SIMD）

常见的查询优化器

  • RBO

    • 基于关系代数等价规则对逻辑计划进行变换

    • 实现上：

      • Pattern：定义了特定结构的 Operator 子树（结构）
      • Rule：定义了如何将其匹配的节点替换（Substitute）为新形态，从而生成新的、等价的Operator 树（原地替换）
      • 优化器搜索过程被抽象为不断匹配 Pattern 然后应用 Rule 转换，直到没有可以匹配的 rule

    • 局限性：

      • 无法解决多表连接问题
      • 无法确定和选择最优的分布式 Join/Aggregate 执行方式

  • CBO

    • 使用一个模型估算执行计划的代价，选择代价最小的执行计划

    • 分而治之，执行计划的代价等于所有算子的执行代价之和

    • 通过 RBO 得到（所有）可能的等价执行计划（非原地替换）

    • 算子代价包含 CPU，cache misses，memory，disk I/O，network I/O 等代价

      • 和算子的统计信息有关，比如输入、输出结果的行数，每行大小等

      • 叶子算子 scan：通过统计原始表数据得到

        • 中间算子：根据一定的推导规则，从下层算子的统计信息推导得到
        • 和具体的算子类型，以及算子的物理实现有关（e.g. hash join vs. sort join）

    • 使用动态规划枚举所有执行计划，选出执行代价最小的执行计划

  • 统计信息

    • 基表统计信息

      • 表或者分区级别：行数、行平均大小、表在磁盘中占用了多少字节等
      • 列级别：min、max、num nulls、num、not nulls、num、distinct value(NDV)、histogram 等

    • 推导统计信息

      • 选择率（selectivity） ：对于某一个过滤条件，查询会从表中返回多大比例的数据
      • 基数（cardinality） ：基本含义是表的 unique 行数，在查询计划中常指算子需要处理的行数

查询优化器的社区开源实践

  • Volcano/Cascade 框架

    • Memo

      • Cascades Optimizer 在搜索的过程中，其搜索的空间是一个关系代数算子树所组成的森林，而保存这个森林的数据结构就是 Memo。Memo 中两个最基本的概念就是 Expression Group（下文简称 Group） 以及 Group Expression（对应关系代数算子）。每个 Group 中保存的是逻辑等价的 Group Expression，而 Group Expression 的子节点是由 Group 组成。

    • Memo 本质是 AND/OR Graph，通过共享相同的子树减少内存开销，记录搜索过的子树的最优执行计划（winner）

  • Branch-and-Bound Pruning

    • 已搜索完成的物理计划的代价最小值成为 Cost Upper Bound。当新的搜索分支的代价高于它时，不需继续搜索。初始 Cost Upper Bound 可由优化器根据启发式规则估算。

SQL 相关的前沿趋势

  • 存储计算分离
  • HSAP, HTAP, HTSAP
  • Cloud Native, Serverless
  • 数据仓库，数据湖，湖仓一体，联邦查询

  • 智能化

    • AI4DB

      • 自配置：智能调参（OtterTune，QTune）、负载预测、负载调度
      • 自诊断和自愈合：软硬件错误、错误恢复和迁移
      • 自优化：统计信息估计（ Learned cardinalities ）、代价估计、学习型优化器（IBM DB2 LEO），索引推荐，视图推荐

    • DB4AI

      • 内嵌人工智能算法（MLSQL，SQLFlow）
      • 内嵌机器学习框架（SparkML， Alink， dl-on-flink ）

课后

  1. Top-down 和 Bottom-up 的优化方式各有什么优缺点？
  1. Aggregate 和 Join 上面的 Filter 下推需要注意什么？什么类型的谓词才能下推倒 Aggregate 和 Join 算子的下面？
  1. Runtime Filter 在什么情况下会造成性能回退？
  1. 了解一下 Spark 系统中 Join Cardinality 的估算方式
  1. 了解一下 Aggregate cardinality/NDV 的估算方式
  1. 了解直方图在统计信息估计中的作用
  1. RBO 里几种 pattern 匹配规则（ARBITRARY，DEPTH_FIRST，TOP_DOWN，BOTTOM_UP）有什么优缺点？
  1. RBO 直到没有可以匹配的 rule 才结束在 serving 场景（在线服务场景）可能会有什么问题？（考虑 rule 很多的情况）除了这种结束方式，还有什么其他结束方式？
  1. CBO 里 Branch-and-bound pruning 可以以 bottom-up 的方式进行吗？

参考

  1. CMU 数据库相关课程，第一个是初级课程，第二个是高级课程。

    1. 15445.courses.cs.cmu.edu/fall2021/
    2. 15721.courses.cs.cmu.edu/spring2020/

  1. Access Path Selection in a Relational Database Management System

    1. 如果说选一篇在优化器框架上，被引用次数最多的文献，应该非这篇论文莫属了，这篇文章介绍了 System R 的优化器，其中关于 Join order enumeration，Selinger 可以说是开创了 dynamic programing based 的 bottom-up 的搜索空间算法的先河，直至今日，很多成熟的商业或开源数据库系统仍在沿用这套框架，比如Oracle / DB2 / PostgreSQL ...

  1. Volcano/Cascades 框架相关论文

    1. The Volcano Optimizer Generator : Extensibility and Efficient Search

    2. The Cascades Framework for Query Optimization

    3. Efficiency in the Columbia Database Query Optimizer

      • 这篇 paper 从实现的角度详细讲解了 columbia optimizer 的设计和实现，它完全参考了 volcano/cascades 中的概念和 top-down 的搜索策略，并做了一系列优化来改善 volcano/cascades 的优化效率。
  1. Apache Calcite: A Foundational Framework for Optimized Query Processing Over Heterogeneous Data Sources
  1. github.com/pingcap/awe…

  1. 以下这几篇文章从各自的角度回顾大数据系统的过去和展望大数据系统的未来，拓展大家的视野，激发大家投身大数据的热情。

    1. 解读数据架构的2021：大数据1.0体系基本建成，但头上仍有几朵乌云_架构_关涛 Tony_InfoQ精选文章
    2. 面向未来的HTSAP一体化数据平台该是什么样子？_文化 & 方法_张翔_InfoQ精选文章
    3. 云原生数据库设计新思路

第二节：流/批/OLAP 一体的 Flink 引擎介绍

概述

本节课程主要分为四个方面：

  1. Apache Flink 概述；
  1. 流批一体的 Apache Flink 架构；
  1. Apache Flink 的 OLAP 场景面临的问题及优化思路；
  1. Flink 使用案例；

课前（必须）

Apache Flink 概述

  • 大数据的发展背景及面临的问题，大数据解决方案的三驾马车；
  • Hadoop 发展历史：MapReduce 的概念；
  • 流式计算概念；
  • Apache Flink 是什么？

推荐文章：

  1. 大数据十年回顾：浪潮之巅数英雄_大数据_宋词_InfoQ精选文章；
  1. 大数据技术简介 - 掘金；
  1. 大数据Hadoop之--实时计算流计算引擎Flink(Flink环境部署) - 掘金；
  1. 现代流式计算的基石：Google DataFlow；
  1. Apache Flink: What is Apache Flink? - Architecture；
  1. Streaming 101: The world beyond batch(A high-level tour of modern data-processing concepts)；
  1. Streaming 102: The world beyond batch(The what, where, when, and how of unbounded data processing)；

流批一体的 Apache Flink 架构

  • Flink 架构的概念：

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

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

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

  • 流批一体：

    • 流式计算与批式计算；

推荐文档：

  1. Flink Architecture；
  1. Glossary；
  1. Deployment Overview；
  1. Jobs and Scheduling；
  1. 一文读懂Apache Flink技术 - 掘金；
  1. Flink入门宝典(详细截图版) - 掘金；

Apache Flink 的 OLAP 场景面临的问题及优化思路

  • OLAP 业务场景；
  • Flink Session Cluster 集群；

推荐文档：

  1. OLAP技术选型思路总结，你绕不开的“不可能三角”_关二爷大数据笔记_InfoQ写作社区；
  1. 字节跳动的 Flink OLAP 作业调度和查询执行优化实践 - 掘金；

课中

Apache Flink 概述

Apache Flink 诞生背景

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

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

  • 流式计算特点：

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

为什么 Flink 会脱颖而出

  • 流式计算引擎发展历史

    • Storm：History of Apache Storm and lessons learned - thoughts from the red planet；

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

    • Spark Streaming：An Architecture for Fast and General Data Processing on Large Clusters；

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

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

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

Apache Flink 开源生态

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

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

Flink 整体架构

Flink 分层架构

架构图参考上面

  • 执行引擎层（Runtime 层）：执行引擎层提供了统一的 DAG，用来描述数据处理的 Pipeline，不管是流还是批，都会转化为 DAG 图，调度层再把 DAG 转化成分布式环境下的 Task，Task 之间通过 Shuffle 传输数据；

  • 状态存储层：负责存储算子的状态信息

Flink 整体架构（Flink Architecture）

  • 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 和数据交换。

Flink 作业示例

  • ExecutionGraph 生成：DataStream API Code --> JobGraph --> ExecutionGraph（Parallelized）
  • OperatorChain：

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 执行模式。

    • Pipeline Region Scheduler 机制：FLIP-119 Pipelined Region Scheduling - Apache Flink - Apache Software Foundation；

  • 流批一体的 Shuffle Service 层（FLIP-31: Pluggable Shuffle Service - Apache Flink - Apache Software Foundation）

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

  • Flink 流批一体总结

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

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；

    • 其他：

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

课后

  1. Dataflow Model 核心设计思想是什么？
  1. Flink 相比于 Storm、Spark Streaming 有哪些优势？
  1. 为什么 Flink 可以做到支持 流/批/OLAP 三种业务场景？三种业务场景核心差异和挑战是哪些？
  1. 流式场景中，反压一种经常遇到的 case，Flink 是如何处理反压的？你知道其他引擎是怎么处理的么？
  1. Flink JobManager 各个组件分别是做什么的？你觉得为什么要这样设计？
  1. 有兴趣的，可以参考 First steps、Intro to the DataStream API、Learn Flink Overview 几篇文档，本地跑一个 Flink Job 试下。

\

参考文献

  1. 大数据十年回顾：浪潮之巅数英雄_大数据_宋词_InfoQ精选文章；
  1. 大数据技术简介 - 掘金；
  1. 大数据Hadoop之--实时计算流计算引擎Flink(Flink环境部署) - 掘金；
  1. 现代流式计算的基石：Google DataFlow；
  1. Flink 社区文档集合：Apache Flink: What is Apache Flink? - Architecture；
  1. Streaming 101: The world beyond batch(A high-level tour of modern data-processing concepts)；
  1. Streaming 102: The world beyond batch(The what, where, when, and how of unbounded data processing)；

第三节：Exactly Once 语义在 Flink 中的实现

概述

本节课程主要分为四个方面：

  1. 数据流和动态表
  1. Exactly-Once 和 Checkpoint
  1. 端到端 Exactly-Once 实现
  1. Flink 案例讲解

课前部分主要罗列课程中涉及到的概念。对于不熟悉的概念，同学们可以提前查询预习；课中部分主要罗列每一部分的关键思路，帮助同学们跟上课程的进度；课后部分是一些问题，帮助同学们在课后梳理本课程的重点。

课前 （必须）

数据流和动态表

  • Stream: 数据流
  • Dynamic Table: 动态表
  • Continuous Queries: 连续查询
  • Append-only Stream: Append-only 流（只有 INSERT 消息）
  • Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息）
  • Upsert Stream:: Upsert 流（同时包含 UPSERT 消息和 DELETE 消息）
  • Changelog: 包含 INSERT/UPDATE/DELETE 等的数据流
  • State: 计算处理逻辑的状态

Exactly-Once 和 Checkpoint

  • Application Consistency Guarantees: 作业一致性保证

    • At-most-once：每条数据消费至多一次
    • At-least-once：每条数据消费至少一次
    • Exactly-once: 每条数据都被消费且仅被消费一次
  • Checkpoint: Flink 实现各个计算逻辑状态快照算法，也可指一次状态快照
  • Checkpoint barrier: 用于标识状态快照的制作，也将数据划分成不同的消费区间
  • Checkpoint Alignment: 等待多个上游的Checkpoint barrier到达的现象
  • JobManager: 负责协调和管理 Checkpoint

端到端 Exactly-Once 实现

  • Two-phase commit protocol: 两阶段提交协议
  • Transaction: 一系列保证原子性操作的集合，即操作同时执行或者都不执行
  • Kafka: 消息中间件
  • State Backend: 用于管理和保存状态到远端可靠存储

Flink 案例讲解

  • Deduplication：去重，在 state 保留的时间内对重复消息进行去重
  • Aggregation：聚合操作，比如求和、求最大值等

课中

数据流和动态表

  • 如何在实时数据流中定义 SQL 语义中的表？

    • 动态表 ： 随时间不断变化的表，在任意时刻，可以像查询静态批处理表一样查询它们

  • 实时流的查询特点？

    • 查询从不终止
    • 查询结果会不断更新，并且会产生一个新的动态表
    • 结果的动态表也可转换成输出的实时流

  • 动态表到实时流的转换

    • Append-only Stream: Append-only 流（只有 INSERT 消息）
    • Retract Stream: Retract 流（同时包含 INSERT 消息和 DELETE 消息）

  • Upsert Stream:: Upsert 流（同时包含 UPSERT 消息和 DELETE 消息）

  • 算子状态

    •   在流式计算中，会存在有状态的计算逻辑（算子），有状态的算子典型处理逻辑如下图所示：

比如，需要计算某个用户在网上的点击量，该用户在网站当前的总点击次数就是算子状态，对于新的输入数据，先判断是否是该用户的点击行为，如果是，则将保留的点击次数（状态）增加一，并将当前累加结果输出。

  • 数据流和动态表的转换关系图

Exactly-Once 和 Checkpoint

一致性保证语义

  • At-most-once：每条数据消费至多一次，处理延迟低
  • At-least-once：每条数据消费至少一次，一条数据可能存在重复消费
  • Exactly-once：每条数据都被消费且仅被消费一次，仿佛故障从未发生

Checkpoint

  • Checkpoint barrier 的下发

  • 算子状态制作和 barrier 传递

  • 多个上游的等待 barrier 对齐现象

  • Checkpoint 并不阻塞算子数据处

  • Checkpoint ACK和制作完成

端到端 Exactly-Once 实现

两阶段提交协议（2PC）

  • Coordinator：协作者，同步和协调所有节点处理逻辑的中心节点
  • Participant：参与者，被中心节点调度的其他执行处理逻辑的业务节点

两阶段提交协议在 Flink 中的应用

  • Flink 中协作者和参与者的角色分配

  • 协作者（JobManager）发起阶段一提交

  • 各算子 Checkpoint 的制作

  • 提交阶段及 Checkpoint 的制作完成

课后

  1. 流式处理中算子为什么会有状态？
  1. 数据流和动态表之间是如何进行转换的？
  1. Flink 作业为什么需要考虑故障恢复？
  1. Flink 故障恢复前为什么需要Checkpoint？
  1. 为什么不能保留任意时刻的状态作为故障恢复的时间点？
  1. Flink Checkpoint 对作业性能的影响有多大？
  1. 两阶段提交协议对性能影响有多大？
  1. 写入下游如果不支持事务读写，能做到 Exactly-Once 语义么？

参考文献

  1. Stream Processing with Apache Flink: Fundamentals, Implementation, and Operation of Streaming Applications

Flink PMC 著作推荐大家作为流式处理和 Flink 入门读物。

  1. nightlies.apache.org/flink/flink…

Flink 官方文档，需要了解 Flink 的同学建议阅读。

  1. en.wikipedia.org/wiki/Two-ph…

维基百科中两阶段提交协议的词条。

  1. flink.apache.org/news/2016/0…

关于 SQL 在 Flink 中使用的一篇博客

  1. flink.apache.org/features/20…

Flink 中两阶段提交协议实现的一篇博客

avatar
文章
阅读
粉丝