本文根據井誠老師于第九屆中國數據庫技術大會(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、大數據、機器學習、區塊鏈、數據可視化等領域的前瞻性熱點話題與技術。

原文發布時間為：2018-06-4

本文作者：井誠

本文來自云棲社區合作伙伴“IT168”，了解相關信息可以關注“IT168”。

總結

以上是生活随笔為你收集整理的阿里专家分享：企业级大数据轻量云实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。