當一個計算任務過於複雜不能被一臺伺服器獨立完成的時候，我們就需要分散式計算。分散式計算技術將一個大型任務切分為多個更小的任務，用多臺計算機透過網路組裝起來後，將每個小任務交給一些伺服器來獨立完成，最終完成這個複雜的計算任務。本篇我們介紹兩個經典的計算框架MapReduce和Spark。
MapReduce是第一個比較成功的計算引擎，主要用於資料批處理。由於企業的大資料業務多是圍繞結構化資料等價值密度更高的資料展開，所有的大資料公司開始在大資料平臺上打造SQL引擎或分佈資料庫。2012年開始到隨後兩年中出現20多個基於Hadoop的SQL引擎，以解決結構化資料問題。
MapReduce框架是Hadoop技術的核心，它的出現是計算模式歷史上的一個重大事件，在此之前行業內大多是透過MPP(Massive Parallel Programming)的方式來增強系統的計算能力，一般都是透過複雜而昂貴的硬體來加速計算，如高效能運算機和資料庫一體機等。而MapReduce則是透過分散式計算，只需要廉價的硬體就可以實現可擴充套件的、高並行的計算能力。一個MapReduce程式會包含一個Map過程和一個Reduce過程。在Map過程中，輸入為(Key, Value)資料對，主要做過濾、轉換、排序等資料操作，並將所有Key值相同的Value值組合起來；而在Reduce過程中，解析Map階段生成的(Key, list(value))資料，並對資料做聚合、關聯等操作，生成最後的資料結果。每個worker只處理一個file split，而Map和Reduce過程之間透過硬碟進行資料交換，如果出現任何錯誤，worker會從上個階段的磁碟資料開始重新執行相關的任務，保證系統的容錯性和魯棒性。
圖片來源於《MapReduce: simplified data processing on large clusters》
MapReduce在設計上並不是為了高效能，而是為了更好的彈性和可擴充套件性。在同等規模的硬體以及同等量級的資料上，與一些基於關聯式資料庫的MPP資料庫相比，MapReduce的分析效能一般會慢一個數量級，不過MapReduce可以支援的叢集規模和資料量級要高几個數量級。在2014年Jeff Dean提出MapReduce的論文裡提及的相關叢集已經是1800臺伺服器的規模，而現在放眼國內，單個叢集超過幾千個伺服器、處理資料量達到PB級別的叢集有超過數百個。
除了可以支援PB級別的彈性化資料計算外，MapReduce還有幾個很好的架構特性，這些特性也都被後來的一些計算框架（如Spark等）有效地繼承。第一個特性是簡化的程式設計介面設計，與之前的MPP領域流行的MPI等程式設計介面不同，MapReduce不需要開發者自己處理並行度、資料分佈策略等複雜問題，而是需要關注於實現Map和Reduce對應的業務邏輯，從而大大簡化開發過程。另外MapReduce的計算基於key-value的資料對，value域可以包含各種型別的資料，如結構化資料或圖片、檔案類非結構化資料，因此MapReduce計算框架能夠很好地支援非結構化資料的處理。
此外，在容錯性方面，由於MapReduce的分散式架構設計，在設計之初即設定了硬體故障的常態性，因此其計算模型設計了大量的容錯邏輯，如任務心跳、重試、故障檢測、重分佈、任務黑/灰名單、磁碟故障處理等機制，覆蓋了從JobTracker、TaskTracker到Job、Task和Record級別的從大到小各個層級的故障處理，從而保證了計算框架的良好容錯能力。
而隨著企業資料分析類需求的逐漸深入，MapReduce計算框架的架構問題從2010年後也逐漸暴露出來。首先就是其效能問題，無論是框架啟動開銷（一般要數分鐘），還是任務本身的計算效能都不足，尤其是在處理中小資料量級的資料任務上與資料庫相差太大，不能用於互動式資料分析場景。有意思的是，從2010年開始，學術界有大量的論文研究如何最佳化MapReduce效能，也有多個開源框架誕生出來，但都未能實現效能在量級上的提升，因此也逐漸淡出了歷史。第二個重要問題是不能處理實時類資料，因此不能滿足一些快速發展的網際網路場景需求，如實時推薦、實時排程、準實時分析等。後續Spark框架的出現就優先解決了這幾個問題，框架啟動開銷降到2秒以內，基於記憶體和DAG的計算模式有效的減少了資料shuffle落磁碟的IO和子過程數量，實現了效能的數量級上的提升。隨著更好的計算框架出現，MapReduce逐漸退出了主流應用場景，不過其作為分散式計算的第一代技術架構，其在計算技術演進的過程中發揮了重要的歷史價值。
— Spark計算框架
—
隨著大量的企業開始透過
Hadoop來構建企業應用，MapReduce的效能慢的問題逐漸成為瓶頸，只能用於離線的資料處理，而不能用於對效能要求高的計算場景，如線上互動式分析、實時分析等。在此背景下，Spark計算模型誕生了。雖然本質上Spark仍然是一個MapReduce的計算模式，但是有幾個核心的創新使得Spark的效能比MapReduce快一個數量級以上。第一是資料儘量透過記憶體進行互動，相比較基於磁碟的交換
，
能夠避免
IO帶來的效能問題；第二採用Lazy evaluation的計算模型和基於DAG（Directed Acyclic Graph, 有向無環圖）的執行模式，可以生成更好的執行計劃。此外，透過有效的check pointing機制可以實現良好的容錯
，避免記憶體失效帶來的計算問題。
Spark 實現了一種分散式的記憶體抽象，稱為彈性分散式資料集(RDD，Resilient Distributed Datasets)。
它支援基於工作集的應用，同時具有資料流模型的特點 自動容錯、位置感知排程和可伸縮性。
RDD 允許使用者在執行多個查詢時顯式地將工作集快取在記憶體中，後續的查詢能夠重用工作集，這極大地提升了查詢速度。
RDD提供了一種高度受限的共享記憶體模型，即RDD是隻讀的記錄分割槽的集合，只能透過在其他RDD執行確定的轉換操作(如map、join和 groupBy) 而建立，然而這些限制使得實現容錯的開銷很低。
與分散式共享記憶體系統需要付出高昂代價的檢查點和回滾機制不同，RDD透過Lineage來重建丟失的分割槽一個RDD中包含了如何從其他 RDD衍生所必需的相關資訊，從而不需要檢查點操作就可以重構丟失的資料分割槽。
除了Spark C
ore API以外，Spark還包含幾個主要的元件來提供大資料分析和資料探勘的能力，主要包括Spark SQL、Spark Streaming、Spark MLLib。
Spark SQL是基於Spark引擎提供使用SQL來做統計分析的模組，因為有較好的SQL相容性，對普通資料開發者使用比較簡單，因此在使用者中使用比較廣泛。SparkSQL充分吸收了Hive等專案的架構優缺點，透過有效的模組化以及與Hive後設資料模組的相容，使得開發者可以直接用Spark SQL來分析Hive中的資料表，而比直接使用Hive做分析能夠大幅度提高效能。此後，Spark SQL陸續增加了對JSON等各種外部資料來源的支援，並提供了一個標準化的資料來源API。資料來源API給Spark SQL提供了訪問結構化資料的可插拔機制。各種資料來源有了簡便的途徑去進行資料轉換並接入到Spark平臺進行計算，此外由API提供的最佳化器，在大多數情況下，可以將過濾和列修剪都下推到資料來源，從而極大地減少了待處理的資料量，能夠顯著提高Spark的工作效率。透過這些架構上的創新，Spark SQL可以有效地分析多樣化的資料，包括Hadoop、Alluxio、各種雲端儲存，以及一些外部資料庫。
Spark Streaming 基於 Spark Core 實現了可擴充套件、高吞吐和容錯的實時資料流處理。Spark Streaming 是將流式計算分解成一系列短小的批處理作業。這裡的批處理引擎是Spark，也就是把Spark Streaming的輸入資料按照micro batch size(如500毫秒)分成一段一段的資料(Discretized Stream)，每一段資料都轉換成 Spark中RDD(Resilient Distributed Dataset)，然後將Spark Streaming中對DStream的轉換操作變為針對Spark中對RDD的轉換操作，將RDD經過操作變成中間結果儲存在記憶體中。
由於Spark Streaming採用了微批的處理方式，系統本身的吞吐量比較高，但是從應用的視角來看，資料從發生到計算結構的延時在500毫秒甚至以上，如果一個複雜邏輯涉及到多個流上的複雜運算，這個延時將會進一步放大，因此對一些延時敏感度比較高的應用，Spark Streaming的延時過高問題是非常嚴重的架構問題。Spark社群也在積極的解決相關的問題，從Spark 2.x版本開始推出了Structured Streaming，最本質的區別是不再將資料按照batch來處理，而是每個接收到的資料都會觸發計算操作並追加到Data Stream中，緊接著新追加的記錄就會被相應的流應用處理並更新到結果表中，如下圖所示。
由於Structured Streaming有效地降低了實時計算的延時，此外又是直接基於Dataframe和Dataset API進行了封裝，從而方便與Spark SQL以及MLlib對接，因此很快便取代了Spark Streaming成為Spark主要的實時計算方案。此後，社群很快增加了對資料亂序問題的處理、透過checkpoint機制保證At least once語義等關鍵的流計算功能要求，逐步貼近了生產需求。
MLlib是Spark對常用的機器學習演算法的分散式實現，同時包括資料型別、數學統計計算庫和演算法評測功能，機器學習演算法包括分類、迴歸、聚類、協同過濾、降維等。除了大量的分散式機器學習演算法以外，MLlib中還提供了包括特徵提取、特徵轉換、特徵選擇等功能。由於基於Spark框架，MLlib有很好的可擴充套件性和效能，並且提供上層API用於定製化的演算法開發，因此從推出後就得到廣泛的支援和落地。
—
小結
—
分散式計算技術按照其業務場景的不同可以分為離線計算和實時計算，本文介紹了兩個具有代表性的離線計算技術MapReduce批處理引擎和Spark計算框架，那麼對於實時資料的處理又該怎麼做呢？下一篇將介紹面向互動式分析的計算引擎Impala、實時計算引擎Apache Flink和星環實時計算引擎Slipstream。
Dean J, Ghemawat S. MapReduce: simplified data processing on large clusters[J]. Communications of the ACM, 2008, 51(1): 107-113.
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69994106/viewspace-2944635/，如需轉載，請註明出處，否則將追究法律責任。
