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

用户3618319768332
72 阅读6分钟

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

Flink

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

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

主流的流式计算框架：

image.png

Streaming Model： 计算模式

  1. mini-batch： 微批处理

一致性保证

  1. At Least： 保证数据能处理一次，但有可能多处理

  2. Most Once： 数据最多处理一次，不会重发，有可能有数据没处理到

  3. Exactly-Once： 精确一次的计算语义

Flink的特点

image.png

Flink框架模型介绍

image.png

1. Flink整体框架

1.1 Flink分层架构

image.png

1.SDK层：Flink的SDK目前主要有三类，SQL/Table、DataStream、Python

2.执行引擎层(Runtime层)：执行引擎层提供了统一的DAG 用来描述数据处理的Pipeline,不管是流还是批，都会转化为 DAG图，调度层再把DAG转化成分布式环境下的Task, Task之间通过Shuffle传输数据；

3.状态存储层：负责存储算子的状态信息

4.资源调度层：目前Flik可以支持部署在多种环境

流程： DAG层将SDK层的描述统一转化为逻辑图DAG图的表达方式，

1.2 Flink总体架构

image.png

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

l.JobManager（Jm）:负责整个任务的协调工口 包括：调度task、触发协调Task做Checkpoint 协调容错恢复等

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

1.2.1 JobManager职责

image.png

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

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

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

Flink 实例

image.png

代码图解

image.png

image.png

1.3 Flink的流批一体

一般的流、批处理流程 image.png

上述架构有一些痛点：

1.人力成本比较高：批、流两套系统，相同逻辑需要开发两遍；

2.数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生 定的资源浪费；

3.数据口径不致：两套系统、两套算子、两套UDF,通常会产生不同程度的误差，这些误差 会给业务方带来非常大的困扰。

Apache Flink主要从以下几个模块来做流批一体：

1.SQL层;

2.DataStream API层统一，批和流都可以使用DataStream API来开发；

3.Scheduler层(调度层)架构统一，支持流批场景；

4.Failover Recovery(容错层)层架构统一，支持流批场景；

5.Shuffle Service层架构统一，流批场景选择不同的Shuffle Service;

1.3.1 流批一体的Scheduler层（调度层）

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

image.png

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

image.png

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

最新的调度模式：Pipeline Regin 需要的资源和性能处于 LAZY和EAGER之间

image.png

image.png

ALL EDGES BLOCKING:

所有Task之间的数据交换都是BLOCKING模式(A1产生的数据不会马上传给B1，需要进行落盘，写到磁盘里，不是实时传输)；

分为12个pipeline region

ALL EDGES PIPELINED:

所有Task之间的数据交换都是PIPELINE模式（A1产生的数据直接发生给B1）：

分为1个pipeline region;

1.3.2 Shuffle Service层

Shuffle:在分布式计算中，用来连接上下游数据交互 的过程叫做Shuffle。 eg：keyby操作到window操作之间的数据分发就是shuffle

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

针对不同的分布式计算框架，Sue通常有几种不同的实现：

1.基于文性的Pull Based Shuffle,比如Spak或MR,它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些，

2.基于Pipeline的Push Based Shuffle,比如Flink、Storm、Presto等，它的特点是低延迟和高性能，但是因为shuffle数据没有存储下来，如果是batch任务的话，就需要进行重跑恢复；

流和批Shuffle之间的差异

  1. Shuffle数据的生命周期流作业的Shuffle数据与Task是绑定的，而批作业的Shuffle数 据与Task是解耦的；

2.Shuffle数据存储介质：流作业的生命周期比较短、而且流作业为了实时性，Shuffle通常 存储在内存中，批作业因为数据量比较大以及容错的需求般会存储在磁盘里；

Shuffle的部署方式：流作业Shuffle服务和计算节点部署在一起，可以减少网络开销，从 而减少latency,而批作业则不同。

Flink的Shuffle

  1. 在Streaming和OLAP场景

为了性能的需要，通常会使用基于Pipeline的Shuffle模式

  1. 在Batch场最 一般会选取Blocking的Shuffle模式

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

image.png

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

1.Netty Shuffle Service:既支持pipeline又支持blocking,Flink默认的shuffle Service策略：

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

2.Flink框架优化

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

image.png

OLAP计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况和普通的批式作业没有特殊的大区别

image.png

Flink从流式计算出发，要支持Batch和OLAP场景，要解决下面问题

image.png

2.2 Flink对于OLAP优化

2.2.1 OLAP架构现状

image.png

Client: 提交SQL Query

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

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

小结

image.png

电商流批一体实践

image.png

总结

一.Flink概述

1.流式计算场景及流式计算框架发展历程

2.业内主要流式计算框架对比、为什么FIik能够脱颖而出；

二.Flink整体架构

1.Flink的分层架构、Flink当前的整体架构介绍；

2.一个Flink作业如何调度和运行起来；

3.Fink如何做到流批一体；

三.Flink架构优化

1.流批/OLAP三种业务场景概述

2.FIik如何来支持OLAP场景需求，需要做哪些架构上的优化

avatar
文章
阅读
粉丝