Hadoop數據處理基本過程回顧

Hadoop是一個分布式的、高度容錯的數據存儲和數據處理架構，主要包括兩個部分：HDFS文件系統：一個分布式的、容錯的、自愈的、自平衡的海量集群文件系統。

MapReduce計算框架：一個分布式的、容錯的、大規模并行數據處理模型和資源管理調度系統。

MapReduce計算的處理過程如下：

 

先將文件按大致固定的大小及分隔符特征，將一個文件分割為多個Split，MapReduce作業調度算法會安排該Split文件分片所在的節點啟動一個Map task，該task會對該文件分片進行Map操作。

每個Map任務有塊內存（io.sort.mb）存放map函數的輸出。

Map的中間結果會先存儲在節點上的內存循環緩存In-Memory Buffer中，當緩存快溢出時，將Map中間結果吐出到節點本地文件系統中的一個臨時文件，此時的臨時文件的內容是按Key分區Partition的并按Key排序的（Key:Value），Map task會繼續處理Split文件分片，吐出相應的Map臨時文件，直到Split文件分片處理完畢。

Shuffle就是Mapper的輸出傳給Reducer的過程。

Shuffle Map端：Map task在將所有Split文件分片處理完畢后，會進入Map端Shuffle過程，會將內存中的以及所有的存儲在本地文件系統中的Map中間臨時文件按各個Partition應當輸出到的Reduce task合并排序，即將所有需要輸出到相同Reduce task的Partition合并在一起，合并成一個已分區且排序的文件作為map的輸出。

Shuffle Reduce端：Reduce任務會在所有的Map任務完成前就啟動，進入復制階段（copy phase），獲取heartbeat中傳過來的已經完成的Map任務列表，從map任務那里通過HTTP并行的取得屬于這個reducer的map輸出，合并不同map輸出成一個有序的文件，當所有的map輸出都被合并成一個有序文件后，reduce函數啟動。

Reduce task會將處理結過輸出到HDFS文件系統的文件中。

以上描述了MapReduce的處理過程，小編在此只想通過以上描述得出以下結論：

HDFS文件系統是按固定大小的數據塊（通常為64MB、128MB等，Oracle的BDA采用256MB的塊大�。┚鶆蚍植荚谒�有存儲節點的所有硬盤上(理想情況下)。

MapReduce會盡量用文件分片所在節點來處理該文件內容，即Hadoop具有數據處理本地化特征。

HDFS文件系統不具有文件系統緩存層，即HDFS不會如通常的文件系統那樣，通過LRU算法實現常用數據塊的緩存，當然也不會安排數據預讀進緩存備用。對于寫，也是如此，HDFS會等待數據塊寫的三個副本都已完成，數據塊寫才算完成。

HDFS的數據塊最底層是寫在每個數據節點上的本地文件系統上的，如EXT4、Btrfs等，這些本地文件系統還是具有文件系統緩存的，這是HDFS底層支持系統所具有的，而不是HDFS文件系統層所具有的。

 

Hadoop架構的經典部署方式

Hadoop的經典部署方式，就是采用采用計算與存儲緊耦合方式，如下圖：

Hadoop經典部署方式采用統一的節點配置，該節點上將安裝和運行HDFS文件系統及MapReduce計算框架。

   經典部署方式是最早的Hadoop架構部署方式，可以完全支持和充分發揮Hadoop固有的數據訪問和處理的本地化特征。

經典部署方是也是目前最廣泛采用的部署方式，但隨著人們在大數據領域用經典部署方式來架構和處理大數據，經典部署方式的不足之處也開始逐步顯現，主要表現在：

Ø  經典部署方式由于采用統一的節點配置，其計算能力與存儲能力在部署之初就形成了一個固定配比，雖然整個Hadoop集群可以隨著節點的增加擴展其計算處理和數據存儲能力，但由于固定配比的存在，其計算處理能力和數據存儲能力并不能獨立擴展，影響了整個架構的靈活性。

Ø  經典部署方式由于采用統一的節點配置，無法快速采用一些新的服務器技術，如目前出現的高存儲容量的存儲服務器、GPU優化的計算服務器、FPGA優化的計算服務器、內存優化的服務器以及低成本高密度計算服務器。

Ø  經典部署方式與HDFS文件系統緊耦合，HDFS面向大文件的設計特點使得HDFS文集系統不善存儲巨量的小文件，在巨量小文件面前，NameNode的瓶頸就容易出現，限制了HDFS文件系統的擴展性。

