openGauss 数据库源码解析系列文章——AI 技术（2.1）
openGauss 数据库源码解析系列文章——AI 技术（2.1）
三、慢 SQL 发现
基于历史 SQL 语句信息进行模型训练，并用训练好的模型进行 SQL 语句的预测，利用预测结果判断该 SQL 语句是否是潜在的慢 SQL。当发现潜在的慢 SQL 后，开发者便可以进行针对性优化或者风险评估，以防业务上线后发生问题。
3.1 慢 SQL 发现的功能
上线业务预检测：上线一批新业务前，使用 SQL 诊断功能评估此次上线业务的预估执行时长，便于用户参考是否应该修改上线业务。
workload 分析：能够对现有 workload 进行分析，将现有 workload 自动分为若干类别，并依次分析此类别 SQL 语句执行代价，以及各个类别之间的相似程度。
3.2 现有技术
首先，明确一下慢 SQL 发现的几个不同阶段，及其对应解决的问题。
阶段 1：对用户输入的一批业务 SQL 语句进行分析，推断 SQL 语句执行时间的快慢，进而可以将评估为慢 SQL 的语句识别出来。
阶段 2：对识别出的潜在慢 SQL 进行根因诊断，判断这些 SQL 语句是因为什么慢，例如比较常见的原因可能是数据量过大、SQL 语句自身过于复杂、容易产生并发的锁冲突、没有创建索引导致全表扫描等等。
阶段 3：对于已经识别出来的慢 SQL 语句的可能问题源，给出针对性的解决方案，譬如可以提示用户进行 SQL 语句的改写、创建索引等。
目前 openGauss 已具备阶段 1 的能力，正在推进阶段 2 能力，同时发布了部分阶段 3 的能力，如索引推荐功能。
业内对于上述第一阶段的主要实现方法大部分是通过执行计划进行估计的，第二阶段大多是通过构建故障模式库、通过启发式规则来实现的，有了上述前两个阶段的准备，第三阶段的实现往往是比较独立的。学术界对于第一阶段的研究比较多，第二阶段采用常规的构建故障模式库的方法实现已经能取得比较好的效果了，因此并不是研究的热点，而第三阶段的工作又相对独立，可以单独作为一个领域进行研究。因此，这里仅介绍业内是如何评估 SQL 语句执行时间的，其他两部分暂不详细展开。
1. 基于执行计划的在线 SVM 模型
图 1 基于执行计划 SVM 模型的系统架构图
如图 1 所示，基于执行计划的在线 SVM（support vector machine，支持向量机）模型包含训练模块和测试模块。
训练阶段：Data Collection 模块执行作为训练集的语句，Data Extraction 模块收集执行的语句特征及执行时间，包括执行计划及算子级别的信息。Model Building 模块基于计划级别特征与算子级别信息分别训练 SVM 模型，再将两模型通过误差分布结合，生成最终的预测模型。这主要是考虑到计划级别信息具有普适性，而算子级别信息具有更高的精确性，结合两者可以在保持具有普适性的前提下，尽可能地精确预测。
测试阶段：Query Planning 模块生成待预测语句的执行计划，Feature Extraction 抽取这些计划中的特征，整合后投入训练阶段生成的模型中产生预测结果。
整个功能的流程如图 2 所示。
图 2 基于执行计划 SVM 模型的流程图
基于执行计划 SVM 技术的缺点。
（1） 如果场景不同时，当参数发生变化，系统不能很快感知，预测会有较大误差。
（2） 预测过程依赖待测语句的执行计划，加重了数据库的负荷，对于 OLTP 场景格外不适用。
（3） 每次重启都要重新训练，不能利用历史训练经验。
2. 基于执行计划的 MART 模型
图 3 基于执行计划 MART 模型的系统架构图
基于执行计划的 MART（multiple additive regression trees，多重累加回归树）模型如图 3 所示，主要包含离线训练模块和在线预测模块。他们的功能如下所示。
离线训练阶段：针对数据库每种类型的算子（如 Table Scan，Merge Join，Sort...），分别训练其对应的模型，用于估算此算子的开销。此外，使用单独的训练阶段，可为不同的算子选择适当的缩放函数。最后，形成带缩放函数的不同的回归树模型。
在线预测阶段：计算出执行计划中所有算子的特征值。然后，使用特征值为算子选择合适的模型，并使用它来估算执行时间。
整个功能的流程如图 4 所示。
图 4 基于执行计划 MART 模型的流程图
基于执行计划 MART 模型技术调优技术的缺点。
（1） 泛用性较差，强依赖训练好的算子模型，遇到例如用户自定义函数的未知语句时，预测效果会较差。
（2） 缩放函数依赖于先验结果，对于超出范围的特征值效果无法保证。
（3） 预测过程依赖待测语句的执行计划，加重了数据库的负荷，很难推广到 OLTP 场景中。
3. 基于执行计划的 DNN 模型
图 5 基于执行计划的结构化 DNN 模型的算法架构图
该技术方案的系统架构图与图 1 类似，区别在于与图 1 中的 Model Building 模块中选择的算法不同。如图 5 所示，是现有技术的算法架构图，算法的概述如下。
该算法依然是将执行计划中的算子信息输入到深度学习网络中，从而对执行时间进行预测的。对于每个算子，收集左右子树的向量化特征、优化器代价及执行时间，输入与之对应的模型中，预测该算子的向量化特征及执行时间等。图 5 中显示了一个 join 操作的预测流程，其左右子树均为 Scan 算子，将两个 Scan 算子通过对应的模型预测出的向量化特征、执行时间，以及该 join 算子的优化器评估代价作为入参，输出 join 算子模型得到该操作的向量化特征及预测出的执行时间。上述过程是个自底向上的过程。
整个功能的流程如图 6 所示。
图 6 基于深度强化学习执行时间预估流程图
上述技术的缺点。
（1） 需要通过已预测算子不断修正模型，预测过程会较慢。
（2） 对环境变化感知差，如数据库参数变化会使得原模型几乎完全失效。
（3） 预测过程依赖待测语句的执行计划，加重了数据库的负荷，对于 OLTP 场景格外不适用。
3.3 慢 SQL 发现采取的策略
图 7 慢 SQL 发现流程图
慢 SQL 发现工具 SQLDiag 的执行流程如图 7 所示，该过程可以分为两个部分，分别是基于模板化的方法和基于深度学习的方法，下面分别介绍一下。
1. 基于 SQL 模板化的流程
（1） 获取 SQL 流水数据。
（2） 检测本地是否存在对应实例的历史模板信息，如果存在，则加载该模板信息，如果不存在，则对该模板进行初始化。
（3） 基于 SQL 数据，提取 SQL 的粗粒度模板信息。粗粒度模板表示将 SQL 中表名、列名和其他敏感信息去除之后的 SQL 语句模板，该模板只保留最基本的 SQL 语句骨架。
（4） 基于 SQL 数据，提取 SQL 细粒度的模板信息。细粒度模板表示在粗粒度模板信息的基础上保留表名、列名等关键信息的 SQL 语句模板。细粒度模板相对粗粒度模板保留了更多 SQL 语句的信息。
（5） 执行训练过程时，首先构造 SQL 语句的基于粗粒度模板和细粒度模板信息，例如粗粒度模板 ID、执行平均时间、细模板执行时间序列、执行平均时间和基于滑动窗口计算出的平均执行时间等。最后将上述模板信息进行储存。
（6） 执行预测过程时，首先导入对应实例的模板信息，如果不存在该模板信息，则直接报错退出；否则继续检测是否存在该 SQL 语句的粗粒度模板信息，如果不存在，则基于模板相似度计算方法在所有粗粒度模板里面寻找最相似的 N 条模板，之后基于 KNN（k nearest neighbor，K 近邻）算法预测出执行时间；如果存在粗粒度模板，则接着检测是否存在近似的细粒度模板，如果不存在，则基于模板相似度计算方法在所有细粒度模板里面寻找最相似的 N 条模板，之后基于 KNN 预测出执行时间；如果存在匹配的细粒度模板，则基于当前模板数据，直接返回对应的执行时间。
2. 基于深度学习的执行流程
（1） 获取 SQL 流水。
（2） 在训练过程中，首先判断是否存在历史模型，如果存在，则导入模型进行增量训练；如果不存在历史模型，则首先利用 word2vector 算法对 SQL 语句进行向量化，即图 7 中的 SQL embeding 过程。而后创建深度学习模型，将该 SQL 语句向量化的结果作为输入特征。基于训练数据进行训练，并将模型保存到本地。值得一提的是，该深度学习模型的最后一个全连接层网络的输出结果作为该 SQL 语句的特征向量。
（3） 在预测过程中，首先判断是否存在模型，如果模型不存在，则直接报错退出；如果存在模型，则导入模型，并利用 word2vector 算法将待预测的 SQL 语句进行向量化，并将该向量输入到深度学习网络中，获取该神经网络的最后一个全连接层的输出结果，即为该 SQL 语句的特征向量。最后，利用余弦相似度在样本数据集中进行寻找，找到相似度最高的 SQL 语句，将该结果返回即为该待预测 SQL 语句的预估执行时间。当然，如果是基于最新 SQL 语句执行时间数据集训练出的深度学习模型，则模型的回归预测结果也可以作为预估执行时间。
3.4 关键源码解析
慢 SQL 发现工具在项目中的源代码路径为：openGauss-server/src/gausskernel/dbmind/tools/sqldiag。
1. 项目结构
慢 SQL 发现工具文件结构如表 1 所示。
表 1 慢 SQL 发现工具结构
2. 总体流程解析
算法的总体流程在 main.py 中给出，根据传来的参数实例化算法模型后，进行训练、增量训练、预测等。main 函数的核心代码如下所示。
3. 模板化算法源码解析
通过模板化方法，实现在不获取 SQL 语句执行计划的前提下，依据语句逻辑相似度与历史执行记录，预测 SQL 语句的执行时间。主要源码如下：
4. DNN 算法源码解析
训练阶段先初始化 SQL 向量，之后创建深度学习模型，将模型保存到本地。
预测阶段，导入模型，向量化待预测的 SQL；基于向量相似度对 SQL 的执行时间进行预测。主要源码如下：
3.5 使用示例
SQL 流水的采集方法：SQL 流水可以通过 openGauss 自带的采集工具进行采集，采集过程的性能损耗很低，一般不会超过 5%，该过程可以通过 GUC 参数设置。
（1） log_statement = all。
（2） log_statement_stats=on。
开启参数后，会向数据库日志文件中记录具体的执行语句以及其开销。
使用方法示例：使用前，可通过如下指令获取帮助。
参数说明如表 2 所示。
表 2 命令行参数说明
使用方法示例，使用提供的训练数据进行训练，代码如下：
使用提供的数据进行预测，代码如下：
使用已有的模型进行增量训练，代码如下：
输出样例为 SQL 语句与预测的执行时间。
3.6 总结
当前的慢 SQL 发现功能只是根据历史的 workload 信息，定性、定量地估计未来的 SQL 语句的执行时间。由于 SQL 语句的真实执行结果会受到多种因素影响，这为 SQL 语句的执行结果带来很大噪声，因此理论上通过本功能实现 SQL 语句的执行时间预估是存在一些偏差的，这也是本功能侧重定性判断的原因。对于更精确的 SQL 执行时间预估，可以使用后面提到的 AI 查询时间预测功能。
还未添加个人签名 2023-07-18 加入
还未添加个人简介
评论