CN117120997A - 用健壮的查询性能支持可扩展数据库 - Google Patents

Abstract

本公开描述了一种服务关键仪表板、应用和内部用户的分析数据管理系统(ADMS)。这种ADMS具有高可伸缩性、通过复制和故障转移的可用性、高用户查询负载和大数据量。ADMS提供连续的摄取和新鲜度可调的高性能查询。它通过解耦其架构部件(摄取、索引和查询)进一步推进分散思想。因此，可以通过牺牲数据新鲜度或增加成本来最小化索引速度变慢对查询性能的影响。

Description

用健壮的查询性能支持可扩展数据库

相关申请的交叉引用

本申请要求2021年4月14日提交的美国临时专利申请第63/174，692号的申请日的权益，其公开内容通过引用并入本文。

背景技术

互联网服务的服务提供商可以依靠应用数据来提供更好的用户体验、提高服务质量和计费。商业用户通过复杂的分析前端与该数据进行交互，以深入了解他们的业务。这些前端对大量数据发出复杂的分析查询，并施加严格的时间限制，在某些情况下，服务级别目标在毫秒量级。有多个拍字节的这种数据，并且通过大规模的行星尺度的更新流不断更新。用户要求查询结果一致、新鲜，并要求在面对数据中心故障或网络分区时持续可用。

有许多用于分析数据管理的商业产品。这些商业系统的技术进步包括列存储、查询优化以及针对写优化索引和更新优化索引的多种设计。传统的数据分析系统已经从存储和计算的紧密耦合发展到存储和计算解耦的分散模型，以利用云计算范式。

发明内容

本公开描述了一种服务于关键仪表板、应用和内部用户的分析数据管理系统(ADMS)。这种ADMS具有高可伸缩性、通过复制和故障转移的可用性、高用户查询负载和大数据量。ADMS提供连续的摄取和新鲜度可调的高性能查询。它通过解耦其架构部件(摄取、索引和查询)进一步推进了分散的思想。因此，索引速度变慢对查询性能的影响可以通过牺牲数据新鲜度或增加成本来最小化。

尽管当前的数据管理存储系统通常依赖于由列存储、并行性和压缩加速的扫描，但是这里描述的ADMS依赖于视图来保证健壮的查询性能。使用日志结构合并(LSM)林，为连续高带宽插入优化视图。ADMS为客户端提供了查询性能、新鲜度和成本的灵活可配置参数。可查询时间戳(QT)提供了客户数据库生产性能相对于所述要求的实时标记或指示符。由于ADMS的可配置性，不同配置下的相同系统可以满足注重成本的客户以及高性能和新鲜度的要求。

根据本文描述的示例，ADMS是完全索引的系统，其被优化用于表和视图上的关键字查找、范围扫描和索引的高效增量维护。它可以轻松地支持即席查询和高选择性且多样性较低的查询。它是多租户、多宿主、分布式、全局复制的数据管理系统，可由任务关键型应用使用。它提供了单数据库级的可查询时间戳，这意味着用户可以以一致的方式引用和查询多个表和视图。它还支持具有完全SQL通用性的视图；它们的子集可以被不断维护。

B树是许多传统数据库管理系统中的主要索引结构。根据本文描述的示例，ADMS使用B+树的变体，该变体利用了ADMS表具有多部分关键字的事实。此外，最小/最大关键字、每列最小/最大值与每个非叶块一起存储以实现有效剪枝。日志结构合并树(LSM)采用B树索引来实现高更新率。ADMS属于以高写入吞吐量换取快速读取的LSM系统类。写操作被写入级别文件，这些文件被压缩以形成更大的级别文件。读操作在运行时合并这些。LSM数据结构的效率通过“写放大”或输入行写入磁盘的次数(跨所有级别)来衡量。

本公开的一个方面提供了一种分析数据管理系统(ADMS)，包括:摄取框架，被配置为将更新提交到存储在存储器中的一个或多个数据表中；存储框架，被配置为压缩所述一个或多个表，并增量地将所述更新应用于所述一个或多个表；以及查询服务框架，被配置为响应客户端查询。压缩所述一个或多个表可以包括在将所述更新应用于所述一个或多个表之前合并多个增量更新。

所述查询服务框架可以将查询导向预先计算的物化视图。包括所述预先计算的物化视图的所述一个或多个表可以通过主关键字进行排序、索引和范围分区。

根据一些示例，数据平面包括所述摄取框架、存储框架和查询服务框架，以及控制平面包括控制器，其中，所述控制器协调所述摄取框架、存储框架和查询服务框架之间的工作。

根据一些示例，所述控制器调度压缩和视图更新任务。所述控制器可以协调跨多个数据中心的元数据事务。

所述摄取框架可以被配置为摄取多行数据，每行数据被分配元数据时间戳。摄取多行数据可以包括批处理、聚合和复制数据。所述摄取框架可以包括位于不同地理位置的多个副本，其中，所述框架被配置为摄取在所述多个副本中的任意副本处的所述数据。

根据一些示例，每个表具有指示可被查询的所述数据的新鲜度的可查询时间戳。所述新鲜度可以由等于当前时间减去所述可查询时间戳的时间段来表示。可以对客户端查询隐藏在所述可查询时间戳之后被摄取的任意数据。当被摄取的所述数据被优化以满足预定义的查询性能要求时，所述可查询时间戳可以被更新。新鲜度、性能和成本的参数是可重新配置的。

本公开的另一个方面提供了一种管理分析数据管理系统(ADMS)的方法，包括使用摄取框架，将更新提交到存储在存储器中的一个或多个数据表中，使用存储框架，压缩所述一个或多个表，并增量地将所述更新应用于所述一个或多个表，以及使用查询服务框架，来响应客户端查询。根据一些示例，所述方法可以进一步包括使用控制平面中的控制器，协调包含所述摄取框架、存储框架和查询服务框架的数据平面中的工作。所述方法可以进一步包括使用所述控制器，调度压缩和视图更新任务，以及使用所述控制器，协调跨多个数据中心的元数据事务。根据一些示例，所述方法可以进一步包括使用所述摄取框架摄取多行数据，每行数据被分配元数据时间戳。每个表可以具有指示可被查询的所述数据的新鲜度的可查询时间戳，并且对客户端查询隐藏在所述可查询时间戳之后被摄取的任意数据。所述方法可以进一步包括优化被摄取的数据以满足预定义查询性能要求，以及当被摄取的所述数据被优化时，更新所述可查询时间戳。

