前沿 | VLDB論文解讀：阿里雲超大規模實時分析型數據庫AnalyticDB

前言

一年一度的 數據庫領域頂級會議VLDB 2019於美國當地時間8月26日-8月30日在洛杉磯召開。在本屆大會上，阿里雲數據庫產品團隊多篇論文入選Research Track和Industrial Track。

本文將對入圍Industrial Track的論文《AnalyticDB: Realtime OLAP Database System at Alibaba 
Cloud》進行深度解讀。

一、背景

隨着數據量的快速增加，愈來愈多的企業迎來業務數據化時代，數據成爲了最重要的生產資料和業務升級依據。伴隨着業務對海量數據實時分析的需求愈來愈多，數據分析技術這兩年也迎來了一些新的挑戰和變革：

1) 在線化和高可用、離線和在線的邊界愈來愈模糊，一切數據皆服務化、一切分析皆在線化； 
2) 高併發低延時，愈來愈多的數據系統直接服務終端客戶，對系統的併發和處理延時提出了新的交互性挑戰； 
3) 混合負載，一套實時分析系統既要支持數據加工處理，又要支持高併發低延時的交互式查詢； 
4) 融合分析，隨着對數據新的使用方式探索，須要解決結構化與非結構化數據融合場景下的數據檢索和分析問題。

阿里巴巴最初經過單節點Oracle進行準實時分析, 後來轉到Oracle RAC。隨着業務的飛速發展, 集中式的Shared Storage架構須要快速轉向分佈式，遷移到了Greenplum，但不到一年時間便遇到擴展性和併發的嚴重瓶頸。爲了迎接更大數據集、更高併發、更高可用、更實時的數據應用發展趨勢，從2011年開始，在線分析這個技術領域，阿里實時數據庫堅決的走上了自研之路。大規模、海量數據實時分析型數據庫系統——AnalyticDB，也是在這個時候誕生。

AnalyticDB是阿里巴巴自主研發、惟一通過超大規模、高併發以及核心業務驗證的PB級實時分析型數據庫。自2012年第一次在集團發佈上線以來，至今已累計迭代發佈近百個版本，支撐起集團內的電商、廣告、菜鳥、文娛、飛豬等衆多在線分析業務。AnalyticDB於2014年在阿里雲開始正式對外輸出，支撐行業既包括傳統的大中型企業和政府機構，也包括衆多的互聯網公司，覆蓋外部十幾個行業。AnalyticDB承接着阿里巴巴廣告營銷、商家數據服務、菜鳥物流、盒馬新零售等衆多核心業務的高併發分析處理，每一年雙十一上述衆多實時分析業務高峯驅動着AnalyticDB不斷的架構演進和技術創新。

二、挑戰

已有的分析型數據庫（如下簡稱OLAP）諸如Impala、Pinot、Druid等，總結了OLAP系統在設計的過程當中應該解決的問題：低延遲、數據新鮮度、多樣性、低成本、高擴展性、高可靠性。和這些已有的OLAP系統相比，AnalyticDB承載着更大的規模：2000+臺物理機器、10PB+規模數據、百萬張數據表以及萬億條數據行。所以，AnalyticDB在設計與實現的時候，不只要解決已有OLAP系統要解決的問題，還要面臨與解決三個更大的挑戰：

1） 隨着用戶分析需求的急劇增長，用戶的查詢變得複雜且多樣化：這些查詢涵蓋點查詢、全表掃描、多表關聯等，還會包含對任意列組合的篩選條件。如何在這種複雜分析場景下依然保證大部分甚至全部查詢的低延遲，是一個很是大的挑戰； 
2） 如何在保證低延遲查詢的狀況下，仍然能處理每秒千萬級別的寫吞吐。傳統的設計理念在同一條鏈路上同時處理讀寫請求，這會形成讀寫性能的互相嚴重影響。 
3） 複雜分析場景下，會對行存、列存、關係型存儲、複雜數據類型（JSON、vector、text）都有着強烈需求。如何設計一個對這些存儲格式都很友好的存儲層，也是一個業界難題。

