CN111480154A - 在数据库系统中的批量数据摄取 - Google Patents

Abstract

用于将数据批量摄取到数据库的表中的系统、方法和设备。一种方法包括确定指示从客户端账户接收的将被摄取到数据库中的用户文件的存在的通知。该方法包括识别用户文件中的数据和识别数据库的目标表以接收用户文件中的数据。该方法包括生成指示数据和目标表的摄取任务。该方法包括将摄取任务分配到执行平台的执行节点，其中执行平台包括独立于共同存储数据库数据的多个共享存储设备而操作的多个执行节点。该方法包括在数据由执行节点完全提交到目标表之后在元数据储备库中登记涉及目标表的元数据。

Description

在数据库系统中的批量数据摄取

相关申请的交叉引用

本申请要求于2017年11月27日提交的标题为“SYSTEMS,METHODS,AND DEVICESFOR BATCH DATA INGESTION”的美国临时专利申请序列号62/591,118的优先权，该临时专利通过引用被全部并入本文，包括但不限于在下文中特别出现的那些部分，该通过引用的并入与下面的例外一起被做出：如果上面引用的申请的任何部分与本申请不一致，本申请取代上面引用的申请。

技术领域

本公开涉及数据库，且更特别地涉及在数据库或表中的数据的增量摄取(ingestion)。

背景

数据库广泛用于在计算应用中的数据存储和访问。数据库可以包括一个或更多个表，其包括或引用可以使用查询来读取、修改或删除的数据。数据库可以在一个或更多个表中在任何地方存储从小到极大的数据集。该数据可由组织中的各种用户访问，或甚至可用于例如通过网站或应用程序接口(API)来为公共用户服务。计算和存储资源及其底层架构可以在实现理想的数据库性能方面起重要作用。

数据可以从一个数据桶被摄取到数据库的一个或更多个表中。各种系统被开发、描述，并且被广泛已知用于在数据库或表中上传和存储数据。例如，在共享磁盘系统中，所有数据存储在从数据集群中的所有处理节点可访问的共享存储设备上。在这种类型的系统中，所有数据变化被写入到共享存储设备以确保在数据集群中的所有处理节点访问数据的一致版本。当处理节点数量在共享磁盘系统中增加时，共享存储设备(以及在处理节点和共享存储设备之间的通信链路)成为减慢数据读取和数据写入操作的瓶颈。这个瓶颈随着更多处理节点的添加而进一步加剧。因此，由于这个瓶颈问题，现有的共享磁盘系统具有有限的可扩展性。

另一个现有的数据存储和检索系统被称为“无共享架构”。在这种架构中，数据分布在多个处理节点当中，使得每个节点在整个数据库中存储数据的子集。当新的处理节点被添加或移除时，无共享架构必须在多个处理节点当中重新排列数据。数据的这个重新排列可能是耗时的，并且对在数据重新排列期间执行的数据读取和写入操作是破坏性的。而且，数据对特定节点的亲和性(affinity)可能在数据集群上针对流行数据创建“热点”。此外，因为每个处理节点也执行存储功能，因此该架构需要至少一个处理节点来存储数据。因此，如果所有处理节点都被移除，则无共享架构无法存储数据。此外，由于数据在许多不同的处理节点当中的分布，在无共享架构中的数据管理是复杂的。

用于数据摄取的现有系统和方法使用可能使文件丢失的具有one/nothing语句的单个命令。例如，在现有系统中，文件摄取可能在表的摄取的中途失败，并使所有先前摄取的数据丢失。此外在传统的数据摄取中，用户可能被要求分配仓库并发出命令，并且数据更新可能不被捕获，直到用户发出特定命令为止。

本文描述的系统和方法提供数据存储、数据摄取和数据检索的改进的方法，其减轻现有系统的上面识别的限制。

附图简述

参考下面的附图描述本公开的非限制性且非详尽的实现，其中相似的参考数字在所有各个视图中指相似或类似的部分，除非另外规定。本公开的优点将关于下面的描述和随附的附图变得更好理解，其中：

图1是根据本公开的教导和原理的用于自动数据摄取的系统的框图架构模型；

图2是根据本公开的教导和原理的摄取数据的过程的框图；

图3是根据本公开的教导和原理的检索和数据存储系统的部件的框图；

图4是根据本公开的教导和原理的资源管理器的实施例的框图；

图5是根据本公开的教导和原理的执行平台的实施例的框图；

图6是示出根据本公开的教导和原理的操作环境的部件的框图；

图7是根据本公开的教导和原理的批量数据摄取系统的框图；

图8是根据本公开的教导和原理的用于将批量数据摄取到数据库的方法的示意性流程图；以及

图9是与启用在本文所教导的计算机过程一致的示例计算设备的框图。

详细描述

公开了用于将批量数据摄取到数据库或表的系统、方法和设备。在本领域中已知的传统数据库系统中，可以借助于复制命令将用户文件插入到数据库表中。这使被分配到数据摄取的运行仓库的使用成为必需，且数据摄取作为同步操作被执行。此外在这种传统方法中，当在数据摄取操作期间新数据被插入到表中时，用于查询或其他操作的数据库表的使用可被阻止。此外，对表做出的任何更新或从客户端账户接收的任何新数据将不由数据库捕获，直到用户再次手动地重新发出复制命令以插入新用户文件为止。当数据借助于单个命令(例如由用户手动地发起的复制命令)被摄取时，如果摄取任务失败，数据的一些或全部可能丢失。在本领域中已知的这种传统系统中，数据摄取操作可能在中途失败，且因此需要整个数据摄取操作被重复。

本文公开了用于将数据摄取到数据库中的改进的系统、方法和设备。这种改进的系统、方法和设备降低由于频繁的数据加载而引起的对数据库系统的负担，并简化用于针对客户端账户的用户的数据摄取的过程。在本文公开的系统、方法和设备中，来自用户文件的数据被增量地提交到数据库表的微分区(micro-partition)，使得已经摄取的数据甚至在系统故障的情况下也不丢失。数据可以被划分并逐个分区地插入到数据库中，使得在系统故障的情况下，摄取操作可以从当故障发生时的点继续。

此外，本文公开的系统、方法和设备的处理资源可以根据需要按比例增加或减少。因此，与本领域中已知的传统数据库摄取系统相比，仓库在如本文所公开的系统中是不需要的。本文公开的系统、方法和设备提供用户文件的异步和无服务器数据摄取。对客户端数据桶做出的改变(例如添加到客户端数据桶的一个或更多个新用户文件)被检测，并且这样的新文件被自动加载到适当的数据库表中而不需要来自客户端账户的用户的特定命令。此外，对于一个或更多个用户文件的数据的目标表被自动确定，并且这样的用户文件被分配到资源管理器的适当实例，其被分配来管理新数据到数据库的特定表中的摄取。

本文公开的系统、方法和设备还包括生成和维护涉及什么数据和什么用户文件被成功地提交到数据库的元数据。元数据还指示例如数据被插入到哪个微分区中和哪个表中，数据是否被成功地插入，数据何时被插入，插入的数据的大小，等等。这种元数据可以在执行平台当中以及在共同存储数据库的多个共享存储设备当中被共享。元数据可以与多个共享存储设备分开地被存储，或者它可以存储在多个共享存储设备中。此外，元数据可以作为单独的微分区存储在数据库表中，或者可以存储在包括数据库数据的微分区中。

在本公开的实施例中，公开了一种用于将数据增量地摄取到数据库中的系统。该系统包括用于确定指示从客户端账户接收的将被摄取到数据库中的用户文件的存在的通知的装置。该系统包括用于识别用户文件中的数据的装置和用于识别数据库的目标表以接收用户文件中的数据的装置。该系统包括用于生成指示数据和目标表的摄取任务的装置。该系统包括用于将摄取任务分配到执行平台的执行节点的装置，其中该执行平台包括独立于共同存储数据库数据的多个共享存储设备而操作的多个执行节点。该系统包括用于在数据由执行节点完全提交到目标表之后在元数据储备库(store)中登记涉及目标表的元数据的装置。

在本公开的实施例中，公开了一种用于将批量数据摄取到数据库中的方法。该方法包括确定指示从客户端账户接收的将被摄取到数据库中的用户文件的存在的通知。该方法包括识别用户文件中的数据和识别数据库的目标表以接收用户文件中的数据。该方法包括生成指示数据和目标表的摄取任务。该方法包括将摄取任务分配到执行平台的执行节点，其中执行平台包括独立于共同存储数据库数据的多个共享存储设备而操作的多个执行节点。该方法包括在数据由执行节点完全提交到目标表之后在元数据储备库中登记涉及目标表的元数据。在实施例中，该方法由数据库系统的资源管理器(例如见302)执行。

数据库表可以在多个微分区中存储数据，其中微分区是不可变存储设备。当事务在这样的表上被执行时，所有受影响的微分区被重新创建以生成反映事务的修改的新微分区。事务完全被执行后，重新创建的任何原始微分区然后可以从数据库移除。在表上执行的每个事务之后，表的新版本被生成。如果在表中的数据经历许多变化，例如插入、删除、更新和/或合并，则表可能在一段时间期间经历许多版本。表的每个版本可以包括指示什么事务生成了表、事务何时被排序、事务何时被完全执行以及事务如何改变表中的一行或更多行的元数据。用于低成本表版本控制的所公开的系统、方法和设备可以被运用来提供用于响应于对数据做出的修改而触发要在数据库数据上执行的任务的有效手段。

变化跟踪信息可以作为元数据存储在数据库中。该元数据描述存储在客户的数据库表中、但实际上不是所存储的表数据的数据。元数据可能变得非常大，尤其是如果有许多客户的大型数据库表。当前的数据库系统在处理大量元数据方面具有严重的限制。当前的数据库系统将元数据存储在可变存储设备和服务(包括主存储器、文件系统和键值储备库)中。这些设备和服务允许元数据就地更新数据。如果数据记录改变，它可能会用新信息被更新且旧信息被覆写。这允许数据库通过就地更新元数据来容易地维护可变元数据。

然而，这些可变存储设备和服务具有限制。限制是至少双重的。首先，可变存储设备(例如，主存储器和文件系统)在存储容量方面具有硬限制。如果元数据的大小超过这些限制，则将更多的元数据存储在那里是不可能的。其次，可变存储服务(例如，键值储备库)在读取大量元数据时表现拙劣。使用范围扫描来执行读取数据，这花费很长时间来完成。实际上，范围扫描可能在大规模部署中花费很多分钟或甚至接近一个小时来完成。

这些限制使在现有的可变存储设备和服务中存储大量元数据变得不可能。本文公开的系统、方法和设备提供了包括将元数据存储在不可变(非可变)存储装置(storage)(例如微分区)中的改进的元数据存储和管理。如本文所使用的，不可变或非可变存储装置包括数据不能或不被允许就地被覆写或更新的存储装置。例如，对位于存储介质的单元或区域中的数据的改变可以作为新文件存储在存储介质的不同的带时间戳的单元或区域中。可变存储装置可以包括数据被允许就地被覆写或更新的存储装置。例如，当存在对与存储介质的给定单元或区域相关的数据的变化时，在存储介质的那个给定单元或区域中的数据可以被覆写。

