阿里巴巴大資料技術關鍵進展及展望
摘要:2019杭州雲棲大會大資料技術專場,由阿里雲通用計算平臺負責人關濤帶來以 “阿里巴巴大資料技術關鍵進展及展望” 為主題的演講。本文首先講解了從阿里巴巴的角度看待大資料領域的客戶價值遷移,概覽了核心技術的發展點,最後針對如何構建智慧化大資料平臺的相關工作進行了介紹,從引擎最佳化到 “自動駕駛”,並列舉了幾個典型案例。
以下為精彩影片內容整理:
一、大資料領域的客戶價值遷移
大資料10年,從“嚐鮮”到“普惠”
大資料技術已經存在了20年的歷程,並且阿里的飛天平臺也有了10年的歷程。上圖是Gartner非常有名的評測機構,在Emerging Technologies中展示了Hype Cycle。Emerging Technologies是指其中所有的技術都視為新興技術。橫軸分為五個部分,從Trigger開始,到達最熱潮,然後到了冷靜期,再繼續向前發展。不同的顏色表示在所指的幾年之後相應的技術會變得成熟。在2014年,Big Data已經到達了尖峰期的末端狀態。在2015年,Big Data就不在上圖中了,關於Big Data應該放在哪裡的問題,許多人都參與了討論,最終Gartner 的分析員 Betsy Burton給出了總結性的一句話:“Big Data..has become prevalent in my lives”,其中的含義是指大資料已經不是一個特定的技術,它是一個普惠的技術領域。阿里巴巴認為大概在2014年大資料會從嚐鮮期到普惠期,並且帶來了非常多的價值變化。
大資料領域Value Proposition的遷移
上圖所示為嚐鮮期到普惠期的對比。嚐鮮期更注重的是快速上手。其次是靈活性,無論是平臺、配套的東西還是工具鏈都不是特別成熟,怎樣更快的做一些調節和修改可以滿足需求是很重要的。另外還需要能達到一些目標,不需要特別全面,甚至不需要很穩定,只要能進行試對和試錯就可以。普惠期的特點與嚐鮮期的特點幾乎是不相同的,甚至是對立的。從普惠期開始,成本和效能變得很關鍵,其中特別關鍵的是“成本”,因為透過調研得出使用者對“成本”是很關注的,使用者的關注不僅僅是對大資料處理上所付得的錢數,更多的關注是資料在海量的增長的情況下,怎樣保證成本在可控的範圍之內。當進入到普惠期,進行大規模應用時,企業級服務能力就變的很關鍵。例如,阿里的大資料平臺每天都會產生支付寶的商戶對賬單,商戶和商戶之間、商戶和上下游之間、及商戶和銀行之間結算的系統要求都萬無一失。當從嚐鮮期進入到普惠期之後,應該有一個相對豐富且完整的工具鏈和生態體系,這就需要生態體系和工具鏈能融合在一起,才能實現整個效能。
從阿里巴巴的角度看 – 飛天平臺發展歷程
MaxComputer是飛天底座平臺的系統,同時支撐了飛天絕大多數的資料儲存和計算力的需求。從阿里的角度來看,在2002年,Oracle是做數倉型的資料建設,包括算賬和inside。在2006年,是亞洲最大的Oracle Rack。在2008年和2009年,分別啟動了Hadoop和飛天的體系,後面是大家熟知的登月系統。在2015年,登月系統完成,所有的資料彙集到一起,同時建立了資料的底座作為統一的儲存系統、一套中間的統一運算系統以及資料中臺,整個系統以中臺體系為核心,成為阿里巴巴內部的大資料一體化。在2016年,啟動了MaxComputer 2.0專案,幾乎替換了從2010年到2015年的整體,同時開始給國內雲端計算的客戶提供服務。在2019年,可以轉型到MaxComputer 3.0,除了關注效能和成本之外,隨著資料量超大規模的增長,以及資料領域的最佳化幾乎已經超出了人類的範疇,中臺的工程師很難靠人的方式完成中臺的建模和最佳化的工作。阿里認為向智慧化的方向發展,透過智慧化來最佳化大資料是至關重要的。
二、核心技術發展方向
核心技術發展方向可以從四個角度分析:
- 高效能+低成本
包括計算層、儲存層、資源利用層、治理層四個部分。 - 企業級的服務
要求企業級的穩定性、可擴充套件性和容災等能力。 - 生態與標準化
主要是將生態與標準融合。 - 智慧化
“MaxCompute大資料成本曲線”(價值中心or成本中心?)
上圖展現的是來自阿里雲的上百家客戶調研資料結果,其中黃色的曲線表示公司和部門業務的增長,藍色表示大資料開始應用的過程,在第一年期間是屬於平穩發展方向,到了普惠期,大家發現大資料的技術和價值之後,大資料就開始向上攀升,剛開始攀升的過程不是平緩的,是一個快速增長的過程。
隨之而來有一個問題,資料量和計算量的增長以及對成本的付出超過了已有的增長速度,到後續階段有可能會繼續上漲,如果有相關的系統做匹配,以及很好的最佳化和治理,那麼資料將會降下來,最終達到應用與發展幾乎匹配的速度,同時保證成本是可持續的。比如業務增長了5倍時,成本只增長了1倍。如果不能將資料降下來,則會出現的情況是,資料中心變成了成本中心,同時有非常多的資料和計算,但是哪些是有價值的是不清楚的。為了解決這個問題,需要提供更好的高效能和低成本的服務能力,將平臺層的成本降下來,同時可以透過資料治理服務來為資料做治理。此外,可以透過智慧化方法來最佳化大資料以達到相應的目的。
構建“高效率與低成本”的計算平臺
阿里針對構建“高效率與低成本”的計算平臺所面對的挑戰分為四個部分:
1、當規模過萬臺之後就會面臨成本的持續增長。
2、資料或計算爆炸,硬體投入大於業務增速。
3、中大型公司的技術發展進入開源軟體盲區。
4、無法形成大叢集,多小叢集拼湊,導致整體利用率低。
相應的,阿里巴巴計算平臺對以上挑戰做了以下四項最佳化:
1、引擎最佳化:核心引擎全自研技術,具備把控力,持續最佳化。
2、儲存最佳化:保證資料不重複,儲存智慧分級(1.6),壓縮分級。
3、資源最佳化:雲原生統一資源池(以及對應的削峰填谷)+在離線混布。特別注意的一點是,資源層面的最佳化要優於作業本身的最佳化,作業的極值效能追求和極值速度已經不是阿里最大的追求,而最大的追求是在整體的情況下將資源利用率提升。
4、資料與計算管理與治理。
上圖是以阿里從2015年到2018年雙十一的例子,左邊的圖為單日作業量,中間的圖為單日處理資料量,右邊的圖為成本的曲線。事實證明,阿里透過飛天平臺以及技術能力,幾乎做到了使業務增長的速度和成本增長的速度相適應。
在此基礎上又做了以下部分最佳化工作:
1、引擎側:• NativeEngine+LLVM CodeGen,Vectorization+SIMD
• CBO+HBO,Dynamic DAG
• 針對Input/Shuffling海量資料,新引入“富結構化資料”
• 資料可以按Range/Hash方式儲存,支援一級Index和Order
2、儲存側:相容開源Apache ORC,全新的C++ Writer和改進的 C++ Reader,讀取效能對比CFile2和開源ORC均快50%+。
3、資源側:一套跨叢集資料、計算排程能力,將多個叢集的伺服器做成一臺計算機。
4、排程系統最佳化:平均叢集利用率70%,除了最佳化單作業指標,更偏重整個叢集的吞吐率。
5、透過混布技術,提升線上伺服器利用率到50%以上。同時支援雙十一場景的業務彈性。
部分資料和案例:
• 2015年,SortBenchmark,MaxCompute 100TB GreySort冠軍。
• 2016年,SortBenchmark, EMR 100TB CloudSort冠軍。
• 2017年,MaxCompute+PAI,全球首家100TB規模TPCx-Bigbench測試透過。
• 2018年,MaxCompute+PAI,指BigBench標繼續提升1X+,繼續保持全球最高分數。
• 2018年,Flink內部版是社群效能數倍,2019年開源。
• 2019年,EMR TPC-DS 10TB全球最快
• 2019年,MaxCompute+PAI,指標繼續提升,保持全球第一,30TB效能快一倍,成本低一半。
上圖是在BigBench上從2017年到2019年的統計圖,可以明顯的看出,幾乎每年增長一倍。
從上圖可以看出,與業界的其它系統做對比,效能幾乎高出一倍,成本幾乎低一半。
構建“多功能的企業級”計算平臺
構建“多功能的企業級”計算平臺是屬於系統後臺的工作,大概分為四個部分:
1、需要可靠的資料交匯點(資料底盤),因為很多公司的資料就是公司的資產,資料的安全性問題就顯得至關重要。具體包括以下內容:
• EB級規模,擴充套件能力(單叢集,多級群,全球部署三級擴充套件)
• 資料可靠性(已經走過了能用,可用的階段,需要提供萬無一失的保障 能力,例如DC級別的容災能力)
• 安全性(從儲存,運算,管理,運維,把資料安全做到每一層)
2、針對容災部分,是需要企業自主解決的工作,透過選擇容災,使得達到某種能力,具體需要包括以下內容:
• 基於高價效比硬體
• 自助運維與自動化運維
• 完善的故障容錯(軟體,硬體,網路,人為)
3、由於隱私洩露的情況是經常會發生的,但是阿里卻不會發生隱私洩露的情況,主要是因為對資料管理、共享與安全性的要求。具體包括以下內容:
• 容災備份
• 細粒度授權,安全衛士,審計,儲存加密
• 資料管理能力,資料血緣和追蹤,基於資料血緣的分析和報表
• 多資料/多作業管理和排程
• 基於基線保障的排程能力
4、排程能力與擴充套件性作為系統內部的最佳化,具體包括以下內容:
• 超大規模,統一的資源池
• 超賣
• 基線保障
• 伸縮能力與混布能力
構建“生態融合的”計算平臺
上圖是飛天MaxCompute平臺融合的案例。其中一層為統一的儲存層,不僅僅可以開放MaxCompute的引擎,也可以開放其他的引擎。中間的抽象層為聯合計算平臺,聯合是指將資料、資源和介面抽象成一套標準的介面,包括Spark和其他引擎都可以應用,形成一套完整的生態系統。第二條線的生態是MaxCompute源向外的生態,資料來源是多種多種的,不僅僅存在阿里自已的儲存裡,也可以存在於資料庫的系統和檔案系統等。此外,可以讓使用者在不搬遷資料的情況下和其他系統做聯動,稱為聯邦計算的概念。
另外,Blink是當年在Flink社群的一個單獨的分支,針對阿里內部的最佳開發實踐的系統,在1.9的版本上已經成為完全預設的社群,在SQL引擎、排程系統以及Algo on Flink上做出了很多貢獻。隨著和Flink的某公司存在收購關係之後,將會推動Flink公司一直向前發展。
最後,是儲存層面的發展。上圖是有關壓縮、讀和寫以及資料相關格式的改造,所有的改造都會推進給社群,橙色的字型是按照設計標準改的。
三、從引擎最佳化到“自動駕駛”
計算引擎的最佳化除了自身的最佳化以外,還涉及到自動駕駛。上圖是使用車的例子,展現了飛天進化的過程。第一個過程為可用階段,比如雙十一當天是否能支撐如此大量的負載以保證系統是可用的。第二個過程是在效能和成本上達到極致的追求。第三個過程是讓效能變得更好。
智慧雲數倉(Auto Cloud Data Warehouse)
在阿里內部已經出現了三條關鍵的挑戰:
1、EB級資料和百萬級別作業,很難管理。資料中臺團隊不再勝任(傳統的DBA模式不能支撐)
2、多種資料融在一起,人無法在海量規模上理解資料的所有價值
3、大資料系統經過多年發展,如果需要實現“躍遷”式的進步,需要體系結構層面的改造
從智慧雲數倉的角度來看,可以從三個方面上做最佳化。第一方面是效率最佳化,包括HBO是基於歷史資訊的最佳化,可以理解是一個全新的作業作用到系統中,當系統對它並不瞭解時,對資源的分配相應的會採用保守的方式,使作業執行完成。在第一次執行作業時,系統的調優可能是保守的,慢慢的會越來越貼近自身的執行狀態,到四天之後,所認為的作業就非常好了。透過HBO最佳化,阿里巴巴的資源利用率達到了70%。此外,還包括Learned Statistics、智慧計算重用和智慧的資料分層。
第二方面是資源規劃,當雲上有十萬臺的機器分佈在不同的資料中心時,怎樣規劃資料和資源調動是不屬於人工的過程,應屬於自動化的過程,包括作業執行模式的自動分類,其中有三種不同的執行模式是針對非常大的作業和互動性非常高的作業。此外,還包括動態Quota調整、縮擴容、作業執行預測與自動預報警、作業自動升降級和資料排布與跨叢集排程。
第三方面是智慧建模,包括相似作業與資料的識別、自動糾錯、作業執行預測與自動預報警以及作業自動升降級。
以上這三個方面是在智慧數倉領域可以持續發展的方面,上圖中帶*的是阿里已經或者馬上要公佈的功能。
Auto CDW – 智慧索引推薦
透過作業之間執行的關係,做cost module的同化,透過這種方式是找到一種index最優的調節並且進行push。例如,基於MaxCompute,在阿里集團內挑選了8W張表的30W個欄位 ,從中為4.4W張表推薦出最優的Clustering方案,平均Cost節省43%。
Auto Tired Store - 冷熱資料識別和管理
在今年9月1號時,阿里的儲存整體降價了30%,其中一部分計算就來自上圖中的Auto Tired Store技術,包括冷熱資料的自動分離,之前的資料是透過兩個方式進行分離,第一個方式是系統自動做冷壓縮,降低的成本大概有三分之二。第二個方式是允許使用者透過做flag的方式。但是,當系統裡有千萬級別的表時,資料開發工程師時很難甄別出資料的使用方式的,這時可以使用經濟學的模型,構建Access和Storage之間的關係,針對每個不同作業的不同分割槽,自動地定製冷熱的程度。透過這種方式,把阿里的壓縮率從3倍率壓縮到1.6倍率,整體的儲存效率提升了20%。
Yugong – 智慧全域性資料排布與排程
因為雲系統是多個資料中心部署在全球各個地方的,資料的產生是與業務相關的,但資料之間的關聯是不許被打破的,把什麼樣的資料放在什麼樣的機房裡,什麼樣的作業排程到最優的效果,是屬於全域性最優匹配的問題。在阿里的內部實際上是將作業的靜態排布以及動態的排程融合了一個系統稱為Yugong。上圖中右邊是兩個原理圖。
DPSAaS– 基於差分隱私的資料共享與分析服務
針對敏感資料的計算能力稱為密態計算,針對隱私的資料希望做到可算不可見。上圖表中前三列為敏感資料,後三列為不敏感資料。透過查分隱私的編碼方式,將所有的敏感資料都隱蔽掉了,當要care敏感資料時是care不到的,但做計算時所有資料的計算結果都是正確的,阿里正在透過這種方式探索如何在資料共享與隱私之間找到平衡。
其他面向未來的探索
針對其他面向未來的探索方面,阿里主要涉及的方面包括怎麼在基於圖的關係上做運算、怎樣找到系統之間最優的平衡、基於隱私的計算、如何在多種目標的情況下做更好的排程、在取樣層面如何大幅度的降低資料的情況下仍然做的更好。
本文為雲棲社群原創內容,未經允許不得轉載。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69949601/viewspace-2662908/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 大資料處理的關鍵技術及應用大資料
- 如何進行大資料分析,這“四大技術”是關鍵_光點科技大資料
- 改進DevSecOps框架的 5 大關鍵技術dev框架
- 工業大資料的關鍵技術是什麼大資料
- 面向金融業的分散式交易型資料庫關鍵技術及發展探討分散式資料庫
- 資料治理:資料整合的關鍵技術
- 七、資料庫技術的發展及新技術資料庫
- 大資料系列 1:大資料技術發展歷程大資料
- 大資料——Flink核心技術及原理大資料
- OTN技術的進展及演進趨勢
- 大資料相關技術有哪些?大資料
- IP代理教你大資料最核心的關鍵技術—演算法大資料演算法
- 大資料進入快速發展階段,挖掘“數字寶礦”是關鍵大資料
- 阿里巴巴高階技術專家章劍鋒:大資料發展的 8 個要點阿里大資料
- Android無埋點資料收集SDK關鍵技術Android
- 綜述 | 農業大模型:關鍵技術、應用分析與發展方向大模型
- 鴻蒙OS架構及關鍵技術整理鴻蒙架構
- 萬字詳解資料安全關鍵技術之資料脫敏
- 現代資料架構的7個關鍵技術架構
- 關於大資料技術的一點思考大資料
- 南大通用:元宇宙資料庫技術展望元宇宙資料庫
- 大資料處理關鍵技術主要有五種,具體指的是什麼?大資料
- AI和大資料下,前端技術將如何發展?AI大資料前端
- 大資料技術特點及優勢有哪些大資料
- 元宇宙八大關鍵技術介紹元宇宙
- 視訊通訊關鍵技術探索及實踐
- 分散式資料庫技術的演進和發展方向分散式資料庫
- 陽振坤:OceanBase 資料庫七億 tpmC 的關鍵技術資料庫
- 大資料技術 - Kyuubi大資料
- 大資料技術 - SuperSQL大資料SQL
- 大資料技術 - Directus大資料
- 大資料技術 - Druid大資料UI
- 大資料技術 - Ververica大資料
- 大資料技術 - Phoenix大資料
- 大資料技術 - Azkaban大資料
- 大資料技術 - Airflow大資料AI
- 大資料技術 - DolphinScheduler大資料
- 大資料技術 - DataX大資料