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

张鱼哥z
69 阅读9分钟

  这是我参与「第四届青训营」笔记创作活动的的第2天，以下是我的课堂笔记。
本次课程主要分为四个大板块：
1. Flink概述
2. Flink整体架构
3. Flink架构优化
4. 精选案例讲解

1. Flink概述

--为什么会有流式计算的需求，为什么Flink能够脱颖而出，Flink当前的开源生态

1.1.1 什么是大数据

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

1.1.2 为什么需要流式计算

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

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

graph TD
批式计算--> 流式计算

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

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

1.2 流式计算引擎对比

流式计算框架对比：

image.png

1.3 Apache Flink开源生态

Flink社区的开源生态：

image.png

2. Flink整体架构

2.1 Flink分层架构

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

Flink分层架构图：
image.png

2.2 Flink整体架构

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

2.3 Flink整体架构-JobManager职责

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

image.png

2.4.1 为什么需要流批一体

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

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

2.4.2 流批一体的挑战

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

image.png

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

image.png

2.4.2 Flink如何做到流批一体

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

2.4.3 Flink如何做到流批一体

Apache Flink主要从以下几个模块来做流批一体:
1.SQL层;
2. DataStream API层统一，批和流都可以使用 DataStream API来开发;3. Scheduler层架构统一，支持流批场景;
4. Failover Recovery层架构统一，支持流批场景;
5. Shuffle Service层架构统一，流批场景选择不同的 Shuffle Service;
（在这每一个模块，flink都做了大量的优化，让他们既支持流，有支持批）

2.4.4 流批一体的Scheduler层

Scheduler主要负责将作业的DAG转化为在分布式环境中可以执行的Task
在1.12之前的 Flink版本中，Flink支持以下两种调度模式:

image.png ·EAGER模式
12个task 会一起调度，集群需要有足够的资源

image.png

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

image.png

· 由Pipeline的数据交换方式连接的Task构成为一个 Pipeline Region;
· 本质上，不管是流作业还是批作业，都是按照 Pipeline Region粒度来申请资源和调度任务。
· ALL_EDGES_BLOCKING:
  · 所有Task之间的数据交换都是BLOCKING模式;
  · 分为12个pipeline region ;
· ALL_EDGES_PIPELINED:
  ·所有Task之间的数据交换都是 PIPELINE模式;
  ·分为1个pipeline region;

image.png

2.4.5 流批一体的Shuffle Service层

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

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

Flink对于流和批提供两种类型的Shufle，虽然Streaming和Batch Shufile在具体的策略上存在一定的
所以Flink的目标是提供一套统一的Shufle架构，既可以满足不同Shuffle在策略上的定制，同时还能避免在共性需求上进行重复开发。

3. Flink架构优化

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

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

image.png

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

image.png

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

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

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

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

image.png

3.3Flink的OLAP的优化之路

Flink的OLAP的优势：

image.png Flink的OLAP场景的挑战：

image.png

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

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

4. 精选案例讲解

4.1.电商流批一体实践

抖音电商业务原有的离线和实时数仓架构如下图:

image.png Flink 社区的现状:

image.png 目前电商业务数据分为离线数仓和实时数仓建设，离线和实时数据源，计算引擎和业务代码没有统一，在开发相同需求的时候经常需要离线和实时对齐口径，同时，由于需要维护两套计算路径，对运维也带来压力。
从数据源，业务逻辑，计算引擎完成统一，提高开发和运维效率。
演进目标：

image.png

4.2 字节Flink OLAP 实践

Flink的OLAP在字节内部的场景主要是HTAP场景。

image.png

image.png

字节内部一个业务实践:
。上面是原来的链路;
。下面是走HTAP之后的链路，Flink直接提供数据查询与分析的能力。

5. 课程总结

  1. Flink概述
    （1）流式计算场景及流式计算框架发展历程
    （2）业内主要流式计算框架对比、为什么Flink 能够脱颖而出;
  2. Flink 整体架构
    （1）Flink的分层加构、Flink当前的整体架构介绍;
    （2）一个Flink作业如何调度和运行起来;
    （3） Flink如何做到流批一体;
  3. Flink架构优化
    （1）流/批/OLAP三种业务场景概述;
    （2）Flink如何来支持OLAP场景需求，需要做哪些架构上的优化;
    4．精选案例讲解
avatar
文章
阅读
粉丝