在一个实施例中，元数据在云中的非可变存储服务上被存储和维护。这些存储服务可以包括例如Amazon

Microsoft Azure Blob

和Google Cloud

这些服务中的许多不允许就地更新数据(即，是不可变或非可变的)。数据文件只可以被添加或删除，但从不被更新。在一个实施例中，在这些服务上存储和维护元数据要求对于在元数据中的每一个变化，元数据文件被添加到存储服务。这些元数据文件可以在后台周期性地合并成更大的“紧凑”或合并的元数据文件。

在实施例中，表中的所有数据被自动划分到被称为微分区的不可变存储设备中。微分区可以被考虑为批量单元，其中每个微分区具有连续的存储单元。作为例子，每个微分区可以包含在50MB和1000MB之间的未压缩数据(注意，在存储装置中的实际大小可以更小，因为数据可以被压缩地存储)。表中的行的组可以被映射到以分栏方式组织的单独微分区内。这个大小和结构允许可以由数百万或甚至数亿个微分区组成的非常大的表的极细粒度修剪(extremely granular pruning)。可以自动收集关于存储在微分区中的所有行的元数据，包括：对于在微分区中的列的每一个的值的范围；不同值的数量；和/或用于优化和有效的查询处理的附加属性。在一个实施例中，可以对所有表自动执行微分区。例如，可以使用当数据被插入/加载时出现的排序来透明地划分表。

在实施例中，文件元数据存储在元数据存储装置中。文件元数据包含表版本和关于每个表数据文件的信息。元数据存储装置可以包括可变存储装置(可以就地被覆写或写入的存储装置)，例如本地文件系统、系统、存储器或诸如此类。在一个实施例中，微分区元数据由两个数据集组成：表版本和文件信息。表版本数据集包括表版本到添加的文件和移除的文件的列表的映射。例如，文件信息由关于每个微分区的信息(包括微分区路径、微分区大小、微分区密钥id以及存储在微分区中的所有行和列的概要)组成。表的每次修改创建新的微分区和新的微分区元数据。对表内的插入创建新的微分区。从表中的删除移除微分区，且如果在微分区中的所有行未被删除则可能添加具有在表中的其余行的新微分区。更新移除微分区，并用具有包含所更新的记录的行的新微分区替换它们。

在一个实施例中，元数据(包括变化跟踪列)可以存储在不可变存储装置中的元数据微分区中。在一个实施例中，系统可以针对数据库表的每次修改而将元数据微分区写到云存储装置。在一个实施例中，系统可以下载和读取元数据微分区以计算扫描集。元数据微分区可以并行地被下载并在它们被接收时被读取以改进扫描集计算。在一个实施例中，系统可以周期性地在后台合并元数据微分区。在一个实施例中，可以包括性能改进，包括预取、缓存、分栏布局和诸如此类。此外，安全改进(包括加密和完整性检查)对具有分栏布局的元数据文件也是可能的。

数据库可以包括多个表，每个表还可以包括不可变存储设备，例如微分区。用户文件可以以不可变微分区的形式被增量地摄取到数据库表中，使得在用户文件中的数据不丢失。来自一个或更多个用户文件的数据可以在该用户文件被认为已被摄取到数据库中之前被摄取到在必须被完全且成功地提交到数据库表的数据的增量部分中。

数据库系统的客户端账户可以提供包含数据的一个或更多个用户文件。用户文件可以被提交到客户端账户队列，并且数据可以在用户文件中被识别。用户文件可以被分配到执行平台的执行节点，使得执行平台可以生成微分区或其他不可变存储设备以插入到包括用户文件中的数据的数据库的目标表中。

例如，这个新系统可以在没有客户或第三方仓库或服务器的情况下操作，并且可以简化客户端账户的数据传送。在实施例中，数据摄取增量地被完成，其中文件分批地被提交到数据库，使得系统故障不使数据丢失。在实施例中，系统检测对文件的变化并将变化自动加载到数据库中而不需要来自用户的特定命令。在实施例中，系统摄取成批数据并且在数据进栈(data pulling)和数据提交期间跟踪该过程，使得如果故障在数据摄取期间出现，系统可以在同一地方继续数据摄取。

本公开的实施例提供了一种用于数据摄取的系统，其具有优于现有系统的增加的灵活性。在实施例中，该系统包括多个计算资源和虚拟仓库，并且数据使用可用资源被自主增量地摄取。通过改变计算资源的使用和改变在系统上的工作负载来动态地适应计算能力。在实施例中，针对多个客户端账户提供公共资源池，并且计算核心的使用在所有客户端账户当中是完全动态和灵活的。

本公开的实施例提供了一种用于数据摄取的系统，其具有优于现有系统的增加的粒度。在实施例中，系统增量地输入和提交数据，并保护数据摄取免受潜在的网络故障影响。在实施例中，一次摄取一个用户文件或用户文件的一部分。在实施例中，一旦阈值数量的用户文件被接收到，用户文件就将被自动提交到数据库表。用户文件可以以不能被就地改变的不可变微分区的形式被提交到数据库表。在实施例中，数据库数据的状态(例如数据库表的内容)被存储在元数据中，使得系统可以精确地恢复什么用户文件被摄取以及在哪个位置被摄取。

在本公开的下面的描述中，参考形成本公开的一部分的随附的附图，并且其中通过例证示出本公开在其中可被实践的特定实现。应理解，其他实现可以被利用并且结构变化可被做出而不偏离本公开的范围。

在描述和主张本公开时，将根据下面陈述的定义使用下面的术语。

必须注意，如在这个说明书和所附权利要求中使用的，单数形式“一个(a)”、“一个(an)”和“该(the)”包括复数所指对象，除非上下文另外明确地规定。

在整个这个说明书中对“一个实施例”、“实施例”、“一个实现”、“实现”、“一个例子”或“例子”的提及意味着关于实施例、实现或例子所描述的特定的特征、结构或特性被包括在本公开的至少一个实施例中。因此，上面识别的短语在整个这个说明书中的各种地方中的出现并不一定都指同一实施例、实现或例子。此外应当认识到，对于本领域中的普通技术人员来说，与此一起提供的附图是为了解释目的。

如在本文使用的，术语“包括(comprising)”、“包括(including)”、“包含(containing)”及其语法等同物是包括界限的或开放式的术语，其不排除额外的、未列举的元件或方法步骤。

如在本文使用的，“表”被定义为记录(行)的集合。每条记录包含表属性(列)的值的集合。表通常物理地存储在多个较小(变化的大小或固定大小)的存储单元(例如文件或块)中。

根据本公开的实施例可以被体现为装置、方法或计算机程序产品。因此，本公开可以采取完全由硬件组成的实施例、完全由软件组成的实施例(包括固件、常驻软件、微代码等)或组合软件方面和硬件方面的实施例的形式，这些实施例在本文中通常都可以被称为“电路”、“模块”或“系统”。此外，本公开的实施例可采取体现在具有在介质中体现的计算机可用程序代码的表达的任何有形介质中的计算机程序产品的形式。

可利用一个或更多个计算机可用或计算机可读介质的任何组合。例如，计算机可读介质可包括便携式计算机磁盘、硬盘、随机存取存储器(RAM)设备、只读存储器(ROM)设备、可擦除可编程只读存储器(EPROM或快闪存储器)设备、便携式光盘只读存储器(CDROM)、光存储设备和磁存储设备中的一个或更多个。可以用一种或更多种编程语言的任何组合来写用于执行本公开的操作的计算机程序代码。这种代码可以从源代码被编译为适合于设备或计算机的计算机可读汇编语言或机器代码，代码将在设备或计算机上被执行。

还可在云计算环境中实现实施例。在本描述和下面的权利要求中，“云计算”被定义为用于实现对可配置计算资源(例如，网络、服务器、存储设备、应用和服务)的共享池的普遍存在的、方便的、按需(on-demand)网络访问的模型，可配置计算资源可经由虚拟化迅速地被供应并以最小管理努力或服务提供商交互作用被释放，且然后相应地被按比例缩放。云模型可以由各种特征(例如，按需自助服务、广泛的网络接入、资源池、快速灵活性和所测量的服务)、服务模型(例如，软件即服务(“SaaS”)、平台即服务(“PaaS”)和“基础设施即服务”(“IaaS”))以及部署模型(例如，私有云、社区云、公共云和混合云)组成。

附图中的流程图和框图示出了根据本公开的各种实施例的系统、方法和计算机程序产品的可能实现的架构、功能和操作。在这点上，在流程图或框图中的每个块可代表包括用于实现指定的逻辑功能的一个或更多个可执行指令的代码的模块、段或部分。也将注意，框图和/或流程图的每个块以及在框图和/或流程图中的块的组合可由执行指定功能或行动的专用的基于硬件的系统或专用硬件和计算机指令的组合实现。这些计算机程序指令还可存储在可指示计算机或其他可编程数据处理装置以特定方式起作用的计算机可读介质中，使得存储在计算机可读介质中的指令产生包括实现在流程图和/或框图的一个或更多个块中指定的功能/行动的指令手段的制造物品。

本文描述的系统和方法使用新的数据处理平台来提供灵活且可扩充的数据仓库。在一些实施例中，所描述的系统和方法运用支持基于云的存储资源、计算资源和诸如此类的云基础设施。示例性的基于云的存储资源以低成本提供按需可得的相当大的存储容量。此外，这些基于云的存储资源可以是容错的和高度可扩充的，这在私有数据存储系统中实现起来可能是昂贵的。示例性的基于云的计算资源可以是按需可得的，并且可以基于资源的实际使用水平被定价。通常，云基础设施以快速方式被动态地部署、重新配置和退出运行。

在所描述的系统和方法中，数据存储系统利用基于SQL(结构化查询语言)的关系数据库。然而，使用任何数据存储架构并使用任何语言以在数据存储和检索平台内存储和检索数据，这些系统和方法可应用于任何类型的数据库和任何类型的数据存储和检索平台。本文描述的系统和方法进一步提供了支持在不同客户/客户端之间以及在同一客户/客户端内的不同用户之间的计算资源和数据的隔离的多租户系统。

在本公开的实施例中，描述了用于批量数据摄取服务的系统、方法和设备。批量数据摄取服务可以减轻由频繁的数据加载引起的在数据存储供应商上的负担。该服务可以进一步使数据存储客户端通过数据存储供应商加载数据变得更方便。

