这是我参与「第四届青训营 」笔记创作活动的第 4 天!
1、Apache Flink概述
(1)诞生背景
- 大数据(Big Data):指无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的海量数据集合。
graph LR
A(Big Data) --> B(Value价值化)
A(Big Data) --> C(Volumes海量化)
A(Big Data) --> D(Velocity快速化)
A(Big Data) --> E(Variety多样化)
- 大数据计算架构发展历史
- 史前阶段~2006:Google发表三篇大数据相关的论文(被誉为大数据领域的“三驾马车”)
- 流式计算的优势
- 大数据的实时性带来的巨大价值,比如:监控场景、金融风控和实时推荐等。
- 大数据的实时性需求,带来了大数据计算架构模式的变化:
(2)优势
- 业内常用的计算框架演化历史(流式计算引擎——红框)
- 流式计算引擎对比
- Why Flink
(3)Flink社区开源生态
2、Flink 整体架构
(1)分层架构
- 分层架构图
- SDK层:目前主要有三层,即SQL/Table、DataStream、Python;
- 执行引擎层(Runtime层):提供统一的DAG,用来描述数据处理的Pipeline,不管是流还是批,都会转化为DAG图,调度层再把DAG转化成分布式环境下的task,task之间通过Shuffle传输数据;
- 状态存储层:负责存储算子的存储信息;
- 资源调度层:目前 Flink 可以支持部署在多种环境。
(2)总体架构
- 总体架构图
- 一个 Flink 集群主要包含以下两个核心组件:
- JobManager(JM):负责整个任务的协调工作,包括:调度task、触发Task做CheckPoint、协调容错恢复等等;
- TaskManager(TM):负责执行一个 DataFlow Graph 的各个 task 以及 data streams 的 buffer 和 数据交换。
- 一个 Flink 集群主要包含以下两个核心组件:
(3)作业示例
- 流式的 WordCount 示例,从 kafka 中读取一个实时数据流,每 10s 统计一次单词出现次数,DataStream(数据流)实现代码如下:
- 业务逻辑转换为一个 Stream DataFlow Graph(流数据流图):
- 假设作业的 sink 算子的并发配置为 1,其余算子并发为 2;紧接着会将上面的 Streaming DataFlow Graph 转化为 Parallel Dataflow(内部叫 Execution Graph)
(4)如何做到流批一体
- 上述架构存在一些痛点:
- 流和批业务场景的特点如下表
- 流和批式计算核心的区别如下表:
- 为什么可以做到流、批一体
- Apache Flink 主要从以下几个模块来做流批一体
- 1.SQL层
- 2.DataStream APL 层统一,批和流都可以使用 DataStream API 来开发
- 3.Schedule 层架构统一,支持流、批场景
- Failover Recovery 层架构统一,支持流、批场景
- Shuffle Service 层架构统一,流、批场景选择不同的 Shuffle Service
- 流、批一体的 Scheduler 层
- Scheduler主要负责将作业的 DAG 转换为在分布式环境中可以执行的 Task
- 在 1.12 之前的 Flink 版本中,Flink支持以下两种调度方式
- EAGER 模式:16个 task 会一起调度,集群需要有足够的资源
- LAZY 模式:可以调度1个 task 即可,集群有一个 slot 资源可以运行
- Scheduler主要负责将作业的 DAG 转换为在分布式环境中可以执行的 Task
- 流、批一体的 Shuffle Service 层
- 在分布式计算中,用来连接上下游数据交互的过程叫做 Shuffle,实际上分布式计算中所有涉及到上下游数据衔接的过程都可以理解成 Shuffle。
- 在分布式计算中,用来连接上下游数据交互的过程叫做 Shuffle,实际上分布式计算中所有涉及到上下游数据衔接的过程都可以理解成 Shuffle。
- 针对不同的分布式计算框架,Shuffle 通常有几种不同的实现:
- 流和批 Shuffle 之间的差异
- 在Streaming 和 OLAP 场景下,为了性能的需要,通常会使用基于 Pipeline 的 Shuffle 模式;在 Batch 场景下,一般会选取 Blocking 的 Shuffle 模式。为了统一 Flink 在Streaming 和 Batch 模式下的 Shuffle 架构,Flink 实现了一个 Pluggable 的 Shuffle Service 框架,抽象出了一些公共模块。
3、Flink 架构优化
(1)Flink做 OLAP 的优势
(2)Flink 面对 OLAP 场景的挑战
- 秒级和毫秒级的小作业
- 作业频繁启停,资源碎片
- Latency + QPS 的要求
(3)Flink 面对 OLAP 架构的现状
- Client:提交 SQL Query;
- Gateway:接收 Client 提交的 SQL Query,对 SQL 进行语法解析和查询优化,生成 Flink 作业执行计划,提交给 Session 集群
- Session Cluster:执行作业调度及计算,并返回结果
(4)Flink 面对 OLAP 架构的问题与设想
- 架构与功能模块
- 作业管理及部署模块
- 资源管理及计算任务调度
- 其他
(5)总结
- Apache Flink 最终的演化结果:
文献:
1、大数据领域的“三驾马车”:blog.csdn.net/wwxy1995/ar… 2、