首次公開！單日600PB的計算力--阿里巴巴EB級大數據平臺的進擊

摘要： 每一年的雙11以前，也是MaxCompute各類乾坤大挪移落定的時候，由於雙11就是各類大折騰項目的天然deadline。在今年雙11以前，一路向北遷移和在離線混部項目，將杭州集羣除螞蟻外總體遷移到張北，涉及了絕大部分的業務project、數據存儲和計算任務，爲今年雙十一大數據計算服務的保障帶來了挑戰。

做者：阿里巴巴計算平臺 高級技術專家 迎輝

MaxCompute做爲阿里巴巴的主力計算平臺，在2018年的雙11中，再次不負衆望，經受住了雙11期間海量數據和高併發量的考驗。爲集團的各條業務線提供了強勁的計算力，不愧是爲阿里巴巴歷年雙11輸送超級計算力的核武器。

本文爲你們介紹，MaxCompute基於多集羣部署的幾萬臺服務器，如何爲集團急劇增加的業務提供護航和保障。

挑戰
每一年的雙11以前，也是MaxCompute各類乾坤大挪移落定的時候，由於雙11就是各類大折騰項目的天然deadline。在今年雙11以前，一路向北遷移和在離線混部項目，將杭州集羣除螞蟻外總體遷移到張北，涉及了絕大部分的業務project、數據存儲和計算任務，爲今年雙十一大數據計算服務的保障帶來了挑戰。

體量

如今MaxCompute包括在離線混部集羣在內有幾萬臺服務器，數據總存儲量在EB級，日均運行近幾百萬量級的做業，而天天全部做業處理的數據總量也在幾百PB。集羣分佈三個地理區域，之間由長傳鏈路相鏈接，因爲集團數據業務固有的廣泛聯繫特性，各個集羣之間有着切不斷的大量數據依賴，以及嚴重的帶寬依賴。

成本

大量的服務器就是大量的成本，下降成本就要充分利用每一個集羣的計算存儲能力，提升資源利用率。同時，不一樣業務有着不一樣的特徵，有的存儲多計算少，有的計算多存儲少，有的大規模ETL I/O繁忙，有的機器學習科學計算CPU密集。

怎樣充分利用每一個集羣的能力，提高CPU、內存、IO、存儲各方面的利用率，同時均衡各集羣負載，兼顧站點之間長傳帶寬的壓力，在超高資源利用率下保障運行穩定，還要支持杭州總體搬遷這樣量級的變動，這些挑戰對於MaxCompute並非應對雙11大促的一次重大戰役，而是MaxCompute天天的平常。

如何應對這些挑戰，下面將從各個角度爲你們介紹 MaxCompute 所作的一些列工做。

集羣遷移
今年，一路向北遷移和在離線混部項目，將杭州集羣遷移到張北，同時也涉及了MaxCompute控制集羣和計算集羣的遷移。 物理資源上的大騰挪，也給MaxCompute的服務保障帶來了一些列問題和挑戰。

透明的Project集羣遷移

可能不少同窗之前遇到過所在Project遷移集羣時做業失敗，出現 AllDenied 報錯。以前在把Project遷到另外一個集羣的時候，會對用戶有影響，操做前須要先作通知，對用戶對運維同窗都很困擾。
今年MaxCompute實現了遷移Project遷移過程當中做業運行和提交都正常不受影響，作到了對用戶透明。

輕量化遷移

集羣之間由於業務的差別，會出現計算和存儲配比不均衡的狀況，而正常的遷移須要目標集羣的存儲和計算空間都知足需求才能作，這樣就會遇到有的集羣存儲水位比較高，但計算能力還沒用滿，卻沒辦法遷移大的Project過去的狀況。

今年上線的輕量化遷移機制，能夠實現只遷移計算和部分熱數據到新的集羣，而老數據則留在原集羣，可以達到既均衡了計算資源，又不會有太多跨集羣讀寫的效果。

搬走動不了的OTS

MaxCompute 使用OTS存儲系統的各類核心元數據，因此一旦OTS異常，MaxCompute的整個服務都會受到影響。更嚴重的是，MaxCompute服務對OTS的依賴長期沒有主備熱切換的支持，使得OTS集羣變成了MaxCompute惟一動不了的一個點。

今年做爲一路向北遷移規劃的一部分，咱們仔細擬定和驗證了OTS熱切換方案，梳理了控制服務和OTS集羣的依賴，目標不可是要作OTS的主備熱切換，並且是從杭州直接切到張北。

儘管經歷了一次彈內切換的失敗，通過進一步優化和演練，最終咱們把切換時間從預約的分鐘級別切換縮短到了若干秒級的切換，並在公共雲線上環境也成功實施，實際切換過程無異常反饋，作到了用戶無感知。

