一、前言

大資料這個概念不用我提大家也聽過很多了，前幾年各種公開論壇、會議等場合言必及大資料，說出來顯得很時髦似的。有意思的是最近擁有這個待遇的名詞是“人工智慧/AI”，當然這是後話。

眾所周知，大資料的發展是來源於Google三駕馬車，分別是：

• Google File System（GFS） —2003
• MapReduce —2004
• Bigtable —2006

不得不說，Google真的是一家牛逼的公司，開源了這些思想造福了全球的IT事業。不過有意思的是，這三篇論文一開始並不是大資料相關的，而是為了更好地服務谷歌自家的搜尋業務。基於此，出現了傳統的大資料框架三大元件：HDFS、MapReduce、Hbase，這就是Hadoop最開始的樣子。

二、Hadoop簡介

Hadoop是一個用Java編寫的Apache開源框架，現在我們提到Hadoop可能有兩種所指，一種是Hadoop幾個基本模組，另一種是可以安裝在Hadoop之上的附加軟體包的集合，例如Hive、Impala、Oozie、Hue等等等等，也稱之為Hadoop家族。所以說，Hadoop技術產品是十分豐富並且在一直不停地演化，有些技術可能幾年後不流行了，又或者產生了新的技術。所以在大資料領域是需要不斷地學習的，這也導致了大資料領域的工作一般待遇都很豐厚，因為要求真的還蠻高的，需要掌握的技術線比較長。
隨便丟張圖瞭解下（圖隨便找的，有些技術可能已經不流行了，有些目前流行的技術沒有）：

Hadoop基本框架介紹

• Hadoop Common：這些是其他Hadoop模組所需的Java庫和實用程式。這些庫提供檔案系統和作業系統級抽象，幷包含啟動Hadoop所需的Java檔案和指令碼；
• Hadoop YARN：這是一個用於作業排程和叢集資源管理的框架；
• Hadoop Distributed File System (HDFS™)：分散式檔案系統，提供對應用程式資料的高吞吐量訪問；
• Hadoop MapReduce：這是基於YARN的用於並行處理大資料集的系統。

MapReduce

實際上是兩個不同的任務：
Map（對映）：把讀入的資料用相同的方法拆分成小資料塊，然後把這些小資料塊分發到不同的工作節點上。每一個節點迴圈處理同樣的事，這就是一個分散式計算的過程。
Reduce（歸併）：此任務將map任務的輸出作為輸入，並將這些資料元組合併為較小的元組集合。 reduce任務總是在map任務之後執行。
圖解：

HDFS

HDFS是GFS的開源實現，它使用主/從結構，其中主節點由管理檔案系統元資料的單個NameNode和儲存實際資料的一個或多個從節點DataNode組成。HDFS名稱空間中的檔案被拆分為幾個塊，這些塊儲存在一組DataNode中。 NameNode決定塊到DataNode的對映。DataNodes負責與檔案系統的讀寫操作。它們還根據NameNode給出的指令來處理塊建立，刪除和複製。
HDFS架構圖：

YARN

舊的MapReduce過程是通過JobTracker和TaskTracker來完成的：

• JobTracker: 負責資源管理，跟蹤資源消耗和可用性，作業生命週期管理（排程作業任務，跟蹤進度，為任務提供容錯）
• TaskTracker: 載入或關閉任務，定時報告任務狀態

舊MapReduce圖示：

可以一眼看出JobTracker是核心所在，存在單點問題和資源利用率問題。所以出現了新的YARN架構。
YARN將JobTracker的職責進行拆分，將資源管理和任務排程監控拆分成獨立的程序：一個全域性的資源管理和一個單點的作業管理。ResourceManager和NodeManager提供了計算資源的分配和管理，而ApplicationMaster則完成應用程式的執行。

• ResourceManager: 全域性資源管理和任務排程
• NodeManager: 單個節點的資源管理和監控
• ApplicationMaster: 單個作業的資源管理和任務監控

YARN架構圖示：

現在的Hadoop架構長這樣：

可以看出，一些Hadoop家族的技術產品也是通過YARN和Hadoop聯動的，YARN作為資源排程器起到一箇中央管理的作用，這麼多技術工具都在同一個叢集上運轉，大家互相配合協調有序工作，就是依賴於YARN的分配管理。

三、Hadoop家族產品介紹

大資料領域的技術產品茫茫多，挑幾個我用過的或者很重要的元件簡單介紹下。

Hive

