Arrow在分布式查詢引擎中的應(yīng)用與研究

張世同

(北京云至科技有限公司南京分公司，數(shù)據(jù)服務(wù)產(chǎn)品研發(fā)部，南京 211801)

0 引言

近年來，大數(shù)據(jù)技術(shù)領(lǐng)域列式存儲成為主流，現(xiàn)代CPU技術(shù)借助流水線技術(shù)、SIMD(Single Instruction Multiple Data)指令、向量計算，大幅提升處理性能。內(nèi)存越來越廉價，借助內(nèi)存提升性能成為可能。數(shù)據(jù)來源復(fù)雜，數(shù)據(jù)格式多樣化，出現(xiàn)了復(fù)雜、嵌套數(shù)據(jù)格式。用戶對數(shù)據(jù)處理效率的要求日益迫切。

以Presto、Drill、Impala、Kylin為代表的查詢引擎采用MPP技術(shù)，使用SQL的方式，對底層異構(gòu)的大數(shù)據(jù)存儲進行訪問。未來查詢引擎向數(shù)據(jù)發(fā)現(xiàn)、數(shù)據(jù)治理、自助服務(wù)的方向發(fā)展，即讓業(yè)務(wù)人員在無IT人員的參與下，可以順利工作，從繁雜的原始數(shù)據(jù)中，發(fā)現(xiàn)數(shù)據(jù)、聚合數(shù)據(jù)、形成高質(zhì)量的數(shù)據(jù)、發(fā)布數(shù)據(jù)服務(wù)。這時，查詢引擎的查詢、更新性能就變得尤為重要。

本文介紹了一種基于MPP和Arrow內(nèi)存列存儲的數(shù)據(jù)查詢引擎ADE(Agile Data Engine)的設(shè)計和實現(xiàn)，ADE有效提升了查詢引擎本身的性能和跨系統(tǒng)數(shù)據(jù)通訊效率，再結(jié)合預(yù)計算和SQL重寫技術(shù)能夠滿足OLAP場景下常規(guī)查詢和即席查詢(1)常規(guī)查詢在系統(tǒng)設(shè)計時是已知的，可以事先通過建立索引、分區(qū)等技術(shù)來優(yōu)化。而即席(ad-hoc)查詢是用戶在使用時臨時產(chǎn)生的，系統(tǒng)無法預(yù)先優(yōu)化這些查詢，所以即席查詢也是一個重要指標(biāo)的需求。

1 研究現(xiàn)狀

1.1 分布式查詢引擎的現(xiàn)狀

分布式查詢引擎的興起，起源于Google的Dremel，隨后Cloudera開源了大數(shù)據(jù)查詢分析引擎Impala，F(xiàn)acebook開源了Presto，Hortonworks開源了Stringer，Apache基于Hadoop原生SQL的HAWQ[9]，國內(nèi)的Kylin、Druid等。Apache基金會的頂級項目Drill是業(yè)界比較接受的Dremel的開源實現(xiàn)。文獻[5]將這些分布式查詢引擎分為基于預(yù)計算思想的計算引擎和實時計算引擎兩類。

基于預(yù)計算思想的計算引擎，通過提前的聚合存儲操作，通過SQL重寫技術(shù)把一個計算任務(wù)轉(zhuǎn)換成查詢操作，本質(zhì)上減少計算量，如Kylin[15]。該類查詢引擎的缺點：①立方體的構(gòu)建具有維度爆炸問題，無論對計算能力還是存儲能力都提出了挑戰(zhàn)。②由于數(shù)據(jù)查詢分析分布具有聚集性，所以，立方體中的大量club從來沒有使用過，浪費了計算資源和存儲資源。所以對該類查詢引擎的研究，主要是立方體物化策略的研究[5]。

實時計算引擎，每次查詢都需要對數(shù)據(jù)進行聚合計算，所以實時性并不是很高不能達到實時的標(biāo)準(zhǔn)[5]。對該類引擎的研究，主要集中在優(yōu)化執(zhí)行計劃和存儲，如位圖索引、列式存儲[1，3]、查詢計劃優(yōu)化[2，6]等。查詢計劃優(yōu)化研究，目前有基于規(guī)則、成本、運行時的查詢計劃優(yōu)化以及基于算法的查詢優(yōu)化等。

1.2 內(nèi)存列式存儲的現(xiàn)狀

