騰訊大規模Hadoop叢集實踐

TDW（Tencent distributed Data Warehouse，騰訊分布式資料倉庫）基于開源軟體Hadoop和Hive進行建構，打破了傳統資料倉庫不能線性擴充、可控性差的局限，并且根據騰訊資料量大、計算複雜等特定情況進行了大量優化和改造。 

TDW服務覆寫了騰訊絕大部分業務産品，單叢集規模達到4400台，CPU總核數達到10萬左右，存儲容量達到100PB；每日作業數100多萬，每日計 算量4PB，作業并發數2000左右；實際存儲資料量80PB，檔案數和塊數達到6億多；存儲使用率83%左右，CPU使用率85%左右。經過四年多的持 續投入和建設，TDW已經成為騰訊最大的離線資料處理平台。 

TDW的功能子產品主要包括：Hive、MapReduce、HDFS、TDBank、Lhotse等，如圖1所示。TDW Core主要包括存儲引擎HDFS、計算引擎MapReduce、查詢引擎Hive，分别提供底層的存儲、計算、查詢服務，并且根據公司業務産品的應用情 況進行了很多深度訂制。TDBank負責資料采集，旨在統一資料接入入口，提供多樣的資料接入方式。Lhotse任務排程系統是整個資料倉庫的總管，提供 一站式任務排程與管理。 

<a href="http://s3.51cto.com/wyfs02/M01/58/AA/wKiom1S3UCPw_O8mAAE55BZ9uqA197.jpg" target="_blank"></a>

圖1 TDW的功能子產品  

建設單個大規模叢集的原因 

随着業務的快速增長，TDW的節點數也在增加，對單個大規模Hadoop叢集的需求也越來越強烈。TDW需要做單個大規模叢集，主要是從資料共享、計算資源共享、減輕營運負擔和成本等三個方面考慮。 

1. 資料共享。TDW之前在多個IDC部署數十個叢集，主要是根據業務分别部署，這樣當一個業務需要其他業務的資料，或者需要公共資料時，就需要跨叢集或者跨 IDC通路資料，這樣會占用IDC之間的網絡帶寬。為了減少跨IDC的資料傳輸，有時會将公共資料備援分布到多個IDC的叢集，這樣又會帶來存儲空間浪 費。 

2. 計算資源共享。當一個叢集的計算資源由于某些原因變得緊張時，例如需要資料補錄時，這個叢集的計算資源就捉襟見肘，而同時，另一個叢集的計算資源可能空閑，但這兩者之間沒有做到互通有無。 

3. 減輕營運負擔和成本。十幾個叢集同時需要穩定營運，而且當一個叢集的問題解決時，也需要解決其他叢集已經出現的或者潛在的問題。一個Hadoop版本要在 十幾個叢集逐一變更，監控系統也要在十幾個叢集上部署。這些都給營運帶來了很大負擔。此外，分散的多個小叢集，資源使用率不高，機器成本較大。 

建設單個大規模叢集的方案及優化 

面臨的挑戰 

TDW從單叢集400台規模建設成單叢集4000台規模，面臨的最大挑戰是Hadoop架構的單點問題：計算引擎單點JobTracker負載重，使得調 度效率低、叢集擴充性不好；存儲引擎單點NameNode沒有容災，使得重新開機耗時長、不支援灰階變更、具有丢失資料的風險。TDW單點瓶頸導緻平台的高可 用性、高效性、高擴充性三方面都有所欠缺，将無法支撐4000台規模。為了解決單點瓶頸，TDW主要進行了JobTracker分散化和NameNode 高可用兩方面的實施。 

JobTracker分散化 

1.單點JobTracker的瓶頸 

TDW以前的計算引擎是傳統的兩層架構，單點JobTracker負責整個叢集的資源管理、任務排程和任務管理，TaskTracker負責任務執行。 JobTracker的三個功能子產品耦合在一起，而且全部由一個Master節點負責執行，當叢集并發任務數較少時，這種架構可以正常運作，但當叢集并發 任務數達到2000、節點數達到4000時，任務排程就會出現瓶頸，節點心跳處理遲緩，叢集擴充也會遇到瓶頸。 

2.JobTracker分散化方案 

TDW借鑒YARN和Facebook版corona設計方案，進行了計算引擎的三層架構優化（如圖2所示）：将資源管理、任務排程和任務管理三個功能模 塊解耦；JobTracker隻負責任務管理功能，而且一個JobTracker隻管理一個Job；将比較輕量的資源管理功能子產品剝離出來交給新的稱為 ClusterManager的Master負責執行；任務排程也剝離出來，交給具有資源資訊的ClusterManager負責執行；對性能要求較高的 任務排程子產品采用更加精細的排程方式。 