在本公开的实施例中，批量数据摄取服务是具有特定语言包装应用程序接口(API)的表述性状态转移(REST)服务。该服务的一个实施例是异步的，使得数据到文件内的加载出现在文件被提交用于加载之后的稍后时间。该服务的一个实施例是持久的，使得文件名在REST调用返回之前被提交到持久存储装置。该服务的一个实施例为客户端提供了在不写入SQL命令的情况下插入数据的能力，并且避免了将数据发布和复制到数据库中的多步骤过程。

现在参考附图，图1是用于批量数据摄取和用于通过数据流水线系统将数据库数据存储在一个或更多个表中的系统100的示意性框图。图1不是数据流或控制流的表示。系统100包括可以与数据库系统通信的客户端账户102。这种客户端账户102可以提供将被提交到数据库的新数据或更新数据。系统100包括REST(表述性状态转移)层104，其包括对象解析106和请求路由108的系统。系统100包括API(应用程序接口)网关110，其包括速率限制112和认证114的系统。系统100包括令牌管理116的协议。该系统包括与REST层104通信的核心引擎120。核心引擎120包括负责队列管理122、任务执行124、仓库管理126、文件管理128和加载历史130的系统或协议。核心引擎120与被配置为执行一个或更多个任务(例如数据摄取任务)的执行平台132通信。

客户端账户102直接或间接地与数据库系统的资源管理器(见例如204、302)通信。REST层104可以是资源管理器302的部件。客户端账户102提供要被摄取到数据库中的用户文件。用户文件可以被上传到供应商服务，例如Amazon Web Services^TM或其他合适的云计算服务。资源管理器302可以接收应该被摄取到数据库内的用户文件被添加到客户端账户或者在数据库中的一些数据应该被更新的通知。在各种实现中，资源管理器302可以自动接收这样的通知，或者它可以周期性地轮询与客户端账户102相关联的数据桶以确定任何用户文件是否被添加。

REST层104包括能够处理到内部格式的有效载荷转换的薄外层，并且还能够处理简单验证。在实施例中，REST层104存在于资源管理器(见例如204、302)内部。REST层104包括负责从被确定范围的表名称(scoped table name)转变到表标识(在本文可以被称为TableID)的对象解析106。REST层104还包括负责将对从客户端账户102接收的用户文件的目标表的请求路由到资源管理器302的适当实例的请求路由108。在实施例中，请求路由108发生在对象解析106之后。请求路由108可以使用与虚拟节点的一致性散列来管理哪个GS实例拥有哪个表。

在实施例中，当供应商账户(例如负责接收用户文件的第三方账户)接收到用户文件的一个或更多个名称时，对象解析106的协议将用户文件的那些名称解析为内部名称。用户文件的内部名称被缓存。

在实施例中，资源管理器302的REST层104的请求路由108的协议被配置成从客户端账户102接收用户文件，并将那些用户文件路由到执行平台的一个或更多个执行节点用于摄取和处理。在实施例中，供应商账户(即，负责直接或间接地从客户端账户102接收用户文件并将那些用户文件提供到例如资源管理器302的第三方账户)可以使用与虚拟节点的一致性散列来管理哪个资源管理器302拥有特定的数据库表。供应商账户可以在表标识和对特定资源管理器302的标识上进行散列以找到在用户文件和资源管理器302之间的匹配。散列空间被分成大小相等的分区。给定多个资源管理器302的实例，每个资源管理器302采用多个分区。当资源管理器302将执行节点添加到执行平台(例如核心引擎120)时，资源管理器302将从每个执行节点提取(pull)随机分区以保持分区配给量的比率。类似地，当执行节点失效时，分区的配给量分散在剩余的执行节点当中。这个映射可以由供应商账户维护。

在实施例中，每当虚拟节点分配被改变时，包括所有虚拟节点映射的数据库记录被事务性地修改。与虚拟节点相关联的值将与正在处理对数据库的给定表的请求的对象一起存储在存储器中。该值可以随着在资源管理器302和执行平台132之间的每次交互作用而来回传递。该值可用于检测陈旧状态或可能被丢弃的请求。

在实施例中，在恢复情况期间使用tableList切片以与供应商账户通信。tableList切片可以指示什么数据库表由给定虚拟节点管理。当表的供应商账户通知已被删除或不再是活动的时，tableList切片可以根据需要被添加或修正，并尽最大努力被清理。

在实施例中，整个虚拟节点表可以被缓存在每个资源管理器302上的存储器中。每个资源管理器302可以监视对数据库表的变化，并周期性地轮询数据库表作为备份措施。在实施例中，当摄取新用户文件的请求必须由请求路由108的协议路由时，供应商账户可以tableId进行散列并确定包含散列的虚拟节点，且然后供应商账户可以在表中查找虚拟节点并路由到特定资源管理器302。

API网关110包括薄层以保护对核心引擎120的访问。API网关110包括负责基本限制的速率限制112以防止数据摄取请求的大量流入。API网关110包括负责验证在REST请求中传递的API令牌的认证114。

在实施例中，认证114的协议包括一组缩小范围(down-scoped)的证书。缩小范围的证书可用于创建范围被确定到特定表的API令牌。令牌可以使TableID被烘焙到它(bakedinto it)中，且根据计划(progammatically)被创建。令牌可以具有短寿命(在实施例中，令牌可以在30分钟、1小时、2小时、3小时等内到期)。在实施例中，客户端账户102可以指示令牌的到期和/或根据计划接收新令牌。在实施例中，系统100接收令牌，验证令牌，并验证在令牌中指定的TableID是否与在REST请求中指定的表的名称匹配。在TableID和REST请求中指定的表不匹配的实现中，调用者将接收到特定错误响应，其将请求新令牌。在实施例中，系统100在每次表被修改时需要新的令牌。

令牌管理116负责生成新的令牌且根据需要撤销先前的令牌。核心引擎120是管理输入数据的处理的核心逻辑。核心引擎120包括负责管理输入文件的队列(包括将文件添加到队列或从队列移除文件)的队列管理122。任务执行器124开始并管理用于加载文件的执行平台作业，包括与编译器的交互作用。仓库管理126管理加载仓库，包括根据需要按比例扩大和缩小。文件管理128负责处理注册本地二进制文件的摄取版本和捕获错误。加载历史130跟踪对于给定表的加载和错误的历史。加载历史130可以在一段时间之后或者在条目的最大数量被达到之后进一步清除加载历史。

在实施例中，任务执行器124知道活动任务的当前总数和活动任务的期望数量。任务执行器124向资源管理器302传递活动任务的期望数量，其努力将仓库的大小保持在活动任务的期望数量处。资源管理器302可以通过借助于在某个时间段内的移动平均使需求随着时间的过去而平稳来实现这一点，该时间段是期望时延的一部分。资源管理器302可以进一步通过保持仓库的大小略大于适应临时尖峰的实际需要来实现这一点。资源管理器302可以进一步通过谨慎地释放执行节点和/或将工作分配到一个或更多个执行节点以便压缩使用以在需要时允许执行节点的合理释放来实现这一点。

在实施例中，任务执行器124生成摄取任务的执行计划。执行计划可以类似于复制命令的计划。任务执行器124可以在包括对当前复制命令的内部布尔选项“ingest_mode”的复制选项中创建代码更改。执行计划可以从SQL文本“copy into T ingest_mode＝true”编译以禁用某些功能。任务执行器124还可以包括在扫描集中的代码更改，包括如果副本在摄取模式中则可以为真的布尔属性“dynamic_scanset”。

在实施例中，仓库管理126为数据摄取管理仓库。仓库管理126可以基于需求来控制按比例扩大和缩小，将工作分配到执行节点，跟踪在仓库上的任务的状态以允许正确的分配，并跟踪出故障的服务器并相应地做出响应。在实施例中，仓库管理126被合并在资源管理器302中。应该注意，因为摄取任务是单线程的，所以在一个仓库节点上每核心被分配一个任务。对于每个仓库节点，跟踪正在运行的任务的数量。任务执行器124可以调度新任务，请求服务器要使用的仓库管理126，以及仓库管理126将选择已经忙碌的服务器以使在负载降低时释放执行节点变得更容易。任务执行器124必须通知仓库管理128关于任务完成的情况。

在实施例中，加载历史130监控加载结果，并记录文件或数据是否被成功地摄取到数据库中。摄取历史还可以存储在数据库内的元数据储备库中，或者与数据库分离并且由资源管理器302可访问。摄取历史包括例如文件名、TableID、文件大小、行计数、状态和第一个错误。在实施例中，数据加载的错误管理将是单独的项目。

图2是将数据摄取到数据库内的过程200的示意性框图。过程200开始，并且客户端账户102在202处发送摄取请求。客户端账户102可以直接或间接地与数据库系统通信以在摄取请求中发送。在实施例中，摄取请求是由第三方供应商存储账户提供的通知，或者摄取请求可以从资源管理器302产生，资源管理器302轮询与客户端账户102相关联的数据湖，以确定还没有被摄取到数据库中的任何用户文件是否被添加到客户端账户102。通知包括要插入到数据库表中的用户文件的列表。用户文件保留在数据库的接收表特有的队列中。

摄取请求由资源管理器204(也见302)接收。资源管理器204在206处识别要摄取的用户文件，在208处将用户文件分配到一个或更多个执行节点，并且在用户文件被摄取到数据库表的微分区内之后在210处登记与数据库表相关联的微分区元数据。资源管理器204提供执行平台212的一个或更多个执行节点214、218以执行与摄取用户文件相关联的一个或更多个任务。这种摄取任务216a、216b、220a、220b包括例如将用户文件切割成一个或更多个分区，基于用户文件来生成新的微分区，和/或将新的微分区插入到数据库的表中。

系统200开始将在仓库上运行的IngestTask。IngestTask将从数据库表的队列提取用户文件，直到它被告知停止这样做为止。IngestTask将周期性地切割新的用户文件，并将它添加到数据库表。在一个实施例中，摄取过程是“无服务器的”，因为它是由数据库或资源管理器204提供的集成服务。也就是说，与客户端账户102相关联的用户不需要供应它自己的仓库或第三方仓库，以便执行摄取过程。例如，该数据库或所提供的数据库(例如，通过资源管理器204的实例)可以维护摄取仓库，其然后服务于数据库提供商的一个或更多个或所有账户/客户。

应该认识到，对于给定的表，可以有从队列提取的多于一个IngestTask，且这对跟上输入数据的速率可能是必要的。在实施例中，IngestTask可以决定切割新文件的时间以增加获得理想大小的文件的机会，并避免如果文件大小与一个或更多个用户文件对齐将导致的“奇怪大小的(odd sized)”文件。这可能以增加的复杂性为代价出现，因为所消耗的文件的跟踪行号必须被跟踪。

在实施例中，对特定表的所有请求将被路由到资源管理器204的单个实例。资源管理器204的每个实例可以负责一组数据库表。在实施例中，这通过使用与虚拟节点的一致性散列来实现，该一致性散列允许将节点视为队列的直写式高速缓存，消除了从元数据储备库读取队列中的项目的需要。

