这是我参与「第四届青训营 」笔记创作活动的第1天
1.Flink概述
1.1Apache Flink 诞生背景
业内对大数据的实时性提出更高的要求 大数据：指无法在一定时间内用常规工具对其进行获取，存储，管理和处理的数据集合。
- 其特点有：海量化，多样化，快速化，价值化。
大数据实时性带来的价值：监控场景，金融风控，实时推荐。。。
| 批式计算 | 流式计算 |
|---|---|
| 离线计算，非实时；静态数据集；小时/天等周期计算 | 实时计算，快速，低延迟；无限流，动态，无边界；持续运行；流批一体 |
1.2 Flink的优势
- Flink 通过实现了 Google Dataflow 流式计算模型实现了高吞吐、低延迟、高性能兼具实时流式计算框架。
- flink 支持高度容错的状态管理，防止状态在计算过程中因为系统异常而丢失，flink 周期性地通过分布式快照技术 Checkpoints 实现状态的持久化维护，使得即使在系统停机或者异常情况下都能计算出正确的结果。
- 流批一体
- 状态计算的 exactly-once 语义，流程序可以在计算过程中维护自定义状态。Flink 的 checkpointing 机制保证了即时在故障发生下也能保障状态的 exactly once 语义。
2. Flink整体框架
2.1Flink分层架构
Flink各个模块的用途
2.2Flink总体架构
一个 Flink 集群，主要包含以下两个核心组件：
- JobManager ( JM )：负责整个任务的协调工作，包括：调度 task 、触发协调 Task 做 Checkpoint 、协调容错恢复等；
- TaskiManager( TM )：负责执行一个 DataFlow Graph 的各个 task 以及 data streams 的 buffer 和数据交换。
- Dispatcher ：接收作业，拉起 JobManager 来执行作业，并在 JobMaster 挂掉之后恢复作业；
- JobMaster :管理一个 job 的整个生命周期，会向 ResourceManager 申请 slot ，并将 task 调度到对应 TM 上；
- ResourceManager ：负责 slot 资源的管理和调度， Task manager 拉起之后会向 RM 注册；
2.3Flink作业示例
示例：从Kafka中读取一个实时数据流，每10s统计一次单词出现数，datastream实现代码如下：
2.4Flink如何做到流批一体
Apache Flink 主要从以下几个模块来做流批一体：
- sQL 层；2.DataStream API 层统一，批和流都可以使用 DataStream API 来开发；
- Scheduler 层架构统一，支持流批场景；
- Failover Recovery 层架构统一，支持流批场景；
- Shufle Service 层架构统一，流批场景选择不同的 Shufle Service ;
3.Flink框架优化
在实际生产环境中，针对不同的应用场景，我们对数据处理的要求是不同的：
- 有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高，典型的应用是 搜索引擎构建索引；
- 有些场景下，需对数据进行实时分析，要求每条数据处理延迟尽可能低，典型的应用是广告 推荐、金融风控场景。
三种解决方案
3.1Flink OLAP架构
- Client ：提交 sQL Query Gateway 接收 Client 提交的 sQL Query ，对sQL 进行语法解析和査询优化，生成 Flink 作业执行计划，提交给 Session 集群
- Session Cluster： 执行作业调度及计算，并返回结果。
3.2Flink在OLAP架构的问题与设想
- 架构与功能模块：
- JobManager 与 ResourceManager 在一个进程内启动，无法对 JobManager 进行水平扩展；
- Gateway 与 Flink Session Cluster 互相独立，无法进行统一管理。
- 作业管理及部署模块：
- JobManager处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存；
- TaskManager 部署计算任务时，任务初始化部分耗时严重，消耗大量 CPU 。
- 资源管理及计算任务调度：
- 资源申请及资源释放流程链路过长
- Slot 作为资源管理单元， JM 管理 slot 资源，导致 JM 无法感知到 TM 维度的资源分布，使得资源管理完全依赖于 ResourceManager
- 其他：
-
作业心跳与 Failover 机制，并不合适AP 这种秒级或毫秒级计算场景；
-
AP 目前使用 Batch 算子进行计算，这些算子初始化比较耗时；