附图说明

图1是示出根据本公开的方面的分析数据管理系统(ADMS)的部件的概念框图。

图2是示出了根据本公开的方面的ADMS的架构的框图。

图3是示出了根据本公开的方面的ADMS的摄取的示意图。

图4是示出了根据本公开的方面的可查询时间戳的时序图。

图5A-C示出了根据本公开的方面的不同类别。

图6是示出了根据本公开的各方面的客户端查询服务的方法的流程图。

图7A-B是示出了根据本公开的方面的与ADMS相关的延迟测量的曲线图。

图8是示出了根据本公开的方面的示例系统的框图。

图9是示出了根据本公开的各方面的摄取的示例方法的流程图。

图10是示出了根据本公开的各方面的查询服务的示例方法的流程图。

具体实施方式

ADMS可以服务于许多对查询性能、数据新鲜度和成本目标有不同要求的应用。查询性能和查询延迟在本文可以互换使用。数据新鲜度是通过将行添加到表中的时间到该行可供查询的时间之间的时间来衡量的。新鲜度要求范围从对新鲜度敏感的客户需要几分钟到对成本敏感的客户需要几个小时不等。成本可以包括例如由于数据处理而产生的机器资源成本。这种成本的示例包括摄取成本、后台维护操作和查询执行。通常，摄入和维护成本占主要。

灵活性

在数据新鲜度、资源成本和查询性能的一般类别中，客户端要求可能改变。一些客户端需要高新鲜度，而其他客户端可能希望优化原始查询性能或降低成本。

摄入和存储可能是耦合的。摄取是指将数据呈现给ADMS，并开始将其合并到系统中。存储是指已经应用于基表的新数据和它影响的所有物化视图。可能不希望设置约束，使得新数据被完全处理之前不能被摄取，或者新数据与查询耦合，从而降低查询性能。ADMS为客户端提供了调整系统的灵活性，并满足他们在数据新鲜度、资源成本和查询性能方面的目标。

图1是示出了ADMS的部件的概念框图。ADMS是高度可伸缩的，以处理更新流，并且以良好的性能同时服务数百万个查询。ADMS依赖于用于可预测和高查询性能的物化视图。

如图1所示，ADMS的高级架构包括三个主要部件:摄取框架110、存储框架120和查询服务130。

摄取框架110以高速率摄取数据行，诸如数十GB/s的压缩数据。它负责将更新或“增量”提交到表中。这种增量可以是例如数据库表中的一个或多个附加行、对一个或多个表的一组更新、或任意各种其他类型的更新。摄取框架110所写的增量用于满足摄取框架110的持久性要求，并且是写优化的。在可以将这些增量应用于表及其相关联视图之前，可以进一步合并它们。

存储框架120增量地将更新应用于表及其视图。ADMS表及其视图可以作为LSM林被增量地维护，其中每个表都是更新的集合。在压缩过程中，增量可以不断地被合并形成更大的增量。视图维护层通过应用相应的SQL转换将表增量转换为视图增量。存储层还负责定期压缩表和视图。它维护物化视图，这些视图在数据中心之间被索引且是一致的。

查询服务框架130负责回答客户端查询。系统在查询时间进行表(或视图)的必要增量的合并。查询延迟是查询时间合并工作量的函数，因此存储子系统处理更新的速度越快，在查询时间需要合并的增量就越少。

ADMS将摄取与视图维护解耦，并将视图维护与查询处理解耦。这种解耦为ADMS客户端提供了满足他们要求的旋钮，允许在新鲜度、性能和成本之间进行权衡。ADMS要求基表和视图的一致性，因此解耦确保了ADMS可以不断进步，而不管单个部件的性能。术语“旋钮”可以指可配置选项的可用性。摄取只依赖于初始运行生成(比如提交更新)，而不依赖于合并或视图维护。ADMS还为客户端提供了高级别的选择，可以转换为选择性索引数据，并限制查询时的合并量。

ADMS客户端可以选择“低工作量”来优化成本，接受降低的查询性能。“低工作量”意味着不积极的压缩，使得在查询执行时有较高的合并工作量。低工作量也可以表示更少的物化视图，或者降低的新鲜度，同时在与视图匹配的查询上仍然保持良好的查询性能。类似地，客户端也可以选择通过支付“更高的工作量”来优化良好的查询性能，例如更积极的压缩，这将导致查询时的低扇入合并，或者可以选择更有针对性的视图。

用户可以根据预期的查询性能、数据新鲜度和成本来指定他们的要求。这些要求转化为内部数据库配置，例如视图数量、处理任务的配额限制、查询处理期间可以打开的增量的最大数量等。在某个时间点，这些形成了客户端数据库的配置。然而，该系统不是静态的，因为数据不断地被摄取到表中，并且需要动态的、易于理解的指示符来指示在由客户端要求生成的配置情境中的数据库状态。

ADMS引入了可查询时间戳(QT)来为客户端提供实时标记。例如，QT可以是前进时间戳，其在满足一个或多个条件时前进。这种条件的示例可以是，表的视图直到时间T为止都是一致的，任意查询需要读取的增量的数量小于X，数据被复制到法定数量的数据中心等。QT是新鲜度的直接指示，并且[Now()-QT]指示数据延迟。客户端可以查询QT时间戳之前的所有数据。由于QT只有在生成了所需数量的视图时才能前进，并且也是增量的最大数量的上限，因此它保证了用于查询的数据满足了提供预期查询性能的条件。此外，QT的持续前进和保持在新鲜度目标内指示了在数据库配置中指定的成本约束内，系统能够更新表和视图。

在一个示例中，ADMS可能具有运行组织范围的内部实验分析框架的有成本意识客户端。对于该客户端，良好的查询性能和适中的成本是很重要的，即使系统需要较低的数据新鲜度。对于该客户端，QT前进标准取决于在查询执行时保持适中的视图数量和较少的要合并的增量。为保持低成本，ADMS执行框架使用更少的工作器任务和更便宜的机会主义机器资源进行视图维护。作为结果，即使视图维护的速度较慢，并因此数据的新鲜度也会受到影响，但ADMS以适中的资源成本为该客户端提供了良好的查询性能。

