大數據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,除了關注性能和成本以外,隨着數據量超大規模的增加,以及數據領域的優化幾乎已經超出了人類的範疇,中臺的工程師很難靠人的方式完成中臺的建模和優化的工做。阿里認爲向智能化的方向發展,經過智能化來優化大數據是相當重要的。數據庫
核心技術發展方向能夠從四個角度分析:
安全
上圖展示的是來自阿里雲的上百家客戶調研數據結果,其中黃色的曲線表示公司和部門業務的增加,藍色表示大數據開始應用的過程,在第一年期間是屬於平穩發展方向,到了普惠期,你們發現大數據的技術和價值以後,大數據就開始向上攀升,剛開始攀升的過程不是平緩的,是一個快速增加的過程。
隨之而來有一個問題,數據量和計算量的增加以及對成本的付出超過了已有的增加速度,到後續階段有可能會繼續上漲,若是有相關的系統作匹配,以及很好的優化和治理,那麼數據將會降下來,最終達到應用與發展幾乎匹配的速度,同時保證成本是可持續的。好比業務增加了5倍時,成本只增加了1倍。若是不能將數據降下來,則會出現的狀況是,數據中心變成了成本中心,同時有很是多的數據和計算,可是哪些是有價值的是不清楚的。爲了解決這個問題,須要提供更好的高性能和低成本的服務能力,將平臺層的成本降下來,同時能夠經過數據治理服務來爲數據作治理。此外,能夠經過智能化方法來優化大數據以達到相應的目的。
構建「高效率與低成本」的計算平臺
阿里針對構建「高效率與低成本」的計算平臺所面對的挑戰分爲四個部分:
一、當規模過萬臺以後就會面臨成本的持續增加。
二、數據或計算爆炸,硬件投入大於業務增速。
三、中大型公司的技術發展進入開源軟件盲區。
四、沒法造成大集羣,多小集羣拼湊,致使總體利用率低。
相應的,阿里巴巴計算平臺對以上挑戰作了如下四項優化:服務器
一、引擎優化:核心引擎全自研技術,具有把控力,持續優化。
二、存儲優化:保證數據不重複,存儲智能分級(1.6),壓縮分級。
三、資源優化:雲原生統一資源池(以及對應的削峯填谷)+在離線混布。特別注意的一點是,資源層面的優化要優於做業自己的優化,做業的極值性能追求和極值速度已經不是阿里最大的追求,而最大的追求是在總體的狀況下將資源利用率提高。
四、數據與計算管理與治理。
上圖是以阿里從2015年到2018年雙十一的例子,左邊的圖爲單日做業量,中間的圖爲單日處理數據量,右邊的圖爲成本的曲線。事實證實,阿里經過飛天平臺以及技術能力,幾乎作到了使業務增加的速度和成本增加的速度相適應。
在此基礎上又作了如下部分優化工做:
一、引擎側:• NativeEngine+LLVM CodeGen,Vectorization+SIMD
• CBO+HBO,Dynamic DAG
• 針對Input/Shuffling海量數據,新引入「富結構化數據」
• 數據能夠按Range/Hash方式存儲,支持一級Index和Order
二、存儲側:兼容開源Apache ORC,全新的C++ Writer和改進的 C++ Reader,讀取性能對比CFile2和開源ORC均快50%+。
三、資源側:一套跨集羣數據、計算調度能力,將多個集羣的服務器作成一臺計算機。
四、調度系統優化:平均集羣利用率70%,除了優化單做業指標,更偏重整個集羣的吞吐率。
五、經過混布技術,提高在線服務器利用率到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年的統計圖,能夠明顯的看出,幾乎每一年增加一倍。
從上圖能夠看出,與業界的其它系統作對比,性能幾乎高出一倍,成本幾乎低一半。
構建「多功能的企業級」計算平臺
構建「多功能的企業級」計算平臺是屬於系統後臺的工做,大概分爲四個部分:
一、須要可靠的數據交匯點(數據底盤),由於不少公司的數據就是公司的資產,數據的安全性問題就顯得相當重要。具體包括如下內容:
• EB級規模,擴展能力(單集羣,多級羣,全球部署三級擴展)
• 數據可靠性(已經走過了能用,可用的階段,須要提供萬無一失的保障 能力,例如DC級別的容災能力)
• 安全性(從存儲,運算,管理,運維,把數據安全作到每一層)
二、針對容災部分,是須要企業自主解決的工做,經過選擇容災,使得達到某種能力,具體須要包括如下內容:
• 基於高性價比硬件
• 自助運維與自動化運維
• 完善的故障容錯(軟件,硬件,網絡,人爲)
三、因爲隱私泄露的狀況是常常會發生的,可是阿里卻不會發生隱私泄露的狀況,主要是由於對數據管理、共享與安全性的要求。具體包括如下內容:
• 容災備份
• 細粒度受權,安全衛士,審計,存儲加密
• 數據管理能力,數據血緣和追蹤,基於數據血緣的分析和報表
• 多數據/多做業管理和調度
• 基於基線保障的調度能力
四、調度能力與擴展性做爲系統內部的優化,具體包括如下內容:
• 超大規模,統一的資源池
• 超賣
• 基線保障
• 伸縮能力與混布能力
構建「生態融合的」計算平臺
上圖是飛天MaxCompute平臺融合的案例。其中一層爲統一的存儲層,不只僅能夠開放MaxCompute的引擎,也能夠開放其餘的引擎。中間的抽象層爲聯合計算平臺,聯合是指將數據、資源和接口抽象成一套標準的接口,包括Spark和其餘引擎均可以應用,造成一套完整的生態系統。第二條線的生態是MaxCompute源向外的生態,數據源是多種多種的,不只僅存在阿里自已的存儲裏,也能夠存在於數據庫的系統和文件系統等。此外,可讓用戶在不搬遷數據的狀況下和其餘系統作聯動,稱爲聯邦計算的概念。
另外,Blink是當年在Flink社區的一個單獨的分支,針對阿里內部的最佳開發實踐的系統,在1.9的版本上已經成爲徹底默認的社區,在SQL引擎、調度系統以及Algo on Flink上作出了不少貢獻。隨着和Flink的某公司存在收購關係以後,將會推進Flink公司一直向前發展。
最後,是存儲層面的發展。上圖是有關壓縮、讀和寫以及數據相關格式的改造,全部的改造都會推動給社區,橙色的字體是按照設計標準改的。網絡
計算引擎的優化除了自身的優化之外,還涉及到自動駕駛。上圖是使用車的例子,展示了飛天進化的過程。第一個過程爲可用階段,好比雙十一當天是否能支撐如此大量的負載以保證系統是可用的。第二個過程是在性能和成本上達到極致的追求。第三個過程是讓性能變得更好。
智能雲數倉(Auto Cloud Data Warehouse)
在阿里內部已經出現了三條關鍵的挑戰:
一、EB級數據和百萬級別做業,很難管理。數據中臺團隊再也不勝任(傳統的DBA模式不能支撐)
二、多種數據融在一塊兒,人沒法在海量規模上理解數據的全部價值
三、大數據系統通過多年發展,若是須要實現「躍遷」式的進步,須要體系結構層面的改造
從智能雲數倉的角度來看,能夠從三個方面上作優化。第一方面是效率優化,包括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不到的,但作計算時全部數據的計算結果都是正確的,阿里正在經過這種方式探索如何在數據共享與隱私之間找到平衡。
其餘面向將來的探索
針對其餘面向將來的探索方面,阿里主要涉及的方面包括怎麼在基於圖的關係上作運算、怎樣找到系統之間最優的平衡、基於隱私的計算、如何在多種目標的狀況下作更好的調度、在採樣層面如何大幅度的下降數據的狀況下仍然作的更好。運維
原文連接ide
本文爲雲棲社區原創內容,未經容許不得轉載。工具