01 背景

隨著B站業(yè)務(wù)的高速發(fā)展，業(yè)務(wù)數(shù)據(jù)的生產(chǎn)速度變得越來越快，離線集群規(guī)模快速膨脹，既有機房內(nèi)的機位急劇消耗，在可預(yù)見的不久的將來會達到機房容量上限，阻塞業(yè)務(wù)的發(fā)展。因此，如何解決單機房容量瓶頸成為了我們亟待解決的問題。

目前，針對機房容量問題的解決方案業(yè)界主要有以下兩種：

1） 集群整體搬遷至更高容量的機房（scale up） 。該方案是一種縱向擴容方案，即將現(xiàn)有集群搬遷至容量更大的機房，從而提供集群擴展的空間?，F(xiàn)實中，集群遷移一般不能影響業(yè)務(wù)的發(fā)展，即保證不停機，因此，遷移過程中需要兩個規(guī)模相近的集群做全量遷移，或者需要一個具有一定規(guī)模的過渡集群，分批次遷移；對于大規(guī)模（tens of thousands）集群來說，遷移的經(jīng)濟成本巨大；另外，遷移后的新機房會有再次達到容量上限的風(fēng)險。

2） 多機房方案（scale out） ，即一個機房容量有限，擴展為多個機房，同時對既有架構(gòu)進行一定的改造，保證用戶視角仍像是一個機房。此舉可依據(jù)業(yè)務(wù)需要，采用靈活的方式增量擴容，從而一定程度上避免容量冗余問題。然而，該方案會存在跨機房數(shù)據(jù)交互，而機房間網(wǎng)絡(luò)帶寬一般也存在瓶頸；同時，網(wǎng)絡(luò)的抖動或斷網(wǎng)可能造成跨機房業(yè)務(wù)出現(xiàn)異常。因此，該方案需要考慮/解決網(wǎng)絡(luò)帶寬不足及網(wǎng)絡(luò)抖動/斷網(wǎng)問題帶來的影響，技術(shù)成本較集群整體搬遷方案要高。

就我們目前自建機房的情況來看，中短期暫無清退既有機房（全部搬遷至新機房）的計劃，從長期來看也會存在多個機房；另外，比起方案2的技術(shù)成本，我們更難接受方案1的經(jīng)濟成本和容量風(fēng)險。因此，方案2是我們解決機房容量問題首選方案。

02 多機房方案

2.1 面臨的問題

上文提到多機房方案面臨帶寬等網(wǎng)絡(luò)問題，多機房方案的設(shè)計受其制約。

帶寬瓶頸

離線場景主要是批處理場景，是對海量歷史數(shù)據(jù)進行離線分析/處理的場景，該場景對延遲不敏感，但由于其處理數(shù)據(jù)量巨大對網(wǎng)絡(luò)帶寬等資源消耗較大；另外，生產(chǎn)場景中作業(yè)數(shù)量一般較多且執(zhí)行時間不受控，若兩個機房的主機只是簡單疊加在一起做為一個集群來用，可能會存在大量的跨機房互訪，產(chǎn)生大量的隨機流量打滿有限的跨機房帶寬, 此時除離線自身受影響外, 還可能對其它跨機房業(yè)務(wù)造成影響 。因此，如何防止跨機房隨機流量打滿跨機房帶寬是多機房方案要解決的一個重要問題。

網(wǎng)絡(luò)抖動&連通性

跨城網(wǎng)絡(luò)會受供應(yīng)商服務(wù)質(zhì)量影響（或施工影響）造成抖動（或斷網(wǎng)）, 與機房內(nèi)CLOS架構(gòu)的網(wǎng)絡(luò)質(zhì)量相比會低很多。若兩個機房的主機當(dāng)做為一個集群來用，如圖1 HDFS示例，當(dāng)網(wǎng)絡(luò)抖動時，不但會導(dǎo)致跨機房讀寫延遲增加，還會影響DN的IBR等過程，造成服務(wù)性能和穩(wěn)定性下降；當(dāng)網(wǎng)絡(luò)出現(xiàn)嚴(yán)重問題造成斷網(wǎng)時，會導(dǎo)致異地機房數(shù)據(jù)不可用，還會導(dǎo)致異地機房DN失聯(lián)，造成大量Block低于預(yù)期副本數(shù)，觸發(fā)NN大量補副本等問題。因此，如何降低網(wǎng)絡(luò)抖動及網(wǎng)絡(luò)連通性問題帶來的影響是多機房方案要解決的另外一個不可忽視的問題。

