微博机器学习平台应用 Flink 实现多流 join 来生成在线机器学习须要的样本。工夫窗口内的数据会被缓存到 state 里，且 state 拜访的提早通常决定了作业的性能。开源 Flink 的状态存储次要包含 RocksDB 和 Heap 两种，而在去年的 Flink Forward 大会上咱们理解到阿里云 VVP 产品自研了一款更高性能的状态存储插件 Gemini，并对其进行了测试和试用。

在本篇文章中咱们将对 RocksDB、Heap 和 Gemini 在雷同场景下进行压测，并对其资源耗费进行比照。测试的 Flink 内核版本为 1.10.0。

测试场景

咱们应用实在的样本拼接业务作为测试场景，通过将多个流的数据 union 后对指定 key 做聚合（keyby），在聚合函数里从各个流中获取相应的字段，并将须要的字段重新组合成一个新的对象存储到 value state 里。这里对每个新的对象都定义一个 timer，用 timer 性能来代替 TimeWindow，窗口完结时将数据发射到上游算子。应用 timer 性能的次要起因是 timer 更灵便，更不便用户自定义，在平台的实用性，可扩展性上体现更好。

MemoryStateBackend vs. RocksDBStateBackend

首先须要阐明的是，MemoryStateBackend 不倡议在线上应用，这里次要是通过测试量化一下应用 Heap 存储 state 的资源耗费。

咱们在测试中对 checkpoint 的配置如下：

CheckpointInterval:10 分钟
CheckpointingMode: EXACTLY_ONCE
CheckpointTimeout:3 分钟

同时对 RocksDB 减少了如下配置：

setCompressionType：LZ4_COMPRESSION
setTargetFileSizeBase：128 * 1024 * 1024
setMinWriteBufferNumberToMerge：3
setMaxWriteBufferNumber：4
setWriteBufferSize：1G
setBlockCacheSize：10G
setBlockSize：4 * 1024
setFilter：BloomFilter(10, false)

测试发现，雷同作业处理雷同的数据量时，应用 MemoryStateBackend 的作业吞吐和 RocksDB 相似（输出 qps 为 30 万，聚合后输入 qps 为 2 万），但所须要的内存 (taskmanager.heap.mb) 是 RocksDB 的 8 倍，对应的机器资源是 RocksDB 的 2 倍。

由此咱们得出以下论断：

• 应用 MemoryStateBackend 须要减少十分多的 Heap 空间用于存储窗口内的状态数据（样本），绝对于把数据放到磁盘的长处是解决性能十分好，但毛病很显著：因为 Java 对象在内存的存储效率不高，GB 级别的内存只能存储百兆级别的实在物理数据，所以会有很大的内存开销，且 JVM 大堆 GC 停机工夫绝对较高，影响作业整体稳固，另外遇到热点事件会有 OOM 危险。
• 应用 RocksDB 则须要较少的 Heap 空间即可，加大 Native 区域用于读缓存，联合 RocksDB 的高效磁盘读写策略依然有很好的性能体现。

GeminiStateBackend vs. RocksDBStateBackend 

能够通过如下形式，在 Ververica Platform 产品中指定应用 Gemini state backend:

state.backend=org.apache.flink.runtime.state.gemini.GeminiStateBackendFactory

同时咱们对 Gemini 进行了如下根底配置：

// 指定 Gemini 存储时的本地目录
kubernetes.taskmanager.replace-with-subdirs.conf-keys= state.backend.gemini.local.dir
state.backend.gemini.local.dir=/mnt/disk3/state,/mnt/disk5/state
// 指定 Gemini 的 page 压缩格局（page 是 Gemini 存储的最小物理单元）state.backend.gemini.compression.in.page=Lz4
// 指定 Gemini 容许应用的内存占比
state.backend.gemini.heap.rate=0.7
// 指定 Gemini 的单个存储文件大小
state.backend.gemini.log.structure.file.size=134217728
// 指定 Gemini 的工作线程数
state.backend.gemini.region.thread.num=8

机器配置

作业应用资源对应参数

内存相干参数

比照后果

Note：全量的样本拼接负载应用 16 台机器无奈齐全服务，因而咱们通过对数据进行不同比例的抽样来进行压测。当呈现反压时，咱们认为作业曾经达到性能瓶颈。

论断

由以上比照能够看出，在数据、作业处理逻辑、硬件配置等都雷同的前提下，应用 Gemini 胜利解决的数据量是 RocksDB 的 2.4 倍（17280 vs 7200 条 /s）。同时通过硬件资源耗费的比照可知，RocksDB 更快达到磁盘 IO 瓶颈，而 Gemini 则具备更高的内存和 CPU 利用率。

作者简介：

曹富强、晨馨，微博机器学习研发核心 - 高级零碎工程师。现负责微博机器学习平台数据计算 / 数据存储模块，次要波及实时计算 Flink、Storm、Spark Streaming，数据存储 Kafka、Redis，离线计算 Hive、Spark 等。目前专一于 Flink/Kafka/Redis 在微博机器学习场景的利用，为机器学习提供框架，技术，利用层面的反对。