CN113711198A - 用于优化大数据查询的学习资源消耗模型 - Google Patents

Abstract

提供了用于评估查询的资源消耗的方法、系统、装置和计算机程序产品。要被执行的所生成的(例如，从查询生成实体获得)查询的逻辑运算符表示可以被确定。逻辑运算符表示可以被变换为用于执行查询的多个不同的物理运算符表示。多个资源消耗模型可以被应用于物理运算符表示中的每个物理运算符表示，以确定针对物理运算符表示的资源消耗估计。资源消耗模型可以以不同方式至少基于查询执行的历史而被训练，使得每个模型在估计查询的资源消耗时可以具有不同的粒度、覆盖范围和/或准确性特性。基于针对物理运算符表示所确定的资源消耗估计，物理运算符表示中的一个特定物理运算符表示可以被选择以执行查询。

Description

用于优化大数据查询的学习资源消耗模型

背景技术

基于成本的查询优化器是针对大规模并行的大数据基础设施的关键组件，其中执行计划的改进可能会潜在地导致更好的性能和资源效率。基于成本的优化器的核心使用成本模型以预测运算符的时延，并且选择具有总体资源消耗(例如，执行查询所需的时间)最便宜的计划。然而，随着大数据系统在云中作为数据服务可用，成本建模由于多种原因而变得具有挑战性。首先，大数据系统的复杂性与云环境中的差异耦合使成本建模变得异常困难，因为不准确的成本估计可能很容易产生具有性能极差的执行计划。其次，成本估计的任何改进需要跨工作负载和随着时间的推移保持一致，这使成本调优更加困难，因为性能峰值不利于云客户的可靠性预期。最后，减少总操作成本在云环境中至关重要，尤其是当用于实施执行计划的云资源可以动态地并且按需供应时。

先前的方法已经使用机器学习用于对集中式数据库上的查询进行性能预测，即，给定来自查询优化器的固定查询计划，它们的目标是正确预测资源消耗(例如，执行时间)。然而，这些技术中的许多技术是查询优化器的外部技术。在其中优化器集成工作被使用的一些其他实例中，反馈可以被提供给针对更准确的统计数据的查询优化器，并且深度学习技术可以被实现用于探索最优联合顺序。尽管如此，准确地建模物理运算符的运行时行为仍然是重大挑战。其他工作通过解决不准确的成本估计(例如，信息传递、重新优化和使用多个计划)来提高计划的稳健性。不幸的是，这些工作中的大部分都难以在生产云环境中利用最小的成本和时间开销来采用。最后，与性能预测类似，资源优化被视为查询优化器之外的单独问题，这可能会导致选择不是最优的查询执行计划。

发明内容

本发明内容被提供以简化的形式介绍对于下面在具体实施方式中进一步被描述的概念的选择。本发明内容不旨在标识所要求保护的主题的关键特征或者必要特征，也不旨在被用于限制所要求保护的主题的范围。

提供了用于评估查询的资源消耗的方法、系统、装置和计算机程序产品。要被执行的所生成的(例如，从查询生成实体获得的)查询的逻辑运算符表示可以被确定。逻辑运算符表示可以被变换为多个不同的物理运算符表示，用于执行查询。多个资源消耗模型可以被应用于物理运算符表示中的每个物理运算符表示，以确定针对物理运算符表示的资源消耗估计。资源消耗模型可以以不同方式、至少基于查询执行的历史而被训练，使得每个模型在估计查询的资源消耗时可以具有不同的粒度、覆盖范围和/或准确性特性。基于针对物理运算符表示、所确定的资源消耗估计，物理运算符表示中的一个特定物理运算符表示可以被选择(例如，具有最低资源消耗的物理运算符表示)。

本发明的其他特征和优点以及各个实施例的结构和操作在下面参照附图详细来描述。要注意的是，本发明不被限于本文中所描述的具体实施例。这种实施例是仅出于说明性目的而在本文中提出的。基于本文包含的教导，附加实施例对于(多个)相关领域的技术人员将是明显的。

附图说明

被包含在本文中并且形成说明书的部分的附图图示了本申请的实施例，并且连同本描述，还用于解释实施例的原理并且使相关领域的技术人员能够制造和使用实施例。

图1示出了根据示例实施例的用于执行查询计划的系统的框图。

图2示出了根据示例实施例的用于基于资源消耗估计来选择查询计划的方法的流程图。

图3示出了根据示例实施例的用于确定多个资源消耗估计的系统的框图。

图4示出了根据示例实施例的用于在确定资源消耗估计之前选择针对物理运算符表示的分区计数的方法的流程图。

图5示出了根据示例实施例的用于通过应用从多个资源消耗模型生成的组合模型来确定资源消耗估计的方法的流程图。

图6图示了根据示例实施例的在两个查询之间的公共子表达式，包括扫描所跟随的过滤器。

图7图示了根据示例实施例的用于克服模型准确性和工作负载覆盖范围之间的差距的不同学习粒度。

图8示出了根据示例实施例的学习模型之间的交互以生成用于预测查询执行成本的组合模型。

图9示出了根据示例实施例的用于资源感知查询计划的方法的流程图。

图10图示了根据示例实施例的用于资源感知查询计划的示例系统。

图11是可以被用于实施本文描述的示例实施例的示例计算设备的框图。

当结合附图时，通过下面陈述的详细描述，本发明的特征和优点将变得更加明显，其中相同的参考字符始终标识对应的元素。在附图中，相同的附图标记通常指示相同的、功能类似和/或结构类似的元素。元素首次出现的附图由对应附图标记中的(多个)最左侧数字指示。

具体实施方式

I.介绍

本说明书和附图公开了包含本发明的特征的一个或多个实施例。本发明的范围不被限于所公开的实施例。所公开的实施例仅例示了本发明，并且所公开的实施例的修改版本也由本发明涵盖。本发明的实施例由所附权利要求限定。

说明书中对“一个实施例”、“实施例”、“示例实施例”等的参考指示所描述的实施例可以包括特定特征、结构或特性，但是每个实施例可能不必然包括该特定特征、结构或特性。此外，这种短语不必然指的是相同实施例。此外，当特定特征、结构或特性结合示例实施例描述时，无论是否明确描述，认为是在本领域技术人员的知识范围内，以结合其他实施例来实现这种特征、结构或特性。

在讨论中，除非另外规定，否则修饰本公开的示例实施例的一个或多个特征的条件或关系特性的诸如“基本上”和“大约”的形容词被理解为意味着该条件或特点被限定为在预期的应用的实施例的操作可接受的公差范围内。

许多示例性实施例被描述如下。要注意的是，本文所提供的任何章节/子章节标题都不旨在是限制性的。实施例贯穿该文档被描述，并且任何类型的实施例可以被包括在任何章节/子章节下。此外，在任何章节/子章节中所公开的实施例可以以任何方式与在相同的章节/子章节和/或不同的章节/子章节中所描述的任何其他实施例组合。

II.示例实现

基于成本的查询优化器是大规模并行的大数据基础设施的关键组件，其中执行计划中的改进可能会潜在地导致更好的性能和资源效率。基于成本的优化器的核心使用成本模型以预测运算符的时延，并且选择具有总体资源消耗(例如，执行查询所需的时间)最便宜的计划。然而，随着大数据系统在云中作为数据服务可用，成本建模由于多种原因而变得具有挑战性。首先，大数据系统的复杂性与云环境中的差异耦合使成本建模变得异常困难，因为不准确的成本估计可能很容易产生具有性能极差的执行计划。其次，成本估计的任何改进都需要跨工作负载和随着时间的推移保持一致，这使成本调优更加困难，因为性能峰值不利于云客户的可靠性预期。最后，减少总操作成本在云环境中至关重要，尤其是当用于实施执行计划的云资源可以动态地并且按需供应时。

先前的方法已经使用机器学习用于对集中式数据库上的查询进行性能预测，即，给定来自查询优化器的固定查询计划，它们的目标是正确预测资源消耗(例如，执行时间)。然而，这些技术中的许多技术是查询优化器的外部技术。在其中优化器集成工作被使用的一些其他实例中，反馈可以被提供给针对更准确的统计数据的查询优化器，并且深度学习技术可以被实现用于探索最优联合顺序。尽管如此，准确地建模物理运算符的运行时行为仍然是重大挑战。其他工作通过解决不准确的成本估计(例如信息传递、重新优化和使用多个计划)来提高计划的稳健性。不幸的是，这些工作中的大部分都难以在生产云环境中利用最小的成本和时间开销来采用。最后，与性能预测类似，资源优化被视为查询优化器之外的单独问题，这可能会导致选择不是最优的查询执行计划。

本文描述的实施例通过提供一种用于评估查询的资源消耗的系统来解决这些和其他问题。在示例系统中，逻辑运算符确定器可以确定以确定要被执行的查询的逻辑运算符表示。物理运算符确定器可以将逻辑运算符表示变换为多个不同的物理运算符表示，用于执行查询。资源消耗评估器可以应用多个资源消耗模型，以确定针对物理运算符表示中的每个物理运算符表示的资源消耗估计。在实现中，多个资源消耗模型可以至少基于查询执行的历史而被训练。资源消耗模型中的每个资源消耗模型可以以不同方式而被训练，使得每个模型在估计查询的资源消耗时可以具有不同的粒度、覆盖范围和/或准确性特性。基于针对物理运算符表示所确定的资源消耗估计，查询计划选择器可以选择物理运算符表示的一个特定物理运算符表示。

以这种方式来评估查询的资源消耗具有许多优点，包括减少用以执行查询的资源。例如，通过使用多个不同模型来估计针对要被执行的查询的不同物理运算符表示的资源消耗，资源消耗估计可以以更准确的方式确定，使查询优化器能够选择特定的物理运算符表示，其以最有效的方式利用资源(例如，基于查询可以被执行的速度、用以执行查询的计算资源量等)。此外，如下面更详细地描述的，物理运算符表示还可以包括与每个这种表示相关联的分区计数，使查询优化器能够在选择适当的表示以执行查询时考虑可用资源。通过这种方式，计算资源可以在优化本身期间考虑，使这种资源能够被更有效地利用(无论是本地的还是分布在多个机器上)。

根据本文所描述的技术，资源消耗模型可以使用来自过去工作负载的、基于学习的技术而被训练，这些过去工作负载可以在优化期间被馈送到查询优化器中。例如，基于学习的技术可以被采用，其利用庞大的云工作负载来学习基于历史查询运行时行为的准确并且广泛适用的资源消耗模型。所公开的技术需要以相互增强的方式、以不同的粒度水平、准确性和覆盖范围的大量专用模型的学习。所公开的技术进一步学习元集成(meta-ensemble)模型，该模型组组合并且校正来自多个专用模型的预测，以在确定资源消耗估计时提供高准确性和高覆盖范围两者。在实现中，所学习的资源消耗模型可以被集成在大数据系统内。集成优化器不仅可以利用学习模型用于资源消耗估计，还可以用于有效地找到最优资源，这在许多实例中对于减少云环境中的操作成本可能很重要。最后，所公开系统的实验评估表明所公开的技术提高了资源消耗估计的准确性。例如，在一些场景中已经观察到，通过应用所学习的资源消耗模型来确定的资源消耗估计可能比其他方法更准确几个数量级，与应计运行时间更相关，并且导致时延和资源使用两者的改进。

示例实施例如下针对用于评估查询的资源消耗的系统和方法来描述。例如，图1示出了用于执行查询计划的系统100的框图。如图1所示，系统100包括查询处理系统102、查询生成实体104、一个或多个(多个)关系数据存储库112和资源消耗学习系统114。如图1所示，查询处理系统102包括查询预处理器106、查询优化器108、查询执行引擎110。要注意的是，系统100在本文中仅通过示例描述。(多个)相关领域的技术人员将容易地了解，用于评估要被执行的查询的资源消耗的技术可以在除图1的系统100之外的多种系统中实施。例如，系统100可以包括任何数目的实体(例如，计算设备和/或服务器或其他实体)，包括图1所图示的那些以及可选地未明确图示的以任何方式耦合的一个或多个其他设备。例如，尽管查询处理系统102、(多个)关系数据存储库112和资源消耗学习系统114被示出为彼此分离，但这种组件(或子组件)中的任何一个或多个组件可以位于同一地点，远离彼此，可以在单个计算设备或服务器上实现，或者可以在未在图1中明确图示的一个或多个附加计算设备上实现或分布。系统100进一步描述如下。