圖1 HDFS 架構(gòu)

2.2 設(shè)計選型

如上所述，多機房的主要矛盾是跨機房網(wǎng)絡(luò)帶寬不足、穩(wěn)定性差與離線海量數(shù)據(jù)處理任務(wù)高效產(chǎn)出之間的矛盾，解決該主要矛盾面臨的核心問題是如何減少跨機房帶寬的消耗，以及如何降低網(wǎng)絡(luò)穩(wěn)定性問題帶來的影響。

經(jīng)調(diào)研，單元化架構(gòu)是為解決多地多中心問題演進而來的部署架構(gòu)，其中，單元是指一個能完成所有業(yè)務(wù)操作的自包含集合，在這個集合中包含了業(yè)務(wù)所需的所有服務(wù)，以及分配給這個單元的數(shù)據(jù) [1-2] 。按照單元化的思路，在多機房場景中，每個機房可以作為一個單元，每個單元內(nèi)提供作業(yè)執(zhí)行所需要的全部服務(wù)以及數(shù)據(jù)，保證作業(yè)在單元內(nèi)完成，從而解決上述多機房面臨的核心問題；單元化拆分后任何一個單元的故障只會影響局部，不會造成整體癱瘓；在選定采用單元化思想來設(shè)計了多機房方案之后， 多機房方案的核心問題就限定在了如何決定作業(yè)與數(shù)據(jù)放置，以及如何讓作業(yè)訪問距離近的數(shù)據(jù)，來降低跨機房帶寬的消耗及網(wǎng)絡(luò)穩(wěn)定性問題帶來的影響。

帶著上面的核心問題，我們調(diào)研了業(yè)界大廠的多機房解決方案 [3-7] 。這些方案在計算層面為防止Shuffle等中間結(jié)果數(shù)據(jù)造成跨機房流量，每個機房均獨立部署了計算集群，在該層面均符合單元化思想；但在存儲存面存在分歧，如圖2所示，依據(jù)數(shù)據(jù)和異地機房的數(shù)據(jù)副本是否屬于同一組NameSpace (NS)，大體可以分為多機房單集群方案和多機房多集群方案。

圖2 多機房方案分類

[3-5] 采用了多機房單集群方案，該方案中采用Block級的數(shù)據(jù)副本，數(shù)據(jù)和數(shù)據(jù)副本同屬于一組NS，無數(shù)據(jù)一致性問題，但因NS只能在其中一個機房，無法有效應(yīng)對網(wǎng)絡(luò)連通性問題，且Namenode異地副本管理（BlockPlacementPolicy）和相關(guān)工具（Mover, Balancer等）改造成本較大，另外該方案可擴展性也受單集群規(guī)模制約。[6-7] 采用了多機房多集群方案，整體符合單元化思想。

其中 [6] 應(yīng)用于云梯遷機房場景，它首先在同機房中通過Fast Copy將文件元數(shù)據(jù)分離到兩個NS，然后再通過同NS內(nèi)DN到DN的跨機房Copy將數(shù)據(jù)復(fù)制到遠程機房，該方案在一定程度上可以有效應(yīng)對跨機房網(wǎng)絡(luò)風(fēng)險，但因存在兩次copy時效性上難以保障，另外也存在異地的數(shù)據(jù)節(jié)點，因此本質(zhì)上也存在多機房單集群方案改造成本和擴展性問題；[7] 阿里Yugong（Yugong: Geo-Distributed Data and Job Placement at Scale）基于MetaStore針對分區(qū)表場景，通過調(diào)整作業(yè)放置和數(shù)據(jù)放置來降低跨機房帶寬的消耗；

如圖3所示，計算A、B存在跨機房訪問行為，通過調(diào)整（互換）計算A、B的放置位置可以有效減少跨機房訪問流量；計算C、D同時跨機房消費同一份數(shù)據(jù)3, 若通過數(shù)據(jù)復(fù)制的方式將數(shù)據(jù)3復(fù)制到機房2， 讓C、D依賴數(shù)據(jù)3在機房2中的副本，則可以減少一次跨機房消費數(shù)據(jù)流量。但對于我們采用開源大數(shù)據(jù)架構(gòu)的場景來說，需要改造（分屬于多個子部門的）多種計算框架來適配其基于MetaStore的數(shù)據(jù)副本管理和數(shù)據(jù)路由，改造實施成本較大；另外，其基于MetaStore的設(shè)計只能解決表（SQL）場景的多機房問題，也不能覆蓋我們對非表場景提供多機房支持的需求；不過，該方案中通過“作業(yè)放置-數(shù)據(jù)復(fù)制”來解決帶寬瓶頸問題的思路非常值得我們借鑒。

