天天看點

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

前言

随着雲時代全面到來,企業資料需求不斷變化,從傳統的 Big Data 逐漸向 Fast Data 演進,主要表現在如下 4 個方面(部分資料參考 Gartner、IDC):

  • 資料規模爆炸性增長,到 2020 年全球資料預計會到 40ZB,而到 2025 年還會繼續增長 4 倍以上。
  • 企業上雲速度明顯加快,預計到 2025 年企業 50% 的資料都是雲存儲,而企業 75% 的資料庫都運作在雲上。
  • 資料的實時化需求強烈,預計 2025 年全球資料進行中會有 30% 是實時資料處理。
  • 資料智能化趨勢明顯,随着 AI 和 5G 技術的發展,非結構化資料快速增長,到 2025 年預計 80% 的資料都是非結構化資料。

在資料爆炸性增長、企業全面上雲的大背景下,海量資料的存儲、處理的性能及成本效益是雲原生數倉面向未來最核心的關鍵技術名額之一,TPC 官方推出的 TPC-DS 基準測試是對一個資料倉庫從資料導入、查詢性能(單并發、多并發)、查詢複雜度(覆寫星型模型/雪花模型、複雜 Window function 支援)、可用性(資料一緻、壞盤容錯處理等)全方面的嚴格考核,并需要進行全面嚴苛的審計,是目前全球衡量一個資料倉庫成熟度、競争力的核心基準測試。

AnalyticDB 作為雲時代的雲原生資料倉庫,參與 TPC-DS 基準測試是我們提升自研産品産品化能力、核心技術突破驗證的重要過程,也是我們技術走向全球領先的必經之路,這個過程中的核心技術突破正在幫我們的客戶提升性能進一步提升實時化程序、大幅降低成本,一起進入資料庫與大資料一體化、業務線上化的新時代。

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

TPC-DS 榜單

一 AnalyticDB 介紹

AnalyticDB(簡稱 ADB,原 ADS) 是阿裡巴巴自主研發、唯一經過超大規模以及核心業務驗證的 PB 級實時資料倉庫,自 2012 年第一次在集團釋出上線以來,至今已累計疊代釋出近百個版本,支撐起集團内的電商、廣告、物流、文娛、旅遊、風控等衆多線上分析業務。AnalyticDB 于 2014 年在阿裡雲開始正式對外輸出,支撐行業既包括傳統的大中型企業和政府機構,也包括衆多的網際網路公司,覆寫外部十幾個行業。

AnalyticDB MySQL 3.0 (簡稱 ADB 3.0)是在過去 8 年沉澱的基礎上,基于資料庫大資料一體化的理念及趨勢以及工程上深度打磨出的雲原生數倉更新版本。在本次 TPC-DS 基準測試中,AnalyticDB MySQL 3.0 充分展現了出色的雲原生技術優勢,對比友商有近 10 倍的巨大優勢!

二 TPC-DS 性能基準介紹

TPC (Transaction Processing Performance Council) 是事務性能管理委員會的簡稱,是最知名的非盈利的資料管理系統評測基準标準化組織,它制定商務應用基準程式(Benchmark)的标準規範、性能和價格度量,并管理測試結果的釋出,而 TPC Benchmark 測試結果是衡量一個資料管理系統性能及成本效益的最核心名額之一。

TPC-DS 基準測試模拟了一個典型的零售行業資料倉庫的評測決策支援系統(Decision Support),是資料庫界最具挑戰的一個測試基準,是 TPC-H 的更新版,它采用星型、雪花等多元資料模式,測試集包含對大資料集的統計、報表生成、聯機查詢、資料挖掘等複雜應用,與真實場景非常接近。

TPC-DS 的難點和挑戰主要有:

  • 資料集規模大,例如事實表 store_sales,單表超過 280 億行。
  • 面向真實零售決策場景,SQL 非常複雜:覆寫 SQL 99 和 2003 的核心部分以及 OLAP 标準;既包含報表類 ad-hoc 低延時查詢,又包含海量資料挖掘高吞吐分析查詢。
  • 測試項多且次元廣:既要高性能、高可靠、高可用、高成本效益,又要 ETL 和資料更新的 ACID 能力。

TPC-DS 測試流程及資料模型:

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

三 AnalyticDB MySQL 3.0 技術架構

