CN112041832A - 分析作业服务中的计算重用 - Google Patents

Abstract

本文描述了一种用于检测和重用重叠计算的系统和方法。查询的重叠子图使用针对特定子图的规范化签名而被确定，该规范化签名跨数据的重复实例标识特定子图。针对查询的所确定的重叠子图中的每个重叠子图的规范化签名被提供。对于被确定要被实体化的每个重叠子图：特定子图是否已经被实体化是使用与特定重叠子图的规范化签名相对应的精确签名来确定的。在数据的特定重复实例内，精确签名标识与规范化签名相对应的特定子图。当特定子图尚未被实体化时，子图被实体化并且被用来对查询进行响应。当特定子图已经被实体化时，所实体化的子图被用来对查询进行响应。

Description

分析作业服务中的计算重用

背景技术

共享分析集群已经成为大型组织分析和获得对其数据的见解的事实方式。集群通常包括数万台机器，存储艾字节(exabyte)的数据，并且支持数千个用户，每天共同运行数十万个批处理作业。

在共享分析集群的情况下，明显的重叠(overlap)可以在由提交的作业执行的计算中被观察到。单纯地计算相同作业子表达式多次会浪费集群资源，这对集群的操作成本具有不利影响。

发明内容

本文描述了一种用于自动重用分析作业服务中的重叠计算的系统：计算机包括处理器和存储器，存储器在其上存储有计算机可执行指令，计算机可执行指令在由处理器执行时使计算机：接收查询；使用关于所分析的工作负载数据的存储信息来确定查询的重叠子图，存储信息包括针对特定子图的规范化签名，规范化签名跨数据的重复实例标识特定子图；提供关于查询的所确定的重叠子图的信息，关于重叠子图的信息包括针对每个重叠子图的规范化签名；使用所提供的信息来确定重叠子图中的哪个重叠子图要被实体化；对于被确定要被实体化的每个重叠子图：使用与特定重叠子图的规范化签名相对应的精确签名来确定特定子图是否已经被实体化，精确签名在数据的特定重复实例内标识与规范化签名相对应的特定子图；当特定子图尚未被实体化时，实体化子图并且使用所实体化的子图来对查询进行响应；以及当特定子图已经被实体化时，使用所实体化的子图来对查询进行响应。

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

附图说明

图1是图示用于在分析作业服务中自动检测和重用重叠计算的系统的功能框图。

图2是图示五个示例性集群中的重叠的条形图。

图3A是图示特定物理集群的多个虚拟集群中的每个虚拟集群中的百分比变化的分布的图(graph)。

图3B是图示跨不同虚拟集群的平均重叠频率的分布的图。

图4A-图4D是图示来自特定业务单元中的虚拟集群的重叠计算的图。

图5A是图示针对图4A-图4D中所示的重叠的多个算子(operator)的子图的百分比的条形图。

图5B是图示混洗算子(shuffle operator)的累积分布的条形图。

图5C是图示过滤算子的累积分布的条形图。

图5D是图示用户定义的处理器的累积分布的条形图。

图6A-图6D是量化重叠在特定业务单元中的影响的图。

图7是图示规范化签名和精确签名的使用的图。

图8是高级架构的示意图。

图9是系统的功能块，系统包括反馈环路，反馈环路协调编译时估计与运行时统计。

图10是运行时组件的功能框图。

图11是图示在运行时各种组件与元数据服务组件的交互的示意图。

图12是图示作为查询处理的一部分的用于创建和重用所实体化视图的机制的示意图。

图13是在分析作业服务中重用重叠计算的方法的流程图。

图14是进一步图示图13的方法的流程图。

图15是在分析作业服务中重用重叠计算的方法的流程图。

图16是进一步图示图14的方法的流程图。

图17是图示示例性计算系统的功能框图。

具体实施方式

现在参考附图描述与在分析作业服务中自动检测和重用重叠计算有关的各种技术，其中相同的附图标记始终用于指代相同的元素。在下面的描述中，出于说明的目的，阐述了许多特定细节以便提供对一个或多个方面的透彻理解。然而，可能明显的是，这样的(多个)方面可以在没有这些特定细节的情况下被实践。在其他实例中，公知的结构和设备以框图形式被示出，以便有助于描述一个或多个方面。此外，应当理解，被描述为由某些系统组件执行的功能性可以由多个组件执行。类似地，例如，组件可以被配置成执行被描述为由多个组件执行的功能性。

本公开内容支持各种产品和过程，产品和过程执行或被配置成执行与在分析作业服务中自动检测和重用重叠计算有关的各种动作。以下是一种或多种示例性系统和方法。

本公开内容的各方面涉及在分析作业服务中检测和重用重叠计算的技术问题。与解决该问题相关联的技术特征涉及：使用关于所分析的工作负载数据的存储信息来确定查询的重叠子图，存储信息包括针对特定子图的规范化签名，规范化签名跨数据的重复实例标识特定子图；提供关于查询的所确定的重叠子图的信息，关于重叠子图的信息包括针对每个重叠子图的规范化签名；使用所提供的信息来确定重叠子图中的哪个重叠子图要被实体化；对于被确定要被实体化的每个重叠子图：使用与特定重叠子图的规范化签名相对应的精确签名来确定特定子图是否已经被实体化，精确签名在数据的特定重复实例内标识与规范化签名相对应的特定子图；当特定子图尚未被实体化时，实体化子图并且使用所实体化的子图来对查询进行响应；以及当特定子图已经被实体化时，使用所实体化的子图来对查询进行响应。因此，这些技术特征的方面表现出更高效和有效地提供对查询的响应的技术效果，例如，减少了(多个)计算资源的利用和/或减少了查询响应时间。

此外，术语“或”旨在意指包括性“或”而不是排他性“或”。即，除非另外指定或从上下文中清楚得知，否则短语“X采用A或B”旨在意指任何自然的包括性排列。也就是说，短语“X采用A或B”由以下任何一个实例满足：X采用A；X采用B；或者X采用A和B两者。另外，除非另外指定或从上下文清楚得知是指向单数形式，否则本申请和所附权利要求中使用的冠词“一(a)”和“一个(an)”通常应当被解释为意指“一个或多个”。

如本文所使用的，术语“组件”和“系统”及其各种形式(例如，组件、系统、子系统)旨在指代与计算机有关的实体，其是硬件、硬件和软件的组合、软件或执行中的软件。例如，组件可以是但不限于：在处理器上运行的过程、处理器、对象、实例、可执行文件、执行的线程、程序和/或计算机。作为说明，在计算机上运行的应用和计算机都可以是组件。一个或多个组件可以驻留在执行的过程和/或线程内，并且组件可以位于一台计算机上和/或被分布在两个或更多个计算机之间。此外，如本文中所使用的，术语“示例性”旨在意指用作某物的说明或示例，并且不旨在指示偏好。

最近存在一种趋势，即由主要的云提供方提供分析即服务(analytics-as-a-service)，也被简称为作业服务(job service)。这些服务被设置和运行数据分析可能是企业的主要障碍的事实所激发。尽管平台即服务(PaaS)、软件即服务(SaaS)以及最近的数据库即服务(DBaaS)已经减轻了供应和缩放硬件和软件基础设施的痛苦，但用户仍需负责管理和调谐其服务器。作业服务通过提供不需要用户供应和管理服务器的无服务器分析功能来减轻这种痛苦。相反，云提供方负责管理和调谐可以即时并且可以按需缩放的查询引擎。用户可以使用所有熟悉的SQL界面快速入门，并且仅需为每个查询所使用的处理付费，而不是为整个供应的服务器基础设施付费，而与实际使用的计算资源无关。

本文描述的是一种计算重用框架，其可以用于解决作业服务中的计算重叠问题。在一些实施例中，框架的各个方面可以包括以下中的一个或多个：(i)计算通过在重复工作负载上创建所实体化视图而被重用，例如，周期性地执行具有相同脚本模板但每次处理新数据的作业，(ii)要实体化的视图使用反馈环路来选择，该反馈环路协调编译时和运行时统计，并且收集每次重叠计算的效用和成本的精确测量，和/或(iii)所实体化视图在在线环境中被创建，例如，在没有用以选择和/或实体化重叠计算的离线阶段的情况下。

