1、Hadoop生態系統概況
Hadoop是一個能夠對大量數據進行分布式處理的軟件框架。具有可靠、高效、可伸縮的特點。
Hadoop的核心是HDFS和MapReduce，hadoop2.0還包括YARN。
下圖為hadoop的生態系統：
2、HDFS（Hadoop分布式文件系統）
源自於Google的GFS論文，發表於2003年10月，HDFS是GFS克隆版。
是Hadoop體系中數據存儲管理的基礎。它是一個高度容錯的系統，能檢測和應對硬件故障，用於在低成本的通用硬件上運行。HDFS簡化了文件的一致性模型，通過流式數據訪問，提供高吞吐量應用程序數據訪問功能，適合帶有大型數據集的應用程序。
HDFS這一部分主要有一下幾個部分組成：
（1）、Client：切分文件；訪問HDFS；與NameNode交互，獲取文件位置信息；與DataNode交互，讀取和寫入數據。
（2）、NameNode：Master節點，在hadoop1.X中只有一個，管理HDFS的名稱空間和數據塊映射信息，配置副本策略，處理客戶端請求。對於大型的集群來講，Hadoop1.x存在兩個最大的缺陷：1）對於大型的集群，namenode的內存成為瓶頸，namenode的擴展性的問題；2）namenode的單點故障問題。
針對以上的兩個缺陷，Hadoop2.x以后分別對這兩個問題進行了解決。對於缺陷1）提出了Federation namenode來解決，該方案主要是通過多個namenode來實現多個命名空間來實現namenode的橫向擴張。從而減輕單個namenode內存問題。
針對缺陷2），hadoop2.X提出了實現兩個namenode實現熱備HA的方案來解決。其中一個是處於standby狀態，一個處於active狀態。
（3）、DataNode：Slave節點，存儲實際的數據，匯報存儲信息給NameNode。
（4）、Secondary NameNode：輔助NameNode，分擔其工作量；定期合並fsimage和edits，推送給NameNode；緊急情況下，可輔助恢復NameNode，但Secondary NameNode並非NameNode的熱備。
目前，在硬盤不壞的情況，我們可以通過secondarynamenode來實現namenode的恢復。
3、Mapreduce（分布式計算框架）
源自於google的MapReduce論文，發表於2004年12月，Hadoop MapReduce是google MapReduce 克隆版。MapReduce是一種計算模型，用以進行大數據量的計算。其中Map對數據集上的獨立元素進行指定的操作，生成鍵-值對形式中間結果。Reduce則對中間結果中相同“鍵”的所有“值”進行規約，以得到最終結果。MapReduce這樣的功能划分，非常適合在大量計算機組成的分布式並行環境里進行數據處理。
MapReduce計算框架發展到現在有兩個版本的MapReduce的API，針對MR1主要組件有以下幾個部分組成：
（1）、JobTracker：Master節點，只有一個，主要任務是資源的分配和作業的調度及監督管理，管理所有作業，作業/任務的監控、錯誤處理等；將任務分解成一系列任務，並分派給TaskTracker。
（2）、TaskTracker：Slave節點，運行Map Task和Reduce Task；並與JobTracker交互，匯報任務狀態。
（3）、Map Task：解析每條數據記錄，傳遞給用戶編寫的map(),並執行，將輸出結果寫入本地磁盤。
（4）、Reducer Task：從Map Task的執行結果中，遠程讀取輸入數據，對數據進行排序，將數據按照分組傳遞給用戶編寫的reduce函數執行。
在這個過程中，有一個shuffle過程，對於該過程是理解MapReduce計算框架是關鍵。該過程包含map函數輸出結果到reduce函數輸入這一個中間過程中所有的操作，稱之為shuffle過程。在這個過程中，可以分為map端和reduce端。
Map端：
1） 輸入數據進行分片之后，分片的大小跟原始的文件大小、文件塊的大小有關。每一個分片對應的一個map任務。
2） map任務在執行的過程中，會將結果存放到內存當中，當內存占用達到一定的閾值（這個閾值是可以設置的）時，map會將中間的結果寫入到本地磁盤上，形成臨時文件這個過程叫做溢寫。
3） map在溢寫的過程中，會根據指定reduce任務個數分別寫到對應的分區當中，這就是partition過程。每一個分區對應的是一個reduce任務。並且在寫的過程中，進行相應的排序。在溢寫的過程中還可以設置conbiner過程，該過程跟reduce產生的結果應該是一致的，因此該過程應用存在一定的限制，需要慎用。
4） 每一個map端最后都只存在一個臨時文件作為reduce的輸入，因此會對中間溢寫到磁盤的多個臨時文件進行合並Merge操作。最后形成一個內部分區的一個臨時文件。
Reduce端：
1） 首先要實現數據本地化，需要將遠程節點上的map輸出復制到本地。
2） Merge過程，這個合並過程主要是對不同的節點上的map輸出結果進行合並。
3） 不斷的復制和合並之后，最終形成一個輸入文件。Reduce將最終的計算結果存放在HDFS上。
針對MR2是新一代的MR的API。其主要是運行在Yarn的資源管理框架上。
4、Yarn（資源管理框架）
該框架是hadoop2.x以后對hadoop1.x之前JobTracker和TaskTracker模型的優化，而產生出來的，將JobTracker的資源分配和作業調度及監督分開。該框架主要有ResourceManager，Applicationmatser，nodemanager。其主要工作過程如下：其ResourceManager主要負責所有的應用程序的資源分配，ApplicationMaster主要負責每個作業的任務調度，也就是說每一個作業對應一個ApplicationMaster。Nodemanager是接收Resourcemanager 和ApplicationMaster的命令來實現資源的分配執行體。
ResourceManager在接收到client的作業提交請求之后，會分配一個Conbiner，這里需要說明一下的是Resoucemanager分配資源是以Conbiner為單位分配的。第一個被分配的Conbiner會啟動Applicationmaster，它主要負責作業的調度。Applicationmanager啟動之后則會直接跟NodeManager通信。
在YARN中，資源管理由ResourceManager和NodeManager共同完成，其中，ResourceManager中的調度器負責資源的分配，而NodeManager則負責資源的供給和隔離。ResourceManager將某個NodeManager上資源分配給任務（這就是所謂的“資源調度”）后，NodeManager需按照要求為任務提供相應的資源，甚至保證這些資源應具有獨占性，為任務運行提供基礎的保證，這就是所謂的資源隔離。
在Yarn平台上可以運行多個計算框架，如：MR，Tez，Storm，Spark等計算，框架。
5、Sqoop（數據同步工具）
Sqoop是SQL-to-Hadoop的縮寫，主要用於傳統數據庫和Hadoop之間傳輸數據。數據的導入和導出本質上是Mapreduce程序，充分利用了MR的並行化和容錯性。其中主要利用的是MP中的Map任務來實現並行導入，導出。Sqoop發展到現在已經出現了兩個版本，一個是sqoop1.x.x系列，一個是sqoop1.99.X系列。對於sqoop1系列中，主要是通過命令行的方式來操作。
sqoop1 import原理：從傳統數據庫獲取元數據信息(schema、table、field、field type)，把導入功能轉換為只有Map的Mapreduce作業，在mapreduce中有很多map，每個map讀一片數據，進而並行的完成數據的拷貝。
sqoop1 export原理：獲取導出表的schema、meta信息，和Hadoop中的字段match；多個map only作業同時運行，完成hdfs中數據導出到關系型數據庫中。
Sqoop1.99.x是屬於sqoop2的產品，該款產品目前功能還不是很完善，處於一個測試階段，一般並不會應用於商業化產品當中。
Sqoop工具當中，目前我對它的認識是可能會存在一定的問題是因為當在導入導出的時候，map任務失敗了，此時Applicationmaster會重新調度另外一個任務來運行這個失敗的任務。但是這可能會存在一個問題就是，在未失敗前Map任務所導入的數據與重新調度map任務產生的結果會存在重復的現象。
6、Mahout（數據挖掘算法庫）
Mahout起源於2008年，最初是Apache Lucent的子項目，它在極短的時間內取得了長足的發展，現在是Apache的頂級項目。相對於傳統的MapReduce編程方式來實現機器學習的算法時，往往需要話費大量的開發時間，並且周期較長，而Mahout的主要目標是創建一些可擴展的機器學習領域經典算法的實現，旨在幫助開發人員更加方便快捷地創建智能應用程序。
Mahout現在已經包含了聚類、分類、推薦引擎（協同過濾）和頻繁集挖掘等廣泛使用的數據挖掘方法。除了算法，Mahout還包含數據的輸入/輸出工具、與其他存儲系統（如數據庫、MongoDB 或Cassandra）集成等數據挖掘支持架構。
mahout的各個組件下面都會生成相應的jar包。此時我們需要明白一個問題：到底如何使用mahout呢？
實際上，mahout只是一個機器學習的算法庫，在這個庫當中是想了相應的機器學習的算法，如：推薦系統（包括基於用戶和基於物品的推薦），聚類和分類算法。並且這些算法有些實現了MapReduce，spark從而可以在hadoop平台上運行，在實際的開發過程中，只需要將相應的jar包即可。
7、Hbase（分布式列存數據庫）
源自Google的Bigtable論文，發表於2006年11月，傳統的關系型數據庫是對面向行的數據庫。HBase是Google Bigtable克隆版，HBase是一個針對結構化數據的可伸縮、高可靠、高性能、分布式和面向列的動態模式數據庫。和傳統關系數據庫不同，HBase采用了BigTable的數據模型：增強的稀疏排序映射表（Key/Value），其中，鍵由行關鍵字、列關鍵字和時間戳構成。HBase提供了對大規模數據的隨機、實時讀寫訪問，同時，HBase中保存的數據可以使用MapReduce來處理，它將數據存儲和並行計算完美地結合在一起。
Hbase表的特點
1）、大：一個表可以有數十億行，上百萬列；
2）、無模式：每行都有一個可排序的主鍵和任意多的列，列可以根據需要動態的增加，同一張表中不同的行可以有截然不同的列；
3）、面向列：面向列（族）的存儲和權限控制，列（族）獨立檢索；
4）、稀疏：空（null）列並不占用存儲空間，表可以設計的非常稀疏；
5）、數據多版本：每個單元中的數據可以有多個版本，默認情況下版本號自動分配，是單元格插入時的時間戳；
6）、數據類型單一：Hbase中的數據都是字符串，沒有類型。
Hbase物理模型
每個column family存儲在HDFS上的一個單獨文件中，空值不會被保存。
Key 和 Version number在每個 column family中均有一份；
HBase 為每個值維護了多級索引，即：<key, column family, column name, timestamp>，其物理存儲：
1、Table中所有行都按照row key的字典序排列；
2、Table在行的方向上分割為多個Region；
3、Region按大小分割的，每個表開始只有一個region，隨着數據增多，region不斷增大，當增大到一個閥值的時候，region就會等分會兩個新的region，之后會有越來越多的region；
4、Region是Hbase中分布式存儲和負載均衡的最小單元，不同Region分布到不同RegionServer上。、
5、Region雖然是分布式存儲的最小單元，但並不是存儲的最小單元。Region由一個或者多個Store組成，每個store保存一個columns family；每個Strore又由一個memStore和0至多個StoreFile組成，StoreFile包含HFile；memStore存儲在內存中，StoreFile存儲在HDFS上。
8、Zookeeper（分布式協作服務）
源自Google的Chubby論文，發表於2006年11月，Zookeeper是Chubby克隆版，主要解決分布式環境下的數據管理問題：統一命名，狀態同步，集群管理，配置同步等。
Zookeeper的主要實現兩步：1）、選舉Leader 2）、同步數據。這個組件在實現namenode的HA高可用性的時候，需要用到。
9、Pig（基於Hadoop的數據流系統）
由yahoo!開源，設計動機是提供一種基於MapReduce的ad-hoc(計算在query時發生)數據分析工具
定義了一種數據流語言—Pig Latin，將腳本轉換為MapReduce任務在Hadoop上執行。通常用於進行離線分析。
10、Hive（基於Hadoop的數據倉庫）
由facebook開源，最初用於解決海量結構化的日志數據統計問題。
Hive定義了一種類似SQL的查詢語言(HQL),將SQL轉化為MapReduce任務在Hadoop上執行。通常用於離線分析。
11、Flume（日志收集工具）
Cloudera開源的日志收集系統，具有分布式、高可靠、高容錯、易於定制和擴展的特點。
它將數據從產生、傳輸、處理並最終寫入目標的路徑的過程抽象為數據流，在具體的數據流中，數據源支持在Flume中定制數據發送方，從而支持收集各種不同協議數據。同時，Flume數據流提供對日志數據進行簡單處理的能力，如過濾、格式轉換等。此外，Flume還具有能夠將日志寫往各種數據目標（可定制）的能力。總的來說，Flume是一個可擴展、適合復雜環境的海量日志收集系統。