这是我参与「第四届青训营 」笔记创作活动的第2天
1. 大数据
麦肯锡全球研究所定义：一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合，具有海量的数据规模、快速的数据流转、多样的数据类型和价值密度低四大特征。
搜狗百科定义：大数据是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。
1.1 大数据计算架构发展历史
1.2 为什么我们需要流式计算
大数据的实时性带来价值更大，比如：
- 监控场景：如果能实时发现业务系统的健康状态，就能提前避免业务故障;
- 金融风控：如果实时监测出异常交易的行为，就能及时阻断风险的发生;
- 实时推荐：比如在抖音，如果可以根据用户的行为数据发掘用户的兴趣、偏好，就能向用户推荐更感兴趣的内容;
- ......
大数据实时性的需求，带来了大数据计算架构模式的变化：
2. Flink
2.1 Flink 是什么
Apache Flink 是一个框架和分布式处理引擎，用于在 无边界和有边界 数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。
2.2 Flink为什么脱颖而出
2.3 Flink 的分层架构
- SDK层：Flink的SDK目前主要有三类，SQL/Table、DataStream、Python;
- 执行引擎层(Runtime 层)：执行引擎层提供了统一的 DAG 用来描述数据处理的 Pipeline,不管是流还是批，都会转化为 DAG 图，调度层再把 DAG 转化成分布式环境下的 Task,Task 之间通过 huffle 传辅输数据：
- 状态存储层：负责存储算子的状态信息：
- 资源调度层：目前Flink可以支持部署在多种环境。
2.4 Flink 的总体架构
包括以下两个核心组件：
- JobManager：负责整个任务的协调工作，包括：调度 task、触发协调 Task 做 Checkpoint、协调容错恢复等；
- TaskManager：负责执行 DataFlow Graph 的各个 task 以及data streams 的 buffer 和数据交换。
2.5 Flink 作业示例
2.6 Flink 流批一体
Apache Flink主要从以下几个模块来做流批一体：
- SQL 层;
- DataStream API 层统一，批和流都可以使用 DataStream API 来开发；
- Scheduler 层架构统一，支持流批场景；
- Failover Recovery 层架构统一，支持流批场景；
- Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service;
3. Flink 架构优化
3.1 流/批/OLAP 业务场景概述
- 三种业务场景的特点对比如下表：
- 三种业务场景的解决方案的要求及带来的挑战是：
3.2 三种业务场景为什么可以用一套引擎来解决
-
场景上对比发现：
- 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
- OLAP 计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。
- Apache Flink 从流式计算出发，需要想支持 Batch 和 OLAP 场景，就需要解决下面的问题：
3.3 FLink 的 OLAP 的优化之路
3.3.1 Flink 做 OLAP 的优势
-
统一引擎：流处理、批处理、OLAP 统一使用 Flink 引擎；
- 降低学习成本，仅需要学习一个引擎；
- 提高开发效率，很多 SQL 是流批通用；
- 提高维护效率，可以更集中维护好一个引擎；
-
既有优势：利用 Flink 已有的很多特性，使 OLAP 使用场景更为广泛；
- 使用流处理的内存计算、Pipeline；
- 支持代码动态生成；
- 也可以支持批处理数据落盘能力；
-
相互增强：OLAP 能享有现有引擎的优势，同时也能增强引擎能力
- 无统计信息场景的优化；
- 开发更高效的算子；
- 使 Flink 同时兼备流、批、OLAP 处理的能力，成为更通用的框架。
3.3.2 Flink OLAP 场景的挑战
-
秒级和毫秒级的小作业；
-
作业频繁启停、资源碎片；
- Flink OLAP 计算相比流式和批式计算，最大的特点是 Flink OLAP 计算是一个面向秒级和毫秒级的小作业，作业在启动过程中会频繁申请内存、网络以及磁盘资源，导致 Flink 集群内产生大量的资源碎片；
-
Latency + 高 APS 要求；
- OLAP 最大的特点是查询作业对 Latency 和 QPS 有要求的，需要保证作业在 Latency 的前提下提供比较高的并发调度和执行能力，这就对 Flink 引擎提出了一个新的要求。
3.3.3 Flink OLAP 架构现状
-
Client：提交 SQL Query；
-
Gateway：接收 Client 提交的 SQL Query，对 SQL 进行语法解析和查询优化，生成 Flink 作业执行计划，提交给 Session 集群；
-
Session Cluster：执行作业调度及计算，并返回结果。
- JobManager 管理作业的执行，在接收到 Gateway 提交过来的作业逻辑执行计划后，将逻辑执行计划转换为物理执行计划，为每个物理计算任务分配资源，将每个计算任务分发给不同的 TaskManager 执行，同时管理作业以及每个计算任务执行状态；
- TaskManager执行具体的计算任务，采用线程模型，为每个计算任务创建计算线程，根据计算任务的上下游数据依赖关系跟上游计算任务建立/复用网络连接，向上游计算任务发送数据请求，并处理上游分发给它的数据。
3.3.4 Flink 在 OLAP 架构的问题与设想
-
架构与功能模块：
- JobManager 与 ResourceManager 在一个进程内启动，无法对JobManager 进行水平扩展；
- Gateway 与 Flink Session Cluster 互相独立，无法进行统一管理；
-
作业管理及部署模块：
- JobManager 处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存；
- TaskManager 部署计算任务时，任务初始化部分耗时验证，消耗大量 CPU；
-
资源管理及计算任务调度：
- 资源申请及资源释放流程链路过长；
- Slot 作为资源管理单元，JM 管理 slot 资源，导致 JM 无法感知到 TM 维度的资源分布，使得资源管理完全依赖于 ResourceManager；
-
其他：
- 作业心跳与 Failover 机制，并不合适 AP 这种秒级或毫秒级计算场景；
- AP 目前使用 Batch 算子进行计算，这些算子初始化比较耗时；
总结
这节课我学到了：
- Apache Flink 概述；
- 流批一体的 Apache Flink 架构；
- Apache Flink 的 OLAP 场景面临的问题及优化思路；
- Flink 使用案例；
