在大数据生态里，不同计算引擎适合不同的计算场景，Spark适合批计算，Presto适合adhoc计算，Hermes适合日志检索/人物画像，Starrocks适合数据湖分析。根据SQL特点自动适配最佳的计算引擎，透明化引擎的差异，可以降低用户学习使用成本，提升易用性，同时可以提升SQL计算的性能。
智能计算引擎选择是SuperSQL的核心特性之一，目前已经覆盖天穹的所有SQL，达到千万级别。通过SuperSQL的AI决策中心，我们基于RBO + CBO + HBO组合的引擎选择算法，自动为用户SQL挑选合适的计算引擎。比如通过分析处理历史用户SQL流水，以通用、抽象化的HBO策略，增强补充已有的具体化RBO/CBO策略，将符合条件的离线计算升级到执行速度更快的MPP引擎（如Presto）。计算引擎架构升级带来了计算效率的大幅提升和资源消耗的降低，极大改善用户体验。在HBO上线后，智能引擎选择平均提升了7-13倍的大数据SQL的执行效率。
同时HBO的算法也有一定的判断失误率，失败的SQL导致计算/存储资源浪费。我们用规避率代表成功利用HBO实现计算提效的比例。经过迭代优化，目前HBO的MPP引擎failover规避率已经从最开始的30%提升到70%。
规避率越高，意味着计算提效的准确率越高
HBO的资源节省
但在研究过程中，我们发现RBO + CBO + HBO组合的方式仍存在几个主要问题：
1. 基于专家经验的限制：无论是RBO、CBO，还是HBO，本质上都是专家经验的总结。每一条规则都人为地总结、验证、设置，整个过程比较复杂，且缺少方法论的指导，受到主观因素的影响较大。同时因为是人工编写规则，很难覆盖全部的使用场景。比如对于HBO，在平台SQL执行历史数据中，通过SQL签名检索其历史执行成功或失败的记录决定当前任务是否使用Presto。而对于之前并未执行过的SQL查询语句，不能进行任务执行成功或者失败的判断，因为其依赖于过去相同SQL语句的执行历史信息，因此会导致HBO存在规则盲区的情况。
2. 引擎失败的资源浪费：当现网SQL提交到SuperSQL，SuperSQL根据规则判断SQL是否优先使用Presto进行计算，如果Presto失败后，SuperSQL会自动failover其它计算引擎执行（如Spark或Hive MR），确保SQL能够拿到正确的结果。但Presto计算失败已经浪费了有限的Presto计算资源，部分大SQL甚至可能造成Presto集群的临时过载或故障，当前现网日均的Presto SQL failover数约为近万条+。
基于机器学习的引擎选择方案
针对上面提到的问题，通过机器学习来实现计算引擎的自适应选择是一个非常自然的选择。首先，机器学习能够从样本数据自动学习不同规则，只要样本数据比较完备，学习出来的规则能够覆盖各种不同的使用场景，避免基于人为规则的盲区。其次，我们可以通过调整机器学习算法的目标来达到不同的目的，比如，为了减少MPP引擎failover带来的资源浪费的问题，我们在训练模型时可以适当增加失败的样本的权重。最后，机器学习模型的训练、部署、服务整个pipeline已经很成熟，可以快速地验证、灰度、上线。
在这个过程中，SuperSQL团队与平台大脑拉通合作，选择以大数据计算提效作为切入点，确定解决思路和方案，通过AI决策中心与平台大脑通信，实现算法指导和调优。天穹平台大脑致力于探索并落地前沿人工智能技术，用于大数据系统的自感知、自决策、自优化过程，在自动黑盒优化、基于机器学习的智能决策方面目前已经取得了一定成果，目前已经在公司多个业务规模落地自动化spark参数调优等服务。
SQL提交到SuperSQL，经过SQL解析优化后，进入引擎选择的逻辑。目前的框架采用先通过RBO + CBO + HBO组合来做初步的引擎选择，然后再经过机器学习算法的选择。采用这种方式的原因是希望可以从基于专家经验的方案平稳过渡到基于算法模型的方案，最小化机器学习算法不断迭代优化成熟过程中对现网业务的影响。当模型比较成熟时，引擎的选择会全部由算法来决定，人为的规则则逐渐下线。
算法研发迭代由平台大脑-AI增强决策服务提供，算法模型生产部署在太极，SuperSQL通过调用算法预测服务，把SQL文本传给服务，获取算法预测的结果，根据结果将SQL分发到具体的引擎上进行计算。SQL failover处理、结果处理等逻辑保持不变。
引擎选择算法
本节介绍如何训练引擎选择具体算法，分为特征提取，特性选择，模型训练，以及模型预测，其对应算法流程示例图如下，研发基于天穹平台大脑提供的观测平面、特征市场和算法实验室。
对于SQL语句，使用自然语言处理中的n-gram TF-IDF方法，将SQL文本转化为数值特征，供机器学习模型训练。具体做法为，将SQL语句按字符（或单词，字符效果更好）进行分割，相邻的1-5个字符构成一个元组，选取训练数据中出现频率最高的50万个元组，计算全部训练数据中对应元组的词频-逆文档词频（TF-IDF）值，从而将每个SQL语句转化为50万维的特征向量。
由于特征维度大（50万），训练数据多（100万），模型训练慢，因此需要对特征进行降维。使用基于模型的降维方法，先利用逻辑回归（LR）模型在数据上执行训练，之后逻辑回归模型会根据模型系数对特征给出重要性分析，选择最重要的3千维特征，供后续模型执行训练。
从Presto引擎收集到的执行流水数据具有明显的标签不均衡特征，例如在6月的执行历史中，其中有500万条成功执行的SQL，然而执行失败的SQL数量是20万。这里的处理方案为将所有集群的执行失败的SQL语句都加入训练集，提升失败样本数量、补全不同的失败数据模式，在缓解这种非常不均衡问题的同时提升训练数据的质量。
使用梯度提升树算法XGBoost拟合训练样本，样本特征为如上所述的3千维特征，样本标签为SQL语句在Presto引擎上是否执行失败。由于样本类别分布非常不均衡（失衡）以及XGBoost有许多敏感的算法超参数，因此在模型训练的时候需要调节模型的类别权重参数以及算法超参数，从而达到最优的建模效果，其中调优工具OpenBox被用于超参数自动调优。
对于待判断的SQL语句，首先利用特征提取器从文本中提取50万维特征，然后利用特征选择器将特征降维为1万维，最后使用XGBoost模型预测SQL语句Presto是否会执行失败。如果预测执行失败，则使用Spark引擎执行。
引擎选择效果
下图为模型在训练数据、验证数据、测试数据上的效果。pos weight代表给予不同类别的权重，这里数值越大表示越注重SQL失败的类别。这里重点关注成功在Presto执行的SQL是否能预测正确（绿线），在Presto执行失败的SQL是否可以规避（红线）。在pos_weight为2.0-2.5时，降低选择Presto失败的概率为65%左右（红线），而代价有5%左右的SQL未能通过Presto执行。从实验数据上，当pos_weight为2.0-2.5时，我们避免65%左右的SQL failover，减少failover造成的资源浪费。
2、线上效果
规避率=(HBO+ML规避SQL数) / (规避数 + Failover数)
基于AI的引擎选择算法已上线内网，从上线后的数据观察，公共集群的Presto failover规避率从之前的70%左右上升至90%左右，presto failover的数目直接减少了50%，说明算法很好地补充了HBO规则的盲区，进一步降低了failover带来的资源浪费。
失败SQL规避数
资源节省
在HBO的资源节省基础上，机器学习模型带来了约50%的提升，日均节约CPU core约300核，减少不必要的数据输入量约1PB/天。
总结
SuperSQL升级已有的引擎自适应算法到基于n-gram TF-IDF + XGBoost组合的机器学习算法。通过SQL特征化 + 基于机器学习的在线推理，对SQL结果与执行引擎之间的关系并进行建模，智能地为业务SQL选择最佳的计算引擎。并且实现避免人为规则的缺陷，补充HBO算法在新输入SQL上的处理盲点，实现精准的引擎自适应选择。未来SuperSQL仍然会在引擎选择上持续探索：
1、不断迭代优化模型算法（从机器学习/深度学习），逐步将人为规则下线，实现机器学习算法完全替代专家经验，并达到自动更新学习模型；
2、针对腾讯大数据多种计算模式的现状，构建通用的分布式融合计算框架，实现不同引擎基于同一套可扩展的分布式框架。在框架上层实现不同的计算模式，比如流、批、图计算、机器学习。同时把调度问题、容灾问题、资源管理等问题下沉到分布式服务层；
3、持续丰富优化计算引擎的种类，包括不限于Hermes、Starrocks等。