<a href="http://s3.51cto.com/wyfs02/M01/58/AA/wKiom1S3UDDxjkxQAAHJOcSYyO8859.jpg" target="_blank"></a>

圖2 JobTracker分散化架構  

新架構下三個角色分别是：ClusterManager負責整個叢集的資源管理和任務排程，JobTracker負責單個Job的管理，TaskTracker負責任務的執行。 

（1）兩路心跳。之前的架構下，TaskTracker向JobTracker上報心跳，JobTracker串行地處理這些心跳，心跳進行中進行節點管 理、任務管理、任務排程等，心跳繁重，影響任務排程和叢集擴充性。新架構下，心跳被拆分成兩路心跳，分别上報任務和資源資訊。 

JobTracker獲知任務資訊通過任務上報心跳的方式。任務上報心跳是通過任務所在的TaskTracker啟動一個新的獨立線程向對應的 JobTracker上報心跳這條途徑，在同一個TaskTracker上，不同Job的任務使用不同的線程向不同的JobTracker上報心跳，途徑 分散，提升了心跳上報效率。 

TaskTracker通過上報心跳的方式将資源資訊彙報給ClusterManager。ClusterManager從TaskTracker的心跳 中擷取節點的資源資訊：CPU數量、記憶體空間大小、磁盤空間大小等的總值和剩餘值，根據這些資訊判斷節點是否還能執行更多的任務。同 時，ClusterManager通過TaskTracker與其之間維系的心跳來管理節點的生死存亡。 

以前繁重的一路心跳被拆分成了兩路輕量的心跳，心跳間隔由40s優化成1s，叢集的可擴充性得到了提升。 

（2）資源概念。之前架構隻有slot概念，一般根據核數來設定slot數量，對記憶體、磁盤空間等沒有控制。新架構弱化了slot概念，加強了資源的概念。 

每個資源請求包括具體的實體資源需求描述，包括記憶體、磁盤和CPU等。向ClusterManager進行資源申請的有三種來源類型：Map、 Reduce、JobTracker，每種來源需要的具體資源量不同。在CPU資源上，排程器仍然保留slot概念，并且針對三種來源保證各自固定的資源 帽。 

例如，對于24核的節點，配置13個核給Map用、6個核給Reduce用、1個核給JobTracker用，則認為該節點上有1個JobTracker slot、13個Map slot、6個Reduce slot。某個Map請求的資源需要2個核，則認為需要兩個Map slot，當一個節點的Map slot用完之後，即使有剩餘的CPU，也不會繼續配置設定Map予其執行了。記憶體空間、磁盤空間等資源沒有slot概念，剩餘空間大小滿足需求即認為可以分 配。在查找滿足資源請求的節點時，會比較節點的這些剩餘資源是否滿足請求，而且還會優先選擇負載低于叢集平均值的節點。 

（3）獨立并發式的下推排程。之前架構下，排程器采用的是基于心跳模型的拉取排程：任務排程依賴于心跳，Map、Reduce的排程耦合在一起，而且對請求優先級采取全排序方式，時間複雜度為nlog(n)，任務排程效率低下。 

新架構采用獨立并發式的下推排程。Map、Reduce、JobTracker三種資源請求使用三個線程進行獨立排程，對請求優先級采取堆排序的方式，時 間複雜度為log(n)。當有資源滿足請求時，ClusterManager直接将資源下推到請求者，而不再被動地等待TaskTracker通過心跳的 方式擷取配置設定的資源。 

例如，一個Job有10個Map，每個Map需要1個核、2GB記憶體空間、10GB磁盤空間，如果有足夠的資源，Map排程線程查找到了滿足這10個 Map的節點清單，ClusterManager會把節點清單下推到JobTracker；如果Map排程線程第一次隻查找到了滿足5個Map的節點列 表，ClusterManager會把這個清單下推到JobTracker，随後Map排程線程查找到了剩下5個Map的節點列 表，ClusterManager再把這個清單下推到JobTracker。 

以前基于心跳模型的拉取排程被優化成獨立并發式的下推排程之後，平均排程處理時間由80ms優化至1ms，叢集的排程效率得到了提升。 

3. Job送出過程 

新架構下，一次Job送出過程，需要Client和ClusterManager、TaskTracker均進行互動（如圖3所示）：JobClient 先向ClusterManager申請啟動JobTracker所需要的資源；申請到之後，JobClient在指定的TaskTracker上啟動 JobTracker程序，将Job送出給JobTracker；JobTracker再向ClusterManager申請Map和Reduce資源； 申請到之後，JobTracker将任務啟動指令送出給指定的TaskTracker。 