目前內(nèi)存數(shù)據(jù)庫已經(jīng)成熟，常見的內(nèi)存數(shù)據(jù)庫有SAP-HANA[18]、Ignite、Geode等。SAP-HANA支持行存儲和列存儲，而Ignite和Geode都是以Key-Value格式存儲。它們在分布式內(nèi)存網(wǎng)絡(luò)方面，都已經(jīng)有了成熟的實現(xiàn)和應(yīng)用。

在大數(shù)據(jù)MPP計算領(lǐng)域，列存儲也已經(jīng)普遍，如文件列存儲格式Parquet、Avro等；內(nèi)存列存儲格式如SAP-HANA、Spark、Drill等都在應(yīng)用。但是目前內(nèi)存列存儲格式還由各軟件自行定義和進行內(nèi)存管理，沒有統(tǒng)一的格式標(biāo)準(zhǔn)和讀寫接口，這就意味著跨系統(tǒng)數(shù)據(jù)傳輸時，避免不了數(shù)據(jù)序列化反序列化操作。

紐約大學(xué)的Pilaf[16]和微軟研究院的FaRM[17]采用RDMA(Remote Direct Memory Access)技術(shù)，實現(xiàn)內(nèi)部節(jié)點之間的數(shù)據(jù)通訊和整個分布式系統(tǒng)對外共享內(nèi)存讀寫接口，較少序列化反序列化，極大提高效率。

Arrow內(nèi)存列存儲就是為了解決當(dāng)前內(nèi)存列存儲無標(biāo)準(zhǔn)的問題，它為內(nèi)存列存儲格式和數(shù)據(jù)讀寫接口提供了標(biāo)準(zhǔn)，并已經(jīng)實現(xiàn)了C++、Go、Java、Python、R、Ruby和Rust等多種編程語言，可以有效提升查詢引擎的效率又可以實現(xiàn)跨系統(tǒng)數(shù)據(jù)傳輸，而無需進行數(shù)據(jù)序列化反序列化。

2 Arrow技術(shù)基礎(chǔ)

Arrow是跨語言、跨平臺的內(nèi)存列式存儲格式。具備傳統(tǒng)列式存儲的優(yōu)勢，同時具有內(nèi)存數(shù)據(jù)快速訪問、復(fù)雜格式、內(nèi)存網(wǎng)格化的優(yōu)勢。Arrow具備以下特征：①充分利用現(xiàn)代高性能CPU的SIMD指令，支持向量計算。②利用內(nèi)存緩存區(qū)， 線性緊湊定義數(shù)據(jù)結(jié)構(gòu)，提高Cache命中率和CPU讀取數(shù)據(jù)效率。③統(tǒng)一內(nèi)存格式，避免或減少異構(gòu)系統(tǒng)之間序列化反序列化。④利用共享內(nèi)存或者直接內(nèi)存訪問，實現(xiàn)zero-copy。⑤支持復(fù)雜數(shù)據(jù)Schema和動態(tài)Schema。⑥易于采用內(nèi)存網(wǎng)格化技術(shù)，實現(xiàn)分布式內(nèi)存計算，大幅提高性能。

2.1 Arrow內(nèi)存布局

Arrow內(nèi)存結(jié)構(gòu)支持基本類型(固定長度)、可變長度二進制、固定長度List、可變長度List、結(jié)構(gòu)體類型、稀疏聯(lián)合類型、Null類型、字典類型等。這些指的是物理存儲類型，所有邏輯數(shù)據(jù)類型，均使用這些物理存儲類型設(shè)計。邏輯類型為整型、長整型、日期類型、字符串類型等。

圖1 Int32的向量內(nèi)存布局

Int32向量的內(nèi)存布局如圖1所示，元數(shù)據(jù)記錄向量長度、空值個數(shù)，理論最多可以存儲231-1元素。Bitmap位圖，記錄非空值索引，例如示例中有效bitmap為1字節(jié)，字節(jié)長度對齊為64字節(jié)(2)64字節(jié)對齊，取決于IntelCPU AVX-512指令集特點，對512位64字節(jié)提供更高的性能。。

is_valid[j]->bitmap[j/8]&(1<<(j%8))

(1)

判斷位置j是否為有效值is_valid為公式(1)：內(nèi)存緩沖區(qū)是一段連續(xù)的內(nèi)存區(qū)，按照64字節(jié)長度對齊。對于空值，不分配字節(jié)值。

圖2 字符串向量內(nèi)存布局

