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

冬天真的冷
171 阅读8分钟

image.png

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

Flink

一、Apache Flink 的诞生背景

1、 什么是大数据
大数据（Big Data） :指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合。
大数据的特点：

  • 海量化（Volumes）
  • 多样化（Variety）
  • 快速化（Velocity）
  • 价值化（Value）

2、大数据计算框架发展历史

  • 史前阶段~2006年：传统数据仓库，Oracle，单机，黑箱使用\
  • Hadoop：分布式，Map-Reduce，离线计算\
  • Spark：批处理，流处理，SQL 高阶 API，内存迭代计算\
  • Flink：流计算，实时、更快，流批一体，Streaming/Batch SQL

3、为什么需要流式计算
（1）大数据的实时性带来更大价值，比如：

  • 监控场景
  • 金融风险
  • 实时推荐
  • ......

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

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

流式计算：

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

4、流式计算引擎对比

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

image.png

5、Apache Flink开源生态

image.png

二、Flink整体架构

1、Flink分层架构

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

2、Flink总体架构

image.png 一个Flink集群，主要包含以下两个核心组件:\

1. JobManager (JM) :负责整个任务的协调工作，包括:调度task、触发协调Task做Checkpoint、协调容错恢复等;

2. TaskManager (TM) :负责执行一个DataFlowGraph的各个task以及data streams的buffer和数据交换。

JobManager

image.png Dispatcher：收作业，拉起JobManager来执行作业，并在JobMaster挂掉之后恢复作业;
JobMaster：管理一个 job的整个生命周期，会向ResourceManager申请slot，并将task调度到对应TM上；
ResourceManager：负责slot资源的管理和调度, Task manager拉起之后会向RM注册。

3、Flink作业示例

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

//Sourse
DataStream<String> lines = env.addSourse(new FlinkKafkaConsumer<>(...));

//Transformation
DataStream<String> events = lines.map((line) -> parse(line));
DataStream<Statistics> stats = events
           .keyBy(event -> event.id)
           .timeWindow(Time.seconds(10))
           .apply(new myWindowAggregationFunction());
 
//Sink
stats.addSink(new BucketingSink(path));

4、Flink如何做到流批一体

为什么需要流批一体
原有架构下流批分离，数据从数据源分别流向实时数仓（Flink）和离线数仓（Spark/Hive）存在一些痛点：
（1）人力成本较高：批、流两套系统，相同逻辑需要开发两遍；
（2）数据链路冗余：本身设计内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费；
（3）数据口径不一致：两套系统、两套算子、两套 UDF ，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。

流批一体的挑战
流和批业务场景的特点如下表：

image.png

Flink 如何做到流批一体

  • 批式计算是流式计算的特例， Everything is Streams ，有界数据集（批式数据）也是一种数据流、一种特殊的数据流。
  • 因此，理论上我们可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应拓展性、并允许做不同的优化策略。
  • 因此不管是有边界数据集（批式数据）还是无边界数据集， Flink 都可以天然支持，这是 Flink 支持流批一体的基础。并且 Flink 在流批一体上，从上层 API 到底层的处理机制都是统一的，是真正意义上的流批一体。

Apache Flink 主要从以下几个模块来做流批一体：
（1）SQL层；
（2）DataStream API 层统一，批和流都可以使用 DataStream API 来开发；
（3）Scheduler 层架构统一，支持流批场景；
（4）Failover Recovery 层架构统一，支持流批场景；
（5）Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service。

流批一体的 Scheduler 层

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

image.png

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

image.png

2.4.5 流批一体的 Shuffle Service 层

  • Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做 Shuffle。
  • 实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为 Shuffle。
  • 针对不同的计算框架，Shuffle 通常有几种不同的实现：
    （1）基于文件的 Pull Based Shuffle，比如 Spark 或 MR，其特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些
    （2）基于 Pipeline 的Push Based Shuffle ，比如 Flink、 Storm、 Presto 等，其特点是低延迟和高性能，但是因为 Shuffle数据没有存储下来，如果是 Batch 任务的话，就需要进行重跑恢复。
  • 流和批 Shuffle 之间的差异：
    （1）Shuffle 数据的生命周期：流作业的 Shuffle 数据与 Task 是绑定的，而批作业的 Shuffle 数据与 Task 是解耦的；
    （2）Shuffle 数据的存储介质：流作业的生命周期比较短，而且流作业为了实时性，Shuffle 通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里；
    （3）Shuffle 的部署方式：流作业 Shuffle 服务和计算节点部署在一起，可以减少网络开销，从而减少 latency，而批作业不同。
  • Flink 对于流和批提供两种类型 Shuffle，虽然 Streaming 和 Batch Shuffle 在具体的策略上存在一定的差异，但本质上都是为了对数据进行 Re-Partition ，因此不同的 Shuffle 之间是存在一定共性的。
  • 所以 Flink 的目标是提供一套统一的 Shuffle 架构，既可以满足不同 Shuffle 在策略上的定制，同时还能避免在共性需求上进行重复开发。

为了统-Flink在Streaming和Batch模式下的Shufle架构，Flink 实现了一个Pluggable的ShuffleService框架，抽象出一些公共模块。

  • 在Streaming和OL AP场景：为了性能的需要，通常会使用基于Pipeline 的Shuffle模式
  • 在Batch场景：一般会选取 Blocking的Shufle模式

image.png

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

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

三、 Flink 架构优化

1 、流/批/OLAP 业务场景概述

  • 三种业务场景的特点对比：

image.png

  • 三种业务场景解决方案的要求及带来的挑战：

image.png

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

  • 通过前述对比分析，可以发现：
    （1）批式计算是流式计算的特例， Everything is Streams ，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
    （2）而 OLAP 计算是一种特殊的批式计算，它对并发性和实时性要求更高，其他情况与普通批式作业没有特别大区别。
  • 因此，理论上我们是可以用一套引擎架构来解决上述三种场景，只不过需要对不同场景支持相应的扩展性、并运行做不同的优化策略。

image.png

3、Flink 如何支持 OLAP 场景

  • Apache Flink 从流式计算出发，需要想支持 Batch 和 OLAP 场景，就需要解决下面的问题：

image.png 3.3.1 Flink 做 OLAP 的优势

image.png

3.3.2.Flink OLAP 场景的挑战

image.png

3.3.3.Flink OLAP 架构现状

image.png

  • Client：提交 SQL Query；

  • Gateway

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

  • Session Cluster

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

4、Flink 在 OLAP 架构的问题与设想

  • 架构与功能模块：

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

  • 作业管理及部署模块：

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

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

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

  • 其他：

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

Apache Flink最终演进到结果如下：

image.png

avatar
文章
阅读
粉丝