# 这是我参与「第四届青训营 」笔记创作活动的的第2天：
一、大数据计算架构发展历史： 史前阶段（传统数仓，Oracle，单机，黑箱使用）->Hadoop（分布式，Map-Reduce,离线计算）->Spark（批处理，流处理,SQL高阶API，内存迭代计算）->Flink（流计算，实时、更快、流批一体、Streaming/Batch SQL）
大数据的实时性带来的价值更大。
批示计算：离线计算，非实时；静态数据集；小时/天等周期性计算。 流式计算：实时计算，快速，低延迟；无限流，动态，无边界；7*24h持续运行；流批一体。
Flink：一个框架，一个分布式处理的引擎，可以基于无界处理集有界处理集，既可以处理流数据也可以处理批数据。Exactly-Once（精确一次的计算语义）；状态容错（Checkpoint），Dataflow编译模型（Window等高阶需求支持友好）；流批一体。
Flink：一个计算框架本身没有存储的能力，但能跟一些数据存储的引擎做一些继承。
二、Flink整体架构
1.分层
（1）SDK目前主要有三层：SQL/Table，DataSTream，Python
（2）行引擎层：执行引擎层提供了同意的DAG，用描述数据处理的Pipeline，不管是流还是批，都会转化成DAG图，调度曾DAG转化成分布式环境下的Task。
（3）状态存储层：负责存储算子的状态信息。
（4）资源调度层：目前Flink可以支持部署在多种环境。
2.总体架构
一个Flink集群，主要包含：
（1）JobManager（JM）负责整个任务的调度工作，包括：调度task、出发协调Task做Checkpoint、协调容错恢复等；
（2）TaskManager(TM)
3.作业示例
为了更高效的分布式执行，FLINK会尽可能的将不同的operator链接在一起形成Task。
4.如何做到流批一体
为何需要流批一体：
例如：实时统计一个短视频的点赞量。
不用流批一体的痛点：（1）人力成本较高：批、流两套系统，相同逻辑需要开发两遍（2）数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两边，传声一定的资源浪费（3）数据口径不一致：两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务放带来非常大的困扰。
流批一体的挑战：
流式计算：实时计算，延迟在秒级以内，01s，广告推荐、金融风控，无限数据集，低延迟、业务会感知运行中的情况。
批示计算：离线计算。处理时间为分钟到小时级别，甚至天级别，10S1h+,搜索引擎构建索引、批示数据分析；有限数据；实时性要求不高，只关注最终结果产出时间。
Flink如何做到流批一体：
批示数据是一种特殊的流式计算，Flink既能做流的调度也能做批的调度，允许不同场景使用不同的JAVA Service计算。
站在Flink的角度，无边界数据集是一种数据流，一个无边界的数据流可以按照时间的切段成一个个有边界的数据集，所以有界数据集（批示数据）也是一种数据流。
因此，不管是有边界的数据集（批示数据）还是无边界数据集，Flink都可以天然的支持，这是Flin支持流批一体的基础。并且Flink在流批一体上，从上面的API到底层的处理机制都是统一的，是真正意义上的流批一体。
Flink主要从以下几个模块来做流批一体：
（1）SQL层
（2）DataStream API层统一，批和流都可以使用DataStream API来开发；
（3）Scheduler 层架构统一，支持流批场景。
（4）Failover Recovery 层架构统一，支持流批场景；
（5）Shuffle Service 层架构统一，流批场景许安则不同的Shuffle Service。
流批一体的Scheduler层：
主要讲DAG转换成在分布式环境中可以执行的Task.
Flink支持两种模式的调度：EAGER,LAZY。
流批一体的Shuffle Service层：
Shuffle:在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle。实际上分布式计算中所有涉及到上下游衔接的过程都可以理解为Shuffle。
流和批Shuffle之间的差异：
1.Shuffle数据的生命周期，2.Shuffle数据存储介质，3.Shuffle的部署方式。
三、Flink架构优化 在实际生产环境中，针对不同的应用场景，我们对数据处理的要求是不同的。 交互式分析：OLAP。要求高并发查询。 批示计算是流式计算的一种特例，OLAP计算是一种特殊的批示计算。因此，理论上，我们是可以用一套引擎架构来解决上述三种场景，只不过需要对不同场景支持响应的扩展性、并允许做不同的优化策略。 Flink做OLAP的优势：引擎统一、既有优势、生态支持。