在第二个示例中，ADMS可能具有要求新鲜回答但具有低或中等查询性能要求的客户端。对于这样的客户端，QT前进标准取决于更少的视图，但是在查询执行时需要合并的增量可能相对更多。因为每个表和视图有更多的增量，所以查询性能较低。查询服务框架在I/O上花费了更多的时间，并折叠了更多的行，否则在视图维护和压缩期间会离线发生。ADMS执行框架指导更多的工作器进行摄取，而不是视图维护，因为视图维护工作量低。因此，这些客户端能够用查询性能换取更好的新鲜度和更低的资源成本。

在第三个示例中，ADMS客户端支持服务提供商的外部仪表板。对于这样的客户端，良好的查询性能和数据新鲜度是重要的，即使成本更高。对于这样的客户端，ADMSQT的前进标准取决于大量的视图，有时单个表会有数百个视图，并且合并时的增量数量非常少，以确保更短的查询执行时间。ADMS使用大量工作器任务来确保通过更快的摄取和高吞吐量视图维护来快速满足该QT标准。这种QT前进标准为客户端提供了所需的查询性能和数据新鲜度，但是资源成本相对较高。

这种不同类别的客户端要求是系统配置的一部分，ADMS使用这些配置作为指南来提供规定的查询性能、数据新鲜度和资源成本。

数据可用性

服务提供商内的许多服务可以被设计为承受可能由灾难性故障或定期维护导致的数据中心规模的停机。ADMS可以保证系统在出现这种停机下仍然可以运行。这种级别的容错可以通过在多个数据中心复制客户端数据库并确保数据库副本相互一致来提供。一种方法是使用全局一致的事务系统将ADMS摄取活动作为同步事务来执行。另一种方法将数据和元数据操作的执行解耦，使得数据操作在数据中心的每个副本上异步执行，并且元数据操作被周期性地使用以确保副本保持彼此同步。ADMS协调了该高度分布式机器的同步和异步模式。QT指示数据库中的所有表和视图在所有数据中心之间全局一致的状态。尽管压缩和视图维护是在每个副本上异步执行的，但是系统会从一个一致状态转移到另一个一致状态。

系统架构

图2示出了ADMS的高级架构的示例，包括数据平面200和控制平面250。该架构可以部署在多个数据中心，以管理每个数据中心的副本。数据平面250包括摄取210、存储220和查询服务230。控制平面由控制器255组成，控制器255协调各种子系统之间的工作。控制器255还负责跨多个数据中心同步和协调元数据事务。ADMS客户端创建数据库和表以及它们相关联的模式。客户端可以选择为每个表创建物化视图。

ADMS可以通过利用现有的基础结构部件来构建，例如具有分散存储基础结构的文件系统。在这方面，ADMS中的表可以是分散文件系统中的文件集合。对于需要严格事务语义的功能(例如元数据管理和存储系统状态)，ADMS可以使用分布式数据库。ADMS可以使用查询处理系统(例如符合SQL的系统)，用于查询服务和大规模数据处理(例如视图创建和维护)。查询处理系统可以支持流式处理和批处理，并且同一系统可以用于交互式查找查询以及处理大量数据的查询。根据其他示例，可以开发用于ADMS的专用基础设施。

ADMS客户端可以使用提取-转换-加载(ETL)管道将数据插入到它们的表中。摄取框架210可以承受非常高的负载，诸如数十GB/s的压缩数据。客户端数据被传输到任意ADMS副本，并且ADMS确保数据摄取在所有数据中心进行。

ADMS擅长处理客户端使用复杂过滤器(例如驱动仪表板的过滤器)发出聚合查询的工作负载。作为结果，存储和视图维护框架用于维护这些聚合。存储框架220负责压缩表以及增量地更新视图。压缩需要合并增量，通常具有高扇入，以创建更大的增量，这减少了查询期间的合并。这类似于LSM树中的后处理，其中离线进程花费的I/O将工作从在线查询转移。

查询服务230在运行时处理必要的缓存、预取和增量合并。查询服务的目标是提供低延迟和低变化的查询。低延迟是通过将查询定向到预先计算的物化视图(而不是基表)以及并行执行查询来实现的。低变化是通过控制合并的扇入以及一系列其他I/O减少和尾部公差技术来实现的。

ADMS依赖视图来获得良好的查询性能。包括物化视图在内的ADMS表按其(多部分)主关键字进行排序、索引和范围分区。ADMS工作负载的严格延迟和资源要求有利于利用索引关键字查找。大多数ADMS查询可以通过范围分区索引表有效地回答。ADMS可以为效率依赖合并和排序性能，并且因此排序、合并和分组运算符可以加快速度。

ADMS控制器255调度压缩和视图更新任务，以将表的增量计数保持在可配置的值。给定成本权衡，这些存储任务可以保持可查询时间戳(QT)尽可能地新鲜。数据库QT形成了数据库新鲜度的基础，并被查询系统用来提供如前所述的健壮的查询性能。ADMS支持接近实时到几个小时的数据库新鲜度；大多数客户端要求其数据库保持大约几十分钟的新鲜度。如果新鲜度落在期望的范围之外，则系统继续服务于客户端查询。然而，与新鲜度要求相比，在这种情况下提供的数据将是陈旧的，并且可能需要管理动作(例如通过暂时允许更高的成本来调整折衷)以使新鲜度回到该范围内。ADMS有数百个数据库，包含成百上千个表和视图，每个表和视图都有稳定的摄取速率。然而，该系统能够将所有这些数据库保持在期望的新鲜度，这证明了它的健壮性。

摄取框架210允许摄取管道在没有显著开销的情况下将大量数据插入ADMS。图3是示出了ADMS的摄取的示意图。摄取服务器312接收数据，并且可以进行批处理、分类和物化。所有被摄取的行被分配元数据时间戳315用于排序，然后在其他持久性条件(诸如复制等)得到满足后被标记为已提交。摄取框架通过允许配置增加或减少接受数据并进行批处理、聚合和复制的摄取工作的任务数量，提供了限制峰值机器成本的旋钮。