MapReduce的程式寫起來是一點都不方便，所以需要更高層更抽象的語言來描述演算法和資料處理過程。於是Hive誕生了，它用類SQL語言來描述MapReduce，稱之為HQL。這簡直是個偉大發明。大量的資料分析人員終於也能直接使用Hadoop技術，我的SQL入門就是在Hive上操作的。Hive現在是Hadoop大資料倉庫的核心工具，它是由Facebook貢獻的，感謝臉書，感恩。

Impala

跟Hive一樣，也提供類SQL語言來查詢處理資料，稱之為Impala SQL。它是一種實時互動的查詢工具，不經由MapReduce批處理，而是通過使用分散式查詢引擎直接讀取HDFS或HBase中的內容，大大降低延遲。總結下，Hive適合於長時間的批處理查詢分析，而Impala適合於實時互動式SQL查詢。
就我個人的使用體會看，Impala的容錯性沒有Hive好，很多Hive能執行的SQL，在Impala中可能報錯，不過Impala的查詢速度的確甩開Hive很多，這也是MapReduce的侷限性所在（這也導致了後續Spark的誕生），而且Impala也不支援UDF（自定義函式擴充套件，實現很多SQL難以實現或不好實現的功能）。所以在很多時候，我們都是Hive和Impala配合著使用，各有優劣。

Oozie

一個基於工作流引擎的開源框架。它能夠提供對Hadoop MapReduce和Pig Jobs的任務排程與協調。當我們需要讓一些資料處理過程自動週期地執行時會需要它，在Oozie上設定好工作流後，可以實現資料的自動匯入HDFS-清洗-處理-匯出同步的過程。

HBase

構建在HDFS之上的分散式，面向列的資料庫。HDFS缺乏隨即讀寫操作，HBase正是為此而出現。在需要實時讀寫、隨機訪問超大規模資料集時，可以使用HBase。它不是關係型資料庫，也不支援SQL，它是一種典型的NoSQL（Not Only SQL）。也是Google經典論文Bigtable的開源實現。

Storm

流計算平臺，為了達到更快更實時的資料更新，在資料流進來的時候就進行處理。流計算基本無延遲，但劣勢是不靈活，你想要處理的資料必須預先設計好，所以並不能完全替代批處理系統。

Spark

一個快速、通用的大規模資料處理引擎，在Hadoop的整個生態系統中，Spark和MapReduce在同一個層級，即主要解決分散式計算框架的問題。至於為什麼會產生Spark，是因為Hadoop的計算框架MapReduce存在著侷限性和不足。比如抽象層次低，程式碼不好寫；表達力欠缺、中間結果儲存在HDFS中，速度不夠快；延時高，只適合批處理不適合互動處理和實時處理。所以Spark的誕生就是為了解決這些問題，它的中間輸出結果可以儲存在記憶體中（記憶體放不下會寫入磁碟），避免了對HDFS的大量的讀寫，減少了I/O的開銷。
可以說，Spark是對Hadoop MapReduce的改進，同時又相容Hadoop家族，它可以執行在YARN之上，負責儲存的仍然是HDFS，它替代的是MapReduce計算框架，獲取更高更快更強的計算速度。上層的話也有用對SQL的支援，叫做Spark SQL，也有Hive ON Spark的專案繼續使用我們可愛的Hive。所以說，Spark是有一定的野心來對Hadoop取而代之的，而且這樣的趨勢來越來越明顯。

其他

還有些我不太瞭解的就簡單提及：Zookeeper是高一致性的分佈存取協同系統；Mahout是分散式機器學習庫；Sqoop是異構資料來源海量資料互動工具。當然這個工具我沒用過，我用的是阿里開源的資料同步工具：DataX。

四、後話—Hadoop版本

Hadoop的部署是比較麻煩的，我自己也只是實現過偽分散式模式的部署，還是按照教程一步步來的，很多步驟都不是很明白到底在做什麼，對於Linux和Java精通的程式設計師來說可能過程會比較友好。
Hadoop實際上有很多版本，有Apache Hadoop，這是開源版本，也叫社群版。實際上所有其他的發行版都是基於此衍生出來的。因為Apache Hadoop是開源的，允許任何人修改並作為商業版本釋出。
最有名的發行版當屬Cloudera版本（CDH）和Hortonworks版本（HDP）了，其中Cloudera可是貢獻了很多Hadoop家族產品技術的公司，CDH也成為了很多人的選擇。有意思的是這些發行版也是免費的。
對於大公司來說，為了靈活和實現高度的定製化，基本會選擇Apache Hadoop，不過這需要一個Hadoop開發團隊來維護，小公司就會選擇付費的商業版，有專門的技術支援來解決疑問，也不用維持一個團隊，保留少量的管理員即可。