圖3 任務(wù)跨機房隨機分布

綜上，我們參考Yugong“作業(yè)放置-數(shù)據(jù)復(fù)制”的思路，采用有限的單元化思想設(shè)計多機房方案；如圖4所示，每個機房部署一套獨立的完整的集群（YARN&HDFS），為作業(yè)在一個機房內(nèi)執(zhí)行提供最基本的服務(wù)保障，從而在跨機房網(wǎng)絡(luò)出現(xiàn)異常時，降低影響范圍；同時，通過合理的作業(yè)放置和有計劃的數(shù)據(jù)復(fù)制，消除跨機房隨機訪問流量及跨機房數(shù)據(jù)重復(fù)消費等問題，來達到降低帶寬消耗的目的；另外，我們結(jié)合內(nèi)部的基礎(chǔ)設(shè)施情況，以及滿足表和非表兩種場景的需求，我們選擇了基于擴展HDFS Router（RBF）多掛載點來實現(xiàn)數(shù)據(jù)副本管理和數(shù)據(jù)路由功能，并通過Client IP感知自動將數(shù)據(jù)請求路由至較近的機房；還有為解決數(shù)據(jù)復(fù)制帶來的一致性問題引入了Version服務(wù)等，圖中涉及組件將在實現(xiàn)部分進行介紹。

圖4 多機房架構(gòu)

2.3 總體流程

圖5展示了以Hive作業(yè)為例的在上述設(shè)計思路下的總體流程，圖中綠色模塊為我們新增或改造組件。首先，通過周期性的分析作業(yè)間依賴關(guān)系及依賴的數(shù)據(jù)大小，確定作業(yè)放置位置信息并進行持久化（DataManager用于管理作業(yè)放置信息等），B站的作業(yè)調(diào)度平臺（Archer和Airflow）提交作業(yè)時，先獲取作業(yè)的放置機房信息，并檢查預(yù)期放置機房的數(shù)據(jù)副本是否Ready，若Ready則提交作業(yè)，否則，阻塞提交，等待數(shù)據(jù)復(fù)制服務(wù)完成復(fù)制數(shù)據(jù)；其次，作業(yè)調(diào)度提交后，拉起Hive/Spark Driver生成可執(zhí)行計劃，向預(yù)期DC的Yarn集群提交Job，等待拉起Job，同時我們在Yarn層面也做了改造，基于Yarn Federation架構(gòu)，實現(xiàn)了基于app tag和隊列的機房調(diào)度策略，這個在下文也會介紹; 最后，被拉起的作業(yè)請求HDFS數(shù)據(jù)，HDFS Router依據(jù)Client IP所屬的DC信息，自動將請求路由到距離Client較近的數(shù)據(jù)復(fù)本所在機房的NS, 并將結(jié)果返回Client。

圖5 多機房作業(yè)調(diào)度執(zhí)行流程

多機房核心流程包括作業(yè)放置、數(shù)據(jù)復(fù)制、數(shù)據(jù)路由、版本控制、數(shù)據(jù)限流、跨機房流量分析等幾個階段，上述Job提交流程并未完全涵蓋，下文實現(xiàn)部分我們將對所有階段進行詳細說明。

03 多機房方案實現(xiàn)

下面章節(jié)會對多機房核心環(huán)節(jié)進行介紹， 包括作業(yè)放置、數(shù)據(jù)復(fù)制、數(shù)據(jù)路由，以及為保障數(shù)據(jù)副本一致性引入的數(shù)據(jù)版本服務(wù)和帶寬控制的限流服務(wù)，并引入事后的跨機房流量分析工具，用以發(fā)現(xiàn)預(yù)期外的跨機房行為指導(dǎo)調(diào)整。

3.1 作業(yè)放置

a. 依賴分析