现在参考图3，示出了用于运行本文公开的方法的数据处理平台300。如图3所示，资源管理器302可以耦合到多个客户端账户314a、314b和314n。在特定的实现中，资源管理器302可以支持期望访问执行平台304和/或共享数据库存储设备308的任何数量的客户端账户。客户端账户314a、314b和314n可以包括例如提供要被摄取到数据库中的用户文件的最终用户、数据存储和检索请求、管理本文描述的系统和方法的系统管理员以及与资源管理器302交互作用的其他部件/设备。

资源管理器302可以提供支持在处理平台300内的所有系统和部件的操作的各种服务和功能。资源管理器302可以耦合到与在整个数据处理平台300中存储的全部数据相关联的共享元数据312。在一些实施例中，共享元数据312可以包括存储在远程数据存储系统中的数据以及从本地高速缓存可得到的数据的概要。另外，共享元数据312可以包括关于数据如何在远程数据存储系统和本地高速缓存中被组织的信息。共享元数据312可以允许系统和服务确定一条数据是否需要在不从存储设备加载或访问实际数据的情况下被处理。

资源管理器302可以进一步耦合到提供执行各种数据存储和数据检索任务的多个计算资源的执行平台304，如下面更详细讨论的。执行平台304包括多个执行节点306a、306b、306c和306n，其被配置为处理与数据库相关联的各种任务，包括摄取新用户文件和基于新用户文件来为数据库的表生成一个或更多个微分区。执行平台304可以耦合到包括多个数据存储设备310a、310b、310c和310n的共享数据库存储设备308。在一些实施例中，共享数据库存储设备308包括位于一个或更多个地理位置上的基于云的存储设备。例如，共享数据库存储设备308可以是公共云基础设施或私有云基础设施的一部分。共享数据库存储设备308可以包括硬盘驱动器(HDD)、固态驱动器(SSD)、存储集群或任何其它数据存储技术。另外，共享数据库存储设备308可以包括分布式文件系统(例如Hadoop分布式文件系统(HDFS))、对象存储系统和诸如此类。应当认识到，共享数据库存储设备308可以被资源管理器302的一个或更多个实例访问，但可以不被所有客户端账户314a-314n访问。在实施例中，资源管理器302的单个实例由多个客户端账户314a-314n共享。在实施例中，每个客户端账户314a-314n具有在执行平台304的多个执行节点306a-306n当中共享的它自己的资源管理器和/或它自己的共享数据库存储设备308。在实施例中，资源管理器302负责向特定客户端账户314a-314n提供对在共享数据库存储设备308内的特定数据的访问。

在特定实施例中，在资源管理器302与客户端账户314a-314n、共享元数据312和执行平台304之间的通信链路经由一个或更多个数据通信网络来实现。类似地，在执行平台304与共享数据库存储设备308之间的通信链路经由一个或更多个数据通信网络来实现。这些数据通信网络可以利用任何通信协议和任何类型的通信介质。在一些实施例中，数据通信网络是耦合到彼此的两个或更多个数据通信网络(或子网络)的组合。在替代实施例中，这些通信链路使用任何类型的通信介质和任何通信协议来实现。

如图3所示，数据存储设备310a-310n从与执行平台304相关联的计算资源去耦。这个架构基于变化的数据存储/检索需要以及访问数据处理平台300的用户和系统的变化的需要来支持对数据处理平台300的动态变化。动态变化的支持允许数据处理平台300响应于对在数据处理平台300内的系统和部件的变化的需求而快速按比例缩放。计算资源从数据存储设备的去耦支持大量数据的存储而不需要相应的大量计算资源。类似地，资源的这个去耦支持在特定时间利用的计算资源的显著增加而不需要可用的数据存储资源的相应增加。

资源管理器302、共享元数据312、执行平台304和共享数据库存储设备308在图3中示为单独的部件。然而，资源管理器302、共享元数据312、执行平台304和共享数据库存储设备308中的每一个可以被实现为分布式系统(例如，分布在多个地理位置处的多个系统/平台当中)。此外，资源管理器302、共享元数据312、执行平台304和共享数据库存储设备308中的每一个可以根据对从客户端账户314a-314n接收的请求的变化和数据处理平台300的变化的需要而(彼此独立地)被按比例放大或缩小。因此，数据处理平台300是动态的，并且支持有规律变化以满足当前的数据处理需要。

图4是描绘资源管理器302的实施例的框图。如图4所示，资源管理器302包括耦合到数据存储设备406的访问管理器402和密钥管理器404。访问管理器402可以处理对于本文所描述的系统的认证和授权任务。密钥管理器404可以管理在认证和授权任务期间使用的密钥的存储和认证。请求处理服务408管理接收到的数据存储请求和数据检索请求。管理控制台服务410支持由管理员和其他系统管理器对各种系统和过程的访问。

资源管理器302还可以包括作业编译器412、作业优化器414和作业执行器416。作业编译器412解析任务(例如摄取任务)并生成用于用户文件的摄取的执行代码。作业优化器414基于需要被处理和/或摄取的数据来确定执行摄取任务的最佳方法。作业执行器416执行由资源管理器302接收的摄取任务的代码。作业调度器和协调器418将接收到的用户文件发送到适当的服务或系统用于编译、优化和对执行平台304的分派。虚拟仓库管理器420管理在执行平台中实现的多个虚拟仓库的操作。

此外，资源管理器302包括配置和元数据管理器422，其管理与存储在远程数据存储设备中和本地高速缓存中的数据相关的信息。监控器和工作负载分析器424监督由资源管理器302执行的过程，并管理任务(例如，工作负载)在执行平台中的执行节点和虚拟仓库当中的分配。配置和元数据管理器422以及监控器和工作负载分析器424耦合到数据存储设备426。

图5是描绘执行平台304的实施例的框图。如图5所示，执行平台304包括多个虚拟仓库，其包括虚拟仓库1、虚拟仓库2和虚拟仓库n。每个虚拟仓库包括多个执行节点，每个执行节点包括数据高速缓存和处理器。虚拟仓库可以通过使用多个执行节点来并行地执行多个任务。如本文所讨论的，执行平台304可以基于系统和用户的当前处理需要来实时地添加新的虚拟仓库和丢掉现有的虚拟仓库。这个灵活性允许执行平台304在需要时快速部署大量计算资源而不在那些计算资源不再被需要时被迫继续为它们付费。所有虚拟仓库可以从任何数据存储设备(例如，在共享数据库存储设备308中的任何存储设备)访问数据。尽管图5所示的每个虚拟仓库包括三个执行节点，但特定的虚拟仓库可以包括任何数量的执行节点。此外，在虚拟仓库中的执行节点的数量是动态的，使得当额外的需求存在时新的执行节点被创建，并且当现有执行节点不再是必要的时删除它们。

每个虚拟仓库能够访问图3所示的数据存储设备310a-310n中的任一个。因此，虚拟仓库不一定被分配到特定的数据存储设备，且替代地可以从在共享数据库存储设备308内的数据存储设备310a-310n中的任一个访问数据。类似地，图5所示的执行节点中的每一个可以从数据存储设备310a-310n中的任一个访问数据。在一些实施例中，特定的虚拟仓库或特定的执行节点可以临时被分配到特定的数据存储设备，但虚拟仓库或执行节点可以稍后从任何其他数据存储设备访问数据。

在图5的例子中，虚拟仓库1包括三个执行节点502a、502b和502n。执行节点502a包括高速缓存504b和处理器506a。执行节点502b包括高速缓存504b和处理器506b。执行节点502n包括高速缓存504n和处理器506n。每个执行节点502a、502b和502n与处理一个或更多个数据存储和/或数据检索任务相关联。例如，虚拟仓库可以处理与内部服务(例如群集服务、物化视图刷新服务、文件压缩服务、存储过程服务或文件升级服务)相关联的数据存储和数据检索任务。在其他实现中，特定虚拟仓库可以处理与特定数据存储系统或特定类别的数据相关联的数据存储和数据检索任务。

类似于上面讨论的虚拟仓库1，虚拟仓库2包括三个执行节点512a、512b和512n。执行节点512a包括高速缓存514a和处理器516a。执行节点512b包括高速缓存514b和处理器516b。执行节点512n包括高速缓存514n和处理器516n。另外，虚拟仓库3包括三个执行节点522a、522b和522n。执行节点522a包括高速缓存524a和处理器526a。执行节点522b包括高速缓存524b和处理器526b。执行节点522n包括高速缓存524n和处理器526n。

在一些实施例中，图5所示的执行节点相对于执行节点正在缓存的数据是无状态的。例如，这些执行节点不存储或以其他方式维护关于执行节点或由特定执行节点正缓存的数据的状态信息。因此，在执行节点故障的情况下，出故障的节点可以由另一个节点透明地替换。因为没有与出故障的执行节点相关联的状态信息，所以新的(替换)执行节点可以容易替换出故障的节点而没有对重新创建特定状态的关注。

尽管图5所示的执行节点每个都包括一个数据高速缓存和一个处理器，但替代实施例可以包括包含任何数量的处理器和任何数量的高速缓存的执行节点。此外，高速缓存在不同的执行节点当中可能在大小上不同。图5所示的高速缓存在本地执行节点中存储从在共享数据库存储设备308中的一个或更多个数据存储设备被检索的数据。因此，高速缓存减少或消除了在从远程存储系统一致地检索数据的平台中出现的瓶颈问题。不是重复地从远程存储设备访问数据，本文描述的系统和方法从执行节点中的高速缓存访问数据，这明显更快并且避免了上面讨论的瓶颈问题。在一些实施例中，使用提供对所缓存的数据的快速访问的高速存储器设备来实现高速缓存。每个高速缓存可以将来自任何存储设备的数据存储在共享数据库存储设备308中。

此外，缓存资源和计算资源可以在不同的执行节点之间变化。例如，一个执行节点可以包含相当数量的计算资源和最少的缓存资源，使该执行节点对于需要相当数量的计算资源的任务变得有用。另一个执行节点可能包含相当数量的缓存资源和最少的计算资源，使该执行节点对于需要大量数据的缓存的任务变得有用。又一个执行节点可以包含提供对于需要大量数据的快速扫描的任务有用的更快的输入输出操作的缓存资源。在一些实施例中，基于要由执行节点执行的预期任务，在执行节点被创建时确定与特定执行节点相关联的缓存资源和计算资源。

此外，与特定执行节点相关联的缓存资源和计算资源可以基于由执行节点执行的变化的任务随着时间的过去而变化。例如，如果由执行节点执行的任务变成更处理器密集的，则执行节点可以被分配更多的处理资源。类似地，如果由执行节点执行的任务需要更大的缓存容量，则执行节点可以被分配更多的缓存资源。

