云計算、大數據、神經計算、生物計算、人工智能、虛擬現實等等，這些聽上去很高大上，很牛逼的名詞，學習起來，就讓人油然的產生一種望而卻步的感覺，其實背后隱藏著的只是自信心的不足。我們從小學習一直走的是一條，打基礎，再打基礎，繼續打基礎的道路，可是前面的那些高大上名詞的基礎是哪些?你打夠呢嗎?我們從小的學習，就像爬山一樣，從山腳順著一條路，往上一步一步的爬，有的人爬一小段就不行了，就下山了，有的爬到了半山腰，但卻不知前路在何方，甚至懷疑這條路到底有沒有柳暗花明的那么一天，在迷茫，找尋之中慢慢磨去了那些為之不多，有限的意志力，也只能中途折返。我們何不先山巔之上，順勢往眺望山下，便能發現上山的路有無數條，看清路之后再找到你所要走過的臺階，翻過的巨石。
廢話不多說，下面正式進入，我對于Google三大論文中的The Google File System 和 Google MapReduce的理解。
首先，我想說云計算是個什么東西?對于到底什么是云計算，至少可以找到100種解釋。現階段廣為接受的是美國國家標準與技術研究院(NIST)定義：云計算是一種按使用量付費的模式，這種模式提供可用的、便捷的、按需的網絡訪問，進入可配置的計算資源共享池(資源包括網絡，服務器，存儲，應用軟件，服務)，這些資源能夠被快速提供，只需投入很少的管理工作，或與服務供應商進行很少的交互。可能生硬的概念看著沒意思，也并不能理解，其實云計算一直就在我們身邊，像是我們平時用的最多的百度云盤，360云盤等等之類的一些云存儲服務;還有便是我們用QQ發送的離線文件，也是存儲在云端的;我們學校選課的時候可能經常遇到過服務器一下子爆滿，崩掉的情況，那么此時如果學校在這幾天租用阿里云服務器或是其他的服務器等等，便能輕松承受住瞬間的大批量訪問，也是說云服務器也是應用之一。這是現階段的云計算實際用到的，可能以后我們云計算結合物聯網，物理ID等等，可能你就不再需要什么筆記本，手機之類的了，你只需要在提供這種機器上用你的手指，或是虹膜，通過物理ID的識別，可能一下子就能成為你的手機，或是你的電腦，一切的一切都在云端進行，在云端進行存儲，完成運算。未來云計算的強大的功能的實現，就像十幾年的前大哥大時代，看待如今的智能手機一樣。科技發展是飛速的，只要在網絡帶寬足夠快，以及物理ID，物聯網的實現的情況下，那么活在云端的生活就不遠了。
其次，我再來介紹一下The Google File System(GFS)。GFS是一個可擴展的分布式文件系統，用于大型的、分布式的、對大量數據進行訪問的應用。它運行于廉價的普通硬件上，并提供容錯功能。它可以給大量的用戶提供總體性能較高的服務。由于搭建這個云平臺的硬件設備，都是廉價，并且是很普通的，那么組件失效是常態而不是一種異常現象，所以GFS在設計的時候，所以迅速地偵測、冗余并恢復失效的組件——容錯性要好;由于日益增加的產生的數據量需要處理，當經常要處理快速增長的、包含數以萬計的對象、長度達TB的數據集時，我們很難管理成千上萬的KB規模的文件塊，即使底層文件系統提供支持。因此，設計中操作的參數、塊的大小必須要重新考慮。對大型的文件的管理一定要能做到高效，對小型的文件也必須支持，但不必優化——大數據的處理;要考慮到可能在云端的一個文件同時被多個客服端訪問使用，處理——交互的靈活性。所以在GFS設計的時候，采用GFS Master單獨的節點來管理GFS中的所有元數據，通過記錄日志的操作，以及自身影子的存在，在Master服務器組件失效時，可實現迅速恢復;GFS Chunk服務器及是，數據存儲的地方，每個文件被分割為數個chunk文件塊，每個文件塊都是唯一標識的，并且每個Chunk文件塊默認情況，都有三個副本，在其中一個副本的組件出現失效時便會迅速進行復制;GFS Client接口，實現GFS的API函數，實現Master服務器和Chunk服務器，Master服務器和客戶機之間的交互。由于我們經常要處理的數據都是數GB、數TB，所以選擇較大Chunk塊尺寸(64MB)其優點：減少Client和Master通訊、減少Master存儲元數據的大小、Client對一個Chunk能進行多次操作，減少網絡IO。那么這個GFS這個文件系統是如何讀數據和寫入數據的了，讀數據：首先，客戶端把文件名和程序指定的字節偏移，根據固定的Chunk大小，轉換成文件的 Chunk索引，文件名和Chunk索引發送給Master節點。然后，Master節點將相應的Chunk標識和副本的位置信息發還給客戶端。客戶端會緩存這些信息(客戶端不緩存數據，但是會緩存元數據)。最后，客戶端發送請求到最近的存儲了目標數據的chunkserver，讀取chunk。寫入數據：1. 客戶端向master詢問一個擁有租約的chunk，如果沒有，master選擇一個chunk 建立租約，并返回這個chunk(作為主chunk)和所有的副本chunk的位置信息。 2. 客戶端緩存這些chunk的位置信息以避免和master的多次通信。 3. 客戶端將數據按照一個優化過的管道推送到所有chunk serer上(不斷地選擇就近和負載低的節點)。chunk server接收到數據后立即推送到下一個節點。這個節點的順序是由主chunk生成的(不一定最先推送到主chunk)。 4. 數據推送完成后，發送寫請求到主chunk，主chunk通知所有副本chunk執行寫請求，副本寫完后，通知主chunk，主chunk返回客戶端。對于GFS分布式文件系統，我也只是初步的了解，還有很多理解不清晰的地方，歡迎大家討論交流。
然后，再來介紹一下 GFS MapReduce這種編程模型。首先我們要先弄清楚，MapReduce是干什么用的?我們都知道Google是搜索引擎起家，那么MapReduce就是Google搜索引擎的精華，它就負責詞條的信息的提取，和大規模的算法，文字，圖像的處理，能在龐大的數PB級別的數據庫中，在很短的時間內找出，用戶所需要的數據所在。那么MapReduce是一個怎樣的工作原理了?MapReduce是由Map和Reduce兩部分組成的。現在我們要使用MapReduce完成一個User Program的一個任務，那么我們首先把任務文件，分為M份，每一份通常有16MB到64MB，然后使用fork將用戶進程拷貝到集群內其它機器上。第二，user program的副本中有一個稱為master，其余稱為worker，master是負責調度的，為空閑worker分配作業(Map作業或者Reduce作業)，worker的數量也是可以由用戶指定的。第三，被分配了Map作業的worker，開始讀取對應分片的輸入數據，Map作業數量是由M決定的，和split一一對應;Map作業從輸入數據中抽取出鍵值對，每一個鍵值對都作為參數傳遞給map函數，map函數產生的中間鍵值對被緩存在內存中。第四，緩存的中間鍵值對會被定期寫入本地磁盤，而且被分為R個區，R的大小是由用戶定義的，將來每個區會對應一個Reduce作業;這些中間鍵值對的位置會被通報給master，master負責將信息轉發給Reduce worker。第五，master通知分配了Reduce作業的worker它負責的分區在什么位置(肯定不止一個地方，每個Map作業產生的中間鍵值對都可能映射到所有R個不同分區)，當Reduce worker把所有它負責的中間鍵值對都讀過來后，先對它們進行排序，使得相同鍵的鍵值對聚集在一起。因為不同的鍵可能會映射到同一個分區也就是同一個Reduce作業(誰讓分區少呢)，所以排序是必須的。最后，當所有的Map和Reduce作業都完成了，master喚醒正版的user program，MapReduce函數調用返回user program的代碼。也就是，Map作業處理一個輸入數據的分片，可能需要調用多次map函數來處理每個輸入鍵值對;Reduce作業處理一個分區的中間鍵值對，期間要對每個不同的鍵調用一次reduce函數，Reduce作業最終也對應一個輸出文件。
最后，再來談一下Hadoop是什么。Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。Google的GFS分布式系統只是谷歌內部使用的并不是開放的，因此Apache基金會用Java實現了一個開源版本，支持Fedora、Ubuntu等Linux平臺。Hadoop是項目的總稱。主要是由HDFS和MapReduce組成。HDFS是Google File System(GFS)的開源實現。MapReduce是Google MapReduce的開源實現。目前像阿里、百度、京東等等都是通過Hadoop來實現的自家的云平臺的搭建，淘寶的阿里云的進步一年一年的雙十一的業績，在571億成交額的背后，是多么強大的服務器技術，還有今年春運期間對于12306網站服務器的分流。阿里云就是Hadoop技術來實現的。
云計算的學習，肯定是一條漫長而又艱辛的路，但還是那句話，你既然選擇了開始，就不要輕易選擇放棄!相信自己，一定能行!
京公網安備 11010502049343號