flink_基础使用_1

reduce
  1. a
split
	把一个datastream分成多个stream
connect&comap
	把两个流和为一个流
union
	把多条流合并为一条,必须是同样的数据类型
数据类型
	1. 元组 tuples
	2. java pojo 必须要有空参构造
	3. arrays list maps enums
rich functions
数据分区
	1. global 全给第一个下游分区
	2. rebalance 轮询分配
	3. rescale 分区轮询
	4. shuffle 随机分配
	5. keyby hashcode分区
sink
	1. kafka 引包 addsink
	2. redis
	3. mysql
window
	把无限流划分为有限流 分多个bucket
	时间窗口 时间满足执行计算
		滚动 tumbling windows 依据固定窗口长度切分
		滑动 sliding windows 固定窗口长度和滑动间隔组成
		会话 session windows 一段时间没有接受新数据就生成新的窗口 指定间隙时长
	计数窗口 数量满足执行计算
		滚动
		滑动
	windowall 把所有数据放一个窗口中
	// 时间滚动窗口
        mapStream.keyBy("id").timeWindow(Time.minutes(1));
        // 时间滑动窗口
        mapStream.keyBy("id").timeWindow(Time.seconds(1),Time.seconds(1));
        // 时间会话窗口
        mapStream.keyBy("id").window(EventTimeSessionWindows.withGap(Time.seconds(5)));
        // 计数滚动窗口
        mapStream.keyBy("id").countWindow(5);
        // 计数滑动窗口
        mapStream.keyBy("id").countWindow(4,1);
window function
	**增量聚合函数** 来一个计算一次 但是不输出
		reduceFunction/AggregateFunction : reduce/aggregage
	**全窗口函数**  等触发执行的时候才计算
		processWindowFunction/WindowFunction :process/apply
		
		tigger()触发器 定义window什么时候关闭 触发计算并输出结果
		evictor() 移除器 移除数据
		allowedLateness() 延迟关闭窗口时间 每次叠加计算
		sideOutputLateData() 配合getSideOutput()获取丢失数据
时间语义
	event time 事件创建的时间
	ingestion time 数据进入flink时间
	processing time 执行算子时间 默认是这个
watermark
	衡量eventtime进展的机制,可以设置延迟触发 一般用来处理短时间大量乱序数据
	处理乱序延迟数据3种机制 watermark->allowedLateness->sideOutputLateData
	根据eventtime更新watermark时间 不能逆序只能向前增加当watermark时间能推荐窗口事件
	watermark传输都规则是:上游任务都最小wm传递给下游的任务
	窗口起始点:
	起始时间- 时间%时间间隔
	多并行度watermark:
		多个slot之间多watermark不相互影响,下游获取上游多个slot最小多watermark,默认watermark是long的最小值当所有的上游slot的watermark的最小值达到触发标注才会触发下游所有的slot任务
状态管理

可以认为是一个本地变量 后续的任务需要根据状态进行业务操作更新
算子状态 状态适用于限定的算子任务才能访问
list state 列表状态 状态表示为一组列表 扩容时分发状态
union list state 联合列表状态 状态表示为一组列表,故障恢复或扩容是每个task有完整的list状态
broadcast state 广播状态 每项任务状态都一致
键控状态 分组状态 状态与key关联
valueState 值状态
listState 列表状态
mapState 映射状态
reducingState 聚合状态
状态后端
负责本地状态管理,checkpoint写入远程存储
MemoryStateBackend 内存级别
FsStateBackend checkpoint保存在远程的文件系统上,本地状态存在内存
rocksDBStateBackend 存在本地的rocketDB中

processFunction 底层api

可以获取时间戳或者上下文
可以获取当前的key 获取watermark
可以注册时间器
有生命周期函数
可以状态管理
分流操作

	processFunction
	keyedProcessFunction keyby流
	coProcesFunction 基于connectedStream
	processJoinFunction 两条流join之后调用
	BroadcastProcessFunction 广播流
	keyedBroadcastProcessFunction
	ProcessWindowFunction window流
	ProcessAllWindowFunction
checkpoint

所有任务的状态在某个时间点的快照 这个时间点应该是所有任务都恰好处理完一个相同的输入数据都时候
从检查点恢复状态
1. 重启应用
2. 从checkpoint读取状态
checkpoint实现
1. barrier 遇到barrier的时候进行checkpoint状态保存 然后ACK jobManager,然后向下游广播 让下游执行checkpoint保存,对于barrier已经到达的分区,继续到达的数据会被缓存 其他分区继续处理等待barrier到达(barrier对齐)

savepoint
	跟checkpoint一样,但需要用户手动触发
状态一致性
	分类
		最多一次
		至少一次
		精确一次
	1. checkpoint
	2. 端到端 end to end 数据源-flink-sink一条线
		内部保证 checkpoint
		source端 数据不丢可重置数据偏移量
		sink端 保证幂等性(数据短暂不一致)/事务性
			事务性:
				实现思路:checkpoit完成对应端结果才写入sink系统
				实现方式:
					预写日志: 先把结果数据保存,等checkpoint完成通知时一次性写入sink系统,genericwriteaheadsink模版类
					两阶段提交: 每个checkpoint sink任务会启动一个事务,数据写入sink系统,但不提交,checkpoin通知时才提交事务,twophasecommitsinkfunction接口模版类
	3. exactly once
	4. flink kafka状态一致性 需要超时时间与checkpoint超时时间一致行 设置kafka数据隔离级别为rc
posted @ 2022-01-17 14:11  rudynan  阅读(65)  评论(0编辑  收藏  举报