尽管虚拟仓库1、2和n与同一执行平台304相关联，但虚拟仓库可以使用在多个地理位置处的多个计算系统来实现。例如，虚拟仓库1可以由在第一地理位置处的计算系统实现，而虚拟仓库2和n由在第二地理位置处的另一计算系统实现。在一些实施例中，这些不同的计算系统是由一个或更多个不同的实体维护的基于云的计算系统。

另外，每个虚拟仓库在图5中被示为具有多个执行节点。可以使用在多个地理位置处的多个计算系统来实现与每个虚拟仓库相关联的多个执行节点。例如，虚拟仓库1的实例在一个地理位置处的一个计算平台上实现执行节点502a和502b，并且在另一个地理位置处的不同计算平台处实现执行节点502n。选择特定计算系统来实现执行节点可以取决于各种因素，例如特定执行节点所需的资源的水平(例如，处理资源要求和高速缓存要求)、在特定计算系统处可用的资源、在地理位置内或在地理位置之间的网络的通信能力以及哪些计算系统已经在虚拟仓库中实现其他执行节点。

执行平台304也是容错的。例如，如果一个虚拟仓库出故障，该虚拟仓库将快速地用在不同地理位置处的不同虚拟仓库代替。

特定执行平台304可以包括任何数量的虚拟仓库。此外，在特定执行平台中的虚拟仓库的数量是动态的，使得当额外的处理和/或缓存资源被需要时，新的虚拟仓库被创建。类似地，当与虚拟仓库相关联的资源不再是必要的时，现有的虚拟仓库可以被删除。

在一些实施例中，虚拟仓库可以对在共享数据库存储设备308中的相同数据进行操作，但每个虚拟仓库具有它自己的具有独立的处理和缓存资源的执行节点。这个配置允许在不同虚拟仓库上的请求独立地并且在没有在请求之间的干扰的情况下被处理。与动态地添加和移除虚拟仓库的能力组合的这个独立处理支持为新用户添加新的处理能力而不影响由现有用户观察到的性能。

图6是描绘具有在虚拟仓库管理器502下与多个虚拟仓库通信的队列602的示例操作环境600的框图。在环境600中，队列602可以通过多个虚拟仓库606a、606b和606n访问多个数据库共享存储设备608a、608b、608c、608d、608e和608n。尽管在图6中未示出，队列602可以通过资源管理器302访问虚拟仓库。在特定实施例中，数据库608a-608n被包含在共享数据库存储设备308中，并且由在执行平台212中实现的任何虚拟仓库可访问。在一些实施例中，队列602可以使用数据通信网络(例如互联网)来访问虚拟仓库606a-606n之一。在一些实现中，客户端账户可以指定队列602(被配置为存储要完成的内部作业)应该在特定时间与特定虚拟仓库606a-606n交互作用。

在(如所示)实施例中，每个虚拟仓库606a-606n可以与所有数据库608a-608n通信。在一些实施例中，每个虚拟仓库606a-606n被配置成与所有数据库608a-608n的子集通信。在这样的布置中，与一组数据相关联的单独客户端账户可以通过单个虚拟仓库和/或向数据库608a-608n的某个子集发送所有数据检索和数据存储请求。此外，在某个虚拟仓库606a-606n被配置为与数据库608a-608n的特定子集通信的情况下，该配置是动态的。例如，虚拟仓库606a可以被配置成与数据库608a-608n的第一子集通信，并且可以稍后被重新配置成与数据库608a-608n的第二子集通信。

在实施例中，队列602向虚拟仓库管理器604发送数据检索、数据存储和数据处理请求，虚拟仓库管理器604将请求路由到适当的虚拟仓库606a-606n。在一些实现中，虚拟仓库管理器604向虚拟仓库606a-606n提供作业的动态分配。

在一些实施例中，容错系统响应于虚拟仓库的故障而创建新的虚拟仓库。新的虚拟仓库可以在同一虚拟仓库组中，或者可以在不同地理位置处的不同虚拟仓库组中被创建。

本文描述的系统和方法允许数据作为从计算(或处理)资源分离的服务来被存储和访问。即使没有计算资源从执行平台212被分配，数据对虚拟仓库也是可用的而不需要数据从远程数据源的重新加载。因此，数据是独立于与数据相关联的计算资源的分配而可用的。所描述的系统和方法对于任何类型的数据是有用的。在特定实施例中，数据以结构化的优化格式被存储。数据存储/访问服务与计算服务的去耦也简化了在不同用户和组当中的数据的共享。如在本文所讨论的，每个虚拟仓库可以访问它具有访问权限的任何数据，甚至在与其他虚拟仓库正在访问相同数据时相同的时间进行访问。这个架构支持运行查询而没有在本地高速缓存中存储的任何实际数据。本文描述的系统和方法能够有透明的动态数据移动，其根据需要以对系统的用户透明的方式将数据从远程存储设备移动到本地高速缓存。此外，这个架构支持数据共享而没有预先数据移动，因为任何虚拟仓库可以由于数据存储服务从计算服务的去耦而访问任何数据。

图7是用于自动数据摄取的系统700的框图架构模型。系统700包括多个客户端账户，其包括例如客户端账户A和客户端账户B。客户端账户可以包括包含用户文件的一个或更多个数据桶或数据湖。客户端账户中的每一个耦合到包括要被摄取到数据库中的所有用户文件的列表的一个客户端账户队列。如图7所示，客户端账户A耦合到账户A的队列704，客户端账户B耦合到账户B的队列708。在替代实施例中，多个客户端账户可以被馈送到一个或更多个客户端账户队列。摄取轮询器706、710与客户端账户中的每一个相关联。在实施例中，摄取轮询器706、710可以轮询一个或更多个客户端账户的队列。如图7所示，摄取轮询器706负责轮询账户A的队列704，以及摄取轮询器710负责轮询账户B的队列708。每个摄取轮询器可以在多个客户端账户队列当中轮询。摄取轮询器706、710可以检查从客户端账户队列接收的通知，并对照所有可用管线712、714、716、718、720、722、724和726使该通知匹配。摄取轮询器706、710负责向匹配管线712-726中的每一个递送通知，使得相关联的用户文件可以从客户端账户被检索并递送到适当的管线。客户端账户队列和相关联的摄取轮询器体现在通知通道702中。

在实施例中，摄取轮询器706、710进行轮询或被轮询操作。在实施例中，摄取轮询器706、710是存在于资源管理器302中的一项功能。摄取轮询器706、710可以检查来自客户端账户队列704、708的每个通知，并且对于每个消息，摄取轮询器706、710将对照每个管线712-726使该通知匹配。摄取轮询器706、710将向匹配管线712-726中的每一个递送通知。

在实施例中，系统700包括多个客户端账户队列，其包括Simple Queue Service^TM(SQS)队列的池作为Amazon Web Service^TM S3桶的一部分。可以将SQS队列的池提供到客户端账户以将用户文件添加到桶。当一个或更多个用户文件被添加到客户端账户数据桶时，通知可以自动生成。可以向每个客户端账户提供多个客户数据桶。客户端账户队列704、708可以处理来自客户端账户的多个数据桶的数据事件(即，一个或更多个用户文件的接收)。客户端账户可以包括将具有用于该客户端账户的一个或更多个专用客户端账户队列704、708的多个数据桶。在实施例中，每个客户端账户队列704、708处理来自对于单个客户端账户的多个数据桶的事件，该多个数据桶将针对多个管线712-726接收用户文件。在实施例中，每个摄取轮询器706、710在多个客户端账户队列704、708当中轮询，并且不专用于单个客户端账户队列704、708，如图7所示。

在实施例中，管线712-726的创建发生在外部阶段或内部阶段中的任一个处。如果两个管线用相同的匹配条件被创建，则可适用的用户文件将被加载到这两个管线中。在实施例中，当客户端丢掉管线712-726时，如果存在从同一客户端数据桶自动摄取的其他管线，则将没有输出。如果被丢掉的管线712-726是为客户端数据桶自动摄取的最后一个管线，则队列配置将从桶通知配置被移除。

在实施例中，在客户端账户队列上存在策略限制，使得客户端账户队列将需要被配置有接受来自客户端数据桶的消息的策略。在实施例中，为了使客户端数据桶能够向客户端账户队列发送创建事件，下列项之一必须为真：客户端数据桶应该被允许来自主体(principal)，或者客户端数据桶源必须在条件中被允许。如果客户端数据桶被允许来自主体，则来自该客户端账户的所有实体将能够在客户端账户队列上发送消息。因此，为了仅限制客户端数据桶发送通知，可以将条件设置为指向客户端数据桶名称。

在实施例中，对于单个客户端账户，存在多个客户端账户队列。这在实施例中可能是有益的，在该实施例中，对于所有可能的客户端账户具有单个客户端账户队列将需要该单个客户端账户队列在许多客户端数据桶当中共享，并且该单个客户端账户队列可能不能够处理大量的客户端数据桶。

在实施例中，系统700为每个客户端账户维护客户端账户队列的池。每个客户端账户队列可以服务于多个阶段和管线712-726。资源管理器302的每个实例将为一个或更多个客户端账户队列构建令牌环并将监视分配到可适用的客户端账户队列的令牌的那个范围，并将进一步轮询那些客户端账户队列。

在实施例中，每当管线712-726被配置为自动摄取时，摄取请求被重定向到当前正在处理用户文件的供应的资源管理器302的实例。一旦资源管理器302的正确实例接收到摄取请求，它就可以从高速缓存中读取它拥有的所有客户端账户队列。资源管理器302的实例可以进一步检查客户端账户队列之一是否已经具有对于可适用的客户端数据桶的现有摄取策略。如果具有，则它可以在元数据储备库中增加对那个客户端账户队列的引用，并返回那个客户端账户队列。资源管理器302的实例可以进一步确定是否没有客户端账户队列具有现有策略，并且实现客户端账户队列选择策略以选择现有客户端账户队列或者创建新客户端账户队列。这可以包括向客户端账户队列添加策略，以在某些情况下为那个客户端账户提供新的客户端账户队列。它还可以在元数据储备库中增加对客户端账户队列的引用，并返回那个客户端账户队列。

在实施例中，客户端账户队列选择策略包括按客户端账户对客户端账户队列进行分组。在实施例中，这包括使用仅仅一个客户端账户队列，但如果对于一个客户端账户有多个客户端账户队列，则客户端账户队列选择策略包括选择具有最少数量的客户端数据桶的一个客户端账户。客户端账户队列选择策略还可以包括通过基于令牌范围的分组来选择客户端账户队列。这可以包括使用在令牌范围上的度量，识别哪些客户端账户队列看到大量流量，并选择看到最少流量的一个客户端账户队列。它还可以包括确定在不同客户端账户队列上的客户端数据桶的数量，以及选择具有最少数量的客户端数据桶的一个客户端账户队列。

在实施例中，每个异议创建(objection creation)通知消息包括客户端数据桶名称和提供在客户端数据桶中的对象(即用户文件)的完整路径的完整对象名称。单个客户端账户队列可以馈入几个管线内，其中每个管线都有一组匹配规则。

