解讀大數據世界中MapReduce的前世此生

講座嘉賓：Tim

講座連接：【太閣直播】解讀大數據世界中MapReduce的前世此生

講座總結：6Kunnnnn

原文連接：【講座總結】解讀大數據世界中MapReduce的前世此生

 

何爲MapReduce？網絡上不少官方的定義都過於抽象難懂了，但願經過如下的講解，可讓你們能更簡單地理解MapReduce的含義。

1. 背景：web檢索的簡單工做流程

MapReduce其實起源於web檢索，咱們常見的web檢索能夠簡單分爲兩部分：獲取網頁內容並創建索引，和根據網頁索引來處理查詢關鍵詞。

第一，獲取網頁內容並創建索引。這一步的實現須要用到兩種程序，分別是：

1. Crawler，別名Spider，網頁爬蟲程序，用來爬取互聯網上的網頁內容

2. Indexer，索引器，對爬取下來的web內容創建索引，變成searchable content，這樣網頁就能被搜索了

須要解釋一下，什麼叫作索引器Indexer。咱們能夠簡單理解爲，互聯網上每個網頁就是一個document，每一個document都包含了不一樣的word，而咱們針對每個word，創建一個word出如今哪些document的table。

以下圖，假設有document分別爲一、二、3，裏面分別有abc、xyz、def等詞彙。而最終的Indexer結果就是將哪些word出如今哪些document ID中的映射保存下來，每個word對應一個sorted list用來存儲document ID。

第二，根據網頁索引來處理查詢關鍵詞。以下圖，當索引器被創建好了以後，每當有網頁查詢query進來，就須要利用這些索引，來處理query的關鍵詞，找出那些同時含有這些關鍵詞的文檔。好比一個query裏面同時有abc和bbb，那麼含有這兩個關鍵字的文檔就是document 2。

2. MapReduce解決分佈式web檢索問題

自從互聯網被創造後，被建立的網頁和網站變的愈來愈多，數量極爲龐大。像Google這樣的web檢索巨頭如何保證能對互聯網上大部分的web進行檢索？答案就是並行parallel，或理解爲數據量達到單機很難處理的程度，迫使採用運行多臺機器來進行分佈式計算。

如上圖，咱們橫向上來看，每一臺單機執行Crawler和Indexer任務，生成local index，最後彙總成global index。可是若是縱向上來看，Crawler和Indexer其實能夠被分爲兩個獨立的部分（由於他們的輸入輸出不一樣），而它們的中間聯繫就是，Crawler的輸出其實就是Indexer的輸入（web pages）。

因此以下圖，對於每個web獲取＋創建索引的任務（Job），咱們把其中從web page到local index的部分看成是Map階段，從local index匯聚到global index的部分看成是Reduce階段。

因此咱們能夠簡單理解爲：MapReduce就是把複雜的分佈式處理任務，簡化分解成Map和Reduce兩個階段。

這樣的programming model好處就是，咱們能更簡單的進行分佈式程序的設計和實現了。可是，雖然有不少的好處，在MapReduce中，咱們還需解決分佈式系統的常見問題。好比網絡問題，磁盤問題，程序自己問題，並且若是分佈式系統出了問題也會很難解決恢復。所以，也就有了上述圖片中的master的概念。簡單說，Master是一個專門用來管理這些分佈式系統的機器。那麼，Master是如何進行分佈式計算的管理呢？以下圖：

在一個分佈式計算集羣（cluster）中，實際運行任務的是Slave機器，也被稱之爲DataNode（由於須要處理的data被存在了這些機器上），而Master機器負責任務的調度，也被稱之爲NameNode，之因此這樣是由於它知道應該將哪一個Task分配到哪一個Slave機器上邊運行（知道Slave和Task的name）。具體細節，Master中有一個Task queue，存儲待執行的任務，每個Slave有若干Task slots用來接收Master分配來的任務並執行。Master的Job Tracker和Slave的Task Tracker，用來監督每一個Task執行狀況，若是出現問題好比網絡鏈接失敗，或者程序出錯，Master和Slave會有相應的措施來解決這些問題並恢復以前的任務進度。

因此，經過以上的任務調度方法，MR的厲害之處，就是把分佈式系統的編程分紅Map和Reduce兩部分，同時解決了頭疼的分佈式計算問題。好處就是，開發者能夠更多的注重程序的開發，而不須要太花時間解決分佈式計算的種種問題。

固然，在MapReduce出現前互聯網web檢索還有別的解決方法，好比可使用一臺超級計算機來看成是super indexer，用來接受web pages做爲輸入，來創建global index，或理解爲「shipping data to software」。這樣作不是不行，可是把數量龐大的web pages傳送到super indexer那裏，僅僅是數據的傳送就須要花費大量的時間。相比之下，MapReduce的方法能夠理解爲「shipping software to data」，也就是，DataNode負責存儲數據，而NameNode負責將Task（software）傳送給DataNode來執行。這樣的方法，速度能提高好幾個數量級，況且和一臺超級計算機相比，購買不少個普通商用計算機來進行分佈式計算要划算得多，擴展性也強。以下圖：

此外，MapReduce更適合用來做non-Transactional的數據分析，也就是數據內容基本保持不變，而相比Transactional或者Real-time的數據就會持續的更新，每次數據分析都是按batch process，一次大量時間長。