<a href="http://s3.51cto.com/wyfs02/M02/58/A7/wKioL1S3UQvSH1TPAAFchNDtLwQ756.jpg" target="_blank"></a>

圖3 Job送出過程  

4. 存在的問題及應對措施 

JobTracker分散化方案給計算引擎帶來高效性和高擴充性，但沒有帶來高可用性，單一故障點的問題在此方案中仍然存在，此時的單一故障點問題有别于以前，如下所述。 

（1）ClusterManager如果發生故障，不會造成Job狀态丢失而且在短時間内即可恢複。它隻存儲資源情況，不存儲狀 态，ClusterManager在很短的時間内可以重新開機完成。重新開機之後，TaskTracker重新向ClusterManager彙報資 源，ClusterManager從重新開機至完全獲得叢集的資源情況整個階段可以在10秒内完成。 

（2）JobTracker如果發生故障，隻會影響單個Job，對其他Job不會造成影響。 

基于以上兩點，認為新方案的單一故障點問題影響不大，而且考慮方案實施的複雜度和時效性，TDW在JobTracker分散化方案中沒有設計高可用方案， 而是通過外圍系統來降低影響：監控系統保證ClusterManager故障及時發現和恢複；Lhotse排程系統從使用者任務級别保證Job重試。 

NameNode高可用 

1. 單點NameNode的問題 

TDW以前的存儲引擎是單點NameNode，在一個業務對應一個叢集的情況下，NameNode壓力較小，出故障的幾率也較小，而且NameNode單 點故障帶來的影響不會波及全部業務。但當把各個小叢集統一到大叢集，各個業務都存儲之上時，NameNode壓力變大，出故障的幾率也變 大，NameNode單點故障造成的影響将會非常嚴重。即使是計劃内變更，停止NameNode服務耗時将近2個小時，計劃内的停止服務變更也給使用者帶來 了較大的影響。 

2. NameNode高可用方案 

TDW設計了一種一主兩熱備的NameNode高可用方案。新架構下NameNode角色有三個：一主（ActiveNameNode）兩熱備 （BackupNameNode）。ActiveNameNode儲存namespace和block資訊，對DataNode下發指令，并且對用戶端提 供服務。BackupNameNode包括standby和newbie兩種狀态：standby提供對ActiveNameNode中繼資料的熱備，在 ActiveNameNode失效後接替其對外提供服務，newbie狀态是正處于學習階段，學習完畢之後成為standby。 

（1）Replicaton協定。為了實作BackupNameNode對ActiveNameNode的中繼資料一緻，随時準備接管 ActiveNameNode角色，中繼資料記錄檔需要在主備間同步。用戶端對中繼資料的修改不止在ActiveNameNode記錄事務日志，事務日志還 需要從ActiveNameNode同步到BackupNameNode，用戶端的每一次寫操作，隻有成功寫入ActiveNameNode以及至少一個 BackupNameNode（或者ZooKeeper）時，才傳回用戶端操作成功。當沒有BackupNameNode可寫入時，把事務日志同步到 ZooKeeper來保證至少有一份事務日志備份。 

用戶端寫操作記錄事務日志遵循以下幾個原則： 

①寫入ActiveNameNode，如果寫入失敗，傳回操作失敗，ActiveNameNode自動退出； 

②當寫入至少兩個節點（Active-NameNode和Standby/ZooKeeper/LOG_SYNC newbie）時傳回操作成功，其他傳回失敗；LOG_SYNC newbie表示newbie已經從ActiveNameNode擷取到全量日志後的狀态； 

③當隻成功寫入ActiveNameNode，此後的Standby和ZooKeeper均寫入失敗時，傳回失敗； 

④當隻存在ActiveNameNode時，進入隻讀狀态。 

（2）Learning協定。newbie學習機制確定newbie啟動後通過向ActiveNameNode學習擷取最新的中繼資料資訊，學習到與 ActiveNameNode同步時變成standby狀态。newbie從ActiveNameNode擷取最新的fsimage和edits檔案列 表，ActiveNameNode還會和newbie之間建立事務日志傳輸通道，将後續記錄檔同步給newbie，newbie将這些資訊載入記憶體，構 建最新的中繼資料狀态。 

（3）事務日志序号。為了驗證事務日志是否丢失或者重複，為事務日志指定遞增連續的記錄号txid。在事務日志檔案edits中加入txid，保證 txid的連續性，日志傳輸和加載時保證txid連續遞增，儲存記憶體中的中繼資料資訊到fsimage檔案時，将目前txid寫入fsimage頭部，載入 fsimage檔案到記憶體中時，設定中繼資料目前txid為fsimage頭部的txid。安全日志序号（safe txid）儲存在ZooKeeper上，ActiveNameNode周期性地将txid寫入ZooKeeper作為safe txid，在BackupNameNode轉換為ActiveNameNode時，需要檢查BackupNameNode目前的txid是否小于safe txid，若小于則禁止這次角色轉換。 

