Chapter7 Hadoop架構架構演進與生態組件

7.1 Hadoop的優化與發展

7.1.1 Hadoop的局限和不足

Hadoop在剛剛推出時，存在很多不足，存在的不足如下：

1. 抽象層次低，需人工編碼，
   很多作業沒有辦法從高層撰寫邏輯代碼，必須從最底層進行邏輯編碼，即使是很簡單的任務都要撰寫完整的MapReduce代碼，然后進行編譯、打包、運行，
2. 表達能力有限
   在Hadoop核心組件中，MapReduce負責計算，雖然它將復雜的分布式計算全部抽象為Map和Reduce函式，簡化了編程作業，但同時這種方法也限制了表達能力，現實中的很多問題沒有辦法使用Map和Reduce函式完成，
3. 開發者自己管理作業（Job）之間的依賴關系
   在企業中，許多大問題的解決需要借助多個MapReduce作業才能完成，這些MapReduce作業之間實際上是相互依賴的關系，需要完成某個MapReduce作業后，將結果提交到另外一個MapReduce作業進行處理，即多個MapReduce作業之間構成了作業流，有先后關系，但是這種先后關系在Hadoop1.0中無法通過產品本身的功能實作，所以開發人員不得不通過編碼的方式，將這種依賴關系寫入代碼，從而實作不同作業之間的相互依賴，
4. 難以看到程式的整體邏輯
   在Hadoop1.0中，沒有為用戶提供高層邏輯表現方式，用戶想了解程式是按照什么順序執行的，只能去看源代碼，一行行的分析處理邏輯，這對用戶是困難的作業，對代碼維護不利，
5. 執行迭代操作效率低
   MapReduce是將作業分階段進行的，每次MapReduce任務完成之后，都要寫入到分布式檔案系統HDFS中，供下一個MapReduce使用，不同階段之間需要迭代，這種迭代與資料傳遞，都要先把資料寫入HDFS再給下一個MapReduce用，在資料挖掘和機器學習中，有非常多的迭代程序，如果采用MapReduce進行這種迭代，效率非常低，
6. 資源浪費
   整個任務執行時，嚴格劃分階段（Map和Reduce），要求所有Map任務處理結束之后，才能進入Reduce，在等待Map任務的程序中，Reduce一直是空閑的，造成了資源浪費，
7. 實時性差
   MapReduce框架很難實作實時互動查詢，

7.1.2 Hadoop的改進和提升

Hadoop的優化與發展主要體現在兩個方面：

1. Hadoop自身兩大核心組件，MapReduce和HDFS架構設計改進，
   Hadoop模塊的自身改進：從1.0到2.0，
   
2. Hadoop生態系統其他組件的不斷豐富，包括Pig，Tez，Spark和Kafka等，
   
   pig：提供類似SQL語法的陳述句，提高編程效率，用戶執行分析任務時，只需要撰寫幾行簡單的代碼即可完成任務，
   spark：MapReduce是基于磁盤的，不同階段之前通過磁盤進行資料交換，而spark的資料處理、傳輸程序全部通過記憶體進行交換，迭代效率非常高，
   Oozie：幫助用戶有效管理多個MapReduce任務之間的相互依賴關系，
   Tez：是支持有向無環圖作業的計算框架，對整個MapReduce作業分解成更多的子操作，減少了不同MapReduce之間的重復操作，
   Kafka：Hadoop生態系統中的多個組件之間需要進行資料互動，可以通過Kafka，將其他型別的分布式系統接入（比如NoSQL、日志系統），實作與Hadoop各個組件之間的資料交換，

7.2 HDFS2.0的新特性

7.2.1 HDFS HA

回顧在HDFS1.0中介紹的核心組件，如下圖所示，
在1.0中，HDFS集群就是由一個名稱節點和若干個資料節點構成的，名稱節點提供元資料服務，資料節點負責資料存盤，名稱節點保存的元資料包括整個檔案系統樹的鏡像檔案（FsImage）以及日志檔案（EditLog），這兩個檔案保存在磁盤上，同時，名稱節點也保存著映射資訊，即一個檔案包含哪些塊、每個塊保存在哪個資料節點上，這些映射資訊保存在記憶體中，

由于在HDFS1.0中只有一個名稱節點，所以一旦名稱節點產生問題，就會發生單點故障，整個系統就會宕機，在1.0中即使存在第二名稱節點（Secondary NameNode），也不能解決單點故障問題，