客户端账户队列是可以去耦和按比例缩放微服务、分布式系统和无服务器应用的消息排队服务。在实施例中，客户端账户队列704、708是由Amazon Web

提供的

Simple Queue Service(SQS)。SQS实现从单独部件构建应用，每个部件执行分立的功能，用于提高可缩放性和可靠性。SQS可以提高使云应用的部件去耦和协调的成本有效性。使用SQS，客户端可以在软件部件之间以任何容量发送、存储和接收消息，而不会丢失消息或需要其他服务总是可用的。

在实施例中，SQS可以提供两种类型的消息队列，包括标准队列和FIFO队列。标准队列提供最大吞吐量、最大努力排序和消息的至少一次递送。FIFO(先进先出)队列被设计为保证消息以它们被发送的确切顺序、以有限的吞吐量被恰好处理一次。

图8是用于将批量数据摄取到数据库内的方法800的示意性流程图。方法800可以由任何合适的计算设备(例如如本文公开的资源管理器302)执行。方法800开始，并且资源管理器在802处确定指示从客户端账户接收的待摄取到数据库内的用户文件的存在的通知。方法800继续，并且资源管理器在804处识别用户文件中的数据，并且在806处识别数据库的目标表以接收用户文件中的数据。方法800继续，并且资源管理器在808处生成指示数据和目标表的摄取任务。方法800继续，并且资源管理器在810处将摄取任务分配到执行平台的执行节点，其中执行平台包括独立于共同存储数据库数据的多个共享存储设备而操作的多个执行节点。方法800继续，并且在数据由执行节点完全提交到目标表之后，资源管理器在812处将涉及目标表的元数据登记在元数据储备库中。

可以在没有用户干预的情况下自主地执行方法800。方法800可以包括在整个执行平台中异步地执行多个摄取任务，使得多个摄取任务实质上并行地被执行。

图9是描绘示例计算设备900的框图。在一些实施例中，计算设备900用于实现在本文讨论的系统和部件中的一个或更多个。例如，计算设备900可以允许用户或管理员访问资源管理器902。此外，计算设备900可以与本文描述的系统和部件中的任一个交互作用。相应地，计算设备900可以用于执行各种过程和任务，例如在本文讨论的那些过程和任务。计算设备900可以用作服务器、客户端或任何其它计算实体。计算设备900可以是各种计算设备(例如台式计算机、笔记本计算机、服务器计算机、手持计算机、平板计算机和诸如此类)中的任一个。

计算设备900包括一个或更多个处理器902、一个或更多个存储器设备904、一个或更多个接口906、一个或更多个大容量存储设备908以及一个或更多个输入/输出(I/O)设备910，其中所有部件都耦合到总线912。处理器902包括执行在存储器设备904和/或大容量存储设备908中存储的指令的一个或更多个处理器或控制器。处理器902还可以包括各种类型的计算机可读介质，例如高速缓冲存储器。

存储器设备904包括各种计算机可读介质，例如易失性存储器(例如，随机存取存储器(RAM))和/或非易失性存储器(例如，只读存储器(ROM))。存储器设备904还可以包括可重写ROM，例如快闪存储器。

大容量存储设备908包括各种计算机可读介质，例如磁带、磁盘、光盘、固态存储器(例如，快闪存储器)等。在大容量存储设备908中还可以包括各种驱动器以使从各种计算机可读介质读取和/或写入到各种计算机可读介质变得可能。大容量存储设备908包括可移除介质和/或不可移除介质。

I/O设备910包括允许数据和/或其他信息被输入到计算设备900或从计算设备900被取回的各种设备。示例I/O设备910包括光标控制设备、键盘、小键盘、麦克风、监视器或其他显示设备、扬声器、打印机、网络接口卡、调制解调器、透镜、CCD或其他图像捕获设备和诸如此类。

接口906包括允许计算设备900与其他系统、设备或计算环境交互作用的各种接口。示例接口906包括任何数量的不同网络接口，例如与局域网(LAN)、广域网(WAN)、无线网络和互联网的接口。

总线912允许处理器902、存储器设备904、接口906、大容量存储设备908以及I/O设备910与彼此以及耦合到总线912的其它设备或部件通信。总线912表示几种类型的总线结构(例如系统总线、PCI总线、IEEE 1394总线、USB总线等)中的一种或更多种。

为了说明的目的，程序和其他可执行程序部件在本文中被示出为分立的块，但是应当理解，这种程序和部件可以在不同时间驻留在计算设备900的不同存储部件中，并且由处理器902执行。可选地，在本文中描述的系统和过程可以以硬件、或硬件、软件和/或固件的组合来实现。例如，一个或更多个专用集成电路(ASIC)可被编程以执行本文所描述的系统和过程中的一个或更多个。如在本文使用的，术语“模块”意欲为了执行查询操作的全部或部分的目的例如通过硬件或硬件、软件和/或固件的组合来传达用于实现进程的实现装置。

本文描述的系统和方法允许数据作为从计算(或处理)资源分离的服务被存储和访问。即使没有计算资源从执行平台被分配，数据对虚拟仓库也是可用的，而不需要数据从远程数据源的重新加载。因此，数据是独立于与数据相关联的计算资源的分配而可用的。所描述的系统和方法对于任何类型的数据是有用的。在特定实施例中，数据以结构化的优化格式被存储。数据存储/访问服务与计算服务的去耦也简化了在不同用户和组当中的数据的共享。如本文所讨论的，每个虚拟仓库可以访问它具有访问权限的任何数据，甚至在与其他虚拟仓库数据正在访问相同数据时相同的时间进行访问。这个架构支持运行查询而没有在本地高速缓存中存储的任何实际数据。本文描述的系统和方法能够进行透明的动态数据移动，其根据需要以对系统的用户透明的方式将数据从远程存储设备移动到本地高速缓存。此外，这个架构支持数据共享而没有预先数据移动，因为任何虚拟仓库可以由于数据存储服务从计算服务的去耦而访问任何数据。

虽然在某些优选实施例的方面描述了本公开，但给定本公开(包括也在本公开的范围内的、不提供在本文阐述的所有益处和特征的实施例)的益处，其他实施例对于本领域中的普通技术人员将是明显的。应理解，其他实施例可以被利用而不偏离本公开的范围。

例子

下面的例子属于另外的实施例：

例子1是用于将批量数据摄取到数据库中的系统，该系统包括用于确定指示从客户端账户接收的将被摄取到数据库中的用户文件的存在的通知的装置。该系统还包括用于识别用户文件中的数据的装置和用于识别数据库的目标表以接收用户文件中的数据的装置。该系统包括用于生成指示数据和目标表的摄取任务的装置。该系统包括用于将摄取任务分配到执行平台的执行节点的装置，其中该执行平台包括独立于共同存储数据库数据的多个共享存储设备而操作的多个执行节点。该系统包括用于在数据由执行节点完全提交到目标表之后在元数据储备库中登记涉及目标表的元数据的装置。

例子2是如在例子1中的系统，还包括用于将用户文件提交到客户端账户队列的装置，并且其中用于确定指示用户文件的存在的通知的装置包括通过轮询客户端账户队列来确定自从上次客户端账户队列被轮询以来是否有任何新的用户文件被提交到客户端账户队列。

例子3是如在例子1-2中的任一个中的系统，其中用于确定指示用户文件的存在的通知的装置被配置为通过从数据湖接收指示用户文件已经被添加的通知来确定。

例子4是如在例子1-3中的任一个中的系统，还包括：用于识别活动摄取任务的当前总数和活动摄取任务的期望数量的装置；以及用于管理执行平台的多个执行节点使得活动摄取任务的当前总数通过下列操作中的一个或更多个而等于或接近活动摄取任务的期望数量的装置：通过移动平均使对多个执行节点的需求随着时间的过去而平滑；或者维护具有多于用于处理当前总数的活动摄取任务的所需数量的活动执行节点的执行平台。

例子5是如在例子1-4中的任一个中的系统，还包括用于生成摄取历史的装置，所述摄取历史包括来自一个或更多个用户文件的数据是否成功地存储在数据库中的指示，其中所述摄取历史存储在元数据储备库中，并且其中所述摄取历史包括文件名、表标识、文件大小、行计数或摄取错误代码中的一个或更多个。

例子6是如在例子1-5中的任一个中的系统，还包括用于基于一致性散列来将用户文件分配到资源管理器的实例的装置，其中一致性散列的散列与目标表的表标识相关联，以及其中资源管理器的实例被分配以管理与目标表相关联的散列的过程。

例子7是如在例子1-6中的任一个中的系统，还包括用于添加资源管理器的新实例的装置，其中添加资源管理器的新实例包括划分一致性散列的多个散列，并将多个散列中的每一个分配到资源管理器的多个实例，使得多个实例中的每个实例被分配相等或几乎相等数量的表。

例子8是如在例子1-7中的任一个中的系统，还包括用于将用户文件提交到客户端账户队列的装置，并且其中用于生成摄取任务的装置被配置为基于在客户端账户队列中的工作量来生成一个或更多个摄取任务，其中在客户端账户队列中的工作量基于下列项中的一个或更多个来确定：基于来自客户端账户的最近摄取的用户文件的平均大小的用户文件的近似大小；在客户端账户队列中的用户文件的数量；或者如由客户端账户指示的用户文件的大小。

例子9是如在例子1-8中的任一个中的系统，其中通过为目标表生成新的微分区来将数据提交到目标表，其中只有在数据完全且成功被插入之后，新的微分区才被存储在多个共享存储设备中。

例子10是如在例子1-9中的任一个中的系统，其中用于将任务分配到执行平台的执行节点的装置被配置为通过在下列操作中的一个或更多个时管理由执行平台正在处理的任务的总数：当阈值数量的任务由执行平台已经在处理时，延迟将摄取任务分配到执行节点；通过延迟将摄取任务分配到执行节点直到阈值数量的新用户文件已被提交到客户端账户队列为止来构建最佳大小的微分区；用户文件一被提交到客户端账户队列，就通过将摄取任务分配到执行节点来最小化时延；或者通过延迟将摄取任务分配到执行节点直到阈值数量的新用户文件已被提交到客户端账户队列为止来最小化开始和停止摄取任务的处理开销。

例子11是如在例子1-10中的任一个中的系统，其中管理由执行平台正在处理的任务的总数包括平衡多个时延因素以确保客户时延保持在阈值水平以下，同时任务的总数被最小化。

例子12是用于将批量数据摄取到数据库中的方法。该方法包括确定指示从客户端账户接收的将被摄取到数据库中的用户文件的存在的通知。该方法包括识别用户文件中的数据和识别数据库的目标表以接收用户文件中的数据。该方法包括生成指示数据和目标表的摄取任务。该方法包括将摄取任务分配到执行平台的执行节点，其中执行平台包括独立于共同存储数据库数据的多个共享存储设备而操作的多个执行节点。该方法包括在数据由执行节点完全提交到目标表之后在元数据储备库中登记涉及目标表的元数据。

