只需一步，DLA開啓TableStore多元索引查詢加速！

時間 2019-11-16

標籤只需一步 dla 開啓 tablestore 多元索引查詢加速简体版

原文原文鏈接

1、背景介紹

Data Lake Analytics（簡稱DLA）在構建第一天就是支持直接關聯分析Table Store（簡稱OTS）裏的數據，實現存儲計算分離架構，知足用戶基於SQL接口分析Table Store數據需求。html

玩轉DLA+OTS： https://ots.console.aliyun.com/index#/demo/cn-hangzhou/dla
王燁： DLA如何分析Table Store的數據

DLA控制檯：https://openanalytics.console.aliyun.com/java

2、DLA與Table Store的密切配合

這是DLA與Table Store在生態中的關係，做爲存儲計算分離架構，DLA負責主要的SQL算子計算，而Table Store則負責部分計算（由DLA下推下來）和核心存儲功能。算法

3、Table Store的數據原型

目前，Table Store的寬數據表結構（https://help.aliyun.com/document_detail/89879.html）中的列，主要分紅兩部分：主鍵（全部主鍵都不可改，也不爲空；其中第一主鍵是物理分區鍵），非主鍵列（可改可覆蓋可爲空，無關緊要）：sql

假設有張表tbl（主鍵：pk1,pk2；非主鍵：col1,col2），當DLA收到這樣的SQL時:數據庫

select pk2,col1 from tbl where pk1 = 123 and pk2 >= '2019-01-10' and col2 = 'zzz'

DLA就會基於Table Store的SDK接口下發相關的查詢：架構

1）查詢tbl表數據，其中只查詢pk二、pk三、col3這幾個列；

2）按照pk1作分區裁剪，只下推查詢到pk1=123所在的分區；
3）下推 pk1 =12三、pk2 >='2019-01-10'和col4 ='zzz' 這三個條件；
4）若是當前分區的數據很大，則會切分出多個分片，並行查詢；less

這裏，最關鍵的條件就是 pk1 =123，DLA基於這個第一主鍵（分區鍵）條件來篩選OTS的目標分區而後下發查詢條件。其餘支持的分區條件有函數

比較條件：>,>=,=,<,<=,!=
範圍條件：[1,20], (2,10), (-∞,10], (20,+∞)等

4、DLA+Table Store查詢時的瓶頸

針對上面的表結構，若是遇到以下的SQL：性能

select pk2,pk3,col3 from tbl where pk2 >= '2019-01-10' and col4 = 'zzz'

由於pk1並無出如今條件中，沒法作分區裁剪，所以目前DLA會先將整個TableStore的表切好分片，而後下推其餘條件，並行獲取每一個分片的數據並作計算。這樣的問題就是：測試

若是where條件的過濾性很強（知足條件的數據很少），那這種拉取大量數據方式就會引發極大的浪費；即便where條件是能夠下推的，但Table Store內部也要消耗大量的CU來作計算和過濾；
雖然經過並行計算來加速，但總體延時仍是會很高，不管這些計算是在Table Store內部仍是DLA這一側；尤爲是強過濾性的SQL，更加不符合用戶需求；

不管是計算成本仍是延時，都會影響客戶的體驗。

而多元索引是基於倒排索引（https://en.wikipedia.org/wiki/Inverted_index）來設計和實現的：

把一行Table Store記錄當作一篇Document，而Pk是這個Document的DocId；
每一個索引字段都當成一個Term，每一個Term值都反向造成一個DocId的鏈表；
在查詢時針對where條件中每一個列找到知足值域的Term列表，再對應產生多個DocId列表；
再經過拉鍊合併算法，最終獲得合併DocId以後的最大公共集合；
基於這個合併以後的DocId集合（即Pk集合），再回主表查詢數據和過濾、返回；

所以，DLA全面升級了，支持直接以SQL方式訪問Table Store的多元索引（https://help.aliyun.com/document_detail/91974.html）
從而來加速查詢。

