这是我参与「第四届青训营 」笔记创作活动的第2天！
一、Flink概述。
1.1.Apache Flink的诞生背景
1.什么是大数据？
- 大数据（Big Data）：指无法在一定时间内用常规软件工具对具体进行获取、存储、管理和处理的数据的集合。
- 大数据有价值化、海量化、快速化、多样化的特点。
2.大数据计算架构发展历史：
| 史前阶段~2006 | Hadoop |
|---|
| Spark | Flink |
|---|
3.为什么需要流式计算：
- 大数据实时性的需求，带来了大数据计算架构模式的变化：流式计算更适应于现如今的需求。
- 批式计算：
- 离线计算，非实时
- 静态数据集
- 小时/天等周期性计算
- 流式计算：
- 实时计算，快速，低延迟
- 无限流，动态、无边界
- 7*24h持续运行
- 流批一体
1.2.为什么Apache Flink会脱颖而出？
1.流式计算引擎发展历程：
2.流式计算引擎对比：
3.Why Flink
- Flink的优点：
- 精确一次的计算语义（Exactly-Once）
- 状态容错（Checkpoint）
- Window等高阶需求支持友好（Dataflow编程模型）
- 流批一体
3.Apache Flink开源生态
二、Flink整体架构
1.Flink分层架构：
- SDK层：分三类：SQL/Table、DataStream、Python;
- 执行引擎层(Runtime层)：执行引擎层提供了统一的DAG,用来描述数据处理的Pipeline,不管是流还是批，都会转化为DAG图，调度层再把DAG转换成分布式环境下的Task，Task之间通过Shuffle传输数据
- 状态存储层：负责存储算子的状态信息
- 资源调度层：目前Flink可以支持部署在多种环境
2.Flink整体架构：
一个Flink集群，主要包含一下两个核心组件：
- JobManager(JM)：负责整个任务的协调工作，包括：调度task、触发协调Task做Checkpoint、协调容错恢复等
- TaskManager(TM)：负责执行一个DataFlowGraph的各个task以及data streams的buffer和数据交换
JobManager的作用：
- Dispatcher：接收作业，拉起 JobManager 来执行作业，并在 JobMaster 挂掉之后恢复作业
- JobMaster：管理一个job的整个生命周期，会向 ResourceManager 申请slot，并将task调度到对应TM上
- ResourceManager：负责slot资源的管理和调度，Task manager 拉起之后会向RM注册
3.Flink如何做到流批一体：
①为什么需要流批一体？
例如在抖音中我们可以实时监控一个视频的点赞、播放或者直播间的实时观看人数等，同时我们还需要按天统计创造者的收入、视频点赞与播放量。
上述架构有一些痛点：
- 人力成本较高：批、流两套系统，相同逻辑需开发两遍
- 数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两边，产生一定的资源浪费
- 数据口径不一致：两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰
2.流批一体的挑战：
流批业务场景特点如下表：
批式计算相比于流式计算核心的区别如下表：
3.Flink如何做到流批一体
为什么可以做到流批一体？
- 批式计算是流式计算的特例，Everythine is Streams，有界数据集(批式数据)也是一种数据流、一种特殊的数据流
因此，理论上我们可用一套引擎架构来解决上述两种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。
Apache Flink主要从以下几个模块来做流批一体：
- SQL层
- DataStream API层统一，批和流都可以使用DataStream API来开发
- Scheduler层架构同意，支持流批场景
- Failover Recovery层架构统一，支持流批场景
- 5Shuffe Service层架构统一，流批场景选择不同的Shuffe Service
流批一体的Scheduler层
Scheduler主要负责将作业的DAG转化为在分布式环境中可执行的Task
流批一体的Shuffle Service层
①Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle
实际上，分布式计算中所有涉及到上下游衔接的过程，都可以理解为Shuffle
②针对不同的分布式计算框架，Shuffle通常有几种不同的实现：
- 基于文件的Pull Based Shuffle，比如Spark或MR，它的特点是有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些
- 基于Pipeline的Push Based Shuffle，比如Flink、Storm、Presto等，它的特点是低延迟和高性能，但是因为Shuffle数据没有存储下来，如果是batch任务的话，就需要进行重跑恢复
③流和批Shuffle之间的差异：
- Shuffle数据的生命周期：流作业的Shuffle数据与Task是绑定的，而批作业的Shuffle数据与Task是解耦的
- Shuffle数据存储介质：流作业得到生命周期比较短，而且流作业为了实时性，Shuffle通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里
- 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框架，抽象出一些公共模块。
三、Flink结构优化。
1.流/批/OLAP业务场景概述
- 针对实际生产环境中的需求不同我们要采取合适的相应的数据处理方式。
三种业务场景的特点比对：
三种业务场景的解决方案的要求以及带来的挑战：
2.为什么三种业务场景可以用一套引擎来解决：
通过前述对比分析，可以发现：
- 批式计算是流式计算的特例， Everything is Streams ，有界数据集（批式数据）也是一种数据流、一种特殊的数据流
- 而 OLAP 计算是一种特殊的批式计算，它对并发性和实时性要求更高，其他情况与普通批式作业没有特别大区别
因此，理论上我们是可以用一套引擎架构来解决上述三种场景，只不过需要对不同场景支持相应的扩展性、并运行做不同的优化策略。
3.Flink如何支持OLAP的优化之路：
Apache Flink 从流式计算出发，想要支持 Batch 和 OLAP 场景，就需要解决下面的问题：
- Batch 场景需求
- 流批一体支持；
- Unify DataStream API；
- Scheduler；
- Shuffle Service；
- Failover Recovery。
- OLAP 场景需求
- 短查询作业场景
- 高并发支持；
- 极致处理性能。
Flink做OLAP的优势：
- 引擎统一
- 既有优势
- 生态支持
Flink OLAP 场景的挑战：
- 秒级和毫秒级的小作业
- 作业频繁启停，资源碎片
- Latency + QPS的要求
总结：
经过这次课的学习，我对Flink有了非常深刻的认识，以及怎样做到流批一体化，流批一体的应用场景，在合适的场景去使用合适的数据处理方式能够大大的增加效率。