在HDFS2.0中，引入的HDFS HA（High Availability）就是為了解決單點故障問題，其架構如下圖所示，
HA集群設定了兩個名稱節點，一個被設定為活躍狀態（Active），一個被設定為待命狀態（Standby），一旦活躍名稱節點出現了故障，就可以馬上切換到代碼名稱節點，這種方式稱為熱備份，
由于同一時間只能有一個NameNode作為管家作業，所以需要Zookeeper確保某個時刻只有一個名稱節點在對外服務，
狀態資訊的同步：對于映射表的維護，所有資料節點需要向兩個名稱節點匯報資訊，以便名稱節點更新自己記憶體中的映射表，保證兩個名稱節點保存的元資料是實時一致的，對于EditLog的維護，兩種名稱節點狀態同步借助于一個共享存盤系統實作，活躍節點通過共享存盤系統，將新的資訊傳遞給待命節點，

7.2.2 HDFS Federation

HDFS1.0中存在的問題

1. 單點故障問題
   這個問題可以使用HDFS HA中的熱備份解決，但是下面幾個問題是無法通過HA解決的，
2. 不可以水平擴展
   不能添加名稱節點，雖然HA提供了備份，但備份的名稱節點只會在出現故障的時候才進行頂替，在某一時刻實際發揮作用的仍然只有一個名稱節點，
   是否能通過縱向擴展（讓名稱節點保持更多元資料資訊、支持更大規模檔案存盤，需要加記憶體和CPU）實作呢？不能，HDFS中名稱節點中很多元資料資訊都保存在記憶體中，記憶體過大會導致啟動速度過慢，并且，記憶體過大會導致一旦垃圾清理程序發生問題，整個系統宕機，
3. 系統整體性能受限于單個名稱節點的吞吐量
   真正提供服務的只有一個處于活躍狀態的名稱節點，吞吐量是由單個節點決定的，
4. 單個名稱節點難以提供不同程式之間的隔離性
   一個應用程式消耗的CPU和記憶體資源可能非常大，一旦將多個程式放到一起運行，可能一個應用程式就將資源消耗完了，其他程式無法運行，
5. HDFS HA是熱備份，提供高可用性，但是無法解決可擴展性、系統性能和隔離性

HDFS Federation 架構示意圖：
在2.0中，由圖可見已經包含多個相互獨立的名稱節點，使得HDFS的命名服務能夠水平擴展，并且這些名稱節點之間彼此作業相互獨立、分別進行各自命名空間和塊的管理，構成聯盟關系，無需進行協調，并且這種機制是向后兼容的，之前基于單名稱節點開發的程式可以無縫遷移到已經采用多名稱節點的框架中，
每一個名稱節點都管理著自己的命名空間，所有名稱節點都共享底層公共的資料節點存盤資源，資料節點向所有名稱節點匯報，屬于同一個命名空間的塊構成一個"塊池"（是邏輯上的概念，不是物理概念，還是要依靠底層的資料節點存盤物理資料），

資料訪問方式
對于Federation中的多個命名空間，可以采用客戶端掛載表（Client Side Mount Table）的方式進行資料共享和訪問，客戶可以通過訪問不同的掛載點來訪問不同的子命名空間，

客戶掛載表方式訪問多個命名空間示意圖
在下圖中，上面的三角形區域是從用戶角度看到的全域命名空間，包括data、project、home、tmp四個子命名空間，下面的陰影區域是每一個名稱節點維持的子命名空間，可以把各個命名空間掛載到全域"掛載表"（mount-table）中，實作全域資料共享，
若將各個命名空間掛載到全域掛載表，就可以從全域看到各個子命名空間，可以選擇指定命名空間訪問資料，若將相同的命名空間掛載到個人的掛載表中，就成為了應用程式可見的命名空間，應用程式可以直接訪問子命名空間，

HDFS Federation相對于HDFS1.0的優勢
HDFS Federation設計可以解決單名稱節點存在的以下問題：