大數(shù)據(jù)離線場景，作業(yè)數(shù)量多，作業(yè)之間依賴復(fù)雜。比如，大數(shù)據(jù)離線報表處理業(yè)務(wù)，從數(shù)據(jù)采集，清洗，到各個層級的報表的匯總運算，到最后數(shù)據(jù)導(dǎo)出到外部業(yè)務(wù)系統(tǒng)，一個完整的業(yè)務(wù)流程，可能涉及到成百上千個相互交叉依賴關(guān)聯(lián)的作業(yè)。就作業(yè)放置來說，對復(fù)雜作業(yè)依賴的管理和分析工作至關(guān)重要， 而如我們自研的調(diào)度平臺Archer等DAG工作流類調(diào)度系統(tǒng)，自身具有較強的作業(yè)依賴管理能力，因此，我們僅需要聚焦作業(yè)依賴分析以確定要遷移的業(yè)務(wù)。

我們依據(jù)作業(yè)間依賴關(guān)系及需要處理的數(shù)據(jù)大小，基于社區(qū)發(fā)現(xiàn)（Community Detection）探索了一種考慮跨機房帶寬代價的作業(yè)關(guān)系鏈劃分模型。該模型首先依據(jù)調(diào)度系統(tǒng)管理的作業(yè)間的依賴關(guān)系構(gòu)建DAG圖， 然后從DAG圖中圈出相對高內(nèi)聚（相對比較閉環(huán)）的業(yè)務(wù)子單元，最后結(jié)合相互依賴的子單元間的數(shù)據(jù)量選擇出的可以遷移的子單元；如圖6所示的簡單DAG, 我們假定圖中正方形代表計算，圓形代表數(shù)據(jù)，圓的大小代表數(shù)據(jù)大小，則我們以虛線作為劃分邊界將DAG分成兩個子單元，分別調(diào)度到兩個機房，則可滿足數(shù)據(jù)傳輸代價小的目標(biāo)。當(dāng)然，整個過程除了考慮跨機房數(shù)據(jù)訪問代價外，還需要考慮機房計算和存儲資源是否可以滿足需求。

圖6 依賴關(guān)系劃分

一般而言，實際生產(chǎn)中的ETL等周期性調(diào)度作業(yè)相對比較穩(wěn)定， 不會頻繁發(fā)生變化，甚至部分作業(yè)不會出現(xiàn)變化，因此，確定Job放置在那個機房的的依賴分析過程可以以天或周為單位周期性的離線計算產(chǎn)生；另外，從管理的角度來看，公司一般會有多個相對比較獨立的業(yè)務(wù)部門，每個業(yè)務(wù)部門又會垂直的劃分出多個業(yè)務(wù)子單元，業(yè)務(wù)內(nèi)的作業(yè)間聯(lián)系緊密程度遠大于業(yè)務(wù)之間；同時，業(yè)務(wù)（單元）也是資源管理單元，以及多機房落地實施過程中的溝通單元；因此，在實踐中往往是以業(yè)務(wù)單元為邊界進行依賴劃分。

b. 作業(yè)放置

我們的生產(chǎn)環(huán)境中存在多個作業(yè)調(diào)度平臺，如Archer、Airflow等平臺，將Job放置在那個機房的信息維護在任一平臺都不能涵蓋所有作業(yè)， 因此我們引入DataManager服務(wù)（在整個體系中的位置見圖4）作為接入層，用來管理作業(yè)放置的IDC信息和需要進行數(shù)據(jù)復(fù)制的路徑信息，Archer/Airflow等調(diào)度平臺通過對接該服務(wù)來接入多機房體系；下面以自研DAG調(diào)度平臺Archer為例描述工作流程如下：

前置工作：Archer 通過DataManager接口設(shè)置作業(yè)的放置位置信息，以及依賴數(shù)據(jù)的路徑pattern、范圍、生命周期等信息。

Archer訪問DataManager確定作業(yè)放置的IDC信息，并為作業(yè)選擇符合IDC作業(yè)配置信息。

Archer詢問Job在該IDC的數(shù)據(jù)是否Ready，若Ready，則設(shè)置app tag為該IDC并通過Yarn RMProxy向計算集群提供作業(yè)；否則，掛起并等待數(shù)據(jù)Ready后嘗試重新提交；其中數(shù)據(jù)是否Ready，是通過DataManager轉(zhuǎn)發(fā)請求至數(shù)據(jù)復(fù)制服務(wù)得到。

另外由于我們的業(yè)務(wù)部門和Yarn上的一級隊列做了一一映射，所以一旦某個業(yè)務(wù)部門的數(shù)據(jù)整體遷移到新機房后，我們會在RMProxy中設(shè)置該部門對應(yīng)的queue mapping策略到新機房，這樣無論是從調(diào)度平臺還是其他用戶客戶端提交的Job即使沒有接入DataManager也能正確路由到新機房的計算集群，同時回收老機房的計算和存儲資源。

