平穩突破單機房容量瓶頸，B站離線多機房架構實踐

　　 一、背景

　　隨著B站業務的高速發展，業務資料的生產速度變得越來越快，離線叢集規模快速膨脹，既有機房內的機位急劇消耗，在可預見的不久的將來會達到機房容量上限，阻塞業務的發展。因此，單機房容量瓶頸成為了我們亟待解決的問題。

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

　　1）叢集整體搬遷至更高容量的機房（scale up）。該方案是一種縱向擴容方案，即將現有叢集搬遷至容量更大的機房，從而提供叢集擴充套件的空間。現實中，叢集遷移一般不能影響業務的發展，即保證不停機，因此，遷移過程中需要兩個規模相近的叢集做全量遷移，或者需要一個具有一定規模的過渡叢集，分批次遷移；對於大規模（tens of thousands）叢集來說，遷移的經濟成本巨大；另外，遷移後的新機房會有再次達到容量上限的風險。

　　2）多機房方案（scale out），即一個機房容量有限，擴充套件為多個機房，同時對既有架構進行一定的改造，保證使用者視角仍像是一個機房。此舉可依據業務需要，採用靈活的方式增量擴容，從而一定程度上避免容量冗餘問題。然而，該方案會存在跨機房資料互動，而機房間網路頻寬一般也存在瓶頸；同時，網路的抖動或斷網可能造成跨機房業務出現異常。因此，該方案需要考慮/解決網路頻寬不足及網路抖動/斷網問題帶來的影響，技術成本較叢集整體搬遷方案要高。

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

　　 二、多機房方案

　　1、面臨的問題

　　1）頻寬瓶頸

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

　　2）網路抖動&連通性

　　跨城網路會受供應商服務質量影響（或施工影響）造成抖動（或斷網）, 與機房內CLOS架構的網路質量相比會低很多。若兩個機房的主機當做為一個叢集來用，如圖1 HDFS示例，當網路抖動時，不但會導致跨機房讀寫延遲增加，還會影響DN的IBR等過程，造成服務效能和穩定性下降；當網路出現嚴重問題造成斷網時，會導致異地機房資料不可用，還會導致異地機房DN失聯，造成大量Block低於預期副本數，觸發NN大量補副本等問題。因此，如何降低網路抖動及網路連通性問題帶來的影響是多機房方案要解決的另外一個不可忽視的問題。

圖1 HDFS 架構

　　2、設計選型

　　如上所述，多機房的主要矛盾是跨機房網路頻寬不足、穩定性差與離線海量資料處理任務高效產出之間的矛盾，解決該主要矛盾面臨的核心問題是如何減少跨機房頻寬的消耗，以及如何降低網路穩定性問題帶來的影響。

　　經調研，單元化架構是為解決多地多中心問題演進而來的部署架構，其中，單元是指一個能完成所有業務操作的自包含集合，在這個集合中包含了業務所需的所有服務，以及分配給這個單元的資料[1-2] 。按照單元化的思路，在多機房場景中，每個機房可以作為一個單元，每個單元內提供作業執行所需要的全部服務以及資料，保證作業在單元內完成，從而解決上述多機房面臨的核心問題；單元化拆分後任何一個單元的故障只會影響區域性，不會造成整體癱瘓；在選定採用單元化思想來設計了多機房方案之後， 多機房方案的核心問題就限定在瞭如何決定作業與資料放置，以及如何讓作業訪問距離近的資料，來降低跨機房頻寬的消耗及網路穩定性問題帶來的影響。

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

圖2 多機房方案分類