接下來咱們會介紹AnalyticDB的設計與實現關鍵點，探究AnanlyticDB是如何解決這些挑戰的。

三、 AnalyticDB架構

AnalyticDB的總體架構以下圖：

每一個模塊的具體描述以下：

• Coordinator（協調節點）：協調節點負責接收JDBC/ODBC鏈接發過來的請求，並將請求分發給讀節點或者寫節點。
• Write Node（寫節點）：只處理寫請求（如INSERT、DELETE、UPDATE）的節點。
• Read Node（讀節點）：只處理讀請求（如SELECT）的節點。
• Pangu（盤古）：高可靠分佈式存儲系統，是AnalyticDB依賴的基礎模塊。寫節點會將寫請求的數據刷到盤古上進行持久化。
• Fuxi（伏羲）：資源管理與任務調度系統，是AnalyticDB依賴的基礎模塊。伏羲合理使用集羣機器的空閒資源，以進行相關計算任務的異步調度執行。

3.一、表分區

爲便於大規模分析處理，AnalyticDB對數據表進行分區。AnalyticDB數據表有兩個分區級別：一級分區和二級分區。圖4展現了建立帶有一級分區、二級分區表的DDL語句：一級分區有50個分區，分區鍵爲id列；二級分區有12個分區，分區鍵爲dob列。數據行依據其包含的一級分區鍵的hash值，對應到不一樣的一級分區。一般，選擇具備較高基數（cardinality）的列做爲一級分區鍵，以保證數據行能均勻地分佈到每一個一級分區，最大化並行。用戶還能夠根據須要定義二級分區，以便進行數據的自動管理。二級分區擁有最大分區數，當二級分區的實際數目超過了這個最大分區數後，最老的二級分區會被自動刪除。一般，選擇時間列（天、周或月）做爲二級分區列，這樣，包含相同時間序列的數據行，會被劃分到同一個二級分區中。

3.二、讀寫分離

傳統OLAP系統在同一個鏈路上同時處理讀寫請求，所以，全部的併發讀寫請求都共享同一個資源池，也會互相影響。可是當讀寫併發同時很是大時，這種設計會因爲過分的資源競爭而致使很差的性能。如圖5所示，爲了解決這個問題，同時確保讀和寫的高性能，AnalyticDB採用的架構爲讀寫分離架構，即AnalyticDB有獨立的讀寫節點各自處理讀寫請求，且寫節點和讀節點徹底互相隔離。

寫節點：某個寫節點會被選爲主節點，其餘寫節點選爲從節點，主節點和從節點之間經過ZooKeeper來進行通訊。每一個節點會獨立負責某些一級分區的數據，主節點的任務就是決定每一個節點負責哪些一級分區。協調節點會將寫請求分發到對應的寫節點上，寫節點收到請求後，會將寫SQL語句放到內存buffer中，這些buffer中的SQL語句稱爲log數據。寫節點會將buffer中的log數據刷到盤古上，當刷盤古成功後，寫節點會返回一個版本號（即LSN）給協調節點，表示寫完成了。每一個一級分區在其對應的寫節點上，都會獨立地對應一個版本號，每次寫節點將某個一級分區的log數據刷到盤古後，都會增大這個版本號，並將最新版本號返回給協調節點。

當盤古上的log數據達到必定規模時，AnalyticDB會在伏羲上啓動MapReduce任務，以將log數據轉換成真實存儲數據+索引。

讀節點：每一個讀節點也獨立負責某些一級分區的數據。在每一個讀節點初始化時，它會從盤古上讀取最新版本數據（包括索引）。以後，基於這份數據，讀節點會從寫節點的內存buffer中將寫請求log週期性地拉取過來，並在本地進行replay，replay以後的數據不會再存儲到盤古中。讀節點根據replay以後的數據，服務到來的讀請求。

因爲讀節點須要去從寫節點上拉取寫請求數據，所以讀節點爲用戶提供了兩種可見性級別：實時（real-time）可見和延時（bounded-staleness）可見。實時可見容許讀節點當即讀到寫節點寫入的數據，延時可見容許讀節點在一段時間後纔讀到寫節點上寫入的數據。AnalyticDB默認使用的可見性級別爲延時可見。

