本文作者：關濤（觀滔） 阿裡雲智能研究員 通用計算平台負責人 。
雙十一！=11.11
首先從雙11說起，雙11已經成為阿裡巴巴最大的單日促銷活動。雙11活動可能對于消費者而言隻是一天而已，但是對于阿裡巴巴和數百萬商家而言，卻是一個非常長線的工作。站在阿裡巴巴的角度來看雙11，其實無論是從業務線還是技術線，背後都存在着很多的思考。
從“人、貨、場”的角度看待雙11。首先，對于“人”而言，雙11需要回答什麼樣的消費者會看什麼樣的商品，以及每個人看到的商品是什麼樣子的。“貨”則是對于商家而言的，商家需要知道在這次雙11中，什麼樣的商品才能成為尖貨，以及需要提前多久準備多少貨才是最合适的。“場”的概念則更偏重于物流，比如需要提前将什麼貨物鋪在什麼地方才能夠達到最優的物流執行效率。在“人、貨、場”的背後存在兩件事情，他們才是電商競争力的關鍵。第一件事情就是供應鍊，如果能夠提前長周期地布局供應鍊，包括柔性、精細化的供應鍊，對于商家雙11大促和成本的降低将會産生非常大的作用。另外一件事情就是物流，前幾年的時候每到雙11物流就會爆倉，而最近幾年雖然成交量在不斷上漲，但是卻沒有再出現物流爆倉的情況。這背後的原因是阿裡巴巴聯合商家已經把消費者可能購買的商品布局到當地的本地倉庫中了。而所有的這些工作其實都是千萬級别商品和十億級的消費者的比對的問題。
而從技術的角度來看，在這背後其實就是大資料和AI能力的競争。雙11競争的是企業是否具有足夠多的資料、足夠強的算力、足夠好的算法，指導什麼樣的消費者在什麼樣的風格、類目以及價格區間上看到商品；對于商家而言，什麼樣的貨品才能夠成為尖貨，需要準備多少貨才是合适的；對于供應鍊而言，需要怎樣布局才能夠達成成本的最優，将貨物放在那個貨場才能夠距離消費者更近。這就是阿裡所提的A+B+C概念，這裡的A指的是Algorithm算法，B指的是Big Data大資料，C就是Computing計算，也就是說是否有足夠多的資料、足夠好的算法以及足夠便宜的計算力。是以，雙11的競争，從技術角度來看，就是一個公司的大資料和AI能力的競争。
下圖展示的雙11單日處理資料量的統計情況。從2015年到2019年，雙11單日資料處理量大約增長了70%左右，但是這樣的資料量不隻是在雙11當天才需要處理的，實際上從9月下旬到雙11當天，每一天都需要處理如此之多的資料。營運同學、分析同學以及商家就在這些資料裡面運作非常精細的算法，實作資料挖掘和資訊處理，通過這種方式助力雙11，這樣才能使得雙11當天實作最優的比對。
從技術的角度來看，雙11的成功有三個必要條件，即超大規模資料，低成本算力，以及資料上的快速疊代。最後這個條件要劃重點，如何使上萬名算法工程師和資料工程師在資料上實作快速疊代與前面資料以及算力同樣關鍵。海量資料上的快速疊代能力，本質是資料中台和資料開發平台的能力。
飛天大資料平台整體架構
如下圖所示的是從阿裡巴巴的角度看的整個飛天大資料平台的布局。從左側看起，阿裡巴巴主線數倉在MaxCompute上，目前在全球10個資料中心具有超過10萬台的規模，阿裡巴巴幾乎所有的資料都存儲在這裡面。MaxCompute支撐了一套自研的SQL引擎，同時也支援Spark等開源的計算能力。除了主線數倉和大資料計算之外，阿裡巴巴還有基于Flink的流計算系統。對于雲上業務則有基于Hadoop的完整的EMR解決方案提供給客戶。下圖中左邊的三部分叫做Basic Engine，也就是基礎計算引擎。右邊的引擎則包括PAI機器學習平台等，之是以左邊和右邊引擎割裂開，是因為兩者不屬于同等層面的關系，比如PAI的作業可以跑在MaxCompute上面也可以跑在Flink和EMR上面。除了PAI之外，阿裡巴巴大資料平台還包括Hologres、圖計算引擎Graph Compute以及Elasticsearch等。中間則是使用DataWorks貫穿起來的一體化大資料開發平台，包括大資料的開發以及資料Pipeline的建立也都整合在一個體系内。
接下來以 MaxCompute 為例為大家介紹阿裡經濟體大資料平台的建設與思考。
飛天平台發展曆程
從2002年開始，阿裡所有的資料都存儲在Oracle資料庫裡面。因為電商類業務最初都是記賬類的，那時候所有的資料都在Oracle裡面，當時阿裡擁有整個亞洲最大的Oracle叢集。而在後來發現Oracle無法支撐計算力的提升之後，阿裡巴巴就遷移到了Greenplum上。Greenplum采用分布式架構，最高能夠擴充到PB級别，但是不到一年的時間，Greenplum卻也無法滿足阿裡業務的發展了。是以，在2008年的時候，阿裡巴巴啟動了Hadoop叢集，這是阿裡最早在大資料方面的探索。2009年阿裡雲成立，建立了飛天品牌，當時考慮是否自建一套飛天系統，是以大資料引擎、分布式存儲和分布式排程一起作為三條主線一起啟動。在2010年，阿裡釋出了存儲計算的MaxCompute 1.0體系，對應的底盤叫做盤古存儲，中間使用伏羲排程，最早支援螞蟻金服的小微貸業務。在2013年，阿裡開始在規模和擴充性上做到一定的量級，大約5千台伺服器的級别，并在這個關鍵點上啟動了阿裡内部非常關鍵的項目“登月”，也就是将阿裡巴巴所有的資料都集中到一個體系上來。是以當時存在非常大的讨論就是到底使用Hadoop還是使用自研的盤古 + MaxCompute體系，最終決定了使用自研體系。從2013年到2015年實作了完整的“登月”過程。2015年，阿裡使用MaxCompute全面替換Hadoop，基于MaxCompute和DataWorks建構了完整的阿裡資料中台。在2017年的時候，阿裡巴巴認為需要進行引擎的疊代了，是以釋出了MaxCompute 2.0版本，将整個核心引擎實作了重構。當時在擴充性上，單叢集能夠達到萬台，全球有超過10個資料中心。最近，阿裡巴巴在MaxCompute方面所做的工作包括性能的提升，以及在中台的基礎之上演進自動中台或者說是自動數倉。
是以，飛天平台的發展曆程可以用幾句話來總結：第一，回首過去10年的發展，其實是阿裡巴巴對于資料規模和低成本算力的持續追求。第二，從開源到自研的演進，而如今又從自研向開源方向演進，比如Flink的發展。第三，從最早的資料庫走向資料倉庫，走向了資料中台，再走向自動數倉。第四，資料湖開始的時候選擇了Hadoop體系，而如今需要考慮如何将資料湖和資料倉庫很好地融合在一起。
企業級計算平台的核心問題
對于企業級計算平台而言，往往會遇到很多問題。第一個問題很簡單，但是也很常見，那就是需要可靠的資料交彙點，這裡的可靠就是100%萬無一失，并且需要保證資料存儲在機房裡面就不會丢失。第二個需要考慮高性能和低成本，這裡除了引擎本身的性能優化之外，還需要考慮存儲。第三個問題是如何做資料管理、共享與安全性。第四個問題則是企業級能力，比如如何做企業級自動化運維。第五個問題是需要支撐統一而豐富的運算能力，包括批處理、流處理、機器學習、圖計算、互動計算等能力。第六個問題是如何擁抱和融合各種生态，包括自主系統與生态的融合，資料湖和資料倉庫的融合等。第七個問題比較簡單，就是開發語言與效率。第八個問題就是彈性能力與擴充性。最後一個問題就是大資料系統如何更好地支撐AI能力，同時是否能夠利用AI能力優化大資料系統。
有關性能/效率(成本)優化
阿裡巴巴在性能和效率方面所面臨的挑戰可以總結為以下4點：
1.當規模超過1萬台時成本會持續增長，是以雲上大規模客戶對于成本的要求非常關鍵。
2.阿裡巴巴資料和計算力的增長非常迅速，從雙11來看，每年資料處理量的增速為70%左右，但是硬體投入不可能達到70%，這樣的成本是無法承受的，是以需要打破資料和計算量線性增長之間的關系。
3.目前，技術發展進入了開源軟體盲區，因為一般而言，開源軟體無法滿足超大規模的應用需要，是以需要解決這個問題。
4.之前發現了非常多的小叢集，但是他們之間的負載無法實作均衡，是以需要解決多叢集整體使用率不夠高的問題。
針對以上問題和挑戰，可以從計算、存儲以及資源方面進行優化，這裡重點分享資源優化中的一部分，那就是混部。這裡需要說明的是阿裡巴巴在考慮資源優化的時候，并不考慮單作業的成本和效率，而關心整個叢集的使用率的提升，将叢集使用率提高到60%以上是阿裡巴巴的強優化目标。
在雙11當天，流量剛開始的時候會出現一個尖峰，這個尖峰可能一年就出現一次。大概到2點多鐘的時候，流量會跌倒一個低谷，因為大家第一波搶購完成之後就睡覺了，等大家起床之後又會出現流量上升。那麼，阿裡巴巴需要準備多少台伺服器才能滿足需求呢？如果按照峰值準備，那麼将會有一半的伺服器總會處于空閑。如果按照均值進行規劃，就會發現在峰值時使用者無法送出請求，雙11的體驗就會很差。
針對于雙11的現狀，阿裡實作了兩套混合部署的體系，第一套體系叫做離線和線上混合部署，第二套體系叫做線上和離線混合部署。比如大資料與AI計算服務和線上計算在離線計算規模上各不相同，對于電商服務而言，白天可能比較空閑，而大資料服務則是一直都很繁忙，是以在白天的時候，可以将一些大資料的計算彈到電商的叢集上來，利用電商的部分CPU計算資源。而在雙11，大資料業務需要快速回退，這裡的回退指的不是幾台機器的回退，而是數萬台機器的回退，來支撐電商的流量洪峰。大資料和AI計算使用電商資源的混合部署是每天都會發生的，而電商使用大資料的資源則隻在每年的雙11和雙12發生，每次隻要兩個小時，但是這兩個小時的彈性卻會為阿裡巴巴節省數十億的成本。混部這件事情絕不是将一些Workload放在一起就能解決問題了，因為總會遇到一些問題，比如如何做資源規劃？這裡不僅是線上叢集的資源規劃問題，而是阿裡巴巴整個經濟體的資源規劃問題。因為不同負載對SLA要求不同，是以需要同時滿足隔離和共享之間的沖突？此外，大資料計算強依賴存儲，這種情況下需要推的就是存儲和計算分離的架構，而在存儲與計算分離的背後是極高的網絡帶寬挑戰。
資源使用率優化–離線與線上混布
如下圖所示的是資源排程模拟圖。Sigma是線上容器排程器，基本上所有的線上系統全部都實作了容器化，所有的容器系統都通過Sigma排程。伏羲是大資料和AI的排程器，主力計算力都通過伏羲進行排程。兩套排程器都看到一套資源的View，相當于能夠看到哪部分資源是空的，可以調入和調出。底層有兩套Agent，這兩套Agent負責在拿到資源之後向下做資源申請和管理。Sigma後續可能會延續到Kubernetes平台上，目前是使用Docker完成的。這裡并沒有試圖去合成一個中央排程器來實作所有的排程工作，而是以線上和離線分開來做排程的。從半動态資源排程政策起步，保持兩邊排程系統改動最小，進而實作快速升降級和疊代。
在思考層面，有幾個關鍵點，其中一個是存儲和計算分離，特别是想要利用大規模電商資源實作彈性的時候，一定要做存儲和計算分離。是以，在阿裡巴巴内部有一個項目叫做“天下無盤”，也就是說所有的計算都可以和存儲分開，而不依賴于本地存儲。因為會涉及到數十萬台機器的排程，是以需要有統一高效的部署運維平台，一定需要一鍵部署，自動檢測與復原，高效版本分發等能力。在資源管理層，因為不同的應用具有不同的SLA要求，是以将資源分為了S10-S20-S30三個等級。隔離能力絕對不僅僅是CPU的隔離，這裡面包括IO、網絡、記憶體等各個方面的隔離。對于大量的改動而言，阿裡巴巴實作了定制版本的核心AliKernel，将這些改動全部放在AliKernel裡面。以上這些關鍵點實作之後，基本上就能夠實作比較完善的電商混部。
有關資料倉庫與資料湖
其實Hadoop本身就是一個資料湖體系，其擁有一套統一的存儲架構，上面運作多套引擎。Hadoop基本滿足資料湖所有的定義，比如HDFS存儲的資料幾乎不要求是完全模組化的，可以不模組化，并且能夠是Schema-On-Read的，可以在讀取到時候動态解析Schema。因為是開放架構，是以可以運作所有引擎，但是從另外一個層面上講解，因為存儲是開放的，是以難以做全面優化。在成本方面，對于資料湖而言，比較容易啟動。其難點在于維護成本比較高，比如最經典的小檔案問題。對于資料使用而言，往往難以實作很高的品質以及可維護性。從另外一個角度來看，包括阿裡在内的很多企業都在做資料倉庫，之是以做這件事情是因為在資料倉庫中，資料進來都是Fully modelled的，那麼表和資料都是事先定義好的。正因為是Fully modelled的，是以通常隻存儲結構化和非結構化的資料，而這樣會造成資料存儲靈活性的問題。而因為采用了一體的概念，那麼并不是所有引擎都适合運作在這套系統裡面。但是一體化架構更容易實作優化，存儲更容易為上層計算進行優化，這裡的成本就是資料倉庫可能不好建設，因為對于資料寫入以及維護等要求較高。但是一旦資料倉庫做成，就更容易實作Fully managed。對于資料使用而言，往往能夠實作較高的資料品質，并且易于使用。
那麼将核心資料全部放在資料倉庫上是否可以行，顯然是可行的，并且包括阿裡巴巴在内的很多企業也都是這麼做的。如果隻用資料湖來做，是否可行，答案也是可行的，其實很多公司也是這麼做的。那麼能否将兩者結合起來呢？也是可行的。業界也有很多嘗試，并且是雙向的，資料湖架構能夠看到資料倉庫的優勢，是以向着資料倉庫演進比如Hadoop + HMS，可以認為是增強版HMS的Netflix Iceberg以及Spark DeltaLake。而資料倉庫系統也能夠看到資料湖的靈活性，也在向着資料湖發展，比如Redshift和Snowflake，是以演進是雙向的。
有關資料倉庫與資料湖–阿裡大資料平台的演進
阿裡巴巴在2013年到2015年的時候看到了Hadoop體系的一些問題，比如擴充性、性能、安全性、穩定性以及代碼可控性。是以，阿裡做了Hadoop到MaxCompute的遷移，相當于對于資料湖場景做了主線數倉，那個時候就已經開始有能力建構阿裡的資料中台，開始建構資料模組化、資料血緣、資料治理以及标簽體系等。
阿裡巴巴建構完資料中台之後，在2016年到2018年的時候對于主線的資料倉庫平台中做了兩個項目，分别是聯合計算平台和邏輯資料湖。聯合計算平台使得資料能支援多種引擎，在MaxCompute平台上封裝了“丘比特”，将資料的資源層封裝成了Yarn和Kubernetes平台，将資料存儲層抽象了一套IO接口，将中繼資料系統抽象出來一套系統，可以對接Spark、Flink等開源引擎。丘比特平台所能實作的是Spark和Flink不需要修改代碼，隻需要替換一些Jar包就能夠在MaxCompute平台上使用資源跑資料，相當于在數倉的基礎之上向上擴充了對于引擎的支援。另外一件事情就是做了外表能力，所謂邏輯資料湖則實作了與其他存儲打通，不是把資料彙聚，因為計算下推比資料上移更高效。
在2019年，阿裡巴巴看到了實作邏輯資料湖潛在的問題，這對于使用者而言是非常困難的，特别是具有海量資料的時候。另外一點，雲上客戶給阿裡的回報是手裡已經有了200台機器的Hadoop體系了，并且希望使用阿裡的數倉架構和中台架構提升業務能力，如何實作兩條線和諧發展呢？是以，阿裡巴巴正在着手實作所謂的“湖倉一體”，也就是将資料倉庫和資料湖融合在一起。除了打通資料湖和資料倉庫的網絡之外，阿裡巴巴還實作了中繼資料的打通，當希望對兩邊的資料做Join計算的時候不需要建立外表，目前這套架構正在試用中。
更多阿裡巴巴大資料計算技術和産品資訊，可點選連結加入 MaxCompute開發者社群2群
https://h5.dingtalk.com/invite-page/index.html?bizSource=____source____&corpId=dingb682fb31ec15e09f35c2f4657eb6378f&inviterUid=E3F28CD2308408A8&encodeDeptId=0054DC2B53AFE745或掃碼加入