Flink & Blink基准测试

测试背景
Flink & Blink在StandAlone / Yarn下,不同的State Backend下的吞吐量、计算延迟进行测试
版本信息
Flink版本:1.6.2
Blink版本:1.5.1
HDFS版本:2.7.3
Yarn版本:2.7.3
Kafka版本:1.1.0-2.11
集群:StandAlone单点
Slot数:12
JobManager:2048MB
TaskManager:3072MB
性能指标
吞吐量
计算延迟
测试方法
1.测试流程
数据生产:
使用Kafka Producer提供的生成数据脚本,按照指定配置生成数据(生成的数据内容相同)
默认Kafka Producer配置如下:
acks
1
数据大小(Byte)
200
数据推送:
生成数据后,向指定Kafka Topic发送数据
数据处理:
FLink端处理逻辑:统计每秒Windowed Word Count数量
指标统计:
Flink Metrics监控系统,监控Flink相关指标
2.默认参数
Flink默认为Exactly Once语义
Flink FileSystem Backend为HDFS
Flink CheckPoint时间为60秒
保证Kafka不是性能瓶颈,尽可能排除Kafka对测试结果的影响
除特殊标注外,测试数据量为5000万,TPS为50万
测试结果分析
1)Flink启用CheckPoint与不启用CheckPoint吞吐量对比
单位:条/秒

结论:对比两者数据可以看出,Flink不启用 CheckPoint吞吐量比启用CheckPoint吞吐量大1.075%,启用CheckPoint后,Flink吞吐量轻微下降

2)FLink在At Last Once语义与Exactly Once语义的吞吐量对比
单位:条/秒
结论:At Last Once语义吞吐量比Exactly Once语义的吞吐量大,但不明显
3FlinkExactly Once语义下File System Backend与RocksDB Backend吞吐量对比
单位:条/秒
 结论:RocksDB Backend的吞吐量比HDFS FileSystem Backend小很多,且FileSystem Backend的吞吐量大约是RocksDB Backend的3.94
(4)Flink在File System Backend下At last Once语义与Exactly Once语义的处理延迟对比
单位:毫秒
下图为两种语义下,延迟的平均数与中位数的对比

 结论:对比两者平均数与中位数以及曲线,可以看出,这两种语义在延迟上性能没有太大差异
(5)Flink在不同Backend下,CheckPoint大小、存储时间、CheckPoint存储速率
结论:通过表格发现,CheckPoint大小与Backend吞吐量有关,HDFS Backend吞吐量较大,则产生的CheckPoint比较大,RocksDB Backend吞吐量较小,则产生的CheckPoint比较小
(6)Blink与Flink 在StandAlone集群下吞吐量对比
保证相同条件下:5000万数据量,50万TPS,Flink与Blink测试图表如下图
单位:条/秒
结论:Flink与Blink吞吐量相差并不大
7)Flink on Yarn与Flink StandAlone吞吐量对比
数据量:2000万
TPS:20万
单位:条/秒
 结论:Flink on Yarn吞吐量高于Flink StandAlone,且任务的调度、资源分配由Yarn独立完成,不需要对资源进行预估和配置
8)Flink RocksDbBackend不同配置的吞吐量
RocksDbBackend提供了四个预设配置:
DEFAULT
默认
关闭fsync(关闭数据强制写入到磁盘)
SPINNING_DISK_OPTIMIZED
机械磁盘优化
设置并行度为4
关闭fsync(关闭数据强制写入到磁盘)
设置最大打开文件数量为-1
列族设置:
设置压缩模式为Level
设置动态压缩分级策略
SPINNING_DISK_OPTIMIZED_HIGH_MEM
机械磁盘优化
高内存消耗模式
设置并行度为4
关闭fsync(关闭数据强制写入到磁盘)
设置最大打开文件数量为-1
列族设置:
设置压缩模式为Level
设置动态压缩分级策略
设置目标文件大小256MB
设置最大字节集级别大小1024MB
设置buffer大小64MB
设置最小buffer合并数为3
设置最大buffer合并数为4
设置block缓存大小256MB
设置block块大小128KB
设置部落过滤器
FLASH_SSD_OPTIMIZED
SSD磁盘优化
设置并行度为4
关闭fsync(关闭数据强制写入到磁盘)
设置最大打开文件数量为-1
 
RocksdbBackend启用不同配置(Exactly Once语义),吞吐量如下图:
数据量:2000万
TPS:20万
单位:条/秒
结论:RocksdbBackend预设配置中,启用FLASH_SSD_OPTIMIZED配置Flink吞吐量远高于其他配置,其他配置下Flink吞吐量相差不明显,
启用SPINNING_DISK_OPTIMIZED_HIGH_MEM配置Flink吞吐量最低
9)Blink RocksDbBackend不同配置的吞吐量
同上,Blink RocksdbBackend启用不同配置(Exactly Once语义),吞吐量如下图:
数据量:2000万
TPS:20万
单位:条/秒
 
下图为Flink RocksdbBackend与Blink RocksdbBackend不同配置下吞吐量对比图表
数据量:2000万
TPS:20万
单位:条/秒
 结论:通过对比,发现在Blink RocksDbBackend下除FLASH_SSD_OPTIMIZED配置之外,其他配置吞吐量均比Flink小,且启用SPINNING_DISK_OPTIMIZED_HIGH_MEM配置Flink吞吐量最低