圖7 Yarn調(diào)度策略

3.2 數(shù)據(jù)復(fù)制

a. 復(fù)制服務(wù)

作業(yè)放置會將有聯(lián)系緊密的Job放在一個機房，以減少跨機房訪問，進而減少跨機房網(wǎng)絡(luò)帶寬消耗；對于無法消除的跨機房依賴，特別是異地機房使用頻次大于1的數(shù)據(jù)，需要異地機房也存在數(shù)據(jù)副本，以降低網(wǎng)絡(luò)帶寬消耗；因此，我們提供了數(shù)據(jù)復(fù)制服務(wù)來進行副本復(fù)制。

數(shù)據(jù)復(fù)制服務(wù)基于社區(qū)提供的DistCp工具實現(xiàn)， 并在正確性、原子性、冪等性、傳輸效率等方面作了增強， 同時支持流控、多租戶傳輸優(yōu)先級（高優(yōu)作業(yè)能得到更多跨機房流量和計算資源配額），副本生命周期管理等功能。

b. 復(fù)制流程

數(shù)據(jù)復(fù)制主要針對有規(guī)律的周期性調(diào)度作業(yè)進行，這類作業(yè)一般比較固定，通過對作業(yè)歷史運行記錄進行分析即可推測出作業(yè)的輸入輸出情況，包括數(shù)據(jù)路徑和使用的數(shù)據(jù)范圍（防止長時間跨度回刷任務(wù)大量復(fù)制）等信息。因此，當(dāng)確定好待遷移的作業(yè)后，可以提煉出數(shù)據(jù)路徑規(guī)則（rules），并持久化到DataManager的規(guī)則庫中（規(guī)則庫會隨作業(yè)放置的變化而進行周期性更新）。

然后，針對不同的場景使用規(guī)則庫進行路徑抽取，下面以Hive表場景為例描述數(shù)據(jù)復(fù)制流程，如圖8所示， 首先收集Hive MetaStore的掛載表/分區(qū)相關(guān)的Event信息至Kafka服務(wù)，然后通過實時Flink任務(wù)清洗出符合上述規(guī)則庫中規(guī)則的路徑，當(dāng)檢測到熱點表的新分區(qū)生成后，交由數(shù)據(jù)復(fù)制服務(wù)（DRS）進行傳輸，生成異地機房副本，DRS本質(zhì)上是一個DistCp作業(yè)的管理服務(wù)，在傳輸完成后由數(shù)據(jù)復(fù)制服務(wù)持久化副本信息（包括路徑、版本、TTL等），以對副本數(shù)據(jù)進行全生命周期管理（刪除過期的跨機房副本，釋放存儲空間），目前B站線上有100+張Hive熱點表路徑設(shè)置了跨機房副本策略。

圖8 數(shù)據(jù)復(fù)制流程

上述復(fù)制流程采用自動發(fā)現(xiàn)主動復(fù)制的策略，可以快速捕獲并準(zhǔn)備數(shù)據(jù)副本，經(jīng)過統(tǒng)計在我們的生產(chǎn)中數(shù)據(jù)副本延遲的PT90可以控制在1min以內(nèi), PT99 在5min以內(nèi)，可以有效滿足離線場景的業(yè)務(wù)需要；然而，上述自動發(fā)現(xiàn)主動復(fù)制的策略，可以有效解決增量數(shù)據(jù)副本的問題，但對于待遷移作業(yè)來說，可能還依賴較長一段時間的存量數(shù)據(jù)，針對該問題，我們除了采用提前啟動復(fù)制流程的方式準(zhǔn)備存量數(shù)據(jù)外，還針對需要快速遷移的場景引入了基于Snapshot的數(shù)據(jù)遷移策略進行初始復(fù)制，因Snapshot為社區(qū)成熟技術(shù)不再綴述。

3.3 數(shù)據(jù)路由

上小節(jié)介紹的數(shù)據(jù)拷貝后雙機房均會存在某路徑的數(shù)據(jù)副本，當(dāng)作業(yè)放置到IDC后如何定位到正確的數(shù)據(jù)是數(shù)據(jù)路由服務(wù)要解決的關(guān)鍵問題；

