Flink
2023-06-07 13:50:53 0 举报AI智能生成
Flink
作者其他创作
大纲/内容
概述
Flink概念
Apache Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行状态计算。
数据处理的演变
传统数据处理架构
图示
分支主题
解释
需要写入传统型数据库，数据量超过了DBMS的负担
分析处理
图示
分支主题
解释
只能离线状态下从传统型数据库经过ETL工具处理，存储到数仓进行分析处理
有状态的流式处理
图示
分支主题
解释
通过计数器对操作进行状态保存，对状态进行存取，需要在阶段性checkpoint进行落盘操作，基于数据传入的顺序问题，所以进行了小批处理
流处理的演变
lambda架构
分支主题
Flink
分支主题
Flink的主要特点
事件驱动（Event-driven）
图示
分支主题
解释
事件驱动型应用是一类具有状态的应用，它从一个或多个事件流提取数据，并根据到来的事件触发计算、状态更新或其他外部动作
基于流
离线数据有界流
实时数据无界流
分层API
图示
分支主题
解释
High-level Analytics | SQL/Table API(dynamic tables）
Stram- & Batch Data Processing | DataStream API(streams,windows)
Stateful Event Driven Applications | ProcessFunction(events,state,time)
Flink与Spark Streaming
图示
分支主题
分支主题
解释
数据模型
Spark采用RDD模型，Dstream实际上是一组小批数据RDD的集合
Flink基本数据模型是数据流，以及事件（Event）序列
运行时架构
Spark是批计算，DAG划分为不同的stage，一个完成后才可以计算下一个
Flink是标准的流执行模式，一个事件在一个节点处理完后可以直接发往下一个节点进行处理
Flink运行架构
运行时组件
JobManager
接受要执行的任务程序
JobGraph
Logical Dataflow Graph
类、库和其他资源的JAR包
转换JobGraph
ExecutionGraph
向ResourceManager申请资源（即TaskManager的Slot）
ResourceManagaer
TaskManagaer
在执行过程中，一个TaskManager可以跟其它运行同一应用程序的TaskManager交换数据
TaskManager 在启动的时候就设置好了槽位数（Slot），每个 slot 能启动一个 Task，Task 为线程
Dispatcher
它为应用提交提供了REST接口，方便集群通信，跨作业运行
任务提交流程
Standalone模式
图示
分支主题
Yarn模式
图示
分支主题
任务调度原理
图示
分支主题
基本流程
Flink Program执行Client准备JobGraph（dataflow）并发送给JobManager
JobManager 再调度任务到各个 TaskManager 去执行
TaskManager 将心跳和统计信息汇报给 JobManager，TaskManager 之间以流的形式进行数据的传输
Client，JobManager，TaskManager都是独立的JVM进程
TaskManger与Slots
Flink中每一个worker(TaskManager)都是一个JVM进程
它可能会在独立的线程上执行一个或多个subtask，执行的数量由slot决定
一个TaskManager多个slot意味着更多的subtask可以共享同一个JVM，同一个JVM进程中的task将共享TCP连接（基于多路复用）和心跳消息
静态与动态
Task Slot是静态的概念，是指TaskManager具有的并发执行能力，可以通过参数taskmanager.numberOfTaskSlots进行配置
并行度parallelism是动态概念，即TaskManager运行程序时实际使用的并发能力，可以通过参数parallelism.default进行配置
程序与数据流（DataFlow）
Flink程序组成
Source
Transformation
Sink
图示
分支主题
执行图（ExecutionGraph）
StreamGraph
根据用户通过 Stream API 编写的代码生成的最初的图。用来表示程序的拓扑结构
JobGraph
StreamGraph的优化，主要优化为多个符合条件的节点连接成一个节点，减少序列化操作
ExecutionGraph
ExecutionGraph是JobGraph的并行化版本，是调度层最核心的数据结构
物理执行图
JobManager 根据 ExecutionGraph 对 Job 进行调度后，在各个TaskManager 上部署 Task 后形成的“图”
图示
分支主题
并行度
一个特定算子的子任务（subtask）的个数被称之为其并行度（parallelism）
并行与并发
并行：多个cpu同时执行多个任务
并发：一个cpu同时执行多个任务
Stream在算子间的传输形式
One-to-one
stream(比如在source和map operator之间)维护着分区以及元素的顺序
Redistributing
stream(map()跟keyBy/window之间或者keyBy/window跟sink之间)的分区会发生改变
任务链（Operator Chains）
图示
分支主题
Flink流处理API
Enviroment
getExecutionEnvironment
批处理
ExecutionEnvironment
流处理
StreamExecutionEnvironment
createLocalEnvironment
createLocalEnvironment(1)
createRemoteEnvironment
ExecutionEnvironment.createRemoteEnvironment("jobmanage-hostname", 6123,"YOURPATH//wordcount.jar")
Source
从集合读取
env.fromCollection()
从文件读取
env.readTextFile()
从kafka读取
val userStream = env.addSource(new FlinkKafkaConsumer011[String]("sensor", new SimpleStringSchema(), properties))
自定义Source
extends SourceFunction[]
Transform
map
flatMap
filter
keyBy
DataStream → KeyedStream
滚动聚合算子（Rolling Aggregation）：针对KeyedStream的每一个支流做聚合
sum()
min()
max()
minBy()
maxBy()
reduce
KeyedStream → DataStream
split与select
split
DataStream → SplitStream
select
SplitStream → DataStream
connect与coMap
DataStream,DataStream → ConnectedStreams
ConnectedStreams → DataStream
union
DataStream → DataStream
Union可以操作多个流，Union之前两个流的类型必须是一样
Connect只能操作两个流，Connect可以不一样
实现UDF函数
Flink暴露了所有udf函数的接口
MapFunction
FilterFunction
ProcessFunction
富函数（Rich Functions）
所有Flink函数类都有其Rich版本。它与常规函数的不同在于，可以获取运行环境的上下文，并拥有一些生命周期方法
Sink
kafka
代码示例
val union = high.union(low).map(_.temperature.toString)
union.addSink(new FlinkKafkaProducer011[String]("localhost:9092", "test", new SimpleStringSchema()))
Flink+kafka如何实现exactly-once语义
通过checkpoint保存数据处理状态
TaskManager进行checkpoint的存储
checkpoint存储在StateBackend中，默认为内存级，可修改落盘
执行过程分为二段式
每一个算子执行完成时进行预提交
执行完sink进行最终提交，执行失败，预提交会放弃掉
redis
分支主题
elasticsearch
分支主题
JDBC自定义sink
继承RichSinkFunction
重写open
重写invoke
重写close
Time与Window
Time
图示
分支主题
解释
Event Time
事件创建的时间
Ingestion Time
数据进入Flink的时间
Processing Time
每一个执行基于时间操作的算子的本地系统时间
Window
window是一种切割无限数据为有限块进行处理的手段
类型
CountWindow
按照指定的数据条数生成一个Window
TimeWindow
按照时间生成Window
滚动窗口（Tumbling Windows）
时间对齐，窗口长度固定，没有重叠
滑动窗口（Sliding Windows）
时间对齐，窗口长度固定，有重叠
会话窗口（Session Windows）
时间无对齐
Window API
TimeWindow
滚动窗口
timeWindow(Time.seconds(15))
滑动窗口
timeWindow(Time.seconds(15), Time.seconds(5))
window_size
sliding_size
CountWindow
滚动窗口
countWindow(5)
滑动窗口
countWindow(10,2)
window_size
sliding_size
EventTime与Watermark
EventTime的引入
// 从调用时刻开始给env创建的每一个stream追加时间特征
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)
Watermark
基本概念
Watermark是用于处理乱序事件的，正确的处理乱序事件，通常用Watermark机制结合window来实现
window的执行是由Watermark触发的，WaterMark代表着timestamp小于其的数据都到达了
watermark的引入
Event Time的使用一定要指定数据源中的时间戳
通过TimestampAssigner接口实现
AssignerWithPeriodicWatermarks
按时间周期性的生成watermark
AssignerWithPunctuatedWatermarks
需要对每条数据进行间断式地生成watermark
EventTimeWindow API
滚动窗口（TumblingEventTimeWindows）
滑动窗口（SlidingEventTimeWindows）
会话窗口（EventTimeSessionWindows）
ProcessFunction（底层API）
ProcessFunction
KeyedProcessFunction
用来操作KeyedStream，会处理流的每一个元素
open（）
close（）
getRuntimeContext（）
processElement（）
onTimer（）
CoProcessFunction
ProcessJoinFunction
BroadcastProcessFunction
KeyedBroadcastProcessFunction
ProcessWindowFunction
ProcessAllWindowFunction
状态编程
状态一致性
状态一致性
定义
有状态的流处理，内部每个算子任务都可以有自己的状态
对于流处理器内部，状态一致性即计算结果要准确
exactly once
容灾恢复
分类
AT-MOST-ONCE
最多处理一次事件
任务故障时，既不恢复丢失，也不重播丢失
AT-LEAST-ONCE
容易多次处理事件
EXACTLY-ONCE
图示
分支主题
一致性检查点（Checkpoints）
目的
基于checkpoint保证exactly-once
方法
所有任务的状态，在所有任务都恰好处理完一个相同输入数据的时间点的一份拷贝
Flink 故障恢复机制的核心是一致性检查点
图示
分支主题
端到端（end-to-end）状态一致性
目的
保证数据源和持久化系统内数据状态的一致性
方法
内部保证
checkpoint
source端
可重设数据的读取位置
sink端
幂等写入（Idempotent Writes）
一个操作可以重复执行许多次，但只导致一次结果更改
分支主题
有几率将故障事件重演
事务写入（Transactional Writes）
预写日志（Write-Ahead-Log，WAL）
把结果数据先当成状态保存，然后在收到 checkpoint 完成的通知时，一次性写入 sink 系统
通过GenericWriteAheadSink来处理
两阶段提交（Two-Phase-Commit，2PC）
内部支持
TwoPhaseCommitSinkFunction
外部支持
sink
必须提供事务支持
不同Source和Sink的一致性保证
分支主题
Flink+Kafka 端到端状态一致性的保证
内部
checkpoint
source
kafka consumer
保存偏移量
sink
kafka producer
TwoPhaseCommitSinkFunction，两阶段提交sink
JobManager 协调各个 TaskManager 进行 checkpoint 存储
checkpoint保存在 StateBackend中，默认StateBackend是内存级
当 checkpoint 启动时，JobManager 会将检查点分界线（barrier）注入数据流
barrier会在算子间传递下去，每个算子会对当前的状态做个快照，保存到状态后端
每个内部的 transform 任务遇到 barrier 时，都会把状态存到 checkpoint 里
sink 任务首先把数据写入外部 kafka，这些数据都属于预提交的事务；遇到 barrier 时，把状态保存到状态后端，并开启新的预提交事务
当所有算子任务的快照完成，也就是这次的 checkpoint 完成时，JobManager 会向所有任务发通知，确认这次 checkpoint 完成
sink 任务收到确认通知，正式提交之前的事务，kafka 中未确认数据改为“已确认”
状态管理
状态类型
算子状态（operator state）
列表状态（List state）
将状态表示为一组数据的列表
联合列表状态（Union List state）
广播状态（Broadcast state）
如果一个算子有多项任务，而它的每项任务状态又都相同，那么这种特殊情况最适合应用广播状态
键控状态（keyed state）
键控状态是根据输入数据流中定义的键（key）来维护和访问的
数据类型
ValueState[T]保存单个的值，值的类型为T
ListState[T]保存一个列表，列表里的元素类型为T
MapState[k,v]
ReducingState[T]
AggregatingState[I,O]
状态后端（State Backend）
类型
MemoryStateBackend（开发环境）
内存级的状态后端
本地状态存储在TaskManager的JVM堆上；而将checkpoint存储在JobManager的内存中。
FsStateBackend（稳定）
将checkpoint存到远程的持久化文件系统（FileSystem）上，本地状态存储在TaskManager的JVM堆上
RocksDBStateBackend
将所有状态序列化后，存入本地的RocksDB中存储
TableAPI与SQL(1.9版本)
Flink CEP
定义
一个或多个由简单事件构成的事件流通过一定的规则匹配，然后输出用户想得到的数据，满足规则的复杂事件
特点
目标：从有序的简单事件流中发现一些高阶特征
输入：一个或多个由简单事件构成的事件流
处理：识别简单事件之间的内在联系，多个符合一定规则的简单事件构成复杂事件
输出：满足规则的复杂事件
目的
支持流上模式匹配，分析低延迟、频繁产生的不同来源的事件流
0 条评论
下一页
