Flink使用RocksDB和Gemini的性能对比实验分析是怎样的

今天就跟大家聊聊有关Flink使用RocksDB 和Gemini 的性能对比实验分析是怎样的,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

目前创新互联建站已为1000+的企业提供了网站建设、域名、虚拟主机成都网站托管、企业网站设计、明溪网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。

摘要:我们将对 RocksDB、Heap 和 Gemini 在相同场景下进行压测,并对其资源消耗进行对比。测试的 Flink 内核版本为 1.10.0。

微博机器学习平台使用 Flink 实现多流 join 来生成在线机器学习需要的样本。时间窗口内的数据会被缓存到 state 里,且 state 访问的延迟通常决定了作业的性能。开源 Flink 的状态存储主要包括 RocksDB 和 Heap 两种,而在去年的 Flink Forward 大会上我们了解到阿里云 VVP 产品自研了一款更高性能的状态存储插件 Gemini,并对其进行了测试和试用。

测试场景


我们使用真实的样本拼接业务作为测试场景,通过将多个流的数据union后对指定key做聚合(keyby),在聚合函数里从各个流中获取相应的字段,并将需要的字段重新组合成一个新的对象存储到 value state 里。这里对每个新的对象都定义一个 timer,用 timer 功能来替代 TimeWindow,窗口结束时将数据发射到下游算子。使用 timer 功能的主要原因是 timer 更灵活,更方便用户自定义,在平台的实用性,可扩展性上表现更好。
MemoryStateBackend vs. RocksDBStateBackend

首先需要说明的是,MemoryStateBackend 不建议在线上使用,这里主要是通过测试量化一下使用 Heap 存储 state 的资源消耗。
 
我们在测试中对 checkpoint 的配置如下:

CheckpointInterval:10分钟CheckpointingMode: EXACTLY_ONCECheckpointTimeout:3分钟

同时对 RocksDB 增加了如下配置:

setCompressionType:LZ4_COMPRESSIONsetTargetFileSizeBase:128 * 1024 * 1024setMinWriteBufferNumberToMerge:3setMaxWriteBufferNumber:4setWriteBufferSize:1GsetBlockCacheSize:10GsetBlockSize:4 * 1024setFilter:BloomFilter(10, false)

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

Flink使用RocksDB 和Gemini 的性能对比实验分析是怎样的


由此我们得出以下结论:

  • 使用 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.dirstate.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

机器配置

Flink使用RocksDB 和Gemini 的性能对比实验分析是怎样的


作业使用资源对应参数

Flink使用RocksDB 和Gemini 的性能对比实验分析是怎样的


内存相关参数

Flink使用RocksDB 和Gemini 的性能对比实验分析是怎样的


对比结果

Flink使用RocksDB 和Gemini 的性能对比实验分析是怎样的

Note:全量的样本拼接负载使用 16 台机器无法完全服务,因此我们通过对数据进行不同比例的抽样来进行压测。当出现反压时,我们认为作业已经达到性能瓶颈。

由以上对比可以看出,在数据、作业处理逻辑、硬件配置等都相同的前提下,使用 Gemini 成功处理的数据量是 RocksDB 的 2.4 倍(17280 vs 7200 条/s)。同时通过硬件资源消耗的对比可知,RocksDB 更快达到磁盘 IO 瓶颈,而 Gemini 则具备更高的内存和 CPU 利用率。

看完上述内容,你们对Flink使用RocksDB 和Gemini 的性能对比实验分析是怎样的有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。


网页题目:Flink使用RocksDB和Gemini的性能对比实验分析是怎样的
文章源于:http://pwwzsj.com/article/pddcie.html