阿里專家分享：企業級大資料輕量雲實踐

　　本文根據井誠老師於第九屆中國資料庫技術大會(DTCC 2018)的現場演講《把大象裝進冰箱 企業級大資料輕量雲的實踐》內容整理而成。

　　講師介紹：

　　井誠，阿里巴巴技術專家，2004年畢業於哈爾濱工業大學，有著多年的商業IT軟體系統與網際網路行業的研發、測試與交付經驗。目前服務於阿里集團計算平臺事業部，主要從事大資料雲服務工程化方面的工作。

　　分享大綱

　　1. 源起：阿里的象群們;

　　2. 輕量化過程中遇到的挑戰;

　　3. 解決之道：切割象群;

　　4. 未來之路

　　一、阿里的象群們

　　首先給大家簡要介紹一下阿里的象群，阿里的大資料服務比較多樣、豐富，第一塊就是我們的大資料計算服務MaxCompute，MaxCompute是用來做離線計算和處理的，第二塊就是一個分析型的資料庫，大概就是一個online或者MPP的資料庫，然後第三塊也是業內比較常見的流計算引擎，第四塊就是資料通道服務DataHub，第五塊就是阿里最著名的資料中臺DataWorks。阿里的象群主要由這五塊服務組成。

　　以下是這些服務在功能特性方面分別對應的開源界的一些生態的小夥伴，有些對比不一定恰當。最後一塊DataWorks比較特殊，它是一個資料中臺，這個概念是阿里率先提出的。基於阿里自身這麼多年業務積累了非常豐富的海量資料，然後如何把這個資料利用好，阿里可能是——我們誇大一點說——業內甚至全球首先遇到相應挑戰的，所以在資料中臺建設上我認為開源社群並沒有一個很好的對比的場景。

　　我重點介紹一下MaxCompute，MaxCompute的發展也很有意思。其實我遇到很多朋友在問我，MaxCompute是不是基於Hadoop去改的或者開發的?其實不是。2010年到2012年的時候，阿里的資料棧已經非常大了，那時還用的是Hadoop，在叢集規模變得非常大、阿里打算把BU之間的資料完全打通的背景下，發現當時的Hadoop確實有很多各種各樣的問題，主要就是效能問題，然後在內部經過了一個很激烈的、長時間的、甚至是痛苦的決策，最後決定自己做一套東西，所以從2010年左右就徹底放棄了Hadoop這條路，完全從頭自己開發了一套系統，當年是叫ODPS。從2010年開始就一直沿著自研這條路去走，發展到2013年的時候叢集規模超過了5千臺，發展到今天MaxCompute已經完全在阿里內部所有的事業部，包括螞蟻金服、高德完全落了地。我來自的這個部門就是在做MaxCompute，我們服務的就是整個集團的大資料引擎部分。目前我們的單叢集已經過萬了，去年雙十一當日就處理了320PB的資料，非常驚人。另外，在公有云和專有云上也做了很多輸出。

　　AnalyticDB是阿里巴巴自主研發的能夠滿足海量資料實時多維分析的大資料產品。分析型資料庫主要是應用的一個場合是在海量資料下去做CRM的報表分析，阿里也是一個資料公司，很看重商業資料探勘，所以AnalyticDB在海量資料下做頻繁的互動和查詢的BI報表有很好的效果，其響應的速度是非常快的，基本都是秒級的響應。在去年雙十一和雙十二兩天，整個集團是批量匯入了1萬億條的資料，然後實時落盤Optimize的資料是1千億條。我們集團內部落地的叢集的規模也是突破了1千臺，效能非常高，那這兩個是我們當前大資料比較核心的地方。

　　二、遇到的挑戰

　　2016年的時候國內正好是私有云或者說大資料雲端計算風起雲湧的一年，市場上湧現了很多輕量化的大資料雲平臺。對阿里而言，阿里從來是大規模到超大規模，單叢集規模過萬;從單機房到多region的方向發展;擁有日益強大的基礎與運維服務;精通阿里大資料運維技術的SRE團隊;7*24小時高效處理平臺問題。此時私有云和專有云客戶的挑戰在於：只有小至10臺左右的規模訴求;缺乏完善的底層基礎設施;對阿里大資料開發/運維技術都不甚瞭解;能最終解決平臺問題的人，難以快速訪問平臺。