接下来，参考图1，图示了用于在分析作业服务100中自动检测和重用重叠计算的系统。在一些实施例中，系统100包括用于作业服务中的计算重用的端到端系统。系统100包括分析器组件110和运行时组件120，其在下面被更详细地讨论。在一些实施例中，对于使用其输出的作业，分析器组件110是离线组件，而对于那些作业，运行时组件120是在线组件。在一些实施例中，分析器组件110周期性地运行。

分析器组件110建立了反馈环路，以选择最感兴趣的子图来实体化和重用。在一些实施例中，分析器组件110基于其之前的(多次)运行捕获要重用的一组感兴趣的计算；在给定一组约束的情况下，插入自定义视图选择方法来选择要实体化的视图；针对该实体化视图选取物理设计，和/或挖掘实体化视图中的每个实体化视图的到期。在一些实施例中，信息可以由分析器组件110提供作为查询注释。在一些实施例中，分析器组件110由管理员界面触发。在一些实施例中，仅在与工作负载信息相关联的实体的明确同意(例如，选择加入)的情况下，由分析器组件110进行的分析被执行。

运行时组件120使用由分析器组件110提供的查询注释来支持在线计算重用。如下面更详细地讨论的，运行时组件120可以包括：元数据服务组件，用以获取与给定作业中的重用有关的计算的元数据；在线视图实体化机制，作为作业执行的一部分；同步机制，用以避免并行地实体化相同视图，在运行时期间及早使实体化视图可用，使用实体化视图进行自动查询重写；和/或作业协调提示，用以使计算重用最大化。

介绍

鉴于云定价从供应的资源到实际消耗的资源的转变，企业自然不希望重复其资源消耗并且支付多余的美元成本。然而，这是现代企业数据分析中的主要挑战，现代企业数据分析包括由几个用户编写的复杂数据流水线(data pipeline)，其中计算中的部分计算最终会一遍又一遍地运行。这种计算重叠不仅增加了美元成本，而且在一些实施例中，对于开发人员和/或管理员来说，跨不同脚本和/或不同用户检测这些重叠也可能是困难的。

为了说明问题，考虑一个示例性系统，该系统利用被部署在几十万台机器上的数据分析，每天运行由几千个开发人员编写的几十万个生产分析作业，每天处理几艾字节的数据，并且涉及几百拍字节(petabyte)的I/O。在一些实施例中，每天作业的几乎40％被观察到与一个或多个其他作业具有计算重叠。进一步观察到，有超过一千万个重叠的子图(至少出现两次)，平均重叠频率为3.9。这些重叠由这些集群上的全部用户实体(例如，人和机器)的70％引发。图2是条形图200，其从左到右图示了针对五个示例性集群的重叠的作业、具有重叠的作业的用户以及重叠的子图。可以观察到，除集群3外，所有集群具有其45％以上的作业重叠。同样，所有集群上65％以上的用户最终在其作业中具有计算重叠，并且出现至少两次的子图的百分比可能高达80％。虽然理想的解决方案是使用户模块化其代码并且重用共享的脚本集和中间数据，但实际上这是不可能的，因为用户跨团队、作业职能以及地理位置分布。因此，如本文所描述的，期望一种用以在作业服务中进行计算重用的自动的云规模方法。

在针对分析作业服务构建计算重用框架方面存在许多挑战。首先，企业数据分析通常包括在变化数据上的重复作业。在一些实施例中，分析作业服务在其关键集群中具有60％以上的作业为重复。在这些重复作业的情况下，对新数据进行调度并且明智地实体化视图可能很重要，而这在传统视图选择中并不是问题。存在增量维护，但是在这里行不通，因为数据可能是全新的。在一些实施例中，分析作业服务作业被进一步打包在紧密的数据流水线中，即，多个作业以严格的完成期限在给定的时间间隔中操作。紧密的数据流水线几乎没有留下空间，来分析每次重复中的新数据上的重复工作负载。其次，在一些实施例中，反馈环路需要被建立，以分析先前执行的工作负载并且检测重叠的计算。考虑到大量的重叠，将所有的重叠子图实体化以进行重用根本不切实际。对感兴趣的重叠(或视图)的选择可以取决于每个重叠的效用和成本，即，每个重叠的运行时间节省和存储成本。然而，不幸的是，由于各种因素(例如，非结构化数据、不准确的算子选择性、用户代码的存在)，针对效用和成本的优化器估计通常严重错误。因此，在一些实施例中，由分析器组件110提供的反馈环路使逻辑查询树与实际运行时统计数据相协调，以获得对每个重叠的效用和成本的更精确测量。

第三，在一些实施例中，作业服务是在线的(例如，总是可用)，并且没有可用于创建实体化视图的离线阶段，离线阶段是传统的实体化视图所期望的。停止和/或延迟重复作业以创建实体化视图通常是不可行的，因为这会带来无法满足完成期限和/或影响下游数据依赖性的风险。因此，在一些实施例中，实体化视图恰好及时(例如，响应于查询)并且以最小的开销被创建。在一些实施例中，由于多个作业现在可以竞争来构建视图(构建-构建交互)，并且对于视图的可用性，它们彼此依赖(构建-消费交互)，因此这可能被进一步复杂化。

在一些实施例中，本文描述的系统和方法提供了一种用于计算重用的端到端系统，该系统具有许多要求，包括自动重用以及对最终用户的透明性，这些要求受生产环境的启发。在一些实施例中，用户可以像以前一样写入他们的作业，即用户脚本零变化，其中系统100自动检测和重用计算。在一些实施例中，假定精确的匹配是足够的，则集中在精确的作业子图匹配上，并且这使得问题变得更加简单而无需陷入视图包含复杂性。

在一些实施例中，系统100将实体化视图的物理设计考虑在内，因为观察到计算重叠经常出现在混洗边界处。在一些实施例中，系统100通过针对计算子图的规范化签名和精确签名(例如，哈希)的组合，使得能够在重复作业上进行计算重用。规范化签名匹配跨重复实例的计算(例如，独立于特定的数据实例)，而精确签名匹配重复实例内的计算(例如，特定于特定的数据实例)。在一些实施例中，这两个签名一起使得系统100能够一次分析工作负载并且重复地重用重叠的计算。

重用机会

在一些实施例中，重叠可以以不同的粒度级别来分析：集群内的重叠、业务单位内的重叠和/或算子方面的重叠。

集群内的重叠

图3A是图示特定物理集群的多个虚拟集群(VC)中的每个虚拟集群中的百分比改变的分布310的图表300。虚拟集群是租户，该租户已经分配了计算机容量(被称为“令牌”)并且控制对其数据的访问特权。对于这些示例性虚拟集群，分析表明，尽管8个VC没有重叠的作业，但54％的VC具有其超过50％的作业重叠，并且6个VC具有其100％的作业重叠。图3B是图示跨不同虚拟集群的平均重叠频率的分布330的图表320。在该示例中，平均重叠频率的范围是1.5到112(中位数频率为2.96，第75百分位数为3.82，第95个百分位数为7.1)。该示例说明计算重叠是集群范围的现象，并且通常不限于特定的VC或工作负载。

在一些实施例中，与分析作业服务客户的交互揭示了上面见到的普遍存在的计算重叠的两个主要原因：(i)用户很少从头开始编写其分析脚本，而是他们从其他人的脚本开始并且扩展/修改它们以适合其目的，以及(ii)分析作业服务中涉及数据生产者/消费者模型，其中多个不同的消费者处理相同的输入(例如，由生产者生成)，并且他们通常最终会重复对这些输入进行相同(部分或全部)的后处理。

业务单元内的重叠

图4A-图4D是图示来自特定业务单元中所有VC的重叠计算的图表400、图表410、图表420、图表430。注意，业务单元是有意义的粒度，因为业务单元内的VC创建数据流水线，其中一些VC生产数据(生产者)，而一些VC处理下游数据(消费者)。

