我們在前幾回又談到了規模可擴充性、談到了雲端計算平臺,也說明了,我們透過雲端計算平臺可以獲得的好處之一,便是規模可擴充性,但這個規模可擴充性和雲端的關係並不是必然的,也就是說,上了「雲端」不意謂著必定具規模可擴充性有關。

想要得到規模可擴充性,可能可以自行在IaaS上建造基礎的設施,或是透過PaaS上提供的機制來達成。有了規模可擴充性,可以隨需要而投入更多的計算資源,使得服務的規模隨之擴大。

以「計算」來說,在過去幾年以來,Hadoop的MapReduce計算平臺獲得了廣泛採用,也便利了許多開發團隊在計算、處理大規模海量資料時的工作。不過,即使如此,MapReduce仍有些許值得改進之處,在前些日子,有個名為Spark的平臺問世,而在最近,Spark也邁進了正式產品的階段,這意謂著在MapReduce之外,開發者多了一個新的選擇,而Spark的出現,也正是瞄準了一些MapReduce在應用上的限制而來的。

在這一回中,就讓我們簡單、概略地介紹一下 Spark。

Hadoop出現勁敵,與之相容,而且執行速度更快

不意外的,Spark也是著名的Apache開放原始碼專案之一,就和Hadoop上的MapReduce一樣,同樣是個具規模可擴充性的分散式計算平臺,而且,試著在一些面向上,提供優於Hadoop MapReduce的方案。

在大規模資料的計算、分析上,排序作業的處理時間,一直是個重要的指標。而在著名的Daytona Gay Sort競賽中,針對102.5 TB的資料量排序,Hadoop MapReduce的記錄是以2,100個計算節點,在72分鐘內完成排序的計算工作。而Spark最近則以十分之一的206計算節點數,在23分鐘內即完成了 100TB 資料量的排序。

這意謂著,Spark可以做到用十分之一的計算節點數量,卻只用三分之一的時間,就完成了相同規模的計算工作。從這個結果,我們可以看出Spark在未來的應用潛力。

Spark是什麼呢?簡單來說,它是一個快速的群集計算系統,它具備了幾個特色,首先,它和Apache Hadoop相容,這意思是說,它支援了Hadoop所支援的儲存系統,包括HDFS、S3、……等等。這些儲存系統,可以說是當前在處理大規模資料時,開發者所慣以使用的儲存系統了,因此,Spark 同樣立足於這些儲存系統之上。

此外,重要的是,Spark在幾個面向上,改進了Hadoop用的傳統MapReduce。

Spark透過一個以分散式記憶體為主的計算模型,來大幅提高計算效率,因此在100TB級的資料排序上,Spark展現了它的計算高效率。另一方面,Spark 提供了豐富而且易用的API,這使得開發者在利用程表述計算邏輯時,得以獲得API層次的支持,如此,一來更容易撰寫程式,二來也能有效降低所需的程式碼行數。

而且,開發者可以利用三種程式語言來開發Spark 之上的應用程式,包括了Scala、Python,以及 Java,這代表著開發者可以視應用的情境,來決定使用何種語言來撰寫Spark程式,更能彈性的符合開發時的需求。

執行時,可在本地端、雲端,或是自身所管理的群集中

目前,運行Spark應用程式的方式,有三種選項,你可以選擇在本地端的機器上執行,這只需要引入 Spark 的程式庫就能辦到。

針對更大型規模的計算工作,本地機器的計算能力恐怕難以滿足,此時,你可以選擇將Spark程式送至AWS的EC2平臺上執行,這使得你可以權衡費用預算,以及需要完成計算工作的時間限制,來決定究竟投入多少EC2上的計算資源,來建立你的Spark 群集。

Spark當中,現在已經附上了將程式送至EC2執行的script,所以,你可以輕易在EC2上運行你所開發的Spark程式。當然,對於某些具有龐大資源的組織來說,他們可能會考慮不送至公開的雲端平臺上來執行他們的程式,因此,Spark也允許你透過諸如Mesos、YARN等來管理自有的群集,並且在自有的群集上運行Spark程式。

所採用的關鍵核心技術RDD,相當獨特

Spark的核心支柱,乃是一個名為RDD(Resilient Distributed Dataset)的分散式計算模型,而其諸多優勢,主要也是源自於RDD本身的特性。

所謂的RDD,乃是由AMPLab實驗室所提出的概念,類似一種分散式的記憶體。而且,RDD是一種可跨群集(cluster)被使用、可儲存於主記憶體中的immutable的物件集合。這裡所謂的immutable物件,乃是指在被產生之後,其狀態便無法被修改的物件。

在RDD之上,可以施加兩類型的操作,一種稱為「轉換(Transformation)」,另一種則為「動作(Action)」。其中,所謂的「轉換」,其操作結果為新的RDD,意即其作用在於將RDD再轉換生成另一個RDD。而所謂的「動作」,則是在RDD之上進行計算之後,將其結果返回 Spark 的驅動程序,或寫至檔案系統。

換句話說,「轉換」的結果,是在RDD的計算世界中,而「動作」的結果,則是輸出至此世界之外。所以,當我們產生RDD物件進到計算世界中之後,可以對其施加多次的「轉換」,當一旦於其上執行「動作」之後,就會從此計算世界中,得到真正可使用的計算結果了。

RDD本身有個Lineage機制,也就是說,它會維持每個RDD與其父代RDD reference之間的關聯,以及究竟是透過什麼操作,才由父代RDD得到該RDD的資訊。

正如你所知的,RDD透過「轉換」操作可以得出新的轉換,但Spark會延遲這個「轉換」動作的發生時間點,它並不會馬上執行,而是等到的確需要得出某個值時,才會基於所有的RDD關係來執行轉換。

也正因為有了Lineage機制,以及RDD本身先天的immutable特性,使得它具備了容錯的特性,即使特定節點損毀,儲存於其上的RDD也能重新計算得出,因而避免了特定節點損毀就無法運作的問題。

不論是「轉換」或是「動作」,基本上,都是以函數式(functional)的形式來表述。因此,正如前一回中所提到的,這種方式很適合「分而治之」的解題方式。

然而,和Hadoop MapReduce不同的是,Spark提供了遠多於map及reduce的操作,這使得開發者有更多的操作可以運用(即更豐富的 API),並且能夠用更簡潔的程式碼來表示計算邏輯。

以RDD這種以儲存在計憶體為主的分散式物件來做計算,避免了Hadoop MapReduce在工作任務間必須透過檔案系統來溝通的效率問題。大家都能輕易的明白,一旦涉及將計算資料儲存在檔案系統,就必須面臨磁碟I/O的緩慢效能,以及將資料做序列化、解序列化的計算負擔。Spark因為以RDD為基礎,得以帶來大幅度的計算效能改善。

從本文的簡單介紹中,不難理解,以RDD為核心的Spark,除了繼續在函數式的計算道路上繼續邁進,讓程式編寫更為容易,也讓運行效能大大提升,而這正是Spark能快速嶄露頭角的重要原因。

作者簡介


Advertisement

更多 iThome相關內容