我們在 《HDFS在B站的探索和實踐》 中提到的基于HDFS Router的多掛載點實現(xiàn)的MergeFs的基礎(chǔ)上，實現(xiàn)了鏡像掛載點來實現(xiàn)數(shù)據(jù)路由功能。為方便描述，我們約定原始數(shù)據(jù)為主數(shù)據(jù)， 傳輸?shù)疆惖貦C房的數(shù)據(jù)為副本數(shù)據(jù)（也稱為鏡像數(shù)據(jù)，該數(shù)據(jù)只允許讀取和刪除），并且約定鏡像掛載點中第一掛載點為主數(shù)據(jù)，之后的掛載點為副本數(shù)據(jù)（理論上可以擴展多個機房），為了在路由層面做到對用戶透明，我們在鏡像掛載點的處理邏輯中，增加了請求來源的IP位置感知功能，該功能能過獲取請求來源IP的位置信息，判斷請求來源的DC并將請求路由到相應(yīng)的DC的HDFS。如圖9示例所示，若數(shù)據(jù)請求來自DC1, 則Router將數(shù)據(jù)請求重定向到DC1的HDFS集群，來自DC2則定向到DC2的HDFS集群（圖中同種顏色線條標(biāo)識請求路徑）。

圖9 基于Router的數(shù)據(jù)路由

為了降低跨機房帶寬的消耗，原則上，我們規(guī)定所有對數(shù)據(jù)的讀取操作，都只允許在本地機房（即Client所在機房）， 否則先拷貝到本地機房。但特殊情況下，如圖10所示，若Data Replication Service發(fā)生異常短時間無法修復(fù)或ns長時間異常時，則我們允許降級為跨機房限流讀（副本未ready情況, 超過一定的時間未在目標(biāo)機房讀取到數(shù)據(jù)，則降級），限流部分在后面章節(jié)進行詳細介紹。

圖10 數(shù)據(jù)路由容錯

另外 ，由于歷史原因，在我們的生產(chǎn)中存在一種特殊的臨時庫，用于管理用戶SQL作業(yè)中的創(chuàng)建的短生命周期的臨時表（Temporary table，七天自動清理），該類臨時表表名不固定（例如一些ETL作業(yè)會在臨時表名上加上日期后綴)，也就造成了表類路徑不固定；針對該類路徑不固定的情況，無法使用上述鏡像掛載點進行管理，因此， 我們引入一種名叫IDC_FOLLOW的多掛載點，用于掛載多個機房中的臨時庫路徑；當(dāng)讀寫臨時表時，會依據(jù)Client所在的DC選擇DC內(nèi)HDFS NS掛載路徑來存取數(shù)據(jù)，從而解決臨時表跨機房流量的問題。

3.4 版本服務(wù)

分布式場景下，通過數(shù)據(jù)復(fù)制方式產(chǎn)生副本，不可避免會導(dǎo)致一致性問題，因此，多機房存在數(shù)據(jù)副本時，除了涉及上述路由選擇問題外，還必須考慮數(shù)據(jù)版本一致性問題，我們通過引入版本服務(wù)（Version）解決該問題；為了簡化版本服務(wù)設(shè)計, 針對大數(shù)據(jù)離線場景寫少讀多的特性，我們依據(jù)CAP理論對鏡像掛載點的實現(xiàn)做了一定的取舍，規(guī)定了對主數(shù)據(jù)可以進行所有操作，副本數(shù)據(jù)只允許讀/刪操作；在這個前提下，我們引入了基于HDFS Editlog的版本服務(wù)，如圖11所示，該服務(wù)以觀察者的身份監(jiān)控向HDFS JournalNodes（JN）訂閱路徑的變更行為，并以操作ID（transaction id）來標(biāo)識數(shù)據(jù)版本；若訂閱的路徑中數(shù)據(jù)發(fā)生了變化，則會通過editlog傳導(dǎo)到JN，再由JN通知Version進行版本更新；因所有對數(shù)據(jù)的變更操作都會記錄editlog，因此，不論SQL場景和非SQL場景，只要數(shù)據(jù)存在變化均可被版本服務(wù)捕捉到，從而可以有效保證數(shù)據(jù)的一致性。

圖11 數(shù)據(jù)版本工作流程