图4A-图4D分别图示了每个作业、每个输入、每个用户和每个VC重叠的累积分布440、450、460、470。令人惊讶地，可以观察到，大多数作业具有与一个或多个其他作业重叠的10s至100s的子图。在一些实施例中，这表明存在大量的机会来改善数据流水线以便减少冗余。除了重用计算之外，在一些实施例中，也可以考虑首先共享计算。从每个输入的重叠分布450可以得出类似的观察，其中可以观察到90％以上的输入在相同子图中被消耗至少两次，40％被消耗至少五次，并且25％被消耗至少十次。在用户方面(图4C，分布460)，可以再次观察到，每个用户发生10s至100s的重叠，其中前10％具有超过1500个的重叠。在一些实施例中，这些量大的命中者可以被单独咨询。最后，对于VC(图4D，分布470)，可以观察到至少三个组具有相似数目的重叠。总体而言，计算重叠跨作业、输入、用户和VC广泛存在，并且可以由系统100以系统的方式解决。

算子方面的重叠

算子方面的重叠指代重叠的计算子图的根算子。图5A是图示针对图4A–图4D中所示的重叠的多个算子的子图的百分比的条形图500。可以观察到，“排序”和“交换”(混洗)构成了前两个最重叠的计算。在一些实施例中，这可能是令人感兴趣的，因为这两个通常也是最昂贵的运算，因此重用它们是有意义的。相比之下，重新评估接下来的三个最重叠的算子(即“Range”(扫描)，“ComputeScalar”和“RestrRemap”(通常是列重映射))被预计为将便宜得多，因为它们更接近查询树中的叶层级。在一些实施例中，在其他感兴趣的算子中，可以观察到聚合成组、结合和用户定义的功能(包括处理、减少甚至提取器)具有明显的重叠。

图5B-图5D是示出了针对算子中的三个算子(即混洗(分布540)、过滤(分布550)和用户定义的处理器(分布560))的累积重叠分布的图表510、图表520、图表530。即使观察到混洗算子具有大量的重叠计算，但只有一小部分混洗具有较高的频率。这对于过滤算子发生改变，其中累积分布更加线性，这意味着更多的过滤具有更高的频率。最后，对于图5D中的用户定义的算子(分布560)，曲线更平坦。在一些实施例中，这是因为用户定义的算子可能被几个用户和团队作为库共享。

重叠的影响

如上所述，计算重叠出现在不同的集群、VC和算子中。这些重叠的影响可以沿几个维度被审查。图6A-图6D是量化了特定业务单元中的重叠的影响的图表600、图表610、图表620、图表630。图表600、图表610、图表620、图表630分别图示了一个特定业务单元中的重叠的计算的频率640、运行时间650、输出大小660和视图与查询的成本比670的累积分布(如上所述)。

在频率方面，对于一天，有826528个计算出现至少两次，其中56500个出现至少10次，587个出现至少100次，并且16个出现至少1000次。然而，参考图6A，分布640图示的是，平均重叠频率为4.2(中位数频率为2，第75百分数为3，第95百分数为14，并且第99百分数为36)。因此，在一些实施例中，计算重叠的频率严重偏斜，并且在选择视图来实体化时需要格外小心。相比于频率，图6B的运行时分布650和图6C的输出大小分布660具有少得多的偏斜。有趣的是，26％的重叠具有1s以下的运行时间，这表明有机会修剪许多重用候选，而99％的重叠具有低于1000s的运行时间。在输出大小方面，35％的重叠具有低于0.1MB的大小，这对于存储空间来说更好(在它们有用的情况下)，并且99％的重叠低于1TB的大小。最后，在图6D的分布670中图示的视图与查询的成本比是理解视图对查询的相对重要性的有趣度量。可以观察到，46％的重叠计算具有0.01(1％)以下的视图与查询的成本比。这些重叠将不会导致时延上的显著节省，尽管特定客户可能仍会对其累积的资源消耗节省感兴趣。总体而言，这又是一个高度偏斜的分布，其中只有23％的重叠具有高于0.1的视图与查询的成本比，并且只有4％的重叠具有高于0.5的比率。

对重复工作负载的重用

在一些实施例中，系统100用于对分析作业服务中的重复作业实体化重叠的计算，例如，对于重复出现(例如，每小时、每天、每周和/或每月)的作业、在每个实例中具有模板改变的作业、和/或每次对新数据进行操作的作业。常规系统要求先验地了解工作负载，以便分析工作负载并且选择要实体化的视图。然而，随着重复作业在每个实例中改变和在新数据上运行，直到下一个重复实例(例如，下一个小时、次日、下周、下月)，确切的工作负载才可用。因此，在一些实施例中，在运行实际作业之前，运行工作负载分析来选择要在相同的重复实例内实体化的视图是完全不切实际的。

在一些实施例中，为了处理重复作业，两个签名的组合针对每个子图的计算而被收集：一个签名精确地标识计算，一个签名通过重复改变(例如，数据/时间断言、输入名称)对精确签名进行规范化。在一些实施例中，输入数据中的任何更新都会导致不同的精确签名，从而自动使任何较旧的实体化视图无效以进行重用。在一些实施例中，规范化签名由分析器组件110创建(例如，相对于特定作业/查询为离线)，并且精确签名由运行时组件120创建(例如，在与特定作业/查询相关联的编译期间)。

在一些实施例中，精确签名可以被扩展，以进一步包括输入GUID、任何用户代码和/或用于定制代码的任何外部库。规范化签名确保系统100捕获跨不同重复实例保持相同的规范化计算。图7是图示这两个签名在该方法中的使用的示意图700。来自工作负载历史的任何重复实例由分析器组件110分析，并且频繁的计算(视图)基于它们的精确签名被选择(步骤1)。它们对应的规范化签名被收集(例如存储)到元数据服务组件中，如下所述(步骤2)。在一些实施例中，该分析需要被周期性地运行和/或仅在工作负载中存在改变时被运行，从而去除了在每个重复实例内运行工作负载分析的需要。稍后，在运行时期间，子图基于子图的规范化签名来实体化(步骤3)，但是实体化视图中的每个实体化视图到实体化文件的物理路径中的精确签名也被记录(步骤4)。精确签名用于匹配将来的计算以进行重用(步骤5)以及用于使实体化视图过期(步骤6)。总而言之，规范化签名跨重复实例标识子图(以用于实体化)，而精确签名将重复实例中的子图匹配(以进行重用)。它们一起使对重复的工作负载的计算重用成为可能。

系统架构概述

在一些实施例中，系统100可以包括以下属性中的一个或多个：

(1)自动：在一些实施例中，开发人员可能难以协调和重用它们中间的重叠计算。因此，在一些实施例中，重叠的计算可以由系统100自动检测、实体化、重用和/或逐出。

(2)透明：在一些实施例中，在数十万作业的情况下，在用户脚本和/或其库中进行改变根本不现实。

(3)正确：不引入数据损坏的计算重用。在一些实施例中，由于参数、用户代码和/或外部库的存在，这可能具有挑战性。

(4)时延敏感：分析作业服务用户通常无法负担降低其数据流水线的速度。因此，在一些实施例中，由系统100进行的计算重用提供更好和/或相同的性能。这需要对实体化视图的成本/增益进行准确的估计。在一些实施例中，在事实证明它过于昂贵的情况下，优化器仍然可以丢弃视图。

(5)最大化重用：在一些实施例中，系统100尽可能执行计算重用。在一些实施例中，这可能是困难的，因为重叠的作业可能同时到达，并且因此在一个作业中被实体化的视图可能最终不被重用。

(6)可调试性：一些分析作业服务具有系统100保留的丰富的可调试性经验和计算重用。具体地，在一些实施例中，客户(和运营团队)能够重播该作业，查看哪些实体化视图被创建或使用，跟踪创建了任何视图的作业，并且甚至还可以深入了解为什么视图被首先选择来进行实体化或重用。

(7)报告：最后，在一些实施例中，系统100可以报告计算重用对作业性能的影响，例如，存储成本和/或运行时间节省。在一些实施例中，与重叠的计算有关的元数据是可查询的。

传统的实体化视图技术通常具有三个组件，即离线视图选择组件、离线视图构建组件和在线视图匹配组件。在一些实施例中，系统100具有两个在线组件：用于挖掘重叠计算的周期性工作负载分析器，以及用于实体化和重用那些计算的运行时引擎。

