MapReduce In-Memory Big Data Hadoop Spark 巨量資料

資料分析新寵 開源Spark竄紅

2016-04-27
在巨量資料處理技術領域快速竄起的Spark,正是藉助In-Memory的處理技術,大幅加速反應速度,解決了MapReduce會耗用大量I/O的問題。
在IT的世界裡有一項鐵則,當資料愈靠近處理器(CPU),反應的速度就會愈快。現今許多解決方案也都開始倡導In-Memory,直接將資料存放在記憶體,以便進一步加快處理速度。而這樣的概念,如今也套用在巨量資料分析上。

近年來,在巨量資料處理技術領域快速竄起的Spark,正是藉助In-Memory的處理技術,大幅加速分析速度。2014年Sort Benchmark Competition(資料排序基準競賽)中,Databricks公司使用Spark,在207台的叢集中,以23分鐘的成績刷新紀錄。相較之下,2013年由Yahoo創下的記錄,是在2,100台的叢集中使用MapReduce,花費了72分鐘完成。這項成就也讓Spark一戰成名。

▲ IBM軟體事業處高級資訊工程師蘇友信指出,採用Spark可以避免MapReduce耗用大量I/O問題。
IBM軟體事業處高級資訊工程師蘇友信指出,Spark之所以受到矚目,主要是因為它能解決MapReduce會耗用大量I/O的問題。他解釋,MapReduce為了確保足夠的可靠性,所以會大量運用硬碟進行資料交換,而硬碟畢竟有其物理限制,最快不過15,000轉,因而導致效能不佳。

而另一方面,由於MapReduce的思維邏輯一定是Map–Reduce的流程,思維邏輯必須拆成片段,往往也讓程式人員很難在MapReduce上撰寫程式(Programming),這些限制也讓企業發現原來要走進MapReduce的世界,需要花很大的力氣學習新框架,並且在它的框架下改變程式風格(Style)。但是Spark不同之處在於,從資料分析到結果,中間的一連串邏輯可以用一支程式就寫完,邏輯的思考更為直覺,而且不會有I/O效能的問題。

儘管Spark在效率上取得極大的優勢,但至今仍無法完全取代MapReduce,蘇友信認為,這中間還存在舊包袱以及可行性的問題。一方面,在企業環境中,依然有很多舊的演算法必須執行在MapReduce上,而另一方面,從現狀來看,單一記憶體容量不可能高於硬碟,當資料量大到一個極致時,例如10PB時,企業勢必會考量可行性,「坦白說,在一個叢集中要部署這麼大量的記憶體並不容易,就算硬體架構做得到,成本也是一大考量。」

在架構層面上,Spark還有一個特點,它能獨立安裝在一台機器,或多台機器構成的叢集,簡單的說,Spark只負責運算,並不介意後端的儲存空間是一般的儲存設備或是Hadoop分散式檔案系統(HDFS)構成的空間,甚至安裝在一台電腦上也可以運行。

「只不過,由於Hadoop比Spark更早被推出,而企業也可能已經採購多台伺服器,將Spark架在Hadoop平台上,更能有效利用資源,特別是當企業需要把資料存放在NoSQL資料庫時,Hadoop上就有很好的生態系,例如HBase就可以存放資料。」但是他也建議,當企業要這麼做時,最好能夠擴充伺服器上的記憶體,「別忘了,Spark是藉助In-Memory的處理技術才能得到好的反應速度,如果不拉高記憶體容量,效果依然會不好。」


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!