流_批_OLAP 一体的 Flink 引擎 | 青训营笔记

Seed_userx
206 阅读9分钟

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

Flink 概述

Apache Flink 的诞生背景

大数据（Data） ：指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合。具有 价值化（value） 、海量化（Volumes） 、多样化（Variety） 、快速化（Velocity） 的特点

  • 价值化：在海量多样数据的快速分析下能够发挥出更高的数据价值
  • 海量化：数据量从TB到PB级别
  • 多样化：数据类型复杂，超过80%的数据是非结构化的
  • 快速化：数据量在持续增加（两位数的年增长率）数据的处理速度要求高

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

  • 史前阶段（~2006）：使用传统的数据仓库、数据库、单机和黑箱的使用

  • Hadoop：Haddop是由Apche基金会开发的分布式系统基础架构，主要用于海量数据的存储和海量数据据的分析。

    在MapReduce的思想下，Hadoop可以并行工作，以加快任务处理速度，保证Hadoop的高效性。

    Hadoop底层会维持多个副本，这意味着即使Hadoop中的某个计算元素或存储出现故障，也不会导致数据丢失，体现了Hadoop的高可靠性。

    同时Hadoop在集群间分配数据，可方便地扩展数以千计的节点，实现高扩展性。

    Hadoop还能够自动将失败的任务重新分配，具有高容错性。

  • Spark： 相比于前代框架Hadoop，Spark在计算性能上有了明显的提升。并且Spark在数据处理上，同时支持批处理和流处理，能够满足更多场景下的需求。

    Spark SQL：

    • Spark SQL 支持多种结构化数据格式的读取，比如JSON，Parquet或者Hive表。
    • Spark SQL 支持从多种外部数据源读取数据，处了本地数据，HDFS以及S3之外，还可以通过JDBC等标准数据库连接器连接外部的关系型数据库系统。
    • Spark SQL 能够在Spark程序中自由的进行SQL操作，并与各种编程语言Python/Java/Scala实现高度融合。

    内存迭代计算：Spark迭代运算，采用内存存储中间计算结果，减少了迭代运算的磁盘IO，并通过并行计算DAG图的优化，减少不同任务之间的依赖，降低延迟等待时间。

  • Flink：Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 通过实现 Google Dataflow 流式计算模型实现了高吞吐、低延迟、高性能兼具实时流式计算框架。同时Flink通过灵活的执行引擎，能够同时支持批处理任务与流处理任务，达到流批一体的方式。

流式计算

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

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

大数据实时性的需求，带来了大数据计算架构模式的变化

image.png

流式计算框架对比：

image.png 知子莫若父，来看看官方怎么描述Flink

  • Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memory speed and at any scale.

    翻译过来就是：

    Apache Flink是一个框架和分布式处理引擎，用于在无界和有界数据流上进行有状态计算。Flink被设计为可以在所有常见的集群环境中运行，以内存速度和任何规模执行计算。

image.png

Flink 整体架构

Flink的分层架构

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

image.png

Flink的总体架构

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

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

JobManager的职责

image.png

Dispatcher： 接收作业，拉起 JobManager 来执行作业，并在 JobMaster 挂掉之后恢复作业；

JobMaster： 管理一个 job 的整个生命周期，会向 ResourceManager 申请 slot，并将 task 调度到对应 TM 上；

ResourceManager： 负责 slot 资源的管理和调度，TaskManager 拉起之后会向 RM 注册；

Flink的流批一体

  • 为什么需要流批一体

    举个例子：

    • 在抖音中，实时统计一个短视频的播放量、点赞数，也包括抖音直播间的实时观看人数等；
    • 在抖音中，按天统计创造者的一些数据信息，比如昨天的播放量有多少、评论量多少、广告收入多少；

我们先来看一个架构 image.png

上述架构有一些痛点：

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

流和批业务场景的特点如下表：

image.png

批式计算相比于流式计算核心的区别如下表：

image.png

  • Flink如何做到流批一体

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

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

因此，理论上我们是可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。

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

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

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

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

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

在 1.12 之前的 Flink 版本中，Flink 支持以下两种调度模式： image.png

  • EAGER模式

    16 个 task 会一起调度，集群需要有足够的资源

    image.png

  • LAZY模式

    最小调度一个task即可，集群有1个slot资源可以运行

    image.png

  • 流批一体的 Shuffle Service 层

    Shuffle： 在分布式计算中，用来连接上下游数据交互的过程叫做 Shuffle。

    实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为 Shuffle。

    image.png

针对不同的分布式计算框架，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 对于流和批提供两种类型的 Shuffle，虽然 Streaming 和 Batch Shuffle 在具体的策略上存在一定的差异，但本质上都是为了对数据进行 Re-Partition，因此不同的 Shuffle 之间存在一定的共性的。

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

总结：

经过相应的改造和优化之后，Flink 在架构设计上，针对 DataStream 层、调度层、Shuffle Service 层，均完成了对流和批的支持。

至此，业务已经可以非常方便地使用 Flink 解决流和批场景的问题了。

avatar
文章
阅读
粉丝