图8图示了高级架构800。左侧示出了分析器组件110(例如，周期性工作负载分析器)，其对分析作业服务工作负载存储库进行分析。在一些实施例中，(多个)管理员可以选择包括和/或排除不同的VC以进行分析。在一些实施例中，该分析的输出是一组注释，该组注释告诉将来的作业要被实体化和重用的子图计算。图8的右侧示出了运行时组件120。这里，在一些实施例中，每个传入的作业都可以按照三种方式中的一种被处理：(i)与以前完全相同，在没有任何作业子图被实体化或者它们被优化器认为过于昂贵的情况下，(ii)从实体化视图进行读取的经修改的作业图(即，存在匹配的子图注释并且其被实体化)，并且优化器认为从实体化视图进行读取比重新计算更加有效；以及(iii)经修改的作业图，该作业图将子图的输出假脱机化(spool)和实体化(即，存在匹配的子图注释，但其尚未被实体化)。在一些实施例中，分析器组件110可以由用户显式地触发或被调度为另一个重复作业，而运行时组件120通过在作业提交期间提供命令行标志来被触发。在一些实施例中，最终用户的作业脚本保持不变。

分析器组件

在一些实施例中，分析器组件110的特征包括：(i)提供用于运行时统计的反馈环路，(ii)针对要实体化的所选择的视图选择物理设计，(iii)确定实体化视图的到期和/或(iv)提供用户界面以对工作负载分析进行调谐和/或可视化。

反馈环路

选取正确的要实体化的视图集可能是一个难题。在视图要被实体化的情况下，一些系统依靠假设分析(what-if)优化来估计预期的改进。不幸的是，由于存在复杂的有向无环图(DAG)和/或用户代码，因此优化器的成本估计通常相差很远。在分布式云设置中，该问题甚至可能会变得更加严重，在这种情况下，虚拟硬件和调度问题使得在作业时延方面对实际增益进行建模变得更加困难。结果，在一些示例中，从实体化的视图的实际的改进可能要低得多，而其实际的实体化成本可能比估计的实体化成本要高得多。另外，将后来最终未被使用的视图实体化在作业服务中浪费了客户的金钱。在一些实施例中，因作业图内的动态资源分配以及分析作业服务中的额外资源分配，对要实体化的视图的选择被进一步复杂化。

在一些实施例中，系统900包括反馈环路，该反馈环路使编译时估计与运行时统计相协调，如图9中所描绘的。在一些实施例中，由分析器组件110提供的反馈机制超越了从相同的查询学习，并且考虑了跨多个作业的任意细粒度共性。在一些实施例中，这是通过枚举过去(例如一天或一周)的时间窗口内看到的(多个)作业(例如，所有作业)的子图(例如，所有可能的子图)并且找到跨它们的共同子图来完成的。例如，分别读取属性(A，B)和(A，C)的查询Q1和Q2会生成视图(A，B，C)作为候选，即使它既不是Q1的子图也不是Q2的子图。尽管在一些实施例中，这比考虑通用视图更受限制，但是所考虑的子图实际上在过去已经被使用(例如，并且将来也可能会被使用)，并且从先前运行有可用的运行时统计(允许对成本的更准确的预测)。为了使用来自先前运行的运行时统计，作业数据流(例如，实际上在机器的集群上被执行的作业数据流)被连接回作业查询图(例如，输入用户查询的树表示)。在一些实施例中，这是通过将在数据流中每个阶段处被执行的算子链接到查询图中的算子来完成的。然后，对于每个查询子图，对应的运行时统计从数据流中被提取。这些包括时延(执行子图所花费的时间)、基数(子图中输出行的数目)、数据大小(以字节为单位)和/或资源消耗(CPU、存储器、并行性、IO等)。在一些实施例中，在多个算子在数据流中被流水线化的情况下，例如通过基于每个算子在流水线中的排他运行时间来细分经流水线化的算子的总资源消耗，诸如资源消耗的运行时统计可以被归因于单独的算子。

在一些实施例中，由分析器组件110提供的反馈环路可以具有一个或多个益处。首先，在一些实施例中，由于多次分析需要共同的数据准备和/或仅仅是由于开发人员通常在添加他们自己的逻辑之前从其他人的脚本开始的事实，因此用户脚本中存在分析的不可避免的重复。利用作业服务中的反馈环路，用户不必担心对其脚本进行重复删除；系统100负责在运行时自动进行重复删除。其次，在一些实施例中，运行时统计可以提供视图实体化成本和益处的更可预测的测量，从而使客户更好地了解客户将为该特征支付多少费用以及客户将节省多少费用。第三，在一些实施例中，与基于成本估计来选取实体化视图并且随后在估计被证明不正确的情况下发现它们无用相比，反馈环路使所选择的(和实体化的)子图实际上更有可能最终在未来的作业中被使用。第四，在一些实施例中，如在更一般的视图选择场景中那样，反馈环路考虑作业子图而不考虑是否合并且两个或更多个子图。这确保了除了使用该视图的作业以任何方式进行的计算以外，将视图实体化永远不需要附加计算(并且因此不需要附加金钱)。最后，在一些实施例中，从一个作业的子图观察到的运行时统计被跨具有这些子图中的任何一个子图的未来查询共享。实际上，对于进入的任何新作业，系统可能已经知道其几个子图的成本，并且可能决定不重新计算它们。

选择子图来实体化

如上所述，在一些实施例中，分析器组件110可以通过将选择限制到公共子图来简化视图选择问题。尽管在与更一般化的视图选择相比时这是受限的，但是在一些实施例中，分析器组件110能够捕获精确的效用和成本估计，因为子图在过去已经被执行。另外，在一些实施例中，在查询重写期间，运行时组件120可以简单地扫描实体化视图，而不会引起任何其他后处理，并且因此增益可以更可预测。

在一些实施例中，分析器组件110利用一种或多种方法来选择子图以实体化：

(i)使用一种或多种启发法(例如总子图效用、由存储成本归一化的总效用)选择前k个子图，和/或限制于每个作业最多一个子图。在一些实施例中，分析器组件110允许用户插入自定义启发法，来缩小到他们感兴趣的子图。

(ii)在给定约束集(例如，存储约束、视图交互约束)的情况下，打包最感兴趣的子图(或子表达式)。

物理设计

在一些实施例中，分析器组件110考虑实体化视图的物理设计。常规地，实体化视图的物理设计尚未被认为重要，因为视图和它们的物理设计通常不被同时选择。然而，在一些实施例中，观察到具有较差物理设计的实体化视图最终没有被使用，因为计算节省被系统为利用该实体化视图而需要进行的任何附加重新分区和/或排序所掩盖。之所以发生这种情况，是因为在分析作业服务作业中具有庞大的数据集和大量并行处理的情况下，重新分区和/或排序通常是作业执行中最慢的步骤。

在一些实施例中，系统100密切关注(多个)视图的物理设计。为此，分析器组件110可以在枚举它们时，提取子图中的每个子图的输出物理性质(例如，分区类型、分区列、分区编号、排序列和/或排序方向)。在一些实施例中，输出物理性质可以是视图物理设计的良好提示，因为它们被作业图中的后续算子所期望。在子图根处没有明确的物理性质的情况下，系统100可以从子级推断出它们，即向下遍历直到遇到一个或多个物理性质。根据重叠子图在不同作业中如何被使用，针对相同子图可能存在物理性质的多个集合。在一些实施例中，默认策略是选取最流行的集合。然而，在一些实施例中，在没有明确选择的情况下，(相同视图的)多个物理设计可以被视为不同的视图，并且被馈送到视图选择例程。

到期和清除

尽管在一些实施例中，存储是廉价的，但是由实体化视图使用的存储空间仍然需要被周期性地回收。在一些实施例中，一种简单的启发法是从先前的重复实例中移除所有视图。然而，在一些实施例中，每小时作业的输出也可以被用在每周作业和/或每月作业中。因此，在一些实施例中，在每个小时/每天之后移除视图可能是浪费的。在一些实施例中，视图的输入的谱系(lineage)被跟踪，即，对于视图输入中的每个视图输入，检查其被任何重复作业使用的最长持续时间。在一些实施例中，所有这种持续时间的最大值给出了视图到期的良好估计。除了使用标准分析作业服务脚本之外，这种谱系跟踪还可以使用出处(provenance)工具来支持。由此获得的视图到期可以被编码成物理文件，并且存储管理器可以在文件到期后负责清除文件。