當可見性級別選擇爲實時可見時，AnalyticDB採用了版本校驗（version verification）機制來確保讀寫節點的同步。當用戶執行完寫請求後，他/她再發送一個查詢請求到協調節點。協調節點會從對應寫節點上獲取最新的版本號（記爲V1），連同查詢請求一塊兒下發給對應的讀節點。讀節點上在進行本地replay的時候，也會存有目前已經replay的版本號（記爲V2）。讀節點會比較V1和V2的大小：若是V1小於等於V2，那麼讀節點直接基於本地replay的數據執行查詢；若是V1大於V2，那麼讀節點會從對應寫節點上拉取直到V1的log數據，replay後再執行查詢。須要強調的是，當可見性級別爲延時可見時，協調節點在下發查詢請求以前，不會實時地從對應寫節點上獲取最新版本號，而是使用緩存的以前寫節點返回給本身的版本號（因爲存在不少協調節點，因此某個協調節點上緩存的版本可能不是最新版本）。

3.三、可靠性與擴展性

• 可靠性。
  AnalyticDB的讀節點和寫節點均具備高可靠性。對於寫節點來講，當某個從節點失效的時候，主節點會將其負責的一級分區均勻地分配給其餘正常的從節點。當主節點失效的時候，新的主節點會被從新選出來進行替代。對於讀節點來講，用戶能夠指定讀節點的副本個數（默認爲2），不一樣副本會被放到不一樣的物理機上，以提供高可靠性。當某個讀節點失效時，協調節點會將讀請求自動下發到其餘副本上。須要強調的是，某個寫節點的失效，也不會影響讀節點正常地拉取log數據和replay數據。由於log數據是持久化在盤古上的，在寫節點失效地時候，讀節點能夠直接去盤古上拉取log數據。
• 擴展性。
  AnalyticDB的讀節點和寫節點也具備高可擴展性。當一個新的寫節點加入時，主節點會自動調整一級分區的分配，保證負載均衡。讀節點的可擴展性也是由相同的機制保證的，只不過對於讀節點，調整一級分區分配的是協調節點。

3.四、集羣管理

AnalyticDB集羣管理模式爲多租戶模式，即同一個集羣上能夠運行多個AnalyticDB實例。咱們設計並實現了一個稱爲Gallardo的集羣管理組件，Gallardo採用CGroup技術對不一樣AnalyticDB實例進行資源隔離（CPU核、內存、網絡帶寬），並負責實例的穩定性。當新的AnalyticDB實例建立的時候，Gallardo會爲其分配相應的資源，在分配資源的時候，Gallardo會將協調節點、寫節點、讀節點以及讀節點的不一樣副本放置在不一樣物理機上，以保證可靠性要求。

四、 AnalyticDB存儲層設計

AnalyticDB存儲圍繞爲「計算而生」 這一設計目標，主要解決海量數據的極速查詢問題。本章將詳細剖析存儲和索引原理，並闡述設計背後的思考。

4.一、存儲層架構

AnalyticDB存儲層採用Lambda架構，讀節點上的數據包括基線數據和增量數據兩部分。如圖6左邊所示，基線數據是增量寫入前的全部歷史數據，包括索引和明細數據；增量數據沒有索引，只有明細數據。明細數據來自於寫入節點的日誌數據，並按照行列混存的結構（見4.2節）保存在讀節點的SSD磁盤上。

4.1.一、寫入和查詢過程

AnalyticDB不只支持實時INSERT，同時還支持UPDATE和DELETE。執行DELTE時，AnalyticDB沒有采用當即物理刪除，而是使用bitset來標記被刪除的數據行，這些被標記刪除的數據會在數據合併（4.1.2）時被真正物理刪除。執行UPDATE時，UPDATE操做會被轉換爲DELETE + INSERT。COPY-ON-WRITE技術被用來支持MVCC多版本控制。當數據發生刪除或更新時，AnalyticDB會產生一個新版本的bitset，並將被刪除後更新的行的位設置1。此時正在運行的查詢能夠繼續使用老版本的delete bitset，不會被寫入阻塞。

