摘要：?每年的雙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%業務增長。