大數據技術原理與應用——Hadoop 再探討

大數據技術原理與應用——Hadoop 再探討

9.1 Hadoop 的優化與發展

Hadoop 的侷限和不足

1.抽象層次低。
2.表達能力有限。
3.開發者自己管理作業之間的依賴關係。
4.難以看到程序整體邏輯。
5.執行迭代操作效率低。
6.資源浪費。
7.實時性差。

Hadoop 的改進和提升

主要體現在兩個方面：
一方面：Hadoop 自身兩大核心組件，MapReduce 和 HDFS 的架構設計改進。
另一方面：Hadoop 生態系統其它組件的不斷豐富，包括 Pig、Tez、Spark 和 Kafka 等。
Hadoop 模塊的自身改進：從1.0到2.0

組件	Hadoop1.0的問題	Hadoop2.0的改進
HDFS	第一名稱節點，存在單點失效問題	設計了HDFS HA，提供名稱節點熱備機制
HDFS	單一名稱節點，無法實現資源隔離	設計了HDFS Federation管理多個命名空間
MapReduce	資源管理效率低	設計了新的資源管理框架YARN

不斷完善的 Hadoop 生態系統

組件	功能	解決 Hadoop 中存在的問題
Pig	處理大規模數據的腳本語言，用戶只需要編寫幾條簡單的語句，系統會自動轉換爲MapReduce作業	抽象層次低，需要手工編寫大量的代碼
Spark	基於內存的分佈式並行編程框架，具有較高的實時性，並且較好支持迭代計算	延遲高，而且不適合執行迭代計算
Oozie	工作流和協作服務引擎，協調Hadoop上運行的不同任務	沒有提供作業（Job）之間的依賴關係管理機制，需要用戶自己處理作業之間依賴關係
Tez	支持DAG作業的計算框架，對作業的操作進行重新分解和組合，形成一個大的DAG作業，減少不必要操作	不同的MapReduce任務之間存在重複操作，降低了效率
Kafka	分佈式發佈訂閱消息，一般作爲企業大數據分析平臺的數據交換樞紐，不同類型的分佈式系統可以統一接入到Kafka，實現和Hadoop各個組件之間的不同類型數據的實時高效交換	Hadoop生態系統中各個組件和其他產品之間缺乏統一的、高效的數據交換中介

9.2 HDFS2.0的新特性

HDFS HA

爲了解決單點故障問題，HDFS2.0採用了 HA（High Availability）架構。在一個典型的 HA 集羣中，一般設置兩個名稱節點，其中一個名稱節點處於“活躍（Active）”狀態，另一個處於“待命（Standby）”狀態。處於活躍狀態的名稱節點負責對外處理所有客戶端的請求，而處於待命狀態的名稱節點則作爲備用節點，保存了足夠多的系統元數據，當名稱節點出現故障時提供快速恢復能力。也就是說，在 HDFS HA 中，處於待命狀態的名稱節點提供了“熱備份”，一旦活躍名稱節點出現故障，就可以立即切換到待命名稱節點，不會影響到系統的正常對外服務。

HDFS Federation

HDFS1.0中存在的問題
1.單點故障問題
2.不可以水平擴展
3.系統整體性能所限於單個名稱節點的吞吐量
4.單個名稱節點難以提供不同程序之間的隔離性
5.HDFS HA 是熱備份，提供高可用性，但是無法解決可擴展性、系統性能和隔離性

HDFS 聯邦的設計

HDFS 聯邦中的名稱節點提供了命名空間和塊管理功能。在 HDFS 聯邦中，所有名稱節點會共享底層的數據節點存儲資源。每個數據節點要向集羣中所有的名稱節點註冊，並週期性地向名稱節點發送“心跳”和塊信息，報告自己的狀態，同時也會處理來自名稱節點的指令。

HDFS 聯邦的訪問方式

對於 HDFS 聯邦中的多個命名空間，可以採用客戶端掛載表（Client Side Mount Table）方式進行數據共享和訪問。每個陰影三角形代表一個獨立的命名空間，上方空白三角形表示從客戶方向去訪問下面子命名空間。客戶可以訪問不同的掛載點來訪問不同的子命名空間。這就是 HDFS 聯邦中命名空間管理的基本原理，即把各個命名空間掛載到全局“掛載表”（Mount-table）中，實現數據全局共享；同樣地，命名空間掛載到個人的掛載表中，就成爲應用程序可見的命名空間。

