Flink SQL 核心解密 —— 提升吞吐的利器 MicroBatch

  • 时间:
  • 浏览:1
  • 来源:彩神3D_神彩3D官方

MicroBatch 的五个 多典型应用场景只是 Group Aggregate。同类简单的求和例子:

另外,仍然是上述的性能测试对比,还都可以发现运行稳定后 MicroBatch 的队列使用率平均值在 3000% 以下,而 MiniBatch 基本是一个劲地处队列满载下。说明 MicroBatch 比 MiniBatch 更加稳定,更不容易引起反压。

MicroBatch 的提出只是为了避免 MiniBatch 遇到的上述间题。MicroBatch 引入了 watermark 来控制聚合节点的定时触发功能,用 watermark 作为特殊事件插入数据流中将数据流切分成相等时间间隔的五个 多个批次。实现原理如下所示:

MicroBatch 目前只支持无限流的聚合和 Join,暂不支持 Window Aggregate。所很久续 Window Aggregate 会重点支持 MicroBatch 策略,以提升吞吐性能。此人 面,MicroBatch 的内存会考虑使用二进制的数据内部人员管理起来,提升内存的利用率和减轻 GC 的影响。

MiniBatch 攒批策略在内存维度是通过统计输入条数,当输入的条数超过用户配置的 blink.miniBatch.size 时,就会触发批次以避免 OOM。因此 size 参数并都在很好评估,一方面当 size 配的过大,将会会抛妻弃子保护内存的作用;而当 size 配的太小,又会意味攒批波特率降低。

因此这种策略有以下十几个 间题:

MicroBatch 会在数据源很久插入五个 多 MicroBatchAssigner 的节点,用来定时发送 watermark,其间隔是用户配置的延时参数,如10s。这麼每隔10s,不管数据源有这麼数据,都在发五个 多当前系统时间戳的 watermark 下去。五个 多节点的当前 watermark 取自所有 channel 的最小 watermark 值,全都 当聚合节点的 watermark 值前进时,也就意味攒齐了上游的五个 多批次,我们我们我们就还都可以触发这种批次了。避免完这种批次后,还都可以将当前 watermark 广播给下游所有 task。当下游 task 收齐上游 watermark 时,也会触发批次。很久批次的触发会从上游到下游逐级触发。

数据抖动的本质意味是 retract 和 accumulate 消息是五个 多事务中的五个 多操作,因此这五个 多操作的里面结果被用户看一遍了,也只是传统数据库 ACID 中的隔离性(I) 中最弱的 READ UNCOMMITTED 的事务保障。要从根本上避免这种间题的思路是,如何原子地避免 retract & accumulate 的消息。如上文所述的 MicroBatch 策略,借助 watermark 划批,watermark 我太多 插在 retract & accumulate 里面,这麼 watermark 只是事务的纯天然分界。按照 watermark 来避免批次还都可以达到原子避免 retract & accumulate 的目的。从而避免抖动间题。

当第一层count distinct的结果从3000上升到101时,它会发出 -3000, +101 的两条消息。当第二层的 SUM 会依次收到这两条消息并避免,假设此时 SUM 值是 900,这麼在避免 -3000 时,会先发出 30000 的结果值,因此避免 +101 时,再发出 901 的结果值。从用户端的感受只是买家数从 900 降到了 30000 又上升到了 901,我们我们我们称之为数据抖动。而理论上买家数只应该只增不减的,全都 我们我们我们也一个劲在思考如何避免这种间题。

这里将 watermark 作为划分批次的特殊事件是很有意思的其他。Watermark 是五个 多非常强大的工具,一般我们我们我们用来衡量业务时间的进度,避免业务时间乱序的间题。但确实换五个 多维度,它也还都可以用来衡量全局系统时间的进度,从而非常巧妙地避免数据划批的间题。