　　[3-5] 採用了多機房單叢集方案，該方案中採用Block級的資料副本，資料和資料副本同屬於一組NS，無資料一致性問題，但因NS只能在其中一個機房，無法有效應對網路連通性問題，且Namenode異地副本管理（BlockPlacementPolicy）和相關工具（Mover, Balancer等）改造成本較大，另外該方案可擴充套件性也受單叢集規模製約。[6-7] 採用了多機房多叢集方案，整體符合單元化思想。其中 [6] 應用於雲梯遷機房場景，它首先在同機房中透過Fast Copy將檔案後設資料分離到兩個NS，然後再透過同NS內DN到DN的跨機房Copy將資料複製到遠端機房，該方案在一定程度上可以有效應對跨機房網路風險，但因存在兩次copy時效性上難以保障，另外也存在異地的資料節點，因此本質上也存在多機房單叢集方案改造成本和擴充套件性問題；[7] 阿里Yugong（Yugong: Geo-Distributed Data and Job Placement at Scale）基於MetaStore針對分割槽表場景，透過調整作業放置和資料放置來降低跨機房頻寬的消耗；如圖3所示，計算A、B存在跨機房訪問行為，透過調整（互換）計算A、B的放置位置可以有效減少跨機房訪問流量；計算C、D同時跨機房消費同一份資料3, 若透過資料複製的方式將資料3複製到機房2， 讓C、D依賴資料3在機房2中的副本，則可以減少一次跨機房消費資料流量。但對於我們採用開源大資料架構的場景來說，需要改造（分屬於多個子部門的）多種計算框架來適配其基於MetaStore的資料副本管理和資料路由，改造實施成本較大；另外，其基於MetaStore的設計只能解決表（SQL）場景的多機房問題，也不能覆蓋我們對非表場景提供多機房支援的需求；不過，該方案中透過“作業放置-資料複製”來解決頻寬瓶頸問題的思路非常值得我們借鑑。　　

圖3 任務跨機房隨機分佈

　　綜上，我們參考Yugong“作業放置-資料複製”的思路，採用有限的單元化思想設計多機房方案；如圖4所示，每個機房部署一套獨立的完整的叢集（YARN&HDFS），為作業在一個機房內執行提供最基本的服務保障，從而在跨機房網路出現異常時，降低影響範圍；同時，透過合理的作業放置和有計劃的資料複製，消除跨機房隨機訪問流量及跨機房資料重複消費等問題，來達到降低頻寬消耗的目的；另外，我們結合內部的基礎設施情況，以及滿足表和非表兩種場景的需求，我們選擇了基於擴充套件HDFS Router（RBF）多掛載點來實現資料副本管理和資料路由功能，並透過Client IP感知自動將資料請求路由至較近的機房；還有為解決資料複製帶來的一致性問題引入了Version服務等，圖中涉及元件將在實現部分進行介紹。

圖4 多機房架構

　　3、總體流程

　　圖5展示了以Hive作業為例的在上述設計思路下的總體流程，圖中綠色模組為我們新增或改造元件。首先，透過週期性的分析作業間依賴關係及依賴的資料大小，確定作業放置位置資訊並進行持久化（DataManager用於管理作業放置資訊等），B站的作業排程平臺（Archer和Airflow）提交作業時，先獲取作業的放置機房資訊，並檢查預期放置機房的資料副本是否Ready，若Ready則提交作業，否則，阻塞提交，等待資料複製服務完成複製資料；其次，作業排程提交後，拉起Hive/Spark Driver生成可執行計劃，向預期DC的Yarn叢集提交Job，等待拉起Job，同時我們在Yarn層面也做了改造，基於Yarn Federation架構，實現了基於app tag和佇列的機房排程策略，這個在下文也會介紹; 最後，被拉起的作業請求HDFS資料，HDFS Router依據Client IP所屬的DC資訊，自動將請求路由到距離Client較近的資料複本所在機房的NS, 並將結果返回Client。　　

圖5 多機房作業排程執行流程

　　多機房核心流程包括作業放置、資料複製、資料路由、版本控制、資料限流、跨機房流量分析等幾個階段，上述Job提交流程並未完全涵蓋，下文實現部分我們將對所有階段進行詳細說明。

　　 三、多機房方案實現

　　下面章節會對多機房核心環節進行介紹， 包括作業放置、資料複製、資料路由，以及為保障資料副本一致性引入的資料版本服務和頻寬控制的限流服務，並引入事後的跨機房流量分析工具，用以發現預期外的跨機房行為指導調整。

　　1、作業放置

　　1）依賴分析

　　大資料離線場景，作業數量多，作業之間依賴複雜。比如，大資料離線報表處理業務，從資料採集，清洗，到各個層級的報表的彙總運算，到最後資料匯出到外部業務系統，一個完整的業務流程，可能涉及到成百上千個相互交叉依賴關聯的作業。就作業放置來說，對複雜作業依賴的管理和分析工作至關重要， 而如我們自研的排程平臺Archer等DAG工作流類排程系統，自身具有較強的作業依賴管理能力，因此，我們僅需要聚焦作業依賴分析以確定要遷移的業務。