例子13是如在例子12中的方法，还包括将用户文件提交到客户端账户队列，并且其中确定指示用户文件的存在的通知包括通过轮询客户端账户队列来确定以确定自从上次客户端账户队列被轮询以来是否有任何新的用户文件被提交到客户端账户队列。

例子14是如在例子12-13中的任一个中的方法，其中确定指示用户文件的存在的通知被配置为通过从数据湖接收指示用户文件已经被添加的通知来确定。

例子15是如在例子12-14中的任一个中的方法，还包括：识别活动摄取任务的当前总数和活动摄取任务的期望数量；以及管理执行平台的多个执行节点，使得活动摄取任务的当前总数通过下列操作中的一个或更多个而等于或接近活动摄取任务的期望数量：通过移动平均使对多个执行节点的需求随着时间的过去而平滑；或者维护具有多于用于处理当前总数的活动摄取任务的所需数量的活动执行节点的执行平台。

例子16是如在例子12-15中的任一个中的方法，还包括生成摄取历史，所述摄取历史包括来自一个或更多个用户文件的数据是否成功地存储在数据库中的指示，其中所述摄取历史存储在数据库的表的微分区中，并且其中所述摄取历史包括文件名、表标识、文件大小、行计数或摄取错误代码中的一个或更多个。

例子17是如在例子12-16中的任一个中的方法，还包括基于一致性散列来将用户文件分配到资源管理器的实例，其中一致性散列的散列与用户文件和目标表相关联，以及其中资源管理器的实例被分配以管理与目标表相关联的散列的过程。

例子18是如在例子12-17中的任一个中的方法，还包括将新执行节点添加到执行平台，其中添加新执行节点包括划分一致性散列的多个散列，以及将多个散列中的每一个分配到多个执行节点，使得多个执行节点中的每个执行节点基于一致性散列被分配相等或几乎相等数量的表。

例子19是如在例子12-18中的任一个中的方法，还包括将用户文件提交到客户端账户队列，并且其中生成摄取任务包括基于在客户端账户队列中的工作量来生成一个或更多个摄取任务，其中在客户端账户队列中的工作量基于下列项中的一个或更多个来确定：基于来自客户端账户的最近摄取的用户文件的平均大小的用户文件的近似大小；或者如由客户端账户指示的用户文件的大小。

例子20是如在例子12-19中的任一个中的方法，其中通过为目标表生成新的微分区来将数据提交到目标表，其中只有在数据完全且成功被插入之后，新的微分区才被存储在多个共享存储设备中。

例子21是如在例子12-20中的任一个中的方法，其中将任务分配到执行平台的执行节点还包括通过在下列操作中的一个或更多个时管理由执行平台正在处理的任务的总数：当阈值数量的任务由执行平台在处理时，延迟将摄取任务分配到执行节点；通过延迟将摄取任务分配到执行节点直到阈值数量的新用户文件已被提交到客户端账户队列为止来构建最佳大小的微分区；用户文件一被提交到客户端账户队列，就通过将摄取任务分配到执行节点来最小化时延；或者通过延迟将摄取任务分配到执行节点直到阈值数量的新用户文件已被提交到客户端账户队列为止来最小化开始和停止摄取任务的处理开销。

例子22是如在例子12-21中的任一个中的方法，其中管理由执行平台正在处理的任务的总数包括平衡多个时延因素以确保客户时延保持在阈值水平以上，同时任务的总数被最小化。

例子23是可编程来执行存储在非暂时性计算机可读存储介质中的指令的处理器。指令包括确定指示从客户端账户接收的将被摄取到数据库中的用户文件的存在的通知。指令包括识别用户文件中的数据和识别数据库的目标表以接收用户文件中的数据。指令包括生成指示数据和目标表的摄取任务。指令包括将摄取任务分配到执行平台的执行节点，其中执行平台包括独立于共同存储数据库数据的多个共享存储设备而操作的多个执行节点。指令包括在数据由执行节点完全提交到目标表之后在元数据储备库中登记涉及目标表的元数据。

例子24是如在例子23中的处理器，其中指令还包括将用户文件提交到客户端账户队列，并且其中确定指示用户文件的存在的通知包括通过轮询客户端账户队列来确定自从上次客户端账户队列被轮询以来是否有任何新的用户文件被提交到客户端账户队列。

例子25是如在例子23-24中的任一个中的处理器，其中确定指示用户文件的存在的通知被配置为通过从数据湖接收指示用户文件已经被添加的通知来确定。

例子26是如在例子23-25中的任一个中的处理器，其中指令还包括：识别活动摄取任务的当前总数和活动摄取任务的期望数量；以及管理执行平台的多个执行节点，使得活动摄取任务的当前总数通过下列操作中的一个或更多个而等于或接近活动摄取任务的期望数量：通过移动平均使对多个执行节点的需求随着时间的过去而平滑；或者维护具有多于用于处理当前总数的活动摄取任务的所需数量的活动执行节点的执行平台。

例子27是如在例子23-26中的任一个中的处理器，其中指令还包括生成摄取历史，所述摄取历史包括来自一个或更多个用户文件的数据是否成功地存储在数据库中的指示，其中所述摄取历史存储在数据库的表的微分区中，并且其中所述摄取历史包括文件名、表标识、文件大小、行计数或摄取错误代码中的一个或更多个。

例子28是如在例子23-27中的任一个中的处理器，其中指令还包括基于一致性散列来将用户文件分配到资源管理器的实例，其中一致性散列的散列与用户文件和目标表相关联，以及其中资源管理器的实例被分配以管理与目标表相关联的散列的过程。

例子29是如在例子23-28中的任一个中的处理器，其中指令还包括将新执行节点添加到执行平台，其中添加新执行节点包括划分一致性散列的多个散列，以及将多个散列中的每一个分配到多个执行节点，使得多个执行节点中的每个执行节点基于一致性散列被分配相等或几乎相等数量的表。

例子30是如在例子23-29中的任一个中的处理器，其中指令还包括将用户文件提交到客户端账户队列，并且其中生成摄取任务包括基于在客户端账户队列中的工作量来生成一个或更多个摄取任务，其中在客户端账户队列中的工作量基于下列项中的一个或更多个来确定：基于来自客户端账户的最近摄取的用户文件的平均大小的用户文件的近似大小；或者如由客户端账户指示的用户文件的大小。

例子31是如在例子23-30中的任一个中的处理器，其中通过为目标表生成新的微分区来将数据提交到目标表，其中只有在数据完全且成功被插入之后，新的微分区才被存储在多个共享存储设备中。

例子32是如在例子23-31中的任一个中的处理器，其中将任务分配到执行平台的执行节点还包括通过在下列操作中的一个或更多个时管理由执行平台正在处理的任务的总数：当阈值数量的任务由执行平台已经在处理时，延迟将摄取任务分配到执行节点；通过延迟将摄取任务分配到执行节点直到阈值数量的新用户文件已被提交到客户端账户队列为止来构建最佳大小的微分区；用户文件一被提交到客户端账户队列，就通过将摄取任务分配到执行节点来最小化时延；或者通过延迟将摄取任务分配到执行节点直到阈值数量的新用户文件已被提交到客户端账户队列为止来最小化开始和停止摄取任务的处理开销。

例子33是如在例子23-32中的任一个中的处理器，其中管理由执行平台正在处理的任务的总数包括平衡多个时延因素以确保客户时延保持在阈值水平以上，同时任务的总数被最小化。

在本公开的实施例中，系统向数据库或表提供连续的数据摄取。在这样的实施例中，系统包括包含数据桶的客户端账户。客户端账户可以被附接到可能与SQS队列通信的S3桶。SQS队列可以与多个管线通信。该系统可以接收对容纳在客户端的数据桶内的客户端数据进行更改的通知。系统可以根据需要按比例增加和减少计算资源以适应对客户端数据桶做出的更改。系统可以自动引入数据变化，并将数据摄取到客户端的数据库或表中。在实施例中，系统自动摄取数据变化而不从客户端账户接收特定命令。

在实施例中，系统自动跟踪先前被摄取到数据库表中的数据。系统可以从S3数据桶接收数据文件何时改变的通知，并对照先前被摄取的数据来比较该通知。

在实施例中，该系统提供如果执行失败则防止数据丢失的增量数据摄取。在实施例中，数据被增量地加载，使得在某个数量的本地二进制文件被达到之后，数据被自动提交到数据库。该系统可以将数据的状态存储在元数据中，使得该系统存储确切地涉及什么文件被摄取以及在哪个位置处的数据。在执行失败的情况下，系统可以从先前摄取中断的文件和位置重新开始，并且避免重新摄取数据(如果客户端账户使用中途失败的SQL命令，系统将这样做)，并且系统因此可以避免重新摄取数据。

Claims (33)

1.一种用于将批量数据摄取到数据库中的系统，所述系统包括：

用于确定指示从客户端账户接收的将被摄取到数据库中的用户文件的存在的通知的装置；

用于识别所述用户文件中的数据的装置；

用于识别所述数据库的目标表以接收所述用户文件中的数据的装置；

用于生成指示所述数据和所述目标表的摄取任务的装置；

用于将所述摄取任务分配到执行平台的执行节点的装置，其中所述执行平台包括独立于共同存储数据库数据的多个共享存储设备而操作的多个执行节点；以及

用于在所述数据由所述执行节点完全提交到所述目标表之后在元数据储备库中登记涉及所述目标表的元数据的装置。

2.根据权利要求1所述的系统，还包括用于将所述用户文件提交到客户端账户队列的装置，并且其中用于确定指示所述用户文件的存在的通知的装置包括通过轮询所述客户端账户队列来确定以确定自从上次所述客户端账户队列被轮询以来是否有任何新的用户文件被提交到所述客户端账户队列。

3.根据权利要求1所述的系统，其中，用于确定指示所述用户文件的存在的通知的装置被配置为通过从数据湖接收指示所述用户文件已经被添加的通知来确定。

4.根据权利要求1所述的系统，还包括：

用于识别活动摄取任务的当前总数和活动摄取任务的期望数量的装置；以及

用于通过下列操作中的一个或更多个管理所述执行平台的所述多个执行节点使得活动摄取任务的所述当前总数等于或接近所述活动摄取任务的所述期望数量的装置：

通过移动平均使对所述多个执行节点的需求随着时间的过去而平滑；或者

维护具有多于用于处理所述当前总数的活动摄取任务的所需数量的活动执行节点的执行平台。

5.根据权利要求1所述的系统，还包括用于生成摄取历史的装置，所述摄取历史包括来自一个或更多个用户文件的数据是否成功地存储在所述数据库中的指示，其中所述摄取历史存储在元数据储备库中，并且其中所述摄取历史包括文件名、表标识、文件大小、行计数或摄取错误代码中的一个或更多个。