AnalyticDB MySQL 3.0 采用雲原生架構,計算存儲分離、冷熱資料分離,支援高吞吐實時寫入和資料強一緻,兼顧高并發查詢和大吞吐批處理的混合負載。

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

第一層是接入層,由 Mulit-Master 可線性擴充的協調節點構成,主要負責協定層接入、SQL 解析和優化、實時寫入 Sharding、資料排程和查詢排程。

第二層是計算引擎,具備分布式 MPP + DAG 融合執行能力,結合智能優化器,可支援高并發和複雜 SQL 混合負載,同時借助于雲原生基礎設施,計算節點實作了彈性排程,可根據業務需求做到分鐘級甚至秒級擴充,達到了資源的有效利用。

第三層是存儲引擎,基于 Raft 協定實作的分布式實時強一緻高可用存儲引擎,通過資料分片和 Multi-Raft 實作并行,利用分層存儲實作冷熱分離降低成本,通過行列存儲和智能索引達到極緻性能。

四 AnalyticDB 存儲技術

1 分布式強一緻存儲

AnalyticDB MySQL 3.0 存儲完全自主研發,基于 Raft 協定建構了一套分布式強一緻高可靠的輕量級存儲架構,可實作高吞吐實時寫入,适合極緻分析性能場景。AnalyticDB MySQL 3.0 存儲相比開源 HBase、Kudu 等在 SQL 分析性能上有較大優勢,并且在實時寫入強一緻可見、支援 ACID 方面也是開源 ElasticSearch、ClickHouse 等所不具備的能力。

AnalyticDB 存儲整體架構如下:

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

AnalyticDB MySQL 3.0 是基于資料庫的并行資料模型,存儲模組化親和 MPP 計算模型,内部實作為多層并行的架構:

第一級是叢集執行個體級并行,使用者執行個體被劃分為多個存儲節點組(Worker Group),每個 Worker Group 由 N(通常是 3,也可以是其他基數)個 Worker 構成。Worker 相當于使用者資料節點容器,分組的目标是保證系統大規模擴充時不會出現通信膨脹、也友善系統并行更新和運維。

第二級是 DB 并行,使用者資料庫被切分為 N 個實體分庫( Shard,也叫資料分片),每個 Shard 是獨立的 Raft Group 以保證資料強一緻,多個 Shard 就形成了 multi-raft 的并行。Shard 是可以是 Hash 或者 Range 分區,通常 Hash 分區可以做資料對齊以避免資料大表 JOIN 的資料 Shuffle;Shard 可以在需要的時候在不同 Worker Group 之間均衡或者遷移,Shard 本身也會支援動态分裂和合并。

第三是表内并行,對于數倉場景的曆史資料存儲通常有資料分區的概念,例如 TPC-DS 中 store sales 就可以根據時間周期分區,資料分區除友善資料生命周期管理外還可以支援查詢分區裁剪和 DFP,有助于大幅縮小資料計算範圍。

在 TPC-DS 基準測試中,通過分布式并行存儲架構以及感覺存儲分布的查詢優化和執行引擎緊密配合,整體性能優異。

2 高性能批量導入

資料導入速度是雲數倉的基礎能力,在 TPC-DS 中對導入有着極緻的性能要求,我們的第一個優化思路是輕量級 build(把實時資料轉換為全量分區資料稱之為 build),AnalyticDB MySQL 3.0 實作了輕量化的全記憶體單副本 local build,相比之前版本的類 MR 作業的全量 build 大幅減少了讀寫 DFS 和落盤開銷,并且可以充分通過本地化向量指令有效利用 CPU 提升性能。

第二個思路是 IO 和網絡優化,在導傳入連結路上,我們采用 DirectIO、Binary 化、全流式、異步化、零拷貝等技術大幅提升導入性能。

第三個思路是減少資料量,通過 Raft 2+1 技術(2 份資料 + 1 份日志)在保證資料高可靠的前提下将資料量減少 1/3, 再通過高性能 lz4 壓縮算法将資料進一步壓縮,整體下來資料的讀寫 IO 和網絡傳輸開銷都得到大幅優化。

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

最終,在 TPC-DS 18 個節點上可以實作超過 5000 萬/秒的導入性能。

3 高吞吐實時更新 DML