　　我們依據作業間依賴關係及需要處理的資料大小，基於社群發現（Community Detection）探索了一種考慮跨機房頻寬代價的作業關係鏈劃分模型。該模型首先依據排程系統管理的作業間的依賴關係構建DAG圖， 然後從DAG圖中圈出相對高內聚（相對比較閉環）的業務子單元，最後結合相互依賴的子單元間的資料量選擇出的可以遷移的子單元；如圖6所示的簡單DAG, 我們假定圖中正方形代表計算，圓形代表資料，圓的大小代表資料大小，則我們以虛線作為劃分邊界將DAG分成兩個子單元，分別排程到兩個機房，則可滿足資料傳輸代價小的目標。當然，整個過程除了考慮跨機房資料訪問代價外，還需要考慮機房計算和儲存資源是否可以滿足需求。　　

圖6 依賴關係劃分

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

　　2）作業放置

　　我們的生產環境中存在多個作業排程平臺，如Archer、Airflow等平臺，將Job放置在那個機房的資訊維護在任一平臺都不能涵蓋所有作業， 因此我們引入DataManager服務（在整個體系中的位置見圖4）作為接入層，用來管理作業放置的IDC資訊和需要進行資料複製的路徑資訊，Archer/Airflow等排程平臺透過對接該服務來接入多機房體系；下面以自研DAG排程平臺Archer為例描述工作流程如下：

　　前置工作：Archer 透過DataManager介面設定作業的放置位置資訊，以及依賴資料的路徑pattern、範圍、生命週期等資訊。

　　Archer訪問DataManager確定作業放置的IDC資訊，併為作業選擇符合IDC作業配置資訊。

　　Archer詢問Job在該IDC的資料是否Ready，若Ready，則設定app tag為該IDC並透過Yarn RMProxy向計算叢集提供作業；否則，掛起並等待資料Ready後嘗試重新提交；其中資料是否Ready，是透過DataManager轉發請求至資料複製服務得到。

　　另外由於我們的業務部門和Yarn上的一級佇列做了一一對映，所以一旦某個業務部門的資料整體遷移到新機房後，我們會在RMProxy中設定該部門對應的queue mapping策略到新機房，這樣無論是從排程平臺還是其他使用者客戶端提交的Job即使沒有接入DataManager也能正確路由到新機房的計算叢集，同時回收老機房的計算和儲存資源。　　

圖7 Yarn排程策略

　　2、資料複製

　　1）複製服務

　　作業放置會將有聯絡緊密的Job放在一個機房，以減少跨機房訪問，進而減少跨機房網路頻寬消耗；對於無法消除的跨機房依賴，特別是異地機房使用頻次大於1的資料，需要異地機房也存在資料副本，以降低網路頻寬消耗；因此，我們提供了資料複製服務來進行副本複製。

　　資料複製服務基於社群提供的DistCp工具實現， 並在正確性、原子性、冪等性、傳輸效率等方面作了增強， 同時支援流控、多租戶傳輸優先順序（高優作業能得到更多跨機房流量和計算資源配額），副本生命週期管理等功能。

　　2）複製流程

　　資料複製主要針對有規律的週期性排程作業進行，這類作業一般比較固定，透過對作業歷史執行記錄進行分析即可推測出作業的輸入輸出情況，包括資料路徑和使用的資料範圍（防止長時間跨度回刷任務大量複製）等資訊。因此，當確定好待遷移的作業後，可以提煉出資料路徑規則（rules），並持久化到DataManager的規則庫中（規則庫會隨作業放置的變化而進行週期性更新）。

　　然後，針對不同的場景使用規則庫進行路徑抽取，下面以Hive表場景為例描述資料複製流程，如圖8所示， 首先收集Hive MetaStore的掛載表/分割槽相關的Event資訊至Kafka服務，然後透過實時Flink任務清洗出符合上述規則庫中規則的路徑，當檢測到熱點表的新分割槽生成後，交由資料複製服務（DRS）進行傳輸，生成異地機房副本，DRS本質上是一個DistCp作業的管理服務，在傳輸完成後由資料複製服務持久化副本資訊（包括路徑、版本、TTL等），以對副本資料進行全生命週期管理（刪除過期的跨機房副本，釋放儲存空間），目前B站線上有100+張Hive熱點表路徑設定了跨機房副本策略。　　

圖8 資料複製流程

