1.Flink概述

1.1为什么需要流式计算

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

1、监控场景：实时发现业务系统的健康状态，提前避免业务障碍

2、金融风控：实时监测出异常交易行为，及时阻断风险产生

3、实时推荐：应用根据用户的行为数据发掘用户的兴趣、偏好，向用户推荐更感兴趣的内容 ...

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

批式计算(以前)： 离线计算(非实时)， 静态数据集， 小时/天等周期性计算

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

1.2为什么Apache Flink会脱颖而出

(1)流式计算引擎发展历程 如果从Google对外发布MapReduce论文算起，已经前后跨越将近二十年，业内常用的计算框架演化历史 (红框是流式计算框架)

（2）流式计算引擎对比

(3)Flink官方介绍

Apache Flink是一个可以基于无界和有界数据集之上有状态计算的框架和分布式处理引擎

关于Flink：Exactly-Once(精确一次的计算语义)、状态容错(Checkpoint)、Dataflow(Window等高阶需求支持友好)、流批一体

1.3Flink开源生态

2.Flink整体架构

2.1Flink分层架构

1、SDK层：分三类：SQL/Table、DataStream、Python;

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

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

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

2.2、Flink总体架构

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

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

2、TaskManager(TM)：负责执行一个DataFlowGraph的各个task以及data streams的buffer和数据交换

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

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

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

2.3Flink作业示例

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

DataStream<String> lines = env.addSource(new FlinkKafkaConsumer<>(...));  //Source
DataStream<Event> events = lines.map((line) -> parse(line));   //transformation
DataStream<Statistices> stats = events
        .keyBy(event -> event.id)
        .timeWindow(Time.second(10))
        .apply(new MyWindowAggregationFunction());             //Transformation
stats.addSink(new BucketingSink(path));                        //Sink

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

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

为了更高效地分布式执行，Flink会尽可能地将不同的operator链接(chain)在一起形成Task。

这样每个Task可以在一个线程中执行，内部叫做OperatorChain，如下图地source和map算子可以Chain在一起

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

2.4Flink如何做到流批一体

(1)为什么需要流批一体

例如抖音实时统计短视频播放量、点赞数、直播实时人数等

上述架构有一些痛点： 1、人力成本较高：批、流两套系统，相同逻辑需开发两遍

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

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

(2)流批一体的挑战

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

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

(3)Flink如何做到流批一体

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

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

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

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

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

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

1、SQL层

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

3、Scheduler层架构同意，支持流批场景

4、Failover Recovery层架构统一，支持流批场景

5、Shuffe Service层架构统一，流批场景选择不同的Shuffe Service

(4)流批一体的Scheduler层

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

(5)流批一体的Shuffle Service层

Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle

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

针对不同的分布式计算框架，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框架，抽象出一些公共模块

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

1、Netty Shuffle Service：既支持pipeline又支持blocking，Flink默认的Shuffle Service策略;

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

Flink流批一体总结：

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

3.fLINK架构优化

• OLAP高并发查询时保持低延迟、高实时
• OLAP可视为特殊的批式计算
• 高并发支持，极致的处理性能

Flink的OLAP的优化之路

• Flink中OLAP的调整 作业频繁启停，资源碎片化等等

• Flink OLAP架构： client：提交SQL Query Gateway：接收Client的提交的SQL Query，对SQL进行解析，查询优化，生成Flink作业执行计划，提交给Session集群 Session Cluster：执行作业调度及计算，并返回结果