原標題：只需一步，DLA開啟TableStore多元索引查詢加速！

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

玩轉DLA+OTS：https://ots.console.aliyun.com/index#/demo/cn-hangzhou/dla

王燁：DLA如何分析Table Store的數據

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

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

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

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

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

1）查詢tbl表數據，其中只查詢pk2、pk3、col3這幾個列；

2）按照pk1做分區裁剪，只下推查詢到pk1=123所在的分區；

3）下推 pk1 =123、pk2 >='2019-01-10'和col4 ='zzz' 這三個條件；

4）如果當前分區的數據很大，則會切分出多個分片，并行查詢；

這里，最關鍵的條件就是 pk1 =123，DLA基于這個第一主鍵（分區鍵）條件來篩選OTS的目標分區然后下發查詢條件。其他支持的分區條件有

針對上面的表結構，如果遇到如下的SQL：

因為pk1并沒有出現在條件中，無法做分區裁剪，因此目前DLA會先將整個TableStore的表切好分片，然后下推其他條件，并行獲取每個分片的數據并做計算。這樣的問題就是：

• 如果where條件的過濾性很強（滿足條件的數據不多），那這種拉取大量數據方式就會引起極大的浪費；即使where條件是可以下推的，但Table Store內部也要消耗大量的CU來做計算和過濾；
• 雖然通過并行計算來加速，但整體延時還是會很高，無論這些計算是在Table Store內部還是DLA這一側；尤其是強過濾性的SQL，更加不符合用戶需求；

無論是計算成本還是延時，都會影響客戶的體驗。

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

1. 把一行Table Store記錄看成一篇Document，而Pk是這個Document的DocId；
2. 每個索引字段都當成一個Term，每個Term值都反向形成一個DocId的鏈表；
3. 在查詢時針對where條件中每個列找到滿足值域的Term列表，再對應產生多個DocId列表；
4. 再通過拉鏈合并算法，最終得到合并DocId之后的最大公共集合；
5. 基于這個合并之后的DocId集合（即Pk集合），再回主表查詢數據和過濾、返回；

因此，DLA全面升級了，支持直接以SQL方式訪問Table Store的多元索引（https://help.aliyun.com/document_detail/91974.html）

從而來加速查詢。

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

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

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

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

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

另外，早期客戶給DLA做的角色授權策略里并沒有這些新增的多元索引接口，因此老客戶需要重新給DLA做跨云服務訪問的角色授權，[戳這里>>>](https://ram.console.aliyun.com/#/role/authorize?request=%7B%22Requests%22:%20%7B%22request1%22:%20%7B%22RoleName%22:%20%22AliyunOpenAnalyticsAccessingOTSRole%22,%20%22TemplateId%22:%20%22OTSRole%22%7D%7D,%20%22ReturnUrl%22:%20%22https:%2F%2Fopenanalytics.console.aliyun.com%2F%22,%20%22Service%22:%20%22OpenAnalytics%22%7D)

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

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

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

這里col1和col2都在索引中，而pk1和pk2也間接在索引中，因此這個SQL完全可以在索引上完成過濾和輸出，從而避免回主表查詢。

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

未來，DLA需要實現預先采集更多的統計信息，免去用戶主動添加hint的麻煩，完全自動化的選擇和路由，做到真正的數據庫體驗。

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

• DLA文檔專欄：https://zhuanlan.zhihu.com/data-lake-analytics
• DLA+Table Store分析：https://zhuanlan.zhihu.com/p/74895537
• DLA使用場景：https://help.aliyun.com/document_detail/70380.html
• OLAP on TableStore——基于Data Lake Analytics的Serverless SQL大數據分析https://yq.aliyun.com/articles/618501
• 使用Data Lake Analytics從OSS清洗數據到AnalyticDB：https://yq.aliyun.com/articles/623401
• 使用Data Lake Analytics 分析OSS數據：https://help.aliyun.com/document_detail/70387.html
• Data Lake Analytics數據庫的連接方式：https://help.aliyun.com/document_detail/71074.html
• DLA用戶與權限操作：https://zhuanlan.zhihu.com/p/75624936

------------------------------------

本文作者：Roin

原文鏈接：https://yq.aliyun.com/articles/712733?utm_content=g_1000071446

本文為云棲社區原創內容，未經允許不得轉載。返回搜狐，查看更多

責任編輯：