1. HDFS 集群擴展性，Federation中有多個名稱節點，每個名稱節點可以各自管理一部分目錄，可以讓一個集群擴展到更多節點，不再像HDFS1.0中那樣由于記憶體的限制制約檔案存盤數目（一個名稱節點能存盤的檔案數目是有限的），
2. 性能更高效，多個名稱節點各自管理不同的資料，并且可以同時對外提供服務，因此可以提供更高的資料吞吐率，
3. 良好的隔離性，可以根據不同業務進行子空間的劃分，某種資料可以歸屬于一個名稱節點管理，另外的資料可能歸屬于另一個名稱節點管理，不同資料分給不同名稱節點管理，可以有效的對不同業務之間進行隔離，不會因為一個應用程式消耗過多資源而影響另一個應用程式運行，

注意：雖然HDFS Federation相當于1.0版本具備很多優勢，但是它不能解決單點故障問題，雖然它存在多個名稱節點，但是對每個名稱節點來說都存在單點故障問題（名稱節點之間是聯盟關系而不是備份關系），需要為每個名稱節點部署一個后備名稱節點、啟用HA高可用性機制，以應對名稱節點宕機對業務產生的影響，

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

7.3.1 MapReduce1.0的缺陷

正是因為MapReduce1.0中存在的缺陷，才會有YARN的誕生，
MapReduce1.0體系結構如下：

MapReduce1.0的缺陷如下：

1. 存在單點故障，
   在1.0體系架構中只有JobTracker作為總管家，負責整個作業的調度、管理、監控、資源調度，JobTracker收到任務后，將之分解為多個作業，分配到TaskTracker，因此，JobTracker如果宕機，MapReduce就沒有辦法使用了，
2. JobTracker"大包大攬"導致任務過重
   JobTracker作為總管家，既要負責資源管理調度分配，也要負責任務的調度、監控，以及失敗的恢復，一旦對記憶體消耗大的多個任務同時運行，記憶體開銷非常大，非常容易導致出現故障，因此，業界發現對MapReduce作集群的時候，上限就是4000個節點，
3. 容易出現記憶體溢位
   分配資源時，僅僅考慮MapReduce任務數，而不考慮每個MapReduce任務到底消耗多少CPU、消耗多少記憶體，一旦多個記憶體消耗大的任務一起執行時，記憶體就會溢位，
4. 資源劃分不合理
   把CPU、記憶體等資源打包后，強行等分成多個slot，并分為Map slot（只能給Map任務用）和Reduce slot（只能給Reduce任務用），即使Reduce任務是空閑的，而Map任務安排的非常繁忙，也不能將Reduce的資源分配給Map用，因為他們不能互相使用，

7.3.2 YARN設計思路

YARN架構思路如下：

正是因為MapReduce存在上述問題，所以YARN進行了有針對性的改進，基本思想是將原JobTracker功能進行拆分，把資源管理功能分配給新的組件ResourceManager，任務調度和任務監控交給組件ApplicationMaster，原來TaskTracker的任務交給NodeManager管理，

MapReduce1.0既是一個計算框架，也是一個資源管理調度框架，
而到了Hadoop2.0之后，MapReduce1.0中的資源管理調度功能，被單獨分離出來形成了YARN，YARN是純粹的資源管理調度框架，不再是一個計算框架，

被剝離了資源管理調度功能的MapReduce框架就變成了MapReduce2.0，它是運行在YARN上的一個純粹的計算框架，不再自己負責資源調度管理服務，而是由YARN為其提供資源管理調度服務，

7.3.3 YARN體系結構

YARN體系結構如下圖所示，包含三大核心組件：
1.ResourceManager：處理客戶端請求、啟動/監控ApplicationMaster、監控NodeManager、資源分配與調度，
2.ApplicationMaster：為應用程式申請資源并分配給內部任務、任務調度/監控/容錯，
3.NodeManager：單個節點上的資源管理、處理來自ResourceManager的命令、處理來自ApplicationMaster的命令，

ResourceManager
簡稱RM，是一個全域的資源管理器，負責整個系統的資源管理和分配，主要包括兩個組件，即調度器（Scheduler）和應用程式管理器（Applications Manager），
調度器接受來自ApplicationMaster的應用程式資源請求，把集群中的資源以"容器"的形式分配給提出申請的應用程式，容器的選擇通常會考慮應用程式要處理的資料的位置，進行就近選擇，從而實作"計算向資料靠攏"，
容器（Container）作為動態資源分配單位，每個容器中都封裝了一定數量的CPU、記憶體、磁盤等資源，從而限定每個應用程式可以使用的資源量，
調度器被設計成是一個可插拔的組件，YARN不僅自身提供了許多種直接可用的調度器，也允許用戶根據自己的需求重新設計調度器，
應用程式管理器負責所有應用程式的管理作業，主要包括應用程式提交、與調度器協商資源以啟動ApplicationMaster、監控ApplicationMaster運行狀態并在失敗時重新啟動等，注意，應用程式管理器不會涉及到具體任務的管理執行，只會監控ApplicationMaster，