6.根据权利要求1所述的系统，还包括用于基于一致性散列来将所述用户文件分配到资源管理器的实例的装置，其中所述一致性散列的散列与所述目标表的表标识相关联，以及其中所述资源管理器的实例被分配以管理与所述目标表相关联的所述散列的过程。

7.根据权利要求6所述的系统，还包括用于添加资源管理器的新实例的装置，其中添加所述资源管理器的所述新实例包括划分所述一致性散列的多个散列，并将所述多个散列中的每一个分配到资源管理器的多个实例，使得所述多个实例中的每个实例被分配相等或几乎相等数量的表。

8.根据权利要求1所述的系统，还包括用于将所述用户文件提交到客户端账户队列的装置，并且其中用于生成所述摄取任务的装置被配置为基于在所述客户端账户队列中的工作量来生成一个或更多个摄取任务，其中在所述客户端账户队列中的工作量基于下列项中的一个或更多个来确定：

基于来自所述客户端账户的最近摄取的用户文件的平均大小的用户文件的近似大小；

在所述客户端账户队列中的用户文件的数量；或者

如由所述客户端账户指示的所述用户文件的大小。

9.根据权利要求1所述的系统，其中，通过为所述目标表生成新的微分区来将所述数据提交到所述目标表，其中只有在所述数据完全且成功被插入之后，所述新的微分区才被存储在所述多个共享存储设备中。

10.根据权利要求1所述的系统，其中，用于将所述任务分配到所述执行平台的所述执行节点的装置被配置为通过在下列操作中的一个或更多个时管理由所述执行平台正在处理的任务的总数：

当阈值数量的任务由所述执行平台已经在处理时，延迟将所述摄取任务分配到所述执行节点；

通过延迟将所述摄取任务分配到所述执行节点直到阈值数量的新用户文件已被提交到客户端账户队列为止来构建最佳大小的微分区；

所述用户文件一被提交到所述客户端账户队列，就通过将所述摄取任务分配到所述执行节点来最小化时延；或者

通过延迟将所述摄取任务分配到所述执行节点直到阈值数量的新用户文件已被提交到所述客户端账户队列为止来最小化开始和停止摄取任务的处理开销。

11.根据权利要求10所述的系统，其中，管理由所述执行平台正在处理的任务的所述总数包括平衡多个时延因素以确保客户时延保持在阈值水平以下，同时任务的所述总数被最小化。

12.一种用于将批量数据摄取到数据库中的方法，所述方法包括：

确定指示从客户端账户接收的将被摄取到数据库中的用户文件的存在的通知；

识别所述用户文件中的数据；

识别所述数据库的目标表以接收所述用户文件中的所述数据；

生成指示所述数据和所述目标表的摄取任务；

将所述摄取任务分配到执行平台的执行节点，其中所述执行平台包括独立于共同存储数据库数据的多个共享存储设备而操作的多个执行节点；以及

在所述数据由所述执行节点完全提交到所述目标表之后在元数据储备库中登记涉及所述目标表的元数据。

13.根据权利要求12所述的方法，还包括将所述用户文件提交到客户端账户队列，并且其中确定指示所述用户文件的存在的所述通知包括通过轮询所述客户端账户队列来确定以确定自从上次所述客户端账户队列被轮询以来是否有任何新的用户文件被提交到所述客户端账户队列。

14.根据权利要求12所述的方法，其中，确定指示所述用户文件的存在的所述通知被配置为通过从数据湖接收指示所述用户文件已经被添加的通知来确定。

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

识别活动摄取任务的当前总数和活动摄取任务的期望数量；以及

管理所述执行平台的所述多个执行节点，使得活动摄取任务的所述当前总数通过下列操作中的一个或更多个而等于或接近活动摄取任务的所述期望数量：

通过移动平均使对所述多个执行节点的需求随着时间的过去而平滑；或者

维护具有多于用于处理所述当前总数的活动摄取任务的所需数量的活动执行节点的执行平台。

16.根据权利要求12所述的方法，还包括生成摄取历史，所述摄取历史包括来自一个或更多个用户文件的数据是否成功地存储在所述数据库中的指示，其中所述摄取历史存储在元数据储备库中，并且其中所述摄取历史包括文件名、表标识、文件大小、行计数或摄取错误代码中的一个或更多个。

17.根据权利要求12所述的方法，还包括基于一致性散列来将所述用户文件分配到资源管理器的实例，其中所述一致性散列的散列与所述目标表的表标识相关联，以及其中所述资源管理器的所述实例被分配以管理与所述目标表相关联的所述散列的过程。

18.根据权利要求17所述的方法，还包括添加资源管理器的新实例，其中添加所述资源管理器的所述新实例包括划分所述一致性散列的多个散列，以及将所述多个散列中的每一个分配到资源管理器的多个实例，使得所述多个实例中的每个实例被分配相等或几乎相等数量的表。

19.根据权利要求12所述的方法，还包括将所述用户文件提交到客户端账户队列，并且其中生成所述摄取任务包括基于在所述客户端账户队列中的工作量来生成一个或更多个摄取任务，其中在所述客户端账户队列中的工作量基于下列项中的一个或更多个来确定：

基于来自所述客户端账户的最近摄取的用户文件的平均大小的用户文件的近似大小；

在所述客户端账户队列中的用户文件的数量；或者

如由所述客户端账户指示的所述用户文件的大小。

20.根据权利要求12所述的方法，其中，通过为所述目标表生成新的微分区来将所述数据提交到所述目标表，其中只有在所述数据完全且成功被插入之后，所述新的微分区才被存储在所述多个共享存储设备中。

21.根据权利要求12所述的方法，其中，将所述任务分配到所述执行平台的所述执行节点还包括通过在下列操作中的一个或更多个时管理由所述执行平台正在处理的任务的总数：

当阈值数量的任务由所述执行平台已经在处理时，延迟将所述摄取任务分配到所述执行节点；

通过延迟将所述摄取任务分配到所述执行节点直到阈值数量的新用户文件已被提交到客户端账户队列为止来构建最佳大小的微分区；

所述用户文件一被提交到所述客户端账户队列，就通过将所述摄取任务分配到所述执行节点来最小化时延；或者

通过延迟将所述摄取任务分配到所述执行节点直到阈值数量的新用户文件已被提交到所述客户端账户队列为止来最小化开始和停止摄取任务的处理开销。

22.根据权利要求21所述的方法，其中，管理由所述执行平台正在处理的任务的所述总数包括平衡多个时延因素以确保客户时延保持在阈值水平以下，同时任务的所述总数被最小化。

23.一种可编程来执行存储在非暂时性计算机可读存储介质中的指令的处理器，所述指令包括：

确定指示从客户端账户接收的将被摄取到数据库中的用户文件的存在的通知；

识别所述用户文件中的数据；

识别所述数据库的目标表以接收所述用户文件中的所述数据；

生成指示所述数据和所述目标表的摄取任务；

将所述摄取任务分配到执行平台的执行节点，其中所述执行平台包括独立于共同存储数据库数据的多个共享存储设备而操作的多个执行节点；以及

在所述数据由所述执行节点完全提交到所述目标表之后在元数据储备库中登记涉及所述目标表的元数据。

24.根据权利要求23所述的处理器，其中，所述指令还包括将所述用户文件提交到客户端账户队列，并且其中确定指示所述用户文件的存在的所述通知包括通过轮询所述客户端账户队列来确定以确定自从上次所述客户端账户队列被轮询以来是否有任何新的用户文件被提交到所述客户端账户队列。

25.根据权利要求23所述的处理器，其中，确定指示所述用户文件的存在的所述通知被配置为通过从数据湖接收指示所述用户文件已经被添加的通知来确定。

26.根据权利要求23所述的处理器，其中，所述指令还包括：

识别活动摄取任务的当前总数和活动摄取任务的期望数量；以及

管理所述执行平台的所述多个执行节点，使得活动摄取任务的所述当前总数通过下列操作中的一个或更多个而等于或接近活动摄取任务的所述期望数量：

通过移动平均使对所述多个执行节点的需求随着时间的过去而平滑；或者

维护具有多于用于处理所述当前总数的活动摄取任务的所需数量的活动执行节点的执行平台。

27.根据权利要求23所述的处理器，其中，所述指令还包括生成摄取历史，所述摄取历史包括来自一个或更多个用户文件的数据是否成功地存储在所述数据库中的指示，其中所述摄取历史存储在元数据储备库中，并且其中所述摄取历史包括文件名、表标识、文件大小、行计数或摄取错误代码中的一个或更多个。

28.根据权利要求23所述的处理器，其中，所述指令还包括基于一致性散列来将所述用户文件分配到资源管理器的实例，其中所述一致性散列的散列与所述目标表的表标识相关联，以及其中所述资源管理器的所述实例被分配以管理与所述目标表相关联的所述散列的过程。

29.根据权利要求28所述的处理器，其中，所述指令还包括添加资源管理器的新实例，其中添加所述资源管理器的所述新实例包括划分所述一致性散列的多个散列，以及将所述多个散列中的每一个分配到资源管理器的多个实例，使得所述多个实例中的每个实例被分配相等或几乎相等数量的表。

30.根据权利要求23所述的处理器，其中，所述指令还包括将所述用户文件提交到客户端账户队列，并且其中生成所述摄取任务包括基于在所述客户端账户队列中的工作量来生成一个或更多个摄取任务，其中在所述客户端账户队列中的所述工作量基于下列项中的一个或更多个来确定：

基于来自所述客户端账户的最近摄取的用户文件的平均大小的所述用户文件的近似大小；

在所述客户端账户队列中的用户文件的数量；或者

如由所述客户端账户指示的所述用户文件的大小。

31.根据权利要求23所述的处理器，其中，通过为所述目标表生成新的微分区来将所述数据提交到所述目标表，其中只有在所述数据完全且成功被插入之后，所述新的微分区才被存储在所述多个共享存储设备中。

32.根据权利要求23所述的处理器，其中，将所述任务分配到所述执行平台的所述执行节点还包括通过在下列操作中的一个或更多个时管理由所述执行平台正在处理的任务的总数：

当阈值数量的任务由所述执行平台已经在处理时，延迟将所述摄取任务分配到所述执行节点；

通过延迟将所述摄取任务分配到所述执行节点直到阈值数量的新用户文件已被提交到客户端账户队列为止来构建最佳大小的微分区；

所述用户文件一被提交到所述客户端账户队列，就通过将所述摄取任务分配到所述执行节点来最小化时延；或者

通过延迟将所述摄取任务分配到所述执行节点直到阈值数量的新用户文件已被提交到所述客户端账户队列为止来最小化开始和停止摄取任务的处理开销。

33.根据权利要求32所述的处理器，其中，管理由所述执行平台正在处理的任务的所述总数包括平衡多个时延因素以确保客户时延保持在阈值水平以下，同时任务的所述总数被最小化。

Images