前言
大資料處理系統:Hadoop原始碼情景分析，採用的是Hadoop2.6。如果你有點野心,想對大資料處理系統有比較深入透徹的了解,特別是想有朝一日自己也設計一個這樣的系統,甚至自己把它寫出來,那麼你真應該認真讀一下這本文,以及 Hadoop的原始碼,看看人家是怎麼設計怎麼實現的。
然後,在最後一章,再看看Spark又是什麼樣的,有些什麼改進。你將看到,在一個計算機叢集上構築一個大資料處理系統,哪些成分是必不可少的,哪些方面又是可以改進的,它與作業系統的關係怎樣,而作為大規模計算機叢集的“作業系統”又可以和應該是什麼樣的。
不過也盡力把它寫成讓非計算機專業的讀者也能讀懂,當然他們的困難會多一些,但也絕非無法理解。正因如此,本文敘述也許顯得過於通俗直白,有時候可能還有點囉嗦。
主要內容全文總共分為20章的內容，因為內容比較多，所以接下來我就給大家做個粗略的介紹，每一節都有更加細化的內容！
第1章大資料與Hadoop，
第2章研究方法，我們的目的是要研究 Hadoop的原始碼,而研究必須有研究方法。這裡所說的研究方法是指如何閱讀、分析、理解各種計算機程式原始碼的方法和手段。實際上對此並沒有一種標準的或者公認的方法,各人所用的方法和手段可能都不一樣,這裡只是把我所用的方法介紹給讀者,以期拋磚引玉
第3章Hadoop叢集和YARN，雖然 Hadoop也可以在單機上執行,但是這個平臺的典型執行場景無疑是在多機的叢集(Cluster)上。我們把執行著 Hadoop平臺的叢集,就Hadoop平臺的邊界所及,稱為“Hadoop叢集”。其中的每臺機器都成為叢集的一個“節點(node)”,節點之間連成一個區域網。這個區域網一般都是交換網,而不是路由網。這就是說,叢集中只有交換機(switch),一般是二層交換機,也可能是三層交換機,但是沒有普通的路由器,因為那些路由器引入的延遲太大了。不過這也不絕對,有時候可能確實需要將一個叢集分處在不同網段中,而通過路由器相連,但是這並不影響 Hadoop的執行(除效能降低之外)。就 Hadoop而言,路由器與交換機在邏輯上是一樣的。
第4章Hadoop的RPC機制，RPC是“RemoteProcedureCall”即“遠地過程呼叫”的縮寫。這個機制的目的,是讓一臺機器上的程式能像呼叫本地的“過程”那樣來呼叫別的機器上的某些過程。這裡所謂“過程”,在傳統的 C程式設計中統稱為“函式”,在 Pascal程式設計中既可以是 PROCEDURE 也可以是 FUNCTION,在Java等 OO 程式設計語言中就是 “方 法 (method)”。所 以,Java傳 統 的RPC機制稱為 RMI,即“遠地方法啟用(RemoteMethodInvocation)”。
第5章Hadoop作業的提交，在計算機上啟動執行一個應用,首先要把這個應用作為“作業(Job)”提交給計算機系統。
一般這是通過鍵入一個命令列或點選某個圖示而實現的,操作很簡單。但是,如果我們要考察在提交作業時系統內部的流程,那就比較複雜了。學過作業系統的人對單機上的作業提交過程會有比較深入的了解,不過那不是本書所要關注的問題。本書所關注的是,在通常運行於計算機叢集的 Hadoop系統上,作業是怎樣提交的。
第6章作業的排程與指派，
第7章NodeManager與任務投運，使用者提交的作業為 ResourceManager接受並得到排程執行之後,RM會設法將其投入執行。但是一 個 作 業 (Job 或 App)通常都包含著很多工,比方說N個MapTask和1個ReduceTask,所以作業的投運終究會分解成許多工的投運。
第8章MRAppMaster與作業投運，
第9章YARN子系統的計算框架，Hadoop中 YARN 子系統的使命是為使用者提供大資料的計算框架。早期的 Hadoop,甚至早期的 YARN 都只提供一種計算框架,那就是 MapReduce。如前所述,MapReduce是一種極簡的,然而在很多情況下頗為有效的計算模型和框架。
但是Hadoop的MapReduce框架要求使用者提供用Java語言編寫的 Mapper和 Reducer,而 App本身則雖然簡單但也要求用Java編寫,這又使有些使用者感到有點不便,而且 MapReduce這個模式也過於簡單和單調。所以 Hadoop後來有了一些新的發展,除 MapReduce外又提供了稱為Chain和Stream的計算框架。一來使使用者不必非得用Java程式設計;二來更允許使用者利用 Linux上的 Utility工具軟體搭建更像“資料流”的結構。本章介紹 YARN 子系統為使用者提供的計算框架,當然主要還是傳統的 MapReduce框架。
第10章MapReduce框架中的資料流
第11章Hadoop的檔案系統HDFS
第12章HDFS的DataNode
第13章DataNode與NameNode的互動，資料節點DataNode在執行中會與三種對端有互動。
第一種是NameNode,如前所述,對於資料塊的儲存地點,雖然最初是由NameNode分配和指定的,但相關的資訊最終來自DataNode的報告。
第二種是使用者的App(包括Shell),使用者的App可以存在於叢集內的任何節點上,不過那是在獨立的JVM上,即使與DataNode同在-一個節點上也互相獨立;然而真正把資料儲存在DataNode上或從DataNode讀取資料的卻是App(或Shell)。
第三種是叢集中別的DataNode,就是說DataNode與DataNode之間也會有通訊和互動,這主要來自資料塊復份replica的傳輸和轉儲。
資料塊在HDFS檔案系統中的儲存是“狡兔三窟”的,一個數據塊要分別儲存在若干不同的DataNode.上,但是系統並不要求App把--個數據塊分別傳送給幾個DataNode,而只需傳送給其中的一個,後面就是DataNode之間的事了。
第14章DataNode間的互動
第15章HDFS的檔案訪問
第16章Hadoop的容錯機制
第17章Hadoop的安全機制
第18章Hadoop的人機介面，供人們直接使用的系統須提供人機互動的手段,或稱“人機介面(UserInterface)”即 UI,更確切地說是“Man-MachineInterface”,使人們得以使用和管理這個系統或平臺。比
第19章Hadoop的部署和啟動，系統的安裝部署本來就不是小事,對於大規模的叢集就更不用說了。Hadoop 一般都是在叢集_上執行,但是要運維人員跑到每一臺機器上去部署或啟動卻是不現實的，得要能在一個集中的控制檯節點上完成Hadoop的部署和啟動(還有關機)才好,這當然又會使整個過程增加許多技術上的複雜度。既然是在一個集中的控制檯節點上部署和啟動一個叢集,那當然就離不開遠端操作,所以Linux的遠端操作工具ssh和rsyne就成了整個過程的基石。之所以是ssh和rsync,而不是別的遠端操作工具(比方說Telnet),是因為這二者的安全性比較好,通訊中採用了較強的加密手段。
第20章Spark的優化與改進
近年來, Hadoop與Spark 之間就像展開了一場你追我趕的競賽。時至今日，Hadoop和Spark已經成為大資料處理平臺的兩個“de facto standard”,即“事實標準”。
不過Spark之於Hadoop也並非完全是對立的兩種平臺或產品,在很大程度上倒是對於Hadoop的補充，而並不完全是作為對於Hadoop的替代。
事實上,Spark雖然也能以“Stand alone"模式獨立存在和執行,但是更多地還是利用YARN,在YARN框架上執行。而且Spark也不提供自己的檔案系統，大多隻是直接利用HDFS。雖然Spark並不要求必須使用HDFS,但是在大規模叢集的條件下要實現“資料在哪裡,計算就去哪裡”這個原則,而且還要容錯,實際上也沒有太多的選擇。
所以從功能上看，Spark的作用只是相當於一個更好的YARN子系統。
Hadoop的不足是明擺著的，總而言之，一是不夠靈活、比較死板，就是專門針對MapReduce;二是效能不夠好;三是使用不夠方便,動不動就得寫個Java程式。
那麼Spark對此又有些什麼樣的改進呢?下面就作些介紹和評述,同時也對Hadoop和Spark做個粗泛的比較研究。
這份【 大資料處理系統: Hadoop原始碼情景分析】共有783頁，已經整理打包好，需要完整版內容的朋友，可以轉發此文關注小編，私信小編【學習】來獲取！！