Ø  經典部署方式由于將所有數據都存儲于HDFS文件系統，HDFS的訪問通常限于Hadoop生態系統，即通過MapReduce或更高級的Pig、Hive等方式訪問，其他生態系統的框架必須有相應的連接器才能訪問。據此，有觀點認為HDFS并不是做為企業級數據湖的最好選擇。

目前通常將Hadoop的經典部署方式簡稱為Hadoop 1.0。

 

Hadoop架構的融合部署方式

Hadoop的融合部署方式是將Hadoop的HDFS文件系統與MapReduce計算框架分開部署的一種部署方式，如下圖：

通常采用存儲優化的超大容量存儲服務器構建HDFS集群，采用計算優化的計算服務器（如高密度的計算服務器、GPU優化的計算服務器、FPGA優化的計算服務器等）組成Map Reduce計算集群。計算集群與存儲集群之間通常采用專用的網絡連接。

融合部署方式使得計算節點與存儲節點沒有固定配比，該部署方式使用戶可以在計算資源和存儲資源各自獨立擴展。

融合部署方式使得用戶可以根據需要靈活選擇計算服務器和存儲服務器型號，充分利用存儲服務器的存儲容量和計算服務器的計算特性，從而構建一個更加靈活和適應新技術的Hadoop部署架構。

融合部署方式雖然帶來了更加靈活的擴展特性，但融合架構也帶來了其他的不足：

Ø  融合部署方式破壞了Hadoop固有的數據訪問本地化特性。所有的數據訪問必須經過數據網絡。隨著網絡向25G和100G的普及，該不足在逐漸淡化。

Ø  融合部署方式仍然與HDFS文件系統緊耦合，HDFS面向大文件的設計特點使得HDFS文集系統不善存儲巨量的小文件，在巨量小文件面前，NameNode的瓶頸就容易出現，限制了HDFS文件系統的擴展性。

融合部署方式由于將所有數據都存儲于HDFS文件系統，HDFS的訪問通常限于Hadoop生態系統，即通過MapReduce或更高級的Pig、Hive等方式訪問，其他生態系統的框架必須有相應的連接器才能訪問。據此，有觀點認為HDFS并不是做為企業級數據湖的最好選擇。

Hadoop架構的緩存優化虛擬分布式存儲部署方式

Hadoop的緩存優化虛擬分布式存儲部署方式是將MapReduce計算集群與存儲系統分開部署，將計算資源與存儲資源解耦，MapReduce集群與存儲系統通過網絡相連。

在MapReduce計算集群的所有節點上構建一個統一的分布式內存緩存資源池，在該資源池的前端，提供HDFS兼容的訪問接口;在該資源池的后端提供整合Oracle Storage Cloud對象存儲的后端接口，并可以將Oracle MapReduce各計算節點內置的PCI-E NVME統一做為二級緩存，將SSD或HDD統一做為三級緩存，以擴大分布式內存緩存資源池的容量。智能緩存調度算法在各緩存層級間智能緩存和預讀最可能用到的數據。各計算節點各自并發地訪問存儲在Oracle Storage Cloud的對象數據。

緩存優化虛擬分布式存儲通過智能緩存算法，理想情況下將大部分數據訪問由內存緩存和本地SSD/HDD緩存實現，只有少數數據訪問通過訪問外部的對象存儲實現。

Oracle幫助過客戶通過智能緩存系統達到十幾倍的性能提升。

該部署方式具有如下優點：

Ø  計算節點與存儲容量沒有固定配比，該部署方式使用戶可以在計算資源和存儲資源各自獨立擴展。

Ø  用戶可以根據需要靈活選擇計算服務器型號和Oracle Storage Cloud的服務級別，充分利用對象存儲的海量容量和多種服務級別。

Ø  對象存儲的供給遠比HDFS快，且自愈速度也比HDFS快。

Ø  Oracle Storage Cloud會將每個對象在Region的三個可用域各存一個副本，遠比HDFS的跨機柜副本放置策略的可靠性高。

Ø  Oracle Storage Cloud可以很簡單地實現跨Region的復制，而HDFS要實現跨區域的數據復制將非常困難。

Ø  由于采用了統一的內存緩存池，加上各節點上的NVME、SSD和HDD組成的大容量的二級和三級緩存，加上智能的緩存調度算法和預讀策略，通常會帶來較大的性能提升。

Ø  對象存儲由于訪問的通用性，可適應各種計算框架，更適合作為企業的數據湖存儲。

緩存優化的虛擬分布式存儲部署方式有時也簡稱Hadoop 2.0。

 