在示例中，查询处理系统102、查询生成实体104、(多个)关系数据存储库112和/或资源消耗学习系统114中的一个或多个可以经由一个或多个网络(未示出)通信耦合。这种网络可以包括局域网(LAN)、广域网(WAN)、个人局域网(PAN)、诸如互联网等通信网络的组合和/或虚拟网络中的任何一个或多个。在实现中，查询处理系统102、查询生成实体104、(多个)关系数据存储库112和/或资源消耗学习系统114中的任何一个或多个可以经由一个或多个应用编程接口(API)、网络调用和/或根据其他接口和/或技术来通信。查询处理系统102、查询生成实体104、(多个)关系数据存储库112和/或资源消耗学习系统114可以分别包括至少一个网络接口，其能够彼此通信。这种有线或无线网络接口的示例包括IEEE 802.11无线LAN(WLAN)无线接口、全球微波接入互通(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙^TM接口、近场通信(NFC)接口等。

查询生成实体104可以包括能够生成要被应用于关系数据库的查询的设备、计算机程序或一些其他基于硬件或基于软件的实体。在一个实施例中，查询生成实体104提供用户界面，其用户可以通过该用户界面提交查询。在另一实施例中，查询生成实体104能够自动生成查询。用于生成查询的其他技术可以由查询生成实体104来实现。由查询生成实体104生成的查询可以使用结构化查询语言(SQL)或任何其他数据库查询语言来表示，这取决于实现。

在一些实现中，查询生成实体104可以包括一个或多个用户(例如，个人用户、家庭用户、企业用户、政府用户等)的任何计算设备，其可以包括一个或多个应用、操作系统、虚拟机、存储设备等，它们可以被用以生成要被应用于所描述的关系数据库的查询。查询生成实体104可以包括任何数目的程序或计算设备，包括数十、数百、数千、数百万甚或更多的数目。在示例中，查询生成实体104可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，

设备、个人数字助理(PDA)、膝上型计算机、笔记本计算机、平板计算机(诸如苹果iPad^TM、上网本等)、移动电话、可穿戴计算设备或者其他类型的移动设备或者静止计算设备(诸如，台式计算机或PC(个人计算机))或服务器。查询生成实体104不被限于物理机，而是可以包括其他类型的机器或节点，诸如虚拟机。查询生成实体104可以通过API和/或其他机制与查询处理系统102接口连接。要注意的是，可能存在任何数量的程序接口。

查询生成实体104被通信地连接至查询处理系统104，并且可操作以向其提交查询。在一个实施例中，查询处理系统102包括在一个或多个计算机或服务器设备上执行的软件实现的系统。在一些实现中，查询处理系统102可以包括可以针对多个客户端、租户、组织等来提供基于云的服务的基于云的计算资源或服务器的集合。一般来说，查询处理系统102被配置为接收来自查询生成实体104的查询，针对(多个)关系数据存储库112执行查询以获得响应于该查询的数据，并且将这种数据作为查询结果返回给查询生成实体104。在一个示例实施例中，查询处理系统102包括由华盛顿州雷蒙德市的微软公司出版的SQL

的版本。然而，该示例并非旨在进行限制，并且可以包括用于执行来自查询生成实体104的查询并且将查询结果提供回查询生成实体104的其他程序、软件包、服务等。

查询预处理器106被配置为接收由查询生成实体104提交的查询，并且对其执行某些操作以生成适合于由查询优化器108进一步处理的查询的表示。这种操作可以包括但不限于以下的一个或多个：查询归一化、查询绑定和查询验证。在实施例中，查询预处理器106输出查询的逻辑运算符表示。进一步根据这种实施例，查询的逻辑运算符表示可以包括逻辑运算符树。如本文描述的，逻辑运算符表示可以通过将由查询生成实体104生成的原始查询文本翻译为树或具有根级运算符的其他分层结构来获得，一个或多个叶节点表示输入(例如，表格访问)，并且内部节点表示关系运算符(例如，关系联合运算符)。

查询优化器108被配置为接收由查询预处理器106输出的查询的逻辑运算符表示，处理这种表示以生成和选择用于执行查询的适当计划。执行计划可以表示针对查询的有效执行策略(诸如，以节省时间和/或系统资源的方式来执行查询的策略)。一般来说，查询优化器108进行操作以通过确定针对逻辑运算符表示的多个物理运算符表示(例如，通过执行查询变换)生成针对查询的执行计划，通过应用多个基于学习的资源消耗模型来确定针对每个物理运算符表示的资源消耗估计，并且基于所确定的估计来选择物理运算符表示中的一个特定物理运算符表示以执行查询。在示例实施例中，查询优化器108可以将由资源消耗学习系统114生成的多个基于学习的模型(下面更详细地描述)应用于物理运算符表示中的每个物理运算符表示。在示例中，如本领域技术人员所了解的，查询优化器108可以在一个或多个运行时优化框架中实现。例如，查询优化器108可以结合自上而下的优化器(诸如，级联式优化器)或优化器来实现。

查询优化器108还可以被配置为在确定针对每个物理运算符表示的资源消耗估计之前针对物理运算符表示中的每个物理运算符表示选择分区计数，使得查询优化器108可以将物理运算符表示可以在优化期间执行的分区数量考虑在内。基于所确定的估计，查询优化器108可以选择物理运算符表示中的一个特定物理运算符表示作为用于执行查询的查询执行计划。关于资源消耗估计过程的其他细节在以下章节中提供。

一旦查询优化器108生成并且选择针对查询的执行计划，查询优化器108就将执行计划提供给查询执行引擎110。查询执行引擎110被配置为通过执行由执行计划(例如，可执行代码)针对(多个)关系数据存储库112所指定的某些物理操作来实施执行计划。(多个)关系数据存储库112可以包括被组织为正式描述的表格集合的数据项的集合，数据可以通过从用户、应用或其他实体来接收查询，针对关系数据存储库执行这种查询以产生结果数据集，并且将结果数据集返回给提交查询的实体来访问。本文所描述的这种操作的执行导致从(多个)关系数据存储库112获得一个或多个数据集。查询执行引擎110还可以被配置为对从(多个)关系数据存储库112获得的(多个)数据集来执行某些后处理操作。例如，这种后处理功能可以包括但不限于组合操作(例如，结合或联合)、数据集操纵操作(例如排序操作、分组操作、过滤器等)或计算操作。一旦查询执行引擎110获得了满足查询的数据集，查询执行引擎110就将这种数据集作为查询结果返回给查询生成实体104。

查询执行引擎110可以被配置为存储或记录与查询执行相关联的运行时结果，用于资源消耗学习系统114摄入。资源消耗学习系统114可以基于历史查询执行训练多个资源消耗模型，每个资源消耗模型具有不同的粒度水平、准确性和覆盖范围。例如，每个资源消耗模型可以包括基于与查询执行历史相关联的特征集训练的机器学习模型，对应于每个机器学习模型的特征集被彼此不同地加权。在示例中，资源消耗模型可以基于物理运算符树模式、物理运算符树的根运算符、物理运算符树的叶节点输入、物理运算符树中的总运算符数目或其任何组合而被训练。资源消耗模型可以被离线训练，但实现不受此限制。如本文所描述的，由资源消耗学习系统114生成的资源消耗模型可以在查询优化期间被提供给查询优化器108，以确定资源消耗估计，使得适当的查询计划可以被选择。

如上面提到的，查询处理系统102可以在一个或多个计算机上实现。例如，查询预处理器106、查询优化器108和查询执行引擎110或其某个子组合可以在同一计算机上实施。备选地，查询预处理器106、查询优化器108和查询执行引擎110中的每个都可以在不同的计算机上实现。更进一步地，查询预处理器106、查询优化器108和查询执行引擎110中的每个都可以使用多个计算机实现。例如，分布式计算方法(例如，在云计算环境中)可以被用以使查询优化器108和/或查询执行引擎110的功能能够由多个计算机并行执行。其他实现可以被使用。

在一个实施例中，查询生成实体104和查询处理系统102的一些或所有组件在同一计算机上执行。根据这种实施例，由查询生成实体104生成的查询可以经由计算机内部的通信通道被提供给查询处理系统102。在备选实施例中，查询生成实体104在与用于实现查询处理系统102的(多个)计算机分离的设备上实现。根据这种实施例，查询生成实体104和查询处理系统102之间的通信可以通过通信网络(例如LAN、WAN、直接连接或其组合)来执行。在一个示例实施例中，通信网络包括作为网络中的网络的互联网。通信网络可以包括有线通信机制、无线通信机制或其组合。通过这种通信网络的通信可以使用任何多种众所周知的有线或无线通信协议来执行。

查询优化器108和资源消耗学习系统114可以以各种方式进行操作，以针对要被执行的查询选择执行计划。例如，查询优化器108和资源消耗学习系统114可以根据图2进行操作。图2示出了根据示例实施例的用于基于资源消耗估计来选择查询计划的方法的流程图200。出于说明的目的，流程图200、查询优化器108和资源消耗学习系统关于图3被描述如下。

图3示出了根据示例实施例的用于确定多个资源消耗估计的系统300的框图。如图3所示，系统300包括查询生成实体104、查询处理系统102、(多个)关系数据存储库112和资源消耗学习系统114的示例实现。如图3所示，查询处理系统102包括查询预处理器106、查询优化器108和查询执行引擎110。查询预处理器106包括逻辑运算符确定器314。查询优化器108包括物理运算符确定器316、资源消耗评估器318以及查询计划选择器320。资源消耗学习系统包括查询执行储存库302、资源消耗模型生成器304和资源消耗模型305。资源消耗模型305包括运算符子图模型、运算符子图近似模型308、运算符输入模型310和运算符模型312。流程图200和系统300更详细地描述如下。

图2的流程图200开始于步骤202。在步骤202中，要被执行的查询的逻辑运算符表示被确定。例如，参考图3，逻辑运算符确定器314可以获得要从查询生成实体104执行的查询，并且确定该查询的逻辑运算符表示。在实现中，逻辑运算符确定器314可以被配置为生成逻辑运算符树或要被执行的查询的其他表示。例如，逻辑运算符确定器314可以执行软件指令，以将由查询生成实体104生成的SQL查询编译或解析为解析树、导出树、具体或抽象语法树等。逻辑运算符确定器314也可以被配置为将这种树转换为另一树，诸如逻辑运算符树或表示查询的其他代数表达式。这些示例不旨在进行限制，并且查询的其他逻辑运算符表示可以被使用，诸如有向无环图(DAG)，以表示运算符之间的关系。

由逻辑运算符确定器314确定的逻辑运算符树可以具有多种形式，包括但不限于包括多个运算符(例如，根级运算符和/或根级下面的一个或多个运算符)的树或层次结构以及树中的运算符中的一个或多个运算符的多个输入(例如，叶节点输入)。此外，虽然逻辑运算符确定器314在一些实现中可以被配置为输出单个逻辑运算符表示，诸如优选的逻辑运算符表示，但示例不受限制，并且逻辑运算符确定器314也可以被配置为输出多个等效的逻辑运算符表示。

在步骤204中，逻辑运算符表示被变换为两个或多个物理运算符表示。例如，参照图3，物理运算符确定器316可以被配置为从逻辑运算符确定器314获得逻辑运算符表示，并且将逻辑运算符表示变换为两个或多个物理运算符表示，用于执行查询。在示例实现中，每个物理运算符表示可以包括指示逻辑运算符表示的物理实现(例如，物理运算符集)的物理运算符树(或其他合适的物理运算符表示)。所确定的物理运算符表示中的每个物理运算符表示可以包括例如对应于逻辑运算符表示的执行计划备选方案。在一些实现中，诸如在所获得的逻辑运算符表示是逻辑运算符树的情况下，物理运算符确定器316可以通过将逻辑运算符树内的一个或多个逻辑运算符变换为物理运算符来确定一个或多个对应的物理运算符表示。

如相关领域的技术人员将了解的，物理运算符确定器316可以将单个逻辑运算符表示变换为许多不同的物理运算符表示，其中每个物理运算符表示可能具有资源消耗。例如，逻辑运算符表示中的联合运算符可以被物理地实现为散列联合或合并联合，或者被实现为包括可以使查询执行引擎110能够执行查询的可执行代码的另一运算符。

在一些其他实现中，物理运算符确定器316还可以被配置为在生成多个物理运算符表示时将一个或多个逻辑运算符变换为一个或多个等效的逻辑运算符，因为与第一逻辑运算符相对应的物理运算符可能具有与对应于第二(但逻辑上等效的)逻辑运算符的物理运算符不同的资源消耗。通过这种方式，物理运算符确定器316可以针对要被执行的相同查询确定多个物理运算符表示。然而，要注意的是，在一些实现中，探索空间可能受限于查询的逻辑和/或物理变换(例如，以减少时延)。

在步骤206中，至少基于查询执行的历史而被训练的多个资源消耗模型被应用于物理运算符表示中的每个物理运算符表示，以确定针对每个物理运算符表示的资源消耗估计。例如，参照图3，资源消耗评估器318可以被配置为将多个模型(例如，运算符子图模型306、运算符子图近似模型308、运算符输入模型310和/或运算符模型312中的两个或更多个模型)应用于由物理运算符确定器316确定的物理运算符表示中的每个物理运算符表示，以确定针对物理运算符表示中的每个物理运算符表示的资源消耗估计。

与每个物理运算符表示相关联的资源消耗估计可以是基于物理运算符表示来处理查询所需的时间的估计、在使用物理运算符表示处理查询时将被消耗的系统资源量(例如，处理周期、通信带宽、存储器等)的估计、与使用物理运算符表示处理查询相关联的一些其他方面的估计或其某种组合。(多个)相关领域的技术人员将容易地了解，多种资源消耗函数(例如，成本)可以被用以生成与每个物理运算符表示相关联的资源消耗估计。这种成本函数可以考虑不同的期望目标，包括但不限于减少查询处理时间和/或降低系统资源利用率。

在示例中，运算符子图模型306、运算符子图近似模型308、运算符输入模型310和/或运算符模型312中的一个或多个模型可以至少基于先前查询执行的历史而被训练。例如，在根据所选择的执行计划来执行查询时，查询执行引擎110可以被配置为将与查询执行相关联的运行时信息存储在查询执行储存库302中。查询执行储存库302可以包括针对由查询执行引擎110实施的查询执行的多个运行时日志。运行时信息可以包括例如过去工作负载的属性、过去工作负载的统计数据、过去工作负载的基数信息、查询执行时间、计算机资源利用率信息(例如，用于执行查询的分区或其他计算资源的数目和/或身份)、与过去所执行的查询的逻辑和/或物理运算符表示相关联的信息(包括但不限于这种表示中的运算符的数量和/或身份)或者可能与过去工作负载相关联、从中提取或以其他方式从中导出的任何其他信息。

资源消耗模型生成器304可以被配置为基于存储在查询执行储存库302中的查询执行历史来生成和/或训练运算符子图模型306、运算符子图近似模型308、运算符输入模型310和/或运算符模型312中的每个模型。在一些实现中，资源消耗模型生成器304可以离线生成和/或训练资源消耗模型，并且在优化期间反馈回查询优化器108，尽管实现不被限于此。例如，在查询优化期间，资源消耗评估器318可以应用资源消耗模型中的两个或更多个资源消耗模型以确定针对物理运算符表示中的每个物理运算符表示的资源消耗估计。

在示例中，资源消耗模型生成器304可以使用相同的训练数据集而被训练运算符子图模型306、运算符子图近似模型308、运算符输入模型310和/或运算符模型312中的一个或多个模型(例如，存储在查询执行储存库302中的查询执行历史)。在一些实现中，资源消耗模型生成器304可以使用相同或类似的特征或特征集而被训练资源消耗模型。由资源消耗模型生成器304使用以训练资源消耗模型的特征集可以包括基础特征和/或导出特征。基础特征可以包括从过去执行的查询中所提取的特征，诸如查询中的运算符信息、针对查询中的特定运算符的基数信息、所操作的行大小、工作负载的输入、工作负载的参数或者可以从先前所执行的查询中获得的其他特性或统计信息。导出查询可以包括其他特征，诸如从基础特征(例如，基于数学操作的特征，诸如，乘积、平方、平方根、偏差等)、工作负载的输入和输出的大小、工作负载的执行时间、分区信息(例如用于执行工作负载的分区的数量和/或身份)或者可能与先前所执行的查询的资源消耗中的促成因素相关的任何其他特征的组合导出的特征。

在一些实现中，每个资源消耗模型可以包括可以被不同地训练的机器学习模型。例如，每个机器学习模型可以至少基于特征集而被训练，其中对应于每个模型的特征集可以与用以训练其他机器学习模型的特征集不同地加权。作为说明，被设计为更细粒度或专用的一个资源消耗模型(例如，运算符子图模型306)可以包括对于某些特征的相对较高的权重(和/或对于其他特征的权重为零或接近于零)，而被设计为更通用的另一模型(例如，运算符模型312)可以更均匀地加权特征。

如上所述，资源消耗模型生成器304可以训练多个资源消耗模型，包括但不限于运算符子图模型306、运算符子图近似模型308、运算符输入模型310和/或运算符模型312，如图3所示。在实现中，运算符子图模型306可以包括至少基于先前查询执行而被训练的模型，该先前查询执行包括具有公共模式的物理运算符树作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。换言之，运算符子图模型306可以基于在某些方面类似的物理运算符树的先前执行，诸如运算符(例如，相同的根运算符和根运算符下面的运算符)以及相同类型的叶节点输入(例如，输入是结构化的还是非结构化的、输入的大小、源文件的位置、源文件类型等)。通过训练具有相同子表达式(不包括特定常数、参数值和输入)的模型，运算符子图模型306可以包括可以具有高准确性的模型。因为运算符子图模型306可以基于特定模式而被训练，所以运算符子图模型306可能具有减少的覆盖范围，因为它可能不适用于具有不同模式的物理运算符表示。然而，在一些实现中，运算符子图模型306可以基于最常见或最频繁出现的子图而被训练，从而增加这种模型的覆盖范围。

运算符模型312可以至少基于先前查询执行而被训练，该先前查询执行包括具有公共根运算符的物理运算符树作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。例如，运算符模型312可以基于根级运算符而不是根级下的运算符或输入而被训练。换言之，只要根级运算符可以包括与由物理运算符确定器316确定的物理运算符表示相同的运算符，运算符模型312就可以被应用于确定资源消耗估计(即使运算符下的输入可能是不同的)。通过这种方式，运算符模型312可以更广泛地适用于确定与物理运算符表示相关联的成本，尽管由于上下文信息(例如与根级下面的运算符和输入相关的信息)可能不存在，所以准确性可能会被降低。

在一些其他实现中，一个或多个附加模型还可以被生成(诸如，运算符子图近似模型308、运算符输入模型310)。运算符子图近似模型308可以包括至少基于先前查询执行而被训练的模型，该先前查询执行包括具有公共根运算符、叶节点输入的公共集以及相同数目的总运算符的物理运算符树，作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。例如，虽然运算符子图近似模型308可以基于类似于运算符模型312的公共根运算符而被训练，但是运算符子图近似模型308还可以基于与根级运算符下的物理运算符树的节点相关的其他特性而被训练。例如，运算符子图近似模型308还可以包括相同类型的叶节点输入(例如，输入是结构化的还是非结构化的、输入的大小、源文件的位置、源文件类型等)以及类似的总体树结构(例如，与要被执行的查询的物理运算符表示相同的运算符总数目)。因此，虽然要被执行的查询的物理运算符表示的子图可能不同，但运算符子图近似模型308仍然可以被应用于估计子图的资源消耗。通过这种方式，准确性可以相对于运算符模型312来提高，而覆盖范围可以相对于运算符子图模型306提高。

运算符输入模型310可以包括至少基于先前查询执行而被训练的模型，该先前查询执行包括具有公共根运算符、叶节点输入的公共集和不同数目的总运算符的物理运算符树，作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。因此，虽然运算符输入模型310可以类似于运算符子图近似模型308，但是运算符输入模型310可以包括与要被执行的查询的物理运算符表示不同的总体运算符计数(并且因此不同的树结构)，从而与运算符子图近似模型308相比提供了该模型的覆盖范围。

这些模型中的每个模型在下面在章节III.C中更详细地描述。要注意和理解的是，虽然在本文中描述了资源消耗模型生成器304可以训练四个机器学习模型(运算符子图模型306、运算符子图近似模型308、运算符输入模型310和运算符模型312)，实现不被限于这些特定模型或任何特定数目的模型。相关领域的技术人员可以了解，除了本文描述的那些之外或作为其替代，其他类型和数量的机器学习模型可以被实施，以实现用于估计资源消耗的覆盖范围和/或准确性的期望组合。

通过这种方式，资源消耗模型生成器304可以使用过去工作负载信息而被训练多个模型，并且将这些模型反馈回资源消耗评估器318未来优化。资源消耗评估器318可以通过各种方式获得模型，包括经由服务或网络调用、访问文件或相关领域的技术人员所了解的任何其他方式。在优化期间，资源消耗评估器318可以将多个(甚或所有)资源消耗模型(运算符子图模型306、运算符子图近似模型308、运算符输入模型310和/或运算符模型312)应用于由物理运算符确定器316确定的物理运算符表示中的每个物理运算符表示，以确定针对物理运算符表示的资源消耗估计(例如，执行时间)。因为资源消耗模型在粒度、准确性和/或覆盖范围上可能不同，所以将多个模型应用于每个物理运算符表示可以使资源消耗评估器318能够以更接近地类似于实际执行时间的方式确定估计，从而能够选择适当的物理运算符表示来执行查询。

在步骤210中，物理运算符表示的一个特定物理运算符表示基于所确定的资源消耗估计来选择。例如，参照图3，查询计划选择器320可以被配置为从由物理运算符确定器316确定的多个表示中选择物理运算符表示中的一个特定物理运算符表示来执行查询。在示例中，查询计划选择器320可以至少基于由资源消耗评估器318确定的资源消耗估计来选择物理运算符表示，诸如通过选择具有最低或其他最优资源消耗(例如，最低执行时间)的物理运算符表示用于执行查询。

在选择特定物理运算符表示时，查询执行引擎110可以执行对应于本文描述的所选择的表示的查询计划。在执行之后，查询执行引擎110还可以被配置为在查询执行储存库302中存储与查询执行相关联的运行时信息(例如，运行时日志等)，其可以被用作训练数据以进一步训练运算符子图模型306、运算符子图近似模型308、运算符输入模型310和/或运算符模型312中的任何一个或多个模型。因此，这种资源消耗模型可以基于实际运行时信息不断改进，从而使资源消耗评估器318能够以更准确的方式应用这些模型以在查询优化期间更好地确定资源消耗估计。

如上所述，分区计数还可以在查询优化期间考虑。例如，图4示出了根据示例实施例的用于在确定资源消耗估计之前选择物理运算符表示的分区计数的方法的流程图。在实现中，流程图400的方法可以由物理运算符确定器316实现。图4继续参照图3来描述。基于关于流程图400和图3的系统300的以下讨论，其他结构和操作实现对于(多个)相关领域的技术人员来说将是明显的。

流程图400开始于步骤402。在步骤402中，在确定物理运算符表示中的每个物理运算符表示的资源消耗估计之前，针对物理运算符表示中的每个物理运算符表示的分区计数被选择。例如，参照图3，物理运算符确定器316可以被配置为针对物理运算符表示中的每个物理运算符表示来选择分区计数。分区计数可以以多种方式选择，包括至少基于每个物理运算符表示的部分的资源消耗估计。换而言之，实施物理运算符表示的分区计数可以基于针对物理运算符表示的特定阶段、运算符、节点等的资源消耗估计(例如执行时间)。

在示例实现中，如下面将在章节III.E中更详细地描述的，物理运算符确定器316可以被配置为针对一个或多个子节点选择适当的分区计数(例如，基于跨给定阶段中的所有运算符的最低资源消耗)。一旦物理运算符确定器316针对特定阶段选择分区计数，则相同的分区计数可以针对物理运算符表示的其他阶段选择。因为给定的物理运算符表示的资源消耗可能与用于执行该表示的分区(例如容器、机器、节点、可能包括处理单元、存储器集合的虚拟化资源集等)紧密联系，在确定资源消耗估计之前选择分区计数可以使资源消耗评估器318能够更准确地确定资源消耗估计，从而允许查询计划选择器320在查询优化期间选择更优的计划。换言之，查询优化器108可以被配置为选择优化器本身内适当的分区计数(或其他程度的分布式处理或与查询执行相关的并行度)以进一步增强优化器的性能，而不是在查询计划已经被选择之后选择合适的分区计数(这可能会导致不准确的资源消耗估计，因为分区的数目可能会影响查询的执行方式)。

如上所述，资源消耗评估器318可以被配置为应用多个资源消耗模型以确定查询的物理运算符表示的资源消耗估计。在一些实现中，多个模型可以被组合为单个模型，用于由资源消耗评估器318应用。例如，图5示出了根据示例实施例的通过应用从多个资源消耗模型生成的组合模型用于确定资源消耗估计的方法的流程图。在实现中，流程图500的方法可以由资源消耗模型生成器304、资源消耗模型305和/或资源消耗评估器318实现。图5继续参照图3来描述。基于关于流程图500和图3的系统300的以下讨论，其他结构和操作实现对于(多个)相关领域的技术人员来说将是明显的。

流程图500开始于步骤502。在步骤502中，多个资源消耗模型通过应用从多个资源消耗模型生成的组合模型来应用。例如，参照图3，资源消耗评估器318可以被配置为应用可以从运算符子图模型306、运算符子图近似模型308、运算符输入模型310和/或运算符模型312中的两个或更多个模型来生成的资源消耗模型305。在一些实现中，资源消耗模型305可以通过对模型中的每个模型加权来组合多个这种模型(或本文未明确描述的任何其他模型)。例如，资源消耗模型305可以比其他模型相对更重地对模型中的任何一个或多个模型加权(例如，以增加覆盖范围、提高准确性和/或增加覆盖范围和准确性的组合)。在示例实现中，一个或多个资源消耗模型可以以各种方式被组合为资源消耗模型305，如下面在章节III.D.3中更详细地描述的。

III.附加示例查询优化器实施例

A.介绍

以下章节旨在描述本文描述的实现可以被提供的附加示例实施例。此外，以下章节解释了针对这种示例实施例的附加上下文、与实现相关的细节以及这种实现的评估。以下章节旨在说明可以基于本文描述的技术实现的各个方面和/或益处，并且并非旨在进行限制。因此，虽然附加的示例实施例被描述，但是要理解的是，并非在所有实现中都需要下面描述的特征和评估结果。

在示例查询优化器实施例中，技术可以由查询处理器106、查询优化器108、查询执行110、查询执行储存库302、资源消耗模型生成器304和资源消耗模型305(包括其任何子组件)中的一个或多个来实现。基于以下讨论，其他结构和操作实施例对于(多个)相关领域的技术人员将是明显的。

如本文描述的，查询优化器实施例可以采用基于学习的方法从过去工作负载而被训练成本模型(例如，上述资源消耗模型)，并且将它们反馈回来以优化未来查询，从而提供集成的工作负载驱动方法以查询优化。本文描述的实施例能够利用现代云数据服务中可见的大量工作负载，以持续学习准确捕获查询运行时行为的模型。这不仅有助于处理云中的各种复杂性，而且还针对具体客户或工作负载进行专门化或“实例优化”，这通常是高度期望的。附加地，与调优传统优化器所需的多年经验相比，学习成本模型易于以定期频率更新。本文描述的一种实现被用于以微创(minimally invasive)方式扩展大数据查询优化器。它建立在学习基数方法之上，并且为实现完全学习的数据库系统提供了实用的行业强度步骤，这是更广泛的数据库社区所共享的愿景。

云工作负载在本质上通常非常多样化，即，不存在代表性的工作负载以调优查询优化器，并且因此不存在适合整个工作负载的单个成本模型，即，不是万能的(no-one-size-fits-all)。因此，本文描述的实施例学习大量较小大小的成本模型，一个用于通常在生产查询工作负载中丰富的多个公共子表达式中的每个子表达式。虽然这种方法可能会产生非常准确的专用成本模型，但这些模型可能无法覆盖整个工作负载：跨查询的不常见的表达式可能没有模型。另一极端是为每个运算符学习成本模型，它覆盖了整个工作负载，但是牺牲了非常通用的模型的准确性。因此，存在准确性与覆盖范围的权衡，这使成本建模具有挑战性。为了解决这个权衡，成本模型稳健性的概念可以被定义为三个期望的属性：(i)高准确性，(ii)高覆盖范围，和(iii)高保留，即，在再训练之前很长一段时间内稳定性能。本文描述的实施例遵循实现该目标的双重方法。首先，准确性——覆盖范围差距通过学习附加的相互增强模型提高覆盖范围和准确性来克服。然后，自动校正和组合来自单个预测的预测的组合模型被学习，从而针对足够长的窗口(例如，超过10天)提供准确并且稳定的预测。最后，在级联式的自上而下查询优化中，学习成本模型也被利用以考虑资源(例如，针对每个运算符的机器数目)，以产生查询优化计划和资源优化计划两者。由这些实施例表示的各种进步如下。

成本估计问题源于生产工作负载。用于手动改进成本模型的先前尝试被分析，并且对成本模型准确性的基数估计的影响被考虑在内。

机器学习技术被提出以学习高度准确的成本模型。与针对整个工作负载构建通用成本模型，而是大量较小模型被学习，针对每个公共(物理)子表达式一个，它们在预测运行时成本方面高度准确。

学习成本模型中的准确性和覆盖范围权衡被描述，两个极端被示出，并且克服差距的附加模型被讨论。组合模型是在各个模型之上学习的，这些模型组合了来自每个单独模型的预测。所得模型是稳健的，因为它通过长时间段隐式组合来自每个单独模型的特征来提供准确性和覆盖范围两者的改进。优化器和成本模型的集成也被讨论，包括准确性训练、从学习系统到优化器的反馈循环以及用于查找查询计划的最优资源(例如，适当数目的分区)的新颖查询计划器扩展。

最后，详细评估被提出以测试学习成本模型的准确性、稳健性和性能。TPC-H基准和对先前生产工作负载的评估的案例研究被进一步呈现。总体而言，发现学习模型将预测成本与实际运行时间之间的相关性从大约0.1提高到0.8，将准确性提高了2到3个数量级，并且导致计划改变，该改变改进端到端时延和资源使用作业两者。然而，要理解的是，示例实现(包括评估结果)不旨在进行限制。

B.动机

本章节提供了SCOPE的简要概述，并且从生产工作负载中激发了成本建模问题。本章节还示出了即使查询计划中的中间基数是固定的，成本模型仍然是问题。最后，本章节讨论从生产工作负载导出的观察结果。

1.SCOPE概述

SCOPE是大数据系统，用于跨整个微软的内部数据分析，以分析和改进各种产品，包括必应、Office、Skype、Windows、XBox等。它在由成千上万个机器组成的超规模基础设施上运行，每天运行成千上万个作业的大量工作负载，处理十亿字节的数据。SCOPE公开了作业服务接口，用户在其中提交他们的分析查询，并且系统负责在分布式环境中自动供应资源和运行查询。

SCOPE查询处理器将数据分区为更小的子集，并且在多个机器上并行处理它们。并行运行的机器数目(即，并行度)取决于分区数目，通常称为输入的分区计数。当上游运算符不需要具体分区时，某些物理运算符(例如提取和交换(可互换称为置乱(Shuffle)))基于数据统计和启发法来选择分区计数。在同一输入分区集上操作的中间运算符序列被分组到阶段中——阶段上的所有运算符都在同一机器集上运行。除了所选择的场景，交换运算符通常被用于在两个阶段之间重新分区数据。

为了生成针对给定查询的执行计划，SCOPE使用基于级联框架的基于成本的查询优化器。如相关领域的技术人员可以了解的，级联框架使用多个任务来变换逻辑计划：(i)优化组、(ii)优化表达式、(iii)探索组、以及(iv)探索表达式、以及(v)优化输入。虽然前四个任务经由多个变换规则和对分区、分组和排序属性的推理来探索候选计划，但本文所描述的实施例可以作为优化输入任务的部分来实现。每个候选物理运算符的成本在优化输入任务内被计算。在SCOPE中，运算符的成本被建模以捕获其运行时时延，使用数据统计和多年来开发的手工启发法的组合来进行估计。总体而言，级联框架以自上而下的方式执行优化，首先标识树中较高的物理运算符，然后递归地在子树中找到物理运算符。在所有子树物理运算符被标识并且其成本被估计之后，更高级运算符的总成本通过将局部成本与子树的成本组合来计算。

附加地，属性(例如，排序、分组)经由以下方式传播：(i)在其必须满足的较低级运算符上强制执行所需的属性，或(ii)让运算符从较低级运算符导出属性(即，导出的属性)。在本文描述的实施例中，分区计数的导出被优化，因为分区计数可能是针对主要并行数据系统的成本估计(在章节III.E中讨论)中的重要因素，同时仍将传播机制重用于其他属性。总体而言，使用SCOPE中的当前成本模型作为示例，所描述的实施例可以在对级联框架进行最小改变的情况下启用对成本模型的改进。

尽管示例实施例在本文中使用级联框架描述，但是实现不被限于此。本文描述的技术可以在除级联式优化器之外的其他查询优化器中实现。

2.成本模型准确性

为了分析SCOPE成本模型的准确性，对来自其最大客户中的一个客户阿西莫夫系统的一天的生产SCOPE工作负载的分析被构建。由SCOPE成本模型产生的成本估计与实际运行时时延之间的极低皮尔逊相关性0.04被观察到。成本估计和实际运行时时延的比率也被检查。接近1的比率意味着估计成本接近实际成本。然而，如观察到的，估计和实际成本比率的范围从10-2到103，指示存在很大的不匹配，具有严重低估和严重高估两者。

如介绍中提及的，这样做的原因是难以对具有虚拟化运行时环境和来自不同供应商的混合硬件的高度复杂的大数据系统进行建模。此外，当前的成本模型依赖于手工启发法和假设，它们以复杂的方式组合统计数据(例如，基数、平均行长度)以预测每个运算符的成本(例如，执行时间)。随着云环境中的工作负载和系统的不断变化，所得的成本估计通常会偏离并且变得更糟。通用数据处理系统(如SCOPE)还受到来自自定义用户代码的广泛使用的影响，这些代码最终在成本模型中成为黑匣子。

手动调优。改进成本模型可以通过考虑更新的硬件和软件配置(诸如，机器SKU、运算符实现或工作负载特性)来实现。SCOPE团队确实尝试了该路径，并且付出了巨大的努力来改进他们的默认成本模型。所得的成本模型可用于标志下的SCOPE查询。该标志被开启，来自改进模型的成本与默认模型进行比较。相同工作负载下的结果被观察到。观察到相关性从0.04提高到0.10，并且手动改进成本模型的比率曲线略微上移，即，其减少了高估。然而，它仍然受到估计成本和实际成本之间的巨大差距的影响，这再次指示成本建模在这些环境中并非没有意义。因此，为了本描述的其余部分，默认的SCOPE成本模型被使用。

反馈回实际基数。根据先前的工作，学习方法被采用以改进大数据系统中的基数。问题是固定基数是否也解决了成本估计问题。为了解决这个问题，实际运行时基数(即，一个可以实现的理想基数估计)被反馈回并且与生成成本估计进行比较。据观察，由于高估较少，固定基数改进了相关性并且使比率曲线略微上移，但是估计成本与实际成本之间仍然存在很大差距。这是因为即使有实际的基数，用于成本估计的启发法和公式保持不变，并且仍然不能反映实际的运行时特性。要注意的是，虽然改进基数估计仍然很重要，尤其是对于作业服务环境中的资源估计，但是改进成本估计是构建学习优化器的补充努力。

3.系统观察

在开发本文描述的实施例时，目标是学习准确的成本模型，该模型可以被集成在用于查询优化的SCOPE作业服务内。为了确保该方法的实用性，从生产环境收集的某些观察结果现在被讨论。这些观察结果并不旨在限制技术可以被实现的系统，而是仅出于示例实现的上下文中的说明性目的来提供。

R1.准确的运行时预测：来自学习成本模型的预测应该接近实际运行时间。学习准确的预测会自动使成本模型高度相关，从而导致更好的执行计划。

R2.非侵入性：期望重用搜索策略，包括变换规则和属性传播，并且仅利用学习成本模型用于预测运算符的成本。因此，学习模型应该在现有的查询优化框架内可实现。

R3.编译时间特征：学习成本模型只能使用编译时间特征及其派生物。运行时特征或样本运行在当前生产环境中可能不可行。

R4.全覆盖：混合和匹配学习和默认成本估计是错误的，并且因此学习模型应该覆盖整个工作负载，并且在需要再训练之前在相当长的时间窗口内保持适用。

R5.在不损害稳健性的情况下具有相当数量的可解释性：需要具有足够可解释性用于调试目的的模型，但同时允许获得准确的结果。

C.学习成本模型

本章节将首先强调学习成本模型的关键挑战，并且然后根据实施例提出学习大量专用模型集的方法。随后的章节将改进和考虑这种方法的各个方面。

1.挑战

一种简单的方法是学习具有所有可能特征的“巨大”模型并且在查询优化期间重复调用它。然而，这种模型存在巨大的误差，因为运算符的行为彼此显着不同。针对相同的原因，即使是传统的查询优化器也单独对每个运算符(例如，按运算符的散列组或合并联合运算符)进行建模，然后组合来自各个运算符的成本以计算总体执行成本。此外，即使针对同一运算符，一种成本模型也可能不足以捕获所有可能的场景。这是因为同一运算符的行为可能取决于上下文而变化(例如，它与查询中的其他运算符通过流水线、共享排序和分组属性以及它在其上运行的底层软件或硬件平台进行交互时出现)。这个问题可能被称为异构性问题。除了异构性之外，来自先前的查询执行学习成本模型还携带过拟合具体模式或统计数据的风险，这些模式或统计数据可能在长时间段内不适用于更大的工作负载。最后，学习模型共同找到最优资源(特别是机器数目)以及成本也可能是有利的，这使与现有资源不可知的查询优化器的集成具有挑战性。

下面，根据实施例的解决异构性挑战的方法将被讨论。此后，过拟合挑战将在章节III.D中讨论，并且在章节III.E中找到联合优化挑战以找到最优分区计数。

2.专用成本模型

在共享云环境中，分析查询的大部分是重复出现的，即，相同的业务逻辑被应用于以固定间隔(例如，每天或每周)到达的数据集的较新实例。由于共享输入，这些重复出现的作业通常最终会在它们之间具有一个或多个公共子表达式。例如，超过一半的SCOPE作业本质上是重复出现的，其中大多数每天都会出现，并且高达60％的作业在它们之间具有公共子表达式。图6图示了根据示例实施例的包括公共子表达式的系统，该公共子表达式由在两个查询之间的扫描后跟过滤器组成。

本文描述的实施例可以通过学习大量专用模型来利用这些公共子表达式，针对每个这样的运算符子图一个。虽然这类似于学习基数，但基数是逻辑树的属性，并且成本是物理树的属性。因此，实施例针对运算符子图模板的每个物理运算符根学习的模型，并且考虑物理属性，诸如分区计数。

学习运算符子图模型具有许多优点。首先，运算符的行为可以基于运算符之前在同一机器上执行的操作而改变。例如，运算符的执行时间可能会有所不同，这取决于它是以流水线方式(即，同时)运行，还是被阻塞直到先前运算符完成。在运算符子图中，这是通过学习每个物理运算符的行为来建模的，这些运算符以查询计划中位于其下方的运算符为条件，从而捕获针对运算符的上下文。

其次，统计数据(例如，基数)的估计误差趋于随着查询计划向上移动而呈指数增长，每个运算符建立在其子运算符的误差之上。然而，在子图中，运算符成本更多地取决于叶级输入，因为编辑子表达式是固定的。换而言之，子图的不同变化将具有不同的模型。此外，当特征值或统计数据可能不准确时，子图模型可以通过调整特征或统计数据的权重来部分减轻损害，使得成本预测接近实际(随后在章节III.C.2.II中讨论)。这由以下事实进一步促进：针对重复出现的作业，即使数据大小随时间不同，输入通常也共享类似的数据分布和特性，并且因此对权重-10的校正概括了未来的作业调用。换言之，即使特征值不准确，学习模型也可以做出准确的预测。这与默认模型形成对比，其中权重是在假设统计数据准确的情况下配置的。

最后，重复出现或重叠的作业通常在类似的平台上执行，因为它们由执行类似任务的用户发出，或属于同一业务组，并且因此共享硬件或软件特性(例如，缓冲区大小、磁盘速度、缓存、RAM)。这些特性通常在短持续时间内保持稳定，因此，如章节III.F所示，训练一次的模型可以做出足够准确的预测。此外，运算符子图模型导致预测成本和实际运行时间(参见章节III.F)之间的高相关性(例如，大于0.9)，与默认成本模型中的相关性(例如大约0.1)相比有显着提高。与任何机器学习方法一样，两个问题应该被解决，即，特征选择和模型选择。这些在下面更详细地讨论。

I.特征选择

用于学习专用运算符子图模型的特征现在被描述。弹性网络的变型被用作学习模型，因为它提供了最佳性能，如下一章节所描述的。针对特征分析，模型在一天训练数据中的特征权重将被考虑。表1描绘了基础特征，而表2描绘了通过组合一个或多个基础特征所导出的特征。这些在下面描述。这些表格中的特征仅是说明性的。实现可以使用比下面描述的更少的特征集，或者可以包含未明确描述的附加特征。

表1：基础特征

表2：导出的特征

基础特征包括但不限于：基数、平均行长度、分区数量、参数和子图的输入。三种基数被考虑在内：1)基础基数：子图中的叶运算符的总输入基数，2)输入基数：来自子运算符的总输入基数，以及3)输出基数：来自当前运算符的基数输出。除了基础特征之外，经由基础特征的组合形成的附加特征也被考虑在内。它们也被分类为三个类别。第一类别包含其中基数与行长度相乘的特征，以捕获通过网络读取、写入或传输的数据量。在第二类别中，输入或基础基数与输出基数的乘积被进一步考虑，从而共同覆盖数据处理和网络通信方面。第三类别捕获每个机器处理的数据量，并且是并行大数据系统唯一的。通常，数据分区是并行处理的，每个机器通常处置一个或多个数据分区，在属于同一阶段的所有运算符共享相同数目的分区。因此，第三类别中的特征捕获每个机器的输入和输出基数以及每个机器的输入和输出分区大小。

