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