字符串類型的向量內(nèi)存布局使用可變長度List物理內(nèi)存結(jié)構(gòu)。如圖2所示，字符串向量通過嵌套格式，在Char數(shù)組上增加offset偏移量索引實現(xiàn)。Null和[]同樣記錄索引和前一個相等。Bitmap、Offset buffer和內(nèi)存緩沖區(qū)均補齊64字節(jié)。字符開始位置slot_position計算為公式(2)；字符串長度slot_length計算公式(3)。

slot_position=offsets[j]

(2)

slot_length=offsets[j+1]-offsets[j]

(3)

有些屬性列是關(guān)聯(lián)字典，重復(fù)存儲造成空間浪費、影響檢索性能?？梢栽O(shè)計成字典類型、通過Int32索引引用字典值。

2.2 Arrow內(nèi)存模型

Arrow 基于NettyJEMalloc實現(xiàn)了內(nèi)存分配器Allocator，它基于數(shù)據(jù)塊分配器內(nèi)存。整個內(nèi)存結(jié)構(gòu)呈樹型結(jié)構(gòu)，如圖3所示。

圖3 內(nèi)存分配器(Allocator)的樹型結(jié)構(gòu)

樹型結(jié)構(gòu)的內(nèi)存分配器(Allocators)，有利于分功能分配、管理、檢測、回收部分內(nèi)存區(qū)。每個內(nèi)存分配器有預(yù)留容量(可用于計算)和最大容量。預(yù)留容量不會被數(shù)據(jù)占用，這意味著整個生命周期中都是被計算分配的。Arrow向量數(shù)組使用Off-heap堆外內(nèi)存。手工管理和釋放內(nèi)存區(qū)，不依賴于GC。內(nèi)存負(fù)載管理，檢測內(nèi)存溢出風(fēng)險、檢測內(nèi)存分配器的使用情況，決定是否寫入部分?jǐn)?shù)據(jù)到磁盤。每個查詢計劃Operator都創(chuàng)建了一個Allocator，它還可以創(chuàng)建自己的子Allocator，用于對該Operator內(nèi)的每個數(shù)據(jù)分片進行處理。

2.3 Arrow數(shù)據(jù)傳輸格式

Arrow 以Batch的方式，封裝數(shù)據(jù)及其模式進而進行數(shù)據(jù)傳輸。即用Batch的方式把一定數(shù)量的數(shù)據(jù)記錄(包括所有屬性列)及其Schema封裝在Record Batch中。有Dictionary Batch和Record Batch兩種形式。數(shù)據(jù)傳輸?shù)腗essage邏輯結(jié)構(gòu)如圖4。

圖4 數(shù)據(jù)傳輸Message邏輯結(jié)構(gòu)

數(shù)據(jù)模式(Schema)定義了數(shù)據(jù)的邏輯結(jié)構(gòu)，屬性邏輯類型，指定了屬性的字典類型編碼。字典類型Batch，把字典屬性進行編碼存儲，記錄中僅存儲字典編碼。記錄類型Batch分屬性向量存儲實際數(shù)據(jù)。

以記錄類型Batch為例，其數(shù)據(jù)分為：數(shù)據(jù)頭、各屬性的bitmap區(qū)、offsets區(qū)、數(shù)據(jù)區(qū)。其中數(shù)據(jù)頭記錄該batch的類型(Dictionary batch、Record batch、Schema)，各屬性向量的長度和空值個數(shù)，各屬性向量的內(nèi)存地址。一個屬性向量占用連續(xù)的物理內(nèi)存，整個Batch在網(wǎng)絡(luò)傳輸時，連續(xù)字節(jié)傳輸。一個Batch中可以存儲 1-64K條數(shù)據(jù)記錄。

3 ADE架構(gòu)設(shè)計與關(guān)鍵技術(shù)

ADE包含Coordinator、Executor兩個角色，兩者通過zookeeper協(xié)調(diào)。Zookeeper記錄了Coordinator和Executor的節(jié)點名稱、IP、內(nèi)存、CPU等信息。Coordinator負(fù)責(zé)接收用戶端SQL請求、解析SQL語法樹、生成Logic Plan、獲取并存儲數(shù)據(jù)表的元數(shù)據(jù)、分配Executor節(jié)點、執(zhí)行每個分區(qū)數(shù)據(jù)的Logic Plan，并匯總SQL結(jié)果返回給客戶端。Executor負(fù)責(zé)執(zhí)行在每個分區(qū)數(shù)據(jù)的Logic Plan，發(fā)送結(jié)果數(shù)據(jù)給Coordinator。Coordinator和Executor之間通過gRPC進行并行通信。