与基数一样，分区或机器的数目也由优化器估计。然而，如章节III.E中详细描述的那样，主要挑战是分区的数目(因此机器的数目)仅由分区运算符(例如交换和提取)决定，而不评估对阶段上的其他运算符的成本的影响。这可能会导致针对阶段的次优性能。用于共同寻找最优成本和分区的查询计划扩展在章节III.E中讨论。要注意的是，诸如作业名称或集群名称等特征会被有意忽略，因为它们可能会导致强烈的偏差并且使模型在名称发生最小变化时变得脆弱。

II.学习模型的选择

许多机器学习模型被评估：线性回归、支持向量机、神经网络、决策树及其在生产工作负载上的变型(在章节III.F.1中讨论)，并且发现这些机器学习模型中的大多数模型都比默认成本模型表现更好。具体地，基于线性和基于决策树两者的回归模型都表现得相当好，并且可以被互换使用。本领域技术人员将了解，其他机器学习模型也可以被使用以实现本文描述的技术。下面，模型选择中的一些考虑将被讨论。

更少并且嘈杂的训练示例。学习模型的准确性可能取决于足够的训练数据的可用性。虽然总体训练数据可能很大，但是据观察，针对许多运算符子图模板，训练示例的数目高度不均匀，许多子图具有更少的训练示例(例如，超过一半的子图实例具有<30个训练样本，用于章节III.B中所描述的工作负载)。附加地，考虑到云环境中的差异(例如，失败)，训练样本的类别标签(即，过去查询的执行时间)以及特征(例如，不准确的统计数据)中可能存在噪声。这些因素两者共同使过拟合问题具有挑战性。事实上，由于这些原因，人们发现神经网络模型以及诸如梯度提升和随机森林的集成模型与其非集成变型相比并没有带来显着的改进(章节III.F.1)。