算法一、二、3分別詳細解釋了INSERT、DELETE和QUERY執行的詳細過程。

4.1.二、數據合併

因爲沒有全局索引，隨着數據的不斷實時寫入，增量數據的查詢性能會愈來愈慢。所以咱們會在後臺經過伏羲啓動一個MapReduce 任務來合併基線數據和增量數據（同時去掉標記爲刪除的數據）造成一個新的基線數據，並基於新的基線數據構建全量索引。如圖7所示，當數據合併任務開始時，首先會將增量數據引擎標記爲immutable，並建立一個新的活躍增量數據引擎，該活躍增量數據引擎接受實時寫入的數據。在合併任務執行過程當中，全部查詢和INSERT/DELETE都會執行在基線數據、immutable增量數據和活躍增量數據這三個數據引擎上。當合並任務完成後，老的基線數據和immutable增量數據會被替換爲新的基線數據，新的查詢將執行在新基線數據和活躍增量數據這兩個數據引擎上。等全部老的查詢都結束後，老基線數據和immutable增量數據會被刪除。

4.二、存儲數據結構

4.2.一、行列混存

在海量數據分析場景下，數據分析業務主要有如下三類workload：

1） OLAP場景下的大規模多維分析：海量數據的統計分析和多表關聯，比較適合列存格式； 
2） 高併發的點查：一般須要撈取出一整行的明細數據，比較適合行存。 
3） 高寫入吞吐：每秒千萬的高吞吐實時寫入，比較適合行存。

不管是行存和列存都沒法同時知足以上需求，如何在一個系統中同時解決以上問題？如圖8所示，AnalyticDB提出使用行列混存 結構，使用一套存儲格式，兼具行存和列存之所長，同時知足以上三類workload。

對於一張表，每k行數據組成一個Row Group。在每一個Row Group中，每列數據連續的存放在單獨的block中，Row Group在磁盤上連續存放。每一個block因爲數據類型相同，能夠支持高效的壓縮。同時爲了保證點查詢的性能，咱們會將全部的數據按照按指定列(彙集列)排序存放，好處是在按該列查詢時顯著減小磁盤隨機IO次數。最後，與列存寫入相比，行列混存能夠把多個文件的寫入被轉化成單個文件的順序寫入，下降了IO的開銷。

4.2.二、元數據

爲了加速查詢，AnalyticDB對每列構建一份元數據，並保存在一個叫detail_meta的單獨文件中。detail_meta文件一般較小（小於1MB），首次查詢時被加載在內存中。如圖8左邊所示，元數據主要包括4部分：

• Header。包括版本號，文件長度以及一些統計信息。
• 列統計信息。包括行數，NULL值數，cardinality，SUM，MAX和MIN 值。優化器根據這些信息來生成最佳執行計劃。
• 字典。對於cardinality較少（小於1024）的列，AnalyticDB採用字典編碼，數據文件裏保存字典號碼。字典保存在該字段中。
• 塊地址信息。保存塊號到數據文件起始地址和長度的映射關係。

4.2.三、非結構化數據存儲

AnalyticDB不只支持基本數據類型，也支持長文本、JSON和向量數組等非結構化數據類型。可是單行文本、JSON、向量數據的長度一般比基本數據類型的數據要長，單行長達數十KB甚至MB級別。基於固定行數的block設計會致使單個block過大，IO效率下降。所以針對非結構化數據類型，AnalyticDB採用了定長數據塊技術，每一個塊大小相同。

如圖9所示，每一個Block由多個定長數據塊（稱做FBlock）組成，每一個FBlock大小爲32KB，單獨存儲爲一個文件中。Block中保存的再也不是原始數據內容，而是數據所在FBlock的塊號和FBlock內的偏移位置。查詢時，首先讀取Block中的內容，獲得FBlock的塊號和塊內偏移，而後再讀取FBlock內容，獲得非結構化數據內容。

4.三、索引管理

