flink sql

for system_time as of 时间点

for system_time from ... to 时间段查询

for system_time between ... and ..

。。。。。。FOR SYSTEM_TIME AS OF otime语法的含义 - 钱塘江畔 - 博客园 

Demo：基于 Flink SQL 构建流式应用 | Jark's Blog

基于Flink SQL构建流式应用 - 王晓天 - 博客园

flink容量规划

2021-09-22 00:01:48

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的博客-优快云博客

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，基于信用点的流量控制

        独占缓存、浮动缓存