一、背景

Table Store是DLA最早支持的存储引擎，基于DLA+Table Store可以很好的满足大数据写入和分析的需求，具体如何使用可以看文章：DLA如何分析Table Store的数据

Hint是数据库系统中非常常用和重要的机制，用来干预SQL在数据库中的执行，从而实现性能调优、新功能灰度测试、紧急预案、执行计划选择、特殊功能选择性开启等等。在DLA中，也有相关的hint机制，具体如何使用，请看：https://zhuanlan.zhihu.com/p/55068247

目前DLA和Table Store一直在完善中，两个云产品之间也持续、密切配合。但现实中因为进度、稳定性、性能等原因，很多时候还不尽人意、不够智能化，因此不得不保留一些人为干预的入口，支持调优的余地。所以，本文就DLA面向Table Store的调优hint做一些介绍。

二、Hints介绍

1）计算分片相关：

DLA是分布式的计算系统，内部通过对每个数据表按照一定的规则来切分片/split（分片间是一个完整的划分：相互不重合，整体又完整），计算层并行执行这些分片，从而获得很高的计算并行度。分片是DLA甚至其他分布式数据库、并行数据库的核心概念。

• 表示单个split切分大小，ots-split-unit-mb=123；默认是10MB，值域从1到102400之间；

对于超大的表，如果分片太小，可能会导致分片太多，从而导致TableStore服务承载了极大的压力，经常会产生超时，影响正常写入链路的稳定性。如果预估当前SQL要访问TableStore的数据量很大（比如10GB以上，那当前分片值建议在256；如果在100GB以上，则建议2048以上）；
对于较小的表，如果分片太大，可能会影响计算并行度，从而影响延时。在适当情况下，可以缩小单个分区的大小；

• 自动优化分片情况，ots-split-optimize=true/false，默认是false；

有些场景下用户的SQL自动产生的分片非常非常多，导致计算时Table Store的服务压力很大，经常超时，另一个方面ots产生的分片列表大> 多是顺序的，而相邻的一批split基本上又会落到相同的机器上，在DLA执行时就有可能造成访问的局部热点问题。因此通过一系列的优化手> 段，自动打散分片、合并相邻分片、随机分发分片等优化逻辑，规避热点问题从而提高性能；

• 相邻分片合并，控制总的分片数量，ots-split-size-ratio=0.5，治愈从0.0001到1.0000之间，默认是0.5；在ots-split-optimize=true时才生效；

在ots-split-optimize=true时生效，开启分片优化之后，会有相邻分片做合并的逻辑，但是最终应该合并成多少个分片，则取决于Table Store的压力情况，通过比例值来控制。比如原本计算出100000个分片，设置ots-split-size-ratio=0.3就会尝试合并分片，控制数量接近30000个

2）计算语义相关：

• 是否使用update功能来替换insert的功能，ots-insert-as-update=true/false，默认是false

Table Store的SDK有两个接口来更新数据，RowPutChange/RowUpdateChange；前者是是根据主键整行覆盖和变更，但主键本身不会变> 更；而后者是根据主键来更新部分非主键列，主键本身不会变更；DLA目前不支持Update语句，因此只能通过Insert SQL+hint的方式来实> 现TableStore中数据的变更；
要小心使用！！

• 是否允许使用宽松的cast（比如long值到double，double到long）ots-loose-cast=true/false，默认是false；

默认DLA是强类型系统，上层DLA层定义了一个varchar/string类型，而底层Table Store中该字段是一个bigint类型，那如果用户就希望这么定义表结构和执行SQL的话，DLA会报错的；通过主动开启loose cast，DLA就会自动做类型转换，比如从将字符串"123"转换成整型123，等等；

3）多元索引相关：

• 是否对于某些满足条件的表做索引优先查询，ots-index-first=auto；除了auto还有其他模式，具体请看：https://zhuanlan.zhihu.com/p/74994975

对于大部分SQL，DLA默认是查Table Store的主表的数据进行分析；但如果用户本身已经开通了多元索引，并且用户主动要求使用多元索引，那DLA就会尽可能的使用上多元索引。当然，多元索引与MySQL的二级索引等强一致索引相比，有一些不同：1）基于异步复制，与主表之间不是强一致；2）基于倒排索引实现而非BTree；因此，用户开启多元索引的hint后，DLA需要计算才知道是否真的可以使用上多元索引。

4）其他全局场景：

• 控制单节点的并发数：task-concurrency=<1 ~ 32的整数>，默认是32；

目前DLA集群规模比较大，默认都是高并发的去拉取Table Store的数据。但如果遇到大量的Table Store的超时、重试问题时，就表示DLA目前的请求吞吐太高，会直接影响到客户线上集群的稳定性。安全起见，用户在遇到Table Store超时报错导致SQL执行失败时，需要酌情控制并发度，比如task-concurrency=2；

本身这个并发度控制不太应该暴露给用户来使用；但迫于目前DLA反压机制不够健全、与Table Store在压力互通上做得不够的问题，因此暂时由客户来控制；未来要去掉这个hint；

三、未来方向考虑

目前，基于hint调优也许可以完成一些场景的优化，但用户的使用代价比较大，不太方便。

未来，DLA需要实现预先采集更多的统计信息，免去用户主动添加hint的麻烦，自动化的选择和路由，做到真正的数据库体验。针对分区的信息，也要打通Table Store内部的消息流，自动去采集相关的信息，免去各种运行时才去做的工作，提高查询性能。

未来，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