索引是數據庫系統裏影響性能最關鍵組件，可是傳統的索引並不能很好知足OLAP場景下任意ad-hoc查詢的需求。例如B+Tree索引，在海量數據下存在中間節點過多，容易產生大量隨機IO等問題；Druid能夠對多列數據構建倒排索引，可是隻能支持特定數據類型（字符串類型，不支持數值類型）； 傳統數據庫構建索引佔用大量資源，影響寫入性能；現有的索引也不支持非結構化數據類型，例如JSON，長文本和向量。

所以，AnalyticDB設計和實現了一個新的索引引擎，在不影響寫入性能的狀況下，支持結構化和非結構化數據類型索引。它將構建過程從寫入鏈路中移除，採用後臺異步構建模式，支持對全部列構建索引，從而解決了OLAP任意查詢的性能問題。

4.3.一、索引查詢

AnalyticDB默認對全部列構建索引，並保存在一個單獨的文件中。與傳統的數據庫不一樣，AnalyticDB索引中的key是列的值，value是該值出現的全部行號集合，並支持全部的條件同時走索引查詢。如圖10所示，該SQL是一個複雜查詢包括結構化列條件和非結構化列條件。索引引擎會首先對每一個條件走索引掃描，獲得多個行號集合，而後將AND/OR 條件轉換爲行號集合的UNION/INTESECT操做。

AnalyticDB在索引引擎是實現上也作了大量的優化，包括：多路流式歸併、索引選擇CBO和索引結果緩存。
多路流式歸併：傳統數據庫大多采用2路歸併策略，在條件數特別多的場景下，會致使大量中間結果，計算效率很低。AanlyticDB採用K路流式歸併算法，能夠支持多個集合並行歸併，避免產生大量中間結果集合，提高了整個歸併的速度。

索引選擇CBO：當where條件中包括多個條件，並非全部的條件走索引掃描能取得最佳的性能。利用索引中的統計信息，提早估算出各個條件可能的選擇率，對於選擇率很高的條件走索引查詢，其餘條件直接在上層進行過濾操做。例如對於where id = 1 and 0 < x < 1000000的狀況下，d = 1這個條件的選擇率已經很高，則0索引結果緩存：在OLAP分析場景中，多個查詢條件中，可能會出現部分條件固定不變或重複屢次出現。針對這種場景AnalyticDB 實現了一個高效的無鎖緩存，緩存的的key爲等值或range條件，value爲行號集合。這樣在出現重複查詢狀況下，能夠直接讀取緩存，避免索引IO掃描開銷。

4.3.二、索引構建

爲了支持每秒千萬的實時數據寫入，避免同步構建索引影響實時寫入的性能，AnalyticDB並無採用同步構建索引的策略，而是採用異步後臺進程構建索引的方式。索引引擎會根據時間或增量數據的大小來決定是否啓動後臺進程來構建索引。該後臺進程讀取Pangu上的歷史全量數據和新寫入的增量日誌數據，完成數據合併造成新的全量數據，並對該全量數據從新構建索引。該過程經過伏羲的MapReduce任務執行，選擇負載較低的機器執行，對用戶徹底透明。

五、 AnalyticDB計算層設計

5.一、優化器

AnalyticDB綜合了CBO（基於代價估算）和RBO（基於規則）的優化模型來爲實時在線分析提供最優的計劃。優化規則的豐富程度是可否產生最優計劃的一個重要指標。由於只有可選方案足夠多時，纔有可能選到最優的執行計劃。AnalyticDB提供了豐富的關係代數轉換規則，用來確保不會遺漏最優計劃。

• 基礎優化規則
  1） 裁剪規則：列裁剪、分區裁剪、子查詢裁剪

2） 下推／合併規則：謂詞下推、函數下推、聚合下推、Limit下推
3） 去重規則：Project去重、Exchange去重、Sort去重
4） 常量摺疊／謂詞推導

• 探測優化規則
  1） Joins：BroadcastHashJoin、RedistributedHashJoin、NestLoopIndexJoin