上文2.3節(jié)總體流程所描述的提交作業(yè)時，當(dāng)獲取到作業(yè)預(yù)期的放置機房后，檢查依賴數(shù)據(jù)是否Ready的工作也包括版本檢查工作；當(dāng)作業(yè)需要副本數(shù)據(jù)時，會通過數(shù)據(jù)傳輸服務(wù)檢查已傳輸?shù)臄?shù)據(jù)副本的版本與版本服務(wù)中訂閱的最新版本是否一致，若一致允許作業(yè)提交使用數(shù)據(jù)副本；否則，作業(yè)臨時阻塞，待傳輸服務(wù)更新副本數(shù)據(jù)后，則允許提交作業(yè)；若超過一定的時間未在目標(biāo)機房讀取到數(shù)據(jù)，則降級為讀取主數(shù)據(jù)。

3.5 限流服務(wù)

我們的場景下跨機房帶寬有限（約4Tbps），并且和在線服務(wù)、實時服務(wù)等對延遲更敏感的服務(wù)共用帶寬，為防止離線跨機房流量（特別是計劃外的跨機流量）打滿帶寬影響在線業(yè)務(wù)， 我們引入了基于令牌桶的限流服務(wù)。

圖12 令牌桶

令牌桶限流的核心思想為當(dāng)進行某操作需要令牌時，需要從令牌桶中取出相應(yīng)的令牌數(shù)，如果獲取到令牌則繼續(xù)操作，否則阻塞，用完之后不用放回?；谠撍枷胛覀冊O(shè)計了全局中心限流服務(wù)，我們在HDFS DistributedFileSystem類基礎(chǔ)上，實現(xiàn)了具有讀寫限流功能的ThrottledDistributedFileSystem，當(dāng)用戶使用該類去讀寫HDFS的文件時，ThrottledDistributedFileSystem會根據(jù)RBF返回的LocatedBlock中的client IDC信息和Block IDC信息，判斷此次讀寫流量是否會跨機房，如果是會先嘗試向ThrottleService發(fā)送申請跨機房帶寬請求（Token），申請到Token后，再進行后續(xù)的HDFS讀寫，如果申請的流量用完后，再向ThrottleService申請新的帶寬Token；除利用令牌桶固有的特性外，我們在令牌桶的基礎(chǔ)上實現(xiàn)了隊列優(yōu)先級和加權(quán)公平特性，限流服務(wù)的隊列優(yōu)先級和調(diào)度系統(tǒng)中的作業(yè)優(yōu)先級也做一一映射，來保障多租戶情況下重要服務(wù)可以優(yōu)先獲取到Token；在穩(wěn)定性方面，為了降低限流服務(wù)的壓力，我們設(shè)置每個Token代表相對較大的流量單元，來降低Token的獲取次數(shù)過多帶來的性能影響；為防止限流服務(wù)宕機導(dǎo)致作業(yè)阻塞，我們增加了降級為本地固定帶寬的策略，同時隨著計算引擎持續(xù)接入限流服務(wù)，服務(wù)本身的穩(wěn)定性和請求水位成為瓶頸（單機100K+ qps），我們通過水平擴展服務(wù)的方式增強了限流服務(wù)的性能。

3.6 跨機房流量分析

隨著多機房項目的逐漸推進，跨機房流量也日漸增長，高峰時刻偶爾會打滿專線帶寬。為了對跨機房帶寬流量進行有效管控，我們需要了解哪些作業(yè)貢獻了最多的跨機房流量，從而進行針對性治理。從離線作業(yè)的角度看，網(wǎng)絡(luò)流量來源主要有三塊：

• 從上游讀取數(shù)據(jù)
• 作業(yè)執(zhí)行過程中不同Executor/Task之間shuffle數(shù)據(jù)
• 寫數(shù)據(jù)到下游表

在B站多機房的場景中，因為采用單元化架構(gòu)每機房均存在獨立Yarn的集群，作業(yè)不會跨機房運行也就不存在跨機房Shuffle數(shù)據(jù)的情況，因此只需考慮讀寫HDFS文件過程中產(chǎn)生的跨機房流量即可，而讀寫HDFS文件產(chǎn)生的跨機房流量又可以分為計劃內(nèi)流量和非計劃內(nèi)流量兩大類：

