SparkStreaming VS 单机
由于要实现实时抠图,已经先后实现在hadoop和spark上的抠图,实时的话,还得靠streaming,要比较的话单机和streaming本来是不能比较的,但是刚刚出炉的数据,就先这么比较吧。
1. 单机
1.1 配置
操作系统:Windows 7 64bit
CPU:Intel(R) Core(TM)i7-2600 CPU @ 3.4GHz 3.70GHZ
内存: 6.00GB
IDE: VS2008
1.2 算法
抠图算法的代码是用C++写的,将输入的PNG图片进行抠图,输出PNG图片,运行在windows下,抠图的速度不是很快。
2. SparkStreaming
2.1 配置
操作系统:Centos Final 6.4 64bit
CPU:Intel(R) Core(TM)i7-2600 CPU @ 3.4GHz 3.70GHZ
内存: 6.00GB
Spark:0.9.0
Hadoop:2.3.0
Master:1个
测试Slave: 5个
2.2 算法
由于C++代码不能直接跑上Spark上,采用JNI的方式,调用windows下写好的C++代码,这样调用方式的速度是很慢的。在spark上用了broadcast的方式,将背景图片放在内存里,降低I/O的开销。
2.3 文件输入
采用hdfs的方式,将文件输入到hdfs上,然后由sparkStreaming自行读取,运行。
3. 实验结果
采用对同样的200张png图片进行抠图计时
3.1 单机
用了122.45秒。
3.2 Streaming
| 数量 | 时间(秒) | 读写时间 | count | lookup | collet |
1 | 200 | 22.343 | 14.3 | 6.134 | 0 | 1.9 |
2 | 200 | 20.958 | 13.2 | 6.058 | 0 | 1.7 |
3 | 200 | 27.479 | 20.4 | 5.418 | 0 | 1.661 |
4 | 100 | 11.6 | 7.9 | 3.7 | 0 | 0 |
5 | 200 | 23.752 | 18.344 | 5.408 | 0 | 0 |
6 | 200 | 21.375 | 16.4 | 4.975 | 0 | 0 |
7 | 200 | 20.278 | 18.7 | 0 | 1.578 | 0 |
8 | 200 | 20.31 | 18.7 | 0 | 1.61 | 0 |
9 | 200 | 21.4 | 19.6 | 0 | 0 | 1.8 |
4 结论
Streaming在测试的时候最大的delay是12秒左右,但是1、2秒之后,delay立马就变成了0.8秒左右了,我猜大概是上传到hdfs的时候,一下子涌入的数据量有点大,等慢慢处理完了,延迟就立马下降了。
尽管集群调用了JNI方式,降低了速度,但是由于背景图片放在内存的缘故,实验数据中有些是还没有优化的时候测的,200张图片抠图的时间基本在21秒左右,参与运算的节点数是5个,这样21*5=105秒,略微比单机快一点,处理速度大概是10张/秒,但是随着集群数量的增加,SparkStreaming能够实时处理,这种优势是明显的。