前言
一年一度的資料庫領域頂級會議VLDB 2019于美國當地時間8月26日-8月30日在洛杉矶召開。在本屆大會上，阿裡雲資料庫産品團隊多篇論文入選Research Track和Industrial Track。
本文将對入圍Industrial Track的論文《AnalyticDB: Realtime OLAP Database System at Alibaba
Cloud》進行深度解讀。
1、背景
随着資料量的快速增長，越來越多的企業迎來業務資料化時代，資料成為了最重要的生産資料和業務更新依據。伴随着業務對海量資料實時分析的需求越來越多，資料分析技術這兩年也迎來了一些新的挑戰和變革：
1) 線上化和高可用、離線和線上的邊界越來越模糊，一切資料皆服務化、一切分析皆線上化；
2) 高并發低延時，越來越多的資料系統直接服務終端客戶，對系統的并發和處理延時提出了新的互動性挑戰；
3) 混合負載，一套實時分析系統既要支援資料加工處理，又要支援高并發低延時的互動式查詢；
4) 融合分析，随着對資料新的使用方式探索，需要解決結構化與非結構化資料融合場景下的資料檢索和分析問題。
圖1 阿裡巴巴分析型資料庫發展曆史
阿裡巴巴最初通過單節點Oracle進行準實時分析, 後來轉到Oracle RAC。随着業務的飛速發展, 集中式的Shared Storage架構需要快速轉向分布式，遷移到了Greenplum，但不到一年時間便遇到擴充性和并發的嚴重瓶頸。為了迎接更大資料集、更高并發、更高可用、更實時的資料應用發展趨勢，從2011年開始，線上分析這個技術領域，阿裡實時資料庫堅定的走上了自研之路。大規模、海量資料實時分析型資料庫系統——AnalyticDB，也是在這個時候誕生。
AnalyticDB是阿裡巴巴自主研發、唯一經過超大規模、高并發以及核心業務驗證的PB級實時分析型資料庫。自2012年第一次在集團釋出上線以來，至今已累計疊代釋出近百個版本，支撐起集團内的電商、廣告、菜鳥、文娛、飛豬等衆多線上分析業務。AnalyticDB于2014年在阿裡雲開始正式對外輸出，支撐行業既包括傳統的大中型企業和政府機構，也包括衆多的網際網路公司，覆寫外部十幾個行業。AnalyticDB承接着阿裡巴巴廣告營銷、商家資料服務、菜鳥物流、盒馬新零售等衆多核心業務的高并發分析處理，每年雙十一上述衆多實時分析業務高峰驅動着AnalyticDB不斷的架構演進和技術創新。
圖2 AnalyticDB設計挑戰
2、挑戰
已有的分析型資料庫（以下簡稱OLAP）諸如Impala、Pinot、Druid等，總結了OLAP系統在設計的過程中應該解決的問題：低延遲、資料新鮮度、多樣性、低成本、高擴充性、高可靠性。和這些已有的OLAP系統相比，AnalyticDB承載着更大的規模：2000+台實體機器、10PB+規模資料、百萬張資料表以及萬億條資料行。是以，AnalyticDB在設計與實作的時候，不僅要解決已有OLAP系統要解決的問題，還要面臨與解決三個更大的挑戰：
1） 随着使用者分析需求的急劇增加，使用者的查詢變得複雜且多樣化：這些查詢涵蓋點查詢、全表掃描、多表關聯等，還會包含對任意列組合的篩選條件。如何在這種複雜分析場景下依然保證大部分甚至所有查詢的低延遲，是一個非常大的挑戰；
2） 如何在保證低延遲查詢的情況下，仍然能處理每秒千萬級别的寫吞吐。傳統的設計理念在同一條鍊路上同時處理讀寫請求，這會造成讀寫性能的互相嚴重影響。
3） 複雜分析場景下，會對行存、列存、關系型存儲、複雜資料類型（JSON、vector、text）都有着強烈需求。如何設計一個對這些存儲格式都很友好的存儲層，也是一個業界難題。
接下來我們會介紹AnalyticDB的設計與實作關鍵點，探究AnanlyticDB是如何解決這些挑戰的。
3、 AnalyticDB架構
AnalyticDB的整體架構如下圖：
圖3 AnalyticDB架構圖
每個子產品的具體描述如下：
- Coordinator（協調節點）：協調節點負責接收JDBC/ODBC連接配接發過來的請求，并将請求分發給讀節點或者寫節點。
- Write Node（寫節點）：隻處理寫請求（如INSERT、DELETE、UPDATE）的節點。
- Read Node（讀節點）：隻處理讀請求（如SELECT）的節點。
- Pangu（盤古）：高可靠分布式存儲系統，是AnalyticDB依賴的基礎子產品。寫節點會将寫請求的資料刷到盤古上進行持久化。
- Fuxi（伏羲）：資源管理與任務排程系統，是AnalyticDB依賴的基礎子產品。伏羲合理使用叢集機器的空閑資源，以進行相關計算任務的異步排程執行。
3.1、表分區
為便于大規模分析處理，AnalyticDB對資料表進行分區。AnalyticDB資料表有兩個分區級别：一級分區和二級分區。圖4展示了建立帶有一級分區、二級分區表的DDL語句：一級分區有50個分區，分區鍵為id列；二級分區有12個分區，分區鍵為dob列。資料行依據其包含的一級分區鍵的hash值，對應到不同的一級分區。通常，選擇具有較高基數（cardinality）的列作為一級分區鍵，以保證資料行能均勻地分布到每個一級分區，最大化并行。使用者還可以根據需要定義二級分區，以便進行資料的自動管理。二級分區擁有最大分區數，當二級分區的實際數目超過了這個最大分區數後，最老的二級分區會被自動删除。通常，選擇時間列（天、周或月）作為二級分區列，這樣，包含相同時間序列的資料行，會被劃分到同一個二級分區中。
圖4 建立帶有分區的資料表的DDL
3.2、讀寫分離
傳統OLAP系統在同一個鍊路上同時處理讀寫請求，是以，所有的并發讀寫請求都共享同一個資源池，也會互相影響。但是當讀寫并發同時非常大時，這種設計會由于過度的資源競争而導緻不好的性能。如圖5所示，為了解決這個問題，同時確定讀和寫的高性能，AnalyticDB采用的架構為讀寫分離架構，即AnalyticDB有獨立的讀寫節點各自處理讀寫請求，且寫節點和讀節點完全互相隔離。
圖5 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.3、可靠性與擴充性
-
可靠性。
AnalyticDB的讀節點和寫節點均具有高可靠性。對于寫節點來說，當某個從節點失效的時候，主節點會将其負責的一級分區均勻地配置設定給其他正常的從節點。當主節點失效的時候，新的主節點會被重新選出來進行替代。對于讀節點來說，使用者可以指定讀節點的副本個數（預設為2），不同副本會被放到不同的實體機上，以提供高可靠性。當某個讀節點失效時，協調節點會将讀請求自動下發到其他副本上。需要強調的是，某個寫節點的失效，也不會影響讀節點正常地拉取log資料和replay資料。因為log資料是持久化在盤古上的，在寫節點失效地時候，讀節點可以直接去盤古上拉取log資料。
-
擴充性。
AnalyticDB的讀節點和寫節點也具有高可擴充性。當一個新的寫節點加入時，主節點會自動調整一級分區的配置設定，保證負載均衡。讀節點的可擴充性也是由相同的機制保證的，隻不過對于讀節點，調整一級分區配置設定的是協調節點。
3.4、叢集管理
AnalyticDB叢集管理模式為多租戶模式，即同一個叢集上可以運作多個AnalyticDB執行個體。我們設計并實作了一個稱為Gallardo的叢集管理元件，Gallardo采用CGroup技術對不同AnalyticDB執行個體進行資源隔離（CPU核、記憶體、網絡帶寬），并負責執行個體的穩定性。當新的AnalyticDB執行個體建立的時候，Gallardo會為其配置設定相應的資源，在配置設定資源的時候，Gallardo會将協調節點、寫節點、讀節點以及讀節點的不同副本放置在不同實體機上，以保證可靠性要求。
4、 AnalyticDB存儲層設計
AnalyticDB存儲圍繞為“計算而生” 這一設計目标，主要解決海量資料的極速查詢問題。本章将詳細剖析存儲和索引原理，并闡述設計背後的思考。
4.1、存儲層架構
AnalyticDB存儲層采用Lambda架構，讀節點上的資料包括基線資料和增量資料兩部分。如圖6左邊所示，基線資料是增量寫入前的所有曆史資料，包括索引和明細資料；增量資料沒有索引，隻有明細資料。明細資料來自于寫入節點的日志資料，并按照行列混存的結構（見4.2節）儲存在讀節點的SSD磁盤上。
圖6 Lamda架構和資料查詢過程
4.1.1、寫入和查詢過程
AnalyticDB不僅支援實時INSERT，同時還支援UPDATE和DELETE。執行DELTE時，AnalyticDB沒有采用立即實體删除，而是使用bitset來标記被删除的資料行，這些被标記删除的資料會在資料合并（4.1.2）時被真正實體删除。執行UPDATE時，UPDATE操作會被轉換為DELETE + INSERT。COPY-ON-WRITE技術被用來支援MVCC多版本控制。當資料發生删除或更新時，AnalyticDB會産生一個新版本的bitset，并将被删除後更新的行的位設定1。此時正在運作的查詢可以繼續使用老版本的delete bitset，不會被寫入阻塞。
算法1、2、3分别詳細解釋了INSERT、DELETE和QUERY執行的詳細過程。
4.1.2、資料合并
由于沒有全局索引，随着資料的不斷實時寫入，增量資料的查詢性能會越來越慢。是以我們會在背景通過伏羲啟動一個MapReduce 任務來合并基線資料和增量資料（同時去掉标記為删除的資料）形成一個新的基線資料，并基于新的基線資料建構全量索引。如圖7所示，當資料合并任務開始時，首先會将增量資料引擎标記為immutable，并建立一個新的活躍增量資料引擎，該活躍增量資料引擎接受實時寫入的資料。在合并任務執行過程中，所有查詢和INSERT/DELETE都會執行在基線資料、immutable增量資料和活躍增量資料這三個資料引擎上。當合并任務完成後，老的基線資料和immutable增量資料會被替換為新的基線資料，新的查詢将執行在新基線資料和活躍增量資料這兩個資料引擎上。等所有老的查詢都結束後，老基線資料和immutable增量資料會被删除。
圖7 資料合并過程
4.2、存儲資料結構
4.2.1、行列混存
在海量資料分析場景下，資料分析業務主要有以下三類workload：
1） OLAP場景下的大規模多元分析：海量資料的統計分析和多表關聯，比較适合列存格式；
2） 高并發的點查：通常需要撈取出一整行的明細資料，比較适合行存。
3） 高寫入吞吐：每秒千萬的高吞吐實時寫入，比較适合行存。
無論是行存和列存都無法同時滿足以上需求，如何在一個系統中同時解決以上問題？如圖8所示，AnalyticDB提出使用行列混存 結構，使用一套存儲格式，兼具行存和列存之所長，同時滿足以上三類workload。
圖8 行列混存資料格式
對于一張表，每k行資料組成一個Row Group。在每個Row Group中，每列資料連續的存放在單獨的block中，Row Group在磁盤上連續存放。每個block由于資料類型相同，可以支援高效的壓縮。同時為了保證點查詢的性能，我們會将所有的資料按照按指定列(聚集列)排序存放，好處是在按該列查詢時顯著減少磁盤随機IO次數。最後，與列存寫入相比，行列混存可以把多個檔案的寫入被轉化成單個檔案的順序寫入，降低了IO的開銷。
4.2.2、中繼資料
為了加速查詢，AnalyticDB對每列建構一份中繼資料，并儲存在一個叫detail_meta的單獨檔案中。detail_meta檔案通常較小（小于1MB），首次查詢時被加載在記憶體中。如圖8左邊所示，中繼資料主要包括4部分：
- Header。包括版本号，檔案長度以及一些統計資訊。
- 列統計資訊。包括行數，NULL值數，cardinality，SUM，MAX和MIN 值。優化器根據這些資訊來生成最佳執行計劃。
- 字典。對于cardinality較少（小于1024）的列，AnalyticDB采用字典編碼，資料檔案裡儲存字典号碼。字典儲存在該字段中。
- 塊位址資訊。儲存塊号到資料檔案起始位址和長度的映射關系。
4.2.3、非結構化資料存儲
AnalyticDB不僅支援基本資料類型，也支援長文本、JSON和向量數組等非結構化資料類型。但是單行文本、JSON、向量資料的長度通常比基本資料類型的資料要長，單行長達數十KB甚至MB級别。基于固定行數的block設計會導緻單個block過大，IO效率降低。是以針對非結構化資料類型，AnalyticDB采用了定長資料塊技術，每個塊大小相同。
如圖9所示，每個Block由多個定長資料塊（稱作FBlock）組成，每個FBlock大小為32KB，單獨存儲為一個檔案中。Block中儲存的不再是原始資料内容，而是資料所在FBlock的塊号和FBlock内的偏移位置。查詢時，首先讀取Block中的内容，得到FBlock的塊号和塊内偏移，然後再讀取FBlock内容，得到非結構化資料内容。
圖9 定長資料塊格式
4.3、索引管理
索引是資料庫系統裡影響性能最關鍵元件，但是傳統的索引并不能很好滿足OLAP場景下任意ad-hoc查詢的需求。例如B+Tree索引，在海量資料下存在中間節點過多，容易産生大量随機IO等問題；Druid可以對多列資料建構反向索引，但是隻能支援特定資料類型（字元串類型，不支援數值類型）； 傳統資料庫建構索引占用大量資源，影響寫入性能；現有的索引也不支援非結構化資料類型，例如JSON，長文本和向量。
是以，AnalyticDB設計和實作了一個新的索引引擎，在不影響寫入性能的情況下，支援結構化和非結構化資料類型索引。它将建構過程從寫傳入連結路中移除，采用背景異步構模組化式，支援對所有列建構索引，進而解決了OLAP任意查詢的性能問題。
4.3.1、索引查詢
AnalyticDB預設對所有列建構索引，并儲存在一個單獨的檔案中。與傳統的資料庫不同，AnalyticDB索引中的key是列的值，value是該值出現的所有行号集合，并支援所有的條件同時走索引查詢。如圖10所示，該SQL是一個複雜查詢包括結構化列條件和非結構化列條件。索引引擎會首先對每個條件走索引掃描，得到多個行号集合，然後将AND/OR 條件轉換為行号集合的UNION/INTESECT操作。
圖10 索引查詢示例
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.2、索引建構
為了支援每秒千萬的實時資料寫入，避免同步建構索引影響實時寫入的性能，AnalyticDB并沒有采用同步建構索引的政策，而是采用異步背景程序建構索引的方式。索引引擎會根據時間或增量資料的大小來決定是否啟動背景程序來建構索引。該背景程序讀取Pangu上的曆史全量資料和新寫入的增量日志資料，完成資料合并形成新的全量資料，并對該全量資料重新建構索引。該過程通過伏羲的MapReduce任務執行，選擇負載較低的機器執行，對使用者完全透明。
5、 AnalyticDB計算層設計
5.1、優化器
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.1、存儲感覺的優化
執行下推。執行下推是将SQL中可以依賴存儲能力的關系代數計算進行提取，将查詢計劃等價轉換為兩部分，一部分在計算層執行，一部分下推給存儲層執行。由于原有查詢計劃中并沒有明确的界限來分隔兩部分，是以需要依賴存儲層本身的計算能力，通過關系代數的等價轉換規則，将其分離。執行下推在很多分布式資料庫中都有類似的實作，但下推算子的極緻基本都是以單列條件的AND操作為主，其他算子如函數、JOIN等都在計算層實作。這主要是由于其并未實作存儲層向上注冊計算能力的邏輯，預設認為存儲層最多隻能做單列或者組合條件的過濾。
AnalyticDB引入了一種STARs模型作為執行下推的架構，通過将異構資料源的執行能力按照關系代數的次元進行抽象，将存儲的能力特征化為其所能處理的關系代數的能力。在優化器完成初步的分布式執行計劃後，利用動态規劃的方式針對不同的資料源将适合下推給存儲執行的關系代數算子進行封裝，轉化為對應的存儲的API調用。
圖11 STARs模型
于此同時，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實作了在不同的資料規模時，生成對應其資料特征最優的執行計劃。
圖12 Aggregation/Join執行計劃産生
基于索引的Join和聚合 。将Join變為查找現有索引，全索引的設計進一步消除了建構哈希開銷。當調整Join的順序時，如果大多數Join列是分區列且具有索引，優化器會避免使用BushyTree，而更傾向選擇LeftDeepTree。采用LeftDeepTree，AnalyticDB能更好地利用現有索引。優化器更近一步下推了謂詞和聚合。聚合函數，比如count和查詢過濾可以直接基于索引計算。所有這些組合降低了查詢延遲，同時提高叢集使用率，進而使得AnalyticDB能輕松支援高并發。
圖13 基于索引的Join優化
5.1.2、高效實時采樣
統計資訊是優化器在做基于代價查詢優化所需的基本資訊，通常包括有關表、列和索引等的統計資訊。傳統資料倉庫僅收集有限的統計資訊，例如列上典型的最常值（MFV）。商業資料庫為使用者提供了收集統計資訊的工具，但這通常取決于DBA的經驗，依賴DBA來決定收集哪些統計資料，并依賴于服務或工具供應商。
上述方法收集的統計資料通常都是靜态的，它可能需要在一段時間後，或者當資料更改達到一定程度，來重新收集。但是，随着業務應用程式變得越來越複雜和動态，預定義的統計資訊收集可能無法以更有針對性的方式幫助查詢。例如，使用者可以選擇不同的聚合列和列數，其組合可能會有很大差異。但是，在查詢生成之前很難預測這樣的組合。是以，很難在統計收集時決定正确統計方案。但是，此類統計資訊可幫助優化器做出正确決定。
我們設計了一個查詢驅動的動态統計資訊收集機制來解決此問題。守護程式動态監視傳入的查詢工作負載和特點以提取其查詢模式，并基于查詢模式，分析缺失和有益的統計資料。在此分析和預測之上，異步統計資訊收集任務在背景執行。這項工作旨在減少收集不必要的統計資料，同時使大多數即将到來的查詢受益。對于前面提到的聚合示例，收集多列統計資訊通常很昂貴，尤其是當使用者表有大量列的時候。根據我們的動态工作負載分析和預測，可以做到僅收集必要的多列統計資訊，同時，優化器能夠利用這些統計資料來估計聚合中不同選項的成本并做出正确的決策。
5.2、執行引擎
在優化器之下，AnalyticDB在MPP架構基礎上，采用流水線執行的DAG架構，建構了一個适用于低延遲和高吞吐量工作負載的執行器。AnalyticDB的列式執行引擎能夠充分利用底層的行列混合存儲。與行式執行引擎相比，目前的向量化執行引擎更加緩存友好，能避免将不必要的資料加載到記憶體中。
圖14 流水線模式執行引擎
與許多 OLAP 系統一樣，AnalyticDB在運作時利用代碼生成器（CodeGen） 來提高 CPU 密集型計算的性能。AnalyticDB的CodeGen基于 ANTLR ASM來動态生成表達式的代碼樹。同時此 CodeGen 引擎還将運作時因素納入考慮，讓AnalyticDB能在Task級别利用異構新硬體的能力。例如，如果叢集中CPU支援 AVX-512指令集，我們通過生成位元組碼使用SIMD來提高性能。在此之外，通過整合内部資料表示形式，在存儲層和執行引擎之間，AnalyticDB是能夠直接對序列化二進制資料進行操作，而不是Java 對象。這有助于消除序列化和去序列化的開銷，這在大資料量shuffle時可能會節約20%以上的時間。
6、 實驗資料展示
6.1、實驗準備
- 實驗環境。實驗運作在一個擁有八台機器的叢集環境上，每天機器配置為Intel Xeon Platinum 8163 CPU (@2.50GHz)、300GB記憶體、3TB SSD和萬兆網卡。叢集上配置設定了一個擁有4個協調節點、4個寫節點、32個讀節點的AnalyticDB執行個體。
- 實驗測試集。實驗選擇了兩種測試集：一個是阿裡巴巴集團内部産生的真實資料集，分别為1TB和10TB大小；一個是标準TPC-H測試集。
- 查詢語句。針對真實資料集，選擇了三種類型的查詢語句，如表1所示，它們分别為全表掃描、點查詢、多表關聯查詢。
表1 真實資料集上的三種類型查詢
6.2、實驗資料
真實資料集。圖14展示了AnalyticDB在真實資料集上運作三種查詢語句的性能。
圖15 1TB和10TB資料量的查詢延遲
如圖所示，得益于全索引設計和行列混存存儲模式，AnalyticDB均可以在秒級甚至更短的時間内完成三種類型的查詢語句。對于任意一種查詢，AnalyticDB均可以精準定位到對應的一級分區或二級分區，并進行索引篩選，進而避免無效、大量的全表資料掃描。也正是因為AnalyticDB能快速定位、掃描有效資料，1TB和10TB資料量的查詢性能差别不大，也即AnalyticDB的性能受資料表大小影響有限。
圖16 TPC-H性能
TPC-H資料集。圖15展示了AnalyticDB在1TB TPC-H資料集下的性能，同時還和PrestoDB、Spark-SQL、Greenplum進行了對比。得益于流水線處理、全列索引、行列混存、運作時索引路徑選擇、K路歸并、向量化執行引擎、CodeGen等優化機制，AnalyticDB獲得了最優的TCP-H測試運作時間，并比第二好的Greenplum快了近2倍。