大数据学习-Flink引擎 | 青训营笔记

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

昨天学习了Flink引擎，讲了大数据的背景，Flink的分层架构、Flink的总体架构和一个类似于Helloworld的wordcount程序，今天继续学习Flink引擎。

Flink如何做到流批一体

这部分内容比较多，会从为什么需要流批一体、流批一体的挑战、Flink如何做到流批一体、流批一体的Scheduler层、流批一体的Shunffle Service层等方面来讲解。

上述流和批的具体实现：

上述架构有一些痛点：

所以为了减少成本，也为了减少误差，就需要流批一体的引擎来处理

流和批业务场景的特点：

流和批的计算核心也不同

流式计算的数据流是无限数据集，是低延迟、业务会感知运行中的情况，比如直播等。

而批式计算的数据流式有限数据集，实时性要求不高，只关注最终结果产出时间等

Flink中有一个抽象，认为Everything is stream,即批式计算是流式计算的特列，有界的数据集是一种特殊的数据流，不管哪种数据的集合，都是流，所以理论上我们是可以用一套引擎架构来解决上述的两种场景的。

而Apache Flink给以下模块都做了大量的优化，来让其既支持流又支持批： 1.SQL层：支持bound和unbound数据集的处理

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

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

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

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

Scheduler主要负责将作业的DAG转化为在分布式环境中可以执行的Task，在1.12之前的版本，Flink就支持EAGER和LAZY两种模式的调换，

但流的场景就需要一直计算，而新版本的Flink就用一个新的概念Pipeline Region来处理，

Pipeline Region就是由Pipeline的数据交换方式连接的Task构成，不管是流还是批都根据Pipeline Region粒度来调度。

在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle，而一般情况下，分布式计算中所有涉及到上下游衔接的过程，都可以理解为Shuffle。
针对不同的分布式计算框架，Shuffle通常有几种不同的实现：

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

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

在日常的生活中，针对不容的场景，往往我们对数据处理的要求是不同的，比如，在抖音的一些推广活动中，运营需要对一些实时产出的结果数据做一些实时多维分析，来帮助后面活动的决策，这时我们就需要OLAP（交互式分析）了

OLAP的典型差异是高并发查询，查询返回时间有很高的要求，需要高性能支持