流/批/OLAP 一体的 Flink 引擎介绍
这是我参与「第四届青训营 」笔记创作活动的第1天
流式计算 --- 最后项目开发
本次课程为第二次课，第一次的笔记还在整理之中，本节课概念较多，已经进行了一定整理。
01.Flink概述
1. 1. 诞生背景
1. 1. 1. 什么是大数据
- Bigdata:无法在一定时间内用常规软件工具对其进行获取、存储、管理和处理的数据集合
- 4v:Value(价值化)、Volumes(海量化)、Velocity(快速化)、Variety(多样化)。
1. 1. 2. 大数据架构发展历史
- 史前阶段-2006
- 传统数仓、Oracle、单机、黑箱使用。
- Hadoop
- 分布式
- map-reduce：计算框架
- bigtable:分布式数据库
- Spark
- map-reduce处理性能较差，spark内存迭代，sql高阶API可表达更多语义，使用更加简单。
- Flink
- 流式计算，实时性强，流/批支持sql使用
1. 1. 3.流式计算
实时性的价值大:
- 监控场景
- 金融风控
- 实施推荐
- 等等
| 批式计算 | 流式计算 |
|---|---|
| 离线计算、非实时 | 实时计算、快速、低延迟 |
| 静态数据集 | 无限流、动态、无边界 |
| 小时/天数等周期性计算 | 7x24h持续运行 |
| 流批一体 |
1. 2. Flink其优势
流式计算框架对比:
| Storm | Spark Streaming | Flink | |
|---|---|---|---|
| Streaming Model | Native | mini-batch | Native |
| 一致性保证 | At Least/Most Once | Exactly-Once | AT-MOST-ONCE、AT-LEAST-ONCE、EXACTLY-ONCE |
| 延迟 | 低延迟(毫秒级) | 延迟较高(秒级) | 低延迟(毫秒级) |
| 吞吐 | Low | High | High |
| 容错 | ACK机制 | RDD Based Checkpoint | Checkpoint (Chandy-Lamport) |
| StateFul | No | Yes(DStream) | Yes(Operator) |
| SQL支持 | No | Yes | Yes |
后边会有课程介绍Flink的Checkpoint(Chandy-Lamport)
Flink:一个支持状态计算的分布式处理框架 无边界的(比如kafka)抽象成streaming 有边界的数据集---streaming
- Exactly-Once 精确一次的计算语义
- Checkpoint 状态容错
- Dataflow编程模型 window等高阶需求支持友好
- 流批一体
1. 3. Apache Flink 开源生态
02.Flink 整体架构
2.1 分层架构
- SDK层：SQL/Table、DataStream、Python
- 执行引擎层(Runtime):提供统一DAG，用来描述数据处理的Pipleline，转化为DAG图，调度层再把DAG转化为分布式环境下的Task，Task之间通过shuffle传输数据。
- 状态存储层:负责存储算子的状态信息
- 资源调度层:目前Flink可以支持部署在多种环境。
2.2 Flink整体架构
一个Flink集群，主要包含以下两个核心组件
- JobManager (JM):负责整个任务的协调工作，包括:调度task、触发协调Task做 Checkpoint、协调容错恢复等;
- TaskManager (TM) :负责执行一个 DataFlowGraph 的各个 task以及 data streams的 buffer和数据交换。
Flink Program中，比如写的SDK，右逻辑，clent处理后（前边提到的Pipline作为DAG）[逻辑执行图]发送给JM,然后发送给(即物理执行图)TM，然后把作业交给worker。 JM在TM挂掉时可起到作用
-
JobManager职责
- 申请资源(slot)
2.3 作业实例
词频统计 流式的WordCount示例，从 kafka中读取一个实时数据流，每10s统计一次单词出现次数
//Source
Datastream<String> lines = env.addSource (
new FlinkKafkaConsumer<> (...) ) ;
//Transformation
Datastream<Event> events - lines.map ( (line)-> parse(line) ) ;
//Transformation
Datastream<statistics> stats = events
.keyBy (event -> event.id)
.timewindow (Time.seconds (10) )
.apply (new MywindowAggregationFunction () ) ;
//Sink
stats.addsink (new BucketingSink(path) ) ;
业务逻辑转换为一个Steaming DataFlow Graph
并发配置以及其余算子配置。 将Steaming DataFlow Graph转化为Parallel Dataflow(Execution Graph)(支持并发)
数据->固定语义处理数据
Flink将不同的operator链接(chain)在一起形成Task 这样每个Task 可以在一个线程中执行，内部叫做OperatorChain，如下图的source和map算子可以Chain在一起
可减少线程切换，以及数据的反序列化。 这部分可再结合源码理解。 之后JM的操作，去TM里申请一些资源(slot)，可见下图：
2.4 Flink流批一体
实时获取一些信息
- 数据源
- 实时数仓(Flink)
- 离线数仓(Sqark/Hive)
2.4.1
架构存在的痛点: -人力成本比较高:批、流两套系统，相同逻辑需要开发两遍 -数据链路冗余:本身计算内容是一致的，由于是两套链路，相同逻辑需要运行两遍，产生一定的资源浪费
- 数据口径不一致:两套系统、两套算子、两套UDF，通常会产生不同程度的误差，这些误差会给业务方带来非常大的困扰
2.4.2
| 维度 | 流式计算 | 批式计算 |
|---|---|---|
| 计算方式 | 实时计算 | 离线计算 |
| 延迟级别 | 延迟在秒级以内 | 处理时间为分钟到小时级别，甚至天级别 |
| 范围 | 0-1s | 10s-1h+ |
| 业务场景 | 广告推荐、金融风控 | 搜索引擎构建索引、批式数据分析 |
| 数据流 | 无线数据集 | 有限数据集 |
| 时延 | 低延迟、业务会感知运行中的情况 | 实时性要求不高，只关注最终结果产出时间 |
2.4.3 Flink如何做到流批一体
批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流一种特殊的数据流。
- 站在 Flink的角度，Everything is Streams，无边界数据集是一种数据流，一个无边界的数据流可以按时间切段成一个个有边界的数据集，所以有界数据集（批式数据）也是一种数据流。
- 因此，不管是有边界的数据集（批式数据）还是无边界数据集，Flink都可以天然地支持，这是Flink支持流批一体的基础。并且Flink 在流批一体上，从上面的API到底层的处理机制都是统一的，是真正意义上的流批一体。
Apache Flink主要从以下几个模块来做流批一体:
- SQL层;
- DataStream API层统一，批和流都可以使用DataStream来API来开发; 3.Scheduler层架构统一，支持流批场景
- Failover Recovery层架构统一，支持流批场景 5.Shuffle Service层架构统一，流批场景选择不同的 Shuffle Service
2.4.4 流批一体的Scheduler层
在1.12之前的版本中，支持两种调度模式
| 模式 | 特点 | 场景 |
|---|---|---|
| EAGER | 申请一个作业所需要的全部资源，然后同时调度这个作业的全部Task，所有的Task之间采取Pipeline的方式进行通信 | Stream 作业场景 |
| LAZY | 先调度上游，等待上游产生数据或结束后再调度下游，类似Spark的 Stage执行模式。 | Batch作业场景 |
- EAGER模式
- 12个task会一起调度，集群需要有足够的资源
- LAZY模式
- 最小调度一个task，集群有1个slot资源可以运行
调度机制Pipline Region
综合两种模式，得出的调度模式。
- 最小调度一个task，集群有1个slot资源可以运行
调度机制Pipline Region
由Pipeline的数据交换方式连接的Task构成为一个Pipeline Region
本质上，不管是流作业还是批作业,都是按照 Pipeline Region粒度来申请资源和调度任务。
-
ALL_EDGES_BLOCKING:
- 所有Task 之间的数据交换都是BLOCKING模式;
- 分为12个pipeline region
-
ALL_EDGES_PIPELINED:
- 所有Task之间的数据交换都是PIPELINE模式
- 分为1个pipeline region 对流和批模型做了抽象，可以同时对流和批进行调度，进行了统一。
2.4.5流批一体的shuffle Service层
Shuffle:在分布式计算中，用来连接上下游数据的过程。
比如LAZY模式中，a1->b1->c1都是shuffle。
针对不同的分布式计算框架，Shuffle通常有几种不同的实现︰
| 基于文件的Pull Based Shuffle | 基于Pipeline的Push Based Shuffle |
|---|---|
| 比如Spark 或MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好—些; | 比如Flink、Storm、Presto等，它的特点是低延迟和高性能，但是因为shuffle数据没有存储下来，如果是batch 任务的话，就需要进行重跑恢复; |
流和批shuffle之间的差异：
| 流 | 批 | |
|---|---|---|
| 生命周期 | 流作业的Shuffle数据与Task是绑定的 | 批作业的shuffle数据和Task和解耦的 |
| 存储介质 | 流作业的生命周期比较短、而且流作业为了实时性，Shuffle通常存储在内存中 | 批作业因为数据量比较大以及容错的需求，一般会存储在磁盘里 |
| 部署方式 | 流作业Shuffle服务和计算节点部署在一起，可以减少网络开销，从而减少latency | 批作业则不同 |
- Shuffle Service,flink开源社区已经支持
- Netty Shuffle Service
- Remote Shuffle Service
Flink在架构设计上针对:
- DataStream层
- 调度层
- Shuffle Service层 均完成了对流和批的支持
03.Flink架构优化
在不同场景下，我们对数据处理要求不同，可能离线可能实时。
| 维度/模块 | 流式计算 | 批式计算 | 交互式计算 |
|---|---|---|---|
| 计算方式 | 实时计算 | 离线计算 | OLAP |
| 实时性 | 高,延迟在秒级以内 | 处理时间为分钟到小时级别，甚至天级别 | 高，查询延迟在秒级，但要求高并发查询 |
| 范围 | 0-1s | 10s-1h+ | 1-10s |
| 业务场景 | 广告推荐、金融风控 | 搜索引擎构建索引、批式数据分析 | 数据分析BI报表 |
| 数据流 | 无线数据集 | 有限数据集 | |
| 时延 | 低延迟、业务会感知运行中的情况 | 实时性要求不高，只关注最终结果产出时间 | |
| SQL | YES | YES | YES |
| 状态 | Yes | No | No |
| 容错能力 | 高 | 中，大作业失败重跑代价高 | No，失败重试即可 |
| 准确性 | Exactly Once，要求高,重跑需要恢复之前的状态 | Exactly Once，失败重跑即可 | Exactly Once，失败重跑即可 |
| 扩展性 | Yes | Yes | yes |
3.2三种业务场景可用一套引擎来解决
- 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流;
- 而OLAP计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。
- 因此，理论上，我们是可以用一套引擎架构来解决上述三种场景，只不过需要对不同场景支持相应的扩展性、并允许做不同的优化策略。
OLAP是一种特殊的批式计算
- Batch 场景需求
- 流批一体支持
- Unify DataStream API;
- Scheduler
- Shuffle Service
- Failover Recovery
- OLAP场景需求
- 短查询作业场景
- 高并发支持
- 极致处理性能
3.3 Flink的OLAP的优化
- 引擎统一
- 降低学习成本
- 提高开发效率
- 提高维护效率
- 既有优势
- 内存计算
- Code-gen
- Pipline Shuffle
- Session 模式的MPP架构
- 生态支持
-
跨数据源查询支持
-
TCP-DS基准测试性能强
-
-
Client :提交SQL QueryF折8853
-
Gateway
- 接收Client提交的SQL Query，对SQL进行语法解析和查询优化，生成 Flink 作业执行计划，提交给Session集群;
-
Session Cluster
- 执行作业调度及计算，并返回结果。
-
架构与功能模块
- JobManager与ResourceManager在一个进程内启动，我发对JobM进行水平扩展
- Gateway与Flink Session Cluster互相独立，无法统一管理。（统一管理成本会很高）
-
作业管理及部署模块
- JobManager处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存; (JM在解析完作业后会生成物理执行计划，物理执行计划最小单位为计算任务，JM管理所有计算任务。在高并发场景下，性能会受影响。)
- TaskManager部署计算任务时，任务初始化部分耗时严重，消耗大量CPU。
-
资源管理及计算任务调度
- 资源申请及资源释放流程链路过长
- Slot 作为资源管理单元，JM管理slot资源，导致JM无法感知到TM维度的资源分布，使得资源管理完全依赖于ResourceManager （希望在AP环境下得到优化）
-
其他
- 作业心跳与Failover机制，并不合适AP这种秒级或毫秒级计算场景;
- AP目前使用 Batch算子进行计算，这些算子初始化比较耗时 Apache Flink 最终演进结果：
思考：我们可以从哪些角度来对Flink AP场景进行优化？
04.精选案例讲解
- 电商流批一体实践
- 从数据源，业务逻辑，计算引擎完成统一，提高开发和运维效率。
流批一体，减少了运维的成本。
- Flink OLAP 场景实践
T--事物的计算
AP--查询的计算
HTAP（Hybrid Transaction / Analytical Processing，混合事务分析处理）即同时支持 OLTP 和 OLAP 场景，需要创新的计算存储框架，在一份数据上保证事务的同时支持实时分析，省去费时的 ETL 过程
上边链路(天级)
下边链路(秒级)
- Flink直接提供数据查询与分析的能力
以上就为课程学习笔记整理，加深学习仍需对学员手册进行复习，同时扩展学习内容以及实践。
