自學大數據有一段時間了，找工作歷時一週，找到一家大廠，下週入職，薪資待遇還不錯，公司的業務背景自己也很喜歡。趁著還沒有入職，給大家爭取先把 Hadoop 系列的文章總結完畢，可以當做科普文，也可以當做筆記收藏。經過查閱各種資料，保證我的理解沒有偏差。但是也難免會有疏漏，歡迎朋友們留言給我進行交流。我的座右銘就是：認真搞定一切！絕對保證一字一字好好斟酌，技術不能有半點馬虎。
目前 Hadoop 系列文章的規劃就是這樣，其它的小組件先不進行總結，以後會慢慢涉及到的。
Hadoop 生態系列之 1.0 和 2.0 架構
Hadoop 生態系列之 HDFS
Hadoop 生態系列之 Mapreduce
Hadoop 生態系列之 Yarn
Hadoop 生態系列之 Zookeeper
Hadoop 生態系列之 Hive
Hadoop 生態系列之 HBase
學習大數據的前提思想：分而治之。
先來一個題目大家思考一下：給定a、b兩個文件，各存放50億個url，每個url各佔64字節，內存限制是4G，讓你找出a、b文件共同的url？
這個問題不要急著我上網去查。先思考一下，結合上面我提到的「分而治之」的思想。思路會在文末給出。
1背景
2003 年 Google 發表三篇論文，分別是 《The Google File System》 《MapReduce: Simplified Data Processing on Large Clusters》 《Bigtable: A Distributed Storage System for Structured Data》，分別對應後來出現的 HDFS，MapReduce， HBase。建議大家都看看論文原文，後臺回覆谷歌論文即可。
2006 年 Docu Cutting 開源了 Hadoop，名字取自於他兒子的玩具小象 Hadoop。
Hadoop 1.0 是指 MapReduce + HDFS，Hadoop 2.0 是指 MapReduce + HDFS + Yarn。
在再細分一下：
大數據解決框架解決的問題大體可以分為兩個方面：一是海量數據的存儲、二是海量數據的計算。
2Hadoop 1.0 架構
為了解決上述問題，推出了一系列的解決方案，其中開源框架中比較出名的就是 Hadoop 了,提供了分佈式存儲系統 HDFS 和分佈式計算模型 MapReduce。
Hadoop1.0 即第一代 Hadoop，指的是版本為 Apache Hadoop 0.20.x、1.x或者 CDH3 系列的 Hadoop，內核主要由 HDFS 和 MapReduce 兩個系統組成，其中MapReduce是一個離線處理框架，由編程模型（新舊API）、運行時環境（JobTracker 和 TaskTracker）和數據處理引擎（MapTask和ReduceTask）三部分組成。
先來說一下 HDFS 的架構，架構圖如下：
分佈式系統最怕的就是出現單節點的問題，很容易成為性能瓶頸。HDFS 1.0 中使用 NameNode 做為主節點，SecondaryNameNode 作為從節點，但是這裡的從節點不能作為主節點的備份。
分佈式計算，MapReduce 1.0 的架構如下：
缺點是：JobTracker 壓力大。單點故障。只能執行 MapReduce 任務,不能跑 Storm，Flink等計算框架的任務。
3Hadoop 2.0 架構
Hadoop2.0即第二代Hadoop，指的是版本為Apache Hadoop 0.23.x、2.x或者CDH4系列的Hadoop，內核主要由HDFS、MapReduce和YARN三個系統組成，其中YARN是一個資源管理系統，負責集群資源管理和調度，MapReduce則是運行在YARN上的離線處理框架。
1、針對Hadoop1.0單NameNode制約HDFS的擴展性問題，提出HDFS Federation，它讓多個NameNode分管不同的目錄進而實現訪問隔離和橫向擴展，同時徹底解決了NameNode單點故障問題；
2、針對Hadoop1.0中的MapReduce在擴展性和多框架支持等方面的不足，它將JobTracker中的資源管理和作業控制分開，分別由ResourceManager（負責所有應用程序的資源分配）和ApplicationMaster（負責管理一個應用程序）實現，即引入了資源管理框架Yarn。
3、Yarn作為Hadoop2.0中的資源管理系統，它是一個通用的資源管理模塊，可為各類應用程序進行資源管理和調度，不僅限於MapReduce一種框架，也可以為其他框架使用，如Tez、Spark、Storm等。
HDFS 在 Hadoop 2.0 中的架構圖如下：
NameNode 變為兩個，一個主節點，一個從節點，主節點負責接收客戶端的讀寫請求，從節點同步主節點的元數據。兩個 NameNode 就需要保持元數據一致，這個是由 JN 集群來完成的。主從節點的自動切換是由 ZKFC 來完成的。這裡面的細實現細節很重要。對於理解分佈式應用也是一種幫助。Hadoop 的 高可用原理：Hadoop HA 深度解剖。
Hadoop 2.0新引入的資源管理系統，直接從MRv1演化而來的；核心思想：將MRv1 中 JobTracker 的資源管理和任務調度兩個功能分開，分別由 ResourceManager 和 進程實現。
1.ResourceManager負責資源管理和調度；
2.ApplicationMaster：負責任務切分、任務調度、任務監控和容錯等。
3.MapTask/ReduceTask：任務驅動引擎，與MRv1一致
注意：每個 MapRduce 作業對應一個 ApplicationMaster 任務調度。
使用 Yarn 資源調度和任務管理。Hadoop 2.0 中 YARN的引入，使得多個計算框架可運行在一個集群中。
今天這篇文章主要是介紹一下 Hadoop 1.0 和 2.0 的架構，以及 2.0 改善的地方。繼續深挖的話，東西太多了，你學的越深，不會的東西就越多。但是做研究就是這樣，沒有一個人敢說自己在某一方面很完美，隨著升級打怪的難度提升，不懂的就越多，人生就是這樣一個大遊戲啊。今天關於架構就介紹到這裡，有什麼正確的地方歡迎留言指出。
回答一下開頭的思路：分而治之。
Q：給定a、b兩個文件，各存放50億個url，每個url各佔64字節，內存限制是4G，讓你找出a、b文件共同的url？
A：可以估計每個文件的大小為50G×64=320G，遠遠大於內存限制的4G。所以不可能將其完全加載到內存中處理。考慮採取分而治之的方法。s 遍歷文件a，對每個url求取 hash(url) % 1000，然後根據所取得的值將url分別存儲到1000個小文件（記為）中。這樣每個小文件的大約為300M。s 遍歷文件b，採取和a相同的方式將url分別存儲到1000個小文件（記為）。這樣處理後，所有可能相同的url都在對應的小文件（）中，不對應的小文件不可能有相同的url。然後我們只要求出1000對小文件中相同的url即可。s 求每對小文件中相同的url時，可以把其中一個小文件的url存儲到hash_set中。然後遍歷另一個小文件的每個url，看其是否在剛才構建的hash_set中，如果是，那麼就是共同的url，存到文件裡面就可以了。
Hadoop 中 MapReduce 計算模型就是分而治之思想的一種實現，更重要對於我們開發者來說使用很簡單，只需要開發的過程中使用對應的模塊就可以完成我們的分佈式應用，Map 和 Reduce 細節不需要我們關心。
（全文完）
如果對您有幫助，歡迎點贊、關注、轉發。
閱讀更多 大數據進擊之路 的文章