客户端将待摄取的数据传递给ADMS副本325中的任意一个。ADMS确保数据在所有副本上被接收，以确保可用性。摄取框架产生写优化增量，因为它们很小，并且它们的物理大小受到服务器的内存缓冲器的限制。因为有许多这样的增量，这些增量不能立即用于查询，这将降低查询服务的速度，因为它必须合并它们。这些增量可以被称为不可查询的，并且可能需要在它们可以被查询之前被压缩。

可查询时间戳

图4是示出了将查询性能与存储性能解耦的可查询时间戳的时序图。表的可查询时间戳(QT)是指示可查询数据的新鲜度的时间戳。如果QT(表)＝X，客户端可以查询在时间X之前摄取到表中的所有数据，而时间X之后的数据不是查询结果的一部分。换句话说，表的新鲜度是[Now()-QT]。QT充当了屏障，使得在X之后被摄取的任意数据对于客户端查询都是隐藏的。一旦(Y-X)范围内的数据被优化以满足查询性能要求，QT的值将从X提高到Y。反过来，客户端可以使用ADMS的配置选项和该单个客户端可见的指标来调整新鲜度、查询性能和成本。例如，如果客户端希望高查询性能和低成本，但可以牺牲新鲜度，则系统会优先使用较少的机器资源来维护视图以降低成本，且QT可能会进展缓慢，从而指示降低的数据新鲜度。

通过优化用于读取的底层数据以及确保视图可用于加速查询，可以确保良好的查询性能。如图4所示，ADMS中的表是其所有增量文件的集合，每个增量对应于在时间窗口内接收到的对该表的更新。不可查询增量对应于由摄取框架在最近的时间窗口(通常是秒)中写入的新接收的更新。另一方面，最大的增量跨越数周甚至数月的时间窗口。每个增量按其关键字排序，范围分区，并有类似本地B树的索引。这些增量在查询时根据需要被合并。

大多数客户端查询都有严格的延迟约束，这对于在查询执行期间应该被打开和合并的增量的最大数量(x)有严格的限制。特别地，可查询时间戳(QT)是形成x的边界(从最老的增量向最新的增量计数)的增量。该限制可以是例如几十个增量。根据一些示例，该限制可以根据对数据库的查询性能要求来自动配置。例如，自动化模块可以基于查询工作负载动态地调整该限制。具有高查询工作负载和严格查询性能要求的表有较低的限制，但是那些查询要求较低的表有较高的限制。对于可以支持多大的x数有一些实际的限制。随着该数字变大，查询开始受到尾部效应的影响。考虑到查询时间合并非常昂贵，通过保持给定数据库的增量数量接近恒定，ADMS能够提供健壮的查询性能。在这方面，ADMS提供了查询延迟变化低的有力保证。

QT可能本质上依赖于后台操作的进度，例如压缩和增量视图维护。数据库的QT是数据库中所有表的QT的最小值。QT还用于为客户端提供跨所有ADMS副本的一致的数据视图。每个副本都有QT的本地值，该值基于本地副本中数据的新鲜度。QT的全局值是基于查询服务可用性要求从本地QT值计算的。例如，如果5个ADMS副本的本地QT值为100、90、83、75、64，并且查询服务要求大多数副本可用，则所有站点上的新QT被设置为83，因为大多数副本是最近的，至少是83。ADMS将使用QT至少为83的副本来回答查询，因为它保证对这些副本的查询只需要读取本地可用的增量。

大规模维护视图

ADMS的存储子系统负责维护视图和压缩增量。它还负责通过跨数据中心的复制来确保数据的完整性和持久性，并处理从单个机器到整个数据中心的停机。

ADMS存储子系统高效地管理数千个表和视图，例如在拍字节级，甚至在存在数据倾斜的情况下。视图维护中的倾斜发生在将基表上的更新转换为视图上的更新的过程中。基表关键字空间到视图关键字空间的映射可能导致中断，其中大多数基表更新可能映射到窄的视图关键字范围，导致倾斜。由于数据库的QT是由最慢的视图或表确定的，因此系统必须自动调整以适应大小的变化和前述的数据倾斜，以确保QT不会受到掉队视图或表的影响。存储子系统还通过改变视图、任务的数量和所用机器资源的类型来调整成本预算。视图维护框架可以包括使用查询处理系统作为“数据泵”，重新规划以避免数据倾斜，以及循环中的智能。

关于将查询处理系统用作“数据泵”，关系数据泵可用于压缩表和维护视图。视图维护使用查询优化器，可以在备选计划中做出好的选择。

关于重新计划以避免数据倾斜，如果检测到数据倾斜，系统可以即时重新计划。例如，ADMS中的许多表的第一关键字是有几个不同值的日期列。即使基表可能有数百个关键字列，但大多数关键字列大多为零或与另一个关键字有很强的相关性。在大规模内，未能检测到倾斜可能意味着视图维护查询可能永远不会完成，从而导致无界限的刷新延迟。

关于循环中的智能，只有当所有表和视图都跟上时，数据库才能前进QT。这意味着QT被最慢的视图阻塞，并需要相当复杂的掉队缓解。ADMS控制器实施了尾部掉队的智能，例如通过使用基于历史负载选择用于任务执行的数据中心、基于进度的主动掉队任务终止以及并发任务执行的技术来界定尾部的大小。

视图维护中的查询优化

ADMS的视图维护过程有效地利用了输入中的数据属性。由于所处理的数据量以及由于使得大规模查询处理变得复杂的特定数据属性(如基数稀疏性、相关性等)，视图更新查询必须解决独特的优化挑战。有效地处理大量数据意味着必须小心不要破坏有益的数据属性，如排序和分区，这些属性很难重新创建。

数据属性的示例是要更新的视图相对于基表的排序顺序。一种方法是根据视图排序顺序对视图关键字重新排序，而不考虑基表的排序顺序。在大规模生产中，这将是一个昂贵的处理方案。相反，尽可能保留输入排序是有益的；即使视图的排序顺序和基表的排序顺序只是部分重叠，也要利用排序性。类似地，更改数据分区属性需要跨网络移动数据，这通常也会影响排序，除非绝对必要，否则应该避免这样做。

图5A-C示出了基于视图和基表关键字列的共性的不同类别的视图。第一类视图是那些与基表共享前缀的视图，例如图5A中的对齐视图。例如，基表有关键字(A，B，C)，而视图在(A，B)上。在这种情况下，该框架通过基于公共关键字前缀(A，B)聚类输入并以流式进行聚合来完全避免排序。