• 計劃內(nèi)流量：3.2 小節(jié)所述數(shù)據(jù)復(fù)制服務(wù)進行數(shù)據(jù)副本復(fù)制產(chǎn)生的流量，我們稱為計劃內(nèi)流量， 該部分?jǐn)?shù)據(jù)大概率會被多次使用
• 非計劃內(nèi)流量：即非數(shù)據(jù)復(fù)制服務(wù)產(chǎn)生的數(shù)據(jù)流量，單次(或多次)使用，主要來源有以下幾種可能：a. 計劃內(nèi)的調(diào)度任務(wù)發(fā)生長時間跨度的歷史回刷，依賴的數(shù)據(jù)副本已過期銷毀b. （漏遷/錯遷/新增等）放置位置不合理的周期性調(diào)度任務(wù)，可以通過優(yōu)化作業(yè)放置消除c. Adhoc查詢，突發(fā)流量， 單次（或多次）使用，臨時生產(chǎn)需求，無法預(yù)知需要的數(shù)據(jù)，無法預(yù)先進行處理

流量分析工具

在實際生產(chǎn)過程中，非計劃內(nèi)流量不可避免，為了對跨機房流量進行有效管控，我們引入了跨機房流量分析工具，我們在引擎端和DN端做了以下改造：

• 引擎端: 在初始化HDFS Client時將作業(yè)JobId注入到DFSClient的ClientName中
• DataNode: 在DataXceiver中埋點，從ClientName中解析出JobId，并按JobId和client ip網(wǎng)段合并讀寫流量，每30s輸出統(tǒng)計結(jié)果到流量日志中

我們將每臺DN上的跨機房流量日志進行實時收集，通過Flink匯總到ClickHouse上，然后聚合分析得出每個時間段的跨機房流量作業(yè)Top10，方便對跨機房流量進行治理（包括重新放置、緊急查殺、作業(yè)優(yōu)化等）。

圖13 流量日志收集鏈路

以下是我們跨機房流量分析的監(jiān)控面板：

圖14 跨機房流量分析

Adhoc流量治理&優(yōu)化

對于Adhoc類型的非計劃內(nèi)流量，因為其隨機性，本文所述多機房體系中“數(shù)據(jù)復(fù)制-作業(yè)放置-數(shù)據(jù)路由”方式不適用；因此，我們采用一些其它的優(yōu)化手段, 比如通過運行時SQL Scan掃描出依賴的數(shù)據(jù)大小、位置信息，以節(jié)省多機房帶寬為最主要目標(biāo)，結(jié)合集群的實際負載情況，決定SQL調(diào)度哪個機房，比如：

• 訪問單張表：作業(yè)調(diào)度至數(shù)據(jù)所在機房
• 訪問多張表多表在同機房， 作業(yè)調(diào)度至數(shù)據(jù)所在機房多表在不同機房， 作業(yè)調(diào)度至數(shù)據(jù)量較大的表所在機房；較小表限流讀，或者阻塞通知拷貝服務(wù)拷貝

另外， 對于Presto這種有多源查詢能力的引擎，我們利用其Connector多源查詢功能力將每個機房視為一個Connector，在多表訪問場景中將子查詢下推發(fā)送到遠端機房進行處理，以減少垮機房流量帶寬，詳情見 《Persto在B站的實踐》 5.2節(jié)多機房架構(gòu)。

04 小結(jié)&展望

本文描述了B站離線多機房方案，該方案已平穩(wěn)上線運行半年以上，遷移數(shù)據(jù)量近300PB，作業(yè)數(shù)占集群所有作業(yè)數(shù)的1/3。從實踐的結(jié)果來看該方案在很大程度上解決了跨機房網(wǎng)絡(luò)帶寬不足、穩(wěn)定性差與離線任務(wù)高效產(chǎn)出之間的矛盾。鑒于當(dāng)前部分大數(shù)據(jù)關(guān)鍵組件的單元化進程，在抗網(wǎng)絡(luò)連通性風(fēng)險方面的能力還有較大的提升空間，后續(xù)我們將不斷的推單元化進程，進一步降低網(wǎng)絡(luò)問題的影響范圍，同時賦予部分高優(yōu)化作業(yè)“雙活”的能力。

另外隨著新機房的持續(xù)擴容（老機房無法擴容，新增節(jié)點都會部署在新機房），我們也需要持續(xù)遷移更多作業(yè)到新機房，為了提高遷移的推進速度，需要盡量減少對上下游業(yè)務(wù)方的依賴（如：請求業(yè)務(wù)方協(xié)助對子業(yè)務(wù)進行劃分和梳理），因此，我們需要實現(xiàn)更智能更自動化的待遷移數(shù)據(jù)和作業(yè)的自動劃分流程，進一步強化使用社區(qū)發(fā)現(xiàn)（Community Detection）算法將DAG能自動劃分成多個內(nèi)聚性較高的子集/社區(qū)，按照社區(qū)粒度進行遷移的工作。