CN115552390A - 无服务器数据湖索引子系统及应用编程接口 - Google Patents

Abstract

本文描述了提供无服务器、多引擎、多用户数据湖索引子系统和应用编程接口的方法、系统和计算机程序产品。索引被定义为派生数据集，并且以通用格式存储在数据湖上，使不同的引擎能够创建和/或发现用于工作负荷优化的索引。索引的实施例经由包括在索引中并且存储在数据湖上的元数据来实现对索引的状态控制和管理。

Description

无服务器数据湖索引子系统及应用编程接口

背景技术

由商业组织、科学研究人员等产生的所有形式的原始数据量可能相当大，为数百千兆字节的量级。现代系统收集和生成数据的速度往往比对此类数据进行有效分类和管理的速度高出许多倍。在这种情况下，数据湖得到了越来越多的采用。“数据湖”是一个数据存储平台，它被配置为以本地形式存储如此数量的原始数据，无论是结构化的还是非结构化的。数据湖的巨大规模，以及通常数据的非结构化性质，可能会使从数据中收集的所有信息难以得到有效利用。

另一方面，“数据仓库”通常存储结构化的或已处理的数据，这些数据可能更易于操作，用于各种业务智能或研究需求。然而，数据仓库不具有与数据湖近似相同的规模，因此可取回的信息可能更加有限。

然而，总体趋势是湖和仓库的融合。例如，数据仓库产品越来越多地在数据多样性和规模方面提供增强的能力，以接近数据湖的能力。数据湖产品显示，在数据湖中出现了对高效可更新和版本化的关系数据的支持，这些数据具有更改追踪和极具竞争力的超大规模关系查询能力。同样，数据湖产品越来越多地为用于报告、数据协调、安全性、共享、合规性和治理的关系工具链提供支持。

传统数据仓库系统在数据湖系统上提供索引支持的需求历来巨大。虽然有多种方式来提高数据库系统中的查询性能，但索引在为某些工作负荷提供极大的加速方面尤其有效，因为它们可以减少针对给定查询取回的数据量。然而，在分布式数据库系统和/或基于云的架构的上下文中提供索引解决方案会带来一些挑战。例如，采用基于云的模型的关键驱动因素是使用任何查询引擎存储和随后查询数据的灵活性。不幸的是，不同的查询引擎通常不能使用共同索引。

发明内容

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

本文描述了查询引擎和系统，其经由索引规范和不同查询引擎可消耗的API来实现多引擎数据工作负荷优化，以创建、发现和使用存储在数据湖上的可发现位置中并且符合索引规范的索引。在一个示例方面，一种系统被配置为接受以多个数据查询形式的工作负荷，从查询中提取可索引列，从可索引列生成候选索引，选择并且然后构建最佳候选索引，其中构建索引符合索引规范并且被存储在数据湖上的预定位置中。在附加方面，系统中的查询引擎可以接收查询，生成用于该查询的查询计划，其被配置为使用一个或多个所构建的候选索引，并且执行该查询计划以生成查询结果。

在另一示例方面中，构建索引包括索引元数据，该索引元数据描述每个相应的构建索引的内容和谱系并且反映索引的状态。在另一方面，构建索引谱系包括查询计划信息，该查询计划信息与用于创建构建索引的查询相对应。

在另一方面，该系统包括第二查询引擎，其被配置为在数据湖中搜索存储在预定位置处的构建索引，接收查询，生成针对查询的查询计划，基于针对每个构建索引的索引元数据来确定相应的索引是否可以被用于优化查询计划，并且如果是，则优化查询计划以使用相应的构建索引，并且执行优化的查询计划以提供查询结果。

下面参照附图详细描述其他特征和优势以及各种示例的结构和操作。需要注意的是，这些想法和技术并不限于本文描述的具体示例。本文仅出于说明的目的而呈现这些示例。基于本文包含的教导，附加示例对于(多个)相关领域的技术人员而言是清楚的。

附图说明

附图，其并入本文并构成说明书的部分，示出了本申请的实施例，并且与说明书一起进一步用于解释实施例的原理并且使相关领域的技术人员能够制造和使用实施例。

图1示出了根据实施例的示例数据湖系统。

图2示出了根据实施例的数据湖索引和查询系统的分层视图。

图3示出了根据实施例的关于数据湖的索引元数据的示例性分层组织图示。

图4示出了根据实施例的示例数据湖索引和查询系统应用编程接口(API)。

图5A示出了根据实施例的示例索引元数据规范。

图5B示出了根据实施例的、根据图5A的示例索引元数据规范描述的覆盖索引的示例实例。

图6示出了根据实施例的支持无服务器有状态索引操作的示例索引状态机。

图7示出了根据实施例的用于支持无服务器多用户索引操作的并发控制的示例日志操作。

图8示出了根据实施例的示例时间线，该示例时间线示出使用图7的示例日志操作来管理两个用户的并发索引操作。

图9示出了根据实施例的过滤(Filter)索引规则对SQL查询的示例应用。

图10示出了根据实施例的联合(Join)索引规则对SQL查询的示例应用。

图11示出了根据实施例的示例工作负荷和用于生成针对该工作负荷的索引推荐的示例步骤。

图12A示出了根据实施例的使用“what if”实用程序的、基于成本的索引调谐(tune)的架构概览。

图12B示出了根据实施例的“what if”实用程序对SQL查询的示例应用。

图13示出了根据实施例的工作负荷优化系统的详细示意图。

图14示出了根据实施例的在分布式查询处理系统中的第一查询引擎处执行的工作负荷优化的方法的流程图。

图15示出了根据实施例的对图14的流程图的多引擎精化的流程图，其中第二查询引擎优化查询计划以利用在预定位置处发现的预先存在的索引。

图16示出了根据实施例的示例工作负荷优化系统的示意图，其示出了多引擎互操作性的各方面。

图17是其中可以实现实施例的示例计算机系统的框图。

当结合附图时，从下面阐述的详细描述中，实施例的特征和优势将变得更加明显，其中相似的附图标记在整个附图中标识相应的元素。在附图中，相似的附图标记通常表示相同的、功能相似的和/或结构相似的元素。元素首次出现的附图由相应附图标记中的(多个)最左边的数字标识。

具体实施方式

I.导言

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

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

在讨论中，除非另有说明，否则，修改本发明实施例的一个或多个特征的条件或关系特性的形容词，诸如“实质上”和“大约”，被理解为该条件或特性被定义为在该实施例对于其预期应用的操作可接受的容差内。

下面描述多个示例性实施例。需要注意的是，本文中提供的任何章节/小节标题不旨在是限制性的。本文档通篇描述了实施例，并且任何类型的实施例可以被包括在任何章节/子节之下。此外，在任何章节/小节中公开的实施例可以以任何方式与在相同章节/小节和/或不同章节/小节中描述的任何其他实施例组合。

II.示例实施例

本文公开的实施例为数据湖带来了多引擎互操作性，并且可以包括引导式、半引导式或自动索引选择，以允许用户优化其工作负荷。此外，为了降低操作成本，为了进一步实现多引擎互操作性，同时还实现多用户并发性，本文公开的实施例实现了一种“无服务器”索引管理策略。在本节中，我们呈现如图1所示的所公开实施例的操作环境的概述。

图1示出了根据实施例的示例数据湖系统100。数据湖系统100被示出为包括专用于各种高等级功能的通用组件。数据湖系统100包括数据采集器(ingester)112、数据消解器(digester)114、数据建模器和服务器116。数据湖系统100还包括数据湖110，该数据湖110与数据采集器112、数据消解器114以及数据建模器和服务器116相接口，由此使数据能够被写入数据湖110或从数据湖110读取。

概念上，数据采集器112被配置为接受结构化的或非结构化的数据并且将这些数据存储在数据湖110中。这样的数据可以包括例如日志文件102(非结构化)、媒体104(非结构化)、文件106(非结构化)和/或包括任何底层模式(结构化)的业务应用108。请注意，此类数据类别仅是示例性的。诸如数据湖110的数据湖通常被配置为以其本机格式接受并且存储任何类型的数据。通过数据采集器112，数据湖110可以填充有数百千兆字节甚至更多的海量数据。

可以通过数据消解器114以及数据建模器和服务器116的组合操作来实现对如此大量的数据的有效利用。在实施例中，数据消解器114被配置为处理数据湖110上的非结构化数据，以提供其中包含的至少一些数据的结构化或半结构化和精选的视图。此后，许可数据建模器和服务器116可以将这些视图用于各种目的，包括产生业务智能118或其他有用的输出。本质上，数据建模器和服务器116可以被配置为以类似于传统数据仓库的方式操作，但是通过如由数据消解器114处理的整个数据湖。

本文描述的实施例可以以各种方式实现。例如，实施例可以在数据建模器和服务器116之中/之上实现，以提供数据湖索引和查询系统。然而，对于(多个)相关领域的技术人员而言，其他结构和操作实施例将是清楚的。

下面结合示例API描述进一步的实施例以及激发优势。此外，还描述了由实施例提供的辅助数据结构。本文公开的工作负荷优化实施例可以结合多个不同的查询引擎来实现并且使用它们来操作。然而，在本公开的上下文中，结合阿帕奇(Apache)Spark来描述实施例。然而，本领域技术人员将理解，阿帕奇Spark仅仅是示例查询引擎，而不是任何实施例的必要组件。可以存在其他类型的查询引擎。

本文描述的索引系统的实施例可以包括以下优势中的一个或多个优势：

1：对数据格式不可知。为了支持最多样化的场景，索引子系统应该能够以任何格式索引存储在湖中的数据，包括文本数据(例如，CSV、JSON、Parquet、ORC、Avro等)和二进制数据(例如，视频、音频、图像等)。此外，数据被认为是外部管理的，即不假定对数据集的生命周期内的控制。

2：低成本索引元数据管理。为了避免给查询优化器和最终用户带来负担，索引元数据应该是轻量级的、快速取回的，并且独立于第三方目录操作。换言之，索引子系统应该只依赖于数据湖来操作，而不应该假定存在任何其他服务才能正确操作。

3：多引擎互操作性。索引子系统应该使第三方引擎集成变得容易。为了实现这一点，实施例以尽可能透明的方式展示(a)索引状态管理和(b)索引元数据。

4：简单并且有指导的用户体验。索引子系统应该支持多种多样的用户，包括数据科学家、数据工程师和数据爱好者。因此，它应该提供尽可能最简单的体验。

5：可扩展索引。因为提供所有可能的辅助数据结构来帮助查询加速通常是不切实际的，所以我们的索引子系统应该提供更新的辅助数据结构(与索引相关)的易插拔性机制。

6：安全性、隐私和合规性。由于辅助结构(诸如，索引、视图和统计数据)部分或全部复制原始数据集，因此索引子系统应当满足必要的安全性、隐私和合规性标准。

