Spark及其应用场景初探

最近老大让用Spark做一个ETL项目,搭建了一套只有三个结点Standalone模式的Spark集群做测试,基础数据量大概8000W左右。看了官方文档,Spark确实在Map-Reduce上提升了很多,可是官方明确提出了在Interactive Data 方面性能提升最大。但是做ETL的数据之间是平行结构,没有任何交互,数据处理完直接就推送走了,也不用做任何缓存,因此完全体现不出来Spark的优势。具体可以用下面这个例子来说,

假设Hadoop集群中有一个文件,每行有一个随机数,我们现在需要计算这些数据的方差 (假设中间过程不会溢出)
方差公式 Spark及其应用场景初探

那么计算过程可以表示为

var file = sc.textFile("hdfs://dataset.txt")
file.persist()
var length = file.count()
var sum = file.reduce((a, b) => a+b)
var sqsum = file.map(line => line * line).reduce( (a,b) => a+b )
var variance = sqsum / length / - sum * sum / length / length

这个过程很简单,但是可以体现出这个交互的过程。file 是一个RDD,这个例子有且仅有一个RDD。Spark中对RDD的操作有两类TransformationActionTransformation是一个延时的过程,只有当具体的Action应用时,才会对具体的数据做运算。Spark的容错机制也正是根据了Transformation对RDD进行了Lineage的推算,即使在某个结点在某种状态下数据丢失,也可以根据记录的Transformations推算出当前请求的RDD数据集。 扯远了,还是看上面这个例子,

var file = sc.textFile("hdfs://dataset.txt")

这里不会立即去集群读取这个文件,而是会延迟到后面具体的Action例如count()时,才会遍历文件。获取所有数据的长度,需要读取一次dataset.txt这个文件,集群中遍历这个文件虽然很快,但是下一次在求和与平方和时,又需要遍历两次次这个文件,那么差别就来了

map - reduce 程序是需要三次IO,集群需要从HDFS上三次获取这个文件进行遍历
Spark 能够将 file 这个RDD缓存在集群的共享内存中,那么在处理时实际上只有一次IO,另外两次遍历直接从内存读取

这个例子很简单,那么我们在做数据挖掘或者迭代运算时,这样的交互行为会很多,需要缓存的中间数据集也会有很多,那么在map-reduce过程中,由于没有内存缓存的机制,只有将中间状态缓存到HDFS中,而Spark通过缓存避免了这些IO,效率就提升了。

参考文档

[1] programming-guide
[2] An Architecture for Fast and General Data Processing on Large Clusters

上一篇:2016年12月5日 星期一 --出埃及记 Exodus 20:26


下一篇:C# winform 安装服务