Flink:source+operator+sink
Source:
SourceFunction:open
CheckpointedFunction:initializeState、snapshotState
一般是source+checkpoint
FlinkKafkaConsumerBase:有四种启动模式:EARLIEST、LATEST、SPECIFIC_OFFSETS、GROUP_OFFSETS
EARLIEST:从最早的offset开始读取
LATEST:从最近的offset开始读取
SPECIFIC_OFFSETS:从指定的offset开始读取
GROUP_OFFSETS:从commit offset位置开始读取
分区策略:
每个算子都都需要考滤并行度和分区策略
Global:全局只选择第一个Channel
Shuffle:跨节点的随机选择一个Channel
Rebalance:跨节点的轮询
Rescale: 尽可能不跨节点的轮询,上游操作的每个分区与下游的分区存在固定的对接关系 ,不会跨TaskManager通信。本地化优先
BroadCast:广播给每一个Channel
Forward:并行度一样,同属一个subTasks,不会跨TaskManager通信。可组成operator chain
KeyGroup:key的hash方式
Custom:自定义
具体见: (94条消息) Flink-Streaming之StreamPartitioner_IWBS的博客-CSDN博客
Timer
KeyedProcessFunction的onTimer是指定期器触发时执行的逻辑
//注册定时期,设置Timer下次触发的时间(基于ProcessTime,Elment处理时间大于设定时间触发),底层用的是ScheduledThreadPoolExecutor.schedule,只会运行一次。多次使用需要多次注册
ctx.timeService.registerProcessingTimeTimer(水印大于设定时间触发)
//注册定时期,设置Timer下次触发的时间(基于EventTime)
ctx.timeService.registerEventTimeTimer
State
同一并行任务所处理的所有数据都可以访问到相同的状态
存储:FsStateBackend/HeapStateBackend/RocksDBStateBackend
分类:keyedState、OperatorState,Flink的Stateful Computations,所有State由RunTimeContext管理
OperatorState: ListState[T]、Union List state[T]、BroadCast State[T]
KeyedState:ValueState[T]、ListState[T]、MapState[K,V]、ReducingState[T]、AggregatingState[I,O]
扩容Flink算子并 行度(这个是重点 KeyedState与OperatorState的分配策略不一样)
OperatorState采用partition数量取模的方式
keyedState采用key-group的方式(Range策略),类似Redis的slot算法,key-group与partition之间映射,key-->key-group--->partition(用于解决修改并行度减少数据迁移)
其中key-group数量要大于maxParallelism。调整maxParallelism会导致整个state的分布调整
使用State需要打开Checkpoint,不建议Checkpoint时间设置过短,会导致分布式文件的压力过大(默认是10min),主要是对job master的压力过大,可能会导致的分布式文件的创建速度超过单点Job master的删除速度,这样会影响整个Flink 集群的运行速度,因为作业处理的Record与checkpoint存在互斥锁
Trigger
决定窗口开始执行的条件,基于数据、水印触发窗口,可自定义条件
Watermark
解决数据乱序方案,不会小于或者等于水印时间戳的事件(即表示后面来的数据EventTime > 水印时间戳),
Event time 场景下的Window Trigger机制:
Window的触发机制是先按照自然时间对Window进行划分,如果window的大小为3S,那么1min会被 划分为20个窗品
Watermark> Window_end_time才会触发
延迟数据处理:1、丢弃。2、指定allowedLateness来处理延迟数据,Watermark<Window_end_time + allowedLateness触发窗口
Kafka
逻辑结构:topic---->partition, consumer、producer,borker(Leader、Follower)
脑裂:partition的broker多副本机制使用Leader、Followerer,ISR列表+Controller epoch机制解决脑裂
End to End
TwoPhaseCommitSinkFunction,端到端的数据一致性的保证,采用二阶段提交方案
Flink容量规划与评估
需要考虑的指标:1、数据源TPS 2、每条记录的大小 3、状态更新的数据以及后端的访问模式和TPS
1、记算每台机器的带宽
2、(网格连接),计算每台机器的输出带宽
3、source、checkpoint、state、shuffle ,基于QPS、keys数量、报文大小来计算
How To Size Your Apache Flink® Cluster: A Back-of-the-Envelope Calculation
背压(BackPressure):
自动反压的原理就是动态反馈速率,以达到速率的自动控制
spark 采用PID做为背压算法,速率更新到blockGenerator从而控制批次的数据生成, 控制kakfa取数速率
1.5版本以前采用TCP 滑动窗口背压
TCP 流控是基于滑动窗口的机制,滑动窗口大小=待处理的消息大小+剩余的空大小,比如窗口size为5,其中有3个消息待处理,那么窗口会向前滑动两个消息大小的空间。同时把信息反馈给发送 方。以达到一个流控的效果
发送方:
Local Buffer(sub Task独有缓存)-->Network Buffer Pool(TM下所有sub Taks 共享)---->Off heap Memory (Netty 缓存)---->Socket buffer
接收方:
Socket Buffer--->off heap Memory(Netty缓存, 会导致Netty AutoRead关闭)---->Network buffer Pool--->Local Buffer
问题:
1、其余sub task也会阻塞(同一个TM会复用同一个Socket)
2、checkpoint barrier也无法发出,导致下游执行的checkpoint 延迟增加
1.5以后版本采用Credit-based Flow Control,基于信用点的流量控制
独占缓存、浮动缓存