　　所以到2016年想做這個事兒的時候就發現，阿里手上並沒有一個很確定的解決方案去解決它。大家都是基於輕量級的，但是阿里當時是反過來的，我們有超大規模的工程能力，因此怎麼把它布小就變成了一個挑戰。所以我們當時遇到的挑戰就是，怎麼去把剛才講到的這些大象，一塊一塊割小，割到一個10臺左右的規模然後去推給客戶。

　　我們大資料輕量雲的產品理念就是，以私用雲的形態，將MaxCompute、AnalyticDB與DataWorks為代表的阿里大資料計算能力，用盡可能低的門檻輸出給客戶，普惠各行各業。、所以當時的產品矩陣是，底層基於飛天分散式作業系統Apsara，然後去把大資料引擎，剛才講的MaxCompute、AnalyticDB都輸出去。再上面就是阿里常用的一些大資料應用，比如說DataV還有BI報表。產品架構就是這樣。

　　關於期望達到的技術目標，我們總體列了五點。第一點肯定是要輕量化的，將公有云上20+的管控伺服器規模，壓縮至7臺以內;第二是從商業角度考慮，1臺伺服器損壞不停服，2臺伺服器損壞不丟資料，提高可用性;第三個目標是可升級性，有能力升級至專有云企業版，提供全量雲端計算服務能力;第四是可擴充套件，易於擴充套件增加新產品;最後一塊就是易運維，對於新接觸阿里大資料技術體系的人，能快速掌握基本運維操作。

　　三、解決之道

　　我現在來講一下我們當時是怎麼做這件事情的。首先是飛天，飛天是阿里雲產品底層的分散式作業系統，由盤古/伏羲/女媧三大部分組成。這個盤古是一個分散式的穩健作業系統，有很強的容錯性，很高的效能;女媧是一個協調服務，有點類似社群的ZK;伏羲就是資源管理和任務排程。當時在公有云和集團內部，我們每一個叢集的規模是總共13臺伺服器，盤古是5臺伺服器，女媧是5臺，伏羲是3臺。因此在管控上，只是一個MaxCompute就有13臺伺服器。

　　在解決方案上，我們當時考慮用一個最流行的方式，就是把它Docker化，第一步Docker化我們把它擠到虛擬機器上去做。還有一點就是考慮減少它的節點，因為5+5+3是非常過量的一個配置，所以我們經過一些容量的規劃和測評，最後把它全部Docker化，用3+2+3的模式部署在了4臺物理機上。所以在這一點上我們極大的把飛天管控壓下去了，包括MaxCompute和AnalyticDB都是基於飛天的，如果不壓縮的話這兩者合起來就是26臺物理機，但是壓完以後在4臺物理機上就可以搞定。

　　第二塊是對運維管控服務做了一個極大的精簡。天基是阿里雲的核心基礎運維繫統，管理雲平臺中的硬體生命週期與各類靜態資源。在我們的雲體系中，天基上面管控了60多個服務，但是這個解決方案在我們輕量的方案中是不成立的。我們在輕量雲裡只有三個產品，AnalyticDB、MaxCompute和DataWorks。當時我們梳理了一遍這個整體的管控服務，還有他們互相之間的依賴關係，然後從裡邊認真篩選了一遍，把所有沒有必要的依賴全部都砍掉了，同時也做了一些改造，最終從60多個服務壓到了10個服務。然後天基的迷你版原來在公有云還有專有云中可能要10臺伺服器，壓縮完以後就減少到了3臺左右，在整體的硬體成本和規模上都節省了一倍以上。

　　還有一個就是比較常見的套路就是服務混布，這個概念其實在業內不是特別新鮮，就是我們把計算密集型，還有網路密集型，還有沒有資源競爭關係的服務儘可能的布到一個伺服器上。

　　功能調整。在輕量的條件下，一些原有的功能失去了意義，因為我們只有12臺。所以這倒是一件乾得很痛快的事情，就是看哪些服務沒有用的就把他全部砍掉，剛才講到的同城同災，多region，還有我們之前整個機群管理，因為有很多內部管理有很多變更的流程，還有很多智慧監控分析我們都砍掉了。智慧監控分析這一塊我說一下，大家知道這個智慧往往都是基於資料的，如果你的叢集量非常大的時候，能產生大量資料的時候，這個智慧是有意義的，但是當機群只有10臺或者20臺的時候，這個時候去搞基於資料化的智慧運維也是沒有太大的價值。所以當時也是梳理了一番，把很多的業務都砍掉了。

