这是我参与「第四届青训营 」笔记创作活动的第6天，学习内容为：流/批/OLAP一体的Flink引擎。
今天的笔记内容主要分为以下几个方面：
- FlinK概述
- Flink整体架构
- Flink架构优化
- 精选案例讲述
-1.Flink概述
Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。
流式计算的优点
- 实时计算，快速，低延迟，低频率
- 无限流、动态、无边界
- 随时在持续运行，不间断7*24持续运行
Flink开源生态
Flink分层架构
- 2.Flink整体框架
1.JobManager(JM)；负责整个任务的协调工作，包括调度task、触发协调Task做Checkpoint、协调容错恢复。
2.TaskManager(TM):负责执行一个DataFlow Graph的各个task以及data streams 的buffer和数据交换。
- 3.Flink架构优化
Flink如何做到流批一体
Apache Flink主要从以下几个模块来做流批一体
- 1.SQL层
- 2.DataStream API层统一，批，流都可以用DataStream API来开发
- 3.Scheduler层架构通一，支持流批场景
- 4.Failover Recovery层架构统一，支持流批场景
- 5.Shuffle Service层架构统一，流批场景选择不同的Shuffle Service
Scheduler层
主要负责将作业中的DAG转化为在分布状态中可执行的task
Shuffle Service层
Shuffle：在分布式计算中，用来连接上下游数据交互的过程叫做Shuffle。
实际上，分布式计算所有涉及到上下游衔接的过程，都可以理解为Shuffle。 针对不同的分布式计算框架，Shuffle通常有几种不同的实现：
- 1.基于文件的Pull Based Shuffle，比如 Spark或MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些；
- 2.基于Pipeline的Push Based Shuffle，比如 Flink、Storm、Presto等，它的特点是低延迟和高性能，但是因为shuffle数据没有存储下来，如果是batch任务的话，就需要进行重跑恢复；
流/批/OLAP业务场景概述
| 模块 | 流式计算 | 批式计算 | OLAP |
|---|---|---|---|
| SQL | Yes | Yes | Yes |
| 实效性 | 高，处理毫秒级别延迟 | 低 | 高、查询延退在秒级但要求高并发查询 |
| 容错能力 | 高 | 中 | No，失败重试即可 |
| 状态 | Yes | NO | No |
| 准确性 | Exactly Once，要求高，重跑之前需要恢复之前的状态 | Exactly Once，失败重试即可 | Exactly Once，失败重试即可 |
| 扩展性 | Yes | Yes | Yes |
流批一体原因：
- 1．人力成本比较高:批、流两套系统，相同逻辑需要开发两遍;
- 2．数据链路冗余:本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费;
- 3.数据口径不一致:两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。
- 4精选案例讲述
1.电商流批一体实践
目前电商业务数据分为离线数仓和实时数仓建设，离线和实时数据源，计算引擎和业务代码没有统一，在开发相同需求的时候经常需要离线和实时对齐口径，同时，由于需要维护两套计算路径，对运维也带来压力。
- 从数据源，业务逻辑，计算引擎完成统一，提高开发和运维效率。
2.Flink OLAP 场景实践
- Flink的OLAP在字节内部的场景主要是HTAP场景。
