SparkStreaming VS 单机

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能够实时处理，这种优势是明显的。