第二类视图是那些具有基表的部分前缀但没有完整前缀的视图，例如图5B的部分对齐视图。例如，基表具有(A，B，C，D)，而视图在(A，B，D)上。可以通过在(A，B)上聚类输入基表，然后在D上对每个唯一(A，B)组进行排序，来利用输入排序顺序。部分前缀上的聚类可能导致倾斜，这应该被检测到并被补救。

第三类视图是那些基表和视图不共享任意前缀的视图，例如图5C的未对齐视图。例如，基表是(A，B，C，D)，而视图是(D，C，A)。优化的机会很少，并且这些视图在实践中是最昂贵的，因为它们需要重新分区和重新排序。

与基表相比，一些视图具有很高的聚合缩减率，例如100-1000倍，因此视图更新与原始表更新相比很小。还有一些视图几乎与基表一样大。对于具有高基数缩减的视图，保留排序顺序并不是最重要的，因为输出足够小，只关注缩减基数并在需要时重新排序输出可能是可行的。另一方面，对于视图聚合度较低的情况，比如视图与基表的大小相似，排序和合并效率就变得很重要。从变异服务器到排序运算符，ADMS的排序库可以应用于跨排序数据的所有ADMS部件。

压缩

压缩将多个输入增量合并为单个输出增量。压缩通过1)将输入一起排序和2)将多个更新聚合到同行来提高查询性能并减少存储消耗。关于查询的异步压缩既减少了查询时的合并工作，又在多个查询之间利用了压缩的结果。然而，对于高摄取率的表，压缩的计算开销很大，并且会延迟数据变得可查询的时间，从而降低数据的新鲜度。如前所述，客户端的配置控制着这种权衡。例如，针对查询性能进行优化的配置会频繁压缩，使得在查询时合并的增量的最大数量小于10，但是这样的配置具有显著的摄取延迟和高压缩成本。

因为增量文件是单独排序的，所以压缩可以类似于合并排序。与客户端查询不同，在客户端查询中，合并的扇入保持较小且有界以避免尾部效应，在压缩期间有意保持较大，以便合并树的高度较小，从而最小化关键字比较。压缩查询的扇入可以达到大约一千个输入，超过这个范围合并性能可能会下降。合并过程在各种输入之间划分固定的存储器预算。在大约一千个输入时，每个输入流的存储器很小。此外，当其中一个输入被消耗时，合并过程停止。在一千路合并时，这种情况发生的频率比10路合并时高100倍。这两种效果的结合使大型路合并变得不高效，这可以通过I/O预取来弥补。

健壮的查询服务性能

图6是示出了ADMS中的客户端查询服务的机制的流程图。许多ADMS客户端可能有需要在毫秒级内获得查询结果的商用情况。延迟要求适用于尾部情况(例如第99百分位)以对拍字节大小的表进行范围查找，以及当底层共享基础结构在性能和可用性方面波动时。查询服务子系统可以使用可查询时间戳(QT)、物化视图和一系列其他技术来实现健壮的性能。

如图6所示，在查询处理系统(QPS)数据中心650接收查询602。QPS服务器652将它们划分成多个子查询。例如，QPS服务器652可以将查询602划分成几十、几百、几千、几万或更多的子查询。该划分可以基于例如过滤判断、延迟预算和/或查询服务资源的可用性来提高性能。分区查询的分布式执行可以由一个或多个QPS工作器654来执行。例如，QPS工作器654可以从增量服务器674读取数据。元数据服务器672可以处理元数据。根据一些示例，要处理的元数据的版本基于QT。元数据服务器672还可以基于元数据来确定哪些数据必须被处理。增量服务器674可以通过分布式缓存676读取增量684。增量684可以与ADMS索引682一起存储在ADMS数据中心670中的文件系统680中。

ADMS使用多种技术来减少为回答关键路径上的查询而读取的数据量。只要有可能，ADMS就使用视图而不是基表来回答查询，因为具有聚合函数的视图可能具有很少的数据。当QPS工作器654从增量服务器674读取数据时，过滤器和部分聚合被下推以最小化通过网络传输到QPS工作器654的字节量。QPS工作器654和ADMS存储(例如文件系统680)并不总是位于同一个数据中心。跨数据中心网络传输可能比数据中心内部传输具有更大的延迟变化。ADMS还依靠并行性来减少每个子查询必须读取的数据量。ADMS在其存储的数据上维护稀疏的B树索引，并使用它们将输入查询快速划分成数千个满足过滤判断的子查询。这种分区机制还会考虑查询服务资源的延迟预算和可用性以获得良好的性能。

鉴于大规模数据集以及对共享和分散存储的依赖，如果必须从磁盘甚至SSD读取元数据或数据，可能会出现高延迟。这种元数据的示例可以包括数据统计、视图定义、增量元数据等。当发出查询602时，ADMS使用QT值来决定要处理的元数据的版本。元数据又决定了什么数据必须被处理。因此，元数据读取可以位于查询服务的关键路径上。ADMS确保所有元数据始终可以从存储器中提供，而无需联系永久存储。这是通过具有周期性后台刷新的元数据缓存实现的，例如基于相似性的分布式元数据缓存。特定的QT被延迟以等待元数据的周期性后台刷新的完成。

所有数据读取都经过透明的分布式数据缓存层676，文件I/O操作通过该层。分布式缓存676是读通过的，并且共享对相同数据的并发读取未命中的工作。共享工作提高了分布式缓存的效率。当处理同一查询的不同子查询时，多个增量服务器674可以读取重叠范围的索引文件，并且分布式数据缓存676确保这样的读取仅被处理一次。

分布式缓存层676显著减少了I/O的数量。ADMS可以进行离线和在线预取，以进一步减少关键路径中顺序I/O的数量。一旦频繁被查询的表的数据被摄取，在QT前进以使新数据可用于查询之前，就可能发生离线预取。在线预取在查询602到达时开始，并且可以由影子查询执行器执行，影子查询执行器与主查询执行器共享数据访问模式，但是跳过所有查询处理步骤。由于影子查询执行器跳过处理，它在主查询执行器之前运行，实现了比基于过去访问的磁盘预读更准确的预取效果。