10)Flink & Blink RocksDbBackend计时器服务状态吞吐量大小
State.backend.rocksdb.timer–service.factory
设置RocksDB计时器服务状态实现的工厂,对于基于RocksDB的计时服务状态有两种:heap堆(默认),rocksdb
图表如下:
数据量:2000万
TPS:20万
单位:条/秒
 
结论:通过对比发现,无论是Flink还是Blink当计时器服务状态设置为heap时,吞吐量较大
11)Blink与Flink处理延迟对比
 
延迟中位数
延迟平均数
Flink
16
13.5
Blink
0
0

由表格可以看出,Blink处理几乎没有延迟


State Backend选择

Flink/Blink提供了Memory、FileSystem、RocksDB三种State Backends,通过之前测试结果,将FileSystemRocksDB Backends吞吐量汇总如下:
数据量:5000万

TPS:50万


Memory Backend
将数据保存在Java堆里,当CheckPoint时,会对State进行快照,然后将快照发送给JobManager,JobManager也将快照保存在Java堆中
默认情况下state状态大小限制为5M
适用:
1.本地开发和测试
2.State较少的Job
FileSystem Backend
将数据保持在TaskManager的内存中,当CheckPoint时,会将state写入文件,保存在文件系统/本地目录,少量的元数据保存在JobManager的内存中
适用:
1.状态比较大,窗口比较长,大的Key Value 状态
2.HA
优点:
1.将数据保存在TaskManager的内存中,吞吐量很大
缺点:
1.如果TaskManager内存不足,两个CheckPoint间隔中,数据过大,会出现OOM的状况,导致任务发生异常
2.写入HDFS时,会产生大量的网络IO,整体性能不稳定
RocksDB Backend
将数据保存在RocksDB中,RocksDB保存数据在TaskManager下的目录中,当CheckPoint时,整个数据库会被写入文件系统,少量的元数据会保存在JobManager的内存中
适用:
1.非常大的状态,长窗口,大的Key Value状态
2.HA
优点:
1.能够保存的State状态多少,取决于磁盘的大小
2.唯一支持增量CheckPoint的Backend
3.使用FLASH_SSD_OPTIMIZED配置吞吐量明显提高,可接近FileSystem Backend吞吐量
缺点:
1.由于依赖字节数据,支持的key和value大小,最大为2^31字节(2147483648字节,2048MB),对于适用Merge操作的状态,大小很可能超过了限制,下次获取会失败

2.RocksDB Backend将数据写入磁盘中,产生大量IO,吞吐量会受限


RocksDB Backend与File System Backend性能对比

 
高可用
状态保存
窗口大小
增量状态
快照
HDFS
支持
较长的状态
较长窗口
不支持
异步/同步
RocksDB
支持
非常大的状态
长窗口
支持
仅支持异步
下面通过两张性能监控图,来对比RocksDB Backend与File System Backend的性能消耗
下图为File System与RocksDB  Backend时发生的IO情况监控
蓝色线为读数据情况,红色为写数据情况
其中,14:24-14:42时间段为RocksDB Backend
14:53-15:03时间段为File System Backend
 
通过图中数据可以发现
14:24-14:42时间段中,RocksDB Backend发生频繁的写磁盘操作,将State保存到磁盘中
14:53-15:03时间段中, File System Backend发生的写操作并不频繁,内存使用率提高
下面的图表为网络流量,绿色为从外接收的流量,蓝色为向外发送的流量
 
其中,14:24-14:42时间段为RocksDB Backend
14:53-15:03时间段为File System Backend

由上图可以看到,在Flink任务过程中,除了向Kafka Topic发送数据产生的流量外,File System Backend会产生大量的网络IO,且网络IO远高于RocksDB Backend,导致整体性能状况不稳定


注意:

1.不同环境下,测试结果不相同,请以实际情况为准

2.测试结果可能存在误差,请谅解,请以实际情况为准



亲,看完了点个赞呀!!

赫墨拉

我是一个喜爱大数据的小菜鸡,这里是我分享我的成长和经历的博客

You may also like...

8 Responses

  1. 匿名说道:

  2. 匿名说道:

    您好!请问测试的workload是什么?latency的值是采用什么方法计算得到的 谢谢!

    • 赫墨拉说道:

      1.不知道您所说的workload是指的什么
      2.latency在flink的监控界面有直观的展现

      • 匿名说道:

        他得意思是你跑得benchmark是yahoo streaming的还是自定义的?另外,latency你的测试方法不太认可,我们更关注的是e2e的latency,flink自带的latency只是说明延迟的分布情况,不能认为是一个e2e的延迟!如有不同,可以继续交流!

        • 赫墨拉说道:

          我跑的benchmark是参照美团的flink与storm的benchmark
          关于latency的测试,我也没有找到很好的方法进行e2e的方式进行测试,只能通过这种方式进行,且测试场景有限,测试结果仅提供参考。
          不知您是否有更好的e2e latency的测试方法?

  3. yang说道:

    您好 请问,您对rocksDB和hdfs进行性能监控使用的是什么监控工具

  4. 匿名说道:

    请问使用FLASH_SSD_OPTIMIZED配置时,你的硬盘是SSD么。同理,另外3个配置时 硬盘是机械硬盘么

发表评论

电子邮件地址不会被公开。