ApplicationMaster
ResourceManager接受用戶提交的作業，按照作業的背景關系資訊以及從NodeManager收集來的容器資訊，啟動調度程序，為用戶作業啟動一個ApplicationMaster（ApplicationMaster也是在容器上運行的，因此ResourceManager需要先給它申請一個容器），
ApplicationMaster的主要功能：

1. 當用戶作業（應用程式以作業的形式提交給Hadoop系統，Hadoop再將它分解成多個Map任務和Reduce任務執行）提交時，ApplicationMaster與ResourceManager協商獲取資源，ResourceManager會以容器的形式為ApplicationMaster分配資源，
2. 把獲得的資源進一步分配給內部的各個任務（Map任務或Reduce任務），實作資源的"二次分配"，
3. 與NodeManager保持互動通信，進行應用程式的啟動、運行、監控和停止，監控申請到的資源的使用情況，對所有任務的執行進度和狀態進行監控，并在任務發生失敗時執行失敗恢復（即重新申請資源重啟任務），
4. 定時向ResourceManager發送"心跳"資訊（以便用戶通過ResourceManager查詢整個作業當前運行狀態），報告資源的使用情況和應用的進度資訊，
5. 當作業完成時，ApplicationMaster向ResourceManager注銷容器，執行周期完成，

NodeManager
NodeManager是駐留在一個YARN集群中的每個節點上的代理，主要負責如下：

1. 容器生命周期管理：集群中的各種資源都是以容器的形式存在的，容器就是由NodeManager管理的，容器中運行ApplicationMaster，可以支持任務的運行
2. 監控每個容器的資源（CPU、記憶體等）使用情況
3. 跟蹤節點監控狀況
4. 以"心跳"的方式與ResourceManager保持通信
5. 向ResourceManager匯報作業的資源使用情況和每個容器的運行狀態
6. 接受來自ApplicationMaster的啟動/停止容器的各種請求

需要說明的是，NodeManager主要負責管理抽象的容器，只處理與容器相關的申請，而不是具體負責每個任務（Map任務或Reduce任務）自身狀態的管理，因為這些管理作業是由ApplicationMaster完成的，ApplicationMaster會通過不斷與NodeManager通信來掌握各個任務的執行狀態（NodeManager向ApplicationMaster主動匯報容器中的任務執行到什么狀態），

在集群部署方面，YARN中的各個組件是和Hadoop集群中的其他組件進行統一部署的，
如下圖所示，兩個"管家"部署在一個節點上，
NodeManager、ApplicationMaster、DataNode也可以一起部署，
NodeManager、Container、DataNode也是一起部署的，因為底層容器屬于計算資源，運行在不同的資料節點上，DataNode既作為HDFS資料節點使用，也作為計算節點使用，NodeManager作為代理者，也和他們部署在一起，

7.3.4 YARN作業流程

YARN的作業流程圖如下所示：

具體步驟：

1. 用戶撰寫客戶端應用程式，向YARN提交應用程式，提交的內容包括ApplicationMaster程式、啟動ApplicationMaster的命令、用戶程式等，
2. YARN中的ResourceManager負責接受和處理來自客戶端的請求，為應用程式分配一個容器，在該容器中啟動一個ApplicationMaster，從而讓ApplicationMaster掌管整個作業執行程序，
3. ApplicationMaster被創建后會首先向ResourceManager注冊，以便ResourceManager對它進行實時監控管理，
4. ApplicationMaster采用輪詢的方式向ResourceManager申請資源，作業被分解成多個Map任務和Reduce任務，每個任務都需要申請容器以執行任務，
5. ResourceManager以"容器"的形式向提出申請的ApplicationMaster分配資源，
6. 在容器中啟動任務（運行環境、腳本），ApplicationMaster獲得容器后，將資源進行二次分配，分配給自己管轄的Map任務和Reduce任務，分別進行啟動執行，啟動時，ApplicationMaster會為容器設定好整個應用程式運行環境，包括jar包、環境變數、二進制程式，都整理好發送給程式，并將運行應用程式的命令寫作腳本發給容器，容器接受到之后，啟動腳本即可完成任務的啟動，
7. 各個任務向ApplicationMaster匯報自己的狀態和進度，每個節點上都駐留著NodeManager組件，作為代理，實時監控容器運行狀態，并反饋給ApplicationMaster，
8. 應用程式運行完成后，ApplicationMaster向ResourceManager的應用程式管理器注銷并關閉自己（釋放掉容器資源），

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