3. MapReduce和HDFS

HDFS，Hadoop Distributed File Systems，是根據Google著名的GFS的論文實現的開源項目，其實Hadoop也是Google另一篇MapReduce論文的具體實現。因此咱們能夠理解爲Hadoop就是HDFS和MapReduce。

簡單說，HDFS解決了分佈式系統不少問題，特別是數據副本replication和恢復recovery問題，它相似於UNIX系統，提供了不少文件系統的抽象接口，這樣廣大熟悉UNIX系統的人可以很快上手。那麼MapReduce是如何與HDFS配合的呢？以下圖：

首先，在Map階段以前，Map程序的輸入須要進行及部分的操做。HDFS在存儲文件的時候，並無把一個文件當作一個總體，而是利用按照必定大小（默認爲64MB）的chunk來保存文件，每個chunk可能有一個或者多個文件，好比chunk1含有文件一、2和3的一部分，chunk2含有文件3的另外一部分，以及其餘文件。因此在從chunk讀入輸入文件以前，須要對這些chunk裏面的文件進行split，即將同一文件在不一樣chunk中的部分split到一塊兒，再經過RecordReader來將文件讀成Key Value Pair的輸入交給Map程序。

以後，獲得了每一臺機器上的Map程序的輸出，須要將這些機器的輸出結果shuffling到不一樣機器的Reduce程序上進一步運算。首先一步就是進行Partition，或者理解爲將不一樣臺機器的輸出數據Group-By-Key，在對同一Key中全部數據Sort，以後的結果會被分配到不一樣機器上的Reduce程序中，這樣會進一步加快Reduce程序的速度。

4. MapReduce的擴展延伸

咱們以前所討論的內容，其實是第一代的MapReduce，基本是基於Google的論文實現的。在1.0中，Master負責了任務調度的所有工做，這樣的後果就是Master會很臃腫（功能太多），以及在同一個集羣cluster上Master只能負責MapReduce相關的分佈式計算的調度，沒法負責別的程序。而如今更流行的是MapReduce 2.0，在1.0的基礎上進行了很多的改動，最大的變化就是YARN的引入。YARN全稱爲Yet Another Resource Negotiator，主要功能就是替代NameNode的任務調度功能，主要的好處就是簡化了Master的工做量使得其再也不過與臃腫，另外一方面就是除了MapReduce以外，還能夠在同一個集羣上運行別的application，好比如今很流行的Spark。

而Spark，你們都說比MapReduce快不少，可是其底層的實現仍是相似於MapReduce分佈式的計算方式，但更多的是作出了不少的性能優化，特別就是RDD（Resilient Distributed Dataset）的引入，一種對分佈式數據的抽象。傳統的MapReduce須要大量的磁盤讀寫操做和網絡的傳輸，好比Split、RR、Partition等等，都會涉及將中間計算結果在不一樣機器之間網絡傳輸並存到disk上做爲以後pipeline的輸入的操做。可是Spark之因此快，是由於Spark採起的更多的是將RDD，也就是分佈式數據保存到Memory裏進行計算，並且是一種lazy evaluation計算方式，也就是必要的時候一口氣將內存中的某個計算過程pipeline執行完畢，而不是像MapReduce同樣，一步一步計算、每步都將中間結果保存到到磁盤上、以後下一步再讀入的方式來進行，這樣會節省大量的disk IO時間。若是pipeline的某一箇中間步驟失敗了，Spark有一個RDD的workflow圖，用來找回以前失敗的RDD重新計算，即使重新計算也極可能比磁盤IO的開銷要小不少，畢竟內存要比disk快不少。

可是Spark也並不必定能徹底替代MapReduce，相比於MapReduce，Spark更適合real-time的數據處理，由於須要較快的響應速度，或者iterative算法好比K-means，即不斷地對同一組數據進行同一個算法的迭代處理，然而MapReduce更適合於數據量很是大的batch process，由於Spark對內存要求的確是比較的高。固然Spark並不必定須要依賴於HDFS上邊運行，也能夠在別的distributed storage layer上。

總之，MapReduce從第一代，到第二代再到以後其餘相似平臺的發展，能夠看出MapReduce的生命力，以及對分佈式處理的巨大貢獻。而但願讀完這篇文章，你們也對MapReduce的前世此生有了大體的理解。

其它細節補充

對於互聯網crawler程序，之因此又叫作爬蟲spider，由於程序就好像在爬（traverse）互聯網。但存在一些獨立的網頁沒法檢索到（好比公司內部網絡）。並且爬網站須要選好seed網站，好比新浪門戶，由於有不少連接指向外部網絡，可是百度可能就不適合爬網站的seed網站，由於缺乏外部的連接。

分佈式數據庫的CAP理論，針對不一樣領域須要有不一樣的取捨。好比銀行轉帳，須要保證一個cluster中，各個機器node之間銀行數據信息是consistent的，好比不管訪問哪一個node的銀行帳單數據，結果都須要是同樣的，不然用戶可能獲得錯誤帳單。然而search engine更強調available，就是要有在必定時間內有結果返回，不要讓用戶等待過久，雖然每次查詢的結果可能不都是consistent的數據。

 

設立於硅谷，專一於編程、數據分析、UIUX設計的在線學習平臺：BitTiger。