AnalyticDB MySQL 3.0 基于 Raft 實作了高吞吐實時資料更新能力,寫傳入連結路通過全異步化、零拷貝、高效編碼壓縮等實作了出色的性能,在 TPC-DS DML 測試中,AnalyticDB 十幾個節點可以做到千萬級 TPS 實時寫入更新,并且能夠保證線性一緻性(寫入後立即可查)。在實際生産中,使用者寫入性能完全可擴充,可以輕松實作億級 TPS 的實時寫入更新。

在 TPC-DS 中,需要驗證資料倉庫的資料修改和 ACID 能力,AnalyticDB MySQL 3.0 支援 ETL 事務,具備 ACID 能力(可以完整跑 TPC-C 事務功能測試),在 TPC-DS 的 DML 測試中,存儲引擎 MVCC 能力發揮了巨大的作用:存儲引擎通過切分為實時資料(Delta)和分區資料(Main)+ 異步的資料轉換(Build)實作了類 LSM 寫優化架構。AnalyticDB 實作了 Block-level MVCC + 快照隔離,可以保證 ETL 和資料更新過程中資料的隔離性(可見性)、在壞盤出錯時可以保證資料更新原子性。

4 行列混存和智能索引

AnalyticDB MySQL 3.0 通過自研的行列混存格式,能夠兼顧高篩選率和大吞吐掃描兩種場景,相比開源 ORCFile 的純列存格式在明細點查上更有優勢,而相比 Parquet,AnalyticDB MySQL 存儲格式具有更出色的随機讀性能,同時對比業界行存表 + 列存表兩份資料備援的模式成本更低。在 AnalyticDB MySQL 中,每個 Table 都有一個行列存儲格式檔案,資料被切分成不同的 RowGroup,在 RowGroup 内由列的 Block 構成,Block 内對定長、非定長(Toast)資料的進行有效的編碼和壓縮,并且支援高效的随機讀和順序讀。

在 TPC-DS 測試中,通過配置合理的存儲 Block 大小(4KB 對齊)、資料塊預取、源頭算子向量讀等大幅優化了存儲掃描性能;同時,存儲上精确的統計資訊(min/max/sum/cnt 等)一方面可以加速資料過濾(Smart Scan),另一方面還能夠為查詢優化器提供豐富的 Statistics 以幫助制定出最優的執行計劃。

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

AnalyticDB MySQL 的特色之一是自研智能索引架構,支援五種索引類型:字元串類的 Invert 索引、bitmap 索引、數值類的 KDTree 索引、JSON 索引和向量索引;不同類型的索引可以實作列級索引多種條件(交、并、差)任意組合;相比較傳統資料的優勢是,無需建組合索引(不會引起空間膨脹)、且支援 OR/NOT 等更多條件的索引下推。為了降低使用者使用門檻,AnalyticDB 在建表時可以開啟一鍵自動全列索引,查詢時通過 Index CBO 智能動态篩選索引下推,确定下推的索引鍊會通過謂詞計算層進行流式漸進多路歸并輸出。

五 AnalyticDB 查詢技術

AnalyticDB MySQL 3.0 的查詢引擎,由自研的查詢優化器和查詢執行器兩個子產品組成。它是 AnalyticDB MySQL 提供高并發、高吞吐數倉分析能力的重要一環。感覺資料特征,深度結合存儲引擎的架構,同時支援 Reporting、Ad-hoc、ETL 數倉分析場景,是其相較于單一計算引擎的核心優勢。

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

作為一款分布式雲原生實時數倉産品,AnalyticDB MySQL 的優化器不僅僅要面臨傳統優化器所涉及的挑戰,例如複雜 Join Reorder 的 NP-hard 問題,代價估算的不确定性問題,還面臨在分布式環境下分布式并行計劃的新問題。CBO 做為 AnalyticDB MySQL 3.0 版本最新成果,在 TPC-DS 戰役中首次開啟使用,對于整體計劃的調優,起到了非常重要的作用。

ADB 查詢執行引擎,以統一的記憶體池化和查詢的混合負載管理能力為基礎,使用動态代碼生成技術,創新性的混合執行模型,利用 SIMD 指令集的向量化算法,以及自适應的面向行、列混合存儲的查詢執行等技術,是 AnalyticDB MySQL 持續的在 TPC-DS 查詢性能上領先的關鍵因素。