圖5 查詢引擎ADE的架構(gòu)設(shè)計

3.1 面向向量的執(zhí)行計劃

圖6 向量在執(zhí)行計劃Operator之間傳輸

傳統(tǒng)的基于行存儲的查詢引擎，在查詢計劃節(jié)點之間傳遞的是行或者Tuple對象。通過調(diào)用next方法，逐行的處理數(shù)據(jù)。在大數(shù)據(jù)環(huán)境下，函數(shù)調(diào)用上下文切換的時間消耗，不可忽略。而且在OLAP中的聚合運算，往往只需要部分列，Tuple中卻包含了所有的列數(shù)據(jù)。相反，列存儲以向量的方式計算和傳遞數(shù)據(jù)，向量數(shù)據(jù)以Record Batch 的格式，在Operator之間傳輸。向量運算和傳遞，充分利用了SIMD指令，快速實現(xiàn)FILTER， COUNT， SUM， MIN 。OLAP典型的計算是復(fù)雜Join、數(shù)據(jù)聚合和數(shù)據(jù)掃描。以如下SQL為例詳細(xì)介紹ADE查詢引擎的工作方式：

SELECT avg(wholesale_cost)， avg(list_price) FROM store_sales

Operator的Allocator之間有父子關(guān)系，同查詢計劃的父子關(guān)系。父Operator能夠訪問子Operator的Allocator的數(shù)據(jù)。Scan算子選擇四個字段，掃描數(shù)據(jù)封裝在Record Batch中。Filter算子掃描store_sk向量，過濾出store_sk=7的行，記錄在Filter Vector向量中。Filter Vector的格式為4個字節(jié)的向量數(shù)組，結(jié)構(gòu)為(batch_index，row_index)。其中1-2字節(jié)標(biāo)識Batch的Index，3-4字節(jié)標(biāo)識在該Batch中的位置。如(3，68)。Aggregation算子，通過構(gòu)建Hash Table來計算Avg平均值。分為兩個步驟：

圖7 面向內(nèi)存向量的過濾與聚合運算

掃描Record Batch中Group By字段(item_sk)，Avg字段(list_price、wholesale_cost)使用SIMD指令掃描，Item Vector構(gòu)建新的Record Batch。

對上述Record Batch掃描字段(item_sk)進行轉(zhuǎn)置成行式數(shù)據(jù)，對所有Keys字段計算Hash值并構(gòu)建Hash Vector，進而構(gòu)建Hash Table，在Hash Table中進行Aggregation運算。Hash Table是常用來進行Hash Aggregation/Hash join的數(shù)據(jù)結(jié)構(gòu)。

3.2 過濾和排序?qū)崿F(xiàn)

在執(zhí)行過濾和排序操作時，使用一個索引向量，來標(biāo)識符合條件的數(shù)據(jù)行或者使用索引向量順序標(biāo)識向量值的順序。因為一個batch設(shè)計為最多64K條記錄。所以用Int16整數(shù)表示。Batch之內(nèi)，使用2字節(jié)的整型0，12，17表示行索引號。標(biāo)識多個Batch數(shù)據(jù)，使用4字節(jié)的，區(qū)間索引。0-12表示第一個batch的第12行記錄。

圖8 FilterVector實現(xiàn)過濾和排序

執(zhí)行過濾操作時，一次Scan就能過濾出符合條件的記錄，不需要改變原始數(shù)據(jù)得結(jié)構(gòu)，只需要構(gòu)建一個索引向量。輸出查詢結(jié)果時，只需要根據(jù)這個FilterVector和字段映射選擇某些字段向量匹配索引輸出即可。

執(zhí)行排序操作時，使用選擇排序算法或者冒泡排序算法，依次把最大到最小值的索引放在FilterVector中。輸出查詢結(jié)果時，只需要根據(jù)這個FilterVector和字段映射選擇某些字段向量匹配索引輸出即可。

3.3 Hash關(guān)聯(lián)與Hash 聚合運算

在實踐中發(fā)現(xiàn)，列式存儲格式，不利于進行HashJoin、HashAggregation運算。因為列式存儲對HashTable的插入、查找是低效的。因此，需要在計算之前先轉(zhuǎn)置成行的格式。首先，把GroupBy字段進行轉(zhuǎn)置成行數(shù)據(jù)，然后構(gòu)建Hash Table。如圖9所示。