MicroBatch 在内存维度目前仍然与 MiniBatch 一样,使用 size 参数来控制条数。因此将来会基于内存管理,将缓存的数据存于管理好的内存块中(BytesHashMap),从而减少 Java 对象的空间成本,减少 GC 的压力和避免 OOM。

攒批策略一般分成五个 多维度,五个 多是延时,五个 多是内存。延时即控制多久攒一次批,这也是用来权衡吞吐和延迟的重要参数。内存即为了避免瞬间 TPS 这麼来太多意味内存无法存下缓存的数据,避免造成 Full GC 和 OOM。下面会分别介绍旧版 MiniBatch 和 新版 MicroBatch 在这五个 多维度上的区别。

因此与 MiniBatch 策略相比,MicroBatch 具有以下优点:

MicroBatch默认关闭,开启依据:

所谓数据抖动间题是指,两层 AGG 时,第一层 AGG 发出的更新消息会拆成两条独立的消息被下游消费,分别是retract 消息和 accumulate 消息。而当第二层 AGG 消费这两条消息时也会发出两条消息。很久端看一遍只是数据会有抖动的间题。同类下面的例子,统计买家数,这里做了两层打散,第一层先做 UV 统计,第二级做SUM。

很久我们我们我们在 Flink SQL 中支持了 MiniBatch, 在支持高吞吐场景发挥了重要作用。今年我们我们我们在 Flink SQL 性能优化中一项重要的改进只是升级了微批模型,我们我们我们称之为 MicroBatch,也叫 MiniBatch2.0。

当开启 MicroBatch 时,对于缓存下来的 N 条数据并肩触发,同 key 的数据只会读写清况 一次。同类上图缓存的 4 条 A 的记录,只会对清况 读写各一次。全都 当数据的 key 的重复率越大,攒批的大小越大,这麼对清况 的访问会越少,得到的吞吐量越高。

MicroBatch 是使用一定的延迟来换取多量吞吐的策略,将会用户有超低延迟的要求的话,不建议开启微批避免。MicroBatch 目前对于无限流的聚合、Join 都在显著的性能提升,全都 建议开启。将会遇到了上述的数据抖动间题,也建议开启。

MiniBatch 攒批策略的延时维度是通过在每个聚合节点注册单独的定时器来实现,时间分配策略采用简单的均分。比如有五个 多 aggregate 节点,用户配置 10s 的 MiniBatch,这麼每个节点会分配2.5s,同类下图所示:

微批的核心思想只是缓存一小批数据,在访问清况 清况 时,多个同 key 的数据就只还都可以地处一次清况 的操作。当批次内数据的 key 重复率较大时,能显著降低对清况 的访问频次,从而大幅提高吞吐。MicroBatch 和 MiniBatch 的核心机制是一样的,只是攒批,因此触发计算。只是攒批策略不太一样。我们我们我们先讲解触发计算时是如何节省清况 访问频次的。

在设计和实现 Flink 的流计算算子时,我们我们我们一般会把“面向清况 编程”作为第一准则。将会在流计算中,为了保证清况 (State)的一致性,还都可以将清况 数据存储在清况 后端(StateBackend),由框架来做分布式快照。而目前主要使用的RocksDB,Niagara清况 后端都在在每次read和write操作时地处序列化和反序列化操作,甚至是磁盘的 I/O 操作。因此清况 的相关操作通常都在成为整个任务的性能瓶颈,清况 的数据内部人员设计以及对清况 的每一次访问都还都可以有点儿注意。

我们我们我们利用五个 多 DAU 作业进行了性能测试对比,在相同的 allowLatency(6秒)配置的清况 下,MicroBatch 能得到更高的吞吐,因此还能得到与 MiniBatch 相同的端到端延迟!

如上图所示,当未开启 MicroBatch 时,Aggregate 的避免模式是每来根小数据,查询一次清况 ,进行聚合计算,因此写入一次清况 。当有 N 条数据时,还都可以操作 2*N 次清况 。