　　輕量化的中介軟體服務。SLB當時物理機是6臺，RDS當時也是基於物理機去部署的，最少要兩臺伺服器。在輕量的場景中，我們去找miniLVS或者miniRDS這種非常小巧的服務去替代原來龐大的物理機，在這個場景下我們節省了十多臺伺服器。

　　還有一點，白屏化運維。可能客戶的運維的同學跟阿里運維的同學背景其實也不太一樣，一個是技術體系的差異，還有一些習慣的差異。我們在做運維繫統的時候經常會給很多很花哨的一些圖表、效能趨勢、效能變化，但是這些圖表或者說有一些縮略語，指標的變化是什麼含義，其實在解讀上是很偏經驗化的。當時考慮到這一點，我們緊急的梳理了一遍在運維上的有價值的指標，把太技術化的這種英文縮略語全部轉換成一個更容易懂的術語。在系統故障檢測上我們除了常見的自檢排查、指標分析、日誌分析、伺服器狀態監控之外，我們還利用這些資料去做故障發現，通過這些比較有規律的特徵和指標，往往能夠比較及時準確地發現一些常見的問題。

　　最後一塊是比較重要的，就是全鏈路效能壓測與穩定性測試。因為這個雲平臺上面有比較核心的兩個元件，一個是MaxCompute，一個是AnalyticDB。我們單獨去測它其實不會發現太多問題，很多時候是結合業務場景，在做全鏈路的時候發現一些瓶頸。包括我前面說到的裁減、刪減，那麼裁到什麼比例是一個比較合理的比例，是需要經過一些驗證的。我們根據客戶的一些典型應用，比如離線計算的資料量、作業值、任務數，還有就是在AnalyticDB的資料儲存等等，最終經過多輪的測試我們把剛才提到的優化點差不多都找到了一個最優的中間數值，最後實現了我們的原始目標。

　　還有其他的切割技術。如合理合併中介軟體資源，適度降低監控輪詢頻率，合併優化有重複的監控方案，調整日誌rotate策略等等。

　　目前我們前三個目標都順利得到了實現，第四塊我們初步完成了運維操作的白屏化、傻瓜化，但我們的目標還沒有完全的實現，因為運維目前更多還是偏經驗去做的，我們為了彌補，也寫了很多運維指南，然後在前端介面上也補充了很多操作指導，希望能夠讓使用者快速掌握一些簡單的問題處理方式。

　　四、未來之路

　　最近我們也有一些思考，這個思考更多的是偏這種業務方面的。因為我們當前講到的東西都是一個雲平臺的，但其實前方傳來更多的需求是偏應用平臺的，應用平臺跟我們做的這個平臺比較大的一個差別，如下：

　　在這種場景下雲平臺這個底座——也就是天基這個底座，很多的能力和威力在應用平臺上其實是很難發揮出來的，所以在這種應用平臺場景下，我們當前考慮的就是要基於天基再進一步去做一些優化和刪減，將它與應用平臺富餘出來的功能接著往下砍。

　　還有一塊是可運維性。因為阿里集團內部很多時候運維工程師考慮的是怎麼高效去處理一些問題，但是在應用平臺上產生了一些特性可能會導致可運維性沒有那麼高，比方說有個東西壞了，他不需要現場修，也許拿回去返廠修了，沒有那麼強的當場解決的特性需求，所以在這種場景下，可能我們整個運維繫統的一些設計目標和理念都會發生變化，對應的技術也會跟著去調整。

　　以上就是我的分享。在(把大象塞進冰箱的)這個過程中，我們從初始的一個很大的規模逐漸的裁到了很小，大概裁減到了15臺伺服器。

　　結尾：

　　第九屆中國資料庫大會以“數領先機?智贏未來”為主題，設定2大主會場及22個技術專場，邀請來自國內外網際網路、金融、教育等行業百餘位技術專家，共同探討Oracle、MySQL、NoSQL、大資料、機器學習、區塊鏈、資料視覺化等領域的前瞻性熱點話題與技術。

　　（更多精彩報導，請戳：http://www.it168.com/redian/dtcc2018/）

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31473948/viewspace-2155616/，如需轉載，請註明出處，否則將追究法律責任。