從MapReduce1.0框架發展到YARN框架，客戶端沒有發生變化，其大部分呼叫API及介面都保持兼容，因此，原來針對Hadoop1.0開發的代碼不需要作大的改動，就可以直接放到Hadoop2.0平臺上運行，

YARN相對于MapReduce1.0的具體優勢如下：

1. 大大減少了承擔中心服務功能ResourceManager的資源消耗
   在1.0體系架構中只有JobTracker作為總管家，負責整個作業的調度、管理、監控、資源調度，
   而ResourceManager任務簡單，只負責資源管理調度，作業量減輕、資源消耗少，
2. ApplicationMaster來完成需要大量資源消耗的任務調度和監控
   每一個作業啟動時，都會為它分配一個相關聯的ApplicationMaster作為管家，管理整個作業的全流程運行，
3. 多個作業對應多個ApplicationMaster，實作了監控分布化
   多個ApplicationMaster分別管理多個作業的全流程運行，
4. MapReduce1.0 既是一個計算框架，又是一個資源管理調度框架，但是，只能支持MapReduce編程模型（只能為MapReduce調度資源，不支持其他任務），而YARN是一個純粹的資源調度管理框架，在它上面可以運行包括MapReduce在內的不同型別的計算框架（比如可以運行Storm框架），只要編程實作相應的ApplicationMaster，
   這是因為ApplicationMaster是可以替換的模塊，在YARN框架中，ApplicationMaster的型別是豐富的，可以針對不同型別的作業設計實作它，從而讓它管理各種型別的作業，
5. YARN中的資源管理比MapReduce1.0更加高效，以容器為單位，而不是以slot為單位，容器對CPU、記憶體進行統籌管理，不存在資源空閑但無法使用的問題，

7.3.6 YARN的發展目標

YARN的目標就是實作"一個集群多個框架"，為什么？
一個企業當中同時存在各種不同的業務應用場景，需要采用不同的計算框架，而目前都是使用不同的計算框架解決不同的問題，可能涉及到的框架比如：
1.使用MapReduce實作離線批處理
2.使用Impala實作實時互動式查詢分箱
3.使用Storm實作流式資料實時分析
4.使用Spark實作迭代計算
這些框架通常來自不同的公式，并且通常帶有各自的資源調度管理機制，
如果將這些框架放到一個集群上運行，會出現問題，這些框架的資源管理調度機制不同，會爭先搶占底層資源，
因此，為了避免不同型別的應用之間相互干擾，企業需要把內部的服務器拆分成多個集群，分別安裝不同的計算框架，即"一個框架一個集群"，
但是這樣拆分集群，導致了如下問題：
1.集群資源利用率低：即使某一個集群的資源空閑也不能分配給另一個集群使用，是完全隔離的，資源不能共享，
2.資料無法共享：企業中的資料通常需要經過一種計算框架處理后提交給另一種計算框架處理執行，通過多個計算框架完成一個大的作業，一旦集群隔離，就要通過人工拷貝的方式，底層不共享就只能通過大規模資料傳輸解決資料共享問題，導致大量資料共享開銷，
3.維護代價高：集群是不同的，需要不同的人管理不同的集群，

YARN提出
YARN的目標就是實作"一個集群多個框架"，即在一個集群上部署一個統一的資源調度管理框架YARN，在YARN之上可以部署其他各種計算框架，所有計算框架共用YARN的資源調度管理功能，
在底層HDFS基礎上搭建YARN框架，由YARN框架為這些計算框架提供統一的資源調度管理服務，并且能夠根據各種計算框架的負載需求，調整各自占用的資源，實作集群資源共享和資源彈性收縮，集群資源可以通過YARN進行實時調整，把資源進行合理的調整分配，需求量大就多分配一些，
可以實作一個集群上的不同應用負載混搭，有效提高了集群利用率，
不同計算框架可以共享底層存盤，避免了資料跨集群移動，

