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

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%業務增長。
訪問MaxCompute官網瞭解更多詳情

加入社群釘釘群，交流大資料技術