在查询服务期间，ADMS通过将查询划分为细粒度单元，然后跨增量和跨被查询列来并行化I/O调用，以积极地并行化工作。这种并行化可能导致尾部延迟。例如，如果每个ADMS查询向磁盘发出一千个并行I/O，则ADMS的第90个百分点的延迟将受到底层磁盘存储的第99.99个百分点的延迟的影响，这通常远远高于其第90、第99和第99.9个百分点的延迟。为了对抗尾部延迟的这种放大，ADMS使用QT来限制可查询增量的数量。此外，ADMS可以尽可能多地组合小I/O，例如通过使用跨增量的惰性合并技术和基于大小的磁盘布局。

关于跨增量的惰性合并，在一个简单的查询计划中，ADMS将自己作为具有主关键字的数据源暴露给查询优化器。当处理子查询时，每个增量服务器674首先基于完整的主关键字合并所有增量684上的行。当有几千(N)个子查询和几十(M)个增量684时，并行IO的数量在几万(N×M)的数量级。然而，由于并行性，每个子查询从大多数增量684中读取非常少的数据。同时，在查询计划的后续阶段，很大一部分ADMS查询要求基于主关键字的子集进行合并。在这些情况下，ADMS调整查询计划以避免增量服务器674中的交叉增量合并，并让每个增量服务器674仅处理一个增量，将N×M个并行IO组合成接近N个并行IO。

关于基于大小的磁盘布局，ADMS使用定制的列存储格式，支持基于增量大小应用的多种磁盘布局选项。可以将所有列访问合并到一个IO中进行查找查询的PAX布局可以应用于小增量。对于大增量，可以使用逐列布局，这对于扫描查询来说是IO高效的，但是对于查找查询来说每列需要一个IO。这种基于大小的选择确保ADMS获得列存储优势，并减少IO操作。

ADMS采用容忍尾部延迟的原则。对于非流式远程过程调用(RPC)(例如元数据服务器672和增量服务器674之间的RPC)，ADMS使用对冲机制，在特定延迟之后将与原始RPC相同的第二RPC发送到不同的服务器，并等待更快的答复。

对于流式RPC，例如查询处理服务(QPS)工作器和增量服务器之间的RPC，ADMS估计它的预期进度，并要求定期执行它的服务器报告进度以及延续令牌。如果报告的进度低于预期或报告丢失，则最近的延续令牌将用于在不同的服务器上重新启动新的流式RPC，而不会丢失进度。在进度报告中，需要小心处理下推运算符(如过滤和部分聚合)，因为它们可以显著减少数据大小，导致进度报告表面上很低或是甚至缺失。ADMS使用过滤和部分聚合之前处理的字节作为进度指标，并定期强制这些运算符刷新其内部状态，以生成带有延续令牌的进度报告。

对于影响查询服务但不影响摄取的数据中心范围内的问题，上述尾部容差机制将发挥作用，并自动将查询重新路由到相邻数据中心中的服务器。当摄取受到影响时，在受影响的数据中心中，数据中心本地QT被延迟，并且查询将基于本地QT值被直接路由到其他数据中心。

图7A示出了随着视图数量增加，查询延迟的减少，而图7B示出了被允许跨越的查询的增量数量以及相应的延迟影响。较低的延迟影响通常更有益。

通过更积极地使用视图，通过更改存储策略并因此减少增量数量以及因此减少尾部延迟，以及通过解耦摄取、视图维护和查询执行，ADMS能够提供健壮的查询性能，从而减轻基础结构和工作负载变化对查询性能的影响。

图8示出了示例分布式计算环境，其中可以实施ADMS。多个数据中心860、870、880可以通信地耦合，例如通过网络850。数据中心860、870、880可以进一步通过网络850与一个或多个客户端设备(例如客户端810)通信。在一些示例中，数据中心860、870、880可以进一步与控制器890通信。

数据中心860-880可以位于彼此相距相当远的位置。例如，数据中心可能位于世界各地的不同国家。每个数据中心860、870、880可以包括一个或多个计算设备，例如处理器、服务器、分片等。例如，如图8所示，数据中心860包括主机计算设备862和多个存储设备864，数据中心870包括存储设备874，以及数据中心880包括存储设备884。虽然数据中心870、880中未示出处理设备(例如服务器、虚拟机主机或其他处理设备)，但是应当理解，它们也可以被包括在内。根据一些示例，计算设备可以包括在主机上运行的一个或多个虚拟机。此外，应当理解，图8所示的配置仅仅是一个示例，并且每个示例数据中心860-880中的计算设备可以具有彼此相同或不同的各种结构和部件。

程序可以跨这些计算设备执行，例如，使得一些操作由第一数据中心的一个或多个计算设备执行，而其他操作由第二数据中心的一个或多个计算设备进行。在一些示例中，各个数据中心中的计算设备可以具有不同的能力。例如，不同的计算设备可以具有不同的处理速度、工作负载等。虽然仅示出了这些计算设备中的一些，但是应当理解，每个数据中心860、870、880可以包括任意数量的计算设备，并且第一数据中心中的计算设备的数量可以不同于第二数据中心中的计算设备的数量。此外，应该理解，每个数据中心860-880中的计算设备的数量可以随着时间而变化，例如，随着硬件被移除、替换、升级或扩展。

存储设备864、874、884可以包括硬盘驱动器、随机存取存储器、磁盘、磁盘阵列、磁带驱动器或任意其他类型的存储设备。存储864、874、884可以作为SAN被提供在托管由存储支持的虚拟机的数据中心内，或者被提供在不与其支持的虚拟机共享物理位置的不同数据中心内。数据中心860-880可以实现多种结构和技术中的任意一种，包括但不限于直连式存储(DAS)、网络附属存储(NAS)、存储区域网络(SAN)、光纤通道(FC)、以太网光纤通道(FCoE)、混合结构网络等。除了存储设备之外，数据中心860-880可以包括许多其他设备，例如电缆、路由器等。此外，在一些示例中，数据中心860-880可以是虚拟化环境。此外，虽然仅示出了几个数据中心860-880，但是许多数据中心可以通过网络850和/或附加网络耦合。