在YARN上部署各種計算框架示意圖如下
底層是HDFS，上面各種計算框架都共享底層HDFS存盤，因此進行資料共享交換時可以直接讀取底層的存盤，不需要再將資料從一個集群傳到另一個集群，避免了資料跨集群移動，

一個新的計算框架如何運行在YARN之上？
讓YARN中的ApplicationMaster組件重新撰寫代碼，讓ApplicationMaster為這個新的計算框架服務即可，

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

7.4.1 Pig

Pig是Apache專案中一個開源的專案，而且是整個Hadoop生態系統中的一個組件，
Pig提供了類似SQL的Pig Latin語言（包含Filter、GroupBy、Join、OrderBy等操作，同時也支持用戶自定義函式），用戶只需要撰寫非常簡單的Pig Latin陳述句就可以完成各種復雜的資料分析任務，而不需要撰寫復雜的MapReduce程式，Pig會自動把用戶撰寫的腳本轉換成MapReduce作業在Hadoop集群上運行，而且具備對生成的MapReduce程式進行自動優化的功能，因此，用戶撰寫Pig程式的時候，不需要關心程式的運行效率，這大大減少了用戶編程的時間，
Pig提供了過濾、分組、連接、排序等操作，通過Pig Latin語言可以很容易實作，
通過配合使用Pig和Hadoop，在處理海量資料時就可以實作事半功倍的效果，比使用Java、C++等語言撰寫MapReduce程式的難度要小很多，并且用更少的代碼量實作了相同的資料處理分析功能，

Pig可以加載資料、表達轉換資料、存盤最終結果，

Pig陳述句通常按照如下格式撰寫：

1. 通過LOAD陳述句去檔案系統讀取資料，
2. 通過一系列"轉換"陳述句對資料進行處理
3. 通過STORE陳述句把處理結果輸出到檔案當中去，或者用DUMP陳述句把處理結果輸出到螢屏上面，

在企業中，通常使用Pig進行資料加工（ETL程序），把資料收集后進行處理轉換，并將處理結果存盤在資料倉庫Hive中，讓Hive完成海量資料分析，

下面是采用Pig Latin語言撰寫的應用程式實體，實作了對用戶訪問網頁情況的統計分析：

在Pig Latin中寫完代碼之后，剩下的事情交給Pig Latin引擎，它會自動把代碼轉換成底層的MapReduce作業執行，上圖中的代碼經轉換會生成如下流程圖，代碼被系統轉化成了Map任務和Reduce任務，
第一行陳述句是Load Visits陳述句，是加載資料，因此轉換成Map1任務，
第二行陳述句是Group By分組任務，需要橫跨Map階段和Reduce階段，
第三行陳述句是聚合操作，轉換成Reduce1任務，
第四行代碼也是加載資料，需要通過Map2任務進行加載，
第五行代碼是兩表連接，需要橫跨Map階段和Reduce階段，
注意，矩形框5和矩形框4是有重疊的，這是因為Map2任務把檔案加載進來之后，輸出了鍵值對串列，可供5使用，但是矩形框3和矩形框5沒有重疊，這是因為3已經完成了Reduce任務，已經把結果寫入了HDFS中，不會直接給5，
第六行代碼是根據網頁內容對連接結果進行分組，需要橫跨Map階段和Reduce階段，
第七行代碼是對分組進行聚合統計，計算每一個分類的訪問量，因此轉換成Reduce3任務，

Pig的應用場景
Pig是面向技術人員的，并且通常是即時性的資料處理需求，這樣可以通過Pig很快寫一個腳本開始運行處理，而不需要創建表等相關的事先準備作業，

Pig主要用戶

1. Yahho!：90%以上的MapReduce作業是Pig生成的，
2. Twitter：80%以上的MapReduce作業是Pig生成的，
3. Linkedin：大部分的MapReduce作業是Pig生成的，
4. 其他主要用戶：Salesforce、Nokia、AOL、comScore，

7.4.2 Tez