在一些实施例中，(多个)集群管理员还可以通过以下来回收给定的存储空间：运行与上述相同的视图选择例程，但是用最小目标函数来代替最大目标函数，即，以最小效用选取视图。在最坏的情况下，实体化视图文件可以简单地从集群中被擦除。然而，在一些实施例中，在删除任何物理文件之前，上述两个算子都需要首先从元数据服务中清除视图(在下面讨论)(以确保消费这些输入中的任何输入的作业不会失败)。

用户界面

在一些实施例中，系统100提供了用于与分析器组件110交互的一种或多种方式。首先，命令行界面可以被提供，以在用户特定的集群、VC和/或时间范围上运行分析器组件110。在一些实施例中，用户还可以提供他们的自定义约束，例如存储成本、时延、CPU小时和/或频率，以过滤重叠计算。在一些实施例中，系统100提供强大的商业智能仪表板，以供用户审查来自计算重叠分析的各种(多个)摘要，以及供用户更详细地深入到最上面(例如100个)的重叠计算。总之，目标是帮助用户理解其工作负载中的计算重叠，并且根据需要调整计算重用。

运行时组件

运行时组件120在在线查询处理期间支持计算重用。在继续参考图9的情况下，参考图10，在一些实施例中，运行时组件120包括以下中的一个或多个：(i)元数据服务组件1000，用于查询每个传入作业中的相关重叠，(ii)在线视图实体化组件1010，用于将视图实体化作为查询处理的一部分；(iii)同步组件1020，用于防止并发作业实体化相同的视图；(iv)提前实体化，用于发布实体化视图，甚至在产生它的作业完成之前发布，(v)自动查询重写组件1030，用于尽可能使用实体化视图，和/或(vi)提供提示的作业调度器930，以便使计算重用最大化。

元数据服务组件

在一些实施例中，元数据服务组件1000提供关于重叠计算的信息，并且协调那些计算的实体化和重用。在在线设置中(即，数据批次和作业连续到达)，视图实体化和重用是动态的活动。因此，代替简单地在编译器1010中查找视图，在运行时，多个分析作业服务组件与元数据服务组件1000交互。图11是图示在运行时各种组件与元数据服务组件1100的交互的示意图1100。首先，编译器910向元数据服务组件1100询问针对给定作业J的重叠计算(视图)(步骤1)。在一些实施例中，朴素的方法是使编译器910单独查找每个子图，以检查这是否是重叠计算。然而，由于分析作业服务作业图可能非常大，因此查找请求的数目可能会变得过大，从而导致更高的编译开销以及对元数据服务组件1100的更高吞吐量要求。在一些实施例中，相反，每个作业做出一个请求，并且可能与该作业相关的所有重叠都被获取。在一些实施例中，这可以通过如下创建反向索引来完成。对于每个重叠计算实例，从其对应的作业元数据中提取标签。针对重复作业的标签被规范化，并且反向索引在标签上被创建，以指向对应的规范化签名。元数据服务组件1000将与J有关的规范化签名的列表返回给编译器910(步骤2)。在一些实施例中，由元数据服务组件1000返回的签名可能包含误报，并且优化器920仍可能需要将它们与查询树中的实际签名相匹配。

其次，当优化器920试图对重叠计算进行实体化时，它向元数据服务组件1000提议实体化(步骤3)。元数据服务组件1000试图创建排他锁以实体化该视图。由于大量的并发运行作业，相同的视图可能已经被另一个作业实体化，即该锁已经存在。在这种情况下，服务返回失败消息，否则，它返回成功(步骤4)。注意，在一些实施例中，视图子图的平均运行时间从过去的事件被挖掘，并且用于设置排他锁的到期。一旦排他锁到期，并且如果视图仍未被实体化，则另一个作业可以尝试创建相同的实体化视图。这给予系统100、900针对视图实体化的容错行为。

最后，作业管理器1110向元数据服务组件1100报告视图的成功实体化(步骤5)，并且元数据服务组件1000确认锁释放(步骤6)。元数据服务组件1000现在使实体化视图可用于其他作业来重用，即，它可以在下次编译器910请求作业的相关视图时出现(步骤1)。在一些实施例中，元数据服务组件1000周期性地轮询分析器组件110的输出，并且每当新的分析可用时，加载所选择的重叠计算的集合。在一些实施例中，计算可以以规则间隔到期。

系统900还包括调度器930，其将执行图和用于查询的资源存储在存储库950中，并且包括作业管理器940，其将针对查询的实际运行时统计存储在存储库950中，并且向查询提供(多个)结果。在一些实施例中，编译器910将经编译的查询DAG存储在存储库950中。在一些实施例中，优化器920将优化计划和估计的统计存储在存储库950中。在一些实施例中，当执行其分析时，分析器组件110可以利用存储在存储库950中的至少一些信息，如上面所讨论的。

在线实体化

传统的实体化视图通常需要离线过程，其中，例如，在数据库变得可用于运行查询工作负载之前，数据库管理员负责首先创建所有相关的实体化视图，即预处理步骤。这对于在具有严格完成期限的紧密数据流水线中运行的重复作业不切实际，在这种情况下，几乎没有空间进行预处理来创建实体化视图。预处理可以阻挡重复作业，从而使得它们错过其完成期限。重复作业在它们之间也具有数据依赖性，即，一个重复作业的结果被用在后续的重复作业中。因此，缺少针对一个重复作业的完成期限可以影响整个数据流水线。

在一些实施例中，运行时组件120的在线视图实体化组件1010提供了一种用于创建和重用实体化视图作为查询处理的一部分的机制，如图12中所描绘的。图12是图示核心计划搜索1210和后续优化1220的示意图1200。在从元数据服务组件1000获取相关的规范化签名之后，编译器910将它们作为注释提供给查询优化器920。在一些实施例中，编译器910还保留注释，作为用于未来可重复性的作业资源。在一些实施例中，在尝试在如后续优化1220中图示的后续优化阶段中实体化一个或多个视图之前，优化器920首先在计划搜索阶段中检查所有重用机会。这确保了已经被实体化(并且可用)的视图不会被尝试进行实体化。在后续的优化1220期间，优化器920检查任何子图的规范化签名是否与注释中的签名匹配。在一些实施例中，规范化签名以自下而上的方式被匹配(首先实体化较小的视图，因为它们通常具有更多的重叠)，并且限制在作业中可以被实体化的视图的数目(可以经由作业提交参数由用户改变)。在匹配的情况下，优化器920提议将视图实体化(图11中的步骤3)。在从元数据服务组件1000接收成功时，优化器920调整查询计划以将子计算的副本输出到实体化视图，同时保持查询计划的剩余部分像之前一样未被修改。新的输出算子还强制执行由分析器针对该视图挖掘的物理设计。在一些实施例中，优化器920负责添加任何额外的分区/排序算子，以满足那些物理性质要求。在一些实施例中，优化器920将每个实体化视图的精确签名以及产生实体化视图的作业的标识符(用于跟踪视图出处)存储到实体化文件的物理路径中。

在一些实施例中，在线视图实体化组件1010可以执行以下特征。首先，在一些实施例中，在线视图实体化组件1010包括一种用于以最小开销创建实体化视图的机制，作为查询处理的一部分被引入，而无需任何会阻挡重复查询的前期预处理。其次，命中要实体化的视图的第一查询使其被实体化，并且后续的查询将尽可能重用它。结果，在线视图实体化组件1010实体化了视图，并且因此仅在需要它们时消耗存储，而不是例如在它们会被使用很久之前就先验地创建它们。第三，在线视图实体化组件1010不需要在实体化视图的查询(作为其执行的一部分)与重用该实体化视图的查询之间进行协调；在多个查询同时到达的情况下，则首先完成的查询将视图实体化。第四，在从给定的重复实例开始查询工作负载存在改变的情况下，此时，由于签名不再匹配，基于先前工作负载分析的视图实体化自动停止。这避免了针对将根本不会被使用的冗余视图付费和消耗资源。在一些实施例中，这也可以指示是时候重新运行工作负载分析。最后，在一些实施例中，在线视图实体化组件1010不影响其分析堆栈中的任何用户基础设施。这意味着用户脚本、数据流水线、查询提交和/或作业调度可以保持原样。

