DLA访问TableStore的性能调优Hints、支持单字段update等

一、背景

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