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

SEANJTX
206 阅读10分钟

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

01 Flink概述

1.1 Apache Flink的诞生背景

1.1.1 什么是大数据

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

image.png

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

image.png

1.1.3 为什么需要流式计算

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

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

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

image.png

1.2 为什么Apache Flink会脱颖而出

1.2.1 流式计算引擎发展历程

大数据如果从 Google对外发布MapReduce论文算起，已经前后跨越将近二十年，业内常用的计算框架演化历史（红框是流式计算框架)

image.png

1.2.2 流式计算引擎对比

流式计算框架对比：

image.png

补充：

  1. Storm是Twitter开源的分布式实时大数据处理框架，最早开源于github，从0.9.1版本之后，归于Apache社区，被业界称为实时版Hadoop。随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍，比如网站统计、推荐系统、预警系统、金融系统(高频交易、股票)等等，大数据实时处理解决方案（流计算）的应用日趋广泛。
  • 是一个分布式, 高容错的实时计算框架
  • Storm进程常驻内存, 永久运行
  • Storm数据不经过磁盘, 在内存中流转, 通过网络直接发送给下游
  1. Spark Streaming是基于spark的流式批处理引擎，其基本原理是把输入数据以某一时间间隔批量的处理，当批处理间隔缩短到秒级时便可以用于处理实时数据流。
  • 计算流程： -Spark Streaming是将流式计算分解成一系列短小的批处理作业。这里的批处理引擎是Spark Core，也就是把Spark Streaming的输入数据按照batch size(如1秒)分成一段一段的数据(Discretized Stream)，每一段数据都转换成Spark中的RDD(Resilient DistributedDataset)，然后将Spark Streaming中对DStream的Transformation操作变为针对Spark中对RDD的Transformation操作，将RDD经过操作变成中间结果保存在内存中。整个流式计算根据业务的需求可以对中间的结果进行缓存或者存储到外部设备。

1.2.3 为什么推荐Flink

image.png

1.3 Apache Flink开源生态

Flink社区的开源生态：

image.png

02 Flink整体架构

2.1 Flink分层结构

image.png

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

2.2 Flink整体架构

image.png

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

  1. JobManager (JM):负责整个任务的协调工作，包括:调度task、触发协调Task做 Checkpoint、协调容错恢复等;
  2. TaskManager (TM):负责执行一个 DataFlowGraph 的各个 task以及data streams 的 buffer 和数据交换。

2.2.1 JobManager职责

image.png

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

2.3 Flink如何做到流批一体

2.3.1 为什么需要流批一体

image.png

上述架构有一些痛点:

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

2.3.2 流批一体的挑战

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

image.png

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

image.png

2.3.3 Flink如何做到流批一体

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

A：批式计算是流式计算的特例，Everything is Streams，有界数据集(批式数据）也是一种数据流.一种特殊的数据流。因此，理论上我们是可以用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。

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;

2.3.4 流批一体的Scheduler层

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

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

image.png

2.3.5 流批一体的Shuffle Service层

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

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

image.png

  • 针对不同的分布式计算框架，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在策略上的定制，同时还能避免在共性需求上进行重复开发。

image.png

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

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

对于Shuffle Service，Flink开源社区已经支持:

  1. Netty Shufile Service:既支持pipeline 又支持blocking，Flink 默认的shuffle Service策略;
  2. Remote Shuffle Service:既支持pipeline又支持 blocking，不过对于pipeline模式，走 remote反而会性能下降，主要是有用在 batch的blocking场景，字节内部是基于CSS来实现的RSS。

2.3.6 流批一体总结

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

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

03 Flink架构优化

3.1 流/批/OLAP业务场景概述

在实际生产环境中，针对不同的应用场景，我们对数据处理的要求是不同的:

  1. 有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高，典型的应用是搜索引擎构建索引;
  2. 有些场景下，需对数据进行实时分析，要求每条数据处理延迟尽可能低，典型的应用是广告推荐、金融风控场景。

三种典型业务场景特点对比如下表：

image.png

解决方案的要求及带来的挑战是：

image.png

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

通过前面的对比分析，可以发现:

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

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

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

image.png

3.3 Flink的OLAP优化之路

3.3.1 Flink做OLAP的优势

image.png

3.3.2 Flink OLAP场景的挑战

image.png

3.3.3 Flink OLAP架构现状

  • client:提交SQL Query;
  • Gateway
    • 接收Client提交的SQL Query，对SQL进行语法解析和查询优化，生成 Flink 作业执行计划，提交给Session集群;
  • Session Cluster
    • 执行作业调度及计算，并返回结果。

image.png

3.3.4 Flink在OLAP架构的问题与设想

架构与功能模块:

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

作业管理及部署模块:

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

资源管理及计算任务调度:

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

其他:

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

3.3.5 总结

Apache Flink最终演进结果如下：

image.png 参考文章：

blog.csdn.net/q672746525/… nightlies.apache.org/flink/flink…

avatar
文章
阅读
粉丝