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

JESSY
169 阅读13分钟

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

01 Flink概述

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

1.1 Apache Flink 的诞生背景

什么是大数据

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

大数据特征：海量化、价值化、快速化、多样化

大数据计算架构发展历史

史前阶段 ~ 2006：传统数仓、Oracle、单机、黑箱使用

Hadoop：分布式、Map-Reduce、离线计算

Spark：批处理、流处理、SQL高阶、API、内存迭代计算

Flink：流计算、实时、更快、流批―体、Streaming/Batch SQL

为什么需要流式计算

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

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

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

批式计算

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

大数据实时性的需求升级为：

流式计算

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

1.2 为什么Apache Flink会脱颖而出

流式计算引擎发展历程

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

image.png

流式计算引擎对比

流式计算框架对比：

image.png

Why Flink

Apache Flink is a framework and distributed processing engine for stateful computations over unboundedand 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社区官方介绍

image.png

1.3.Apache Flink开源生态

image.png

02 Flink 整体架构

Flink当前的整体架构介绍，一个Flink作业如何调度和运行起来，Flink如何做到流批一体

2.1.Flink分层架构

  • Flink各个模块的用途

image.png

2.2.Flink总体架构

Master/Slave架构、JobManager/TaskManager

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

  1. JobManager（JM）：负责整个任务的协调工作， 包括：调度task、触发协调Task做Checkpoint、 协调容错恢复等；

  2. TaskManager（TM)：负责执行一个DataFlow Graph 的各个 task 以及 data streams 的 buffer 和 数据交换。

image.png

Flink 整体架构-JobManager职责

image.png

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

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

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

2.3.Flink作业示例

一个Flink作业在Flink中的处理流程、DataFlow Model设计思想 流式的WordCount示例，从kafka中读取一个实时数据流，每10s统计一次单词出现次数，DataStream实现代码如下：

image.png

业务逻辑转换为一个 Streaming DataFlow Graph image.png

假设作业的sink算子的并发配置为1，其余算子并发为2 紧接着会将上面的Streaming DataFlow Graph 转化Parallel Dataflow(内部叫Execution Graph): image.png

为了更高效地分布式执行，Flink会尽可能地将不同的operator 链接（chain)在一起形成Task。 这样每个Task可以在一个线程中执行，内部叫做OperatorChain,如下图的source和map算子可以Chain在一起。

image.png

最后将上面的Task调度到具体的TaskManager中的slot中执行，一个Slot只能运行同一个task的subTask

image.png

2.4.Flink如何做到流批一体

流批一体的业务场景及挑战、Flink如何做到流批一体

为什么需要流批一体

举个例子：

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

image.png

上述架构有一些痛点：

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

会给业务方带来非常大的困扰。

流批一体的挑战

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

image.png

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

image.png

Flink如何做到流批一体

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

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

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

image.png

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

因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink都可以天然地支持，这是Flink支持流批一体的基础。并且FIlink在流批一体上，从上面的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

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

image.png

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

image.png

  • 由Pipeline的数据交换方式连接的Task 构成为一个Pipeline Region;
  • 本质上，不管是流作业还是批作业，都是按照Pipeline Region 粒度来申请资源和调度任务。

image.png

  • ALL_EDGES_BLOCKING:
    • 所有Task之间的数据交换都是BLOCKING模式；
    • 分为12个 pipeline region;
  • ALL EDGES PIPELINED:
    • 所有Task之间的数据交换都是PIPELINE模式；
    • 分为1个pipeline region;

image.png

流批一体的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在策略上的定制，同时还能避免在共性需求上进行重复开发。

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

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

image.png

对于Shuffle Service,Flink开源社区已经支持：

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

image.png

Flink流批一体总结

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

03 Flink架构优化

流/批/OLAP业务场景概述

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

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

举个例子：

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

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

image.png

三种业务场景的解决方案的要求及带来的挑战是： image.png

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

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

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

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

image.png

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

image.png

Flink 如何支持 OLAP场景

Flink 做OLAP 的优势

image.png

Flink OLAP 场景的挑战

image.png

Flink OLAP 架构现状

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

image.png

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算子进行计算，这些算子初始化比较耗时；

image.png

总结

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

image.png

04 精选案例讲解

选择两个字节内部真实的案例场景，介绍Flink在流批一体以及 OLAP 上的实践

电商流批一体实践

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

image.png

Flink社区的现状

image.png

目前电商业务数据分为离线数仓和实时数仓建设，离线和实时数据源，计算引擎和业务代码没有统一，在开发相同需求的时候经常需要离线和实时对齐口径，同时，由于需要维护两套计算路径，对运维也带来压力。

从数据源，业务逻辑，计算引擎完成统一，提高开发和运维效率。

演进目标

image.png

Flink OLAP场景实践

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

image.png

image.png

字节内部一个业务实践：

  • 上面是原来的链路；
  • 下面是走HTAP之后的链路，Flink直接提供数据查询与分析的能力。

课程总结

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