HDFS 聯邦相對於 HDFS 1.0的優勢
1.HDFS 集羣可擴展性。多個名稱節點各自分管一部分目錄，使得一個集羣可以擴展到更多節點，不再像 HDFS 1.0中那樣由於內存的限制制約文件存儲數目。
2.性能更高效。多個名稱節點管理不同的數據，且同時對外提供服務，將爲用戶提供更高的讀寫吞吐率。
3.良好的隔離性。用戶可根據需要將不同業務數據交由不同名稱節點管理，這樣不同業務之間影響很小。

需要注意的是，HDFS 聯邦並不能解決單點故障問題，也就是說，每個名稱節點都存在單點故障問題，需要爲每個名稱節點部署一個後備名稱節點，以應對名稱節點宕機後對業務產生的影響。

9.3 新一代資源管理調度框架 YARN

MapReduce 1.0的缺陷

1.存在單點故障。
2.JobTracker“大包大攬”導致任務過重。
3.容易出現內存溢出。
4.資源劃分不合理。

YARN 設計思路

在 Hadoop 1.0中，其核心子項目 MapReduce 1.0既是一個計算框架，也是一個資源管理調度框架。到了 Hadoop 2.0以後，MapReduce 1.0中的資源管理調度功能被單獨分離出來形成了 YARN，它是一個純粹的資源管理調度框架，而不是一個計算框架；而被剝離了資源管理調度功能的 MapReduce 框架就變成了 MapReduce 2.0，它是運行在 YARN 之上的一個純粹的計算框架，不再自己負責資源調度管理服務，而是由 YARN 爲其提供資源管理調度服務。

YARN 體系結構

YARN 各個組件的功能

• ResourceManager：
  1.處理客戶端請求
  2.啓動/監控 ApplicationMaster
  3.監控 NodeManager
  4.資源分配與調度
• ApplicationMaster：
  1.爲應用程序申請資源，並分配給內部任務
  2.任務調度、監控與容錯
• NodeManager：
  1.單個節點上的資源管理
  2.處理來自 ResourceManger 的命令
  3.處理來自 ApplicationMaster 的命令

在集羣部署方面，YARN 的各個組件和 Hadoop 集羣中的其他組件進行統一部署的。YARN 的 ResourceManager 組件和 HDFS 的名稱節點（NameNode）部署在一個節點上，YARN 的 ApplicationMaster 及 NodeManager 是和 HDFS 的數據節點（DataNode）部署在一起的。YARN 中的容器代表了 CPU、內存、網絡等計算資源，它也是和 HDFS 的數據節點一起的。

YARN 工作流程

1.用戶編寫客戶端應用程序，向 YARN 提交應用程序，提交的內容包括 ApplicationMaster 程序、啓動 ApplicationMaster 的命令、用戶程序等。
2.YARN 中的 ResourceManager 負責接收和處理來自客戶端的請求，爲應用程序分配一個容器，在該容器中啓動一個 ApplicationMaster。
3.ApplicationMaster 被創建後會首先向 ResourceManager 註冊，從而使得用戶可以通過 ResourceManager 來直接查看應用程序的運行狀態，
4.ApplicationMaster 採用輪詢的方式通過 RPC 協議向 ResourceManager 申請資源。
5.ResourceManager 以“容器”的形式向提出申請的 ApplicationMaster 分配資源，一旦 ApplicationMaster 申請到資源後，就會與該容器所在的 NodeManager 進行通信，要求它啓動任務。
6.當 ApplicationMaster 要求容器啓動任務時，它會爲任務設置好運行環境（包括環境變量、JAR 包、二進制程序等），然後將任務啓動命令寫到一個腳本中，最後通過在容器中運行該腳本來啓動任務。
7.各個任務通過某個 RPC 協議向 ApplicationMaster 彙報自己的狀態和進度，讓 ApplicationMaster 可以隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啓動任務。
8.應用程序運行完成後，ApplicationMaster 向 ResourceManager 的應用程序管理器註銷並關閉自己。若 ApplicationMaster 因故失敗，ResourceManager 中的應用程序管理器會檢測到失敗的情形，然後將其重新啓動，直到所有的任務執行完畢。

YARN 框架與 MapReduce1.0 框架的對比分析

