天天看點

首次公開!單日600PB的計算力--阿裡巴巴EB級大資料平台的進擊挑戰叢集遷移跨叢集排程新機型的新問題透明的檔案合并平台性能提升總結

作者:阿裡巴巴計算平台 進階技術專家 迎輝 MaxCompute

作為阿裡巴巴的主力計算平台,在2018年的雙11中,再次不負衆望,經受住了雙11期間海量資料和高并發量的考驗。為集團的各條業務線提供了強勁的計算力,不愧是為阿裡巴巴曆年雙11輸送超級計算力的核武器。

本文為大家介紹,

基于多叢集部署的幾萬台伺服器,如何為集團急劇增長的業務提供護航和保障。
首次公開!單日600PB的計算力--阿裡巴巴EB級大資料平台的進擊挑戰叢集遷移跨叢集排程新機型的新問題透明的檔案合并平台性能提升總結

挑戰

每年的雙11之前,也是MaxCompute各種乾坤大挪移落定的時候,因為雙11就是各種大折騰項目的自然deadline。在今年雙11之前,一路向北遷移和在離線混部項目,将杭州叢集除螞蟻外整體遷移到張北,涉及了絕大部分的業務project、資料存儲和計算任務,為今年雙十一大資料計算服務的保障帶來了挑戰。

體量

現在MaxCompute包括在離線混部叢集在内有幾萬台伺服器,資料總存儲量在EB級,日均運作近幾百萬量級的作業,而每天所有作業處理的資料總量也在幾百PB。叢集分布三個地理區域,之間由長傳鍊路相連接配接,由于集團資料業務固有的普遍聯系特性,各個叢集之間有着切不斷的大量資料依賴,以及嚴重的帶寬依賴。

首次公開!單日600PB的計算力--阿裡巴巴EB級大資料平台的進擊挑戰叢集遷移跨叢集排程新機型的新問題透明的檔案合并平台性能提升總結

成本

大量的伺服器就是大量的成本,降低成本就要充分利用每個叢集的計算存儲能力,提高資源使用率。同時,不同業務有着不同的特征,有的存儲多計算少,有的計算多存儲少,有的大規模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+,世界領先。

首次公開!單日600PB的計算力--阿裡巴巴EB級大資料平台的進擊挑戰叢集遷移跨叢集排程新機型的新問題透明的檔案合并平台性能提升總結

總結

MaxCompute 在2018雙十一又一次平滑通過了大促的考驗,同時我們也看到, 平台需要不斷提升分布式計算下多叢集的綜合能力,不斷提升計算力,保障大規模計算下的穩定性,來支撐起持續高速增長的業務。 通過持續的引擎能力優化、開發架構建設、智能數倉建設等次元,MaxCompute 向智能化的、開放的、生态平台發展,來支撐起下一個100%業務增長。

通路MaxCompute官網了解更多詳情

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

首次公開!單日600PB的計算力--阿裡巴巴EB級大資料平台的進擊挑戰叢集遷移跨叢集排程新機型的新問題透明的檔案合并平台性能提升總結

繼續閱讀