（4）checkpoint協定。新架構仍然具有checkpoint功能，以減少日志的大小，縮短重新開機時建構中繼資料狀态的耗時。由 ActiveNameNode維護一個checkpoint線程，周期性地通知所有standby做checkpoint，指定其中的一個将産生的 fsimage檔案上傳給ActiveNameNode。 

（5）DataNode雙報。Block副本所在的節點清單是NameNode中繼資料資訊的一部分，為了保證這部分資訊在主備間一緻性，DataNode 采用雙報機制。DataNode對塊的改動會同時廣播到主備，對主備下發的指令，DataNode差別對待，隻執行主機下發的指令而忽略掉備機下發的命 令。 

（6）引入ZooKeeper。主要用來做主節點選舉和記錄相關日志：NameNode節點狀态、安全日志序号、必要時記錄edit log。 

3. 主備切換過程 

當主退出時主備狀态切換的過程（如圖4所示）：當ActiveNameNode節點IP1由于某些原因退出時，兩個備節點IP2和IP3通過向 ZooKeeper搶鎖競争主節點角色；IP2搶到鎖成為ActiveNameNode，用戶端從ZooKeeper上重新擷取主節點資訊，和IP2進行 互動，這時即使IP1服務恢複，也是newbie狀态；事務日志在主備間同步，newbie IP1通過向主節點IP2學習成為standby狀态。 

<a href="http://s3.51cto.com/wyfs02/M02/58/AA/wKiom1S3UE2RPjoAAAG3daUfIeg829.jpg" target="_blank"></a>

圖4 主退出時主備狀态切換  

4. 存在的問題 

NameNode高可用方案給存儲引擎帶來了高可用性，但在高效性方面做出了一些犧牲，由于事務日志需要同步，寫性能有20%左右的下降。 

其他優化 

TDW在實施大叢集過程中，除了主要實施JobTracker分散化和NameNode高可用兩個方案，還進行了一些其他優化。 

1. NameNode分散化 

随着存儲量和業務的不斷增長，一個HDFS中繼資料空間的通路壓力與日俱增。通過NameNode分散化來減少一個中繼資料空間的通路壓力。NameNode 分散化主要對中繼資料資訊進行分拆，對使用者透明，使用者通路認為處于同一個存儲引擎，底層可以拆分成多個叢集。TDW在Hive層增加使用者到HDFS叢集的路 由表，使用者表的資料将寫入對應的HDFS叢集，對外透明，使用者隻需使用标準的建表語句即可。TDW根據公司業務的實際應用場景，根據業務線和共享資料等把 資料分散到兩個HDFS叢集，有利于資料共享同時也盡量規避叢集間的資料拷貝。采用簡單、改動最少的方案解決了實際的問題。 

2. HDFS相容 

TDW内部有三個HDFS版本：0.20.1、CDH3u3、2.0，線上主流版本是CDH3u3，主流HDFS版本使用的RPC架構尚未優化成 Thrift或者Protocol Buffers等，三個版本互不相容，增加了互相通路的困難。通過RPC層相容方式實作了CDH3u3和0.20.1之間的互通，通過完全實作兩套接口方 式實作了CDH3u3和2.0之間的互通。 

3. 防止資料誤删除 

重要資料的誤删除會給TDW帶來不可估量的影響，TDW為了進一步增加資料存儲可靠性，不僅開啟NameNode資源回收筒特性，還增加兩個特性： 删除黑白名單，删除接口修改成重命名接口，白名單中的目錄可以被删除，白名單中的IP可以進行删除操作，其他則不可；DataNode資源回收筒，塊删除操作 不會立即進行磁盤檔案的删除，而是維護在待删除隊列裡，過期之後才進行實際的删除操作，這樣可以保證在一定時間内如果發現重要的資料被誤删除時可以進行數 據恢複，還可以防止NameNode啟動之後中繼資料意外缺失而造成資料直接被删除的風險。 

結語 

TDW從實際情況出發，采取了一系列的優化措施，成功實施了單個大規模叢集的建設。為了滿足使用者日益增長的計算需求，TDW正在進行更大規模叢集的建設， 并向實時化、集約化方向發展。TDW準備引入YARN作為統一的資源管理平台，在此基礎上建構離線計算模型和Storm、Spark、Impala等各種 實時計算模型，為使用者提供更加豐富的服務。

本文轉自 小強測試幫 51CTO部落格，原文連結：http://blog.51cto.com/xqtesting/1604284，如需轉載請自行聯系原作者