1 CBO 查詢優化架構

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

基于代價的優化器本質上是一個複雜的搜尋問題,想要解決好這個問題,需要從四個方面入手:

搜尋架構

從資料庫的發展曆程來看,基于 Cascades 的搜尋架構已經成為了業界标準,包括商業資料庫 SQL Server 以及開源資料庫 GP/ORCA 都采用 Cascades 實作。AnalyticDB MySQL 優化器 CBO 也是基于 Cascades 論文實作的。搜尋架構面臨的一個核心問題是搜尋空間會急速膨脹,但是搜尋時間需要維持毫秒級響應,是以需要有高效的資料結構存儲搜尋空間、高效的優化規則生成搜尋空間、高效的搜尋算法周遊搜尋空間,高效的剪枝政策裁剪搜尋空間。

分布式并行計劃

相對于傳統的單機版資料庫來說,分布式 MPP 資料庫給優化器帶來了新的挑戰。在分布式 MPP 資料庫中,資料的分布屬性變得十分的重要,它會直接影響到資料的正确性。為了滿足不同算子對資料分布的要求,資料重分布不可避免,然而資料的重分布即資料 shuffle 的代價非常昂貴,是以,在保證資料正确性的前提下,盡可能的減少資料 shuffle。作為分布式 MPP 資料庫優化器來說,需要把資料的 Partitioning 屬性,以及 Sorting、Grouping 屬性,也納入到搜尋空間來綜合考慮,基于代價選擇最優的分布式并行執行計劃。

代價估算

代價估算是優化器能否尋找到最優計劃的關鍵因素。代價估算涉及到統計資訊的推導和代價模型。統計資訊的推導依賴于:原始表的統計資訊、中間算子的推導算法、對資料的各種假設(均勻性假設、獨立性假設、包括性假設、包含性假設)以及在一些極端情況下的猜測。是以統計資訊的推導存在大量的不确定性,也正是因為這些不确定性,極大的加劇了優化器尋找最優解的難度。本質上來說,隻有打破對資料屬性的假設,才有可能使得統計資訊的估算做到知其然知其是以然,然而打破這些假設,也要付出更多的代價。

統計資訊收集

收集必要的統計資訊是 CBO 工作的前提,統計資訊需要做到:基本資訊能夠自動化收集,自動化更新,進階統計資訊可以手動收集,為 CBO 提供可靠的、多緯度的統計資訊。在實際的情況下,可能存在統計資訊丢失或者沒有及時收集,在這種情況下,為了避免生成災難性的計劃,可以在運作時動态采樣來擷取必要的統計資訊。

2 混合查詢執行架構

傳統的火山執行模型不能滿足分析場景高吞吐的性能需求已經成為業界的共識。随着各個系統的不斷發展,目前業界計算引擎有 2 種演化後的執行架構實作:

  • Just-in-time (JIT) compilation
  • Vectorization

JIT編譯方式以資料為中心,一條資料經過上一個算子處理後,還在 CPU 緩存中便直接進行下一個算子的計算,對 CPU 緩存友好,适合計算密集型任務。Vectorization 中每個算子處理一批資料後,将一批結果再交給下一個算子計算。适合記憶體密集型任務以及向量計算,用中間結果物化的開銷換取算子的計算高内聚。

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

JIT 編譯方式和 Vectorization 各有所長,如上圖所示,紅色表示 JIT 編譯方式,綠色表示 Vectorization 方式。目前 AnalyticDB MySQL 是唯一的同時支援這兩種查詢模式的自研分析引擎。混合執行架構,在 Vectorization 執行模式的基礎上,自适應的把多個計算密集特征的算子融合成一個驅動執行。實作了一個查詢執行引擎同時具備 Compilation 和 Vectorization 的優點。

3 統一記憶體管理

在記憶體方面,高效的記憶體管理是計算優化的基石。面向類型的記憶體模型,特指針對不同的資料類型使用不同的基礎類型存儲。這導緻不同的類型無法存儲在連續的記憶體位址中,僅能通過按列的方式進行存儲,減少多個記憶體對象帶來的額外代價。另外一方面,不同記憶體類型間的記憶體無法複用,這會造成額外的記憶體管理代價。

技術解析:阿裡雲 AnalyticDB 如何實作全球性能第一

