这是我参与「第四届青训营 」笔记创作活动的的第2天
flink概述
flink的诞生
关于flink的诞生问题，我门需要理解什么是大数据以及大数据的一个发展演变
关于大数据：一种规模大到在获取、存储、管理、分析方面大大超出了传统数据库软件工具能力范围的数据集合，具有1.海量的数据规模、2.快速的数据流转、3.多样的数据类型和4.价值密度低四大特征。
大数据计算框架历史演变： 史前阶段 -> hadoop -> spark -> flink
史前阶段：主要是传统数仓 hadoop:分布式，mapreduce，离线计算 spark：批处理，流处理，内存迭代计算，SQL高阶API flink：流批一体，实时快速，流批SQL
对于流式计算，主要是考虑到大数据的实时性价值更大
比如实时计算通常用于监控，金融风控，实时推荐等场景
flink的突出
流式计算框架有很多，但是为什么flink能够从中脱颖而出呢？
下面是几个流行流式计算框架的对比：
| Storm | Spark Streaming | Flink | |
|---|---|---|---|
| Streaming Model | Native | mini-batch | Native |
| 一致性保证 | At Least/Most one | Exactly-Once | Exactly-Once |
| 延迟 | 低延迟(毫秒级) | 延迟较高 | 低延迟(毫秒级) |
| 吞吐 | Low | Hign | HIgh |
| 容错 | ACK | RDD Based Checkpoint | Checkpoint(Chandy-Lamport) |
| StateFul | No | Yes(Dstrem) | Yes(Operator) |
| SQL支持 | No | Yes | Yes |
flink特点：
- 流批一体
- Exactly-Once 精确一次的计算语义
- 提供状态容错 checkpoint
- Dataflow 编程模型；Window 等高阶需求支持友好
- 有状态计算
开源生态
Apache Flink 在开源生态上的能力比较强大，可以支持：
- 流批一体：支持流式计算和批式计算；
- OLAP：Flink 可以支持 OLAP 这种短查询场景；
- Flink ML：pyFlink、ALink、AIFlow 等生态支持 Flink 在 ML 场景的应用；
- Gelly：图计算；
- Stateful Function：支持有状态的 FAAS 场景；
flink整体架构
分层架构
有四个层级
- SDK层:SQL/Table、DataStream、Python
- 执行引擎层(Runtime层):描述业务处理的Pipeline，转化为DAG图
- 状态存储层:负责存储算子的状态信息
- 资源调度层:多种部署模式
总体架构
两个核心组件
-
JobManager：整个任务的协调工作包括：调度 task、触发协调 Task 做 Checkpoint、协调容错恢复等，核心有下面三个组件：
- Dispatcher: 接收作业，拉起 JobManager 来执行作业，并在 JobMaster 挂掉之后恢复作业；
- JobMaster: 管理一个 job 的整个生命周期，会向 ResourceManager 申请 slot，并将 task 调度到对应 TM 上；
- ResourceManager：负责 slot 资源的管理和调度，Task manager 拉起之后会向 RM 注册；
-
TaskManager：必须始终至少有一个任务管理器。任务管理器中资源调度的最小单位是任务槽。任务管理器中的任务槽数指示并发处理任务数。请注意，一个任务槽中可能会执行多个运算符
flink作业示例
使用大数据计算中的hello world - wordcount程序 Hands-On Training
流批一体
流批一体的需求
例子：
-
实时统计短视频的播放量、点赞量或者直播间的观看人数
-
统计up主的历史数据，如昨天的播放量，评论量等等
解决以上问题需要设计两种架构，批处理和流处理
带来问题：
- 相同逻辑开发两遍
- 数据链路冗余
- 数据口径不一致：容易造成不同程度的误差
流批一体的挑战：两种模式的特点不同，主要表现在延迟高低，数据流的模式
flink实践
一个思想： 批计算是流式计算的特例， 对于无边界数据流可以按实践切短一个个有界的数据流
从几个模块做到批流一体：
- sql层
- datastream API层统一
- Scheduler层架构统一
- Failover Recovery层架构统一
- Shuffle Service层
scheduler层
任务：DAG-> 分布式环境中可执行的task
两种调度模式
- eager 申请一个作业所需的全部资源，task之间用pipeline的方式进行通信 stream 集群需要有足够的资源
- lazy 先上游后释放给下游 数据不需要落盘 batch
- all_edges_blocking
- all_edges_pipelines
- blocking模式：需要落盘
- pipeline模式：不需要落盘，直接走内存，传到下个task
Shuffle Service层
shuffle:在分布式计算中，用来连接上下游数据交互的过程叫做shuffle
实现：
- 基于文件的 Pull Based Shuffle，比如 Spark 或 MR，它的特点是具有较高的容错性，适合较大规模的批处理作业，由于是基于文件的，它的容错性和稳定性会更好一些；
- 基于 Pipeline 的 Push Based Shuffle，比如 Flink、Storm、Presto 等，它的特点是低延迟和高性能，但是因为 shuffle 数据没有存储下来，如果是 batch 任务的话，就需要进行重跑恢复；
flink架构优化
flink可以运用于三种不同的计算场景： 流/批/OLAP
这三种模式有着不同的特点和挑战，但还是可以用一套引擎来解决
原因：
- 批式计算是流式计算的特例，Everything is Streams，有界数据集（批式数据）也是一种数据流、一种特殊的数据流；
- OLAP 计算是一种特殊的批式计算，它对并发和实时性要求更高，其他情况与普通批式作业没有特别大区别。
但是如今flink再OLAP上还是存在不小的挑战
问题：
-
架构与功能模块：
- JobManager 与 ResourceManager 在一个进程内启动，无法对JobManager 进行水平扩展；
- Gateway 与 Flink Session Cluster 互相独立，无法进行统一管理；
-
作业管理及部署模块：
- JobManager 处理和调度作业时，负责的功能比较多，导致单作业处理时间长、并占用了过多的内存；
- TaskManager 部署计算任务时，任务初始化部分耗时验证，消耗大量 CPU；
-
资源管理及计算任务调度：
- 资源申请及资源释放流程链路过长；
- Slot 作为资源管理单元，JM 管理 slot 资源，导致 JM 无法感知到 TM 维度的资源分布，使得资源管理完全依赖于 ResourceManager；
-
其他：
- 作业心跳与 Failover 机制，并不合适 AP 这种秒级或毫秒级计算场景；
- AP 目前使用 Batch 算子进行计算，这些算子初始化比较耗时；
个人感想
上完这节课，对流式计算引擎flink有了一个大致的了解，感叹它流批一体功能的强大，在OLAP业务场景下也能投入实践。
本节课重点内容在于如何理解flink的总体架构和分层架构，利用wordcount作业来示例flink是如何进行作业的提交和计算。此外flink在在流批一体上的实现十分吸引我的目光，很好奇本来需要两种架构的计算模式，底层是如何做到合二为一，流批一体的，这是一个值得探讨的点