弹性网络。弹性网络的变型被使用。弹性网络是一种正则化线性回归模型，它组合了L1和L2正则化，以取决于子图和可用的训练样本来自动改变模型的复杂性(即，特征和权重)。尽管小并且嘈杂的训练数据上的特征和权重往往会发生显着变化，但组合的L1和L2正则化趋于通过使变化更稳定来解决这个问题，从而导致更平滑的预测。通常候选特征的数目(在数目上为25到30个)与训练样本的数量一样多。然而，针对给定的子图，通常只有选择的几个特征是信息量大的。这些信息量大的预测器在不同的子图实例中进一步趋于不同。自然地，几乎不可能单独追踪针对每个子图实例的相关预测器。适当地，弹性网络通过针对每个子图独立选择一些信息量大的预测器来帮助执行自动特征选择。因此，所有子图都利用相同的特征集进行训练，并且弹性网络被允许选择相关的一个子图。最后，弹性网络模型直观并且易于解释，就像默认成本模型，其通常是许多统计数据的加权总和。这是重要要求中的一个要求(如章节III.B讨论的)，并且是有效调试和理解生产作业的执行行为的先决条件。针对生产工作负载的实验(参见章节III.F)示出，弹性网络模型是准确的，具有存储占用空间低，并且在查询优化期间快速调用。低存储占用空间确实使针对每个可能的子图的学习专用模型变得可行(参见章节III.B.3中的R1和R5)。虽然运算符子图可能会导致针对公共子表达式的专用成本模型，但是针对训练数据中不频繁(例如至少出现5次)的子图仍然缺乏模型。附加地，由于训练样本的数目通常在数目上较少，因此预测的成本可能不具有代表性。下面，解决这个问题的方法被讨论。