在一些实施例中，对于具有足够的空间来进行预先视图实体化(例如每周分析)的传统用户，系统100仍然可以提供离线视图实体化模式。在该模式下，优化器920提取匹配的重叠计算子图，同时排除作业中的任何剩余操作。所产生的计划仅实体化视图，并且可以被离线执行，即在运行实际工作负载之前被执行。离线模式可以在元数据服务组件1000中的VC等级处被配置，并且稍后根据元数据服务组件1000的配置，传递到优化器920的注释被标记为在线或离线。

查询重写1030

在一些实施例中，为了使用实体化视图来重写查询，查询重写组件1030包括火山样式计划搜索中的附加任务。如图12的核心计划搜索1210中所示，该附加任务以自上而下的方式(例如，最大的实体化视图被首先匹配)，将从元数据服务中取回的规范化签名与查询子图中的每个查询子图的规范化签名进行匹配。在匹配的情况下，优化器920也匹配精确签名。在一些实施例中，仅在精确签名匹配的情况下，实体化视图才可以被重用。在这种情况下，优化器920添加从实体化视图进行读取的备选子表达计划。在一些实施例中，可以用于回答查询的实体化视图的数目不受限制。一旦所有适用的实体化视图已经被添加为备选子表达，优化器920就基于成本估计来选取最佳计划，即，如果一个或多个实体化视图的读取成本过高，则该一个或多个实体化视图可能最终不被使用。从实体化视图进行读取的计划还加载实际统计(针对该子计算)，并且将这些统计向上传播到查询树。这使得更有信心来决定使用该实体化视图的计划实际上是否是一个好的计划。总体上，在一些实施例中，提供了使用视图的全自动查询重写，对用户脚本的改变为零。

同步1020

在一些实施例中，运行时组件120包括(多个)同步特征，其包括：(i)构建-构建同步，即，没有多个作业对相同视图进行实体化，和/或(ii)构建-使用同步，即，一旦计算被实体化，就重用计算。在一些实施例中，如上所述，构建-构建同步通过在尝试实体化计算之前尝试重用计算来处理。对于并发作业，排他锁可以经由元数据服务组件1000而被创建，如上所述。在一些实施例中，元数据服务组件1000由提供一致锁定的

支持，并且一次仅单个作业可以实际上实体化视图。为了处理构建-使用同步，在一些实施例中，分析作业服务作业管理器940被修改，以在实体化视图可用时立即将其发布。这意味着实体化视图输出甚至在产生它的作业完成之前就可用。这被称为提前实体化。提前实体化是语义改变，因为它打破了分析作业服务作业的原子性，然而它非常有用，因为视图可以是整个作业图的小得多的子图。此外，实体化视图不是用户输出，而是被视为系统输出，并且因此不影响用户合同。最后，在一些实施例中，在作业失败的情况下，提前实体化也有帮助，因为作业现在可以从实体化视图重新开始，即，提前实体化充当检查点。

作业协调

用于计算重用的理想场景是当具有重叠计算的作业中的一个作业在其他作业之前被调度时，使得视图可以被精确地计算一次并且被其他作业重用。然而，在一些实施例中，包含相同重叠计算的多个作业可以被并发地调度。在该情况下，多个作业将重新计算相同的子图，并且甚至尝试将它实体化(尽管只有一个将占上风)。在一些实施例中，这可以通过对客户端作业提交系统中的重复作业进行重新排序来减轻。为此，除了选择感兴趣的计算来实体化之外，在一些实施例中，分析器组件110还提供包含那些计算的重复作业的提交顺序，这将带来最大的益处。这可以通过以下方式而被执行：对具有相同重叠的作业进行聚集(具有多个重叠的作业可以出现在多个组中)，并且从每个组选取在运行时间方面最小的作业，或者在平局的情况下，选取最少重叠的作业。上述作业的重复删除列表将创建可以由其他作业使用的实体化视图，并且因此它们将被首先运行(例如，按其运行时排序，并且使用重叠的数目打破平局)。这种排序可以使用分析作业服务客户端侧作业提交工具来强制执行。

图13-图16图示了与在分析作业服务中检测和重用重叠计算有关的示例性方法。虽然这些方法被示为并且被描述为是按顺序执行的一系列动作，但是应当理解和了解，方法不受顺序的次序限制。例如，一些动作可以以与本文描述的不同的顺序出现。另外，一个动作可以与另一个动作同时出现。此外，在一些情况下，实现本文描述的方法可能不需要所有动作。

此外，本文描述的动作可以是可以由一个或多个处理器实现和/或被存储在一个或多个计算机可读介质上的计算机可执行指令。计算机可执行指令可以包括例程、子例程、程序、执行线程等。更进一步，该方法的动作的结果可以被存储在计算机可读介质中、被显示在显示设备上等。

参考图13和图14，图示了在分析作业服务1300中重用重叠计算的方法。在一些实施例中，方法1300由系统100和/或系统900执行。

在1310处，查询被接收。在1320处，查询的重叠子图使用关于所分析的工作负载数据的存储信息来确定。存储信息包括针对特定子图的规范化签名。规范化签名跨数据的重复实例标识特定子图。

在1330处，关于查询的所确定的重叠子图的信息被提供。关于重叠子图的信息包括针对每个重叠子图的规范化签名。在1340处，重叠子图中的哪个重叠子图要被实体化被确定。

在1350处，确定特定子图是否已经使用与特定重叠子图的规范化签名相对应的精确签名而被实体化。精确签名在数据的特定重复实例内标识与规范化签名相对应的特定子图。在1360处，进行关于特定子图是否已经被实体化的确定。如果在1360处的确定为“否”，则在1370处，特定子图被具体化并且被用来对查询进行响应，然后处理在1390处继续。如果在1360处的确定为“是”，则在1380处，所实体化的特定子图被用来对查询进行响应。

在1390处，进行关于是否有更多重叠的子图要被实体化的确定。如果在1390处的确定为“否”，则没有进一步的处理出现。如果在1390处的确定为“是”，则处理在1350处继续。

参考图15和图16，图示了在分析作业服务1500中重用重叠计算的方法。在一些实施例中，方法1500由系统100和/或系统900执行。

在1510处，查询被接收。在1520处，查询的重叠子图使用关于所分析的工作负载数据的存储信息来确定。存储信息包括针对特定子图的规范化签名。规范化签名跨数据的重复实例标识特定子图。

在1530处，关于查询的所确定的重叠子图的信息被确定。关于重叠子图的信息包括针对每个重叠子图的规范化签名。在1540处，重叠子图中的哪个重叠子图要被实体化被确定。

在1550处，对于被确定要被实体化的每个重叠子图：在1560处，使用与特定重叠子图的规范化签名相对应的精确签名来确定特定子图是否已经被实体化，精确签名在数据的特定重复实例内标识与规范化签名相对应的特定子图；在1570处，当特定子图尚未被实体化时，实体化子图并且使用所实体化的子图来对查询进行响应；并且在1580处，当特定子图已经被实体化时，使用所实体化的子图来对查询进行响应。

本文描述了一种用于在分析作业服务中重用重叠计算的系统，系统包括：包括处理器和存储器的计算机，存储器在其上存储有计算机可执行指令，计算机可执行指令在由处理器执行时使计算机：接收查询；使用关于所分析的工作负载数据的存储信息来确定查询的重叠子图，存储信息包括针对特定子图的规范化签名，规范化签名跨数据的重复实例标识特定子图；提供关于查询的所确定的重叠子图的信息，关于重叠子图的信息包括针对每个重叠子图的规范化签名；使用所提供的信息来确定重叠子图中的哪个重叠子图要被实体化；对于被确定要被实体化的每个重叠子图：使用与特定重叠子图的规范化签名相对应的精确签名来确定特定子图是否已经被实体化，精确签名在特定的数据的重复实例内标识与规范化签名相对应的特定子图；当特定子图尚未被实体化时，实体化子图并且使用所实体化的子图来对查询进行响应；以及当特定子图已经被实体化时，使用所实体化的子图来对查询进行响应。