Hadoop環境下處理大量小文件的問題

前文提到了HDFS在處理大量小文件時候會遇到瓶頸。主要是因為HDFS通常有一個Master的NameNode和一個Standby NameNode，當然，從技術上講，用戶可以配置多個Standby NameNode，但Master NameNode默認只有一個，搭建NameNode HA步驟很繁瑣（Oracle Bigdata Cloud Service提供2個Master節點的高可用保障）。Master NameNode會將HDFS文件系統的MetaData保存在內存中(MetaData被持久化到磁盤文件fsimage中，NameNode啟動時會先讀取這個信息)，任何對Master NameNode的MetaData更改會在修改內存的同時，將修改添加到本地磁盤log文件edits中，其余Standby NameNode會實時獲取該Log，并將變化同步到Standby NameNode的內存中。

在HDFS文件系統中，任何一個文件、目錄和Block都會被表示為一個Item存儲在 NameNode的內存中，每一個Item占用150~200bytes的內存空間。所以，如果有一億個文件，每一個文件對應一個Block，那么就會消耗NameNode 30~40G來保存這些MetaData的信息。如果規模再大一點，如10billion的文件，就需要3TB~4TB的內存，那么將會超出現階段計算機硬件所能滿足的極限。

目前關于避免NameNode瓶頸的技術思路主要是分布式MetaData管理和Key/Value管理Namespace。

分布式MetaData的基本思想是將文件系統的命名空間root及全部命名空間先由分布式MetaData集群中的一個節點管理，隨著文件系統負荷增加，將命名空間樹形結構中的最忙碌的分支遷移到另一個節點管理，依次循環往復，動態保持整個命名空間在MetaData集群節點間的訪問負荷平衡。

Oracle在Big data Cloud Service-Compute Edition中實現了一個統一的命名空間（Big data file system，BDFS），該命名空間可以將其一個或多個目錄映射到Oracle Storage Service對象存儲的一個或多個container，利用計算節點的內存、NVMe和HDD做為統一的緩存。Big data file system僅需管理緩存在計算節點的數據塊的MetaData，無需管理整個命名空間的MetaData，整個命名空間的MetaData由底層的存儲系統Oracle對象存儲管理。

對象存儲通常采用Key/Value方式管理MetaData。用戶在統一命名空間中的一個文件會自動映射到對象存儲中的一個對象，對象存儲計算對象名的Hash值，通過Hash值得到該對象的對應的Placement Group ID, 再利用該Placement Group ID、當前各節點的狀態圖和事先定義的規則計算出負責該Placement Group的對象存儲節點，在該存儲節點就可以得到該對象的內容。

通過以上描述，我們可以知道，Oracle Big data file system自身并不需要管理整個命名空間的MetaData，通過映射文件到對象，對象存儲僅需進行簡單的計算就可以直接找到我們文件所需要的文件。

所以，Oracle Big Data file system虛擬分布式文件系統能快速處理小文件，且沒有MetaData性能瓶頸。

僅需三步，就可以在Oracle公有云上部署Big data Cloud Service, 以上是一個服務的訂閱情況：一個節點(2個OCPU, 30GB內存)，分配了50GB給HDFS，分配了50GB給Oracle BDFS文件系統做緩存，BDFS文件系統映射到了一個后端的對象存儲的Container。

 

總結

Hadoop的幾種部署方式客官可以根據自己的情況選擇，Hadoop 1.0溫柔賢惠，Hadoop 2.0前衛時尚。

Oracle是業界公認的數據管理和大數據分析領域的領導者，我們不僅有業界領先的關系型數據庫，我們還有基于Hadoop的大數據平臺，并能將關系型數據庫與Hadoop平臺很好地集成在一起，提供全數據解決方案和云服務。

Oracle還將Machine Learning機器學習算法集成在關系型數據庫和分析平臺中，幫助用戶在各種數據中發現價值。

對于Hadoop的部署，Oracle全面支持Hadoop 1.0和2.0部署方式，客官可以選擇BDA大數據一體機/OCC公有云一體機/BDCC公有云大數據一體機及BDCS大數據云服務，客官還可選擇在自己數據中心和Oracle公有云部署自己的Hadoop。

各部署方式的特點及Oracle對應的產品和云服務見下表：

Oracle Big Data Cloud Service-Compute Edition提供了基于緩存優化的虛擬分布式存儲部署方式，充分利用了內存及本地SSD/HDD的高性能和對象存儲的高可靠性和高性價比，同時又能很好地處理小文件。

 

 

 

 

 

【文章來源：Oracle官網】