D.稳健性

构建稳健的成本模型现在将更详细地讨论，如章节III.A讨论的(即，不仅准确而且覆盖整个工作负载并且在再训练之前仍然适用相当长一段时间的模型)。关于稳健查询处理的早期技术要么在查询执行期间改变计划，要么同时针对同一查询执行多个计划，从而产生附加的开销。相比之下，实施例旨在利用大量云工作负载以提前学习模型(例如，以离线方式)，使得一个稳健的计划可以在查询优化期间生成。

本章节将首先解释运算符子图模型的覆盖范围和准确性权衡。然后，本章节将讨论另一极端(即运算符模型)，并且介绍附加模型来克服这两个极端之间的差距。最后，本章节将讨论组合各个模型以实现稳健性。

1.准确性-覆盖范围权衡

一个极端：运算符子图模型。章节III.C中呈现的运算符子图模型(例如，本文所描述的运算符子图模型306)在实现中可能是高度专用的，因为它捕获了在查询工作负载中重复看到的查询子图的运算符下方的上下文。因此，该模型很可能是高度准确的。同时，运算符子图模型可能不能很好地概括到训练数据集中没有重复出现的子图，并且因此可能只覆盖工作负载的有限部分，即低覆盖范围(参见章节III.F.1和III.F.2，用于生产工作负载的准确性和覆盖范围)。因此，在一些实例中可能很难预测由训练数据集中从未见过的子图组成的任意查询计划的成本。

另一极端：运算符模型。与运算符子图模型相反，模型可以针对物理运算符中的每个物理运算符学习，类似于传统查询优化器对成本建模的方式。运算符模型(例如，本文所描述的运算符模型312)可以被用于通过以类似于默认成本模型如何从单个运算符的成本导出查询成本的分层方式组合成本来估计给定查询的执行时延。自然地，运算符模型可以被用于估计任何任意查询的成本，即，它覆盖了整个工作负载，然而，类似于传统的查询优化器，它可能会在一些实例中降低准确性，因为运算符的行为基于什么操作出现在它下面来改变。事实上，学习单个模型来捕获运算符的所有实例可能很困难。此外，查询计划的低级运算符的特征或统计数据中的估计误差会被传播到上级运算符，这可能会降低最终预测的准确性。因此，准确性和覆盖范围的权衡可以在学习成本模型时观察到，运算符子图和运算符模型是这种权衡的两个极端。如所提到的，在一个示例实施例中，运算符子图和运算符模型被称为极端。如本领域技术人员将了解的，其他模型也可以被训练和利用。

2.克服差距

两种备选成本模型也被描述在上面讨论的准确性-覆盖范围权衡方面介于两个极端模型之间。

运算符输入模型。每个运算符的备选方案(或附加)是针对共享类似输入的所有作业学习模型。即使数据大小随时间变化，类似的输入也往往具有类似的模式和类似的数据分布。因此，运算符在类似输入上学习的行为通常会概括到未来的作业调用上。具体地，模型(例如，本文所描述的运算符输入模型310)针对每个运算符和输入模板组合来创建。输入模板是归一化输入，其中日期、数字和名称随时间变化的部分针对相同的重复出现的输入将被忽略。这有助于对在不同日期在同一输入模式上运行的作业进行分组。此外，中间子图的特征是引入了两个附加特征。第一特征对子图中的逻辑运算符的数量进行计数，而第二特征对子图中的物理运算符的深度进行计数。

运算符输入近似模型。虽然子图建模利用了大数据分析的重叠和重复出现的性质，但已经观察到大量作业的子图彼此类似，但并不完全相同。因此，模型(例如，本文所描述的运算符子图近似模型308)可以针对共享类似输入以及具有相同近似底层子图的作业来学习。如果两个子图在根处具有相同的物理运算符并且由底层子图中的每个逻辑运算符的相同频率组成，则可以被认为近似相同。子图相似性的概念一直保持粗粒度(例如，逻辑运算符而不是物理运算符的频率被使用，运算符之间的排列可以被忽略)，以便有效地将类似子图分组以解决异构性问题，而无需实质上减少覆盖范围。要注意的是，运算符子图模型已经使用更严格的相似性概念对子图分组(例如捕获运算符之间的排列)。如此，运算符子图近似可能是运算符子图和运算符输入模型的混合，并且可以捕获这两个模型的特性：与运算符或运算符输入模型相比，它可以实现更高的准确性，并且与运算符子图模型相比覆盖更多。

图7图示了根据示例实施例的用于克服迄今为止讨论的模型准确性和工作负载覆盖范围之间的差距的四种不同学习粒度。从左到右，模型准确性降低，而工作负载的覆盖范围增加。在实施例中，针对这些模型中的每个模型，特征或属性权重可以被改变。例如，针对专用模型(如运算符子图模型)的权重可能被集中在几个特征上，而针对更概括的模型(如每个运算符模型)的权重可能被分布得更均匀。给定具有不同准确性和覆盖范围的多个学习模型，可以确定使用哪个模型(或多个模型)以及何时使用。解决该确定的方式现在将被讨论。

3.组合模型

选择要使用的学习模型的一种方式是采用基于规则的方法，该方法以专业化的降序寻找学习模型的存在，从运算符子图开始到运算符子图近似到运算符输入到运算符。然而，以这种方式选择模型并不总是有效的。例如，尽管运算符子图总体上具有最佳性能，但也有一些实例，尤其是在训练数据不足的情况下，其中这些模型由于过拟合而性能不佳。改进是在验证数据的准确性方面来选择阈值，以决定针对给定子图使用哪个模型。然而，在一些实例中，决定一个具体的阈值以从一个模型切换到另一模型是麻烦的并且可能是不可行的，该另一模型(i)针对所有子图同样有效，并且(ii)在很长的预测窗口内工作。此外，如果模型x的总体训练准确性低于模型y，则可能仍然存在一些类别的查询，其中模型x的性能优于y，反之亦然。这可能是由于诸如缺少一个或多个信息特征、特征值或类别标签中的噪声等因素造成的。实际上，不同模型表现良好的特征空间很难使用阈值或规则来分离，并且追踪每个模型表现更好的子空间也不总是可行的。

通过对来自生产工作负载的超过42K个运算符实例的分析，不同的各个模型的准确性和覆盖范围被观察到。在观察中，针对运算符子图模型，能看出，针对学习过模型的运算符，成本预测大多是准确的。另一方面，运算符模型比运算符子图模型具有相对更多的误差。与运算符子图相比，运算符输入具有更多的覆盖范围，但误差略高。然而，针对一些实例，有人注意到运算符输入模型比运算符子图模型表现更好。这是因为落在这些区域的运算符的训练样本要少得多，从而导致针对运算符子图的过拟合问题。另一方面，运算符输入模型有更多的训练样本，并且因此被观察到在示例中表现得更好。

学习元集成模型。元集成模型被引入，该模型使用来自专用模型的预测作为特征(即，元特征)以及附加特征：(i)基数，(ii)每个分区的基数，以及(iii)输出校正或预测成本的分区数量，如图8所图示的。例如，图8示出了根据示例实施例的生成用于预测查询执行成本的组合模型(例如，资源消耗模型305)的学习模型中的交互。许多机器学习模型被评估为示例生产工作负载中的元学习器(章节III.F.1)，并且发现快速树回归(FastTreeRegression)导致更准确的成本预测。

快速树回归是梯度提升回归树的变型，它使用MART梯度提升算法的有效实现。快速树回归构建一系列回归树，每个连续的树都拟合在它之前的树的残差上。每个树递归地分区由来自各个模型(和原始特征)的预测限定的空间，以创建细粒度的子空间。在每个子空间内，快速树回归输出(i)来自各个模型中的一个模型的预测，或(ii)取决于特征值来学习新的预测。简而言之，在不使用显式分箱或阈值的情况下，快速树回归能够学习各个模型预测、附加特征值和运算符的实际运行时行为之间的复杂依赖。

益处。快速树回归的益处在下面总结。

(1)其中每个模型表现良好的空间的有效表征。每个单独的模型都能够学习问题的一些部分，但可能无法学习整个空间。然而，组合模型可以探索各个学习模型的空间，并且有能力(i)基于其预测的准确性来选择和不信任模型，以及(ii)校正或组合来自一个或多个模型的预测以预测更准确的成本。观察到图8所示的组合模型可以被配置为跨所有模型来捕获有利特性。

(2)对噪声和离群值的稳健性。组合模型利用子采样以构建集成中的回归树中的每个回归树，使其对类别标签中的噪声是有弹性的(例如，先前查询的执行时间)。在一些实例中，观察到组合模型表现更好。而且，注意到特征值误差的影响跨模型而变化，并且组合模型可以被配置为选择受错误特征影响最小的模型。这是因为专用模型可能会取决于其学习的粒度对同一特征进行不同的加权。例如，针对给定的运算符，如果基数估计是错误的，则组合模型可能更喜欢来自运算符子图或运算符输入模型的预测，这些模型更依赖于基础基数(比运算符基数错误更少)。因此，由于特征中的噪声而由一个模型引起的误差可以通过组合中的其他学习器的预测来补偿。与各个模型相比，这也导致更低的差异和更平滑并且稳定的预测。

(3)具有高准确性的全覆盖。组合模型可以能够覆盖所有可能的计划，因为它使用运算符模型作为预测器中的一个预测器。最重要的是，与运算符模型相比，组合模型通常可能具有更高的准确性，并且具有与专用模型的预测可比的预测。而且，当专用模型由于缺乏足够的训练样本而过拟合时，组合模型标识并且改进这种预测，从而提供比专用模型更好的准确性。

(4)可扩展性。组合模型可能足够灵活，以包含附加模型或特征或者利用另一模型替换一个模型。包括默认成本模型也被尝试。然而，在SCOPE上，将默认成本模型添加到集成中并没有导致性能的提高。

限制。快速树回归的缺点是预测很难解释。尽管最近努力使集成模型更具可解释性，但在一些实现中，它们可能会添加系统的复杂性。在这些实施例中，组合模型建立在多个线性模型之上，而这些线性模型转而是可解释的。因此，为了简单起见，特征对各个模型中的每个模型的总成本的贡献被单独示出。事实上，这种方法没有捕获到跨模型的特征的交互，但仍然针对调试提供了足够的见解。

E.优化器集成

本章节描述了本文讨论的学习成本模型与SCOPE查询优化器的双重集成：(i)在查询优化期间，反馈回学习成本模型并且查找它们，而不是默认的模型，以及(ii)使用学习成本模型来扩展用于资源感知优化的查询计划器。

1.反馈和查找

在示例实施例中，训练模型可以基于针对每个集群的过去工作负载轨迹来实施。据观察，两天的训练窗口和每十天的训练频率提供了相当好的准确性和覆盖范围(章节III.F)，尽管这些时间段不旨在以任何方式进行限制。具体地，四个单独模型中的每个模型都可以在第一天独立学习，并且在第二天使用它们的预测以及其他特征来学习组合模型。

一旦模型被训练(例如，由资源消耗模型生成器304)，模型可以作为反馈被提供给优化器，如本文描述的。因此，根据本文描述的示例，以下中的一个或多个可以作为反馈被提供给优化器108：运算符子图模型306、运算符子图近似模型308、运算符输入模型310、运算符模型312和/或组合模型(例如，资源消耗模型305)。在实施例中，模型可以从文本文件、使用附加编译器标志或使用由SQL数据库支持的web服务来序列化和提供。针对集群相关的所有模型都可以被预先加载到散列映射中，以避免在查询优化期间进行昂贵的查找调用。散列映射的密钥可以是不同计划粒度的标识符或签名，如图7所示，对应于模型中的每个模型。

最后，为了在查询优化期间调用学习成本模型，级联框架的优化输入任务(在章节III.B.1中描述)可以被修改。在级联框架中，优化器输入任务是针对其中物理运算符的成本被计算的表达式的最终优化任务。在实现中，图9示出了根据示例实施例的用于资源感知查询计划的方法的流程图。在图9中，示出了本文描述的示例实施例可以如何结合级联框架的优化输入任务来实现，例如在优化器内部来集成学习成本模型。在导出分区计数之后(在下一章节中更详细地描述)，对默认成本模型的调用可以被替换为对学习模型的调用，如图9所示。在示例实施例中，学习模型可以利用的特征可以从由默认模型使用的相同统计集导出。分区计数可能是在一些实例中不会重用的特征中的一个特征。相反，更优的分区计数可以在优化期间确定，因为它与机器数目直接相关，并且因此与查询时延相关。分区选择过程在下面更详细地描述。

2.资源感知查询计划