系统还可以包括：其中在接收到查询之前，工作负载数据的分析被执行。系统可以包括：其中规范化签名独立于数据的特定实例。系统还可以包括：关于所分析的工作负载数据的存储信息还包括以下中的至少一项：经编译的查询子图、经优化的计划和估计的统计、执行图和资源，或者所执行的查询的实际运行时统计。系统可以包括：其中关于所分析的工作负载数据的存储信息还包括关于针对要被实体化的至少一个子图的物理设计的信息。

系统还可以包括：其中关于所分析的工作负载数据的存储信息还包括关于所实体化的子图的到期的信息。系统可以包括：关于所分析的工作负载数据的存储信息至少部分地基于用户可选择设置，用户可选择设置与以下中的至少一项有关：存储成本、时延、CPU小时或者频率。系统还可以包括：其中关于所分析的工作负载数据的存储信息基于对多个作业的子图的运行时统计的分析，运行时统计包括以下中的至少一项：时延、基数、数据大小或者子图的资源消耗。

本文描述了一种在分析作业服务中自动重用重叠计算的方法，包括：接收查询；使用关于所分析的工作负载数据的存储信息来确定查询的重叠子图，存储信息包括针对特定子图的规范化签名，规范化签名跨数据的重复实例标识特定子图；提供关于查询的所确定的重叠子图的信息，关于重叠子图的信息包括针对每个重叠子图的规范化签名；使用所提供的信息来确定重叠子图中的哪个重叠子图要被实体化；对于被确定要被实体化的每个重叠子图：使用与特定重叠子图的规范化签名相对应的精确签名来确定特定子图是否已经被实体化，精确签名在特定的数据的重复实例内标识与规范化签名相对应的特定子图；当特定子图尚未被实体化时，实体化子图并且使用所实体化的子图来对查询进行响应；以及当特定子图已经被实体化时，使用所实体化的子图来对查询进行响应。

方法还可以包括：其中在接收查询之前，工作负载数据的分析被执行。方法可以包括：其中规范化签名独立于数据的特定实例。方法还可以包括：其中关于所分析的工作负载数据的存储信息还包括还包括以下中的至少一项：经编译的查询子图、经优化的计划和估计的统计、执行图和资源，或者所执行的查询的实际运行时统计。

方法还可以包括：其中关于所分析的工作负载数据的存储信息还包括关于针对要被实体化的至少一个子图的物理设计的信息。方法可以包括：其中关于所分析的工作负载数据的存储信息还包括关于所实体化的子图的到期的信息。

方法还可以包括：其中关于所分析的工作负载数据的存储信息至少部分地基于用户可选择设置，用户可选择设置与以下中的至少一项有关：存储成本、时延、CPU小时或者频率。方法可以包括：其中关于所分析的工作负载数据的存储信息基于对多个作业的子图的运行时统计的分析，运行时统计包括以下中的至少一项：时延、基数、数据大小或者子图的资源消耗。

本文描述了一种计算机存储介质，其存储计算机可读指令，计算机可读指令在被执行时使计算设备：使用关于所分析的工作负载数据的存储信息来确定查询的重叠子图，存储信息包括针对特定子图的规范化签名，规范化签名跨数据的重复实例标识特定子图；提供关于查询的所确定的重叠子图的信息，关于重叠子图的信息包括针对每个重叠子图的规范化签名；使用所提供的信息来确定重叠子图中的哪个重叠子图要被实体化；对于被确定要被实体化的每个重叠子图：使用与特定重叠子图的规范化签名相对应的精确签名来确定特定子图是否已经被实体化，精确签名在特定的数据的重复实例内标识与规范化签名相对应的特定子图；当特定子图尚未被实体化时，实体化子图并且使用所实体化的子图来对查询进行响应；以及当特定子图已经被实体化时，使用所实体化的子图来对查询进行响应。

计算机存储介质还可以包括：其中关于所分析的工作负载数据的存储信息还包括以下中的至少一项：经编译的查询子图、经优化的计划和估计的统计、执行图和资源，或者所执行的查询的实际运行时统计。计算机存储介质可以包括：其中关于所分析的工作负载数据的存储信息还包括关于针对要被实体化的至少一个子图的物理设计的信息。计算机存储介质还可以包括：其中关于所分析的工作负载数据的存储信息还包括关于所实体化的子图的到期的信息。

参考图17，图示了示例通用计算机或计算设备1702(例如，移动电话、台式机、膝上型电脑、平板电脑、手表、服务器、手持式的可编程消费者或工业电子设备、机顶盒、游戏系统、计算节点)。例如，计算设备1702可以被用在系统中，以用于在分析作业服务100中自动检测和重用重叠计算。

计算机1702包括一个或多个处理器1720、存储器1730、系统总线1740、(多个)大容量存储设备1750以及一个或多个接口组件1770。系统总线1740可通信地耦合至少上述系统成分。然而，应当理解，在其最简单的形式中，计算机1702可以包括被耦合到存储器1730的一个或多个处理器1720，一个或多个处理器1720执行被存储在存储器1730中的各种计算机可执行动作、指令和/或组件。例如，指令可以是用于实现被描述为由上面讨论的一个或多个组件执行的功能性的指令或用于实现上述一个或多个方法的指令。

(多个)处理器1720可以用以下被设计用于执行本文所述的功能的各项来实现：通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其他可编程逻辑器件、分立的栅极或晶体管逻辑、分立硬件组件或其任何组合。通用处理器可以是微处理器，但是可选地，处理器可以是任何处理器、控制器、微控制器或状态机。(多个)处理器1720还可以被实现为计算设备的组合，例如DSP和微处理器的组合、多个微处理器、多核处理器、一个或多个微处理器结合DSP核，或者任何其他这样的配置。在一个实施例中，(多个)处理器1720可以是图形处理器。

计算机1702可以包括各种计算机可读介质或以其他方式与各种计算机可读介质交互，以有助于控制计算机1702来实现所要求保护的主题的一个或多个方面。计算机可读介质可以是可以由计算机1702访问的任何可用介质，并且包括易失性和非易失性介质，以及可移除和不可移除介质。计算机可读介质可以包括两种不同且互斥的类型，即计算机存储介质和通信介质。

计算机存储介质包括以用于存储信息的任何方法或技术实现的易失性和非易失性、可移除和不可移除介质，信息诸如计算机可读指令、数据结构、程序模块或其他数据。计算机存储介质包括存储设备，诸如存储器设备(例如，随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM))、磁存储设备(例如，硬盘、软盘、磁带盒、磁带)、光盘(例如，压缩盘(CD)、数字多功能盘(DVD))和固态设备(例如，固态驱动器(SSD)、闪存驱动器(例如，卡、棒、钥匙驱动器))，或者存储(而不是传输或传送)由计算机1702可访问的期望信息的任何其他相同介质。因此，计算机存储介质排除经调制的数据信号以及关于通信介质所描述的内容。

通信介质以诸如载波或其他传输机制等经调制的数据信号来体现计算机可读指令、数据结构、程序模块或其他数据，并且包括任何信息传递介质。术语“经调制的数据信号”表示以对信号中的信息进行编码的方式设置或改变的其一个或多个特性的信号。通过示例而非限制，通信介质包括诸如有线网络或直接有线连接的有线介质，以及诸如声学、RF、红外和其他无线介质的无线介质。

存储器1730和(多个)大容量存储设备1750是计算机可读存储介质的示例。取决于计算设备的确切配置和类型，存储器1730可以是易失性的(例如，RAM)，非易失性的(例如，ROM、闪存)或两者的某种组合。通过示例，基本输入/输出系统(BIOS)，包括在计算机1702内的元件之间传递信息的基本例程，诸如在启动期间可以被存储在非易失性存储器中，而易失性存储器可以充当外部缓存存储器以有助于(多个)处理器1720的处理等等。

(多个)大容量存储设备1750包括可移除/不可移除、易失性/非易失性计算机存储介质，用于存储相对于存储器1730的大量数据。例如，(多个)大容量存储设备1750包括但不限于一个或多个设备，诸如磁盘或光盘驱动器、软盘驱动器、闪存、固态驱动器或记忆棒。

存储器1730和(多个)大容量存储设备1750可以包括或已经在其中存储了操作系统1760、一个或多个应用1762、一个或多个程序模块1764和数据1766。操作系统1760用于控制和分配计算机1702的资源。应用1762包括系统和应用软件中的一者或两者，并且可以由操作系统1760通过被存储在存储器1730和/或(多个)大容量存储设备1750中的程序模块1764和数据1766来利用资源管理来执行一个或多个动作。因此，应用1762可以根据由此提供的逻辑将通用计算机1702变成专用机器。