存储设备864、874、884可以包括对应于复制磁盘的数据。例如，可以在数据中心860的第一存储设备中的第一副本中复制磁盘，也可以在数据中心880的第二存储设备中的第二副本中复制磁盘。根据其他示例，可以在同一数据中心内的多个不同存储设备上复制磁盘。跨其复制磁盘的存储设备的数量可以变化。例如，尽管在本示例中磁盘被跨两个存储设备复制，但是根据其他示例，可以实施额外的副本。

虚拟机866可以附接到磁盘的一个或多个副本。例如，VM866可以附接到可信副本。

在一些示例中，控制器890可以与数据中心860-880中的计算设备通信，并且可以促进程序的执行。例如，控制器890可以跟踪每个计算设备的容量、状态、工作负荷或其他信息，并使用这种信息来分配任务。

控制器890可以包含处理器898、存储器892和通常存在于通用计算机中的其他部件。存储器892可以存储处理器898可访问的信息，包括可由处理器898执行的指令896。存储器还可以包括可以由处理器898检索、操纵或存储的数据894。存储器892可以是一种能够存储可由处理器898访问的信息的非暂时性计算机可读介质，例如硬盘驱动器、固态驱动器、磁带驱动器、光存储器、存储卡、ROM、RAM、DVD、CD-ROM、可写和只读存储器。系统可以包括存储器的不同组合，由此指令和数据的不同部分被存储在不同类型的介质上。处理器898可以是众所周知的处理器或其他不太为人所知的处理器类型。或者，处理器898可以是专用控制器，例如ASIC。

指令896可以是由处理器898直接执行的一组指令(例如机器代码)，或者间接执行的一组指令(例如脚本)。在这点上，术语“指令”、“步骤”和“程序”在本文可以互换使用。指令896可以以目标代码格式存储，以便由处理器898直接处理，或者以其他类型的计算机语言存储，包括按需解释或预先编译的独立源代码模块的脚本或集合。

处理器898可以根据指令896检索、存储或修改数据894。例如，尽管该系统和方法不受特定数据结构的限制，但是数据894可以存储在计算机寄存器中，存储在关系数据库中作为具有多个不同字段和记录的表，或者存储在XML文档中。数据894也可以被格式化为计算机可读格式，例如但不限于二进制值、ASCII或Unicode。此外，数据894可以包括足以识别相关信息的信息，例如数字、描述性文本、专有代码、指针、引用存储在其他存储器(包括其他网络位置)中的数据，或者由函数用来计算相关数据的信息。

尽管图8在功能上示出处理器898和存储器892在同一框内，但是处理器898和存储器892实际上可以包括多个处理器和存储器，这些处理器和存储器可以存储在也可以不存储在同一物理外壳内。例如，一些指令896和数据894可以存储在可移动的CD-ROM上，而其他的可以存储在只读计算机芯片内。一些或所有指令和数据可以存储在物理上远离处理器898但仍可由处理器898访问的位置。类似地，处理器898实际上可以包括处理器的集合，其可以并行操作或者可以不并行操作。

类似于上述控制器890，客户端810可以包括处理器820和存储器830，包括数据834和指令832。每个客户端810可以是个人计算机，旨在由具有通常在个人计算机中找到的所有内部部件的人使用，这些部件例如中央处理单元(CPU)、CD-ROM、硬盘驱动器和显示设备(例如具有屏幕的监视器、投影仪、触摸屏、小型LCD屏幕、电视或另一设备例如可操作来显示由处理器820处理的信息的电子设备)、扬声器，调制解调器和/或网络接口设备、用户输入，例如鼠标、键盘、触摸屏或麦克风，以及用于将这些元件相互连接的所有部件。此外，根据本文描述的系统和方法的计算机可以包括能够处理指令并向人类和其他计算机传输数据和从人类和其他计算机传输数据的设备，包括通用计算机、PDA、平板电脑、移动电话、智能手表、缺乏本地存储能力的网络计算机、电视机顶盒和其他联网设备。

客户端810可以包括例如位于客户位置的计算设备，其利用云计算服务，例如基础设施即服务(IaaS)、平台即服务(PaaS)和/或软件即服务(SaaS)。例如，如果计算设备810位于商业企业，则客户端810可以使用云系统作为提供软件应用(例如会计、文字处理、库存跟踪等应用)到在操作企业系统中使用的客户端810的服务。此外，客户端810可以访问云计算系统作为其操作的一部分，该操作采用机器学习、深度学习或更一般的人工智能技术来训练支持其商业企业的应用。

客户端810、数据中心860-880和控制器890能够例如通过网络850进行直接和间接通信。例如，使用网络套接字，客户端810可以通过互联网协议组连接到在远程服务器上运行的服务。服务器可以设置监听套接字，该监听套接字可以接受发送信息和接收信息的初始连接。网络850和中间节点可以包括各种配置和协议，包括因特网、万维网、内联网、虚拟专用网、广域网、局域网、使用一个或多个公司专有通信协议的专用网、以太网、WiFi(例如，702.78、702.78b、g、n或其他这样的标准)和HTTP，以及前述的各种组合。这种通信可以通过能够向传输数据和从其他计算机传输数据的设备来实现，例如调制解调器(例如，拨号、电缆或光纤)和无线接口。

除了上面描述的和附图中示出的操作之外，现在将描述各种操作。应当理解，以下操作不必按照下述的精确顺序来执行。相反，可以以不同的顺序或同时地处理各种步骤，并且还可以添加或省略步骤。

图9示出了使用ADMS摄取数据的示例方法。这种方法可以例如使用摄取框架来执行。

在框910，使用摄取框架来摄取多行数据，例如以上结合图3的描述。例如，可以摄取几十、几千、几十万或更多行。

在框920中，元数据时间戳被分配给每个被摄取的行。在框930，进行摄取工作。例如，这种摄取工作可以包括批处理、分类、聚合、复制、物化等。根据一些示例，摄取工作可以使用被分配的元数据时间戳来进行。例如，可以基于被分配的元数据时间戳对行排序。

在框940，来自被摄取行的数据被作为优化增量传送给ADMS副本。根据一些示例，当满足复制时，每行可被标记为已提交。

图10示出了使用ADMS进行查询的示例方法。这种方法可以如以上结合图6的描述来进行，例如使用查询服务框架。

在框1010，接收查询。在框1020中，查询可以被划分为多个子查询。例如，查询可以被划分为几十个、几千个或更多的子查询。划分可以取决于可用的工作器资源。

