青训营-流/批/OLAP 一体的Flink引擎介绍

一、Flink概述

1.1 Apache Flink诞生背景：

1）什么是大数据：指无法在一定时间内用常规软件工具对其进行获取，存储，管理，处理的数据集合。

特点：价值化，海量化，快速化，多样化

发展：oracle-map reduce(Hadoop)-Spark-Flink

2）为什么需要flink：

监控场景，金融风控，实时推荐等

批式计算-流式计算（实时，低延迟，7*24h不间断进行）

1.2 为什么Flink会脱颖而出

1）流式计算引擎对比：

2）flink可以基于无边界有界数据集和无界数据集之上的有状态计算的分布式处理框架

核心：stream,dataful

特点：exactly-once 精确一次的计算语义

状态容错：checkpoint
  
  dataflow编程模型  window 等高阶需求支持友好
  
  流批一体
复制代码

1.3 Apache flink开源生态

二、flink整体架构

2.1 flink分层架构

1） SDK层: Flink 的SDK目前主要有三 类，SQL/Table、 DataStream、 Python;

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

3）状态存储层:负责存储算子的状态信息;

4）资源调度层:目前Flink可以支持部署在多种环境。

2.2 flink整体架构

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

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

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

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

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

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

2.3 flink 作业示例：

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

DataStream lines = env.addSource(

new FlinkKafkaConsumer<>(...));

DataStream events = lines.map((line)->parde(line));

DataStream stats = events

.keyBy(event -> event . id)

.timeWindow(Time.seconds(10))

.apply(new MyWindowAggregationFunction());

stats.addSink(new BucketingSink(path));

2.4 flink如何做到流批一体

1）流/批对比：

批式计算是流式计算的特例，Everything is Streams,有界数据集(批式数据)也是一种数据流，一种特殊的数据流;

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

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

因此，不管是有边界的数据集(批式数据)还是无边界数据集，Flink 都可以天然地支持，这是Flink支持流批一体的基础。并且Flink 在流批一体上，从上面的API到底层的处理机制都是统一的，是真正意义上的流批一体。

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

. SQL层;

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

. Scheduler 层架构统一，支持流批场景;

. Failover Recovery层架构统一,支持流批场景;

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

3）流批一体的scheduler层

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

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

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

6）流批一体的shuffle service层

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

7）针对不同的分布式计算框架，Shuffle 通常有几种不同的实现:

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

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

8）流和批Shuffle之间的差异:

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

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

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

9）在Streaming和OLAP场景：为了性能的需要，通常会使用基于Pipeline 的Shuffle模式

在Batch场景：一般会选取Blocking 的Shuffle模式

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

10）对于Shuffle Service, Flink 开源社区已经支持: . Netty Shuffle Service:既支持pipeline 又支持blocking, Flink 默认的shuffle Service策略;

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

三、flink架构优化

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

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

.有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高，典型的应用是 搜索引擎构建索引;

.有些场景下， 需对数据进行实时分析，要求每条数据处理延迟尽可能低，典型的应用是广告 推荐、金融风控场景。

2）三种业务场景特点的对比：

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

1）批式计算是流式计算的特例，而OLAP是批式计算的特例，它对并发和实时性要求更高，其他情况与普通批式作业无太大差别

3.3 flink如何支持OLAP场景

1）优势：

引擎统一——降低学习成本，提高开发、维护效率

既有优势——内存计算，Code-gen，pipeline shuffle,session模式的MPP架构

生态支持——跨数据源查询支持，TCP-DS基准测试性能强

2）挑战：

.秒级和毫秒级的小作业

.Latency+ QPS的要求

.作业频繁启停，资源碎片

3)flink OLAP架构现状：

.Client:提交SQL Query;

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

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

4）架构与功能模块:

. JobManager 与ResourceManager在个进程内启动，无法对JobManager 进行水平扩展;

. Gateway 与Flink Session Cluster互相独立，无法进行统一管理。

5）作业管理及部署模块:

. JobManager 处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存;

. TaskManager 部署计算任务时，任务初始化部分耗时严重，消耗大量CPU.

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

.资源申请及资源释放流程链路过长

. Slot 作为资源管理单元，JM管理slot资源，导致JM无法感知到TM维度的资源分布，使得资源管理完全依赖于ResourceManager

7）其他:

.作业心跳与Failover机制，并不合适AP这种秒级或毫秒级计算场景;

. AP目前使用Batch算子进行计算，这些算子初始化比较耗时;

8）总结：

四、flink使用案例：

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

2.Flink OLAP 场景实践