總體而言，YARN 相當於 MapReduce1.0 來說具有以下優勢：
（1）大大減少了承擔中心服務功能的 ResourceManager 的資源消耗。
（2）MapReduce1.0 既是一個計算框架，又是一個資源管理調度框架，但是隻能支持 MapReduce 編程模型。
（3）YARN 中的資源管理比 MapReduce1.0 更加高效。

YARN 的發展目標

YARN 的目標就是實現“一個集羣多個框架”，爲什麼？
一個企業當中同時存在各種不同的業務應用場景，需要採用不同的計算框架
MapReduce 實現離線批處理
使用 Impala 實現實時交互式查詢分析
使用 Storm 實現流式數據實時分析
使用 Spark 實現迭代計算

爲了避免不同類型應用之間互相干擾，企業就需要把內部的服務器拆分成多個集羣，分別安裝運行不同的計算框架，即“一個框架一個集羣”。

YARN 的目標就是實現“一個集羣多個框架”，即在一個集羣上部署一個統一的資源調度管理框架 YARN，在 YARN 之上可以部署其他各種計算框架。
由 YARN 爲這些計算框架提供統一的資源調度管理服務，並且能夠根據各種計算框架的負載需求，調整各自佔用的資源，實現集羣資源共享和資源彈性收縮。
可以實現一個集羣上的不同應用負載混搭，有效提高了集羣的利用率。
不同計算框架可以共享底層存儲，避免了數據集跨集羣移動。

9.4 Hadoop 生態系統中具有代表性的功能組件

Pig

通過配合使用 Pig 和 Hadoop，讓兩者結合起來使用在處理海量數據的時候就可以達到事半功倍的效果，比使用 Java 和 C++ 語言編寫 MapReduce 難度要小很多，而且用更少的代碼量，實現了相同的數據處理分析。

• 通過 LOAD 語句去文件系統讀取數據
• 通過一系列“轉換”語句對數據進行處理
• 通過 STORE 語句把處理結果輸出到文件當中去或者用 DUMP 語句把處理結果輸出到屏幕上面
  
  下面是一個採用 Pig Latin 語言編寫的應用程序實例，實現對用戶訪問網頁情況的統計分析
  
  
  Pig 的應用場景
  

Tez

1.Tez 是 Apache 開源的支持 DAG 作業的計算框架，它直接源於 MapReduce 框架
2.核心思想是將 Map 和 Reduce 兩個操作進一步拆分


分解後的元操作可以任意靈活組合，產生新的操作
經過一些控制程序組裝後，可形成一個大的 DAG 作業
通過 DAG 作業的方式運行 MapReduce 作業，提供程序運行的整體處理邏輯
Hortonworks 把 Tez 應用到數據倉庫 Hive 的優化中，使得性能提升了約100倍

Tez 的優化主要體現在
1.去除連續兩個作業之間的“寫入 HDFS”
2.去除每個工作流中多餘的 Map 階段


（Tez+Hive）與 Impala、Dremel 和 Drill 的區別
Tez 在解決 Hive、Pig 延遲大、性能低等問題的思路，是和那些支持實時交互式查詢分析的產品（如 Impala、Dremel 和 Drill 等）是不同的。
比如，針對 Hive 數據倉庫進行優化的“Tez+Hive”解決方案，仍採用 MapReduce 計算框架，但是對 DAG 的作業依賴關係進行了裁剪，並將多個小作業合併成一個大作業，這樣，不僅計算量減少了，而且寫 HDFS 次數也會大大減少。

Spark 和 Kafka

Hadoop 缺陷
1.其 MapReduce 計算模型延遲過高，無法勝任實時，快速計算的需求因而只適用於離線批處理的應用場景。
2.中間結果寫入磁盤，每次運行都從磁盤讀數據。
3.在前一個任務執行完成之前，其他任務無法開始，難以勝任複雜、多階段的計算任務。

Kafka
1.一種高吞吐量的分佈式發佈訂閱消息系統，用戶通過 Kafka 系統可以發佈大量的消息，同時也能實時訂閱消費消息。
2.可以同時滿足在線實時處理和批量離線處理。

在公司的大數據生態系統中，可以把 Kafka 作爲數據交換樞紐，不同類型的分佈式系統（關係數據庫、NoSQL 數據庫、流處理系統、批處理系統等），可以統一接入到 Kafka，實現和 Hadoop 各個組件之間的不同類型數據的實時高效交換。