圖9 數(shù)據(jù)轉(zhuǎn)置和構(gòu)建Hash Table

3.4 節(jié)點數(shù)據(jù)遷移優(yōu)化

節(jié)點之間Shuffle數(shù)據(jù)仍然是按照Record Batch封裝，每個Record Batch都開啟一個線程進行數(shù)據(jù)傳輸，而Record Batch過濾后可能僅有很少的數(shù)據(jù)，這無疑就增加了上下文交換、任務(wù)調(diào)度、線程資源開銷。為此本文中使用多路復(fù)用技術(shù)、在發(fā)送端重新組裝Record Batch。

圖10 多路復(fù)用節(jié)點間數(shù)據(jù)傳輸

如圖10所示，N個RecordBatch最終分配到K個Buckets進行數(shù)據(jù)傳輸，K即集群節(jié)點數(shù)。Filter Vector后的數(shù)據(jù)，首選對Key進行Hash，生成Bucket Id，為此，每個RecordBatch生成Bucket Vector。然后，所有遍歷Record Batch，根據(jù)Bucket Vector把數(shù)據(jù)分配到對應(yīng)的Bucket，并根據(jù)記錄數(shù)等參數(shù)，每個Bucket數(shù)據(jù)都封裝成多個Record Batch。為每個Bucket啟動一個線程，進行數(shù)據(jù)傳輸。優(yōu)化前節(jié)點間數(shù)據(jù)交換次數(shù)為(K-1)* N，優(yōu)化后為(K-1)* K。

3.5 動態(tài)估算Batch Size

Arrow以Batch的方式存儲和傳輸數(shù)據(jù)，在內(nèi)存的數(shù)據(jù)，往往要比在磁盤上大，因為在磁盤上可以壓縮，而在內(nèi)存中一般不壓縮，因為要支持隨機讀取等操作。Batch是處理數(shù)據(jù)得最小執(zhí)行單元。適當(dāng)?shù)腂atch Size有利于集中計算，提高Operator之間數(shù)據(jù)傳輸效率，減少上下文交換，減少計算任務(wù)調(diào)度次數(shù)，提升整體效率。Batch Size過大可能會造成Operation之間數(shù)據(jù)傳輸異常。Batch Size過小會增多上下文交換、增加線程數(shù)量、增大數(shù)據(jù)處理時內(nèi)存overhead消耗。除此之外，批次大小還要考慮數(shù)據(jù)表的寬度、字段數(shù)量、平均字節(jié)數(shù)等因素。

ADE實現(xiàn)了根據(jù)表寬、字段數(shù)自動調(diào)整Batch Size。一般情況下Batch size在127-4095之間。計算公式為：

(4)

其中：bi為第i個字段的固定字節(jié)長度，h為行固定開銷一般為128字節(jié)，C為字段數(shù)量。W為表寬的調(diào)整因子，當(dāng)C大于100是為1，當(dāng)C小于100是為2。使用公式(6)把batchsize計算結(jié)果調(diào)整到127-4095的范圍內(nèi)。

W=2ifC≤100

1ifC>100

(5)

batchsize=min(max(pre_batchsize， 127)， 4095)

(6)

3.6 RPC數(shù)據(jù)傳輸協(xié)議

Batch的字段內(nèi)部是連續(xù)的內(nèi)存存儲，字段之間的內(nèi)存區(qū)是不連續(xù)的。在RPC 傳輸時，修改傳輸協(xié)議頭，一次性連續(xù)傳輸所有字段的數(shù)據(jù)。并且增加RPC連接失敗回調(diào)處理方法，發(fā)生傳輸異常時進行重試，而不是簡單的異常斷開連接。

3.7 數(shù)據(jù)壓縮和優(yōu)化

使用字典類型進行數(shù)據(jù)編碼和查詢優(yōu)化。例如可以將全國省市字典加載，數(shù)據(jù)中使用Int32類型表示。原來重復(fù)每行記錄需要存儲的省市名稱，現(xiàn)在只需要用一個有限長度的字典向量即可。這樣，可以減少數(shù)據(jù)存儲量，壓縮數(shù)據(jù)。同時，把可變長度字段變?yōu)楣潭ㄩL度Int32類型，提高計算過濾、分組統(tǒng)計效率。如圖11所示。