2） Aggregate：HashAggregate、SingleAggregate
3） JoinReorder
4） GroupBy下推、Exchange下推、Sort下推

• 高級優化規則
  1） CTE

除了這些，咱們創新性引入了兩個關鍵功能：存儲感知的優化和高效實時採樣。

5.1.一、存儲感知的優化

執行下推。執行下推是將SQL中能夠依賴存儲能力的關係代數計算進行提取，將查詢計劃等價轉換爲兩部分，一部分在計算層執行，一部分下推給存儲層執行。因爲原有查詢計劃中並無明確的界限來分隔兩部分，所以須要依賴存儲層自己的計算能力，經過關係代數的等價轉換規則，將其分離。執行下推在不少分佈式數據庫中都有相似的實現，但下推算子的極致基本都是以單列條件的AND操做爲主，其餘算子如函數、JOIN等都在計算層實現。這主要是因爲其並未實現存儲層向上註冊計算能力的邏輯，默認認爲存儲層最多隻能作單列或者組合條件的過濾。

AnalyticDB引入了一種STARs模型做爲執行下推的框架，經過將異構數據源的執行能力按照關係代數的維度進行抽象，將存儲的能力特徵化爲其所能處理的關係代數的能力。在優化器完成初步的分佈式執行計劃後，利用動態規劃的方式針對不一樣的數據源將適合下推給存儲執行的關係代數算子進行封裝，轉化爲對應的存儲的API調用。

於此同時，STARs框架還加入了代價的計算，也就是說並不是簡單的依賴存儲的能力進行執行下推，而是在對其進行關係代數能力抽象的同時，對其執行的代價進行數值化。在進行動態規劃時，將代價和執行能力同時做爲參考因素，避免盲目的下推致使性能變差。

Join下推。數據重分佈是分佈式數據庫執行計劃區別於傳統數據庫執行計劃的一個重要方面，主要是因爲數據的物理分佈特性與關係代數的邏輯語義不匹配致使的。好比SQL：SELECT t.tid, count(*) FROM t JOIN s in t.sid = s.sid GROUP BY t.tid。其中t表按照tid進行Hash分區，s表按照sid進行Hash分區。其邏輯執行計劃以下：

基於規則的優化器。在生成Aggregation/Join的執行計劃時，會發現其下游節點並不符合當前算子對數據物理分佈特性的要求，所以會強制增長一個數據數據重分佈的算子來保證其執行語義的正確，數據重分佈帶來的物理開銷很是大，涉及到數據的序列化、反序列化、網絡開銷等等，所以避免屢次數據重分佈是對於分佈式計算是一個很是重要的優化。AnalyticDB的優化器能夠經過將全部可能的執行計劃進行展開，並對其進行代價計算。正是使用了這種方式，AnalyticDB實現了在不一樣的數據規模時，生成對應其數據特徵最優的執行計劃。

基於索引的Join和聚合 。將Join變爲查找現有索引，全索引的設計進一步消除了構建哈希開銷。當調整Join的順序時，若是大多數Join列是分區列且具備索引，優化器會避免使用BushyTree，而更傾向選擇LeftDeepTree。採用LeftDeepTree，AnalyticDB能更好地利用現有索引。優化器更近一步下推了謂詞和聚合。聚合函數，好比count和查詢過濾能夠直接基於索引計算。全部這些組合下降了查詢延遲，同時提升集羣利用率，從而使得AnalyticDB能輕鬆支持高併發。

5.1.二、高效實時採樣

統計信息是優化器在作基於代價查詢優化所需的基本信息，一般包括有關表、列和索引等的統計信息。傳統數據倉庫僅收集有限的統計信息，例如列上典型的最常值（MFV）。商業數據庫爲用戶提供了收集統計信息的工具，但這一般取決於DBA的經驗，依賴DBA來決定收集哪些統計數據，並依賴於服務或工具供應商。

