在Blink的流式任务中，State相关的操作通常都会成为整个任务的性能瓶颈。实时计算部-查询和优化团队开发了MiniBatch功能，大幅降低了State操作的开销，在今年的双11中，几乎所有适用的任务都启用了MiniBatch功能。

MiniBatch的一个典型场景-无限流上的GroupBy

在Blink-SQL中，通常会使用无限流的GroupBy来完成去重或者聚合计算，一个简单的例子如下

SELECT a, count(b) FROM dual GROUP BY a

标准实现的计算方式

MiniBatch实现的计算方式

StateBackend的Batch操作

从上图可知，开启MiniBatch之后要求State能支持Batch读写，目前默认的RocksDBStateBackend暂时不支持，Batch的读写实际是循环读写，而NiagaraStateBackend则支持真正的Batch读写。

用户的参数设置以及实现方案

目前用户在使用Bayes提交Blink-SQL任务时，可以设置以下两种触发逻辑

# 表示整个job允许的延迟(必须参数)
blink.miniBatch.allowLatencyMs=5000
# 单个batch的size(可选参数)
blink.miniBatch.size=1000

由于最终的SQL任务是一个DAG，需要在GroupBy节点上分配时间使得整个任务的在攒数据上的延迟不超过该值，目前时间分配的策略是简单地做均分，一个可能的例子如下

适用场景

当前MiniBatch支持Blink-SQL中的无限流GroupBy和无限流Proctime Over Window
如果Blink-SQL任务有热Key，则非常适合启用MiniBatch优化, 一些任务启用了MiniBatch，可以看出往下游发送的数据比原有少了约2个数量级

优化模型及后续

• 从上可以看出现有的时间分配策略只是给了可行但不是最优的方案，Key的分布更密集的节点不一定分配到了更多的时间。
• 完整MiniBatch的优化需要通过Key的分布，source节点输入速率， 节点处理能力等信息来计算每个节点的时间分配，在后续的版本中会结合HotUpdate功能做到动态调整，最大化发挥出MiniBatch的威力。