Hadoop概要
到底是業務推動了技術的發展，還是技術推動了業務的發展，這個話題放在什麼時候都會惹來一些爭議。
隨著網際網路以及物聯網的蓬勃發展，我們進入了大資料時代。IDC預測，到2020年,全球會有44ZB的資料量。 傳統儲存和技術架構無法滿足需求 。在2013年出版的《大資料時代》一書中，定義了大資料的5V特點：Volume(大量)、Velocity(高速)、Variety(多樣)、Value(低價值密度)、Veracity(真實性)。
大資料學習群：119599574
當我們把時間往回看10年，來到了2003年，這一年Google發表《Google File System》，其中提出一個GFS叢集中由多個節點組成，其中主要分為兩類：一個Master node，很多Chunkservers。之後於2004年Google發表論文並引入MapReduce。2006年2月，Doug Cutting等人在Nutch專案上應用GFS和 MapReduce思想,並演化為Hadoop專案。
Doug Cutting曾經說過他非常喜歡自己的程式被千萬人使用的感覺，很明顯，他做到了;下圖就是本尊照片，帥氣的一塌糊塗
2008年1月, Hadoop成為Apache的開源專案。
Hadoop的出現解決了網際網路時代的海量資料儲存和處理，其是一種支援分散式計算和儲存的框架體系。假如把Hadoop叢集抽象成一臺機器的話，理論上我們的硬體資源(CPU、Memoery等)是可以無限擴充套件的。
Hadoop通過其各個元件來擴充套件其應用場景，例如離線分析、實時處理等。
Hadoop相關元件介紹
本文主要是依據Hadoop2.7版本，後面沒有特殊說明也是按照此版本
HDFS
HDFS,Hadoop Distributed File System (Hadoop分散式檔案系統)被設計成適合執行在通用硬體(commodity hardware)上的分散式檔案系統。它和現有的分散式檔案系統有很多共同點，例如典型的Master/Slave架構(這裡不準備展開介紹);然而HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。
關於HDFS主要想說兩點。
HDFS中的預設副本數是3，這裡涉及到一個問題為什麼是3而不是2或者4。
機架感知(Rack Awareness)。
只有深刻理解了這兩點才能理解為什麼Hadoop有著高度的容錯性，高度容錯性是Hadoop可以在通用硬體上執行的基礎。
Yarn
Yarn,Yet Another Resource Negotiator(又一個資源協調者)，是繼Common、HDFS、MapReduce之後Hadoop 的又一個子專案。Yarn的出現是因為在Hadoop1.x中存在如下幾個問題：
擴充套件性差。JobTracker兼備資源管理和作業控制兩個功能。
可靠性差。在Master/Slave架構中,存在Master單點故障。
資源利用率低。Map Slot (1.x中資源分配的單位)和Reduce Slot分開,兩者之間無法共享。
無法支援多種計算框架。MapReduce計算框架是基於磁碟的離線計算 模型,新應用要求支援記憶體計算、流式計算、迭代式計算等多種計算框架。
Yarn通過拆分原有的JobTracker為：
全域性的 ResourceManager(RM)。
每個Application有一個ApplicationMaster(AM)。
由Yarn專門負責資源管理,JobTracker可以專門負責作業控制,Yarn接替 TaskScheduler的資源管理功能,這種鬆耦合的架構方式 實現了Hadoop整體框架的靈活性。
Hive
Hive的是基於Hadoop上的資料倉儲基礎構架，利用簡單的SQL語句(簡稱HQL)來查詢、分析儲存在HDFS的資料。並且把SQL語句轉換成MapReduce程式來資料的處理。
Hive與傳統的關聯式資料庫主要區別在以下幾點：
儲存的位置 Hive的資料儲存在HDFS或者Hbase中，而後者一般儲存在裸裝置或者本地的檔案系統中。
資料庫更新 Hive是不支援更新的，一般是一次寫入多次讀寫。
執行SQL的延遲 Hive的延遲相對較高，因為每次執行HQL需要解析成MapReduce。
資料的規模上 Hive一般是TB級別，而後者相對較小。
可擴充套件性上 Hive支援UDF/UDAF/UDTF，後者相對來說較差。
HBase
HBase，是Hadoop Database，是一個高可靠性、高效能、面向列、可伸縮的分散式儲存系統。它底層的檔案系統使用HDFS，使用Zookeeper來管理叢集的HMaster和各Region server之間的通訊，監控各Region server的狀態，儲存各Region的入口地址等。
HBase是Key-Value形式的資料庫(類比Java中的Map)。那麼既然是資料庫那肯定就有表，HBase中的表大概有以下幾個特點：
大：一個表可以有上億行，上百萬列(列多時，插入變慢)。
面向列：面向列(族)的儲存和許可權控制，列(族)獨立檢索。
稀疏：對於為空(null)的列，並不佔用儲存空間，因此，表可以設計的非常稀疏。
每個cell中的資料可以有多個版本，預設情況下版本號自動分配，是單元格插入時的時間戳。
HBase中的資料都是位元組，沒有型別( 因為系統需要適應不同種類的資料格式和資料來源，不能預先嚴格定義模式 )。
Spark
Spark是由伯克利大學開發的分散式計算引擎，解決了海量資料流式分析的問題。Spark首先將資料匯入Spark叢集，然後再通過基於記憶體的管理方式對資料進行快速掃描 ，通過迭代演算法實現全域性I/O操作的最小化，達到提升整體處理效能的目的，這與Hadoop從“計算”找“資料”的實現思路是類似的。
Other Tools
Phoneix
基於Hbase的SQL介面，安裝完Phoneix之後可以適用SQL語句來操作Hbase資料庫。
Sqoop
Sqoop的主要作用是方便不同的關聯式資料庫將資料遷移到Hadoop，支援多種資料庫例如Postgres，Mysql等。
Hadoop叢集硬體和拓撲規劃
規劃這件事情並沒有最優解，只是在預算、資料規模、應用場景下之間的平衡。
硬體配置
Raid
首先Raid是否需要，在回答這個問題之前，我們首先了解什麼是Raid0以及Raid1。
Raid0是提高儲存效能的原理是把連續的資料分散到多個磁碟上存取，這樣，系統有資料請求就可以被多個磁碟並行的執行，每個磁碟執行屬於它自己的那部分資料請求。這種資料上的並行操作可以充分利用匯流排的頻寬，顯著提高磁碟整體存取效能。( 來源百度百科 )
當Raid0與Hadoop結合在一起會產生什麼影響呢?
優勢：
提高IO。
加快讀寫。
消除單塊磁碟的讀寫過熱的情況。
然而在Hadoop系統中，當Raid0中的一塊磁碟資料出現問題(或者讀寫變得很慢的時候)時，你需要重新格式化整個Raid，並且資料需要重新恢復到DataNode中。整個週期會隨著資料的增加而逐步增加。
其次Raid0的瓶頸是Raid中最慢的那一塊盤，當你需要替換其中最慢的那一塊盤的時候就會重新格式化整個Raid然後恢復資料。
RAID 1通過磁碟資料映象實現資料冗餘，在成對的獨立磁碟上產生互 為備份的資料。當原始資料繁忙時，可直接從映象拷貝中讀取資料，因此RAID 1可以提高讀取效能。RAID 1是磁碟陣列中單位成本最高的，但提供了很高的資料安全性和可用性。當一個磁碟失效時，系統可以自動切換到映象磁碟上讀寫，而不需要重組失效的資料。( 來源百度百科 )
所以Raid1的本質是提高資料的冗餘，而Hadoop本身預設就是3個副本，所以當存在Raid1時候，副本數將會變成6，將會提高系統對於硬體資源的需求。
所以在Hadoop系統中不建議適用Raid的，其實更加推薦JBOD，當一塊磁碟出現問題時，直接unmount然後替換磁碟(很多時候直接換機器的)。
叢集規模及資源
這裡主要依據資料總量來推算叢集規模，不考慮CPU以以及記憶體配置。
一般情況來說，我們是根據磁碟的的需求來計算需要機器的個數。
首先我們需要調研整個系統的當量以及增量資料。
舉個例子來說，假如現在系統中存在8T的資料，預設副本數為3，那麼所需要的儲存=8T*3/80% = 30T左右。
每臺機器儲存為6T，則資料節點個數為5。
加上Master節點，不考慮HA的情況下，大概是6臺左右機器。
軟體配置
根據業務需求是否需要配置HA方案進行劃分,由於實際場景複雜多變，下面方案僅供參考。
1.非HA方案
一般考慮將所有的管理節點放在一臺機器上，同時在資料節點上啟動若干個Zookeeper服務(奇數)。
管理節點：NameNode+ResourceManager+HMaster
資料節點：SecondaryNameNode
資料節點：DataNode +RegionServer+Zookeeper
2.HA方案
在HA方案中，需要將Primary Node 與Standby Node 放在不同的機器上，一般在實際場景中，考慮到節省機器，可能會將不同的元件的Master節點進行交叉互備，如A機器上有Primary NameNonde 以及 Standby HMaster ，B機器上有Standby NameNode 以及 Primary Master。
管理節 點：NameNode(Primary)+HMaster(Standby)
管理節點：NameNode(Standby)+HMaster(Primary)
管理節點：ResourceManager
資料節點：DataNode +RegionServer+Zookeeper
Hadoop的設計目標和適用場景
其實在上面的 Hadoop概要 上我們就可以看到Hadoop當初的設計目標是什麼。Hadoop在很多場合下都是大資料的代名詞。其主要是用來處理半結構以及非結構資料(例如MapReduce)。
其本質也是通過Mapreduce程式來將半結構化或者非結構化的資料結構化繼而來進行後續的處理。
其次由於Hadoop是分散式的架構，其針對的是大規模的資料處理，所以相對較少的資料量並不能體現Hadoop的優勢。例如處理GB級別的資料量，利用傳統的關係型資料庫的速度可能相對較快。
基於上述來看Hadoop的適用場景如下：
離線日誌的處理(包括ETL過程，其實本質就是基於Hadoop的資料倉儲)。
大規模平行計算。
Hadoop的架構解析
Hadoop由主要由兩部分組成：
分散式檔案系統(HDFS)，主要用於大規模的資料儲存。
分散式計算框架MapReduce，其主要用來對HDFS上的資料進行運算處理。
HDFS主要由NameNode(Master)以及DataNode(Slave)組成。前者主要是對名稱空間管理：如對HDFS中的目錄、檔案和塊做類似 檔案系統的建立、修改、刪除、列表檔案和目錄等基本操作。後者儲存實際的資料塊，並與NameNode保持一定的心跳。
MapReduce2.0的計算框架本質是有Yarn來完成的，Yarn是關注點分離的思路，由Yarn專門負責資源管理 ，JobTracker可以專門負責作業控制，Yarn接替 TaskScheduler的資源管理功能，這種鬆耦合的架構方式 實現了Hadoop整體框架的靈活性。
MapReduce工作原理和案例說明
MapReduce可謂Hadoop的精華所在，是用於資料處理的程式設計模型。MapReduce從名稱上面可以看到Map以及Reduce兩個部分。其思想類似於先分後合，Map對與資料進行抽取轉換，Reduce對資料進行彙總。其中需要注意的是Map任務將輸出結果儲存在本地磁碟,而不是HDFS。
在我們執行MapReduce的過程中，根據Map與資料庫的關係大體上可以分為三類：
資料本地
機架本地
跨機架
從上述幾種可以看出來，假設一個MapReduce過程中存在大量的資料移動對於執行效率來說是災難性。
MapReduce資料流
從資料流來看MapReduce的關係大體可以分為以下幾類：
單Reduce
多Reduce
無Reduce
然而無論什麼MapReduce關係如何，MapReduce的執行流程都如下圖所示：
其中在執行每個Map Task時，無論Map方法中執行什麼邏輯，最終都是要把輸出寫到磁碟上。如果沒有Reduce階段，則直接輸出到HDFS上。如果有Reduce作業，則每個Map方法的輸出在寫磁碟前線在記憶體中快取。每個Map Task都有一個環狀的記憶體緩衝區，儲存著Map的輸出結果，預設100m，在每次當緩衝區快滿的時候由一個獨立的執行緒將緩衝區的資料以一個溢位檔案的方式存放到磁碟，當整個Map Task結束後再對磁碟中這個Map Task產生的所有溢位檔案做合併，被合併成已分割槽且已排序的輸出檔案。然後等待Reduce Task來拉資料。
上述這個過程其實也MapReduce中赫赫有名的 Shuffle 過程。
MapReduce實際案例
Raw Data
原始的資料檔案是普通的文字檔案，每一行記錄中存在一個年份以及改年份中每一天的溫度。
Map
Map過程中，將每一行記錄都生成一個key，key一般是改行在檔案中的行數(Offset)，例如下圖中的0，106代表第一行、第107行。其中 粗體 的地方代表年份以及溫度。
Shuffle
該過程中獲取所要的記錄組成鍵值對{年份，溫度}。
Sort
將上一步過程中的相同key的value組成一個list，即{年份，List<溫度>}，傳到Reduce端。
Reduce
Reduce端對list進行處理，獲取最大值，然後輸出到HDFS中。
大資料學習QQ群：119599574