问题。如早前描述的，分区计数可能是确定运算符成本的重要特征。这是因为并行度(即，所分配的机器或容器的数目)是大规模并行数据库中的关键因素，该并行度可能取决于分区计数。因此，选择正确的分区计数对于优化运算符成本很重要。在SCOPE中，分区计数以及给定阶段的机器数量(同一阶段的所有运算符共享相同的分区计数)可能主要由分区运算符(例如，图10中的针对阶段2的合并)基于本地成本决定。例如，在图10的阶段2中，合并选择分区计数为2，因为它导致最小的本地成本(即，15)。合并之上的运算符(即，减少和输出)导出相同的分区计数，导致针对整个阶段的总成本为305，而总成本的很大部分(即，200)来自减少。在该实例中，分区计数为16而不是2更好：它将减少的成本降低到50，同时仅将合并的成本略微增加到25，从而导致125的低得多的总成本。如所示，因此，不优化针对整个阶段的分区计数会导致次优计划。此外，虽然最优分区计数跨运算符而变化，但是阶段中的所有运算符必须具有相同分区计数的要求进一步使问题变得有意义。因此，当前的优化器应该以微创的方式进行扩展，以通过在查询计划期间有效地探索分区计数来使其具有资源感知能力。

方法。资源感知查询计划方法可以根据实施例来实现(在图9中概述并且在图10中图示)。资源上下文的概念可以首先在优化器上下文内利用，用跨在阶段中的运算符来传递针对分区优化(或更一般地资源优化)所需的上下文。此外，分区探索步骤(更一般地资源探索)可以被添加，其中每个物理运算符将针对不同分区计数的学习成本列表或分析分区计数模型附加到资源上下文。这些分区探索模式中的两种模型在下一章节中更详细地描述。

如图9所示，其是用于资源感知查询计划的方法的流程图，根据示例实施例，如果分区作为来自上游运算符的所需的属性(图9的步骤902)，则分区计数可以被设置为所需的值而不探索(图9的步骤904)，并且子组可以如本文描述的那样优化(图9的步骤910)。

如果分区计数不是来自上游运算符的所需的属性，则分区探索可以被执行(步骤906)。例如，在图10的阶段2中，资源上下文表示出了在优化输入任务开始时由三个运算符中的每个运算符添加的针对不同分区计数的学习成本(图9中的步骤906)。子组可以首先被优化(步骤912)，并且可以确定是否存在分区运算符(步骤914)。在到达阶段边界时，例如分区运算符执行分区优化(图9中的步骤918)以选择阶段最优分区计数，并且资源上下文可以被更新(步骤908)。分区运算符将其本地分区计数设置为所选择的一个。例如，在图10的阶段2中，合并运算符将分区计数设置为16，这有所有运算符而具有成本最低为125。此后，所有上级运算符简单地从分区操作符导出分区计数(图9中的步骤916)，类似于它们在标准查询计划中可以如何导出。阶段最优分区计数然后被用以使用学习模型来估计每个运算符的本地成本(步骤920)，并且成本可以被组合并且返回(步骤922)，这可以导致总体成本更低。

具有对级联框架的三个新抽象(即，资源上下文、资源探索和资源优化)的以上资源感知查询计划还可以包含附加的资源，诸如存储器大小、核心数目和虚拟机(VM)实例类型以及其他基础设施级的决策，以共同优化计划和资源两者。虽然一些实现可能允许这些其他资源被改变，但实现不受此限制。然而，即使这种资源可能未被改变，分区计数仍然可能被改变，这可能是一些分布式系统中的更重要资源中的一个资源。而且，如相关领域的技术人员了解的，本文所描述的实施例还可以被应用于其他自上而下的查询优化器(或通常的其他优化器)，诸如Spark、Flink、Calcite等。

如章节III.F中描述的，资源感知查询计划不仅可以在时延方面生成更好的计划，也可以达到资源节约。然而，一个挑战是针对查询计划中的每个运算符的每个分区计数来估计成本可能会扩大搜索空间，并且使查询计划变得困难。解决这一挑战的方法在下面讨论。

3.有效资源探索

两种技术被讨论以有效地探索分区计数，而无需极大地扩展搜索空间。

基于采样的方法。不是考虑每个单个分区计数，而是仅分区计数的样本被探索，并且具有成本最低的一个样本可以被选择。一个选项是在针对租户或集群的所有可能容器集上考虑统一样本。然而，在考虑到分区对成本的影响时，分区的相对变化可能更感兴趣，例如从1到2个分区的变化预计比从1200到1210个分区的变化对成本的影响更大。因此，分区计数以几何增加的序列进行采样，其中样本x_i+1取决于其先前的值，如下：x_i+1＝[x_i+x_i/s]，其中x₀＝1，x₁＝2并且x_i+1<P_max，此处s是跳跃系数以决定连续样本之间的差距。大s可能导致大样本，并且因此导致更准确的预测。然而，大s也可能会增加预测时间。总体而言，针对m个物理运算符映射和P_max最大可能分区计数，进行5mlog_(s+1)/s P_max成本模型调用。在示例中，观察到s＝2并且样本大小为20，范围为0到3000会产生合理的准确性，并且与具有相同样本大小的均匀和随机采用方法相比，会产生更准确的结果。

基于样本的方法可以是用于探索分区计数的搜索空间。然而，这种方法有两个限制：(i)低采样频率可能会导致分区计数可能远非最优，(ii)高采样频率可以快速增加模型调用的数量，首先针对各个学习模型，然后针对组合模型。因此，一种不同的方法被讨论，它可以更有效地从学习模型中分析地找到单个最优分区计数。

分析方法。在实现中，所学习的各个模型还可以被重用以直接理解分区计数和运算符成本之间的关系。一种见解是，其中只有存在分区计数的特征可能与分区探索相关，而其他特征可以被视为常量，因为它们的值在分区探索期间可用。因此，运算符成本可以被表达如下：

此处，I、C和P分别指的是输入基数、基数和分区计数。在查询优化期间，I、C、I*C是已知的，因此：

直观上，

对应于每个分区的处理成本，并且θ_c*P对应于每个分区的开销。成本随着分区计数中的增加而减少(由于每个分区的处理减少)，但在特定数目的分区之后，通信开销占主导地位，其导致成本增加。跨阶段上的所有运算符(比如在数量上为n)来扩展以上关系，该关系可以被建模为：

存在三种可能的场景：(i)

为负，而

为正：由于不存在增加分区数目的开销，因此针对阶段的最大分区数目可以被实现，(ii)

为正，而

为负：分区计数可以被设置为最小值，因为增加分区计数可能会增加成本，并且(iii)

和

都是正或都是负：最优分区计数可以通过利用对P的请求对成本方程进行微分来导出：

因此，在资源探索期间，每个运算符计算θ_P和θ_c，并且将它们添加到资源上下文。在资源优化期间，分区运算符使用以上公式来计算针对阶段的最优分区，从而避免对学习成本模型的指数调用。总体而言，针对超过P_max分区计数的m个物理运算符，分析模型仅进行5m次模型调用，因子log_(s+1)/sP_max比基于采样的方法小。已经观察到，分析模型仅产生几十次调用，而基于采样的方法取决于跳跃系数可能产生数千次。在章节III.F中，采样策略的准确性与分析模型以及其他抽样策略(诸如，均匀和随机采样)进行了实验比较。

F.实验

在该章节中，学习成本模型相对于默认优化器评估。相同的统计数据(例如，基数、平均行长度)被馈送给由默认成本模型使用的学习模型。实验的目标是四重的：(i)比较学习成本模型在使用不同机器学习模型时的预测准确性，(ii)评估各种采样策略的有效性和寻找最优资源的分析方法(即，分区计数)，(iii)测试学习成本模型在不同测试窗口上的覆盖范围和准确性，以及(iv)使用TPC-H基准和生产工作负载两者来分析由学习成本模型产生的计划的性能。每个都在下面讨论。

1.准确性

与在章节III.B.1中讨论的相同的生产微软工作负载被考虑在内，包括在单天内出现的来自最大客户中的一个客户阿西莫夫的数万个SCOPE作业。默认成本模型与五种最常用的机器学习模型进行比较：(i)弹性网络，正则化的线性回归模型，(ii)决策树回归器，(iii)随机森林，(iv)梯度提升树，以及(v)多层感知器回归器(MLP)。针对模型中的每个模型，相同的特征集在表1和2中描绘，因为在一些实例中没有观察到添加附加特征会导致显着改进。

针对不同机器学习模型的整个工作负载的交叉验证结果被观察到。具体地，成本预测分数的CDF(运算符分数)、针对计划中的每个物理运算符的一个预测以及估计成本与实际运行时间的比率被分析。进行了以下观察。首先，与默认成本模型相比，几乎所有机器学习模型都能产生更准确的结果。其次，线性回归、决策树以及它们基于集成的变型会产生类似的准确性结果。针对具有许多训练样本(>1000)的子图实例，决策树及其基于集成的变型的表现略好于弹性网络。虽然每个运算符模型通常有大量的训练样本，但是其他子图模型的样本较少(<100)。最后，令人惊讶的是，MLP在所有模型中的准确性最差。这又是由于训练样本较少。与其他子图相比，MLP模型的性能相对优于运算符模型，但是仍比其他学习模型差。总体而言，组合模型的50％和95％误差比默认的SCOPE成本模型好10倍和1000倍。

因此，观察到可以从查询工作负载中学习高度准确的成本模型。这些学习模型的准确性与稳健性之间的对比在下面更详细地讨论。

2.稳健性

在一个月的长测试窗口内学习模型在覆盖范围以及准确性和与运行时间的相关性方面的稳健性(在章节III.D中描述)现在将被讨论。覆盖范围可以被描述针对学习成本模型适用的子图的分数。与先前章节中使用的相同的生产工作负载可以被考虑。

不同测试窗口上的覆盖范围。不同子图模型的覆盖范围可以在不同的测试窗口上描述。第一天(第0天)工作负载可以被用于训练各个模型，并且第二天用于训练组合模型。每个运算符和组合模型的覆盖范围可以被认为是100％，因为它们针对每个物理运算符学习一个模型。每个子图模型的覆盖范围是所有模型中最严格的，在实验2天后观察到约为58％，并且在28天后观察到降低到37％。类似地，实验中每个子图近似的覆盖范围在75％到60％之间。另一方面，在测试期间，每个运算符输入模型在78％和84％之间保持更稳定。

不同测试窗口上的准确性和相关性。虽然学习模型的中位误差百分比比默认成本模型预测提高了3至15倍，但是在实验期间观察到95％的误差百分比好三个数量级以上。观察到跨子图学习模型的误差在前两周缓慢增加，此后其增加得更快，尤其是每个子图模型的误差。这是由于子图模型的覆盖范围减少所致。每个运算符模型的误差也在数周内增加，但速率较慢。总体而言，针对子图模型，与中位误差相比，95％的百分位误差百分比变得更差。类似地，与具有非常小的相关性(大约0.1)的默认成本模型相比，来自学习模型的预测成本与实际运行时间的相关性更高，具有高皮尔逊相关性(通常在0.70和0.96之间)。超过1个月的持续时间的高相关性示出，学习模型可以更好地区分两个候选物理运算符。总体而言，基于这些结果，每10天再训练一次应该是可接受的，中位误差约为20％，95％误差约为200％，并且皮尔逊相关性约为0.80。

组合模型的稳健性。组合模型(i)可能具有100％的覆盖范围，(ii)在任何时候都匹配最佳性能的各个模型的准确性，并且与实际运行时间具有高相关性(>0.80)，以及(iii)提供相对稳定的性能，并且长期运行的准确性适度降低。总之，这些结果示出组合模型确实是稳健的。

3.分区探索的准确性

如上面描述的，与由默认优化器用于预测成本的分区计数相同的分区计数已经被使用。各种采样策略(均匀、随机和几何)以及用于找到导致针对给定运算符的最优成本的分区计数的分析模型(在章节III.E.2中讨论)的准确性被评估。从生产工作负载中采用200个运算符的子集，并且0到3000范围内的所有分区计数被探索，以找到针对运算符中的每个运算符的最优成本(即，跨所有分区的最小值)。总体而言，观察到随着样本大小的增加，针对所有采样方法的准确性都会提高。然而，与基于采样的方法相比，分析模型虽然是近似的，但是在样本大小约为15到20之前给出了更准确的结果，具有模型调用要少得多。此外，针对20的样本大小，观察到与均匀和随机方法相比，几何增加的采样策略导致更准确的结果。这是因为当值较小时，几何增加策略需要更多的样本，其中与较高的值相比，成本倾向于发生更强烈的变化。基于每个运算符的分区探索的有效性在前述内容中分析。在下一章节中，分区探索如何帮助产生更有效的执行计划的更全面的分析将被描述。

4.性能

下面描述的性能评估被拆分为两个部分。首先，提出了对TPC-H基准的案例研究，详细解释了由学习成本模型引起的计划变化。然后，生产工作负载的运行时性能被呈现。针对这些评估，新版本的SCOPE运行时被部署在实现本文描述的技术的生产集群上，并且该运行时间的性能与默认的生产SCOPE运行时间进行比较。

I.关于TPCH工作负载的案例研究

TPC-H数据集以1000的比例因子生成，即，总输入为1TB。所有22个查询都运行了10次，每次都利用随机选择的不同参数，以生成训练数据集。成本模型然后在该工作负载上训练，并且学习模型被反馈回以重新运行所有22个查询。具有和不具有反馈的性能被比较。针对每次观察，取3次运行的平均值。总体而言，有7个TPC-H查询改变了计划。在这些中，有5个变化导致了改进时延以及总处理时间，而2个改变导致性能回归。这七个查询中的每个查询的差异在下面描述。

Q8、Q9。针对两个查询，在合并联合部分表的100个分区时，与默认优化器相比，学习成本模型通过选择不同的分区计数来帮助提高性能。Q8将部分与行项表的200个分区联合在一起，而Q9将部分与联合行项和供应方表的输出的250个分区联合在一起。针对两个查询，默认优化器在250个分区上执行合并联合，从而将部分和另一联合输入重新分区为部分键列上的250个分区。然而，利用学习成本模型，合并联合在100个分区上执行，这需要仅对其他联合输入而不是部分表进行重新分区。此外，与将它们重新分区为250个分区相比，将200或250个分区重新分区为100个分区更便宜，因为它涉及部分合并。最后，学习成本模型还将Nations和供应方表之间的联合从合并联合改变为散列联合。总体而言，这些改变使端到端时延提高了10％到15％，并且总处理时间(CPU小时数)提高了5％到8％。

