这是我参与「第四届青训营 」笔记创作活动的第1天
流/批/OLAP一体的Flink引擎
1.Flink概述 1.1 Apache Flink诞生的背景 大数据是指在一定时间内无法用常规软件和工具进行获取、存储、管理和处理的数据集合 海量化、多样化、快速化、价值化
Hadoop 解决方案：分布式、Map-Reduce、离线计算 Spark解决方案：批处理、流处理、SQL高级API、内存迭代处理 Flink：流计算、实时、快
大数据的实时性带来的价值更大 随着大数据的发展，大数据计算结构模式改变 批示计算->流式计算 批示计算是等待一批数据到期才进行计算 有周期的离线计算 流失计算理解为水龙头 从源头的数据在水龙头的部分被源源不断的处理 是持续动态的快速计算
1.2 Apache Flink的优势 具有状态容错 精确语义 流批一体：支持流式计算和批式计算； OLAP：Flink 可以支持 OLAP 这种短查询场景； Flink ML：pyFlink、ALink、AIFlow 等生态支持 Flink 在 ML 场景的应用； Gelly：图计算； Stateful Function：支持有状态的 FAAS 场景；
1.3 开源生态
总结：大数据的需求 Fink why 当前生态
- Flink整体架构
2.1 Flink分层架构 SDK层：主要是当前提供的API 执行引擎层：转化成统一的DAG API 之后进入调度的图 Shuffle Service进行数据交换 状态存储层：负责存储算子的状态信息
总体架构： 包含两个组件 JobManager(JM):负责整个任务的协调工作 TackManager(TM)：负责一个DataFlow Graph的各个task以及data streams的数据交换
代码->逻辑执行图->物理执行图->调度到不同的节点执行 JM包含： Dispatcher: 接收作业，拉起 JobManager 来执行作业，并在 JobMaster 挂掉之后恢复作业； JobMaster: 管理一个 job 的整个生命周期，会向 ResourceManager 申请 slot，并将 task 调度到对应 TM 上； ResourceManager：负责 slot 资源的管理和调度，Task manager 拉起之后会向 RM 注册；
2.3 Flink作业示例 source->map()->keyBy()/window()/aooly()->Sink operator chain:可以把Source map()放在一起 放到一个线程中 当做一个算子来处理 来减少交换 之后到具体TM中slot中执行，只能运行同一个task的subTask
2.4 Flink如何做到流批一体 数据源可能产生实时数据、也可能产生离线数据 分别处理产生两天线路冗余、人力成本高、可能产生一些误差，比较难解释 批示计算是流式计算的特立，所以可以流批一体 允许不同场景使用不同的Shuffle Service 进行计算 从几个模块实现流批一体： SQL 层； DataStream API 层统一，批和流都可以使用 DataStream API 来开发； Scheduler 层架构统一，支持流批场景； Failover Recovery 层 架构统一，支持流批场景； Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service；
之前的模型： Lazy（Batch 场景）：先调度上游，等待上游产生数据或结束后再调度下游，类似 Spark 的 Stage 执行模式。 Eager（Streaming 场景）：申请一个作业所需要的全部资源，然后同时调度这个作业的全部 Task，所有的 Task 之间采取 Pipeline 的方式进行通信；
现在的模型： 全都抽象为pipeline region，lazy分为多个pipeline region
shuffle：用于连接上下游数据交互
Nerry Shuffle Service Remote Shuffle Service:popeline模式下性能会下降
- Flink架构优化
根据不同应用场景采用不同策略 交互式分析(OLAP):需要高速的处理 是一种批示计算的特立：对实时性要求高
Flink做OLAP的优势：引擎统一、生态支持、原有的优势（内存计算等） 需要毫秒级的计算、作业频繁启停、资源碎片
框架现状：