　　上述複製流程採用自動發現主動複製的策略，可以快速捕獲並準備資料副本，經過統計在我們的生產中資料副本延遲的PT90可以控制在1min以內, PT99 在5min以內，可以有效滿足離線場景的業務需要；然而，上述自動發現主動複製的策略，可以有效解決增量資料副本的問題，但對於待遷移作業來說，可能還依賴較長一段時間的存量資料，針對該問題，我們除了採用提前啟動複製流程的方式準備存量資料外，還針對需要快速遷移的場景引入了基於Snapshot的資料遷移策略進行初始複製，因Snapshot為社群成熟技術不再綴述。

　　3、資料路由

　　上小節介紹的資料複製後雙機房均會存在某路徑的資料副本，當作業放置到IDC後如何定位到正確的資料是資料路由服務要解決的關鍵問題；

　　我們在《HDFS在B站的探索和實踐》中提到的基於HDFS Router的多掛載點實現的MergeFs的基礎上，實現了映象掛載點來實現資料路由功能。為方便描述，我們約定原始資料為主資料， 傳輸到異地機房的資料為副本資料（也稱為映象資料，該資料只允許讀取和刪除），並且約定映象掛載點中第一掛載點為主資料，之後的掛載點為副本資料（理論上可以擴充套件多個機房），為了在路由層面做到對使用者透明，我們在映象掛載點的處理邏輯中，增加了請求來源的IP位置感知功能，該功能能過獲取請求來源IP的位置資訊，判斷請求來源的DC並將請求路由到相應的DC的HDFS。如圖9示例所示，若資料請求來自DC1, 則Router將資料請求重定向到DC1的HDFS叢集，來自DC2則定向到DC2的HDFS叢集（圖中同種顏色線條標識請求路徑）。　　

圖9 基於Router的資料路由

　　為了降低跨機房頻寬的消耗，原則上，我們規定所有對資料的讀取操作，都只允許在本地機房（即Client所在機房）， 否則先複製到本地機房。但特殊情況下，如圖10所示，若Data Replication Service發生異常短時間無法修復或ns長時間異常時，則我們允許降級為跨機房限流讀（副本未ready情況, 超過一定的時間未在目標機房讀取到資料，則降級），限流部分在後面章節進行詳細介紹。　　

圖10 資料路由容錯

　　另外 ，由於歷史原因，在我們的生產中存在一種特殊的臨時庫，用於管理使用者SQL作業中的建立的短生命週期的臨時表（Temporary table，七天自動清理），該類臨時表表名不固定（例如一些ETL作業會在臨時表名上加上日期字尾)，也就造成了表類路徑不固定；針對該類路徑不固定的情況，無法使用上述映象掛載點進行管理，因此， 我們引入一種名叫IDC_FOLLOW的多掛載點，用於掛載多個機房中的臨時庫路徑；當讀寫臨時表時，會依據Client所在的DC選擇DC內HDFS NS掛載路徑來存取資料，從而解決臨時表跨機房流量的問題。

　　4、版本服務

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

圖11 資料版本工作流程

　　上文2.3節總體流程所描述的提交作業時，當獲取到作業預期的放置機房後，檢查依賴資料是否Ready的工作也包括版本檢查工作；當作業需要副本資料時，會透過資料傳輸服務檢查已傳輸的資料副本的版本與版本服務中訂閱的最新版本是否一致，若一致允許作業提交使用資料副本；否則，作業臨時阻塞，待傳輸服務更新副本資料後，則允許提交作業；若超過一定的時間未在目標機房讀取到資料，則降級為讀取主資料。

　　5、限流服務

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

圖12 令牌桶

　　令牌桶限流的核心思想為當進行某操作需要令牌時，需要從令牌桶中取出相應的令牌數，如果獲取到令牌則繼續操作，否則阻塞，用完之後不用放回。基於該思想我們設計了全域性中心限流服務，我們在HDFS DistributedFileSystem類基礎上，實現了具有讀寫限流功能的ThrottledDistributedFileSystem，當使用者使用該類去讀寫HDFS的檔案時，ThrottledDistributedFileSystem會根據RBF返回的LocatedBlock中的client IDC資訊和Block IDC資訊，判斷此次讀寫流量是否會跨機房，如果是會先嚐試向ThrottleService傳送申請跨機房頻寬請求（Token），申請到Token後，再進行後續的HDFS讀寫，如果申請的流量用完後，再向ThrottleService申請新的頻寬Token；除利用令牌桶固有的特性外，我們在令牌桶的基礎上實現了佇列優先順序和加權公平特性，限流服務的佇列優先順序和排程系統中的作業優先順序也做一一對映，來保障多租戶情況下重要服務可以優先獲取到Token；在穩定性方面，為了降低限流服務的壓力，我們設定每個Token代表相對較大的流量單元，來降低Token的獲取次數過多帶來的效能影響；為防止限流服務當機導致作業阻塞，我們增加了降級為本地固定頻寬的策略，同時隨著計算引擎持續接入限流服務，服務本身的穩定性和請求水位成為瓶頸（單機100K+ qps），我們透過水平擴充套件服務的方式增強了限流服務的效能。