今後MaxCompute服務裏最關鍵的一個點有了無損熱切換的能力，大大下降了總體服務的全局性風險。

跨集羣調度
多樣的全局做業調度機制

集羣之間由於做業類型或業務特徵等因素，可能會有各類計算資源使用的不充分，好比：業務的全天資源高峯時段及持續時間不一樣；申請大塊資源的任務類型所在集羣有空隙能夠超賣小做業填充；甚至有些特殊狀況會有臨時的資源借用需求。

爲此MaxCompute提供了一些全局做業調度機制，能夠把指定的一批做業調度到指定的集羣運行，或者在當前集羣資源繁忙的時候，系統自動去看若是其它集羣資源有空閒，就調度到空閒集羣運行。

除了均衡資源利用率，這些機制也提供了人工調控的靈活性，而且還在進行與數據排布相結合的調度機制開發，以根據集羣實時的狀態進行調度。

拓撲感知、數據驅動的橋頭堡

做業要訪問其它集羣的表數據有兩個選擇，一個是從本集羣直接讀遠程集羣（直讀），一個是先把遠程的數據複製一份到本集羣（等複製）。這兩種方式各有優缺點及其適用的場景。 同時，集羣之間的網絡拓撲（是異地長傳仍是同城同核心）也會影響直讀和等複製策略的選擇。異地長傳帶寬成本高，容量小，同城的網絡帶寬則相對容量較大，但在大數據的流量下，高峯期都是同樣的可能擁堵，因此須要既利用同城帶寬優點，又不能把瓶頸轉移到同城，須要全局的策略調配。

由於天天業務都在變化，數據的依賴關係也在變化，咱們利用對歷史任務的分析數據持續優化和更新複製策略，在每一個區域選擇橋頭堡集羣接收長傳的複製，而後在區域內實施鏈式複製或者近距離直讀。 經過橋頭堡2.0項目，咱們實現了將2個地域間的數據複製流量下降了30%+。

新機型的新問題
一朝天子一朝臣，一代機型一代瓶頸。

如今MaxCompute的集羣規模仍然是萬臺標準，但今天的萬臺已經不是幾年前的萬臺，單機的CPU核數從曾經的24核、32核，再到新集羣的96核，一臺頂過去3臺。但無論單機多少核，在MaxCompute的集羣裏，天天CPU老是能持續幾個小時滿負荷運行，整體日均CPU利用率達到65%。

不變的除了CPU利用率，還有磁盤數，咱們的數據IO能力仍然是由不變的單機機械硬盤提供。雖然硬盤充起了氦氣，單盤容量是之前的3倍，但單盤的IOPS能力卻相差無幾，DiskUtil就變成了很是大的瓶頸。

通過一系列的優化措施，今年大量96核集羣的上線沒有了去年面對64核時的狼狽不堪，把DiskUtil維持在了比較可控的水平。

透明的文件合併
跑做業時遇到報錯FILE_NOT_FOUND重跑又能過，或者掃描長時間分區範圍的做業反覆重跑也無法跑過，這個狀況相信不少人都遇到過。

爲了緩解集羣文件數的壓力，平臺的後臺自動文件合併停一兩天都有觸頂的危險，但長期以來這個動做爲了保證數據一致性和效率，都無法避免打斷正在讀的做業，只能選擇只合並比較冷的分區，但一方面文件數的壓力迫使把冷的斷定閾值從一個月壓縮到兩週到更短，另外一方面總會有很多做業仍然會去讀早些時間的分區而被合併操做打斷。

今年平臺實現了新的合併機制，會給已經在運行的做業留必定的時間仍能讀合併以前的文件，從而再也不受影響，能夠很大程度上解決這個頑固問題。

目前新的機制在公共雲取得了很好的效果，集團內也在灰度試運行中。

平臺性能提高
做爲一個計算平臺，MaxCompute以計算力爲核心指標，經過不斷的提高計算力，支撐起集團飛速的業務增加。 對比2017雙十一，今年雙十一當天MaxCompute做業數幾乎有了成倍的增加。 過去一年中，MaxCompute經過在NewSQL+富結構化+聯合計算平臺+AliORC多個方向上發力，持續構建高可用、高性能、高自適性的大數據平臺，提高平臺計算力。 9月雲棲大會發布中，TPC-BB的測評結果在10TB規模上超越開源系統3倍以上；100TB規模評分從去年的7800+提高到18000+，世界領先。

總結MaxCompute 在2018雙十一又一次平滑經過了大促的考驗，同時咱們也看到， 平臺須要不斷提高分佈式計算下多集羣的綜合能力，不斷提高計算力，保障大規模計算下的穩定性，來支撐起持續高速增加的業務。 經過持續的引擎能力優化、開發框架建設、智能數倉建設等維度，MaxCompute 向智能化的、開放的、生態平臺發展，來支撐起下一個100%業務增加。