Q16.观察到性能的提高主要是因为相对于学习成本模型的资源意识方面。针对最终聚合和前k个操作，学习优化器和默认优化器两者都根据最终聚合键对来自先前运算符输出的250个分区进行重新分区。虽然默认优化器重新分区为128个分区，但是学习成本模型选择100个分区。由于分区计数的变化，聚合成本的改变几乎忽略不计。然而，结果证明从250到100的重新分区比从250到128个分区的重新分区要快得多，使用学习成本模型在运行时间总体上提高了约25％至30％，并且在处理时间上提高了8％至10％。虽然针对Q8和Q9的改进是通过将分区计数改变为其他联合输入(即，部分表)的分区计数并且跳过代价高昂的交换操作来实现的，但是分区计数已被改变为新数字，这在没有资源意识的情况下将很难实现。

Q20.针对Nations和供应方表之间的联合，学习成本模型将合并联合运算符改变为散列联合，从而将时延降低16％到18％，并将总处理时间提高约10％。

Q11、Q17、Q22。这些查询涉及扫描操作(Q11中的部分、Q17中的行项、Q22中的消费者)紧跟在不同键上的两个聚合之后。针对这种表格，默认优化器应用一种特殊情况，其中它尝试并行扫描同一表格两次，然后根据聚合键来进行分区(如果需要)。然而，学习优化器遵循的典型方法是首先扫描这些表格，并且然后将它们重新分区为两个不同的副本，针对每个聚合一个副本。不进行冗余扫描和并行聚合会导致这些查询的性能回归，针对Q17和Q22的时延分别增加20％和30％，并且处理时间分别增加10％和2％。默认优化器策略的一个缺点是应该有足够数量的机器可用于并行扫描两次，否则扫描中的一个扫描会被阻塞，直到其他并发运行的操作完成并且释放机器。因此，观察到学习成本模型导致针对Q11的性能改进。尽管如此，在开启资源感知后，学习优化器可以使多个扫描运算符与不同的分区计数并行运行，从而有助于防止时延的增加。

在添加资源感知后，Q17仍有10％的开销。这是因为学习成本模型在全局聚合之前添加了本地聚合(不由默认优化器执行)以提高性能。然而，这样做实际上会降低时延，因为它无助于减少数据。此外，虽然当前学习的模型没有从自己的反馈中学习执行轨迹，但是这种学习可能会解决一些回归问题。

II.生产工作负载

来自如先前章节中所使用的相同的生产工作负载的示例性能评估结果在下面提出。如下由于生产资源很昂贵，因此工作负载的子集被选择，类似于先前的工作。具有学习成本模型反馈的作业被重新编译，并且在物理运算符实现中有至少一个改变的作业被选择，例如用于聚合(散列与流分组相对)、联合(散列与合并相对)、分组的添加或移除、排序或交换运算符；过滤出具有默认成本模型计划的冗余扫描运算符的那些，如上面讨论的。17个这样的作业被选择并且执行，利用和不利用对相同生产数据的学习成本模型反馈，同时将输出重定向到虚拟位置，类似于先前的工作。

当使用默认成本模型时，针对作业中的每个作业的端到端时延相对于它们的时延的变化被观察到。在示例中，正变化表示时延减少。与针对TPC-H作业一样，总处理时间(CPU小时数)的变化被分析，以更好地理解这些变化。虽然在大多数时间，这些变化会导致时延的改进，但是存在一些作业会受到这些变化的不利影响。总体，这些作业中约70％的作业的端到端时延的减少被观察到，其中约30％的作业时延增加。

在大规模并行系统中改进延迟的典型策略是向外扩展处理，即，通过增加分区的数目来增加并行度。更高的并行度会增加总处理时间，但是预计会减少端到端时延。感兴趣的是，示例实验示出这种策略并不总是有帮助。资源感知学习模型能够以较低的并行度改进12个作业中的10个作业的端到端时延，从而导致总处理时间大量减少(高达70％)。因此，资源意识具有实现性能提高和成本节约两者的潜力。

开销。即使大量学习模型被构建，这些模型也可以独立并且并行地进行训练和验证。因此，并行模型训练器使用SCOPE以显着加快训练过程。例如，从微软最大的生产集群中的一个集群的超过50K个作业中分析和学习模型只需不到4小时。平均而言，要分析的作业数量要少得多，并且总体训练和验证过程可以在不到2小时内完成。

在优化时间和存储器使用率方面，当使用学习成本模型时，针对大多数作业观察到优化时间增加了大约5％至10％。然而，由于优化时间通常在数百毫秒的数量级，因此与总体编译时间(秒级)以及可以在端到端时延方面实现的潜在增益相比，此处产生的开销忽略不计(大约10分钟)。针对存储器使用，当针对运行超过一千个作业的生产集群同时加载所有学习模型时，大约增加70至90MB被观察到。大约80％的存储器被专用模型占用，其余的由组合模型使用，这在许多大数据环境中没有问题。

5.讨论

可以从查询工作负载中学习准确并且稳健的成本模型。考虑到现代云环境的复杂性和差异，模型准确性不完美。然而，与当前技术相比，它们提供了两到三个数量级的准确性以及相关性从小于0.1到大于0.7的改进。组合元模型进一步有助于在不显着牺牲准确性的情况下实现完整的工作负载覆盖范围。事实上，组合模型在更长的持续时间内始终保留准确性。虽然从学习成本模型中获得的准确性和稳健性增益是明显的，但是对性能的影响却更加微妙。这些通常是由于利用当前成本模型而做出的各种设计决策。例如，SCOPE作业趋于在叶级别过度分区，并且利用可能的大规模向外扩展来改进作业的时延。这种决策可以根据更新的学习成本模型重访。然而，针对工作系统，成本反馈导致回归的情况应该被标识，并且在决定是否首先提供反馈时对其进行推理。如果客户不受一些有限时间回归的困扰，更快的循环可以在针对部署的早期阶段而被训练，以通过反馈回其新成本来自动校正不好的计划。

最后，根据本文所描述的示例实施例，用于选择物理查询计划的成本模型的传统用例被讨论。然而，多个其他成本模型用例与云环境相关，其中预测成本的准确性可能至关重要。示例包括性能预测、对查询分配资源、估计用于调度的任务运行时间、估计查询的进度，尤其是在无服务器查询处理器中，以及运行用于物理设计选择的假设分析。

G.相关工作

本章节总结了本章节的相关工作。

一些早期的工作使用机器学习用于估计集中式数据库中的给定物理计划的查询执行时间。具体地，运算符和子计划级模型与运算符和运算符子图模型共享相似性。然而，两个模型之间的覆盖范围——准确性差距被确定为非常大。为了克服该差距，附加的相互增强模型被描述，并且然后将这些单独模型的预测组合为模型，从而在准确性和覆盖范围方面实现优点。附加地，这些工作都没有考虑集成资源(例如，针对每个运算符找到最优机器数量)，这是云环境中的运算符成本的关键决定因素。存在关于查询进度指示器的其他工作，它们使用来自当前正在运行的查询的运行时统计数据以告诉查询已经完成了多少工作百分比。相反，本文所描述的示例实施例使用编译时间特征，以在执行开始之前进行预测。

基数是成本估计的一个关键输入，并且多种学习和反馈驱动的方法已经被提出。然而，这种方法要么只关注重复出现的子图或严格子图，要么只学习在许多情况下可能出错的实际基数和预测基数之间的比率。重要的是，如章节III.B中讨论的，单独确定基数并不总是导致准确的成本。还有可以确定成本的其他因素，诸如消耗的资源(例如分区)、运算符实现(例如，自定义运算符)和硬件特性(例如，并行分布式环境)。

如果在运行时发现估计的统计数据不准确，则动态或渐进式查询优化通过重新优化计划来应对不准确的成本估计。然而，这种方法有三个主要缺点：(i)已知基数估计误差以指数方式传播，并且在系统可以校正真正不良的估计之前，很多查询可能已经被执行，(ii)调整查询计划，在重新优化的情况下，在分布式系统中是冗长的，因为中间数据需要被具体化(阻止任何流水线执行)，并且被缝合到新计划，以及(iii)针对每个单个查询都会产生开销，因为调整不是在编译时间做出的。相反，本文所描述的技术在编译时间利用反馈，即，使用从过去查询执行收集的统计数据来优化当前查询。

给定物理查询执行计划，多个工作找到最优资源。它们要么训练性能模型，要么利用一些样本运行来应用非参数贝叶斯优化技术以找到最优资源配置。然而，最优执行计划本身可能取决于资源，因此根据本文描述的实现，最优成本和资源可以被共同确定。尽管如此，来自资源优化工作的构思可以在实现中利用以减少搜索空间，尤其是在多种硬件类型被考虑的情况下。

最后，最近的趋势是应用机器学习技术以改进数据系统的不同组件。最突出的是学习索引，它将给定的存储数据过拟合到学习模型，该模型提供更快的查找以及更小的存储占用空间。在一些更具破坏性的方法中，其愿景是将传统的查询优化器替换为使用神经网络来构建的优化器。相比之下，本文所描述的实施例专注于改进运算符的成本估计，并且目标是以微创方式将学习模型集成到现有查询优化器中。

IV.示例移动和静止设备实施例

查询处理系统102、查询生成实体104、查询预处理器106、查询优化器108、查询执行引擎110、(多个)关系数据存储库112、资源消耗学习系统114、查询执行储存库302、资源消耗模型生成器304、资源消耗模型305、运算符子图模型306、运算符子图近似模型308、运算符输入模型310、运算符模型312、逻辑运算符确定器314、物理运算符确定器316、资源消耗评估器318、查询计划选择器320、图6至8和10、流程图200、流程图400、流程图500和/或流程图900所示的任何组件可以被实现在硬件或者与软件和/或固件中的一个或两者组合的硬件中，诸如被实现为计算机程序代码/指令(被存储在物理/基于硬件的计算机可读存储介质中并且被配置为在一个或多个处理器中执行)，或者被实现为硬件逻辑/电路系统(例如，电路包括晶体管、逻辑门、运算放大器、一个或多个专用集成电路(ASIC)、一个或多个现场可编程门阵列(FPGA))。例如，查询处理系统102、查询生成实体104、查询预处理器106、查询优化器108、查询执行引擎110、(多个)关系数据存储库112、资源消耗学习系统114、查询执行储存库302、资源消耗模型生成器304、资源消耗模型305、运算符子图模型306、运算符子图近似模型308、运算符输入模型310、运算符模型312、逻辑运算符确定器314、物理运算符确定器316、资源消耗评估器318、查询计划选择器320、图6至8和10、流程图200、流程图400、流程图500和/或流程图900所示的任何组件中的一个或多个可以单独地或一起在SoC中实现。SoC可以包括集成电路芯片，该集成电路芯片包括以下一个或多个：处理器(例如中央处理单元(CPU)、微控制器、微处理器、数字信号处理器(DSP)等)、存储器、一个或多个通信接口和/或其他电路，并且可以可选地执行所接收的程序代码和/或包括嵌入式固件以执行功能。要注意的是，诸如ASIC和FPGA的电子电路可以被用以加速各种计算，诸如校验和、散列、加密、压缩等。

图11描绘了可以被用于实现如上所述的本文描述的各种示例实施例的示例基于处理器的计算机系统1100。例如，任何的查询处理系统102、查询生成实体104、查询预处理器106、查询优化器108、查询执行引擎110、(多个)关系数据存储库112、资源消耗学习系统114、查询执行储存库302、资源消耗模型生成器304、资源消耗模型305、运算符子图模型306、运算符子图近似模型308、运算符输入模型310、运算符模型312、逻辑运算符确定器314、物理运算符确定器316、资源消耗评估器318、查询计划选择器320和/或图6至8和10所示的任何组件可以在类似于固定或移动计算机实施例中的计算设备1100的一个或多个计算设备中实现，包括计算设备1100的一个或多个特征和/或备选特征。本文提供的系统1100的描述是出于说明的目的提供的，并且不旨在是限制性的。如(多个)相关领域的技术人员已知的，实施例可以在其他类型的计算机系统中实现。

如图11所示，系统1100包括处理单元1102、系统存储器1104和将包括系统存储器1104的各种系统组件耦合至处理单元1102的总线1106。处理单元1102可以包括一个或多个微处理器或微处理器核心。总线1106表示任何的多种类型的总线结构中的一个或多个总线结构，包括存储器总线或存储器控制器、外围总线、加速图形端口以及使用任何的各种总线架构中的处理器总线或本地总线。系统存储器1104包括只读存储器(ROM)1108和随机存取存储器(RAM)1110。基础输入/输出系统1112(BIOS)被存储在ROM 1108中。

系统1100还具有以下驱动器中的一个或多个：用于读取和写入硬盘的硬盘驱动器1114、用于读取或写入可移除磁盘1118的磁盘驱动器1116以及用于读取或写入可移除光盘1122的光盘驱动器1120(诸如CD ROM、DVD ROM、BLU-RAY^TM盘或其他光学介质)。硬盘驱动器1114、磁盘驱动器1116和光盘驱动器1120分别通过硬盘驱动器接口1124、磁盘驱动器接口1126和光盘驱动器接口1128被连接至总线1106。驱动器及其关联的计算机可读介质针对计算机提供计算机可读指令、数据结构、程序模块和其他数据的非易失性存储装置。尽管硬盘、可移除磁盘和可移除光盘被描述，但是其他类型的计算机可读存储器设备和存储结构可以被用以存储数据，诸如闪存卡、数字视频盘、随机存取存储器(RAM)、只读存储器(ROM)等。

多个程序模块或组件可以被存储在硬盘、磁盘、光盘、ROM或RAM上。这些程序模块包括操作系统1130、一个或多个应用程序1132、其他程序模块1134和程序数据1136。应用程序1032或其他程序1034可以包括例如计算机程序逻辑(例如计算机程序代码或指令)，以用于实现查询处理系统102、查询生成实体104、查询预处理器106、查询优化器108、查询执行引擎110、(多个)关系数据存储库112、资源消耗学习系统114、查询执行储存库302、资源消耗模型生成器304、资源消耗模型305、运算符子图模型306、运算符子图近似模型308、运算符输入模型310、运算符模型312、逻辑运算符确定器314、物理运算符确定器316、资源消耗评估器318、查询计划选择器320、图6至8和10、流程图200、流程图400、流程图500和/或流程图900所示的任何组件(包括流程图200、400、500或900的任何合适步骤)和/或本文描述的其他示例实施例。

