由於單臺機器的計算能力和I/O能力已經無法滿足不斷增長的數據處理需求，越來越多的組織需要將應用擴展到更大規模的集羣上。但在集羣環境中，可編程性方面將遇到以下幾個挑戰：
- 並行編程問題；爲了將應用並行化，需要並行編程模型的支撐。
- 容錯和慢節點問題；當集羣規模相當大時，這個問題也是非常嚴重的。
- 多用戶共享集羣要求能具備彈性計算的能力，此外還要考慮干擾問題。
結果就是出現了很多編程模型，首先是MapReduce使數據批處理變得簡單通用同時能處理容錯。但很難處理其它類型的負載，於是就出現了各種各樣專用的編程模型：
- Pregel，用來解決迭代圖算法問題
- F1，處理SQL查詢
- MillWheel，持續流處理
- Storm，Impala，Piccolo，GraphLib...
我們認爲能夠設計一種通用的編程抽象，不僅僅能夠處理現在各種各樣的工作類型負載，還能處理未來新的應用類型。我們提出了RDD（Resilient Distributed Dataset，彈性分佈式數據集），一種高效的數據共享原語，從而大幅度提升了其通用性。圍繞RDD建立起來的框架相比於現有框架有以下幾種優勢：
- 一個運行時系統同時支持批處理，迭代，流處理計算，交互式查詢。這讓由這幾種計算模型組合而成的大量的新興應用成爲可能。同時在性能上比單獨的分佈式系統有更大的提升。
- 提供高強度的容錯和慢節點容忍方案。
- 相比於MapReduce，性能有100倍以上的提升。
- 支持多租戶，支持資源彈性調度。
圍繞RDD建立的Spark系統如圖1所示。
圖 1 Spark系統
專用系統的問題
- 重複工作，每個系統都需要考慮容錯和負載分佈等問題。
- 組合，不同專用系統的計算組合起來非常苦難
- 範圍有限，如果應用和系統不符，要麼修改應用，要麼發明新系統
- 資源共享，不同計算系統之間共享數據非常困難，因爲每個系統都假設自己擁有整個集羣的資源
- 管理維護，每個系統都需要重新學習其API，運行原理，部署方法等等...
基於這些問題，我們需要一個對集羣計算的統一抽象來提升集羣的可用性，性能，對多用戶的處理以及對複雜應用的支持。
彈性分佈式數據集（RDD）
仔細研究MapReduce不能支持其它不同類型的應用，就會發現問題都歸結爲一個，那就是在計算階段缺少高效的數據共享機制。RDD正是爲了解決這個問題而誕生的。以MapReduce和Dryad爲例，他們對都通過計算任務的有向無環圖（DAG）對計算進行結構化。除了將文件系統的數據做多份副本以外，這些模型並沒有提供存儲抽象。當發生故障時，需要通過網絡拷貝大量的數據。RDD是一個不使用數據複製的容錯分佈式內存抽象，通過對RDD創建圖的記憶，在遇到故障時，可以像批處理一樣重新恢復出丟失的數據。只要這些創建RDD的操作時粗粒度的，這種方法就比單純的數據複製高效很多。
爲什麼RDD的通用性這麼強？從表達能力的角度看，RDD可以模仿任意的分佈式系統。2.從系統的角度看，RDD給應用足夠的控制來優化集羣中可能造成計算瓶頸的資源。通過優化這些資源，基於RDD的應用性能上幾乎可以和專用系統媲美。
基於RDD的模型
- 迭代算法，RDD可以解決迭代算法問題
- 關係數據庫查詢，對應的是Shark SQL
- MapReduce，RDD可以支持MapReduce類型和Dryad類型的應用
- 流處理，基於RDD實現的流處理，稱之爲D-Stream
- 組合模型，基於RDD可以將以上幾種模型組合起來以構造更加複雜的應用。
圖2 和專用系統的比較
圖2爲基於Spark實現的各種編程模型和專用系統的比較。左側爲代碼量的比較，右側爲效率比較。可以看到，無論是表達能力還是運行效率RDD都達到了預期的目標。