(1)復(fù)雜的批量數(shù)據(jù)處理，通常的時間跨度在數(shù)十分鐘到數(shù)小時之間。
(2)基于歷史數(shù)據(jù)的交互式查詢，通常的時間跨度在數(shù)十秒到數(shù)分鐘之間。
(3)基于實(shí)時數(shù)據(jù)流的數(shù)據(jù)處理，通常的時間跨度在數(shù)百毫秒到數(shù)秒之間。
目前已有很多相對成熟的開源和商業(yè)軟件來處理以上三種情景 ：第一種業(yè)務(wù)，可以利用 MapReduce 來進(jìn)行批量數(shù)據(jù)處理 ;第二種業(yè)務(wù)，可以用 Impala 來進(jìn)行交互式查詢 ;對于第三種流式數(shù)據(jù)處理，可以想到專業(yè)的流數(shù)據(jù)處理工具 Storm。但是這里有一個很重要的問題 ：對于大多數(shù)互聯(lián)網(wǎng)公司來說，一般會同時遇到以上三種情景，如果采用不同的處理技術(shù)來面對這三種情景，那么這三種情景的輸入/ 輸出數(shù)據(jù)無法無縫共享，它們之間可能需要進(jìn)行格式轉(zhuǎn)換，并且每個開源軟件都需要一支開發(fā)和維護(hù)團(tuán)隊(duì)，從而提高了成本。另外一個不便之處就是，在同一個集群中對各個系統(tǒng)協(xié)調(diào)資源分配比較困難。
那么，有沒有一種軟件可以同時處理以上三種情景呢? Spark 就可以，或者說有這樣的潛力。Spark 同時支持復(fù)雜的批處理、互操作和流計(jì)算，而且兼容支持HDFS 和 Amazon S3 等分布式文件系統(tǒng)，可以部署在 YARN 和 Mesos 等流行的集群資源管理器上。
從 Spark 的設(shè)計(jì)理念(基于內(nèi)存的迭代計(jì)算框架)出發(fā)，其最適合有迭代運(yùn)算的或者需要多次操作特定數(shù)據(jù)集的應(yīng)用場合。并且迭代次數(shù)越多，讀取的數(shù)據(jù)量越大，Spark 的應(yīng)用效果就越明顯。因此，對于機(jī)器學(xué)習(xí)之類的“迭代式”應(yīng)用，Spark 可謂拿手好戲，要比 Hadoop MapReduce 快數(shù)十倍。另外，Spark Streaming因?yàn)閮?nèi)存存儲中間數(shù)據(jù)的特性，處理速度非常快，也可以應(yīng)用于需要實(shí)時處理大數(shù)據(jù)的場合。
當(dāng)然，Spark 也有不適用的場合。對于那種異步細(xì)粒度更新狀態(tài)的應(yīng)用，例如 Web 服務(wù)的存儲或增量的 Web 爬蟲和索引，也就是對于那種增量修改的應(yīng)用模型不適合。Spark 也不適合做超級大的數(shù)據(jù)量的處理，這里所說的“超級大”是相對于這個集群的內(nèi)存容量而言的，因?yàn)?Spark 要將數(shù)據(jù)存儲在內(nèi)存中。一般來說，10TB 以上(單次分析)的數(shù)據(jù)就可以算是“超級大”的數(shù)據(jù)了。
一般來說，對于中小企業(yè)的數(shù)據(jù)中心而言，在單次計(jì)算的數(shù)據(jù)量不大的情況下，Spark 都是很好的選擇。另外，Spark 也不適合應(yīng)用于混合的云計(jì)算平臺，因?yàn)榛旌系脑朴?jì)算平臺的網(wǎng)絡(luò)傳輸是很大的問題，即便有專屬的寬帶在云端 Cluster 和本地 Cluster 之間傳輸數(shù)據(jù)，相比內(nèi)存讀取速度來說，依然不抵。