Spark及其应用场景初探

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

假设Hadoop集群中有一个文件，每行有一个随机数，我们现在需要计算这些数据的方差 (假设中间过程不会溢出)
方差公式 

那么计算过程可以表示为

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的操作有两类Transformation和Action，Transformation是一个延时的过程，只有当具体的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