從故事開始：一個電商平台的用戶行為分析需求
最近，就職於一家電商公司的小李遇到了一些麻煩事，因為領導突然給他布置了一個任務，要把他們電商平台里所有的用戶在 PC 端和 App 上的瀏覽、點擊、購買等行為日志都存放起來集中分析，並形成報表，以供老板每天查看。
最初，小李覺得這個任務比較簡單，他的基本思路是將日志數據全部存入 MySQL 庫中，然后通過不同條件進行查詢、分析，得到老板想要的結果即可，但在具體實施過程中，小李遇到了前所未有的麻煩。
首先，這些數據量太大了，每天網站產生近 500G 的數據，這么大量的日志存儲到一個單機的 MySQL 庫中，已經難度很大了，磁盤空間經常告警；
其次，老板要的報表展示維度有 20 個之多，過多的維度會導致數據庫查詢 SQL 非常龐大，SQL 查詢效率極度低下，一個 SQL 查詢要跑十幾個小時，這導致前一天的分析報表，老板第二天無法准時看到，因為這件事，老板已經開始懷疑小李的工作能力了；
最后，老板要求這些電商數據至少保留一年時間，以供跨年分析、對比，而目前的架構，數據都存儲在 MySQL 庫中，還是單機，這顯然無法滿足老板的需求。
小李已經從事技術工作 3 年多了，還是有一定知識儲備的，經過查閱資料，他決定改造目前的技術架構。
首先，他將數據庫服務器增加到 5 台，並在每台服務器上配置了大容量 SSD 磁盤組，以解決存儲能力不足的問題；其次，對 MySQL 進行分庫分表處理，以解決單表過大，數據集中存儲查詢效率低下的問題。技術架構調整以后，小李覺得分庫分表坑太多，一個幾百行的大 SQL，加上跨庫 Join，以及各種復雜的計算，實現快速查詢，根本不現實。因此，仍然無法滿足老板的需求，更可怕的是，老板提出以后會增加實時查詢、分析的功能，這種需求，通過 MySQL 來實現，完全是不可能的。
難道就沒有能實現老板需求的技術方案嗎？無奈之下，小李又開始查閱各種資料，無意中發現了一個叫 Hadoop 的東西，好像這個東西能完成老板提出的功能需求。
Hadoop 與大數據之間到底是什么關系？
Hadoop 是 Apache 下的一個開源項目，說起 Hadoop，通常都會跟“大數據”這幾個字聯系在一起，但大數據並不等於 Hadoop，大數據本身是個很寬泛的概念，你可以把大數據理解為 Hadoop 的生態圈（或者泛生態圈）。
Hadoop 生態圈好比家里的廚房，廚房里有鍋、碗、瓢、盆、勺等各種做飯用具，這些用具類似 Hadoop 生態圈里的各種軟件，比如 HDFS、Hive、Pig、Spark、Storm 等，這些軟件各有各的用途，相互配合而又具有自己的獨立特性。比如，可以用湯鍋熬湯、也可以用炒鍋熬湯，熬好的湯可以直接在鍋里喝，也可以用碗配合勺子喝；我們用盆子洗菜，用廚刀切菜，將切好的菜放入炒鍋里炒。可以看到，廚房里面的每個餐具各有用途，功能相互配合而又重合，並且具有自己的獨立特性，用炒鍋熬湯雖然可行，但味道並不一定最好。
因此，在生態圈中，各種軟件堆疊組合也能工作，但未必是最佳選擇。而對於大數據運維來說，就是要實現 Hadoop 生態圈各種軟件的最優組合，熬出一碗最好喝的湯。
接着，我們來分析一下，Hadoop 生態圈架構是否能解決小李當前的困難：海量數據的存儲問題和數據查詢效率問題。
1、數據存儲：HDFS，一個分布式文件系統
HDFS，它是 Hadoop 技術體系中的核心基石，負責分布式存儲數據，你可以把它理解為一個分布式的文件系統。此文件系統的主要特征是數據分散存儲，一個文件存儲在 HDFS 上時會被分成若干個數據塊，每個數據塊分別存儲在不同的服務器上。
假如你有 100 台服務器，那么所有數據會平均分擔在這 100 台機器上。而且，為了保證數據安全，每個存儲在 HDFS 上的文件，可以設置不同的備份數。假如你設置了 3 個文件備份，只要你的服務器不是同時壞 3 個，那 HDFS 上面的數據都是安全的。
很帥氣吧？這個 HDFS 就解決了小李的兩個問題：存儲容量和數據安全。
2. 數據分析：MapReduce 計算引擎
數據存儲問題解決了，接下來數據該如何分析處理呢？
單機處理的話，已經證明過是不可能的，必須用多台服務器並行處理，那么就要考慮如何分配計算任務到多台機器。如果一台機器掛了，該如何重新啟動相應的分析任務，以及機器之間如何互相通信、交換數據以完成復雜的計算等。這就是馬上要講的 Hadoop 中的計算引擎，其有多種計算引擎，MapReduce 是第一代計算引擎，Tez 和 Spark 是第二代。
MapReduce 的強大在於分布式計算，也就是將計算任務分布在多個服務器上，因此服務器數量越多，計算速度就越快。
MapReduce 主要分為兩階段：Map 階段和 Reducer 階段。比如，你要讀取 HDFS 上一個大文件中某個 IP 出現的頻次，那么 Map 階段就是多台機器同時讀取這個文件內容的一個部分，然后分別統計出各自讀到的內容中此 IP 出現的頻次，這相當於是分散讀取；Reducer 階段是將 Map 階段的輸出結果作為輸入，然后進行整合、匯總，最終得到一個此 IP 出現次數的結果。
由此可以看出，MapReduce 的過程就是一個分分合合的過程，而這個分布式計算功能完美解決了小李在 MySQL 中查詢效率低下的問題。
那老板提出的實時查詢分析功能，Hadoop 這個生態圈能實現嗎？當然可以。
Hadoop 生態圈
我先帶你來了解下 Hadoop 生態圈的常用組件，讓你能夠對 Hadoop 生態圈有一個基本的了解和認知，至於這些組件的具體應用場景和使用細節，我會在后面的課時中逐一講述。
現在，你應該了解了大數據以及與 Hadoop 生態圈的關系，並且初步了解了 Hadoop 究竟能做什么。而實際上，Hadoop 生態圈的技術點還有很多，但並非每個技術點都要求掌握，你只需要掌握一套成熟的技術框架即可。
下圖展示了 Hadoop 生態圈常見的軟件和應用場景：
可以看出，Hadoop 的基礎是 HDFS 和 Yarn，在此基礎上有各種計算模型，如 MapReduce、Spark、HBase 等；而在計算模型上層，對應的是各種分布式計算輔助工具，如 Hive、Pig、Sqoop 等。此外，還有分布式協作工作 ZooKeeper 以及日志收集工具 Flume，這么多工具如何協作使用呢？這就是任務調度層 Oozie 的存在價值，它負責協調任務的有序執行。最頂層是 Hadoop 整個生態圈的統一管理工具，Ambari 可以為 Hadoop 以及相關大數據軟件使用提供更多便利。
下面我來依次介紹圖中的技術點。
1. HDFS（Hadoop 分布式文件系統）
HDFS 是 Hadoop 生態圈中提供分布式存儲支持的系統，上層的很多計算框架（Hbase、Spark 等）都依賴於 HDFS 存儲。
若要構建 HDFS 文件系統，不需要特有的服務器，普通 PC 即可實現，它對硬件和磁盤沒有任何特殊要求，也就是說，HDFS 可在低成本的通用硬件上運行。前面的介紹中，我們也看到了，它不但解決了海量數據存儲問題，還解決了數據安全問題。
為了更好的理解它的作用，我們來看一個 HDFS 分布式文件系統的實現原理圖：
可以看出，HDFS 主要由 NameNode 和 DataNode 兩部分組成。
NameNode 是 HDFS 的管理節點，它存儲了元數據（文件對應的數據塊位置、文件大小、文件權限等）信息，同時負責讀、寫調度和存儲分配；
DataNode 節點是真正的數據存儲節點，用來存儲數據。另外，在 DataNode 上的每個數據塊會根據設置的副本數進行分級復制，保證同一個文件的每個數據塊副本都不在同一個機器上。
2. MapReduce（分布式計算模型）離線計算
何為離線計算，其實就是非實時計算。
比如，老板讓小李今天出昨天電商網站的報表數據，這其實是對數據做離線計算；老板要馬上看到來自北京 App 端用戶的實時訪問數據，這就是實時計算。當然實時計算也不是完全實時，它一定有一個延時，只不過這個延時很短而已。
MapReduce 到現在已經 15 年了，這種 Map 加 Reduce 的簡單計算模型，解決了當時單機計算的缺陷，時至今日還有很多場景仍在使用這種計算模型，但已經慢慢不能滿足我們的使用需求了。大數據時代的今天，數據量都在 PB 級甚至 EB 級別，對數據的分析效率有了更高的要求。
於是，第二代計算模型產生了，如 Tez 和 Spark，它們通過大量使用內存、靈活的數據交換，更少的磁盤讀寫來提高分析效率。
3. Yarn（分布式資源管理器）
計算模型層出不窮，這么多計算模型如何協同工作、如何做好資源管理，就顯得至關重要了。於是，在 MapReduce 基礎上演變出了 Yarn 這個資源管理器，它的出現主要就是為了解決原始 Hadoop 擴展性較差、不支持多種計算模型的問題。
在YARN中，支持CPU和內存兩種資源管理，資源管理由ResourceManager（RM）、ApplicationMaster（AM）和NodeManager（NM）共同完成。其中，RM負責對各個NM上的資源進行統一管理和調度。而NodeManager則負責資源的供給和隔離。當用戶提交一個應用程序時，會創建一個用以跟蹤和管理這個程序的AM，它負責向RM申請資源，並要求NM啟動指定資源的任務。這就是YARN的基本運行機制。
最后，Yarn 作為一個通用的分布式資源管理器，它可以管理多種計算模型，如 Spark、Storm、MapReduce 、Flink 等都可以放到 Yarn 下進行統一管理。
4. Spark（內存計算）
Spark 提供了內存中的分布式計算能力，相比傳統的 MapReduce 大數據分析效率更高、運行速度更快。總結一句話：以內存換效率。
說到 Spark，不得不提 MapReduce。傳統的 MapReduce 計算過程的每一個操作步驟發生在內存中，但產生的中間結果會儲存在磁盤里，下一步操作時又會將這個中間結果調用到內存中，如此循環，直到分析任務最終完成。這就會產生讀取成本，造成效率低下。
而 Spark 在執行分析任務中，每個步驟也是發生在內存之中，但中間結果會直接進入下一個步驟，直到所有步驟完成之后才會將最終結果寫入磁盤。也就是說 Spark 任務在執行過程中，中間結果不會“落地”，這就節省了大量的時間。
在執行一個分析任務中，如果執行步驟不多，可能看不出 MapReduce 和 Spark 執行效率的區別，但是當一個任務有很多執行步驟時，Spark 的執行效率就體現出來了。
5. HBase（分布式列存儲數據庫）
在介紹 HBase 之前，我們首先了解兩個概念：面向行存儲和面向列存儲。
面向行存儲，這個應該接觸比較多，比如我們熟悉的 MySQL、Oracle 等就是此種類型的。面向行存儲的數據庫主要適合於事務性要求嚴格的場合，這種傳統關系型數據庫為了實現強一致性，通過嚴格的事務來進行同步，這就讓系統在可用性和伸縮性方面大大折扣。
面向列存儲的數據庫也叫非關系型數據庫（NoSQL），比如Cassandra、HBase等。這種數據庫通常將不同數據的同一個屬性值存在一起，在查詢時只遍歷需要的數據，實現了數據即是索引。因此，它的最大優點是查詢速度快，這對數據完整性要求不高的大數據處理領域，比如互聯網，猶為重要。
Hbase繼承了列存儲的特性，它非常適合需對數據進行隨機讀、寫操作、比如每秒對PB級數據進行幾千次讀、寫訪問是非常簡單的操作。 其次，Hbase構建在HDFS之上，其內部管理的文件全部存儲在HDFS中。這使它具有高度容錯性和可擴展性，並支持Hadoop mapreduce程序設計模型。
如果你的應用是交易歷史查詢系統、查詢場景簡單，檢索條件較少、每天有千萬行數據更新、那么Hbase將是一個很好的選擇。其實，行存儲和列存儲只是不同的維度而已，沒有天生的優劣，而大數據時代大部分的查詢模式決定了列式存儲優於行式存儲。
講到這里，突然發現，小李遇到的技術難題，其實用 HBase 也能實現。
6. Hive（數據倉庫）
小李打算在 Hadoop 生態平台上完成公司電商數據的存儲和分析了，但又遇到了難題，MapReduce 的程序寫起來很麻煩，如果通過寫 MapReduce 程序來實現老板的需求，不但要重新學習，而且功能實現也繁瑣。該怎么辦呢？
經過調研與查閱資料，一款 Hive 工具出現在他面前。Hive 定義了一種類似 SQL 的查詢語言（HQL），它可以將 SQL 轉化為 MapReduce 任務在 Hadoop 上執行。這樣，小李就可以用更簡單、更直觀的語言去寫程序了。
因此，哪怕你不熟悉 MapReduce 程序，只要會寫標准的 SQL 語句，也能對 HDFS 上的海量數據進行分析和計算。
7. Oozie（工作流調度器）
小李現在已經能夠熟練使用 Hive 對數據進行各種維度的分析了，由於老板要求定時給出報表數據，所以小李就將數據分析任務寫成腳本，然后放到操作系統的定時任務（Crontab）中定期執行。剛開始這種方式完全滿足了老板的要求，但隨着報表任務的增多，一個腳本已經無法滿足。
於是，小李根據不同的任務需求，寫了多個腳本程序，然后放到操作系統定時任務中去執行。這種方法大多時候都能正常完成分析任務，但也遇到了任務分析錯誤或失敗的情況，小李最終發現這是定時任務出現了問題。
原來在小李寫的多個腳本中，個別腳本有相互依賴性，也就是說，假定有腳本 A 和腳本 B，腳本 B 要執行的話，必須等待腳本 A 完成，否則腳本 B 啟動就沒有意義了。因此，他在操作系統定時任務中，通過設置腳本開始執行時間的差別來避免這種依賴性。
比如，腳本 A 凌晨 6 點執行，小李預估此腳本最多執行到 8 點就完成了，所以設置腳本 B 在 8:30 時啟動執行。可是，仔細一想，就覺得這種設置肯定存在問題，比如腳本 A 執行失敗，或者在 8:30 沒有完成怎么辦？
小李發現，某次任務執行失敗是因為他認為腳本 C 2 個小時肯定執行完，但事實上卻執行了 4 個多小時，由於當天的日志量非常大，分析時間也相應延長了，腳本 C 在預估的時間內沒有完成，而下個腳本 D 如約啟動，腳本 D 的執行要依賴於腳本 C 的輸出結果，因此腳本 D 肯定執行失敗。
如何解決這個問題呢？Oozie 出場了。Oozie 是一個基於工作流引擎的調度器，它其實就是一個運行在 Java Servlet 容器（如 Tomcat）中的 Javas Web 應用，你可以在它上面運行 Hadoop 的 Map Reduce 和 Pig 等任務，。
對於 Oozie 來說，工作流就是一系列的操作（如 Hadoop 的 MR，Pig 的任務、Shell 任務等），通過 Oozie 可以實現多個任務的依賴性。也就是說，一個操作的輸入依賴於前一個任務的輸出，只有前一個操作完全完成后，才能開始第二個。
Oozie 工作流通過 hPDL 定義（hPDL 是一種 XML 的流程定義語言），工作流操作通過遠程系統啟動任務。當任務完成后，遠程系統會進行回調來通知任務已經結束，然后再開始下一個操作。
8. Sqoop 與 Pig
小李還有一個苦惱，他要把原來存儲在 MySQL 中的數據導入 Hadoop 的 HDFS 上，是否能實現呢？這當然可以，通過 Sqoop（SQL-to-Hadoop）就能實現，它主要用於傳統數據庫和 Hadoop 之間傳輸數據。數據的導入和導出本質上是 MapreDuce 程序，充分利用了 MR 的並行化和容錯性。
通過 Hive 可以把腳本和 SQL 語言翻譯成 MapReduce 程序，扔給計算引擎去計算。Pig 與 Hive 類似，它定義了一種數據流語言，即 Pig Latin，它是 MapReduce 編程的復雜性的抽象，Pig Latin 可以完成排序、過濾、求和、關聯等操作，支持自定義函數。Pig 自動把 Pig Latin 映射為 MapReduce 作業，上傳到集群運行，減少用戶編寫 Java 程序的苦惱。
9. Flume（日志收集工具）
現在小李已經基本解決了老板提出的各種數據分析需求，數據分析任務在 Hadoop 上有條不紊的進行。現在電商平台的數據是通過 rsync 方式定時從電商服務器上同步到 Hadoop 平台的某台機器，然后通過這台機器 put 到 HDFS 上，每天定時同步一次，由於數據量很大，同步一次數據在一個小時左右，並且同步數據的過程會消耗大量網絡帶寬。小李想，有沒有更合適的數據傳輸機制，一方面可以保證數據傳輸的實時性、完整性，另一方面也能節省網絡帶寬。
通過 Flume 可以圓滿完成小李現在的困惑，那么什么是 Flume 呢？來個官方的概念，Flume 是將數據從產生、傳輸、處理並最終寫入目標路徑的過程抽象為數據流，在具體的數據流中，數據源支持在 Flume 中定制數據發送方，從而支持收集各種不同協議數據。
同時，Flume 數據流提供對日志數據進行簡單處理的能力，如過濾、格式轉換等。此外，Flume 還具有能夠將日志寫往各種數據目標（文件、HDFS、網絡）的能力。在 Hadoop 平台，我們主要使用的是通過 Flume 將數據從源服務器寫入 Hadoop 的 HDFS 上。
10. Kafka（分布式消息隊列）
相信我們都乘坐過地鐵，正常情況下先安檢后刷卡，最后進站上車，如果遇到上下班高峰期，地鐵的人流會很多，坐地鐵的順序就變成了先進入引流系統排隊，然后進行安檢，最后進站上車，從這里可以看出，在地鐵人流量大的時候會多一個“引流系統排隊”，通過這個引流系統，可以保證在人多的時候乘坐地鐵也能有條不紊的進行。
這個引流系統就跟我們要介紹的 Kafka 的作用非常類似，它在人和地鐵中間作為一個緩存，實現解耦合的作用。
專業術語來描述一下，現在是個大數據時代，各種商業、社交、搜索、瀏覽都會產生大量的數據。那么如何快速收集這些數據，如何實時的分析這些數據，是一個必須要解決的問題，同時，這也形成了一個業務需求模型，即生產者生產（Produce）各種數據、消費者（Consume）消費（分析、處理）這些數據。那么面對這些需求，如何高效、穩定的完成數據的生產和消費呢？這就需要在生產者與消費者之間，建立一個通信的橋梁，這個橋梁就是消息系統。從微觀層面來說，這種業務需求也可理解為不同的系統之間如何傳遞消息。
Kafka 是 Apache 組織下的一個開源系統，它的最大特性就是可以實時的處理大量數據以滿足各種需求場景：比如基於 Hadoop 平台的數據分析、低時延的實時系統、Storm/Spark 流式處理引擎等。Kafka 現在它已被多家大型公司作為多種類型的數據管道和消息系統使用。
11. ZooKeeper（分布式協作服務）
對集群技術應該並不陌生，就拿最簡單的雙機熱備架構來說，雙機熱備主要用來解決單點故障問題，傳統的方式是采用一個備用節點，這個備用節點定期向主節點發送 ping 包，主節點收到 ping 包以后向備用節點發送回復信息，當備用節點收到回復的時候就會認為當前主節點運行正常，讓它繼續提供服務。而當主節點故障時，備用節點就無法收到回復信息了，此時，備用節點就認為主節點宕機，然后接替它成為新的主節點繼續提供服務。
這種傳統解決單點故障的方法，雖然在一定程度上解決了問題，但是有一個隱患，就是網絡問題，可能會存在這樣一種情況：主節點並沒有出現故障，只是在回復響應的時候網絡發生了故障，這樣備用節點就無法收到回復，那么它就會認為主節點出現了故障；接着，備用節點將接管主節點的服務，並成為新的主節點，此時，集群系統中就出現了兩個主節點（雙 Master 節點）的情況，雙 Master 節點的出現，會導致集群系統的服務發生混亂。這樣的話，整個集群系統將變得不可用，為了防止出現這種情況，就需要引入 ZooKeeper 來解決這種問題。
ZooKeeper 是如何來解決這個問題的呢，這里以配置兩個節點為例，假定它們是“節點 A”和“節點 B”，當兩個節點都啟動后，它們都會向 ZooKeeper 中注冊節點信息。我們假設“節點A”鎖注冊的節點信息是“master00001”，“節點B”注冊的節點信息是“master00002”，注冊完以后會進行選舉，選舉有多種算法，這里以編號最小作為選舉算法，那么編號最小的節點將在選舉中獲勝並獲得鎖成為主節點，也就是“節點A”將會獲得鎖成為主節點，然后“節點B”將被阻塞成為一個備用節點。這樣，通過這種方式 ZooKeeper 就完成了對兩個 Master 進程的調度。完成了主、備節點的分配和協作。
如果“節點A”發生了故障，這時候它在 ZooKeeper 所注冊的節點信息會被自動刪除，而 ZooKeeper 會自動感知節點的變化，發現“節點 A”故障后，會再次發出選舉，這時候“節點 B”將在選舉中獲勝，替代“節點 A”成為新的主節點，這樣就完成了主、被節點的重新選舉。
如果“節點A”恢復了，它會再次向 ZooKeeper 注冊自身的節點信息，只不過這時候它注冊的節點信息將會變成“master00003”，而不是原來的信息。ZooKeeper 會感知節點的變化再次發動選舉，這時候“節點 B”在選舉中會再次獲勝繼續擔任“主節點”，“節點 A”會擔任備用節點。
通俗的講，ZooKeeper 相當於一個和事佬的角色，如果兩人之間發生了一些矛盾或者沖突，無法自行解決的話，這個時候就需要 ZooKeeper 這個和事佬從中進行調解，而和事佬調解的方式是站在第三方客觀的角度，根據一些規則（如道德規則、法律規則），客觀的對沖突雙方做出合理、合規的判決。
12. Ambari（大數據運維工具）
Ambari 是一個大數據基礎運維平台，它實現了 Hadoop 生態圈各種組件的自動化部署、服務管理和監控告警，Ambari 通過 puppet 實現自動化安裝和配置，通過 Ganglia 收集監控度量指標，用 Nagios 實現故障報警。目前 Ambari 已支持大多數 Hadoop 組件，包括 HDFS、MapReduce、Oozie、Hive、Pig、 Hbase、ZooKeeper、Sqoop、Kafka、Spark、Druid、Storm 等幾十個常用的 Hadoop 組件。
作為大數據運維人員，通過 Ambari 可以實現統一部署、統一管理、統一監控，可極大提高運維工作效率。
總結
到這里，已經介紹完了 Hadoop 生態圈常用的組件，相信你對它們的用途也有了大致了解，后面的課程中，我會詳細講解這些組件的應用與實踐，以便於你牢記掌握這些組件的使用。
今天的內容比較多，這源於大數據生態圈組件繁多以及應用的復雜性，但這都值得。如果說今天我希望你看完文章后，還能記住些什么，簡單的一句話就是：經典的大數據架構以及常用組件的功能。
最后，我想請你思考一個問題，你所在的企業里都用到了哪些大數據組件呢？也非常歡迎你在留言區和我們分享你眼中的大數據技術以及大數據應用架構。
大數據學習交流群239963844