Tez是Apache開源的支持DAG（有向無環圖）作業的框架，它直接源于MapReduce框架，
Tez的核心思想是將Map和Reduce兩個操作進行進一步拆分，Map被拆分成Input、Processor、Sort、Merge、Output，Reduce被拆分成Input·、Shuffle、Sort、Merge、Processor和Output等子操作，
分解后的元操作可以進行任意靈活組合，產生新的操作，這些操作經過一些控制程式組裝后，可以形成一個大的DAG作業，可以通過DAG作業的方式運行MapReduce作業，提供程式運行的整體處理邏輯，可以去除掉作業流中多余的Map階段，減少不必要的操作，提高了資料處理的性能，
Hortonworks（一個知名的提供商業版本Hadoop廠家）將Tez應用到了資料倉庫Hive的優化中，使得性能提升了約100倍，

HiveQL陳述句在MapReduce和Tez中的執行情況對比
左側代碼是HiveQL陳述句，實作了連接分組功能，
這段代碼若在資料倉庫Hive中執行，Hive提供了自動轉化功能，會把這段代碼自動轉換成底層MapReduce作業，得到左側的流程圖結果，M表示Map任務，R表示Reduce任務，發現要將MapReduce任務寫入HDFS檔案，涉及了4次MapReduce和3次HDFS，而涉及HDFS的操作都是較為耗時的，
右側是經過Tez轉化得到的流程圖，消除了寫入HDFS、從HDFS讀出等操作，大大提升了性能，即去除了連續兩個作業之間的"寫入HDFS"，并且，去除了每個作業流中多余的Map階段，

在Hadoop2.0生態系統中，MapReduce、Hive、Pig等計算框架，都需要最終以MapReduce任務的形式執行資料分析，因此，Tez框架可以發揮重要作用，可以借助Tez框架實作對MapReduce、Pig和Hive等的性能優化，可以解決現有MR框架在迭代計算（如PageRank計算）和互動式計算方面的問題，

Tez框架在Hadoop生態系統中的作用
底層使用HDFS，在HDFS上架構資源管理調度YARN，在YARN之上可以構建Tez框架，由Tez對MR、Pig、Hive和其他計算框架（底層轉換成MapReduce作業的計算框架）進行優化，

Tez+Hive與Impala、Dremel和Drill的區別？
復習：Impala是類似Hive的資料倉庫，可以提供實時的互動式分析，Drill是谷歌Dremel的開源實作，
Tez在解決Hive、Pig延遲大、性能低等問題的思路，是和那些支持實時互動式查詢分析的產品（如Impala、Dremel和Drill）是不同的，
Impala、Dremel和Drill的解決思路是完全拋棄MapReduce計算框架，不再將類似SQL的HiveQL陳述句或者Pig陳述句翻譯成MapReduce程式，而是采用與商用并行關系資料庫類似的分布式查詢引擎，可以直接從HDFS或者HBase中用SQL陳述句查詢資料，而不需要把SQL陳述句轉化成MapReduce任務執行，從而大大降低了延遲，很好的滿足了實時查詢的要求，
Tez則不同，比如針對Hive資料倉庫進行優化的"Tez+Hive"解決方案，仍然使用MapReduce計算框架，但是對DAG作業依賴關系進行了裁剪，并且將多個小作業合并成一個大作業，這樣不僅計算量減少了，而且寫HDFS次數也會大大減少，

7.4.3 Spark

Hadoop缺陷：

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

Spark最初誕生于伯克利大學的APM實驗室，是一個可以應用于大規模資料處理的快速、通用引擎，如今是Apache軟體基金會下的頂級開源專案之一，

Spark在借鑒Hadoop MapReduce優點的同時，很好的解決了MapReduce所面臨的問題：

1. Spark采用記憶體計算，不需要使用磁盤，帶來了更高的迭代運算效率，
2. 基于DAG的任務調度執行機制，優于MapReduce的迭代執行機制，

當前，Spark正在以其結構一體化、功能多元化的趨勢，逐漸成為當今大資料領域最熱門的大資料計算平臺，

7.4.4 Kafka

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

Kafka作為資料交換樞紐
Kafka要在企業構建大資料系統中，起到資料交換中樞的作用，在企業中，使用一種產品滿足所有業務需求是不可能的，為了滿足不同業務需求，需要引入不同的有某方面特長的系統，實際當中不可能為每個分布系統開發一個專門的與Hadoop互動的工具，只設計針對Kafka的互動工具即可，
不同型別的分布系統（關系資料庫、NoSQL資料庫、流處理系統、批處理系統等），可以統一接入到Kafka，實作和Hadoop各個組件之間的不同型別資料的實時高效交換，