所要求保护的主题的全部或部分可以使用标准编程和/或工程技术来实现，以产生软件、固件、硬件或其任何组合，以控制计算机实现所公开的功能性。通过示例而非限制，系统100或其部分可以是应用1762或者形成应用1762的一部分，并且包括被存储在存储器和/或(多个)大容量存储设备1750中的一个或多个模块1764和数据1766，一个或多个模块1764和数据1766在由一个或多个处理器1720执行时，其功能性可以实现。

根据一个特定实施例，(多个)处理器1720可以对应于片上系统(SOC)或类似架构，包括或者换言之，在单个集成电路基板上集成硬件和软件两者。这里，(多个)处理器1720可以包括一个或多个处理器以及至少类似于(多个)处理器1720和存储器1730的存储器等。传统处理器包括最少量的硬件和软件，并且广泛依赖于外部硬件和软件。相比之下，处理器的SOC实现更加强大，因为它在其中嵌入了硬件和软件，硬件和软件能够以对外部硬件和软件的最小程度的依赖或不依赖于外部硬件和软件来实现特定功能性。例如，系统100和/或相关联的功能性可以被嵌入SOC架构中的硬件内。

计算机1702还包括一个或多个接口组件1770，其被可通信地耦合到系统总线1740并且支持与计算机1702的交互。通过示例，接口组件1770可以是端口(例如，串行、并行、PCMCIA、USB、FireWire)或接口卡(例如，声音、视频)等。在一个示例实现中，接口组件1770可以被实施成用户输入/输出接口，以使得用户能够通过一个或多个输入设备(例如，诸如鼠标、轨迹球、触控笔、触摸板、键盘、麦克风、操纵杆、游戏手柄、卫星天线、扫描仪、相机、其他计算机的指示设备)将命令和信息输入到计算机1702中，例如通过一个或多个手势或语音输入。在另一个示例实现中，接口组件1770可以被实施成输出外围接口，以向显示器(例如，LCD、LED、等离子体)、扬声器、打印机和/或其他计算机等提供输出。更进一步地，接口组件1770可以被实施成网络接口，以实现与其他计算设备(未示出)的通信，诸如通过有线或无线通信链路。

以上描述的内容包括所要求保护的主题的各方面的示例。当然，出于描述所要求保护的主题的目的，不可能描述组件或方法的每个可想到的组合，但是本领域普通技术人员可以认识到，所公开的主题的许多其他组合和置换是可能的。因此，所公开的主题旨在涵盖落入所附权利要求的精神和范围内的所有这些更改、修改和变型。此外，在具体实施方式或权利要求中使用术语“包括”的程度上，以与如“包括(comprising)”在权利要求中被用作过渡性词语时解释的那样的术语“包括”类似的方式，这种术语旨在是包括性的。

Claims (15)

1.一种用于在分析作业服务中重用重叠计算的系统，包括：

计算机，包括处理器和存储器，所述存储器在其上存储有计算机可执行指令，所述计算机可执行指令在由所述处理器执行时使所述计算机：

接收查询；

使用关于所分析的工作负载数据的存储信息来确定所述查询的重叠子图，所述存储信息包括针对特定子图的规范化签名，所述规范化签名跨数据的重复实例标识特定子图；

提供关于所述查询的所确定的所述重叠子图的信息，关于重叠子图的所述信息包括针对每个重叠子图的规范化签名；

使用所提供的所述信息来确定所述重叠子图中的哪个重叠子图要被实体化；

对于被确定要被实体化的每个重叠子图：

使用与所述特定重叠子图的规范化签名相对应的精确签名来确定所述特定子图是否已经被实体化，所述精确签名在数据的特定重复实例内标识与所述规范化签名相对应的特定子图；

当所述特定子图尚未被实体化时，实体化所述子图并且使用所实体化的所述子图来对所述查询进行响应；以及

当所述特定子图已经被实体化时，使用所实体化的所述子图来对所述查询进行响应。

2.根据权利要求1所述的系统，其中在接收到所述查询之前，工作负载数据的分析被执行。

3.根据权利要求1所述的系统，其中所述规范化签名独立于数据的特定实例。

4.根据权利要求1所述的系统，其中关于所分析的工作负载数据的所述存储信息还包括以下中的至少一项：经编译的查询子图、经优化的计划和估计的统计、执行图和资源，或者所执行的查询的实际运行时统计。

5.根据权利要求1所述的系统，其中关于所分析的工作负载数据的所述存储信息还包括关于针对要被实体化的至少一个子图的物理设计的信息。

6.根据权利要求1所述的系统，其中关于所分析的工作负载数据的所述存储信息还包括关于所实体化的子图的到期的信息。

7.根据权利要求1所述的系统，其中关于所分析的工作负载数据的所述存储信息至少部分地基于用户可选择设置，所述用户可选择设置与以下中的至少一项有关：存储成本、时延、CPU小时或者频率。

8.根据权利要求1所述的系统，其中关于所分析的工作负载数据的所述存储信息基于对多个作业的子图的运行时统计的分析，所述运行时统计包括以下中的至少一项：时延、基数、数据大小或者子图的资源消耗。

9.一种在分析作业服务中自动重用重叠计算的方法，包括：

接收查询；

使用关于所分析的工作负载数据的存储信息来确定所述查询的重叠子图，所述存储信息包括针对特定子图的规范化签名，所述规范化签名跨数据的重复实例标识特定子图；

提供关于所述查询的所确定的所述重叠子图的信息，关于重叠子图的所述信息包括针对每个重叠子图的规范化签名；

使用所提供的所述信息来确定所述重叠子图中的哪个重叠子图要被实体化；

对于被确定要被实体化的每个重叠子图：

使用与所述特定重叠子图的规范化签名相对应的精确签名来确定所述特定子图是否已经被实体化，所述精确签名在数据的特定重复实例内标识与所述规范化签名相对应的特定子图；

当所述特定子图尚未被实体化时，实体化所述子图并且使用所实体化的所述子图来对所述查询进行响应；以及

当所述特定子图已经被实体化时，使用所实体化的所述子图来对所述查询进行响应。

10.根据权利要求9所述的方法，其中所述规范化签名独立于数据的特定实例。

11.根据权利要求9所述的方法，其中关于所分析的工作负载数据的所述存储信息还包括以下中的至少一项：经编译的查询子图、经优化的计划和估计的统计、执行图和资源，或者所执行的查询的实际运行时统计。

12.根据权利要求9所述的方法，其中关于所分析的工作负载数据的所述存储信息还包括关于针对要被实体化的至少一个子图的物理设计的信息。

13.一种计算机存储介质，其存储计算机可读指令，所述计算机可读指令在被执行时使计算设备：

使用关于所分析的工作负载数据的存储信息来确定查询的重叠子图，所述存储信息包括针对特定子图的规范化签名，所述规范化签名跨数据的重复实例标识特定子图；

提供关于所述查询的所确定的所述重叠子图的信息，关于重叠子图的所述信息包括针对每个重叠子图的规范化签名；

使用所提供的所述信息来确定所述重叠子图中的哪个重叠子图要被实体化；

对于被确定要被实体化的每个重叠子图：

使用与所述特定重叠子图的规范化签名相对应的精确签名来确定所述特定子图是否已经被实体化，所述精确签名在数据的特定重复实例内标识与所述规范化签名相对应的特定子图；

当所述特定子图尚未被实体化时，实体化所述子图并且使用所实体化的所述子图来对所述查询进行响应；以及

当所述特定子图已经被实体化时，使用所实体化的所述子图来对所述查询进行响应。

14.根据权利要求13所述的计算机存储介质，其中关于所分析的工作负载数据的所述存储信息还包括以下中的至少一项：经编译的查询子图、经优化的计划和估计的统计、执行图和资源，或者所执行的查询的实际运行时统计。

15.根据权利要求13所述的计算机存储介质，其中关于所分析的工作负载数据的所述存储信息还包括关于针对要被实体化的至少一个子图的物理设计的信息。

Images