SLS提供对海量日志数据进行聚合计算的分析能力（SQL），日志数据一旦写入，用户即可开箱即用地使用SQL进行计算分析，所见即所得。
一、痛点
用户在使用SLS查询分析时，当数据规模（100+亿行记录）越来越大，查询时间范围（30+天）越来越长时，可能会遇到“查询结果不精确”或者直接“执行超时”的尴尬；或者在中小数据规模（1~10亿行记录）下，希望拥有更高性能的分析能力，查询延时更短，为了解决用户的这类痛点和需求，我们推出“SQL增强”功能，为SLS分析提供加速能力。
二、实现原理
图1是典型的分布式计算架构，存储层负责数据的读写，计算层负责计算和分析。 SLS中将存储层抽象为分区（Shard），同时将计算层抽象为SQL，对用户提供免费的计算资源，以实现查询分析能力。 针对上述痛点，想要实现SLS的分析加速，从本质上来说，是要提升计算层的计算能力。在实践和使用过程中，也产生了如下几种实现方案，我们分享在此，并与SQL增强做对比，希望读者更清楚地理解SQL增强的实现原理。 
图1
2.1 扩展分区（Shard）实现一定的计算能力扩展
当分析能力不够的时候，我们可以通过手动分裂Shard来扩展一定的计算能力，如图2所示 
图2
然而这种方式并非完美，存在诸多不足：
首先，Shard分裂对历史数据无法失效，只对新写入数据生效，当用户对历史存量数据进行统计分析，通常情况下用户往往无法做到提前的准确规划和部署
其次，活跃Shard会产生额外的租用费用（详见《为什么会产生活跃Shard租用费用？》），用户为了少量的超大规模的查询分析而长期持有大量活跃shard，对成本造成一定的浪费
此外，Shard分裂对计算能力的扩展有限，其本质上是扩展存储层的能力，计算层由于是多租户分时租用，为了保障多租户间的隔离性，会对单次查询的计算资源做限制（如查询并发数、扫描数据量等）
最后，Shard分裂、合并操作均需要用户手动处理，且仅对新数据生效，很难满足用户弹性多变的查询分析需求
2.2 大查询分割成多个小查询，进行二次聚合
针对大规模数据无法计算精确的问题，很多有经验的SLS用户使用了这种方式：既然一次查询计算不了，那就将单个大查询切分成多个小查询，然后再进行二次聚合，最终得出需要的分析结果。 但是这种方式弊端也很明显：
上层有维护和开发成本，需要保存小查询的计算结果，并进行二次聚合
维度爆炸，业务的分析需求往往是复杂多变的，每当分析维度变化，都可能带来二次聚合的变更成本
数据规模本身非常大，切分粒度已经控制得很小了，但是计算仍然比较吃力
2.3 SQL增强，弹性扩展计算能力
为了解决用户对计算资源的需求，我们提供了“SQL增强”功能，当用户需要大规模计算分析能力的时候，为用户提供弹性的独享计算资源，实现真正的弹性扩展计算能力、按需使用。图3为SQL增强的实现原理，当用户在查询时开启SQL增强后，SLS会根据本次查询的实际计算需求，合理调度独享资源参与计算，加速整个查询分析过程。 
图3
相比以上两种方式，SQL增强实现了真正的计算能力的弹性扩展，且有以下几点优势：
计算资源弹性扩展，按需使用
计算与存储（Shard）无强制绑定，无需用户提前规划和运维管理
突破免费资源的分时租用限制，享受独享资源
免除额外的开发和运维成本，不管什么数据规模（从几万-千亿级别），一条SQL帮您搞定分析，无需再做上层二次聚合
三、普通SQL和SQL增强的特性对比
** 下表列举出目前普通SQL和SQL增强在各个维度上的对比：**
| | 普通SQL | SQL增强 | | --- | --- | --- | | 并发查询数 | 单个Project支持的最大分析操作并发数为15个 | 单个Project支持的最大分析操作并发数为150个 | | 扫描数据量 | 单个Shard单次仅支持分析1 GB数据 | 单次分析最大支持扫描2000亿行数据 | | 计算资源 | 免费资源，分时租用有使用限制 与分区Shard数有一定的配比关系 | 独享资源，资源上限有用户自定义 与分区Shard数无绑定关系 | | 费用 | 免费 | 目前公测免费 后续计划根据实际使用的CPU时间付费，更多信息，请参见计费项| | | | 更多增强特性，敬请期待。 |
四、什么场景下推荐使用SQL增强
我们推荐在遇到如下场景时，使用SQL增强：
超大数据规模的计算分析（如SLS报“计算结果不精确”）
历史周期长且数据规模大的计算分析（如SLS报“execution timeout”）
burst高并发查询（如定时告警、定时调度等，可能一次性同时触发多个SQL请求，如SLS报“user can only run 15 query concurrently”）
五、使用实践
为了让读者更真切地体会SQL增强，我们提供了一个1000+亿行Nginx访问日志的模拟环境，供SLS用户免费在线体验，享受SQL增强带来的极致加速感。 
接下来，我们分别在不同数据规模（1000+亿、10+亿、1+亿）下演示SQL增强的使用实践 我们使用上述模拟环境，选择查询时间段为3天，对1000亿行日志数据进行计算分析，使用SQL测试用例如下：
| select sum(request_length), avg(request_time), avg(upstream_response_time)
1000+亿数据规模下的计算分析
使用普通查询
使用SQL增强
使用SQL增强非常简单，只需要在SLS控制台查询页面右侧，点亮“SQL增强”按钮即可。 如果您是开发者，使用SDK或者API调用，也可以开启SQL增强，详情请参考GetLogs的powerSql参数。 
下表是普通SQL和SQL增强，在1000+亿数据规模、同样SQL下的执行表现对比：
| | 普通SQL | SQL增强 | 提升效果 | | --- | --- | --- | --- | | 日志总条数 | 100,000,863,644 | 100,000,863,644 | | | 查询状态 | 查询结果不精确 | 结果精确 | | | 扫描行数 | 9,084,644,562 | 100,000,863,644 | 10X | | 查询时间 | 3,054ms | 7,258ms | 10倍数据扫描量，仅增加了1.38倍延迟 | | 消耗CPU时间 | 392.759s | 9,459.867s | 23X | | 结果行数 | 1 | 1 | |
可以看到，开启SQL增强后，能够在7.3s内扫描1000+亿行数据，并完成精确计算。相比普通SQL，计算结果精确、扫描行数提升10倍、运行CPU时间提升23倍，延时仅增加了1.38倍。
10+亿数据规模下的计算分析
使用普通查询
使用SQL增强
下表是普通SQL和SQL增强，在10+亿数据规模、同样SQL下的执行表现对比：
| | 普通SQL | SQL增强 | 提升效果 | | --- | --- | --- | --- | | 日志总条数 | 1,006,371,097 | 1,006,371,097 | | | 查询状态 | 结果精确 | 结果精确 | | | 扫描行数 | 1,006,371,097 | 1,006,371,097 | | | 查询时间 | 2,176ms | 1,692ms | 延时缩短了22% | | 消耗CPU时间 | 60.18s | 93.517s | 提升了55% | | 结果行数 | 1 | 1 | |
1+亿数据规模下的计算分析
使用普通查询
使用SQL增强
下表是普通SQL和SQL增强，在1+亿数据规模、同样SQL下的执行表现对比：
| | 普通SQL | SQL增强 | 提升效果 | | --- | --- | --- | --- | | 日志总条数 | 123,306,893 | 123,306,893 | | | 查询状态 | 结果精确 | 结果精确 | | | 扫描行数 | 123,306,893 | 123,306,893 | | | 查询时间 | 1,036ms | 831ms | 延时缩短了20% | | 消耗CPU时间 | 7.183s | 11.021s | 提升53% | | 结果行数 | 1 | 1 | |
结合上面三种不同数据规模下的使用实践，可以看到，在超大数据规模（1000+亿）下，SQL增强通过提供额外的独享计算资源，可以完成普通SQL无法完成的精确计算任务，并大幅提升了计算效率；而在10+亿和1+亿数据规模下，普通SQL和SQL增强均可完成精确计算，但是SQL增强可以投入更多CPU资源（约50~55%）加速计算，使计算延时缩短20%左右。
控制和管理SQL独享资源使用上限
在提供了SLS分析加速能力的同时，我们还贴心地为用户提供了独享资源使用上限（SQL独享实例CU数）的设置，默认值1000，该值表示一次查询可并发运行的任务数，它有效控制了计算核时的资源，**避免意外造成的计算资源使用过量，产生不必要的费用。**用户可以前往目标Project的概览页面中进行自定义的配置。 
参考文档
开启SQL独享实例：https://help.aliyun.com/document_detail/223777.htm
SLS SQL分析概述：https://help.aliyun.com/document_detail/53608.html