ADB 的查詢執行引擎,通過統一記憶體管理來解決上面的幾個問題:

  • 記憶體 binary 化:統一記憶體類型,不同類型均使用相同的資料類型(byte)來存儲,同時這也是查詢執行面向行存,緩存友好算法優化的基石。
  • 規範化的記憶體管理規格:統一記憶體規格,降低記憶體碎片帶來的額外代價,并且降低複用記憶體的難度。
  • 分層的記憶體管理:統一記憶體管理,根據計算特點對應記憶體的生命周期,針對記憶體使用特點,實作 MemoryCache, MemoryPool,并且支援記憶體洩漏檢測,實作面向常駐服務的主動記憶體管理。

4 DFP 和 CTE 技術

在資料倉庫中,事實表和次元表 Join 是典型場景,他們之間的資料量的差異可以達到千萬倍級别,這個時候,Join 的計算成本更多的在于資料的掃描成本,是以我們會采用 DynamicFilterPushDown 的方式,來極大的減少左表的資料量。另外資料倉庫中會出現大量的 WITH 語句以及隐式的共享語句,這些都可以通過 Common Table Expression 的共享來避免重複計算。

DFP(DynamicFilterPushDown)對于篩選率高的 Join (命中率低)、Probe 端的資料從存儲中被讀上來之後,大部分資料會被丢棄掉。是以如果評估出來 build 的資料維持在一個比較小範圍的門檻值,那麼我們就可以把 build 端結果值,作為左表的過濾條件,也就是 Dynamic Filter,直接下推存儲,減少掃描量。對于優化器來說,最主要的工作就是要合理評估 build 端命中 Join 條件的 NDV 值。

不同的 Join Order 直接影響可做 Dynamic Filter 的範圍和粒度,能夠進行該優化的 Join 其 Cost 與真正的 Hash Join 有巨大的差異反過來也影響了 Join Order。基于 ADB 完善且擴充性較好的 CBO 架構,我們做到了從全局考慮,基于 Cost 選擇最優的 Dynamic Filter 方案。

在執行層面,我們通過如下三個關鍵點實行有高效的 DFP:

  • 高效動态謂詞建構,通過程序内 in-place 建構動态謂詞,降低動态文詞建構代價。
  • 多層過濾執行優化,結合 bloomfilter,分區裁剪,感覺存儲索引等方式,加速過濾效果。
  • 異構資料源的下推,統一資料源接口層抽象實作,擴充異構資料源的支援。

CTE(Common table expression),TPC-DS 30%+ 的 sql 中包含 with as 用法, 通過 with as 子查詢,在主查詢中多次引用,每一次引用帶來了額外的重複計算,導緻資源浪費。基礎的 CTE 優化,通過複用 with 子句的結果給多個引用方,來減少重複計算的代價。但是對于部分場景,與主查詢的關系推導可以進一步減少 with 子查詢中的計算量,這時直接 share 完整 with 子句會導緻額外的性能回退。那麼通過 inline 後的最優計劃,進行 common sub tree 的識别,進一步減少重複計算量,達到無 bad case 的效果。執行器實作中,我們引入了死鎖檢測,通過分析 common sub tree 的多個 consumer 之間的依賴關系,解決死鎖問題。

六 總結和展望

AnalyticDB 經過資料庫領域最頂級會議 VLDB 論文(AnalyticDB: Realtime OLAP Database System at Alibaba Cloud)的理論驗證(中國極其少有的大規模商用系統介紹論文,類似有 Google F1 [VLDB'2013]、AWS Aurora [SIGMOD'2017] 等)、TPC-DS 全球領先的工程驗證(TPC-DS 全球成本效益、性能雙雙領先)、覆寫核心部委以及大型泛網際網路客戶的客戶驗證、阿裡集團多年的超大規模驗證形成了多方面優勢,基于雲計算的高效資源效率、資料庫與大資料一體化發展趨勢,正式完成重大品牌更新,由“分析型資料庫”更新為“雲原生資料倉庫”。

未來已來,大資料與資料庫一體化 + 雲原生将會重新定義雲計算時代的資料倉庫,TPC-DS 破世界紀錄隻是起點,AnalyticDB 将會持續投入緻力于成為企業數字化轉型更新、資料價值線上化的基礎設施!

AnalyticDB 2019 大盤點:

點選這裡