五*、DLA訪問Table Store的多元索引

對DLA的客戶來講，只需一步，就可使用DLA來訪問Table Store的多元索引。由於目前統計信息採集及優化器等緣由，暫時還不支持自動判斷多元索引，因此須要利用DLA的hint來主動開啓（DLA的hint機制：https://zhuanlan.zhihu.com/p/55068247）：

/*+ ots-index-first=<相關的索引開關> */ select * from tbl1 where ...

其中，索引開關有幾種模式：

auto模式，會尋找與表相關的索引，只要有知足條件的索引，就會強制使用：

/*+ ots-index-first=auto */ select * from tbl1 where ...

custom模式，根據用戶選擇表列表，來自動選擇知足條件的索引；其中tbl1不須要顯示指定庫名，是由於當前鏈接上已經綁定了一個庫（好比use xxx）；以下case中，只有tbl1和tbl2會走索引，而tbl3則不會：

/*+ ots-index-first=[tbl1, dla_schema2.tbl2, ...] */ select * from tbl1 
join dla_schema2.tbl2 join dla_schema3.tbl3 where ...

threshold模式，會根據當前條件匹配的數據量來動態決策，若是找到一個索引，其匹配的數據量小於必定的行數或者必定比例，那就會自動選擇；threshold:200表示where條件匹配的行數不超過200行纔會使用，而threshold:5%則表示匹配的比例不超過5%纔會使用（至於200和5%，DLA內部會調用Table Store的count接口作快速測試並預估判斷）：

/*+ ots-index-first=threshold:200 */ select * from tbl1 where ...
/*+ ots-index-first=threshold:5% */ select * from tbl1 where ...

另外，早期客戶給DLA作的角色受權策略裏並無這些新增的多元索引接口，所以老客戶須要從新給DLA作跨雲服務訪問的角色受權，戳這裏>>>
)

6、多元索引不是銀彈，請合理使用

雖然Table Store多元索引很好用，但他也不是銀彈，須要合理的使用。有幾個場景的約束：

查詢多元索引時，只能構建並下發一個分片，所以沒法利用並行計算優點；所以對於匹配行數很是少時，單分片索引計算是有優點的；而過濾性不好、數據量不少時就沒有優點；
目前多元索引與主表數據之間不是強一致同步的（正常同步時間在毫秒到秒級），所以業務上須要容忍這個延時；
經過索引找到一批Pk列表後，會再發起隨機query來查找主表數據，因此可能會更慢；
索引字段的類型、定義等，可能不符合數據庫的使用特性（好比定義了全文索引字段等），暫時也不能被自動使用起來；

固然，針對傳統數據庫的索引中的一些特性，在DLA中也儘可能採納進來，好比Covering Index（http://literatejava.com/sql/covering-indexes-query-optimization/）來避免隨機查詢主表，DLA和Table Store也支持，好比這樣的SQL：

-- pk1, pk2是主鍵，col1，col2是非主鍵列，索引是idx_col1_col2
select pk1, col1 from tbl where col2 = 21

這裏col1和col2都在索引中，而pk1和pk2也間接在索引中，所以這個SQL徹底能夠在索引上完成過濾和輸出，從而避免回主表查詢。

7、將來方向考慮

除了多元索引以外，目前Table Store團隊也在積極地推廣二級索引（https://help.aliyun.com/document_detail/91935.html），幫助用戶更好的使用Table Store。將來DLA也會將這塊能力集成進來，這樣DLA能夠幫助用戶在主表、二級索引表、多元索引表之間最優化選擇，幫助客戶提高性能而且下降成本。

將來，DLA須要實現預先採集更多的統計信息，免去用戶主動添加hint的麻煩，徹底自動化的選擇和路由，作到真正的數據庫體驗。

將來，DLA還須要下推更多的計算到Table Store上，實現更好的」近存儲計算「，好比聚合能力下推、函數下推、支持全文索引等等，讓用戶使用DLA+Table Store得到更好的體驗。