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

foliage
75 阅读9分钟

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

一、Flink概述

什么是大数据

要了解Flink为什么诞生，首先要知道大数据是什么。大数据：指无法在一定时间内用常规工具对其进行获取、存储、管理和处理的数据集合。

大数据的特点：

  • 价值化（Value）：数据的价值密度是非常低的，但是整体的数据是十分有价值的
  • 海量化（Volumes）：
  • 快速化（Velocity）：数据的产生和处理时非常快的
  • 多样化（Variety）：数据的类型是多种多样的，比如有结构化、半结构化、格式化等等

大数据计算框架的发展

  • 史前阶段（~ 2006）

    • 传统数仓
    • Oracle
    • 单机
    • 黑箱使用

  • Hadoop

    • 分布式
    • Map-Ruduce
    • 离线计算

  • Spark

    • 批处理
    • 流处理
    • SQL高阶API
    • 内存迭代计算

  • Flink

    • 流计算
    • 实时、更快
    • 流批一体
    • Streaming/batch SQL

为什么有流式计算

当今社会处于数据喷射式爆发的时代，无时无刻不有大量的数据，而这些无时无刻产生的数据有着十分巨大的价值，比如：

  • 监控场景：如果能实时发现业务系统的健康状态，就能提前避免业务故障
  • 金融风控：如果实时监测出异常交易的行为，就能及时阻断风险的发生
  • 实时推荐：比如在抖音，如果可以根据用户的行为数据发掘用户的兴趣、偏好，就能向用户推荐更感兴趣的内容
  • ...

批处理和流处理的对比

批式处理：

  • 离线计算，非实时
  • 静态数据集
  • 小时/天等周期性计算

流式计算：

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

常见的流式计算引擎和对比

  • storm
  • MillWheel （Google）
  • Kafka
  • Cloud Dataflow（Google）
  • Flink
  • Spark streaming
  • Beam

image.png

为什么Flink能脱颖而出？

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

Apache Flink开源生态

index.png

二、Flink的架构

Flink分层框架

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

Flink整体结构

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

  • JobManager（JM）：负责整个任务的协调工作，包括：调度task、触发协调task做Checkpoint、协调容错恢复等等。JobManager又有如下部件： index.png
    • Dispatcher：接受作业，拉起JobManager来执行作业，并在Jobmaster挂掉之后恢复作业。
    • Jobmaster：管理一个job的整个生命周期，会向ResourceManager申请slot，并将task调度到对应TM上。
    • ResourceManager：负责slot资源的管理和调度，Task Manager拉起之后会向RM注册。
  • TaskManager（TM）：负责执行一个DataFlowGraph的各个task以及data streams的buffer和数据交换。

slot：taskmanager调度具体的task到slot上执行，一个slot只运行同一个task的subtask

流式wordcount实例

从kafka中读取一个实时数据流，每10s统计一次单词出现次数，datastream实现代如下：

index.png 在上面过程中，我们可以提高并发度，将来自不同数据的source和map可以并发执行，然后为了更高效地分布式执行，我们将source和map在一个线程中执行。

index.png

每一个subtask在taskmanager执行结构如下：

  • 一个taskmanager可以有多个task slot
  • 一个subtask运行在一个task slot中

index.png

Flink如何做到流批一体

为什么需要流批一体或者说流批一体有什么应用
  • 在抖音中，实时统计直播人数、点赞数、播放量
  • 统计昨天抖音的播放量、评论量、广告收入

第一种情况就是典型的流式处理，第二种就是典型的批处理，在日常生活中，这两种情况都有各自的需求，因此才有了流批一体计算。

流批一体的架构图

index.png

但是上诉架构也有一些缺点：

  • 流批处理两套系统相同的逻辑需要开发两遍
  • 数据量路冗余：本身计算内容一致，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费。
  • 数据口径不一致：两套系统、两套算子、两套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 层

Schedule是作用：负责将作业的 DAG 转化为在分布式环境中可以执行的 Task

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

三、FLink支持OLAP

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

Flink 做 OLAP 的优势就是可以统一引擎 缺点就是作业频繁启停、资源碎片化、Latency+高APS要求

FLink OLAP架构图

index.png

  • Client：提交 SQL Query；

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

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

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

总结：

  • 了解了Flink产生的原因，特点，以及为什么FLink比其他流式处理引擎强，强在哪。
  • 本次课程学习Flink的架构中的DataStream 层、调度层、Shuffle Service 层。
  • 了解了Flink在OLAP下的架构
avatar
文章
阅读
粉丝