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

JHoves
134 阅读10分钟

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

一、Flink引擎概述

1.1 Apache Flink的诞生背景

1.1.1 什么是大数据？

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

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

① 史前阶段~2006

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

② Hadoop

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

③ Spark

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

④ Flink

  • 流计算
  • 实时、更快
  • 流批一体
  • Straming/Batch SQL

1.1.3 为什么需要流式计算

  • 大数据的实时性带来的价值更大
  • 大数据实时性的需要，也带来了大数据计算架构模式的变化

image.png

1.2 脱颖而出的Flink

1.2.1 流式计算框架对比

image.png

1.2.2 Flinkz支持的能力

image.png

1.2.3 Apache Flink开源生态

image.png

二、Flink整体架构

2.1 Flink分层架构

iage.png

  • SDK层：支持sql/table、用java的DataStream、python来编写业务逻辑
  • 执行引擎层(Runtime层)，执执行引擎层提供了统一的DAG,用来描述数据处理的Pipeline,不管是流还是批，都会转化为DAG图，调度层再把DAG转化成分布式环境下的Task,Task之间通过Shuffle传输数据；
  • 状态存储层：负责存储算子的状态信息
  • 资源调度层：目前Flink可以支持部署在多种环境

2.2 Flink总体架构

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

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

上图的流程是这样子的：

  • 1、首先client端先把代码的业务逻辑转化成一个DAG，然后发送到JM
  • 2、然后JM把这个DAG转化成一个真正能运行的物理计划，然后把task调度到TM的slot里去

JobManager 职责

image.png

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

2.3 Flink作业示例

流式的VordCount示例，从kafka中读取一个实时数据流，每1Os统计一次单词出现次数，DataStream实现代码如下：

image.png

作业示例：
1、业务逻辑转换为一个Streaming DataFlow Graph，下图Source的数据源，然后经过一些算子，最后Sink是输出 image.png 2、假设作业的sink算子的并发配置为1，其余算子并发为2 紧接着会将上面的Streaming DataFlow Graph转化Parallel Dataflow(内部叫Execution Graph): image.png 3、为了更高效地分布式执行，Flink会尽可能地将不同的operator链接(chain)在一起形成Task。 这样每个Task可以在一个线程中执行，内部叫做OperatorChain,如下图的source和map算子可以Chain在一起。 image.png 4、最后将上面的Task调度到具体的TaskManager中的slot中执行，一个Slot只能运行同一个task的subTask image.png 总结：整个调度流程就是client把代码转化成DAG发给JM，JM把DAG转换成执行计划，根据计划把Task发到TM里去执行。

2.4 Flink如何做到流批一体

2.4.1 为什么需要流批一体

举个例子：
1.在抖音中，实时统计一个短视频的播放量、点赞数也包括抖音直播间的实时观看人数等：
2.在抖音中，按天统计创造者的一些数据信息，比如昨天的播放量有务少、评论量多少、广告收入多少： image.png 上述架构有一些痛点：
1.人力成本比较高：批、流两套系统，相同逻辑需要开发两遍
2.数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费
3.数据口径不一致：两套系统、两套算子、两套UDF,通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。

2.4.2 流批一体的挑战

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

image.png

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

image.png

2.4.3 Flink 如何做到流批一体

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

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

image.png

站在Flink的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集(批式数据)也是一种数据流。 因此，不管是有边界的数据集（批式数据）还是无边界数据集，Fink都可以天然地支持，这是Flink支持流批一体的基础。并且FIik在流批一体上，从上面的API到底层的处理机制都是统一的，是真正意义上的流批一体。

总结：

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

2.4.4 流批一体的Scheduler层

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

image.png

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

image.png

  • EAGER模式：16给task会一起调度，集群需要有足够的资源

image.png

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

image.png

image.png

image.png

2.4.5 流批一体的Shuffle Service层

Shuffle:在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle。
实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为Shuffe。

image.png

针对不同的分布式计算框架，Shuffle通常有几种不同的实现：
1.基于文件的Pull Based Shuffle,比如Spak或MR,它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些；
2.基于Pipeline的Push Based Shuffle,比如Fink、Storm、Presto等，它的特点是低延迟和高性能，但是因为shuffle数据没有存储下来，如果是batch任务的话，就需要进行重跑恢复；

流和批Shuffle之间的差异：
1.Shuffle数据的生命周期：流作业的Shuffle数据与Task是绑定的，而批作业的Shuffle数据与Task是解耦的；
2.Shufle数据存储介质：流作业的生命周期比铰短、而且流作业为了实时性，Shuffle通常 存储在内存中，批作业因为数据量比较大以及容错的需求，一股会存储在磁盘里；
3.Shuffle的部署方式：流作业Shuffle服务和计算节点部署在一起，可以减少网络开销，从 而减少latency,而批作业则不同。

image.png

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

2.4.6 Fink 流批一体总结

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

image.png

三、Flink架构优化

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

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

举个例子：
1.在抖音中，实时统计一个短视领的播放量点赞数，也包括抖音直播间的实时观看人数等；
2.在抖音中，按天统计创造者的一些数据信息，比如昨天的播放量有条少评论量姿少、广告收入多少；
3.在抖音的一些推广活动中，运营同学需要对一些实时产出的结果数据做一些实时条维分析，来帮助后面活动的决策。

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

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,对QL进行语法解析和查询优化，生成Fink作业执行计划，提交给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

四、Flink 使用案例

  • 电商流批一体实践
  • Flink OLAP 场景实践
avatar
文章
阅读
粉丝