　　6、跨機房流量分析

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

　　從上游讀取資料

　　作業執行過程中不同Executor/Task之間shuffle資料

　　寫資料到下游表

　　在B站多機房的場景中，因為採用單元化架構每機房均存在獨立Yarn的叢集，作業不會跨機房執行也就不存在跨機房Shuffle資料的情況，因此只需考慮讀寫HDFS檔案過程中產生的跨機房流量即可，而讀寫HDFS檔案產生的跨機房流量又可以分為計劃內流量和非計劃內流量兩大類：

　　計劃內流量：3.2 小節所述資料複製服務進行資料副本複製產生的流量，我們稱為計劃內流量， 該部分資料大機率會被多次使用。

　　非計劃內流量：即非資料複製服務產生的資料流量，單次(或多次)使用，主要來源有以下幾種可能。

　　計劃內的排程任務發生長時間跨度的歷史回刷，依賴的資料副本已過期銷燬

　　（漏遷/錯遷/新增等）放置位置不合理的週期性排程任務，可以透過最佳化作業放置消除

　　Adhoc查詢，突發流量， 單次（或多次）使用，臨時生產需求，無法預知需要的資料，無法預先進行處理

　　1）流量分析工具

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

　　引擎端: 在初始化HDFS Client時將作業JobId注入到DFSClient的ClientName中

　　DataNode: 在DataXceiver中埋點，從ClientName中解析出JobId，並按JobId和client ip網段合併讀寫流量，每30s輸出統計結果到流量日誌中

　　我們將每臺DN上的跨機房流量日誌進行實時收集，透過Flink彙總到ClickHouse上，然後聚合分析得出每個時間段的跨機房流量作業Top10，方便對跨機房流量進行治理（包括重新放置、緊急查殺、作業最佳化等）。　　

圖13 流量日誌收集鏈路

　　以下是我們跨機房流量分析的監控皮膚：　　

圖14 跨機房流量分析

　　2）Adhoc流量治理&最佳化

　　對於Adhoc型別的非計劃內流量，因為其隨機性，本文所述多機房體系中“資料複製-作業放置-資料路由”方式不適用；因此，我們採用一些其它的最佳化手段, 比如透過執行時SQL Scan掃描出依賴的資料大小、位置資訊，以節省多機房頻寬為最主要目標，結合叢集的實際負載情況，決定SQL排程哪個機房，比如：

　　訪問單張表：作業排程至資料所在機房。

　　訪問多張表

　　多表在同機房， 作業排程至資料所在機房。

　　多表在不同機房， 作業排程至資料量較大的表所在機房；較小表限流讀，或者阻塞通知複製服務複製。

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

　　 四、小結&展望

　　本文描述了B站離線多機房方案，該方案已平穩上線執行半年以上，遷移資料量近300PB，作業數佔叢集所有作業數的1/3。從實踐的結果來看該方案在很大程度上解決了跨機房網路頻寬不足、穩定性差與離線任務高效產出之間的矛盾。鑑於當前部分大資料關鍵元件的單元化程式，在抗網路連通性風險方面的能力還有較大的提升空間，後續我們將不斷地推進單元化程式，進一步降低網路問題的影響範圍，同時賦予部分高最佳化作業“雙活”的能力。

　　另外隨著新機房的持續擴容（老機房無法擴容，新增節點都會部署在新機房），我們也需要持續遷移更多作業到新機房，為了提高遷移的推進速度，需要儘量減少對上下游業務方的依賴（如：請求業務方協助對子業務進行劃分和梳理），因此，我們需要實現更智慧更自動化的待遷移資料和作業的自動劃分流程，進一步強化使用社群發現（Community Detection）演算法將DAG能自動劃分成多個內聚性較高的子集/社群，按照社群粒度進行遷移的工作。