这些优势，特别是多引擎互操作性，通过将索引重新考虑为“派生数据集”而得到了推进。虽然索引传统上是作为数据库管理系统(“DBMS”)内部的辅助数据结构来构建和维护的，但在数据湖中，因为不存在单个“数据库系统”，因此本文描述的实施例将索引视为派 生数据的形式——该数据从一个或多个数据集派生，并且可以可选地由任意查询优化器使用以提高数据取回的速度。将索引视为派生数据集可能只有多个的基本假设：(1)这种派生数据集支持基本生命周期操作，诸如创建、删除、(完全或增量)重建和恢复，以及(2)它们可以用于查询加速(具体地，可以容易地被查询优化器和执行运行时利用和/或集成到其中)。因此，实施例实际上支持任何类型的索引，包括例如覆盖索引、区域映射、物化视图、索引视图(即，物化视图上的索引)、统计和块消除索引。因此，当下文使用术语“索引”时，适当地考虑了上文列举的示例中的每个示例，但是“索引”也可以包括满足上述假设的任何其他类型的派生数据集。然而，出于上下文和完整性的考虑，下面描述数个派生数据集的示例。

覆盖索引。在某些选择列和过滤列在查询中频繁共同出现的情况下，覆盖索引非常有效。它们具有以下属性：

1.非集群--索引与数据是分开的。

2.覆盖--索引包含键列(即，下文中使用的术语“索引列”)和数据/有效负荷列(即，也在下文中使用的术语“包括的列”)；这些数据/有效负荷列从原始数据复制(用于“仅索引”查询访问路径)。

3.柱状--索引以某种柱状格式(例如，Parquet)存储，而不是诸如B树的面向行的格式。这允许利用向量化和最小-最大修剪的技术来加速对索引的扫描。

通过将查询中的所有列作为键列或非键列包括在覆盖索引中，可以显著提高查询性能。附加物理布局属性(诸如，分块、分区和排序顺序)可以加快过滤和联合的主力操作符的速度，这些操作符通常主导查询执行时间。在实施例中，用户标记为“索引列”的所有列都可以被分块并且(可选地)被排序。

块消除索引。对于高度选择性的查询(例如，在数十亿中搜索单个GUID)，可以有利地采用被称为“块消除索引”的索引类别。块消除索引类似于传统的倒排索引，不同之处在于指针是引用块的任意URI(而不是row_id)，块是存储在数据湖中的可寻址数据的合理单元(例如，单个Parquet文件或大型CSV文件内的偏移量范围)。优化器可以利用该索引以快速消减查询的不相关块。

物化视图。对于具有联合或聚合的昂贵查询，可以将物化视图创建为派生数据集。然后，底层查询优化器可以透明地使用这些物化视图。

统计数据。在具有基于成本的查询优化器的环境中，实施例可以先验地收集感兴趣的列的统计数据(例如，直方图)。然后，有能力的优化器可以在运行时利用这些统计数据来优化资源。

受益于上述优势和背景，更详细的描述现在转向根据实施例的数据湖索引和查询系统的架构概述。更具体地，图2示出了根据实施例的数据湖索引和查询系统的示例分层视图200。如图2所示，数据湖索引和查询系统200包括数据湖202、索引基础设施208、查询基础设施224和面向用户的索引管理API的集合226。索引基础设施200提供并包括日志管理API214、索引规范212、并发模型216以及在这些之上的索引创建和维护API的集合210。数据湖索引和查询系统200的查询基础设施224包括优化器扩展的集合222、索引推荐系统220和“what-if”实用程序218。基于如图2所示的关于数据湖索引和查询系统200的以下讨论，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

在实施例中，用户可以利用索引基础设施208(作为服务或库可用)来通过索引创建和维护API(在下文中进一步描述)来在其数据上创建和维护索引(或“派生数据集”)。例如，索引基础设施208可以被实现为对阿帕奇Spark的sparkSession对象的一个或多个扩展，并且其中用户可以使用适合的数据访问客户端(例如，spark-shell)来创建非集群的柱状覆盖索引、指定要在其上创建索引的列、以及要包括作为数据列的列，即利用如下查询：CREATE INDEX myCoveringIndex ON dirLocation1 INDEX(a,b)INCLUDE(c)。注意，实施例不需要分离的“索引服务”，因为索引基础设施208原则上可以利用任何可用的查询引擎(例如，Spark)进行索引构建。如下文更详细地描述的，索引及其元数据被存储在数据湖本身上，因此，用户可以将索引扫描并行化到他们的查询引擎规模和他们的环境/业务允许的程度。

在实施例中，索引元数据维护由索引管理器(图2中未示出)来管理，该索引管理器通过索引创建和维护API 210而被控制。当索引数据发生相应修改时，索引管理器负责索引元数据创建、更新和删除，从而管理索引数据和索引元数据之间的一致性。索引管理器还提供从其序列化格式读取索引元数据的实用程序函数。例如，查询优化器可以读取所有索引元数据，然后找到针对给定查询的最佳索引。

实施例还可以启用构成索引创建和维护API 210的基础的原语组件。例如，这样的原语组件可以包括日志管理API 214、索引规范212或并发模型216中的任何项或全部。

如上所述并且在下面更详细地描述的，对多引擎互操作性的支持激发了将所有索引及其元数据存储在湖上的需要。为了追踪在索引上发生的操作的谱系，实施例将用户操作记录在操作日志中，如下文更详细地描述的，并且可以通过日志管理API 214来这样做。

索引规范212支持上述可扩展性优势，因为实施例涉及反映对应的底层索引(或派生数据集)的属性的索引规范212。这些优势是经由索引创建和维护API 210展示的，并且那些希望扩展系统以包括其他类型的索引/派生数据集的优势必须实现对这些API的支持。

最后，并发模型216展示了使用乐观并发控制来支持多用户和增量维护场景的原语(如下文进一步描述的)。

现在讨论转向数据湖之上的另一主要层，即查询基础设施224。在不丧失一般性的情况下，查询基础设施224的组件在本文被描述为作为Scala版本库来实现，作为阿帕奇Spark查询优化器(又名，Catalyst)的扩展，以使其知道索引。也就是说，给定查询和现有索引，利用Spark实现的实施例可以执行透明查询重写以利用现有索引。要在用户侧启用优化器扩展222，需要在创建Spark会话之后执行sparkSession.enableIndexingSubSystem()。由于实施例将索引视为湖上的另一数据集，因此用户可以利用Spark的分布式性质来自动缩放索引扫描。尽管上文和下文在Spark和Scala方面描述了实施例，但是应该理解，其他实施例可以使用Scala以外的编程语言以及Spark以外的查询引擎。

虽然本文描述的实施例引入了在数据湖上索引的概念，但严重影响性能的大数据管理的重要方面是针对给定查询或工作负荷选择要构建索引的能力。要决定针对工作负荷的正确的索引，对用户来说至关重要的是能够对现有索引和他们脑海中的任何“假设”索引执行成本效益分析。因此，查询基础设施224包括允许用户定量地分析现有的或假设的索引对系统性能的影响的“what if”实用程序218。此外，查询基础设施224还包括索引推荐模块220，其展示用于在大数据工作负荷的查询加速中自动选择索引的自动索引推荐。该工具将SQL查询的工作负荷作为输入，并且建议适合的索引集合。下文将更详细地描述索引推荐模块220和“what if”实用程序218的实现细节。

如上所述，实施例在数据湖本身上存储所有索引数据和元数据，而不存在任何外部依赖性。图3示出了根据实施例的关于数据湖上的索引元数据的示例分层组织图示300。基于如图3所示的关于分层组织图示300的以下讨论，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

在一个实施例中，如图3所示，所有索引可以被存储在文件系统根302处。根据所采用的索引，这样的布置可能是有利的。例如，索引可以包括物化视图，其本身可以跨越数据集，这转而需要将数据集与索引解耦合。然而，在另一实施例中，索引可以与数据集同位。实施例可以实现细粒度的访问控制机制，例如，从作为索引的数据集中复制最严格的访问控制列表(ACL)，以实现较严格的安全性和合规性。因为我们允许禁用公共索引的概念，所以用户可以自由地使用“索引集”向优化器提供提示，从而允许进行A/B测试。

然而，应当理解，文件系统根302的使用仅是示例性的，并且可以在例如如上所述的索引规范212中指定另一默认索引位置。更具体地，部分地通过索引规范212来实现多引擎互操作性，其使得知道并且遵守索引规范212中阐述的规范查询引擎和其他客户端能够预先知道索引存储的默认位置，从而允许这些引擎和客户端发现可能已经存在的索引的可用性，并且此后构建并入这些索引的查询计划。