上述方法收集的統計數據一般都是靜態的，它可能須要在一段時間後，或者當數據更改達到必定程度，來從新收集。可是，隨着業務應用程序變得愈來愈複雜和動態，預約義的統計信息收集可能沒法以更有針對性的方式幫助查詢。例如，用戶能夠選擇不一樣的聚合列和列數，其組合可能會有很大差別。可是，在查詢生成以前很難預測這樣的組合。所以，很難在統計收集時決定正確統計方案。可是，此類統計信息可幫助優化器作出正確決定。

咱們設計了一個查詢驅動的動態統計信息收集機制來解決此問題。守護程序動態監視傳入的查詢工做負載和特色以提取其查詢模式，並基於查詢模式，分析缺失和有益的統計數據。在此分析和預測之上，異步統計信息收集任務在後臺執行。這項工做旨在減小收集沒必要要的統計數據，同時使大多數即將到來的查詢受益。對於前面提到的聚合示例，收集多列統計信息一般很昂貴，尤爲是當用戶表有大量列的時候。根據咱們的動態工做負載分析和預測，能夠作到僅收集必要的多列統計信息，同時，優化器可以利用這些統計數據來估計聚合中不一樣選項的成本並作出正確的決策。

5.二、執行引擎

在優化器之下，AnalyticDB在MPP架構基礎上，採用流水線執行的DAG架構，構建了一個適用於低延遲和高吞吐量工做負載的執行器。AnalyticDB的列式執行引擎可以充分利用底層的行列混合存儲。與行式執行引擎相比，當前的向量化執行引擎更加緩存友好，能避免將沒必要要的數據加載到內存中。

與許多 OLAP 系統同樣，AnalyticDB在運行時利用代碼生成器（CodeGen） 來提升 CPU 密集型計算的性能。AnalyticDB的CodeGen基於 ANTLR ASM來動態生成表達式的代碼樹。同時此 CodeGen 引擎還將運行時因素歸入考慮，讓AnalyticDB能在Task級別利用異構新硬件的能力。例如，若是集羣中CPU支持 AVX-512指令集，咱們經過生成字節碼使用SIMD來提升性能。在此以外，經過整合內部數據表示形式，在存儲層和執行引擎之間，AnalyticDB是可以直接對序列化二進制數據進行操做，而不是Java 對象。這有助於消除序列化和去序列化的開銷，這在大數據量shuffle時可能會節約20%以上的時間。

六、 實驗數據展現

6.一、實驗準備

1. 實驗環境。實驗運行在一個擁有八臺機器的集羣環境上，天天機器配置爲Intel Xeon Platinum 8163 CPU (@2.50GHz)、300GB內存、3TB SSD和萬兆網卡。集羣上分配了一個擁有4個協調節點、4個寫節點、32個讀節點的AnalyticDB實例。
2. 實驗測試集。實驗選擇了兩種測試集：一個是阿里巴巴集團內部產生的真實數據集，分別爲1TB和10TB大小；一個是標準TPC-H測試集。
3. 查詢語句。針對真實數據集，選擇了三種類型的查詢語句，如表1所示，它們分別爲全表掃描、點查詢、多表關聯查詢。

表1 真實數據集上的三種類型查詢

6.二、實驗數據

真實數據集。圖14展現了AnalyticDB在真實數據集上運行三種查詢語句的性能。

如圖所示，得益於全索引設計和行列混存存儲模式，AnalyticDB都可以在秒級甚至更短的時間內完成三種類型的查詢語句。對於任意一種查詢，AnalyticDB都可以精準定位到對應的一級分區或二級分區，並進行索引篩選，從而避免無效、大量的全表數據掃描。也正是由於AnalyticDB能快速定位、掃描有效數據，1TB和10TB數據量的查詢性能差異不大，也即AnalyticDB的性能受數據表大小影響有限。

TPC-H數據集。圖15展現了AnalyticDB在1TB TPC-H數據集下的性能，同時還和PrestoDB、Spark-SQL、Greenplum進行了對比。得益於流水線處理、全列索引、行列混存、運行時索引路徑選擇、K路歸併、向量化執行引擎、CodeGen等優化機制，AnalyticDB得到了最優的TCP-H測試運行時間，並比第二好的Greenplum快了近2倍。

---

本文做者：Roin

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。