圖11 字典類型向量壓縮

3.8 并行查詢接口

ADE作為其他大數(shù)據(jù)組件(如Spark)的數(shù)據(jù)源，則JDBC訪問方式會成為瓶頸。因此該平臺設(shè)計了并行查詢接口，如上圖MPP并行計算引擎Spark，如圖12所示。ADE和Spark之間，使用Arrow Flight RPC傳輸數(shù)據(jù)，詳細(xì)過程分為三個階段：①發(fā)送SQL語句，ADE開始運行SQL，并生成運行基本數(shù)據(jù)，包括數(shù)據(jù)分片、執(zhí)行節(jié)點、各節(jié)點的RPC的Endpoint。②客戶端向ADE發(fā)送doGet命令，請求發(fā)送數(shù)據(jù)，同時建立一個監(jiān)聽器，監(jiān)聽ADE發(fā)回的數(shù)據(jù)。ADE建立數(shù)據(jù)發(fā)送通道，不停地把數(shù)據(jù)集push到客戶端。③ADE發(fā)送數(shù)據(jù)完畢，發(fā)送complete指令?；蛘呖蛻舳酥鲃觕ancel 數(shù)據(jù)獲取動作。如圖12所示。

圖12 并行查詢接口架構(gòu)

3.9 實驗效果分析

該項目采用TPC-DS測試工具集，與Hive on Spark、Apache Drill進行對比驗證。Hive on Spark配置為Executor四臺(8 Cores、10G內(nèi)存、500G磁盤)；Driver一臺(8 Cores、32G內(nèi)存、500G磁盤)。Drill配置為四臺(8 Cores、4堆內(nèi)存、8G堆外內(nèi)存、500G磁盤)。ADE配置為Coordinator一臺(8 Cores、32G內(nèi)存、500G磁盤)，Executor四臺(8 Cores、4堆內(nèi)存、8G堆外內(nèi)存、500G磁盤)。

TPC-DS測試工具集生成1GB的數(shù)據(jù)量，并對數(shù)據(jù)根據(jù)時間分區(qū)。使用5線程數(shù)據(jù)負(fù)載測試，每個線程均按照隨機順序運行TPC-DS的84個SQL查詢語句(3)TPC-DS有標(biāo)準(zhǔn)的99條SQL語句，該文去除了15個函數(shù)不兼容的SQL語句?？傮w耗時對比結(jié)果如表1所示。

表1 TPC-DS測試數(shù)據(jù)對比

采集壓測過程中84條SQL的耗時數(shù)據(jù)，分別把ADE與Hive、Drill對比，如圖13所示?？梢姡诖蠖鄶?shù)SQL語句中，ADE性能大幅提高，比較Hive提升了近300%；比較Drill提升了近70%。在壓測過程中，觀察CPU負(fù)載情況，如圖14所示。可見，在SQL并行運行過程中，Hive的CPU負(fù)載較大波動，CPU利用率低；Drill的CPU負(fù)載相對比較平穩(wěn)，CPU利用率高；ADE的CPU負(fù)載最為平穩(wěn)，CPU利用率最高。

(a) Hive on Spark 與 ADE SQL耗時對比

(b) Apache Drill 與 ADE SQL耗時對比

(a) Hive on Spark的CPU利用率

(b) Apache Drill的CPU利用率

(c) ADE的CPU利用率

4 結(jié)語

本文介紹了一種基于Arrow技術(shù)設(shè)計和實現(xiàn)的一種內(nèi)存列存儲查詢引擎ADE，詳細(xì)介紹了SQL查詢中向量計算、內(nèi)存使用的方法，并描述了其中的關(guān)鍵技術(shù)及優(yōu)化策略，包括：過濾排序、節(jié)點數(shù)據(jù)Shuffle、Hash聚合運算、Hash Join、Batch Size估算、并行查詢接口等。經(jīng)與Hive on Spark、Apache Drill的驗證對比說明ADE在面向OLAP場景的數(shù)據(jù)源聯(lián)合查詢中有效提高了查詢性能。

進一步的展望，可以著重在SQL的兼容性和預(yù)計算技術(shù)兩個方面。ADE的SQL兼容性應(yīng)符合ANSI SQL-99標(biāo)準(zhǔn)，并支持大多數(shù)的函數(shù)運算。ADE結(jié)合預(yù)計算和SQL重寫技術(shù)，進一步提高常規(guī)查詢的性能。