继续参考图3，/indexes/*/<index name>下面列出的每个索引具有两个组件：

1)名为_indexing_subsystem_log的目录308，其包含索引的操作日志，即该索引自创建以来发生的所有操作的列表；以及

2)索引的实际内容322。

请注意，内容被捕获在多个目录中。这是为了支持诸如并发索引管理(例如，快照隔离)和增量维护(例如，最新索引是多个目录的内容的联合)的功能。

图4示出了由实施例在阿帕奇Spark的上下文中展示的示例数据湖索引和查询系统应用编程接口(API)400。请注意，该列表仅是示例性的，并且不应被解释为对每个引擎或每个实施例的要求。基于如图4所示的关于API 400的以下讨论，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

API 400在第2至8行包括索引维护API，其包括对应于诸如创建、删除、恢复、清空、重建(有时被称为“刷新”，尤其是当重建是递增时)和取消的动作的API。在实施例中，第4行的删除索引(deleteIndex)API对应于告诉优化器在优化期间不考虑该索引的“软删除”。API调用引用的实际索引不会被永久删除，因此允许用户使用恢复索引(restoreIndex)API恢复已删除的索引，如第5行所示。备选地，用户可以使用清空索引(vacuumIndex)API永久删除已处于软删除状态的索引，如第6行所示。第7行的重建索引(rebuildIndex)API实现前面提到的重建/刷新操作。如第8行所示，用户可以使用删除索引(cancelIndex)API取消正在进行的索引维护操作，如果用户怀疑维护作业停滞或失败，这可能会很有用。

API 400还包括用于调试和推荐的实用程序API，如第11至15行所示。这些API分别称为解释、whatIf和推荐，如第11、12和14行所示。解释API允许用户从优化器获得各种有用的信息，例如，修改了计划的哪部分、选择了哪些索引、为什么选择它们等等。whatIf API允许用户向索引子系统提供样本索引配置，并且了解如果构建索引将有多大用处。推荐API允许用户获得可以针对他们选择的工作负荷构建索引/视图的排名推荐。

API 400还包括存储和查询优化器定制配置设置，如第18至21行所示。这些设置允许用户覆写查询优化器和索引管理的行为。例如，默认情况下，创建的每个索引都是可发现的，被存储在公共文件夹或文件系统根目录下，如上所述，使其可由工作空间等级的所有用户访问。如果这是不可接受的，并且因为索引仅对创建它们的用户可访问，则用户可以选择私有索引位置和名称空间，然后创建它们的私有索引，并且在优化期间向优化器提供提示(例如，通过设置配置变量

indexing_subsystem.index.creation.[path|namespace]

和/或

indexing_subsystem.index.search.disablePublicIndexes.

在描述了实施例中可用的各种API之后，现在将讨论转向由所公开的实施例实现的无服务器索引管理。如上所述，一优势是低成本的多引擎索引子系统，它允许对由多个引擎可调用的索引执行并发索引维护操作。尽管实施例可以用服务器来实现以中介这种操作，但是本文描述的其他实施例可以通过使索引管理“无服务器”来简化实现，即实施例不需要专用于索引管理任务的独立服务器。部分地，通过将所有索引信息(例如，元数据、对索引的操作)存储在数据湖中，并且通过合并到索引中的索引操作日志以及通过对其自己的元数据的其他更新来使该索引追踪其自己的状态，来实现无服务器功能。尽管是无服务器的，但实施例通过乐观(optimistic)并发控制来实现并发更新(如下文更详细描述的)。对实施例的进一步描述现在转向对这些方面中的一个方面的进一步描述：湖上的索引元数据。

互操作性是复杂的，因为每个查询引擎必须就什么构成索引达成一致，这可能需要在不同竖井生态系统中工作的开发人员(和组织/公司)之间达成一致。因为后一个问题在现实中要难得多，所以本文描述的实施例优先考虑用于以一种允许轻松集成的方式展示索引相关元数据(例如，内容、状态等)的低摩擦配置。通过传统方式(诸如，目录服务或事务管理器服务)展示索引的状态或在索引上调用的操作列表，确保了强一致性。然而，这种方法有数个主要的操作影响。首先，它带来了服务依赖性和现场支持管理费用。其次，这使得集成变得复杂，因为现在每个新引擎都必须依赖于第三方服务。最后，它引入了运行该服务的操作成本。

考虑到这些缺点，本文描述的实施例权衡了元数据一致性以便于操作维护，即索引的信息的基准真相被存储在数据湖上。有多种方式来指定需要存储的索引信息。例如，图5A示出了根据实施例的示例索引元数据规范500。索引元数据规范500包括三个部分：内容504、谱系506和状态508。基于如图5A所示的以下讨论索引元数据规范500，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

内容504可以包括在实例化适当的索引解释逻辑时有用的派生数据集的类型和类型特定信息，诸如名称、种类、配置(例如，索引和包括的列及其类型)、内容(例如，物理位置和布局)。

谱系506可以包括用于追踪派生数据集的谱系的信息，例如，被索引的HDFS数据源、用来自用户的最少信息来刷新索引所需的信息、执行索引/视图选择所需的信息、以及索引的描述性历史。谱系还可以包括关于在构建索引时应用于一个或多个数据源的任何附加变换的信息(例如，在索引之前应用的过滤，例如，WHERE Col1 IN(“user1”,“user2”)或类似过滤)。

状态508可以包括关于派生数据集的状态信息，例如，诸如活动和禁用的全局信息，以及诸如创建和删除的瞬时信息。

图5A还包括操作日志510。下面结合多用户并发控制的描述更详细地描述操作日志510。

图5B示出了根据实施例的根据图5A的示例索引元数据规范500描述的覆盖索引502的示例实例。本领域的技术人员将容易地理解覆盖索引502的大部分元数据。然而，首先要注意的是，所有元数据都以易于阅读的JSON格式存储，这减少了对于查询引擎集成的依赖性，并且其通过版本控制字段提供了对规范演进的支持。还请注意源节点512下的计划节点514。计划节点514还包括作为计划节点514的属性的rawPlan节点516。rawPlan节点516是用于覆盖索引502的原始查询计划信息。例如，在Spark的情况下，rawPlan节点516是逻辑计划的串行化表示。

在覆盖索引502的rawPlan节点516中包括原始查询计划信息提供了多个优势。首先，原始查询计划实现对透明索引刷新的支持(例如，通过调用上面关于图4描述的rebuild()API)，而不需要用户提供在创建索引时使用的原始查询。其次，它允许查询引擎决定在优化期间是否利用该索引。例如，并且回想实施例包括多引擎支持，查询引擎可以检查索引的原始查询计划并且发现该索引是使用不受支持的散列函数创建的，因此从任何优化计划中忽略该索引。第三，包括原始查询计划对于调试是有用的。

覆盖索引502还包括状态节点518，如上所述，状态节点518追踪索引的状态，从而使得实施例能够是无服务器的。在无服务器范例下，有多种管理索引状态的方式。例如，图6示出了根据实施例的支持无服务器有状态索引操作的示例索引状态机600。状态机600包括以下瞬时状态：创建602、恢复604、删除606、刷新608和优化610。状态机600还包括以下稳定状态：活动612、已删除614和空/DNE 616(其中‘DNE’＝‘不存在’)。基于如图6所示的索引状态机600的以下讨论，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

因为实施例是以无服务器范例实现的，所以当然没有服务器来维护或追踪索引状态。因此，实施例通过根据图6的索引状态机600中示出的状态转换来管理索引状态。注意，状态活动612、已删除614和空/DNE 616是稳定状态，而其他状态是转换状态。这些状态转换如下所述：

创建602：假设不存在索引，则状态机在状态空/DNE 616开始。当用户如以上结合图4描述的那样调用createIndex()API时，被创建的索引从状态空/DNE 616进入状态创建602。如果由于某种原因，当索引仍处于状态创建602时，用户通过发出cancelIndex()API来取消索引创建，则索引返回到状态空/DNE 616。

活动612：一旦索引创建成功，则索引转换到状态活动612并且变为可见(当索引处于状态创建602时是不可见的)。索引通常将其大部分时间花费在状态活动612中。

刷新608：可以经由上述rebuildIndex()API来刷新/重建现有索引。尽管术语刷新和重建在本文中基本上可互换使用，但术语“刷新”通常应用于增量重建。注意，刷新不会阻止索引可见性——在刷新完成之前，索引的消费者可以继续访问索引的当前活动副本。

删除606：用户可以使用上述deleteIndex()API来删除索引。在删除操作期间，索引进入状态删除606。如上所述，删除操作只是软删除(为了速度)，并且具有使索引不可见/不可用的效果。

已删除614：在完成deleteIndex()调用后，索引进入状态已删除614。

恢复604：因为删除只是软删除，所以restoreIndex()命令可以恢复索引，此时索引进入状态恢复604，并且在完成时，索引再次进入状态活动612。同样，当索引处于恢复状态时是不可见的。

优化610：用户可以进一步选择经由optimizeIndex()API来优化索引。例如，一种优化是索引压缩，其中增量生成的(小的)索引块被合并成更大的索引块，以提高索引读取效率。

在多用户场景中，显然一些索引状态彼此冲突(即，索引不能同时呈现不同用户的某些状态)。例如，如果索引在一个用户会话中处于状态删除606、刷新608或优化610，则不能在另一并发用户会话中同时处于状态恢复。这是可以理解的，因为索引只能从活动612移动到删除606、刷新608或优化610，而它只能从删除606进入恢复604。如果两个API调用可能导致索引状态冲突，则它们是不兼容的。表1示出了本文公开的API的兼容性矩阵，并且示出了一个用户的API调用(例如，当读取时)与第二用户(向下读取)的API调用不兼容，其中C＝创建、D＝删除、O＝优化、RF＝刷新、RS＝恢复和V＝清空。

API

C

D

O

RF

RS

V

C

Y

N

N

N

N

N

D

N

Y

Y

Y

N

N

O

N

Y

Y

Y

N

N

RF

N

Y

Y

Y

N

N

RS

N

N

N

N

Y

N

V

N

N

N

N

N

Y

表1：索引管理API的兼容性矩阵

尽管表1防止索引在两个不同的用户会话中达到不兼容状态，但它不能防止两个不同的用户尝试对索引进行冲突的更改。为了解决该问题，实施例通过乐观并发控制来确保索引一致性。如上所述，实施例实现利用根据图7的示例日志操作700的乐观并发控制方案。示例日志操作700包括LogOp()702、Validate()704、Begin()706、RunOp()708、Commit()710和提交协议712。这样的操作使用图5A的操作日志510来执行，并且本文描述如下：

·LogOp()-记录用户将要尝试操作日志510的索引操综

·Validate()-验证索引是否处于允许所需操作的适合状态(例如，不能删除不存在的索引)

·Begin()-将id分配给具有对应转换状态的索引操作

·RunOp()-将所需操作现在正在运行记录到操作日志510

·Commit()-将完成的索引操作的id记录到操作日志510，包括对应的最终稳定状态

Commit()依赖于在云文件系统(例如，HDFS、Azure Storage或Azure Data Lake)中重命名文件的原子性，以确保在Commit()期间将索引状态从转换状态改变为稳定状态是原子的。例如，如果在提交期间，对应于索引转换状态的文件被重命名，则作为整体的提交和事务可以被中止(如提交协议712中所描述的)。在接收到中止消息之后，可以稍后再次尝试该事务。

图8的时间线800中示出了使用图7的示例日志操作来管理两个用户的并发索引操作的示例事务。时间线800从左向右前进，其中最初在步骤802处创建索引，并且在步骤804处添加数据。在步骤806处，用户(用户1)尝试刷新现有索引。几乎同时地，在步骤808处，另一用户(用户2)试图删除相同的索引。假设删除是昂贵的(即，耗时的)，则来自用户1的刷新在步骤810处成功地首先完成。当用户2的删除尝试提交时，日志反映索引的状态改变(由于用户1的刷新)的事实，并且在步骤812删除失败。

实施例被实现为允许使用上述并发控制机制的多个写入器和多个读取器。针对索引的读取器，通常已提交的索引数据的任何稳定快照就足够了。为了确保索引与被索引的对应数据之间的一致性，实施例可以采用基于签名的机制，由此使用数据文件的最新时间戳来生成索引的签名(例如，如图5A所示的签名520)。如下文更详细描述的，在查询处理期间，查询可能同时触及表和其索引。使用存储在索引元数据中的数据的签名，优化器可以确保索引不会过时。在无服务器的体制中，通常不可能保证完美的外部一致性。例如，查询可能正在访问自从使用索引的签名520验证数据以来已经更新的数据，并且不存在对资源的锁定。相反，必须在查询引擎等级处支持外部一致性——即，只有当查询引擎可以展示这样的API时，才能支持外部一致性。

上述描述提供了索引和对应的生命周期API的框架。当然，除非可以在查询时利用这些索引，否则这些索引是没有用的。因此，必须让查询引擎的查询优化器知道索引的存在和格式，并且使其能够正确处理此类索引。如下文更详细地描述的，实施例通过将新规则合并到Spark的基于规则的查询优化器中来利用索引。具体地，过滤和联合索引规则被定义，并且可以用于优化给定查询的查询计划，以使用可用索引。在下一节中，我们首先讨论索引对查询执行的影响。然后，我们介绍了索引规则的实现和集成的细节。将索引规则集成到其他类型的查询优化器中，例如遵循Starburst、Volcano或Cascades架构的查询优化器将是类似的。

如上所述，本文描述的实施例集中于查询处理中的两个主力Spark操作符，即过滤和联合，仅仅是为了说明概念(即，也可以以类似的方式优化其他操作符，例如聚合和分组)。更具体地，实施例实现两个查询优化器规则，即FilterIndexRule(过滤索引规则)和JoinIndexRule(联合索引规则)，它们的目标是在如上所述使用索引的Spark查询执行计划中加速过滤和联合操作符。实施例通过消除数据分区以及通过按索引列对索引数据进行分块(即，使用散列函数进行分区)来产生过滤索引，从而有利于过滤操作符的性能。因此，这样的索引可以显著减少具有引用索引列的相等谓词(即，点查找)的过滤要访问的数据量。

在索引列与联合键匹配并且优化器选择使用基于混洗的联合(例如，散列联合或排序-合并联合)的情况下，这样的索引可能同样有益于联合操作符的性能。在这种情况下，由于索引的分块，联合的混洗阶段可以完全避免。众所周知，在分布式大数据处理中，混洗操作很昂贵，并且消除或最小化这种混洗通常会提供大量的性能优势。

尽管本文未描述，但这样的索引对于其他操作符也是有益的，例如在分组之上的聚合等等。下文我们正式定义了FilterIndexRule和JoinIndexRule。

FilterIndexRule的工作原理如下：如果表扫描的顶部有过滤f，如果满足以下条件，我们将其替换为索引I：

·I的索引(键)列中的前导列被f中的某个谓词引用；

·由f中的谓词引用的所有列都被I覆盖，即出现在I的索引列或包括的列中。

考虑图9中的示例，其示出了根据实施例的由查询优化器对SQL查询的过滤索引规则的示例应用900。示例应用900假定输入配置902，其包括表904、查询906和索引908。索引908包括单个索引F₁，它是过滤索引。索引F₁包括索引列R.a(即，R.a是由下划线表示的索引F₁的键列)和包括的列R.b。在接收到查询906之后，作为响应，查询优化器可以生成原始查询计划912。索引规则首先在查询计划中搜索模式的匹配

扫描->过滤。

在从查询906生成的原始查询计划912中，存在两个这样的匹配：

(M1)扫描(R)->过滤(R.a＝5)；

(M2)扫描(S)->过滤(S.d>200)。

对于每个匹配，索引规则指示查询优化器进一步检查是否有满足条件的索引，并且如果有，则用相应的索引替换表扫描。在我们的示例中，只有匹配(M1)有这样的索引：索引F₁，它被定义为具有等于R.a的索引列。结果，表R顶部的扫描操作符被替换为索引F₁顶部的扫描操作符，从而产生优化的查询计划914。

JoinIndexRule的工作方式与此类似，它通过模式匹配查找候选索引。但是，与FilterIndexRule不同的是，除了仅匹配单个联合操作符之外，不可能匹配特定模式。当找到匹配的联合操作符时，检查它是否满足等联合条件，即被限制为联合列之间的相等谓词的连词的联合条件。

将符合条件的联合操作符O与联合条件c匹配后，下一步是查找针对O的可用索引。给定联合的左子计划和右子计划两者都是线性的，则计划树中O下只有两个基本表。对于每个基本表T，在T的顶部针对每个候选索引I检查以下条件：

c引用的T中的所有联合列都应该与I的索引列相同；

访问T的左子计划或右子计划引用的所有其他列都包含在I的包括的列中。

更正式地，假设

和

分别是针对左子计划和右子计划找到的候选索引。通过执行以下兼容性测试，可以进一步配对索引：

考虑索引

和索引

如果I_l的索引列(K_l1，…，K_ln)和I_r的索引列(K_r1，…，K_rn)是逐对关联的，即每个列对(K_lj，…，K_rj)出现在等联合谓词K_1j＝K_rj中，则两个索引的对(I_l，I_r)是兼容的。请注意，I_l和I_r必须具有相同数目的索引列。

上述兼容性测试可以通过示例来理解：

考虑以下查询：

SELECT A,D FROM T1,T2

WHERE T1.A＝T2.B AND T1.C＝T2.D

假设我们有两个索引，T1上的I₁<(A,C)；()>和T2上的I₂＜(B,D)；()>。则(I₁,I₂)是兼容的。如果，不是I2，我们有索引I′₂<(D,B)；()>，则(I₁,I′₂)是不兼容的。

可能存在多于一个兼容性索引对。在一个实施例中，可以基于以下标准来选择导致最小执行成本的索引对：

·如果存在兼容的索引对(I_l，I_r)，使得I_l和I_r具有相同数目的块，

则选择具有最大数目的块的索引对。

·否则，如果不存在这样的索引对，则从符合条件的索引对中选择任意索引对。

使用这些标准有多个原因。首先，当两个索引具有相同数目的块时，在执行(排序-合并)联合时不会出现混洗。也就是说，如果块的数目不同，则将一个索引重新混洗为与另一相同的块数目。其次，一般而言，块数目越多，联合执行的并行性就越好(假设没有资源限制)。

最后，JoinIndexRule将表顶部的扫描操作符替换为最佳兼容索引对中相应索引顶部的扫描操作符。例如，考虑图10，其示出了根据实施例的对SQL查询的JoinIndexRule的示例应用1000。示例应用1000包括基于图9的配置902的输入配置1002。具体地，输入配置1002包括来自图9的表904和查询906。输入配置1002还包括基于图9的索引908的索引1008，但它现在包括两个联合索引J₁和J₂。

然后，根据上面的描述进行JoinIndexRule的应用。具体地，因为现在有两个联合索引J₁和J₂，所以查询计划912可以检查符合条件的联合操作符。这里，查询计划912包括具有联合条件R.b＝S.c的联合操作符1010。接下来，检查联合的左子计划和右子计划是否有候选索引。我们发现索引J₁适用于左子计划(由于在过滤操作1012中存在列R.a)，并且索引J₂适用于右子计划(由于在过滤操作1016中存在列S.d)。显然，(J₁，J₂)是唯一兼容的候选索引对。结果表R和表S之上的扫描操作符可以分别由J₁和J₂顶部上的扫描操作符替换，从而产生优化的查询计划1014。

如上所述，FilterIndexRule和JoinIndexRule定义允许查询引擎优化查询计划以利用对应索引的规则。然而，必须将此类规则的使用集成到查询引擎中。如上所述，本文的实施例是在Spark查询引擎(又名，Catalyst)方面描述的。作为基于规则的查询优化器，集成这些规则很简单，并且主要包括将索引规则合并到优化器采用的规则中，需要做出两个决定：在哪里包括新规则，以及以什么顺序应用新规则。

在哪里包括规则？将新规则放在错误的位置可能会由于规则之间的潜在相互作用和副作用而导致不想要的后果。然而，本文描述的实施例仅用符合条件的索引替换基本表，这对逻辑计划中的下游操作符没有影响。因此，可以在所有其他优化器规则之后(即，在查询优化器已经以其他方式完成逻辑查询计划之后)应用新规则。

规则的顺序是什么？因为FilterIndexRule和JoinIndexRule各自都是在所有其他规则之后应用的，所以顺序有点随意，并且可以按任一顺序进行。然而，实施例可以受益于将JoinIndexRule放在FilterIndexRule之前，因为可以预期用于联合的索引可能导致更多的改进。

在描述了索引子系统的架构、索引的生命周期管理以及在查询中有效地利用这种索引之后，下面的描述转向以下问题：给定已知的查询工作负荷，创建什么(多个)索引将是最有益的？

下面描述的实施例提供了以两个主要步骤操作的索引推荐框架：

1)候选生成–基于查询工作负荷的特性生成候选索引；以及

2)最佳索引的选择–使用基于规则的方法或基于成本的方法来选择候选索引中的最佳索引。

由此，给定查询工作负荷，创建候选索引集合，并且选择该集合中的最佳索引并且将其推荐用于构建(或者，备选地，自动构建)。

参考图11进一步探索该两步骤过程，图11示出了示例工作负荷1100和用于针对工作负荷1100生成索引推荐的示例步骤1102。工作负荷1100包括查询1104，其包括查询Q1和查询Q2。与工作负荷1100一起示出的还有以表1106的形式示出的被查询的数据源。示例步骤1102包括步骤1108至1112，分别指向步骤1：候选生成，步骤2：搜索最佳索引配置和步骤3：推荐输出。步骤1108包括子步骤1a和子步骤1b。同样，步骤1110包括子步骤2a和子步骤2b。基于如图11所示的以下讨论示例步骤1102，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

图11的步骤1108的候选生成的主要想法如下：

1.检查工作负荷1100的每个查询以确定可索引列(例如，在步骤1a)；以及

2.使用a来构建候选索引(例如，在步骤1b处)。

在实施例中，候选生成可以根据以下所示的算法1进行：

算法1

算法1继续参考图11的候选生成步骤1108来描述。实施例可以被配置为确定本领域中已知的不同类型的可索引列。在一个特定实施例中，算法1从查询q中提取以下可索引列：

ε-出现在q的相等谓词(即，x＝a，其中x是列，a是常量)中的列(算法1的第4行)；

-出现在q的相等谓词(即，x≤a或x≥a，其中x是列，a是常量)中的列(算法1的第5行)；

-出现在q的等联合谓词(即，R.x＝S.y，其中R和S是表)中的列(算法1的第6行)；

-出现在q的分组列表(即，分组为x₁,…,x_m)中的列(算法1的第7行)；

-出现在q的投影列表(即，选择x₁,…,x_m)中的列(算法1的第8行)

q的可索引列的集合

简单地是上述列的集合的并集(并且如算法1的第9行所反映的)。

在枚举了算法1的第3至9行的可索引列之后，在算法1的第13至21行从可索引列生成用于工作负荷

的每个查询

的候选索引，其描述如下。

为了从可索引列构建候选索引，可索引列在第13行通过它们的对应表(由查询访问)分组在一起。然后，算法1循环遍历与特定表相对应的可索引列的每个这样的组，并且在第15-20行处生成针对每个组的候选索引。

具体地，创建针对对应于过滤(算法1的第16行)的可索引列的一个或多个索引，并且创建针对对应于联合(算法1的第19行)的可索引列的索引(如果有的话)。

对应于过滤的候选索引在第16行被表示为I_filter，其中每个候选索引包括索引列和包括的列。索引列由

中的相等过滤列与

中的范围过滤列的串联形成，而其余的可索引列形成其包括的列(如算法1的第24至26行的辅助函数GenerateFilterIndex()所示)。对应于联合的候选索引在第19行被表示为I_join，并且与过滤索引一样，每个候选索引包括索引列和包括的列。

中的等联合列形成索引列，而其余可索引列形成其包括的列(如算法1的第30到31行的辅助函数GenerateJoinIndex()所示)。

在算法1完成后，图11的步骤1108同样完成，并且实施例接下来必须确定哪个索引配置是最佳的。为了从算法1返回的索引候选集合

中选择最佳索引，一种方法是枚举

的所有子集，并且找到在查询执行时间方面导致对工作负荷

的最佳改进的子集。然而，当

很大时，这种方法在实践中可能不可行。因此，本文公开的实施例应用启发式方法。

第一种这样的启发式方法是基于规则的方法，由此比较候选索引的确定性统计数据。具体地，实施例可以实现如下文中的算法2所示的基于频率的方法：

算法2

算法2可以概括为如下三个步骤：

1.统计索引频率(第2至5行)，其中我们对每个候选索引在查询的工作负荷中的出现次数进行计数；

2.合并候选索引(第7至13行)，其中我们通过组合其包括的列来将具有相同索引列的索引合并到一个单个的索引中；以及

3.对合并后的索引进行排名(第15行)，其中我们按频率的降序对合并后的索引进行排序。

然后，算法2从排序的候选返回前K个索引(在第16行)，其中K是由用户给出的预定值。

尽管基于频率的方法通常提供良好的索引建议，但该方法可能并不适用于所有工作负荷。首先，仅仅因为工作负荷的查询会频繁使用候选索引并不必然意味着该索引提供大大缩短的查询执行时间。例如，这样的索引可能位于访问时间可以忽略不计的频繁访问并且小引用(即维度)表之上。其次，虽然将候选索引与相同的索引列合并具有减少索引存储和维护开销的优势，但在没有正确了解开销的情况下，可能很难衡量效率。为了解决这些和其他问题，实施例可以采用依赖于对查询执行成本进行建模的基于成本的方法。

基于成本的索引选择方法的一个实施例依赖于数个基本构建块：

1.成本模型，其估计给定查询计划的执行成本的；

2.“what if”实用程序，其返回假设的查询计划及其成本而不实际构建索引；以及

3.高效搜索算法，其查找产生最低工作负荷执行成本的索引。

图12A示出了根据实施例的使用“what if”实用程序1210进行基于成本的索引调谐的架构示意图1200。示意图1200包括索引调谐模块1204和查询优化器1212，其包括“whatif”实用程序1210。基于如图12A中所示的关于示意图1200的以下讨论，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

在高等级处，图12A的示意图1200实施的基于成本的方法如下工作。索引调谐模块1204将包括查询q和假设索引配置C的有序对1206提供给“what-if”实用程序1210。假设索引配置可以包括如上所述的候选索引集合。“what-if”实用程序1210可以结合查询优化器1212生成有序对1208，该有序对1208包括查询计划P和执行计划P的估计成本(在图12A中表示为‘cost-est(P)’)。查询计划P是由查询优化器生成的计划，假设实际上已经构建了配置C的索引。同样，成本估计cost-est(P)反映计划P的执行成本的估计。下文在图12B的上下文中包括对该高等级概述的更详细描述，图12B示出了根据实施例的“what-if”实用程序1210对SQL查询的示例1202应用。示例1202包括表1214、SQL查询1216、过滤索引F₁ 1218、计划P1220、计划P’1222、成本R 1224和成本R’1226。基于如图12所示的以下讨论的“what-if”实用程序1210，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

如图12B所示，数据源具有两个要查询的表1214：R(a,b)和S(c,d)，并且查询1216是应用于它们的简单过滤-联合查询。假设用户想要通过构建索引F₁ 1218来了解对查询1216的性能影响。在一个实施例中，用户可以调用“what-if”实用程序1210而不构建索引F₁1218。

这样的调用通常如下进行：

1.接收由查询优化器返回的计划P 1220，并且搜索可以使用索引F₁ 1218评估的过滤谓词。

2.索引F₁ 1218被确定为有利于加速过滤R.a＝5的处理。

3.R上的表格扫描被替换为访问“假设”过滤F₁ 1218，并且生成新计划P’1222。计划P’1222是不可执行的(因为过滤F₁ 1218还没有构建)。

4.对新计划P’1222调用成本估计程序，并生成其估计成本。(同样，这一成本是假想的，并且如果F₁被构建，这是有意义的)。

为了确定成本P，可以将成本模型应用于计划P 1220。例如，假设成本模型被配置为估计每个操作符的输出大小。假设表R的大小为2GB，这意味着对R的表扫描产生取回和处理2GB的成本(表示为成本R 1224)。另一方面，“what-if”实用程序1210采用的成本模型可以确定，当R的表扫描被索引F₁ 1218取代时，大小可以减少到0.8GB，这是成本R’1226，如图12B所示。

以此方式，成本模型可以估计计划P 1220中的所有操作符的输出大小，并且同样地估计计划P’1222中的操作符的输出大小，将各个成本相加，并且确定用于执行每个计划的估计成本。这样做之后，现在可以比较计划P 1220和计划P’1222的成本，并且计算改进。对于这里的示例，假设cost(P)＝size(P)＝2.5GB，以及成本cost(P′)＝size(P′)＝1.5GB，它们分别是计划P 1220和计划P’1222中的所有操作符的输出大小的总和。作为结果，如果索引F₁ 1218被构建，则改进将是

本文所示的算法3示出了“whatif”实用程序1210的实施例：

成本模型可以通过多种方式来估算计划的查询成本。在如上所述基于大小的成本模型中，可以依赖存储在文件系统中的元数据来获得基本表/索引文件的大小。在上面结合图12描述的示例中，可以以这种方式获得R和索引F₁ 1218的大小。估计其他操作符的输出大小通常可以通过估计操作符的基数和/或选择性(例如，估计表中满足谓词过滤的条件的行的分率)来完成。可以确定操作符的选择性，收集关于工作负荷的统计数据，并且使用紧凑的数据结构(例如，直方图、草图、随机样本)来汇总统计数据。然而，收集大量数据的统计数据非常耗时。此外，可能很难维护这些统计数据，以防止它们因数据更新而变得过时。

备选地，可以采用启发式方法，从而将选择性值分配给操作符。例如，对于输出大小与输入大小相同的操作符，诸如排序，其选择性仅为1.0；对于其他操作符，诸如过滤或联 合，其选择性可设置为0.1。

应当注意的是，成本模型所产生的成本估计的确切值对于“what-if”实用程序1210的目的并不是特别重要。也就是说，拥有真实和准确的成本估计并不像任何两个估计的可比性那么重要。如果成本模型能够准确地确定两个查询计划中哪个的成本较高，就足够了。

在图12A的架构示意图1200的上下文中提供了对“what-if”实用程序1210的高等级描述之后，现在转向对使用“what-if”实用程序1210进行索引选择的基于成本的方法的实施例的详细描述。然而，应该注意的是，除了其在索引推荐中的角色之外，“what if”实用程序1210还具有其自身的好处。使用“what if”实用程序1210，用户能够定量地评估构建假设索引的潜在改进，例如，以百分比的形式。然而，这些好处并不是免费的--它们导致了更准确的成本建模，从而增加了收集统计数据时的开销。

算法4利用例如由算法3实施的“what if”实用程序1210，实现了索引选择的基于成本的方法的一个实施例，并且如下文所示：

算法4接受查询工作负荷

由算法1列举的候选索引集合

以及要返回的索引数量K作为输入。枚举多达大小K的每个子集(在第3行)，并且对于每个这样的子集

调用“what if”实用程序1210来获得每个

的估计成本，就好像

中的假设索引被构建一样(第4行)。如果针对工作负荷

的估计成本cost

之和低于当前记录的最低成本，则我们将

标记为最佳索引，并且更新到目前为止的最低成本(第5至7行)。最后，返回找到的具有最小估计成本的整体最佳子集(第8行)。请注意，将调用

返回的成本相加，如第4行所示，只是组合查询成本以计算工作负荷成本的一个示例。例如，在备选实施例中，可以进一步向每个查询分配权重(例如，相对于频率)，并且此后在组合查询成本时计算“加权总和”。

工作负荷优化系统的实施例可以以各种方式实现，以使用从工作负荷的查询中获得的信息来生成将使工作负荷受益的索引推荐，并且构建和使用这样的索引来服务于查询。例如，图13示出了根据实施例的工作负荷优化系统1302的详细示意图1300。如图13所示，工作负荷优化系统1302包括候选索引生成器1304、索引选择器1308和查询处理器1312。基于如图13所示的关于工作负荷优化系统1302的以下讨论，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

作为初始事项，如上所述，如图13所示的工作负荷优化系统1302被配置为接收包括多个查询的工作负荷1104，并且将工作负荷1104传递给候选索引生成器1304。候选索引生成器1304被配置为以多种方式从工作负荷1104的查询中提取可索引列的集合。例如，在实施例中，可以按照算法1从工作负荷1104的查询中提取可索引列，如上所述。候选索引生成器1304还被配置为此后基于可索引列的集合来生成候选索引1306的集合。例如，候选索引1306可以从根据算法1的可索引列的集合生成。

此后，生成的候选索引1306被传递到索引选择器1308。索引选择器1308被配置为选择候选索引1306中的哪个或哪些索引将在执行工作负荷1104的查询时提供最大的性能益处，并且将如此选择的索引提供给查询处理器1312。索引选择器1308可以多种方式选择最佳索引。例如，索引选择器1308可以采用算法2中阐述的并且如上所述的基于频率的方法。备选地，索引选择器1308可以采用基于成本的方法，其利用图12的“what-if”实用程序1210来确定哪些索引具有最低成本。例如，索引选择器1308可以采用如上所述实现算法3的“what-if”实用程序1210的实施例。此外，索引选择器1308此后可以采用算法4，以使用“what-if”实用程序1210以及上文所述的方式来选择最佳索引。此后，索引选择器1308将所选择的索引1310传递给查询处理器1312。

查询处理器1312被配置为接受所选择的索引1310，构建包括在所选择的索引1310中的索引以提供构建索引1314，接收查询1316，生成被优化为使用构建索引1314中的一个或多个构建索引1314的查询计划，以及执行查询计划以产生查询结果。例如，通过构建包括一个或多个键列(即，如上文在算法1的描述中详细描述的“索引列”)以及对应于“包括的列”的一个或多个数据列的表，可以从所选择的索引1310中构建构建索引1314。

在接收到查询1316之后，查询处理器1312被配置为生成用于该查询的查询计划，其中在可能的情况下，通过使用FilterIndexRule和JoinIndexRule，并且以如上结合图9和10描述的方式，修改查询计划以引用一个或多个构建索引1314。查询处理器1312此后可以执行修改的查询计划以产生最终查询结果。

根据一个实施例，结合图14描述了图13的工作负荷优化系统1302的其他操作方面，图14示出了在分布式查询处理系统中的第一查询引擎处执行的工作负荷优化的方法的流程图1400。在实施例中，流程图1400可以由图13的工作负荷优化系统1302执行。尽管参考图13所示的工作负荷优化系统1302进行了描述，但是图14的方法不限于该实现。实际上，如下面进一步描述的，流程图1400同样可以由图16的工作负荷优化系统1602执行。基于以下关于图14的流程图1400的讨论，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

请注意，可以触发流程图1400以各种方式优化分布式查询处理系统工作负荷。例如，可以响应于来自系统管理员的明确请求或自动地(例如，基于平均系统工作负荷随时间的改变或对底层数据的实质性改变)触发优化。流程图1400开始于步骤1402。在步骤1402中，基于多个查询来生成候选索引集合。例如，并且参考图13的工作负荷优化系统1302，候选索引生成器1304可以被配置为基于从包括多个查询的工作负荷中提取的可索引列的集合来生成候选索引1306，在一个实施例中，以如上关于图13的工作负荷优化系统1302、图11的详细描述和算法1及其详细描述的方式。流程图1400在步骤1404继续。

在步骤1404处，基于由候选索引集合提供的对工作负荷性能的估计性能改进的确定，从候选索引集合中选择预定数目的候选索引。例如，并且继续参考图13的工作负荷优化系统1302，索引选择器1308可以被配置为基于所选择的集合提供的对工作负荷的性能的估计性能改进，从候选索引集合1306中选择预定数目的候选索引1310。更具体地，索引选择器1308可以按照以上结合图13的工作负荷优化系统1302、算法2或算法3结合算法4以及它们各自的详细描述而详细描述的方式来操作。流程图1400在步骤1406继续。

在步骤1406处，根据索引规范来构建所选择的候选索引中的索引，并且将其存储在数据湖上的预定位置，预定位置和构建索引中包括的索引元数据符合索引规范。例如，并且继续参考图13的工作负荷优化系统1302，查询处理器1312可以被配置为接受来自索引选择器1308的所选择的索引1310，并且构建这样的索引以提供构建索引1314，按照以上关于图13的工作负荷优化系统1302和/或本领域公知的方式。此外，这样的索引可以符合索引规范212，从而包括如上文详细描述的诸如内容504和谱系506的元数据。借助于符合索引规范212，这样的索引同样可以存储在索引规范212中指定的预定默认位置。流程图1400在步骤1412继续。

在步骤1408处，接收查询。例如，并且继续参考图13的工作负荷优化系统1302，查询处理器1312可以接收查询1316，查询1316可以包括对工作负荷1104的查询或任何其他查询。流程图1400在步骤1410继续。

在步骤1410中，生成针对该查询的查询计划，其中该查询计划被优化以使用构建索引。例如，并且继续参考图13的工作负荷优化系统1302，查询处理器1312可以被配置为生成不被配置为使用任何构建索引的中间查询计划，并且此后将FilterIndexRule和/或JoinIndexRule应用于中间查询计划以提供被配置为使用如上关于图13的工作负荷优化系统1302详细描述的构建索引中的至少一个的查询计划，FilterIndexRule和/或JoinIndexRule分别如结合图9和10的示例900和1000所描述的。

图14的流程图1400在步骤1412结束。在步骤1412中，执行查询计划以生成最终查询结果。例如，并且继续参考图13的工作负荷优化系统1302，查询处理器1312可以被配置为执行在步骤1414中生成的查询计划以生成查询结果1318。如本领域中已知的，因为查询计划被配置为使用构建索引1314中的至少一个构建索引，所以与执行未被配置为使用构建索引1314的上述中间查询计划相比，生成查询结果1318需要更少的系统资源(例如，存储空间、CPU周期和/或存储器)。

在流程图1400的步骤1402至1412的前述讨论中，应当理解，有时可以以不同的顺序或者甚至与其他步骤同时执行这些步骤。例如，一旦在步骤1406处构建了至少一个索引，实施例可以执行步骤1408至1412，同时系统继续构建预定数目的候选索引的其他索引。对于(多个)相关领域的技术人员而言，其他操作实施例将是清楚的。还要注意的是，图13的工作负荷优化系统1302的操作的前述一般描述仅用于说明而提供，并且工作负荷优化系统1302的实施例可以包括不同的硬件和/或软件，并且可以以与上述不同的方式操作。实际上，流程图1300的步骤可以以各种方式执行。

结合图15和16描述了图13的工作负荷优化系统1302的其他操作方面。图15示出了对图14的流程图1400的多引擎精化的流程图，其中根据一个实施例，第二查询引擎优化查询计划以利用在预定位置处发现的预先存在的索引。图16示出了根据实施例的包括多引擎互操作性的各方面的示例工作负荷优化系统1600的示意图。如图16所示，工作负荷优化系统1600包括数据湖202、数据湖访问客户端1606、第一查询引擎1608和第二查询引擎1614。数据湖202包括其上存储的索引1602和数据集1604。根据下面的描述，索引1602包含其创建后的覆盖索引502。

在一个实施例中，图15的流程图1500的步骤由例如图16中示出的第二查询引擎1614来执行，并且这些步骤假设在数据湖202上存在由不同查询引擎构建的构建索引(例如，覆盖索引502)。因此，在描述图15的流程图1500之前，现在将参考图16的工作负荷优化系统1600来描述由这样的查询引擎创建这样的索引。

在实施例中，第一查询引擎1608可以被配置为通过接收并且执行对数据集1604的适当查询来在数据湖202上创建索引。例如，第一查询引擎1608可以从数据湖访问客户端1606接收创建索引(CREATE INDEX)查询1610，并且对数据集1604执行该查询以创建覆盖索引502。在实施例中，对应于创建索引查询1610的索引是根据上面参考图14的流程图1400和图13的工作负荷优化系统1302描述的过程确定的索引。具体地，并且参考工作负荷优化系统1302，要由创建索引查询1610创建的索引可以包括由索引选择器1308从候选索引1306中选择的所选择的索引1310中的一个索引。

在接收到创建索引查询1610时，第一查询引擎1608可以对数据集1604执行查询，更具体地，对被索引的数据1612执行查询，以生成覆盖索引502，该覆盖索引502此后被存储在数据湖202上的索引规范214中指定的默认预定位置处，如上文详细描述的，除非在索引创建时(也如上所述)指定了备选存储位置。在实施例中，第一查询引擎1608可以对应于图13的查询处理器1312。然而，应当理解，在一些实施例中，候选索引生成器1304和索引选择器1308可以与第一查询引擎1608分开。

在描述了工作负荷优化系统1600的索引创建之后，现在将结合图15描述图16的工作负荷优化系统1600的其他操作方面，图15示出了对图14的流程图1400的多引擎精化的流程图1500，其中根据实施例，第二查询引擎优化查询计划以利用在预定位置处发现的预先存在的索引。在实施例中，流程图1500可以由图16的工作负荷优化系统1600执行。尽管参考图16所示的工作负荷优化系统1600进行了描述，但是图15的方法不限于该实现。实际上，如下面进一步描述的，流程图1500同样可以由图13的工作负荷优化系统1302执行。基于以下关于图15的流程图1500的讨论，其他结构和操作实施例对于(多个)相关领域的技术人员而言将是清楚的。

流程图1500开始于步骤1502处。在步骤1502，接收查询。例如，第二查询引擎1614可以接收查询1316。流程图1500在步骤1504继续。

在步骤1504处，生成针对该查询的查询计划。例如，图16的第二查询引擎1614可以按照上面关于图14的流程图1400的步骤1410描述的方式来生成这样的可执行查询计划。更具体地，第二查询引擎1614可以被配置为类似于图13的查询处理器1312来操作，以生成不被配置为使用任何构建索引的中间查询计划。流程图1500在步骤1506继续。

在步骤1506处，在数据湖中搜索存储在预定位置的构建索引。例如，在实施例中，第二查询引擎1614被配置为知道索引规范214，并且实现诸如上文所述的面向用户的索引管理API 226的API，从而可以发现可能存在于数据湖202上的、存储在索引规范214中指定的预定默认位置中的任何索引。因此，第二查询引擎1614可以在数据湖202上的预定默认位置处发现覆盖索引502，并且此后可以如上所述从覆盖索引502的rawPlan节点516取回针对该索引的索引元数据原始查询计划信息。第二查询引擎1614可以检查原始查询计划以发现第二查询引擎1614是否可以使用覆盖索引502。如上所述，第二查询引擎1614可能不能使用该索引，因为它需要在第二查询引擎1614上不可用的能力(例如，不支持的散列函数)。

第二查询引擎1614还可以在分析上述原始查询计划信息之前或之后，访问包括内容504和谱系506的索引元数据，两者都在本文进行了描述，以确定例如索引列和包括的列(及其类型)、被索引的数据源、和/或覆盖索引502的物理位置和布局。这些信息中的一些或全部信息对于确定第二查询引擎1614是否以及如何利用这种索引可能是有用的。流程图1500在步骤1508处继续。

在步骤1508处，基于找到的每个构建索引的索引元数据，确定相应的构建索引是否可以用于优化查询计划，并且如果是，则优化查询计划以使用相应的构建索引。例如，并且继续参考图16的工作负荷优化系统1600，已经接收到查询1316并且同样已经发现覆盖索引502的第二查询引擎1614确定覆盖索引502可由第二查询引擎1614和由此索引的数据源使用，第二查询引擎1614可以在构建针对查询1316的查询计划时使用覆盖索引502，其中这样的查询计划在可能的情况下以上文关于工作负荷优化系统1302描述的方式使用覆盖索引502来产生查询结果1318。例如，第二查询引擎1614可以将FilterIndexRule和/或JoinIndexRule应用于在步骤1504生成的查询计划，以提供优化的查询计划，该优化的查询计划被配置为以上述关于图13的工作负荷优化系统1302的一般方式使用覆盖索引502，FilterIndexRule和/或JoinIndexRule分别如结合图9和10的示例900和1000所描述的。

流程图1500在步骤1510处结束。在步骤1510中，执行优化的查询计划以提供查询结果。例如，并且继续参考图16的工作负荷优化系统1600，第二查询引擎1614可以被配置为执行在步骤1512中生成的查询计划，以生成查询结果，例如，如图13所示的查询结果1318。如本领域所公知的，因为查询计划被配置为使用覆盖索引502，所以与执行未被配置为使用构建索引的上述中间查询计划相比，生成查询结果需要更少的系统资源(例如，存储空间、CPU周期和/或存储器)。

在流程图1500的步骤1502至1410的前述讨论中，应当理解，有时可以以不同的顺序或者甚至与其他步骤同时执行这些步骤。例如，可以在步骤1508之前的任何时间，包括在步骤1502接收查询或在步骤1504生成查询计划之前，执行步骤1506，其中实施例在数据湖中搜索构建索引。同样地，在一些实施例中，可能基于索引元数据来确定在步骤1506处找到的索引中的一个或多个索引本身是否与查询引擎(例如，第二查询引擎1614)不兼容，从而在某些情况下允许在步骤1502和1504之前执行步骤1508。对于(多个)相关领域的技术人员而言，其他操作实施例将是清楚的。还要注意的是，图13和图16的工作负荷优化系统1302和1600的操作的前述一般描述仅用于说明而提供，并且工作负荷优化系统1302和1600的实施例可以包括不同的硬件和/或软件，并且可以以与上述不同的方式操作。

III、示例计算机系统实现

数据采集器112、数据消解器114、数据建模器和服务器116、查询优化器1212、候选索引生成器1304、索引选择器1308、查询处理器1312、数据湖访问客户端1606、第一查询引擎1608和/或第二查询引擎1614以及流程图1400和/或1500中的每个都可以用硬件或与软件和/或固件相结合的硬件来实现。例如，数据采集器112、数据消解器114、数据建模器和服务器116、查询优化器1212、候选索引生成器1304、索引选择器1308、查询处理器1312、数据湖访问客户端1606、第一查询引擎1608和/或第二查询引擎1614以及流程图1400和/或1500可以被实现为被配置为在一个或多个处理器中执行并且存储在计算机可读存储介质中的计算机程序代码/指令。备选地，数据采集器112、数据消解器114、数据建模器和服务器116、查询优化器1212、候选索引生成器1304、索引选择器1308、查询处理器1312、数据湖访问客户端1606、第一查询引擎1608和/或第二查询引擎1614、以及流程图1400和/或1500可以实现为硬件逻辑/电子电路。

例如，在一个实施例中，数据采集器112、数据消解器114、数据建模器和服务器116、查询优化器1212、候选索引生成器1304、索引选择器1308、查询处理器1312、数据湖访问客户端1606、第一查询引擎1608和/或第二查询引擎1614以及流程图1400和/或1500中的一个或多个，以任意组合的方式，可以一起在SoC中实现。SoC可以包括集成电路芯片，该集成电路芯片包括处理器(例如，中央处理单元(CPU)、微控制器、微处理器、数字信号处理器(DSP)等)、存储器、一个或多个通信接口和/或其他电路中的一个或多个，并且可以可选地执行接收到的程序代码和/或包括用于执行功能的嵌入式固件。

图17示出了其中可以实现实施例的计算设备1700的示例性实现。例如，数据采集器112、数据消解器114、数据建模器和服务器116、查询优化器1212、候选索引生成器1304、索引选择器1308、查询处理器1312、数据湖访问客户端1606、第一查询引擎1608和/或第二查询引擎1614、以及流程图1400和/或1500可以在与固定或移动计算机实施例中的计算设备1700类似的一个或多个计算设备中实现，包括计算设备1700的一个或多个特征和/或备选特征。本文提供的计算设备1700的描述是为了说明的目的而提供的，并不旨在是限制性的。实施例可以在其他类型的计算机系统中实现，如(多个)相关领域的技术人员所公知的。

如图17所示，计算设备1700包括被称为处理器电路1702的一个或多个处理器、系统存储器1704、以及将包括系统存储器1704的各种系统组件耦合到处理器电路1702的总线1706。处理器电路1702是在作为中央处理单元(CPU)、微控制器、微处理器和/或其他物理硬件处理器电路的一个或多个物理硬件电路器件元件和/或集成电路器件(半导体材料芯片或管芯)中实现的电子和/或光学电路。处理器电路1702可以执行存储在计算机可读介质中的程序代码，诸如操作系统1730的程序代码、应用程序1732、其他程序1734等。总线1706表示多个类型的总线结构中的任何一个或多个总线结构，包括存储器总线或存储器控制器、外围总线、加速图形端口、以及使用各种总线架构中的任何的处理器或局部总线。系统存储器1704包括只读存储器(ROM)1708和随机存取存储器(RAM)1710。基本输入/输出系统1712(BIOS)存储在ROM 1708中。

计算设备1700还具有以下驱动器一个或多个：硬盘驱动器1714，用于读取和写入硬盘；磁盘驱动器1716，用于读取或写入可移动磁盘1718；以及光盘驱动器1720，用于读取或写入可移动光盘1722，例如CD ROM、DVD ROM或其他光学介质。硬盘驱动器1714、磁盘驱动器1716和光盘驱动器1720分别通过硬盘驱动器接口1724、磁盘驱动器接口1726和光盘驱动器接口1728连接到总线1706。驱动器及其相关联的计算机可读介质为计算机提供计算机可读指令、数据结构、程序模块和其他数据的非易失性存储。虽然描述了硬盘、可移动磁盘和可移动光盘，但也可以使用其他类型的基于硬件的计算机可读存储介质来存储数据，例如闪存卡、数字视频盘、RAM、ROM和其他硬件存储介质。

多个程序模块可以存储在硬盘、磁盘、光盘、ROM或RAM上。这些程序包括操作系统1730、一个或多个应用程序1732、其他程序1734和程序数据1736。应用程序1732或其他程序1734可以包括例如用于实现数据采集器112、数据消解器114、数据建模器和服务器116、查询优化器1212、候选索引生成器1304、索引选择器1308、查询处理器1312、数据湖访问客户端1606、第一查询引擎1608和/或第二查询引擎1614、以及流程图1400和/或1500(包括流程图1400和/或1500的任何适当步骤)和/或本文描述的其他实施例的计算机程序逻辑(例如，计算机程序代码或指令)。

用户可以通过诸如键盘1738和定点设备1740的输入设备将命令和信息输入到计算设备1700中。其他输入设备(未示出)可以包括麦克风、操纵杆、游戏板、卫星天线、扫描仪、触摸屏和/或触摸板、用于接收语音输入的语音识别系统、用于接收手势输入的手势识别系统等。这些和其他输入设备通常通过耦合到总线1706的串口接口1742连接到处理器电路1702，但也可以通过诸如并行端口、游戏端口或通用串行总线(USB)的其他接口连接。

显示屏1744还经由诸如视频适配器1746的接口连接到总线1706。显示屏1744可以在计算设备1700的外部或并入计算设备1700。显示屏1744可以显示信息，以及作为用于接收用户命令和/或其他信息(例如，通过触摸、手指手势、虚拟键盘等)的用户界面。除了显示屏1744之外，计算设备1700还可以包括其他外围输出设备(未示出)，例如扬声器和打印机。

计算设备1700通过适配器或网络接口1750、调制解调器1752或用于在网络上建立通信的其他装置连接到网络1748(例如，互联网)。如图17所示，可以是内置或外置的调制解调器1752可以经由串口接口1742连接到总线1706，或者可以使用包括并行接口的另一接口类型连接到总线1706。

如本文所使用的，术语“计算机程序介质”、“计算机可读介质”和“计算机可读存储介质”用于指物理硬件介质，诸如与硬盘驱动器1714相关联的硬盘、可移动磁盘1718、可移动光盘1722、诸如RAM、ROM、闪存卡、数字视频盘、zip盘、MEM、基于纳米技术的存储设备、以及其他类型的物理/有形硬件存储介质的其他物理硬件介质。这种计算机可读存储介质与通信介质不同并且不与其重叠(不包括通信介质)。通信介质在诸如载波的调制数据信号中包含计算机可读指令、数据结构、程序模块或其他数据。术语“调制数据信号”是指其一个或多个特性以编码信号中的信息的方式设置或改变的信号。作为示例而非限制，通信介质包括无线介质，诸如声学、RF、红外和其他无线介质，以及有线介质。实施例还涉及与涉及计算机可读存储介质的实施例分开且不重叠的这种通信介质。

如上所述，计算机程序和模块(包括应用程序1732和其他程序1734)可以存储在硬盘、磁盘、光盘、ROM、RAM或其他硬件存储介质上。这样的计算机程序也可以经由网络接口1750、串口接口1742或任何其他接口类型来接收。这样的计算机程序在由应用程序执行或加载时使计算设备1700能够实现本文描述的实施例的特征。因此，这样的计算机程序表示计算设备1700的控制器。

实施例还涉及包括存储在任何计算机可读介质上的计算机代码或指令的计算机程序产品。这样的计算机程序产品包括硬盘驱动器、光盘驱动器、存储设备包、便携式记忆棒、存储卡和其他类型的物理存储硬件。

IV.附加示例实施例

本文提供了一种第一查询引擎。第一查询引擎被配置为耦合到数据湖，数据湖被配置为存储数据集和基于数据湖上的数据集的索引，第一查询引擎还被配置为：接收包括指向数据集的多个查询的工作负荷；基于多个查询来生成候选索引集合；基于确定候选索引集合提供的对工作负荷的性能的估计性能改进，从候选索引集合中选择预定数目的候选索引；以及根据索引规范构建所选候选索引中的索引，并且将构建索引存储在数据湖上的预定位置处，预定位置和包括在构建索引中的索引元数据符合索引规范。

在第一查询引擎的另一实施例中，索引元数据描述以下一项或多项：构建索引的内容；构建索引的谱系；或者构建索引的状态。

在第一查询引擎的另一实施例中，描述构建索引的内容的索引元数据包括以下一项或多项：构建索引的名称；构建索引的类型；构建索引的配置，包括索引列的标识和包括的列的标识以及每个列的类型；或者构建索引的物理位置和布局。

在第一查询引擎的另一实施例中，描述构建索引的谱系的索引元数据包括以下一项或多项：一个或多个标识符，每个标识符对应于被索引的一个或多个数据源；索引数据源的时间；或者构建索引的描述性历史。

在第一查询引擎的另一实施例中，描述构建索引的状态的索引元数据包括来自启用、禁用、创建或删除的集合中的一个或多个状态描述符。

在第一查询引擎的另一实施例中，描述构建索引的谱系的索引元数据还包括用于创建构建索引的原始查询的查询计划信息。

在第一查询引擎的另一实施例中，数据湖还被配置为耦合到与第一查询引擎不同的第二查询引擎，第二查询引擎被配置为：在数据湖中搜索存储在预定位置的构建索引；接收查询；基于通过搜索找到的、针对每个构建索引的索引元数据，确定相应的构建索引是否能够被用以优化用于执行查询的查询计划，并且如果是，则优化查询计划以使用相应的构建索引；以及执行优化的查询计划以提供查询结果。

在第一查询引擎的另一实施例中，第一查询引擎和第二查询引擎还被配置为，基于描述构建索引的谱系的元数据来确定自从索引与构建索引相对应的数据源以来数据源是否已经被更新，并且如果是，则使用原始查询计划信息来重建索引。

本文提供了一种查询处理工作负荷优化系统，其被配置为接收包括多个查询的工作负荷。系统包括：一个或多个处理器；以及一个或多个存储设备，其可由一个或多个处理器访问，一个或多个存储设备存储用于由一个或多个处理器执行的程序代码，程序代码包括：第一查询处理器，其耦合到数据湖、候选索引生成器和索引选择器，其中：候选索引生成器被配置为基于多个查询来生成候选索引集合；以及索引选择器被配置为基于确定候选索引集合提供的对工作负荷的性能的估计性能改进，从候选索引集合中选择预定数目的候选索引；第一查询处理器被配置为：根据索引规范构建所选择的候选索引中的索引，并且将构建索引存储在数据湖上的预定位置处，预定位置和包括在构建索引中的索引元数据符合索引规范；接收查询；生成针对查询的查询计划，其中查询计划被优化以使用构建索引；以及执行查询计划以生成最终查询结果。

在查询处理工作负荷优化系统的另一实施例中，索引元数据描述以下一项或多项：构建索引的内容；构建索引的谱系；或者构建索引的状态。

在查询处理工作负荷优化系统的另一实施例中，描述构建索引的内容的索引元数据包括以下一项或多项：构建索引的名称；构建索引的类型；构建索引的配置，包括索引列和包括的列的标识以及每个列的类型；或者构建索引的物理位置和布局。

在查询处理工作负荷优化系统的另一实施例中，描述构建索引的谱系的索引元数据包括以下一项或多项：一个或多个标识符，每个标识符对应于被索引的一个或多个数据源；索引数据源的时间；或者构建索引的描述性历史。

在查询处理工作负荷优化系统的另一实施例中，描述构建索引的状态的索引元数据包括启用、禁用、创建或删除的集合中的一个或多个状态描述符。

在查询处理工作负荷优化系统的另一实施例中，描述构建索引的谱系的索引元数据还包括用于创建构建索引的原始查询的原始查询计划信息。

在查询处理工作负荷优化系统的另一实施例中，系统还包括耦合到数据湖的第二查询处理器，第二查询处理器被配置为接收查询；针对查询生成查询计划；在数据湖中搜索存储在预定位置的构建索引；基于找到的每个构建索引的索引元数据，确定相应的构建索引是否可用于优化用于查询计划，并且如果是，则优化查询计划以使用相应的构建索引；以及执行优化的查询计划以提供查询结果。

在查询处理工作负荷优化系统的另一实施例中，第一查询处理器和第二查询处理器还被配置为，基于描述构建索引的谱系的元数据来确定自从索引与构建索引相对应的数据源以来数据源是否已被更新，并且如果是，则使用原始查询计划信息来重建索引。

本文提供了一种查询处理工作负荷优化系统，其被配置为接收包括多个查询的工作负荷。系统包括：数据湖，其被配置为在其上存储数据集和基于数据集的索引；至少一个处理器，其被配置为耦合到数据湖；以及至少一个存储器，其存储被配置为由至少一个处理器执行以执行操作的程序代码，操作包括：接收包括指向数据集的多个查询的工作负荷；基于多个查询来生成候选索引集合；基于确定由候选索引集合提供的对工作负荷的性能的估计性能改进，从候选索引集合中选择预定数目的候选索引；以及根据索引规范构建所选择的候选索引中的索引，并且将构建索引存储在数据湖上的预定位置处，预定位置和包括在构建索引中的索引元数据符合索引规范。

在查询处理工作负荷优化系统的另一实施例中，索引元数据描述以下一项或多项：构建索引的内容；构建索引的谱系；或者构建索引的状态。

在查询处理工作负荷优化系统的另一实施例中，描述构建索引的谱系的索引元数据包括以下一项或多项：一个或多个标识符，每个标识符对应于被索引的一个或多个数据源；索引数据源的时间；或者构建索引的描述性历史。

在查询处理工作负荷优化系统的另一实施例中，操作还包括基于描述构建索引的谱系的元数据来确定自从索引与构建索引相对应的数据源以来数据源是否已经被更新，并且如果是，则使用原始查询计划信息来重建索引。

V、结论

虽然上面已经描述了所公开的主题的各种实施例，但是应当理解，它们仅作为示例而不是限制地呈现。(多个)相关领域的技术人员将理解，在不背离所附权利要求中定义的实施例的精神和范围的情况下，可以在其中进行形式和细节上的各种改变。因此，所公开的主题的广度和范围不应受任何上述示例性实施例的限制，而应仅根据所附权利要求及其等同形式来定义。

Claims (15)

1.一种第一查询引擎，其被配置为耦合到数据湖，所述数据湖被配置为存储数据集和基于所述数据湖上的所述数据集的索引，所述第一查询引擎还被配置为：

接收包括指向所述数据集的多个查询的工作负荷；

基于所述多个查询来生成候选索引集合；

基于确定由所述候选索引集合提供的对所述工作负荷的性能的估计性能改进，从所述候选索引集合中选择预定数目的候选索引；以及

根据索引规范构建所选择的所述候选索引中的索引，并且将构建索引存储在所述数据湖上的预定位置处，所述预定位置和被包括在所述构建索引中的索引元数据符合所述索引规范。

2.根据权利要求1所述的第一查询引擎，其中所述索引元数据描述以下一项或多项：

所述构建索引的内容；

所述构建索引的谱系；或者

所述构建索引的状态。

3.根据权利要求2所述的第一查询引擎，其中描述所述构建索引的所述内容的所述索引元数据包括以下一项或多项：

所述构建索引的名称；

所述构建索引的类型；

所述构建索引的配置，包括索引列的标识和被包括的列的标识、以及每个列的类型；或者

所述构建索引的物理位置和布局。

4.根据权利要求2所述的第一查询引擎，其中描述所述构建索引的所述谱系的所述索引元数据包括以下一项或多项：

一个或多个标识符，每个标识符对应于被索引的一个或多个数据源；

所述数据源被索引的时间；或者

所述构建索引的描述性历史。

5.根据权利要求2所述的第一查询引擎，其中描述所述构建索引的所述状态的所述索引元数据包括启用、禁用、创建或删除的集合中的一个或多个状态描述符。

6.根据权利要求4所述的第一查询引擎，其中描述所述构建索引的所述谱系的所述索引元数据还包括用于创建所述构建索引的原始查询的查询计划信息。

7.根据权利要求6所述的第一查询引擎，其中所述数据湖还被配置为被耦合到与所述第一查询引擎不同的第二查询引擎，所述第二查询引擎被配置为：

在所述数据湖中搜索被存储在所述预定位置处的构建索引；

接收查询；

基于通过所述搜索被找到的、针对每个构建索引的所述索引元数据，确定相应的所述构建索引是否能够被用以优化用于执行所述查询的查询计划，并且如果是，则优化所述查询计划以使用相应的所述构建索引；以及

执行经优化的查询计划以提供查询结果。

8.根据权利要求7所述的第一查询引擎，其中所述第一查询引擎和所述第二查询引擎还被配置为，基于描述所述构建索引的所述谱系的所述元数据来确定自与所述构建索引相对应的所述数据源被索引以来所述数据源是否已经被更新，并且如果是，则使用所述查询计划信息来重建所述索引。

9.一种查询处理工作负荷优化系统，被配置为接收包括多个查询的工作负荷，所述系统包括：

一个或多个处理器；以及

一个或多个存储设备，由所述一个或多个处理器可访问，所述一个或多个存储设备存储用于由所述一个或多个处理器执行的程序代码，所述程序代码包括：

第一查询处理器，被耦合到数据湖、候选索引生成器和索引选择器，其中：

所述候选索引生成器被配置为基于所述多个查询来生成候选索引集合；以及

所述索引选择器被配置为基于确定由所述候选索引集合提供的对所述工作负荷的性能的估计性能改进，从所述候选索引集合中选择预定数目的候选索引；

所述第一查询处理器被配置为：

根据索引规范构建所选择的所述选候选索引中的索引，并且将构建索引存储在所述数据湖上的预定位置处，所述预定位置和被包括在所述构建索引中的索引元数据符合所述索引规范；

接收查询；

生成针对所述查询的查询计划，其中所述查询计划被优化以使用所述构建索引；以及

执行所述查询计划以生成最终查询结果。

10.根据权利要求9所述的查询处理工作负荷优化系统，其中所述索引元数据描述以下一项或多项：

所述构建索引的内容；

所述构建索引的谱系；或者

所述构建索引的状态。

11.根据权利要求9所述的查询处理工作负荷优化系统，其中描述所述构建索引的所述内容的所述索引元数据包括以下一项或多项：

所述构建索引的名称；

所述构建索引的类型；

所述构建索引的配置，包括索引列的标识和被包括的列的标识、以及每个列的类型；或者

所述构建索引的物理位置和布局。

12.根据权利要求9所述的查询处理工作负荷优化系统，其中描述所述构建索引的所述谱系的所述索引元数据包括以下一项或多项：

一个或多个标识符，每个标识符对应于被索引的一个或多个数据源；

所述数据源被索引的时间；或者

所述构建索引的描述性历史。

13.根据权利要求9所述的查询处理工作负荷优化系统，其中描述所述构建索引的所述状态的所述索引元数据包括启用、禁用、创建或删除的集合中的一个或多个状态描述符。

14.根据权利要求12所述的查询处理工作负荷优化系统，其中描述所述构建索引的所述谱系的所述索引元数据还包括用于创建所述构建索引的原始查询的查询计划信息。

15.根据权利要求14所述的查询处理工作负荷优化系统，还包括被耦合到所述数据湖的第二查询处理器，所述第二查询处理器被配置为：

接收查询；

生成针对所述查询的查询计划；

在所述数据湖中搜索被存储在所述预定位置处的构建索引；

基于针对被找到的每个构建索引的所述索引元数据，确定相应的所述构建索引是否能够被用以优化用于所述查询计划，并且如果是，则优化所述查询计划以使用相应的所述构建索引；以及

执行经优化的查询计划以提供查询结果。

Images