用户可以通过诸如键盘1138和指向设备1140等输入设备将命令和信息键入到系统1100中。其他输入设备(未示出)可以包括麦克风、操纵杆、游戏控制器、扫描仪等。在一个实施例中，触摸屏结合显示器1144提供，以允许用户经由向触摸屏上的一个或多个点施加触摸(例如，通过手指或手写笔)来提供用户输入。这些和其他输入设备通常通过被耦合至总线1106的串行端口接口1142被连接至处理单元1102，但是可以通过诸如并行端口、游戏端口或通用串行总线(USB)等其他接口来连接。这种接口可以是有线或无线接口。

显示器1144还经由接口(诸如，视频适配器1146)被连接至总线1106。显示屏1144可以显示信息，以及作为用于接收用户命令和/或其他信息(例如，通过触摸、手指手势、虚拟键盘等)的用户界面。除了显示器1144之外，系统1100可以包括其他外围输出设备(未示出)，诸如扬声器和打印机。

系统1100通过网络接口或适配器1150、调制解调器1152或用于通过网络建立通信的其他合适部件被连接至网络1148(例如，局域网或广域网，诸如互联网)。可以是内部或外部的调制解调器1152经由串行端口接口1142被连接到总线1106。如本文使用的，术语“计算机程序介质”、“计算机可读介质”和“计算机可读存储介质”被用于通常指代存储器设备或存储结构，诸如与硬盘驱动器1114、可移除磁盘1118、可移除光盘1122相关联的硬盘以及其他存储器设备或存储结构(诸如，闪存卡、数字视频盘、随机存取存储器(RAM)、只读存储器(ROM)等)。这种计算机可读存储介质与通信介质(不包括通信介质)区分开，并且不重叠。通信介质通常将计算机可读指令、数据结构、程序模块或其他数据具化在调制数据信号(诸如，载波)中。术语“调制数据信号”表示其一个或多个特性以对信号中的信息进行编码的这种方式设置或改变的信号。通过示例而非限制，通信介质包括无线介质(诸如，声学、RF、红外和其他无线介质)。实施例还涉及这种通信介质。

如上面提到的，计算机程序和模块(包括应用程序1132和其他程序模块1134)可以被存储在硬盘、磁盘、光盘、ROM或RAM上。这种计算机程序也可以经由网络接口1150、串行端口接口1142或任何其他接口类型来接收。在由应用执行或加载时，这种计算机程序使系统1100能够实现本文描述的本方法和系统的实施例的特征。因此，这种计算机程序表示系统1100的控制器。

实施例还涉及包括存储在任何计算机可用介质上的软件的计算机程序产品。当在一个或多个数据处理设备中执行时，这种软件使(多个)数据处理设备如本文描述的那样进行操作。本方法和系统的实施例采用现在或未来已知的任何计算机可用或计算机可读介质。计算机可读介质的示例包括但不限于存储器设备和存储结构，诸如RAM、硬盘驱动器、软盘、CD ROM、DVD ROM、压缩磁盘、磁带、磁性存储设备、光学存储设备、MEM、基于纳米技术的存储设备等。

V.附加示例实施例

一种用于评估查询的资源消耗的系统在本文中公开。该系统包括：一个或多个处理器；以及存储程序代码的一个或多个存储器设备，该程序代码被配置为由一个或多个处理器执行，程序代码包括：逻辑运算符确定器，被配置为确定要被执行的查询的逻辑运算符表示；物理运算符确定器，被配置为将逻辑运算符表示变换为用于执行查询的两个或更多个物理运算符表示；资源消耗评估器，被配置为将至少基于查询执行的历史而被训练的多个资源消耗模型应用于物理运算符表示中的每个物理运算符表示，以确定物理运算符表示中的每个物理运算符表示的资源消耗估计；以及查询计划选择器，被配置为基于所确定的资源消耗估计来选择物理运算符表示的一个特定物理运算符表示。

在前述系统的一种实现中，物理运算符确定器被配置为在资源消耗评估器确定物理运算符表示中的每个物理运算符表示的资源消耗估计之前，针对物理运算符表示中的每个物理运算符表示来选择分区计数，该分区计数是至少基于每个物理运算符表示的部分的资源消耗估计来选择的。

在前述系统的另一实现中，多个资源消耗模型中的每个资源消耗模型包括：至少基于与查询执行历史相关联的特征集而被训练的机器学习模型，与每个机器学习模型相对应的特征集被彼此不同地加权。

在前述系统的另一实现中，至少一个资源消耗模型是至少基于先前查询执行而被训练的，该先前查询执行包括：具有公共模式的物理运算符树，作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。

在前述系统的另一实现中，至少一个资源消耗模型是至少基于先前查询执行而被训练的，该先前查询执行包括：具有公共根运算符的物理运算符树，作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。

在前述系统的另一实现中，至少一个资源消耗模型是至少基于先前查询执行而被训练的，该先前查询执行包括具有公共根运算符、叶节点输入的公共集和相同数目的总运算符的物理运算符树，作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。

在前述系统的另一实现中，至少一个资源消耗模型是至少基于先前查询执行而被训练的，该先前查询执行包括具有公共根运算符、叶节点输入的公共集和不同数目的总运算符的物理运算符树，作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。

在前述系统的另一实现中，资源消耗评估器被配置为通过应用从多个资源消耗模型所生成的组合模型来应用多个资源消耗模型。

在前述系统的另一实现中，组合模型是从多个资源消耗模型中的每个资源消耗模型的加权来生成的。

一种用于评估查询的资源消耗的方法在本文中公开。该方法包括：确定要被执行的查询的逻辑运算符表示；将逻辑运算符表示变换为用于执行查询的两个或更多个物理运算符表示；将至少基于查询执行的历史而被训练的多个资源消耗模型应用于物理运算符表示中的每个物理运算符表示，以确定物理运算符表示中的每个物理运算符表示的资源消耗估计；以及基于所确定的资源消耗估计来选择物理运算符表示的一个特定物理运算符表示。

在前述方法的一种实现中，该方法还包括：在确定物理运算符表示中的每个物理运算符表示的资源消耗估计之前，针对物理运算符表示中的每个物理运算符表示选择分区计数，该分区计数是至少基于每个物理运算符表示的部分的资源消耗估计来选择的。

在前述方法的另一实现中，多个资源消耗模型中的每个资源消耗模型包括至少基于与查询执行的历史相关联的特征集而被训练的机器学习模型，与每个机器学习模型相对应的特征集被彼此不同地加权。

在前述方法的另一实现中，至少一个资源消耗模型是至少基于先前查询执行而被训练的，该先前查询执行包括具有公共模式的物理运算符树，作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。

在前述方法的另一实现中，至少一个资源消耗模型是至少基于先前查询执行而被训练的，该先前查询执行包括具有公共根运算符的物理运算符树，作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。

在前述方法的另一实现中，资源消耗评估器被配置为通过应用从多个资源消耗模型生成的组合模型来应用多个资源消耗模型。

一种计算机可读存储器在本文中公开。计算机可读存储器在其上记录有程序代码，在由至少一个处理器执行时，该程序代码使至少一个处理器执行方法，包括：确定要被执行的查询的逻辑运算符表示；将逻辑运算符表示变换为用于执行查询两个或更多个物理运算符表示；将至少基于查询执行的历史而被训练的多个资源消耗模型应用于物理运算符表示中的每个物理运算符表示，以确定物理运算符表示中的每个物理运算符表示的资源消耗估计；以及基于所确定的资源消耗估计来选择物理运算符表示的一个特定物理运算符表示。

在前述计算机可读存储器的一种实现中，该方法还包括：在确定物理运算符表示中的每个物理运算符表示的资源消耗估计之前，针对物理运算符表示中的每个物理运算符表示来选择分区计数，该分区计数是至少基于每个物理运算符表示的部分的资源消耗估计来选择的。

在前述计算机可读存储器的另一实现中，多个资源消耗模型中的每个资源消耗模型包括：至少基于与查询执行的历史相关联的特征集而被训练的机器学习模型，与每个机器学习模型相对应的特征集被彼此不同地加权。

在前述计算机可读存储器的另一实现中，至少一个资源消耗模型是至少基于先前查询执行而被训练的，该先前查询执行包括具有公共模式的物理运算符树，作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。

在前述计算机可读存储器的另一实现中，至少一个资源消耗模型是至少基于先前查询执行而被训练的，该先前查询执行包括具有公共根运算符的物理运算符树，作为物理运算符表示中的至少一个物理运算符表示的物理运算符树。

VI.结论

预测准确的成本对于在大数据系统中寻找有效的执行计划可能很重要。同时，在这些系统中建模查询执行成本可能很困难。在前述内容中，从大型云工作负载中学习成本模型的技术被提出。云工作负载本质上是高度异构的，并且没有一个模型适合所有情况。相反，工作负载中的公共子表达式模式被利用，并且专用模型针对每个模式学习。这些专用模型的准确性和覆盖范围的权衡在前述内容中描述，并且用于克服差距的附加的相互增强模型被提出。来自所有这些单独模型的预测被组合为稳健的模型，该模型可以在足够长的时间段内提供准确性和覆盖范围方面的优点。此外，学习成本模型可以与现有的查询优化框架集成。关于示例集成的细节被提供有SCOPE(级联式查询优化器)，并且学习模型被示出为用于有效地查找查询和资源优化计划。因此，在前述内容中，机器学习可以以实用的方式被应用于查询处理系统的核心。

虽然本方法和系统的各种实施例已经在上面描述，但是它们是通过示例而非限制来提出的。对于相关领域的技术人员名字的是，在不脱离本方法和系统的精神和范围的情况下，形式和细节上的各种改变可以在其中进行。因此，本方法和系统的宽度和范围不应受到任何上述示例性实施例的限制，而应该仅根据以下权利要求及其等同来限定。

Claims (15)

1.一种用于评估查询的资源消耗的系统，所述系统包括：

一个或多个处理器；以及

一个或多个存储器设备，所述一个或多个存储器设备存储程序代码，所述程序代码被配置为由所述一个或多个处理器执行，所述程序代码包括：

逻辑运算符确定器，被配置为确定要被执行的查询的逻辑运算符表示；

物理运算符确定器，被配置为将所述逻辑运算符表示变换为两个或更多个物理运算符表示，以用于执行所述查询；

资源消耗评估器，被配置为将多个资源消耗模型应用于所述物理运算符表示中的每个物理运算符表示，以确定所述物理运算符表示中的每个物理运算符表示的资源消耗估计，所述多个资源消耗模型至少基于查询执行的历史而被训练；以及

查询计划选择器，被配置为基于所确定的所述资源消耗估计来选择所述物理运算符表示中的一个特定物理运算符表示。

2.根据权利要求1所述的系统，其中所述物理运算符确定器被配置为：在所述资源消耗评估器确定所述物理运算符表示中的每个物理运算符表示的所述资源消耗估计之前，针对所述物理运算符表示中的每个物理运算符表示来选择分区计数，所述分区计数是至少基于每个物理运算符表示的部分的资源消耗估计来选择的。

3.根据权利要求1所述的系统，其中所述多个资源消耗模型中的每个资源消耗模型包括：至少基于与所述查询执行的历史相关联的特征集而被训练的机器学习模型，与每个机器学习模型相对应的所述特征集被彼此不同地加权。

4.根据权利要求1所述的系统，其中至少一个资源消耗模型是至少基于先前查询执行而被训练的，所述先前查询执行包括：具有公共模式的物理运算符树，作为所述物理运算符表示中的至少一个物理运算符表示的物理运算符树。

5.根据权利要求1所述的系统，其中至少一个资源消耗模型是至少基于先前查询执行而被训练的，所述先前查询执行包括：具有公共根运算符的物理运算符树，作为所述物理运算符表示中的至少一个物理运算符表示的物理运算符树。

6.根据权利要求1所述的系统，其中至少一个资源消耗模型是至少基于先前查询执行而被训练的，所述先前查询执行包括：具有公共根运算符、叶节点输入的公共集和相同数目的总运算符的物理运算符树，作为所述物理运算符表示中的至少一个物理运算符表示的物理运算符树。

7.根据权利要求1所述的系统，其中至少一个资源消耗模型是至少基于先前查询执行而被训练的，所述先前查询执行包括：具有公共根运算符、叶节点输入的公共集和不同数目的总运算符的物理运算符树，作为所述物理运算符表示中的至少一个物理运算符表示的物理运算符树。

8.根据权利要求1所述的系统，其中所述资源消耗评估器被配置为：通过应用从所述多个资源消耗模型生成的组合模型，来应用所述多个资源消耗模型。

9.根据权利要求8所述的系统，其中所述组合模型是从所述多个资源消耗模型中的每个资源消耗模型的加权而被生成的。

10.一种用于评估查询的资源消耗的方法，所述方法包括：

确定要被执行的查询的逻辑运算符表示；

将所述逻辑运算符表示变换为两个或更多个物理运算符表示，用于执行所述查询；

将多个资源消耗模型应用于所述物理运算符表示中的每个物理运算符表示，以确定所述物理运算符表示中的每个物理运算符表示的资源消耗估计，所述多个资源消耗模型至少基于查询执行的历史而被训练；以及

基于所确定的所述资源消耗估计来选择所述物理运算符表示中的一个特定物理运算符表示。

11.根据权利要求10所述的方法，还包括：

在确定所述物理运算符表示中的每个物理运算符表示的所述资源消耗估计之前，针对所述物理运算符表示中的每个物理运算符表示来选择分区计数，所述分区计数是至少基于每个物理运算符表示的部分的资源消耗估计来选择的。

12.根据权利要求10所述的方法，其中所述多个资源消耗模型中的每个资源消耗模型包括：至少基于与所述查询执行的历史相关联的特征集而被训练的机器学习模型，与每个机器学习模型相对应的所述特征集被彼此不同地加权。

13.根据权利要求10所述的方法，其中至少一个资源消耗模型是至少基于先前查询执行而被训练的，所述先前查询执行包括：具有公共模式的物理运算符树，作为所述物理运算符表示中的至少一个物理运算符表示的物理运算符树。

14.根据权利要求10所述的方法，其中至少一个资源消耗模型是至少基于先前查询执行而被训练的，所述先前查询执行包括：具有公共根运算符的物理运算符树，作为所述物理运算符表示中的至少一个物理运算符表示的物理运算符树。

15.一种在其上记录有程序指令的计算机可读存储介质，包括：

用于使处理器能够执行根据权利要求10至14中任一项的所述方法的计算机程序逻辑。

Images