这是我参与「第四届青训营」笔记创作活动的的第2天
Apache Flink 概述
大数据定义：无法在一定时间内用常规软件工具对其进行获取、储存、管理和处理的数据集合。 流式计算应用场景：监控场景、金融风控、实时推荐等。
Flink整体架构
Flink分层架构
- SDK层：三类，SQL、DataStream、Python（ML）
- 执行引擎层Runtime：提供了统一的DAG图用来描述数据处理的Pipeline
- 状态存储层：储存算子的状态信息
- 资源调度层：可支持部署在多种环境，Yarn,K8S
Flink总体架构
一个Flink集群主要包含两个核心组件：
- JobManager：负责整个任务的协调工作，包括：调度 task、触发协调 Task 做 Checkpoint、协调容错恢复
- TaskManager：负责执行一个 DataFlow Graph 的各个 task 以及 data streams 的 buffer 和数据交换
流批一体需求的原因：
- 人力成本比较高；
- 数据链路冗余：本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费；
- 数据口径不一致：两套系统、两套算子、两套 UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰。
流批一体的挑战：
- 数据流维度：无线数据集
- 时延：低时延，业务会感知运行中的情况
Flink中的流批一体
- 批式计算是流式计算的特例。
- Flink 主要从以下几个模块来做流批一体：
- SQL 层；
- DataStream API 层统一，批和流都可以使用 DataStream API 来开发；
- Scheduler 层架构统一，支持流批场景；
- Failover Recovery 层 架构统一，支持流批场景；
- Shuffle Service 层架构统一，流批场景选择不同的 Shuffle Service；
流批一体的 Shuffle Service 层
- Shuffle：在分布式计算中，用来连接上下游数据交互的过程
- 两种实现方式：
- 基于文件的 Pull Based Shuffle，比如 Spark 或 MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些；
- 基于 Pipeline 的 Push Based Shuffle，比如 Flink、Storm、Presto 等，它的特点是低延迟和高性能，但是因为 shuffle 数据没有存储下来，如果是 batch 任务的话，就需要进行重跑恢复； 流和批 Shuffle 之间的差异：
流和批Shuffle的差异
本质上都是对为了对数据进行Re-Partition，因此存在共性
- Shuffle 数据的生命周期：流作业的 Shuffle 数据与 Task 是绑定的，而批作业的 Shuffle 数据与 Task 是解耦的；
- Shuffle 数据存储介质：流作业的生命周期比较短、而且流作业为了实时性，Shuffle 通常存储在内存中，批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里；
- Shuffle 的部署方式：流作业 Shuffle 服务和计算节点部署在一起，可以减少网络开销，从而减少 latency，而批作业则不同。
流、批、交互式分析 三种业务场景
- 共同点：需要SQL，具有拓展性，Exactly Once。批式计算是流式计算的特例，批式数据也是一种数据流、一种特殊的数据流；OLAP 计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。
- 流式计算：实时计算，延迟秒级内，容错高，重跑需要恢复之前的状态，适用于广告推荐、金融风控
- 批式计算：离线计算，处理时间分钟到小时，失败重跑但大作业中失败代价高，适用于搜索引擎构建索引等
- 交互式分析OLAP：特殊的批式计算，对并发和实时性要求高，适用于数据分析BI报表