在框1030，分布子查询以供执行。例如，子查询可以分布到分布式系统中的多个工作器或服务器。

在框1040，通过分布式数据缓存层从增量中读响应于查询的数据。

本公开的各方面可以在数字电路、计算机可读存储介质中实施为一个或多个计算机程序，或者一个或多个前述程序的组合。计算机可读存储介质可以是非暂时性的，例如，作为可由云计算平台执行并存储在有形存储设备上的一个或多个指令。

在本说明书中，短语“配置为”用于与计算机系统、硬件或计算机程序、引擎或模块的一部分相关的不同上下文中。当系统被提到被配置为执行一个或多个操作时，这意味着该系统具有安装在该系统上的适当的软件、固件和/或硬件，当在操作时，这些软件、固件和/或硬件使该系统执行一个或多个操作。当某个硬件被提到被配置为执行一个或多个操作时，这意味着该硬件包括一个或多个电路，在操作时，这些电路接收输入并根据该输入生成对应于一个或多个操作的输出。当计算机程序、引擎或模块被提到被配置为执行一个或多个操作时，这意味着计算机程序包括一个或多个程序指令，当由一个或多个计算机执行时，该程序指令使得一个或多个计算机执行一个或多个操作。

虽然附图中所示和权利要求中所述的操作是以特定顺序示出的，但是应当理解，这些操作可以以与所示不同的顺序来执行，并且一些操作可以被省略、执行不止一次和/或与其他操作并行执行。此外，被配置用于执行不同操作的不同系统部件的分离不应被理解为要求部件被分离。所描述的部件、模块、程序和引擎可以集成在一起作为单个系统或者是多个系统的一部分。

除非另有说明，否则前述替代示例并不相互排斥，而是可以以各种组合来实施，以实现独特的优点。由于在不脱离权利要求所定义的主题的情况下，可以利用上述特征的这些和其他变型和组合，因此前面对示例的描述应该被理解为是说明性的，而不是对权利要求所定义的主题的限制。此外，本文所提供的描述的示例，以及措辞为“诸如”、“包括”等的条款，不应该被解释为将权利要求的主题限制到特定的示例；相反，这些示例仅旨在说明许多可能的实施方式中的一种。此外，不同附图中的相同附图标记可以标识相同或相似的元件。

Claims (21)

1.一种分析数据管理系统(ADMS)，其特征在于，包括:

摄取框架，被配置为将更新提交到存储在存储器中的一个或多个数据表中；

存储框架，被配置为压缩所述一个或多个表，并增量地将所述更新应用于所述一个或多个表；以及

查询服务框架，被配置为响应客户端查询。

2.根据权利要求1所述的ADMS，其特征在于，压缩所述一个或多个表包括在将所述更新应用于所述一个或多个表之前合并多个增量更新。

3.根据权利要求1所述的ADMS，其特征在于，所述查询服务框架将查询导向预先计算的物化视图。

4.根据权利要求3所述的ADMS，其特征在于，包括所述预先计算的物化视图的所述一个或多个表通过主关键字被进行排序、索引和范围分区。

5.根据权利要求1所述的ADMS，其特征在于，进一步包括:

数据平面，包括所述摄取框架、所述存储框架和所述查询服务框架；以及

控制平面，包括控制器，其中，所述控制器协调所述摄取框架、所述存储框架和所述查询服务框架之间的工作。

6.根据权利要求5所述的ADMS，其特征在于，所述控制器调度压缩和视图更新任务。

7.根据权利要求5所述的ADMS，其特征在于，所述控制器协调跨多个数据中心的元数据事务。

8.根据权利要求1所述的ADMS，其特征在于，所述摄取框架被配置为摄取多行数据，每行数据被分配元数据时间戳。

9.根据权利要求8所述的ADMS，其特征在于，摄取所述多行数据进一步包括批处理、聚合和复制所述数据。

10.根据权利要求1所述的ADMS，其特征在于，所述摄取框架包括位于不同地理位置的多个副本，并且其中，所述框架被配置为摄取在所述多个副本中的任意副本处的所述数据。

11.根据权利要求1所述的ADMS，其特征在于，每个表具有指示可被查询的所述数据的新鲜度的可查询时间戳。

12.根据权利要求11所述的ADMS，其特征在于，所述新鲜度由等于当前时间减去所述可查询时间戳的时间段来表示。

13.根据权利要求11所述的ADMS，其特征在于，对客户端查询隐藏在所述可查询时间戳之后被摄取的任意数据。

14.根据权利要求13所述的ADMS，其特征在于，当被摄取的所述数据被优化以满足预定义查询性能要求时，所述可查询时间戳被更新，其中，这种优化包括基于服务器的存储缓冲器或压缩来限制更新的物理大小中的至少一个。

15.根据权利要求11所述的ADMS，其特征在于，新鲜度、性能和成本的参数是可重新配置的。

16.一种管理分析数据管理系统(ADMS)的方法，其特征在于，包括:

使用摄取框架，将更新提交到存储在存储器中的一个或多个数据表中；

使用存储框架，压缩所述一个或多个表，并增量地将所述更新应用于所述一个或多个表；以及

使用查询服务框架，来响应客户端查询。

17.根据权利要求16所述的方法，其特征在于，进一步包括:

使用控制平面中的控制器，协调包含所述摄取框架、所述存储框架和所述查询服务框架的数据平面中的工作。

18.根据权利要求17所述的方法，其特征在于，进一步包括:

使用所述控制器，调度压缩和视图更新任务；以及

使用所述控制器，协调跨多个数据中心的元数据事务。

19.根据权利要求16所述的方法，其特征在于，进一步包括使用所述摄取框架摄取多行数据，每行数据被分配元数据时间戳。

20.根据权利要求19所述的方法，其特征在于，每个表具有指示可被查询的所述数据的新鲜度的可查询时间戳，并且对客户端查询隐藏在所述可查询时间戳之后被摄取的任意数据。

21.根据权利要求20所述的方法，其特征在于，进一步包括:

优化被摄取的数据以满足预定义查询性能要求，其中，这种优化包括基于服务器的存储缓冲器或压缩来限制更新的物理大小中的至少一个；以及

当被摄取的所述数据被优化时，更新所述可查询时间戳。