Hadoop 核心概念解析
Hadoop 權威指南讀書筆記 - 入門
前言
在大學里曾經使用過Nutch，實現了一個簡單的搜索引擎。工作之后，公司里有同事使用Lucene來做站內搜索。這些年伴隨著大數據的興起，Hadoop已經成為了靜態數據處理的標準，號稱性能更優且可以處理
流式數據的Spark也發展得如火如荼。記得那時候搜索引擎還是一個高端的技術，是一種非常神秘的存在，能夠從紛繁復雜的數據海洋中精確地找到用戶想要的信息，這確實能夠直觀地體現技術的價值。這些年
過去之后，發現搜索這個詞不見了，更為的是智能推送。從你希望系統告訴你什么，變成了系統知道你需要什么，這是一步很大的跨越，相信將來沒有大數據處理的概念，因為大數據處理是基本的技術。
Hadoop的歷史
Hadoop 并不是從石頭里面蹦出來的，而是從其他項目演化過來的。其中有兩個項目不得不提-Lucence和Nutch。
Lucene其實是一個提供全文文本搜索的函數庫，它不是一個應用軟件。它提供很多API函數，是一個開放源代碼的全文檢索引擎工具包，讓你可以運用到各種實際應用程序中。它提供了完整的查詢引擎和索引引擎
以及部分的文本分析功能。Lucene的目的是為軟件開發人員提供一個簡單易用的工具包，以方便的在目標系統中實現全文檢索的功能，或者是以此為基礎建立起完整的全文檢索引擎。
Nutch是一個建立在Lucene核心之上的Web搜索的實現，它是一個真正的應用程序。也就是說，你可以直接下載下來拿過來用。它在Lucene的基礎上加了網絡爬蟲和一些和Web相關的內容。其目的就是想從一個
簡單的站內索引和搜索推廣到全球網絡的搜索上，就像Google和Yahoo一樣。
Hadoop 是一個分布式計算的基礎架構，用戶在不需要了解底層細節的情況下，開發分布式的應用。Hadoop 最重要的是實現了一個分布式的文件系統，這樣的文件系統可以架構在價格低廉的集群之上。Hadoop
另外一個重要內容就是MapReduce，一種分布式任務處理的架構。這兩個部分構成了Hadoop的基石，Hadoop在創新在于從以前的以應用為中心，轉變為以數據為中心。以前是應用獲取數據進行處理，現在是將
計算任務發送給數據，然后進行處理。
它主要有以下幾個優點：
1. 高可靠性。Hadoop按位存儲和處理數據的能力值得人們信賴。
2. 高擴展性。Hadoop是在可用的計算機集簇間分配數據并完成計算任務的，這些集簇可以方便地擴展到數以千計的節點中。
3. 高效性。Hadoop能夠在節點之間動態地移動數據，并保證各個節點的動態平衡，因此處理速度非常快。
4. 高容錯性。Hadoop能夠自動保存數據的多個副本，并且能夠自動將失敗的任務重新分配。
5. 低成本。與一體機、商用數據倉庫以及QlikView、Yonghong Z-Suite等數據集市相比，hadoop是開源的，項目的軟件成本因此會大大降低。
Hadoop 也是由諸多的子項目構成的，下面是組成Hadoop的核心項目：
1. HDFS: Hadoop分布式文件系統(Distributed File System) － HDFS (Hadoop Distributed File System)
2. MapReduce：并行計算框架，0.20前使用 org.apache.hadoop.mapred 舊接口，0.20版本開始引入org.apache.hadoop.mapreduce的新API
3. HBase: 類似Google BigTable的分布式NoSQL列數據庫。（HBase和Avro已經于2010年5月成為頂級 Apache 項目）
4. Hive：數據倉庫工具，由Facebook貢獻。
5. Zookeeper：分布式鎖設施，提供類似Google Chubby的功能，由Facebook貢獻。
6. Avro：新的數據序列化格式與傳輸工具，將逐步取代Hadoop原有的IPC機制。
7. Pig: 大數據分析平臺，為用戶提供多種接口。
8. Ambari：Hadoop管理工具，可以快捷的監控、部署、管理集群。
9. Sqoop：于在HADOOP與傳統的數據庫間進行數據的傳遞。
HDFS
HDFS 絕對是Hadoop的創舉，因為要對大批量的數據進行處理，如果采取集中的方式，那么一定會受限于計算資源的限制，必須采取分布式的架構，利用分而治之的思想才能將負載分發到整個集群中去，分布式
文件系統就應運而生了。分布式的存儲使得文件存放在眾多的節點上，而只需要一個節點去記錄這些文件的元數據信息（主要是文件的位置），在訪問文件的時候，先訪問這個元數據節點，獲取文件所在的位置，
然后再獲取文件。用戶不必關心文件存儲在哪個節點上，而且由于分布式存儲已經解決了高可用的問題，所以用戶不必擔心數據存儲的可用性。
HDFS的設計思想來源于谷歌的GFS(Google File System)，Google發布的MapReduce論文中提出了基本的框架，在HDFS中得到了充分的體現。HDFS中的文件默認保存三份，所以一份丟失不會造成數據丟失，可以
根據另外兩份恢復回來。HDFS存儲數據的基本單元是塊(Block)，大小為64M。
HDFS 有兩種Node，一種是NameNode，負責記錄具體數據的元數據信息，另一種是DataNode，真正的數據節點。這里的NameNode有兩個，另一個主要作用是分擔主NameNode的一部分工作負載。每一個文件的副本
存儲在不同的節點上，可以通過配置，讓HDFS感知機架，這樣副本會存儲在不通的機架上，即使整個機架壞掉，數據也是可以恢復的。不同副本之間的數據復制由HDFS負責。在NameNode和DataNode之間維持著心跳
NameNode能夠感知DataNode的狀態，DataNode變得不可用，會啟用副本復制。
MapReduce
從請求處理的流程來看，數據寫入時，數據會在不同機架上的節點上進行寫入。數據讀取的時候，NameNode會查找這個數據的塊信息，根據這些信息去相應節點上獲取數據，返回給客戶端。創建文件時，先在NameNode
上創建文件，然后寫入數據到DataNode，數據在DataNode之間進行復制，寫入成功后，返回信息給NameNode，確認文件創建成功后，記錄文件的相關信息（存儲位置等等）。
MapReduce 是一種分而治之的思想，谷歌在論文中提出的這種思想成為了后來分布式任務處理的標準。Map是映射，Reduce則是歸約，對于輸入的數據來說，先需要分片，然后通過Map對數據進行處理，處理的結果是k/v
這個k/v是針對每個map接收到的分片進行的操作，每一個map操作輸出至少一個key/value對，根據map的key對map的輸出先進行合并，每一個key對應一個reduce，各個reduce做各自的處理。
MapReduce由JobTracker接收用戶提交的Job，然后下發任務到各個節點上，由節點上的Task Tracker負責具體執行。當然這只是一個大概的流程，實際情況下會有更多具體的細節。這個例子中，我們可以看出Map和
Reduce的原理。Map對每一個接收到的內容做相同的處理，即記錄每個單詞的次數，然后列一個清單進行輸出，在進入到Reduce之前有一個合并key的過程，即將各個Map輸出的相同的Key進行合并(shuffle)，這個過程
匯總所有Map輸出的Key和Value，匯總之后的key就是最終reduce的輸入的key，那么value則很可能是多個值的集合，因為map合并的時候，相同的key作為一個key，但是value會存入一個數組作為這個key的value。
每個Reduce從Map的輸出中獲取數據，然后匯總每個key對應的值，最終多個Reduce的結果再做一次匯總就輸出為最終的內容。在整個過程中，只有map操作和reduce操作是用戶需要關系的，其他的部分全部交給Hadoop。
通俗易懂的例子
在講到MapReduce時，總是會講到wordcount的例子，之后再想想，貌似腦海里又不清晰了。網上有個人分享了一個撲克牌分類的例子，非常貼切。
需要在一堆撲克牌(張數未知)中統計四種花色的牌有多少張，只需要找幾個人，每人給一堆，數出來四種花色的張數，然后匯總給另外一個人就可以了。比如兩個人每人一堆撲克牌，查出紅桃、黑桃、梅花、方片之
后四個人，每個人只負責統計一種花色，最終將結果匯報給一個人，這是典型的map-reduce模型。
細節探討
- split 的機制
在Map之前，數據會被分片（split），分片的結果決定了map的個數，那么分片的機制如何呢?
Hadoop 2.x默認的block大小是128MB，Hadoop 1.x默認的block大小是64MB，可以在hdfs-site.xml中設置dfs.block.size，注意單位是byte。
分片大小范圍可以在mapred-site.xml中設置，mapred.min.split.size mapred.max.split.size，minSplitSize大小默認為1B，maxSplitSize大小默認為Long.MAX_VALUE = 9223372036854775807
在我們沒有設置分片的范圍的時候，分片大小是由block塊大小決定的，和它的大小一樣。比如把一個258MB的文件上傳到HDFS上，假設block塊大小是128MB，那么它就會被分成三個block塊，與之對應產生三個split，所以最終會產生三個map task。我又發現了另一個問題，第三個block塊里存的文件大小只有2MB，而它的block塊大小是128MB，那它實際占用Linux file system的多大空間？答案是實際的文件大小，而非一個塊的大小。
這篇文章講解比較詳細：http://blog.csdn.net/dr_guo/article/details/51150278
- shuffle 的原理
hadoop的核心思想是MapReduce，但shuffle又是MapReduce的核心。shuffle的主要工作是從Map結束到Reduce開始之間的過程。首先看下這張圖，就能了解shuffle所處的位置。圖中的partitions、copy phase、sort phase所代表的就是shuffle的不同階段。
shuffle階段又可以分為Map端的shuffle和Reduce端的shuffle。
1.Map端的shuffle
Map端會處理輸入數據并產生中間結果，這個中間結果會寫到本地磁盤，而不是HDFS。每個Map的輸出會先寫到內存緩沖區中，當寫入的數據達到設定的閾值時，系統將會啟動一個線程將緩沖區的數據寫到磁盤，這個過程叫做spill。
在spill寫入之前，會先進行二次排序，首先根據數據所屬的partition進行排序，然后每個partition中的數據再按key來排序。partition的目是將記錄劃分到不同的Reducer上去，以期望能夠達到負載均衡，以后的Reducer就會根據partition來讀取自己對應的數據。接著運行combiner(如果設置了的話)，combiner的本質也是一個Reducer，其目的是對將要寫入到磁盤上的文件先進行一次處理，這樣，寫入到磁盤的數據量就會減少。最后將數據寫到本地磁盤產生spill文件(spill文件保存在{mapred.local.dir}指定的目錄中，Map任務結束后就會被刪除)。
最后，每個Map任務可能產生多個spill文件，在每個Map任務完成前，會通過多路歸并算法將這些spill文件歸并成一個文件。至此，Map的shuffle過程就結束了。
2.Reduce端的shuffle
Reduce端的shuffle主要包括三個階段，copy、sort(merge)和reduce。
首先要將Map端產生的輸出文件拷貝到Reduce端，但每個Reducer如何知道自己應該處理哪些數據呢？因為Map端進行partition的時候，實際上就相當于指定了每個Reducer要處理的數據(partition就對應了Reducer)，所以Reducer在拷貝數據的時候只需拷貝與自己對應的partition中的數據即可。每個Reducer會處理一個或者多個partition，但需要先將自己對應的partition中的數據從每個Map的輸出結果中拷貝過來。
接下來就是sort階段，也稱為merge階段，因為這個階段的主要工作是執行了歸并排序。從Map端拷貝到Reduce端的數據都是有序的，所以很適合歸并排序。最終在Reduce端生成一個較大的文件作為Reduce的輸入。
最后就是Reduce過程了，在這個過程中產生了最終的輸出結果，并將其寫到HDFS上。
總結
Hadoop 的數據處理過程的細節在實際項目中進行運用時，才會真正體會到深刻的原理，希望能遇到更多的有價值的實例。本篇借鑒了很多有價值的博客內容，在此表示感謝。
部分內容引用自：
1.Nutch和Lucene的區別
http://blog.csdn.net/qq_20545159/article/details/50433810
2.hadoop運行原理之shuffle
http://www.cnblogs.com/gwgyk/p/3997849.html
總結
以上是生活随笔為你收集整理的Hadoop 核心概念解析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Asp.Net操作Cookie总结
- 下一篇： watch命令