1.用圖與自己的話，簡要描述Hadoop起源與發展階段。
Hadoop是道格·卡丁（Doug Cutting）創建的，Hadoop起源於開源網絡搜索引擎Apache Nutch，后者本身也是Lucene項目的一部分。Nutch項目面世后，面對數據量巨大的網頁顯示出了架構的靈活性不夠。當時正好借鑒了谷歌分布式文件系統，做出了自己的開源系統NDFS分布式文件系統。第二年谷歌又發表了論文介紹了MapReduce系統，Nutch開發人員也開發出了MapReduce系統。隨后NDFS和MapReduce命名為Hadoop，成為了Apache頂級項目。
從Hadoop的發展歷程來看，它的思想來自於google的三篇論文。
GFS：Google File System 分布式處理系統 ------》解決存儲問題
Mapreduce：分布式計算模型 ------》對數據進行計算處理
BigTable：解決查詢分布式存儲文件慢的問題，把所有的數據存入一張表中，通過犧牲空間換取時間
2.用圖與自己的話，簡要描述名稱節點、第二名稱節點、數據節點的主要功能及相互關系。
在HDFS中，名稱節點（NameNode）負責管理分布式文件系統的命名空間（Namespace），保存了兩個核心的數據結構，即FsImage和EditLog
第二名稱節點（SecondaryNameNode）：是HDFS架構中的一個組成部分，它是用來保存名稱節點中對HDFS 元數據信息的備份，並減少名稱節點重啟的時間。
SecondaryNameNode一般是單獨運行在一台機器上SecondaryNameNode讓EditLog變小的工作流程：
（1）SecondaryNameNode會定期和NameNode通信，請求其停止使用EditLog文件，暫時將新的寫操作寫到一個新的文件edit.new上來，這個操作是瞬間完成，上層寫日志的函數完全感覺不到差別；
（2）SecondaryNameNode通過HTTP GET方式從NameNode上獲取到FsImage和EditLog文件，並下載到本地的相應目錄下；
（3）SecondaryNameNode將下載下來的FsImage載入到內存，然后一條一條地執行EditLog文件中的各項更新操作，使得內存中的FsImage保持最新；這個過程就是EditLog和FsImage文件合並；
（4）SecondaryNameNode執行完（3）操作之后，會通過post方式將新的FsImage文件發送到NameNode節點上
數據節點是分布式文件系統HDFS的工作節點，負責數據的存儲和讀取，會根據客戶端或者是名稱節點的調度來進行數據的存儲和檢索，並且向名稱節點定期發送自己所存儲的塊的列表
4.梳理HBase的結構與運行流程，以用圖與自己的話進行簡要描述，圖中包括以下內容：
-
Master 功能：
-
1、為 RegionServer 分配 Region
2、負責 RegionServer 的負載均衡
3、發現失效的 RegionServer 並重新分配其上的 Region
4、HDFS 上的垃圾文件（HBase）回收
5、處理 Schema 更新請求（表的創建，刪除，修改，列簇的增加等等）
-
RegionServer功能：
-
1、RegionServer 維護 Master 分配給它的 Region，處理對這些 Region 的 IO 請求
2、RegionServer 負責 Split 在運行過程中變得過大的 Region，負責 Compact 操作
開始只有一個Region，后來不斷分裂
Region拆分操作非常快，接近瞬間，因為拆分之后的Region讀取的仍然是原存儲文件，直到“合並”過程把存儲文件異步地寫到獨立的文件之后，才會讀取新文件
每個Region默認大小是100MB到200MB（2006年以前的硬件配置）
– 每個Region的最佳大小取決於單台服務器的有效處理能力
– 目前每個Region最佳大小建議1GB-2GB（2013年以后的硬件配置）
同一個Region不會被分拆到多個Region服務器
每個Region服務器存儲10-1000個Region
Region的定位
元數據表，又名.META.表，存儲了Region和Region服務器的映射關系
當HBase表很大時， .META.表也會被分裂成多個Region
根數據表，又名-ROOT-表，記錄所有元數據的具體位置
-ROOT-表只有唯一一個Region，名字是在程序中被寫死的
Zookeeper文件記錄了-ROOT-表的位置
-
ZooKeeper功能：
1、ZooKeeper 為 HBase 提供 Failover 機制，選舉 Master，避免單點 Master 單點故障問題
2、存儲所有 Region 的尋址入口：-ROOT-表在哪台服務器上。-ROOT-這張表的位置信息
3、實時監控 RegionServer 的狀態，將 RegionServer 的上線和下線信息實時通知給 Master
4、存儲 HBase 的 Schema，包括有哪些 Table，每個 Table 有哪些 Column Family
-
Client請求流程：
Client 訪問用戶數據前需要首先訪問 ZooKeeper，找到-ROOT-表的 Region 所在的位置，然 后訪問-ROOT-表，接着訪問.META.表，最后才能找到用戶數據的位置去訪問，中間需要多次網絡操作，不過 client 端會做 cache 緩存。
- 四者之間的相系關系
-
與HDFS關聯：
HBase是一個內存數據庫，而hdfs是一個存儲空間；是物品和房子的關系。HBase 參考了 Google 公司的 Bigtable 建模，而 Bigtable 是基於 GFS 來完成數據的分布式存儲的，因此，HBase 與 HDFS 有非常緊密的關系，它使用 HDFS 作為底層存儲系統。
HDFS是GFS的一種實現，他的完整名字是分布式文件系統，類似於FAT32，NTFS，是一種文件格式，是底層的。Hive與Hbase的數據一般都存儲在HDFS上。Hadoop HDFS為他們提供了高可靠性的底層存儲支持。
5.理解並描述Hbase表與Region與HDFS的關系。
在Hbase中存在一張特殊的meta表,其中存放着HBase的元數據信息,包括,有哪些表,表有哪些HRegion,每個HRegion分布在哪個HRegionServer中。meta表很特殊，永遠有且僅有一個HRegion存儲meta表，這個HRegion存放在某一個HRegionServer中，並且會將這個持有meta表的Region的HRegionServer的地址存放在Zookeeper中meta-region-server下。
所以當在進行HBase表的讀寫操作時，需要先根據表名 和 行鍵確 定位到HRegion，這個過程就是HRegion的尋址過程。
HRgion的尋址過程首先由客戶端開始，訪問zookeeper 得到其中meta-region-server的值,根據該值找到唯一持有meta表的HRegion所在的HRegionServer,得到meta表,從中讀取真正要查詢的表和行鍵 對應的HRgion的地址,再根據該地址,找到真正的操作的HRegionServer和HRegion,完成HRgion的定位,繼續讀寫操作.
6.理解並描述Hbase的三級尋址。
第 1 步：Client 請求 ZooKeeper 獲取.META.所在的 RegionServer 的地址。
第 2 步：Client 請求.META.所在的 RegionServer 獲取訪問數據所在的 RegionServer 地址，Client
會將.META.的相關信息 cache 下來，以便下一次快速訪問。
第 3 步：Client 請求數據所在的 RegionServer，獲取所需要的數據。
7.假設.META.表的每行（一個映射條目）在內存中大約占用1KB，並且每個Region限制為2GB，通過HBase的三級尋址方式，理論上Hbase的數據表最大有多大？
計算方法是：（-ROOT-表能夠尋址的。META.表的Region個數)×（每個.META.表的Region可以尋址的用戶數據表的Region個數），一個-ROOT-表只能由一個Region，也就似乎最多只能有2GB(2048MB),按照每行（一個映射條目)占用1KB內存計算，2GB空間可以容納2048MB/1KB=2048行，也就是說一個-ROOT-表可以尋址2048個.META.表的Region
最終三層結構可以保存的Region的數目是：
一個-ROOT-表最多只能有一個Region，也就是最多只能有2GB，按照每行（一個映射條目）占用1KB內存計算，2GB空間可以容納2GB/1KB=2的21次方行，也就是說，一個-ROOT-表可以尋址2的21次方個.META.表的Region。同理，每個.META.表的 Region可以尋址的用戶數據表的Region個數是2GB/1KB=2的21次方。最終，三層結構可以保存的Region數目是(2GB/1KB) × (2GB/1KB) = 2的42次方個Region
8.MapReduce的架構，各部分的功能，以及和集群其他組件的關系。
一句話——整體依舊主從構，map加redu（reduce簡寫）。 map、split入磁盤，數據對分partition。shuffle、sort、key-value，一個redu（reduce）一 tion（partition）透。注：最后一句，一個reduce解析一個partition。
一堆話——如下：
和HDFS一樣，MapReduce也是采用Master/Slave的架構，其架構如下圖所示：
MapReduce包含四個組成部分，分別為Client，JobTracker，TaskTracker，Task。
a）client客戶端
每一個Job都會在用戶端通過Client類將應用程序以及參數配置Configuration打包成Jar文件存儲在HDFS，並把路徑提交到JobTracker的master服務，然后由master創建每一個Task（即MapTask和ReduceTask），將它們分發到各個TaskTracker服務中去執行。
b）JobTracker
JobTracker負責資源監控和作業調度。JobTracker監控所有的TaskTracker與job的健康狀況，一旦發現失敗，就將相應的任務轉移到其它節點；同時JobTracker會跟蹤任務的執行進度，資源使用量等信息，並將這些信息告訴任務調度器，而調度器會在資源出現空閑時，選擇合適的任務使用這些資源。在Hadoop中，任務調度器是一個可插拔的模塊，用於可以根據自己的需要設計相應的調度器。
c）TaskTracker
TaskTracker會周期性地通過HeartBeat將本節點上資源的使用情況和任務的運行進度匯報給JobTracker，同時執行JobTracker發送過來的命令 並執行相應的操作（如啟動新任務，殺死任務等）。TaskTracker使用“slot”等量划分本節點上的資源量。“slot”代表計算資源（cpu，內存等） 。一個Task獲取到一個slot之后才有機會運行，而Hadoop調度器的作用就是將各個TaskTracker上的空閑slot分配給Task使用。slot分為MapSlot和ReduceSlot兩種，分別提供MapTask和ReduceTask使用。TaskTracker通過slot數目（可配置參數）限定Task的並發度。
d）Task
Task分為MapTask和Reduce Task兩種，均由TaskTracker啟動。HDFS以固定大小的block為基本單位存儲數據，而對於MapReduce而言，其處理單位是split。split是一個邏輯概念，它只包含一些元數據信息，比如數據起始位置、數據長度、數據所在節點等。它的划分方法完全由用戶自己決定。但需要注意的是，split的多少決定了MapTask的數目，因為每一個split只會交給一個MapTask處理。split與block的關系如下圖：
MapTask的執行過程如下圖所示：由下圖可知，Map Task 先將對應的split迭代解析成一個個key-value對，依次調用用戶自定義的map()函數進行處理，最終將臨時結果存放到本地磁盤上。其中，臨時數據被分成若干個partition，每個partition將被一個Reduce Task處理。
Reduce Task 執行過程下圖所示。該過程分為三個階段：
- 從遠程節點上讀取Map Task 中間結果（稱為"Shuffle 階段"）；
- 按照key 對key/value 對進行排序（稱為"Sort 階段"）；
- 依次讀取< key, value list>，調用用戶自定義的reduce() 函數處理，並將最終結果存到HDFS 上（稱為"Reduce 階段"）
9.MapReduce的工作過程，用自己詞頻統計的例子，將split, map, partition,sort,spill,fetch,merge reduce整個過程梳理並用圖形表達出來。
從整體上，MapReduce框架可以分為五個不同實體：
客戶端：提交 MapReduce job
Yarn 資源管理器（ResouceManager）：協調集群計算資源的分配。包含主要的組件：定時調用器(Scheduler)以及應用管理器(ApplicationManager)
定時調度器(Scheduler)：從本質上來說，定時調度器就是一種策略。當 Client 提交一個任務的時候，它會根據所需要的資源以及當前集群的資源狀況進行分配。
應用管理器(ApplicationManager)：應用管理器就是負責管理 Client 用戶提交的應用。監控應用的工作正是由應用管理器（ApplicationManager）完成的
Yarn 節點管理器（NodeManager）：啟動和監視集群中每個節點的計算容器，並監控它們的資源使用情況（cpu，內存，磁盤及網絡等），以及向 ResourceManager/Scheduler 提供這些資源使用報告
Mapreduce 應用管理器（Application Master）：負責調度Mapreduce任務。應用管理器和 MapReduce 任務是運行在容器中的，這個容器是由資源管理器分配的，並且接受階段管理器的管理
分布式文件系統（通常為HDFS）
客戶端提交job給 ApplicationManager 連接NodeManager去申請一個Container的容器，這個容器運行作業的ApplicationMaster的主程序，啟動后向ApplicationManager進行注冊，然后ApplicationMaster向ResourceManager申請資源，申請job的提交資源staging-dir，還會拿到ResourceManager為這個job產生的jobId，並把staging-dir和jobId合並在一起形成特定路徑。然后客戶端再把這些資源提交到HDFS相應的路徑下面。隨后，Yarn框架會把本次job所要用到的資源放到一個任務隊列里面描述出來，拿到一個資源的列表，和對應的NodeManager進行通信，啟動對應的Container容器，運行 ReduceTask和MapTask ，它們是向ApplicationMaster進行匯報它們的運行狀態， 當所有作業運行完成后還需要向ApplicationManager進行匯報並注銷和關閉，這時所有資源會回收。
Map端流程：
由程序內的InputFormat(默認實現類TextInputFormat)來讀取外部數據，它會調用RecordReader(它的成員變量)的read()方法來讀取，返回k,v鍵值對。map每次讀取split的數據（一行一行的讀取）
讀取的k,v鍵值對傳送給map()方法，作為其入參來執行用戶定義的map邏輯
context.write方法被調用時，outputCollector組件會將map()方法的輸出結果寫入到環形緩沖區內
環形緩沖區其實就是一個數組，后端不斷接受數據的同時，前端數據不斷被溢出，長度用完后讀取的新數據再從前端開始覆蓋
spiller組件會從環形緩沖區溢出文件，這過程會按照定義的partitioner分區(默認是hashpartition)，並且按照key.compareTo進行排序(快速排序、外部排序)，若有combiner也會執行combiner。spiller的不斷工作，會不斷溢出許多小文件。這些文件仍在map task所處機器上
小文件執行merge(合並)，行程分區且區內有序的大文件(歸並排序，會再一次調用combiner)
Reduce會根據自己的分區，去所有map task中，從文件讀取對應的數據。
Reduce端流程：
1.Copy過程。每個ReduceTask不斷地通過RPC（HTTP協議）從ResourceManager獲取MapTask是否完成信息。如果ReduceTask獲知AppMaster上的MapTask執行完成，那么Shuffler的后半段過程開始啟動。Reduce task通過網絡向Map task獲取某一分區的數據
8. Merge階段。復制過來數據會先放到內存緩沖區中，當內存中的數據達到一定閾值時，就會啟動內存到磁盤的Merge。與Map端類似，這也是溢寫過程，會在磁盤中形成眾多的溢寫文件，由於一個split對應一個Map，Reduce端是從多個Map中拉取數據，所以也需要進行歸並排序，成為一個有序的文件，最終每個相同的key分為一組執行一次Reduce方法
9. Reducer的輸出文件。不斷地進行Merge后，最后會生成一個“最終文件”。這個文件可能存放在磁盤，也可能存放在內存中，默認存放在磁盤上。當Reducer的輸入文件已定時，整個Shuffle過程才最終結束