CN110168515B - 用于分析数据关系以支持查询执行的系统 - Google Patents

Abstract

公开了一种用于识别一个或多个数据表的列之间的关系的方法和软件工具。在所公开的方法中，为多个列对中的每一个计算关系指示符，每个列对包括从一个或多个数据表中选择的相应的第一列和第二列。关系指示符包括第一列的数据和第二列的数据之间的关系的度量(例如，指示关系的强度或可能性)。然后根据计算的关系指示符来识别数据表的列之间的关系。所识别的关系可以用于创建和执行数据查询。

Description

用于分析数据关系以支持查询执行的系统

技术领域

本发明涉及用于分析数据集以识别可以使用的数据集之间可能的关系的系统和方法，例如，这些关系可用于支持对数据集的查询的创建和执行。

背景技术

组织维护越来越庞大，且数据集越来越复杂。通常需要将来自不同数据源的数据汇集在一起，以便能够处理并分析数据集。然而，在不同数据集之间的关系不是先验已知的情况下，或者在当从其原始源中提取数据时这些信息已经丢失的情况下，这可能会很困难。这可能需要费力的手动分析来确定数据的结构并创建高效的数据查询。此外，复杂数据集的查询设计通常需要专业知识，并且使普通用户能够访问这些数据集带来了重大的技术挑战。

发明内容

因此，本发明的实施例寻求解决现有数据处理系统中的缺陷。

因此，在本发明的第一方面，提供了一种识别数据集之间关系的方法，每个数据集包括多个数据记录，所述方法包括：评估多个候选关系，在与第一数据集相关联的第一数据值集合和与第二数据集相关联的第二数据值集合之间定义每个候选关系，所述评估包括计算每个候选关系的关系度量，其中，候选关系的关系度量提供第一值集合和第二值集合之间的关系的度量，所述计算包括：计算指示第一值集合和第二值集合中的至少一个的值的差异度的第一度量；计算指示第一值集合的值和第二值集合的值之间重叠的度量的第二度量；所述方法还包括根据计算的关系度量来识别数据集之间的一种或多种关系。

所述第一值集合和第二值集合优选地定义相应数据集的相应第一和第二候选键。术语候选键优选地是指从数据集中导出的数据，该数据集可用于识别数据记录，例如，作为主键或外键(无论是否实际定义或用作源数据中的键)，因此，候选键可用作数据集之间的关系的源或目标。这种候选键通常对应于从数据集的给定字段或字段组合中获取(或导出)的值的集合(具有从收集的相应记录中获取/导出的相应键值)。

术语“差异度”优选地指值集合(例如，定义键)的值彼此区分(不同)的程度(例如，换言之，这可以涉及值集合内值的重复程度)。因此，与具有更多重复值的值集合相比，具有更少重复值的值集合(绝对值，或更优选，相对值)可以被认为具有更高的差异度。术语“重叠”优选地指在另一值集合/键中也发现一个值集合/键中的值的程度。术语“度量”优选地指可以计算或以其他方式确定的任何度量或指标(度量可以用数字或任何其他方式表示)。

优选地，每个数据集包括数据记录，每个数据记录具有一个或多个数据字段，并且其中，所述第一和/或第二值集合(对于给定的候选关系)包括：其相关数据集的一个或多个数据字段的值的集合；或者从其相关数据集的一个或多个数据字段中导出的值的集合。所述第一和/或第二值集合可以包括(对于给定/至少一个候选关系)相关数据集的两个或多个字段的字段值的组合或串联。

优选地，所述第一和/或第二值集合包括多个值，从相关数据集的相应记录中导出每个值，优选地，其中，从相应记录的一个或多个相应字段中导出所述值集合的值。相应的字段优选地是分开的记录共有的字段，例如，根据数据集的数据模式，这些字段是相同的字段(例如，值集合可以对应于表格的一个或多个特定列或者对象集合的一个或多个特定属性)。给定字段的一个或多个预定义值可以从形成候选键的值集合中排除，例如，空值或其他预定义异常。因此，在这种情况下，可以仅针对非空和/或非排除的候选键值来执行分析。

优选地，数据集包括表格(例如，关系数据库表格)，所述记录包括表格的行，优选地，其中，所述第一值集合包括来自第一表格的第一列或列组合，并且其中，所述第二值集合包括来自第二表格的第二列或列组合。在关系数据库表格的上下文中，术语“行”和“记录”在本文通常可互换使用，术语“列”和“字段”也是如此。

该方法可以包括评估候选关系，涉及(作为候选键)第一和/或第二数据集的至少一个、优选地多个不同的字段/列组合。可选地，可以考虑所有可能的字段/列组合(例如，高达字段/列的最大数量，在一个示例中，可以是两个或三个；或者，没有限制可以应用)。可以基于预定标准，过滤可能的组合(例如，达到极限)，例如，以消除不太可能的组合，从而提高计算效率。

优选地，该方法包括计算一个或多个(或每个)候选关系的关系指示符，其中，候选关系的关系指示符指示形成候选关系的值集合之间的关系的强度或可能性，并且基于候选关系的第一和第二度量来计算。

优选地，所述第一度量包括键概率指示符，指示所述第一值集合或第二值集合是(或用作/能够用作)其数据集的主键的概率。计算键概率指示符包括：为所述第一值集合和第二值集合计算相应的第一和第二概率指示符，指示相应的值集合是其数据集的主键的概率，并且基于第一和第二概率指示符确定候选关系的键概率指示符。可以确定候选关系的键概率，作为(或者基于)第一和第二概率指示符中的较大者。该方法可以包括基于值集合的不同值的数量与值集合的值的总数(或数据集中的记录的总数)之间的比率，确定值集合定义其数据集的主键的概率。如上所述，空值和可选的其他定义的异常值可以不被认为是有效的键值，并且在确定不同值的数量和/或值集合中的值的总数时不计数。因此，术语“键值”可以被认为是指不为空并且可选地不对应于一个或多个预定义的异常值的键值。

优选地，所述第二度量包括指示所述第一值集合和第二值集合的值之间的相交程度的相交指示符。计算相交指示符优选地包括：计算第一值集合和第二值集合之间的不同相交值的数量，其中，相交值是出现在第一值集合和第二值集合中的值；并且基于不同相交值的数量和第一值集合或第二值集合的不同值的总数之间的比率来计算候选关系的相交指示符。如前所述，空值和可选地其他定义的异常值可以从相应值集合的不同相交值和/或不同值的计数中排除。

在本公开中，集合的不同值优选地被认为是消除了重复值的值的集合，即，每个值彼此不同的集合。

优选地，该方法包括：计算不同相交值的数量和第一值集合的不同值的总数之间的第一比率；计算不同相交值的数量和第二值集合的不同值的总数之间的第二比率；并且根据第一比率和第二比率计算相交指示符。该方法可以包括计算相交指示符，作为(或基于)第一比率和第二比率中的较大者。

优选地，该方法包括基于键概率指示符和相交指示符的乘积来计算候选关系的关系指示符。

识别一种或多种关系的步骤可以包括响应于候选关系的第一度量、第二度量和关系指示符中的一个或多个超过相应预定阈值，识别相应数据集的值集合之间的可能关系。可替代地或额外地，该方法可以包括根据其关系指示符和/或计算的度量对多个候选关系进行排序，和/或将排序值与候选关系相关联。

识别步骤优选地包括生成输出数据集，所述输出数据集包括识别一个或多个识别的关系的信息，所述输出数据优选包括计算的关系指示符、度量和/或等级。

在优选实施例中，所述数据集是数据表格，所述第一值集合和第二值集合包括相应表格的列。所述方法随后可以包括多个处理阶段，包括：第一处理阶段，包括将出现在数据表格中的值映射到那些数据值的列位置；第二处理阶段，包括计算相应列的不同数据值的数量和/或相应列对的不同相交值的数量；以及第三处理阶段，包括基于第二处理阶段的输出计算关系指示符。第一处理阶段还可以包括以下中的一个或多个：聚集、分类和划分所映射的数据值。所述第一处理阶段、第二处理阶段和第三处理阶段中的一个或多个可以由并行操作的多个计算节点执行。该方法可以被实现为映射化简算法。例如，所述第一处理阶段可以使用映射操作来实现，所述第二处理阶段可以被实现为化简操作。

优选地，该方法包括在数据查询的创建和/或执行中使用至少一个所识别的关系来从一个或多个数据集中检索数据，所述数据查询优选地指定在数据集的相应键之间定义的连接，这些键对应于定义关系的值集合。

在本发明的另一方面(可以与上述方面相结合)，提供了一种计算机实现的数据处理方法，包括：计算指示多个数据表格的列之间关系的数据；接收至少具有第一列集合的第一表格和具有第二列集合的第二表格的用户选择；向用户提供第一表格和第二表格的相应列之间的一个或多个建议关系的指示，每个指示基于计算的数据指示第一表格的一列或多列和第二表格的一列或多列之间的关系的强度或可能性；接收一个建议的关系的用户选择；并且基于所选表格和所选关系，创建数据查询。计算步骤可以包括执行如上所述的任何方法。

在上述任一方面，所述数据查询可以指定所选表格之间的连接，相对于与所选关系相关的列来定义所述连接。所述数据查询可以包括数据查询语言语句，优选地是SQL(结构化查询语言)或HQL(Hive查询语言)语句。该方法可以包括执行查询，以从数据表格中检索数据，并且可选地存储查询输出和/或向用户装置发送查询输出。

在本发明的另一方面(可以与上述任何方面相结合)，提供了一种识别数据表格之间关系的方法，每个数据表格优选地包括对应于存储在表格中的相应数据记录的一行或多行以及对应于数据记录的相应数据字段的一列或多列，所述方法包括：为多个键对中的每一个计算关系指示符，每个键对包括从相应的数据表格中选择的相应的第一和第二候选键，其中，所述关系指示符包括第一候选键的数据和第二候选键的数据之间的关系的度量；并且根据计算的关系指示符，识别数据表格之间的一种或多种关系。

在本发明的另一方面，提供了一种数据处理系统，包括：数据存储器，用于存储数据表格(每个数据表格优选地包括对应于存储在表格中的相应数据记录的一行或多行以及对应于数据记录的相应数据字段的一列或多列)；以及表格分析器模块，其被配置为：为多个键对中的每一个计算关系指示符，每个键对包括从一个或多个数据表格中选择的相应的第一和第二候选键，其中，所述关系指示符包括第一候选键的数据和第二候选键的数据之间的关系的度量；所述关系指示符优选地基于第一和第二候选键中的至少一个的值的差异度的度量和/或基于第一候选键的值和第二候选键的值之间的重叠的度量来计算；并且根据计算的关系指示符，输出指定数据表格的候选键之间的一种或多种关系的数据。该系统还可以包括查询模块，其被配置为使用在输出数据中指定的关系，创建和/或执行数据表格上的数据查询。该系统可以被配置成执行如上所述的任何方法。

更一般地，本发明还提供了一种系统或设备，其具有用于执行本文所述的任何方法的装置，优选地为具有相关存储器的处理器的形式；以及包括软件代码的计算机可读介质，当在数据处理设备上执行时，所述软件代码适于执行本文所述的任何方法。

本发明的一个方面的任何特征可以以任何适当的组合应用于本发明的其他方面。特别地，方法方面可以应用于设备和计算机程序方面，反之亦然。

此外，在硬件中实现的特征通常可以在软件中实现，反之亦然。本文对软件和硬件特征的任何引用都应相应地进行解释。

附图说明

现在将参照附图，仅以举例的方式描述本发明的优选特征，其中：

图1示出了用于将数据导入中央数据储存库并分析和管理导入数据的系统；

图2A示出了将数据从关系数据库导入数据湖的高级处理；

图2B示出了在导入期间管理数据模式的处理；

图3示出了元数据生成器和模式演化模块的功能组件；

图4示出了元数据生成器和模式演化模块的操作；

图5A和图5B示出了自动生成的脚本用于数据导入；

图6A和图6B示出了表格差值计算器的功能组件；

图7示出了表格差值计算器的操作；

图8示出了表格差计算的示例；

图9示出了自动发现数据表之间关系的表格分析处理；

图10、图11、图12、图13、图14A和图14B更详细地示出了表格分析处理；

图14C-图14H示出了表格分析算法的扩展；

图15示出了元数据集和管理处理；

图16示出了元数据集和管理处理的替代表示；

图17示出了元数据集和管理处理的工作队列用户界面；

图18A和图18B示出了用于导航和配置信息层次结构的用户界面；

图19示出了用于配置元数据项的用户界面；

图20示出了元数据集和/或批准用户界面；

图21示出了用于查看或编辑数据关系的用户界面；

图22示出了元数据同步处理；

图23A和图23B示出了查询构造器用户界面；

图24示出了使用查询构建器工具创建、编辑和记载查询的处理；

图25A-图25C示出了数据管理系统的软件架构；以及

图26示出了可用于实现各种描述的处理的计算节点的硬件/软件架构的示例。

具体实施方式

本发明的实施例提供了用于将数据从诸如关系数据库等各种结构化数据源导入到大规模非结构化或灵活结构化数据储存库中以及用于在导入之后管理数据的系统和方法。这种数据管理系统在图1中进行了概述。

应当注意的是，在以下描述中，具体的实现细节是以举例的方式阐述的(例如，与所使用的数据库和软件技术以及系统的软件架构的细节有关，例如，Hadoop/Hive和Java技术的使用)。这些涉及系统的示例性实现方式，但不应被解释为限制，并且替代方法和技术可以替换。

数据管理系统100提供称为“数据挖掘”工具106的软件组件，用于将数据从任意数量的数据源102-1、102-2、102-3导入到数据库108中。

数据储存库108在本文也称为“数据湖”，并且可以包括任何数据存储技术。优选地，数据湖允许以非结构化或灵活结构化的方式存储数据。例如，储存库或数据湖可能不需要固定或预定义的数据模式。数据湖可以是(或可以包括)NoSQL或其他非关系数据库，例如，将数据存储为“记载”数据对象(例如，JSON记载)的面向记载的数据库、键值存储器、面向列的数据库、存储平面文件的文件系统、或任何其他合适的数据存储器或上述任何内容的组合。然而，在其他实施例中，数据湖可以替代地包括传统的结构化数据库，例如，关系数据库或对象数据库。

在本文描述的示例中，数据湖被实现为采用具有Apache Hive数据仓库基础设施的Hadoop分布式文件系统(HDFS)的Hadoop数据储存库。Hive查询语言(HQL)用于在HDFS中创建和操作数据集，以存储从数据源102提取的数据。

数据源102-1、102-2、102-3被示为结构化数据库(例如，关系或对象数据库)，但是可以使用任何形式的数据源，例如，平面文件、实时数据馈送等。在以下示例中，数据源是由传统关系数据库管理系统(RDBMS)管理的关系数据库，例如，Oracle/MySQL/Microsoft SQL服务器等。

给定的源数据库102由多个表104组成(其中，表包括一组行或记录，每一行或记录分成一个或多个字段或列)。数据挖掘工具可以导入整个数据库(即，包括所有表)，或者可替换地，可以只导入一个或多个选定的表格(例如，如此处所示，用实线示出的表子集已经被选择用于从数据库102-1导入)。此外，系统可以从单个数据源102-1或者从多个数据源将表格和数据导入到同一数据湖108中。因此，源自具有不同原始数据模式的不同结构化的数据源的数据可以以Hive表110的集合的形式共存于数据湖108中。

在一个示例中，导入的表数据可以存储在HDFS(例如，Hadoop SEQUENCEFILE格式)中的文件中。实际上，除了非常小的表之外，一个给定的源表可能分为HDFS中的多个文件。数据挖掘工具优选地以并行方式作为映射化简算法(此处使用Hadoop Java映射化简框架实现)操作，并且为导入的表生成的文件数量取决于使用多少映射器来创建文件。例如，对于小型表，可以使用默认的十个映射器，为一个表生成十个文件，但是非常大的表可能会分成数千个文件。

文件按行分区，每个文件包含从源表导入的完整列集(通常源表的所有列都将导入，但情况并非总是如此)。在导入期间，出于管理目的，可以将额外的管理数据列添加到导入的表中，例如，记录导入时间戳等。文件放置在目录结构中，使得与单个源表相关联的文件优选地驻留在公共目录中(例如，每个源表具有单独的目录，但是可替换地，文件可以分布在多个目录中，例如，取决于表是否在源处分区)。

这些文件由数据挖掘映射化简算法以SEQUENCEFILE格式创建。Apache Hive使数据库结构能够应用于这些文件，例如，表和列，并且结构信息存储在称为Hive Metastore的Hive数据库中。因此，术语“Hive表”用于描述应用于HDFS文件系统中的许多文件上的表结构。因此，Hive表是结构化HDFS文件的集合，每个文件对应于源表的分区，该分区包括该表的行的子集。Hive命令(使用HQL)可用于访问这些数据以及更新表结构。HQL提供了与SQL类似的语法。

在优选实施例中，Hadoop平台被配置为保持两个可操作的数据库；第一种称为OPEN，另一种称为CLOSED。OPEN存储当前源系统表的副本，而CLOSED存储这些源系统表的完整历史记录，包括已删除的记录和此后已更新的旧版本的记录。

数据湖108中的数据可用于外部处理，例如，分析处理112和报告处理114。因此，所描述的方法可以使一个组织能够将来自许多不同数据库的信息聚集在一起(可能支持组织的不同操作)，并集中分析和处理数据。

从许多不同的数据源导入数据时，可能会丢失对数据表内容及其相互关系的了解。此外，从不同数据源导入的数据往往是相互关联的。例如，燃气或类似公用事业提供商可以从组织的供应部分导入燃气供应账户的数据库，并从组织的服务/保持部分导入锅炉保持数据的数据库。这些数据可能是相关的，因为一些供应客户也可能是保持客户。因此，多个数据源中的数据之间可能存在关系，例如，这可能表现为出现在两组中的重叠数据项，例如，客户标识符或姓名、地址等。以上仅是一个示例，由任何领域(例如，医疗、银行、制造等)内的组织保持的不同数据源之间可能出现类似的关系。

然而，来自不同数据源的等效或相关数据不一定会驻留在具有相同或相关名称的表/列中，源数据库的记载可能不完整或不一致，使得难以使用导入后的数据。此外，即使在从同一数据源导入多个表的情况下，这些表之间的关系(例如，可以在源数据库中以元数据、查询、视图等形式定义)也可能在导入处理中丢失。这种结构信息和数据知识的丢失带来了一个技术问题，影响了数据的后续处理。

本发明的实施例通过提供能够自动发现存储在数据湖108中的Hive表之间的关系的表格分析器软件模块107以及提供用于整理关于导入的数据实体的元数据的处理的元数据管理器工具109来解决这些问题。

基于特定列作为其表格的键的概率以及不同列的数据内容之间的重叠程度，表格分析器107使用采用随机方法的算法来识别表格列之间的关系。这种关系可以表示例如主键-外键关系或者可以允许执行表连接操作来组合来自不同源表的数据的任何其他关系。然后，所识别的关系可用于创建连接查询，以组合数据湖并从中提取数据。

元数据管理器工具109实现与已经导入数据湖的数据相关的元数据的输入和管理处理。连同由表格分析器工具107发现的关系，元数据可以用于帮助后续的数据处理和提取。

以下部分更详细地描述了数据挖掘工具、表格分析器工具和元数据管理器工具。

数据挖掘

数据挖掘工具106包括以下组件：

1)元数据生成和模式演化；

2)差值计算器；

3)历史捕捉。

数据挖掘框架非常灵活，能够将数据从任何关系数据库中吸收到Hadoop数据湖中。元数据生成和模式演化工具不仅提供无缝处理源模式变化的能力，还提供自动化Hadoop开发的能力，这是从新数据源吸收额外的表和数据所必需的(在某些情况下，完全不需要人为干预/开发工作)。

差值计算器用于无法以增量方式提供变更数据的数据源。

历史捕捉处理提供了每天创建OPEN和CLOSED分区的方法，分别包含当前数据集和历史数据。

图2A示出了与从给定源数据库导入的特定表相关的数据挖掘导入处理。对每个要导入的表重复所描述的处理。

元数据生成器和模式演化处理202检索并存储正在导入的表格的元数据，并处理元数据的变化。元数据定义了导入的表格的模式，即，表结构和字段定义。元数据提取可以通过配置文件204来控制。

元数据在数据提取处理206中用于从源数据库的表中提取数据。在本示例中，Sqoop脚本用于执行提取，但也可以用其他技术代替。

数据提取处理从源数据库中读取表的内容。提取的数据存储在数据湖内的临时着陆区域208中。

重新定序器和数据清理处理210(例如，使用Hive命令或脚本实现)预处理数据并将预处理后的数据存储在暂存区域212中。重新排序包括改变行的列顺序，以确保当存储在Hadoop中时，作为键的列是每行的第一列，这可以提高访问效率。清理包括将数据放入Hadoop的适当格式的其他处理，例如，通过移除虚假数据、重新格式化数据等。在一个示例中，清理包括去除针对Oracle数据库使用Sqoop时引入的错误空间的处理(由于Sqoop的已知错误)。更一般地，重新排序/清理脚本可以用来配置其他所需的数据转换，这取决于应用程序上下文和特定需求。优选地，重新排序/数据清理处理还生成表信息文件，这些文件在列重新排序和清理之后存储文件的表和列信息。

如果导入是给定数据源的第一次运行(检查214)，例如，第一次导入特定的表，则整个数据集移动到着陆区域218。如果不是第一次运行，则差值计算器处理216执行差值计算，以识别在数据提取步骤206中读取的当前表格内容和先前导入版本的同一表格之间的差值。旧版本和当前导入版本之间的差值(本文也称为表增量)然后存储在着陆区域218中。因此，如果这是第一次导入表格，则着陆区域218将包含表格的完整数据，或者如果表格先前已经导入，则着陆区域218将包含增量。

历史捕捉处理220随后更新数据湖中的Hive表。这既包括更新OPEN数据库中记录的当前值，也包括保持CLOSED数据库中的历史信息。将在下面详细描述历史捕捉处理。

控制框架230管理数据挖掘工作流。在一个实施例中，这使用Unix外壳脚本来管理数据导入处理的完整工作流。控制框架优选地从任何故障点提供重启能力，并向所有涉及的处理提供日志记录和错误跟踪功能。

注意，上面的示例描述了使用差值计算器为先前导入的表生成表增量。然而，在某些情况下，源数据库可能能够直接提供增量信息，在这种情况下，可能不需要差值计算器。

图2B更详细地示出了将表104从源数据库导入数据湖中的Hive表110的处理。该处理开始于步骤240，数据挖掘工具连接到源数据库。在步骤242中，该表的元数据提取到一个或多个元数据文件244中。然后，在步骤246中，数据挖掘识别该表是新表(先前未导入)还是先前导入的表。如果该表是新的，则在步骤248中基于定义源表的提取的元数据创建相应的Hive表110(例如，通过发出“创建表”命令)，并且该处理前进到步骤254(见下文)。

如果先前已经导入该表，那么在步骤250中，提取的元数据244与为该表存储的现有元数据进行比较，以识别元数据是否已经以需要改变Hive表110的方式改变(注意，并非源数据库中的所有模式变化都需要变更Hive表，如下面更详细讨论的)。对表模式的变化也可能需要重新生成Sqoop和HQL数据导入脚本，如下面更详细的描述。如果需要改变，则在步骤252中，变更Hive表(例如，通过发出“变更表”命令)。如果源表的模式(如元数据中定义的)没有改变，或者任何变化不需要变更Hive表，则该处理直接前进到步骤254。

在步骤254中，运行表的Sqoop脚本，以将表数据提取到临时存储中。注意，对于先前导入的表，如果源数据库支持增量报告，则提取的数据可以是自上次导出以来的变化增量，或者提取的数据可以是全表内容，在这种情况下，可以运行差值计算器来识别自上次导入以来的任何变化，如下面更详细描述的。在新表的情况下，Sqoop脚本读取全表内容。

然后，在步骤256中，表数据(全表内容或表增量)插入到Hive表110中。

在一个优选实施例中，表信息文件260(“tableinfo”)优选地保持，并且用于存储Hadoop文件系统中保持的表格的列信息(在表已经重新排序和清理之后，例如，在列顺序中首先放置键列，并且移除列之间的任何错误空格)。在步骤258中，更新表格信息文件，以反映导入期间检测到的任何变化。

元数据生成和模式演化

元数据生成和模式演化处理202执行以下功能：

·在运行时为源数据库中的任何物化RDBMS表收集元数据；

·运行时根据元数据在Hadoop环境中创建表；

·在运行时识别对表元数据的变化，这会影响Hadoop环境；

·在运行时，将表的模式变化应用到Hadoop环境；

·运行时根据表元数据生成Sqoop和Hive脚本；

·如果识别出模式变化，则根据需要重新生成Sqoop和Hive脚本。

通常，要将数据从任何RDBMS系统导入Hadoop，根据正在导入的表格的数据模式，编写定制的导入脚本(例如，使用Sqoop)。然而，编写必要的脚本是很耗时的(在典型的示例中，为一个新项目向数据湖添加表可能需要三天或更多的开发时间，同时需要额外的时间来保证质量)。这增加了项目的实施复杂性和成本。此外，如果RDBMS数据模式改变，则需要类似的开发工作来升级用于导入的脚本。

本文描述的实施例减少或消除了吸引新的RDBMS表或处理源数据库模式的变化所需的开发工作。

元数据生成和模式演化处理提供了以下功能组件。

元数据生成器：该元数据生成器从任何RDBMS系统中收集物化表的元数据，并将元数据存储在元数据储存库中。元数据用于生成Sqoop/Hive脚本，以便将数据从RDBMS导入Hadoop环境。

模式演化：模式演化功能识别任何RDBMS的物化表的元数据的变化。如果发现任何会影响表的Hadoop环境的变化，则Hadoop环境会在运行时相应地变更(脚本会重新生成)，不会造成系统停机或任何手动准备。

元数据存档：元数据存档，包括描述表的初始数据模式的元数据(第一次吸引)和随后的变化。优选地，元数据以这样的方式存档，即，表可以从初始元数据重新创建，并且相同的模式演化可以应用于其中，以将其模式演化为最新的模式。这可能有助于开发/测试环境中模式的进化。

元数据生成和模式演化处理旨在使用通用的Java API为任何RDBMS的表提取元数据。优选实施例使用DatabaseMetaData Java API来检索任何RDBMS源的元数据(并识别对元数据的任何变化)。如果在数据源改变了表的模式，则数据湖中表示的模式也会相应地修改。

动态执行模式发现。来自源系统的动态模式发现在运行时执行，必要的操作应用于数据湖(如果有的话)。这可以允许将现有数据源中的表添加到数据湖中，而无需任何手动开发工作。

图3示出了元数据生成器和模式演化处理的核心模块。

元数据生成器302使用由Java提供的DatabaseMetaData API从数据源102的关系数据库管理系统(RDBMS)读取表的元数据，该API提供了读取不同数据库源的元数据的公共平台。举例来说，为要导入的每个表的每列收集以下信息。

·表格名称；

·表格描述；

·源-这表示源系统或数据库；

·列名(如果在脚本中不能使用列名，则在生成Sqoop脚本时可能需要特殊处理，在这种情况下，列名会相应地进行标记)；

·Sqoop列名-如果为列名识别特殊情况(见上文)，则可以在数据湖中重新命名该列。在此处记录新名字。

·列数据类型；

·列描述；

·键类型(如果列是表索引的一部分，则主键标记为‘P’，其他类型的键标记为‘S’)。其他列可以用特定的标志来标记；例如，导入期间添加的内部管理数据列可以用适当的标志来识别。

·处理As-这表示该列将如何在数据湖中表示/处理。在优选实施例中，所有列都作为字符串数据类型导入和处理(自动执行任何必要的数据转换)；

·可控类型-如果允许列在源表中取空值，则标志设置为‘真’，否则标志设置为‘假’；

·DeltaView前缀-这仅用于Oracle数据集成器馈送，由重新排序器和数据清理处理用来确定要用作输入的数据库日志视图的名称。DeltaView前缀是指源系统日志数据库的数据库视图名称的前缀。例如，对于名为“ADRC”的CRM表，日志数据库的视图名称是“CRM_JE_ADRC”，因此DeltaView前缀是“CRM_JE_”；

·验证As-如果在数据湖中处理数据，则应根据该数据类型验证列值。

收集的特定元数据可能因源数据库的类型而异。

模式元数据存储在元数据储存库310中，例如，以CSV(逗号分隔值)格式(例如，作为每个源表的CSV文件)或任何其他合适的方式。元数据储存库可以存储在数据湖中或单独存储。

模式区分器304为每个表识别源102中的模式变化。如果识别模式变化，则旧模式将归档在归档目录中，将保持新模式，以供进一步处理。模式区分器还向Sqoop生成器306和数据湖模式生成器308提供信号，以生成新的Sqoop脚本和相应的HQL脚本。

在优选实施例中，模式演化处理可以仅作用于可能影响数据湖中数据的存储和处理的模式变化。在优选实施例中，以下模式变化被认为可能影响数据湖数据表示：

·向表中添加一列

·表的唯一索引变化

以下变化不会被认为影响数据湖数据表示：

·删除列

·列的重命名

·列长度/大小的变化

·数据类型的变化(因为数据湖认为所有列都是字符串类型)

·列的顺序变化

然而，特定的模式变化是否会影响数据湖表示并因此应该检测和处理，这取决于数据湖的具体实现和所使用的数据表示。因此，在其他实施例中，所检测和处理的模式改变的集合可以不同，并且可以在这些实施例中处理诸如列长度或类型变化和顺序变化等变化。

作为特定示例，在优选实施例中，在源表中删除列的情况下，该列保留在数据湖表示中，以允许历史数据分析。然而，未来导入的记录将不包括已删除的列(导入脚本可能会相应修改)。然而，在其他实施例中，源表中删除的列也可以从目标Hive表中删除。

此外，不同的模式变化可能需要不同类型的操作。例如：

·某些模式变化可能会导致目标模式的变化和导入脚本的重新生成(例如，添加列)

·某些模式变化可能会导致导入脚本的重新生成，但不会导致目标模式的变化(例如，删除上面示例中的一列)，反之亦然

·某些模式变化可能不会导致目标模式或导入脚本的变化(例如，列顺序的变化)

此外，系统可以被配置为针对特定类型的模式改变生成警报(即使不需要对目标模式和/或脚本进行改变)。

Sqoop生成器306从储存库310读取元数据，并在运行时为任何源生成Sqoop脚本。基于模板生成Sqoop脚本。优选地，系统保持多个Sqoop模板，每个模板适用于特定类型的源数据库系统。例如，可以分别为mySQL、Oracle和MS-SQL数据库提供不同的Sqoop模板。此外，对于每个数据库系统，为初始加载和增量加载处理提供了单独的模板(假设所讨论的数据库支持增量加载)。如果模式区分器304识别影响数据导入的模式变化，则Sqoop生成器306重新生成脚本并用重新生成的脚本替换旧脚本。

导入的数据使用适合所使用的存储技术的数据模式存储在数据湖中。数据湖模式生成器308通过从元数据储存库310读取模式元数据来为每个表生成数据湖模式。还响应于模式区分器发出的模式变化来演化数据湖模式。当修改现有模式时，经由归档处理312在归档目录中保持该模式的历史。

警报功能314提供生成与元数据生成器/模式演进处理202执行的处理相关的警报的工具。在一个实施例中，警报功能314生成以下输出：

·success_tables-这是成功完成元数据生成和模式演化处理的逗号分隔的表列表

·fail_tables-这是元数据生成或模式演化失败的逗号分隔的表列表

·index_change_tables-已改变唯一索引的逗号分隔的表列表(在继续数据导入之前，这种表可能需要手动干预来改变模式)

·add_column_tables-已添加列的逗号分隔的表列表

在优选实施例中，元数据生成器和模式演化处理在所有层(模块)提供可扩展的架构，例如，元数据生成器、模式区分器、Sqoop生成器、数据湖模式生成器和警报。

在图4中进一步示出元数据生成和模式演化处理的操作。

当触发元数据生成和模式演化处理时，元数据生成器302查询数据源102处的RDBMS系统，以收集一个或多个指定表的元数据。模式区分器304将收集的元数据与元数据储存库310中相同表的现有元数据进行比较。

如果没有为表找到现有元数据，则将被视为该表是第一次导入到数据湖中，并且信号发送到Sqoop生成器306和数据湖模式生成器308，以生成Sqoop脚本和数据湖模式(包括表信息文件以及初始加载和增量加载Hive查询语言(HQL)脚本)。一旦生成了所需的脚本，就存储在本地目录中(在配置数据中指定)，然后可以用来为表生成数据湖环境(即，表结构、目录结构和组成表的文件集合)。这些脚本也可以用来在Hadoop集群之间传输表。

如果为表找到现有元数据，则模式区分器304识别新表模式(如当前提取的元数据中定义的)和旧表模式(如存储在元数据储存库中的元数据定义的)之间的差值，并将变化应用于数据湖数据表示，根据需要重新生成脚本。出于调试目的，每次运行时，每个表的元数据都会存档在存档目录中。此外，如果识别模式差值，则捕捉模式演化历史。

导入脚本的生成和操作

在图5A和图5B中更详细地示出导入脚本的生成和操作。

图5A示出了元数据储存库310中来自数据源102的给定源表的一组元数据，用于生成各种脚本，例如，表创建502、Sqoop导入504和Hive导入506。执行脚本，以将模式变化和导入数据应用于数据湖108。

图5B示出了更详细的示例，其中，正在导入具有表名“TJ30T”和一组字段MANDT、STSMA、ESTAT、SPRAS、TXT04、TXT30和LTEXT的源表104。

元数据生成器和模式演化模块202从源读取表模式元数据，并生成以下脚本(脚本生成由图5B中的虚线示出)：

·HQL脚本510，包括一个或多个数据定义语言(DDL)语句，用于创建对应于Hadoop数据湖中的源表104的Hive表110

·Sqoop初始加载脚本512，用于执行源表的全部数据的初始加载

·Sqoop增量加载脚本516，用于从源表执行后续增量加载(即，用于加载自上次导入以来的一组差值，例如，以插入、更新或删除记录的形式)

·Hive初始加载脚本514，用于将初始加载的全表数据集存储到Hive表中

·Hive增量加载脚本518，用于将表增量(即，自上次导入以来的一组差值，例如，以插入、更新或删除记录的形式)存储到Hive表中

在元数据生成器/模式演化模块202的初始运行之后，运行Hive创建表脚本510，来创建Hive表110。然后，执行Sqoop初始加载脚本512，以将表的全表内容读入着陆区域208。在预处理之后(例如，通过如本文别处所述的重新排序/清洗处理)，执行Hive初始加载脚本514，以将由Sqoop初始加载脚本512获取的数据存储到Hive表110中。

对于表的后续导入(例如，这可以周期性地完成，例如，一天一次)，执行Sqoop增量加载脚本516，以获取自上次导入以来存储在着陆区域208中的表增量。在预处理之后，Hive增量加载脚本518然后将差值应用于Hive表110，例如，通过应用任何必要的插入、更新或删除操作。然而，在某些情况下(例如，如果由于不一致或失败而需要重新生成/恢复表)，可以运行初始加载脚本，而不是增量加载脚本，来将全表内容导入Hadoop数据湖。

因此，这些脚本一起构成了自动数据导入处理的一部分，该处理通过根据需要修改/再生各种脚本来响应于源数据模式的变化而动态地重新配置。

如前所述，系统保持每个RDBMS源类型的模板(例如，Oracle、Mysql、MS-sql等)，来启用Sqoop生成。结果，从存在模板的现有支持数据库导入额外表，不需要开发活动。为了支持新的源数据库系统，可以在代码中添加额外的模板，以能够生成初始和增量加载Sqoop脚本。

在下面的附录中列出系统生成的脚本示例(例如，参见提供的示例1-3)。在附录的示例6中显示了一个Sqoop模板的示例。

如果在随后的导入期间，元数据生成器/模式演化模块202识别影响如何从源数据库读取数据的源模式的变化，则根据需要重新生成Sqoop脚本512、516。此外，如果源中的变化需要改变Hive表结构，则Hive脚本514、518也根据需要重新生成，并且Hive表结构根据需要进行调整(例如，通过执行“ALTER TABLE”语句等)。

以下部分提供了如何处理不同源模式变化的信息。

添加列

例如，可以将列添加到源表中。假设该表最初具有图5B所示的结构：

随后，将以下列“COL1”添加到表中：

然后，系统在Hive表中创建额外列(例如，参见下面附录中的代码示例4)。此外，Sqoop和Hive脚本重新生成，以引用新列(例如，参见附录中的代码示例5)。

删除列

在删除源表模式中的列的情况下，脚本512、516、514和518类似地重新生成，以不再引用删除的列。虽然可以在Hive表中删除该列，但是在一个实施例中，该列保留但是被标记为不再使用。这允许保留历史数据并保持可用于分析/报告，但是未来导入的记录将不包含所讨论的列。

表的唯一索引变化

当添加一个或多个新键列时，新键列移动到Hive模式中最左边的位置，因为这对于映射化简代码的处理(例如，当执行如下所述的增量计算时)可能更有效，因为这种处理通常基于处理主键，因此只有前几列频繁解析，而不是整个记录。在一些实施例中，这种变化可以手动执行，尽管也可以替代地自动执行。

其他变化

优选实施例不基于数据类型相关信息的变化(例如，表列的数据类型的变化、列长度的变化等)来修改Hive表或导入脚本，因为默认情况下，所有数据都在导入处理中转换并作为字符串处理。然而，如果需要保留数据类型，则可以改变所描述的方法来适应这种情况，并自动检测和处理这种变化，例如，通过实现适当的类型转换。

差值计算器

本实施例允许以两种方式捕捉源表中的变化。首先，可以在源系统上实现变更数据捕捉解决方案来捕捉变化数据。这可以在源数据库环境中实现，以识别对数据表所做的变化，并将这些变化导出到数据挖掘导入工具。然而，在某些情况下，这种解决方案的复杂性可能是不合理的，和/或底层数据存储系统(例如，RDBMS)可能无法提供必要的功能。

因此，数据挖掘提供了差值计算器工具，以避免在源系统上实现如此昂贵的解决方案。

差值计算器的一些键特性包括：

·使用映射化简架构的可扩展/并行执行

·自动识别记录的DML类型

·提供故障时重新运行或从故障点重新开始的框架

·为新创建的分区自动创建Hive元数据

·易于使用，最大限度减少开发时间

只要能够在合适的时间范围内提取源数据，就可以使用差值计算器。因此，根据数据可用性要求，最好将该方法用于中小型数据集。

通常，可以根据给定应用程序上下文的特定数据量和性能要求来决定是使用差值计算器还是变更数据捕捉解决方案。例如，针对特定实现方式运行的基准表明，处理分布在大约600个表中的3TB数据，需要大约6个小时(将数据从源拉入湖中需要4个小时，通过差值计算器和历史捕捉处理需要2个小时)。在优选实施例中，如果表大小超过30GB，则在源位置执行增量处理。这不是一个硬性限制，而是基于存储大小和处理时间对Hadoop平台的影响。

在一个示例中，如果在Oracle数据库环境中在源处执行，则可以使用Oracle金门来处理增量，并且可以使用Oracle的大数据适配器将这些增量变化直接流式传输到Hadoop文件系统，其中，变化被存储在文件中。系统定期截取文件，然后使用Hive插入来更新Hadoop中的Hive表。在这种情况下，从源导入数据可能不需要Sqoop脚本。

另一方面，如果使用差值计算器(例如，对于小于30GB的表)，则使用Sqoop脚本(例如，脚本512)将整个表周期性地复制到HadoopHDFS文件系统，然后，差值计算器在复制的表数据上运行。

在一个实施例中，Sqoop和Oracle的大数据适配器都被配置为以字符串格式输出其文件，以使得解析更加容易。然而，在替代实施例中，这可以改变，使得在Sqoop和Oracle的大数据适配器中传递本地格式。

在图6A中示出差值计算器的架构。

如前所述，数据从数据源中的表读取到初始着陆区域208中。执行初始处理/清洗，并将预处理数据存储在暂存区域212中。差值计算器然后将表格数据与先前版本的表格(例如，最近导入的版本，其副本可由系统保持)进行比较，并识别任何差值。所识别的差值保存到着陆区域218，并作为输入提供给历史捕捉处理220(见图2)。

图6B示出了差值计算器处理的软件架构。使用推或拉传输模型将表数据读入暂存区域212(如前所述，如果需要，经由着陆区域和预处理)。使用映射化简算法以并行方式实现差值计算。为了支持这一点，可以提供“路径构建器”组件604，其用于构建目录路径名，以供实现差值计算器的映射化简代码使用，并包含数据源和表名。在此处，映射器606读取表信息并分离主键，并将其用作映射化简算法的数据键。添加识别数据源202的源指示符，并执行分区计算。化简器608迭代值，以识别记录是否存在于着陆区域中，并识别变化类型(通常对应于DML、数据操作语言、导致变化的语句)。因此，变化类型通常被标识为插入、更新或删除中的一个。例如，用记录键、变化类型和旧/新值(如果需要)存储变化。

逐行执行增量处理。系统保持整个源表的每日快照(例如，存储在Hadoop数据湖中)。将新导入的数据与表的最近一次快照(对应于差值计算器的最后一次运行时间)进行比较，以生成表的增量文件。

在一个实施例中，系统在Hadoop平台上保持15天的旧表快照。这是在一个实施例中采用30GB限制的一个原因以及处理两个30GB表之间的差值所花费的时间。然而，具体细节可能会因应用程序上下文和可用的处理/存储资源而异。

图7是示出差值计算处理的流程图。在表已经读入暂存区域之后，该处理开始于步骤702。在步骤704中，路径构建器组件构建输入路径流(以包含目录路径名的字符串形式，供映射化简代码使用)。在步骤706中，解析暂存区域中的记录，并且主键和辅键填充在映射器输出中(在一个示例中，在导入期间作为管理信息的一部分添加的时间戳用作辅键，差值计算器按主键然后按辅键对输出进行排序)。在步骤708中，系统检查给定的主键是否存在于数据湖中Hive表的当前版本(即，存储在OPEN数据库中)和暂存区域中。如果是，则导入版本的记录与缓存版本相比较(优选地比较每个列值)，并且如果识别出任何差值，则在步骤710中标记为更新。如果不是，则步骤712检查主键是否仅存在于暂存区域中(而不存在于Hive表中)。如果是，则该记录是新记录，并且在步骤714中被标记为插入。如果不是，则记录就存在于Hive表中，而不是暂存区中，因此是已删除的记录。在步骤716，该记录被标记为删除。

然后使用Hive插入将增量文件中的增量行插入Hadoop中的Hive表中，以获得标记为“插入”的任何更新。同样，Hive更新命令用于标记为“更新”的任何变化，以更新Hive表中的值，Hive删除命令用于删除标记为“已删除”的记录。

注意，这些变化发生在OPEN数据库中。如其他地方所述，历史捕捉处理定期(例如，每天)重新创建OPEN和CLOSED数据库。因此，删除的行不再出现在OPEN数据库中，而是保留在CLOSED数据库中(更新额外的时间戳相关列，以反映有效期和原因)。在某些情况下，可能不允许删除某些表的行。在这些情况下，行保留在OPEN数据库中，但被标记为“丢弃”。

图8示出了增量计算的示例。在此处，由增量计算器216处理多个表表A(802)至表N(804)。在每种情况下，主键列(或列组合)用作识别旧快照806(先前从数据源导入)和新快照808(当前从数据源导入)之间的差值的基础。例如，在这个示例中，列“col1”可以用作主键。增量计算器识别旧快照(具有旧列值)和新快照(具有新列值)之间的差值。在此处，对于表A，确定了以下差值：

·col1＝11的记录不再出现在新快照中

·col1＝12的记录在新快照中已修改

·col1＝15的记录新添加到新快照中

因此，对于每个识别出的差值，将条目添加到表A增量810，带有指示更新类型(更新/删除/插入)和新列值(对于更新和插入条目)或旧列值(对于删除条目)的标志。为剩余的表生成类似的增量(例如，表N的增量812)。

然后，包括标志和列值的生成的表增量用于更新相应的Hive表(例如，经由先前生成的Hive增量导入脚本)。

如前所述，增量计算处理优选地被实现为分布式映射化简算法(例如，在Hadoop集群中运行)，使其高度可扩展，并允许并行计算多个表的增量。该处理是可配置的和元数据驱动的(使用存储在元数据储存库312中的元数据)。

历史捕捉

通常，在从新数据源进行初始导入(经由初始加载脚本)并且在数据湖中为导入数据创建了相关结构之后，随后的更新递增地执行(根据需要使用增量加载脚本和差值计算器)，以捕捉数据源中的变化并将这些变化应用于数据湖(见图5B)。在一些实施例中，可以在特定基础上(例如，响应于操作员命令)或在预定基础上发生这种更新。在后一种情况下，每个数据源的更新计划可能不同。

然而，在一个优选实施例中，为了效率且为了确保一定程度的数据一致性，采用了一种定期更新所有数据源的协调的方法。用这种方法，定期执行增量加载，例如，每天从每个导入的数据源执行，并且相应地更新OPEN和CLOSED数据库。该定期更新由历史捕捉处理协调。

历史捕捉是一个间歇运行的处理，优选地，定期运行(例如，每天，例如，每天午夜)，以创建数据湖中当前稳定数据的快照。

在一个实施例中，历史捕捉处理被实现为用于更新两个主要操作数据库(即，OPEN和CLOSED)的Java映射化简程序。该处理使用来自每日增量处理的输出(例如，来自如上所述的数据挖掘差值计算器，或者来自源数据库提供的表增量，例如，经由Oracle金门/Oracle数据集成器馈送)。然后，确定应该插入、更新或删除哪些行，并每天为OPEN和CLOSED数据库创建一组新的数据库文件。作为该处理的一部分，每个表行都带有五列额外管理信息的时间戳，即：

·jrn_date-来自源系统数据库的时间戳(对于Oracle数据集成器馈送，这是来自源系统日志数据库；对于数据挖掘馈送，这是运行Sqoop导入脚本来复制源系统数据库的时间)；

·jrn_flag-指示记录是插入、更新还是删除

·tech_start_date-该行有效时的时间戳，即，历史捕捉插入或更新该新记录时的时间戳

·tech_end_date-该行有效时的时间戳，直到历史捕捉更新(覆盖)、删除或丢弃该旧记录时。在OPEN数据库中，所有行都设置为31/12/9999的高日期

·tech_closure_flag-删除旧记录的原因：更新、删除、丢弃

在一个优选实施例中，实际数据库(OPEN和CLOSED)都没有更新，相反，JavaM/R将为OPEN和CLOSED表重新创建新版本的数据库文件，每个表都更新了五个时间戳相关列，以反映行的有效期。

“tech_start_date”和“tech_end_date”列有效地描述了特定行当前的日期和时间。这些日期用于确保从源系统接收的当前版本存储在保存当前数据视图的OPEN数据库中。作为历史捕捉处理的一部分，当检测到任何更新/覆盖或删除时，旧行从OPEN数据库中删除，并使用适当的时间戳添加到CLOSED数据库中。

因此，在增量导入和历史捕捉处理完成后，更新的OPEN数据库将保持当前有效的数据集，该数据集包括来自各种导入数据源的数据，而CLOSED数据库将保存历史数据。

通过上述处理，源数据库中所做的变化会自动传播到数据湖。这既适用于给定表中包含的数据的变化，也适用于数据模式的变化。

例如，如果将一列添加到数据源中的表中，则只有记录因为添加而可能在数据源中具有该列的值，而其他记录则为该列保留“空”值。或者，可能已经为已有记录的列添加了值。在任一种情况下，空值或新值都将传播到数据湖中的OPEN数据库(该数据库将适当修改，以包括新列)。最新版本的源数据表随后在OPEN数据库中可用，任何以前的版本都将移动到CLOSED数据库中。CLOSED数据库将保留所有的数据湖历史，包括在某一特定日期进行变化之前的表格的样子。

注意，在某些情况下，源数据库可能已经包括历史信息(例如，通过保存在源表中的日期信息)。这种特定于应用程序的历史信息独立于历史捕捉处理捕捉的历史信息，并且将像任何其他源数据一样被系统(包括数据挖掘)处理。这样，数据湖中的消费者就可以以正常方式从开放数据库中获得这些信息。

通过相应地应用时间戳将旧版本移动到已关闭的数据库，历史捕捉处理响应源中任何信息的删除、覆盖或更新(无论该信息是否对应于源中的历史数据)。

表格分析器

回到图1，表格分析器工具107提供用于分析导入数据湖中的表格的数据内容的功能，以便识别表格之间的关系。通常，所识别的关系具有主键到外键关系的性质，即，一个表格中的主键和另一表格中的对应外键之间的关系。这种关系通常用于表示关系数据模式中的一对一和一对多实体关系(通常使用辅助映射表对多对多关系进行建模)。

在以下示例中，为了简单明了，通常假设候选键(无论是主键还是外键)对应于数据库表的单个列。然而，候选键可以替代地包括表格中的多列(例如，级联，以提供键值)。更一般地，键可以对应于以任何合适的方式从表格的一列或多列中导出的任何值。候选关系在多个候选键(通常但不一定来自不同的表格)之间定义，其中，候选键可以在相应的表格中执行主键或外键功能。表格分析器评估给定一组表格中的候选关系，以量化候选关系的强度(指示这些关系对应于实际关系的可能性)，并基于该评估识别可能的关系。

在图9中概括表格分析器为识别关系而执行的处理。表格分析器基于包括源表格901以及任何配置数据的一组输入文件904进行操作。

例如，当调用表格分析器时(例如，经由用户界面)，要为其识别关系的一组表格901可以由用户指定，作为脚本调用、配置文件或任何其他合适方式中的参数。如上所述，表格存储在数据湖108中。

数据映射器模块910(其包括并行执行的多个映射器)读取所有识别的表格的表数据。给定表由多行(对应于表中的记录)和多列(对应于这些记录中的单独数据字段)组成。记录中的每个数据字段可以包含数据值(根据某些数据格式，例如，字符串、整数、数据等)或可以(如果表定义允许)为空值，表示没有值存储在那里。

在步骤912中，生成映射表，其中，来自输入表的所有数据值映射到其源列位置。因此，生成的映射表包括一组条目，其中，每个条目指定出现在一个源表中的特定值以及识别从中读取该值的源表和列的信息。

在步骤914中，执行聚集，以聚集来自相同源列的相同值的映射表条目。每个聚集条目都会添加一个计数，该计数指示给定列中给定值的出现次数。然后根据数据值对表格进行排序。

在步骤916中，划分分类的信息，用于并行处理。结果，在步骤914中生成的聚集映射条目分成多个数据文件902，用于后续处理。

数据读取化简器模块920随后对数据文件902并行操作，以确定与输入表的列相关的统计信息。首先，在步骤922中，识别每列不同值的数量。在确定这一点时，同一数据值在一列中的重复出现(即，数据值在该列中出现在多行上)被计数为单个不同的值。在步骤924中，该处理识别具有共同数据值的多对列(即，出现在一列中的值也出现在该对的另一列中的某处)。这种数据值在本文称为列对的交叉数据值。在步骤926中，确定每个列对的不同相交值的数量(如上所述，此处，“不同”意味着相同共享值的多次出现被计数为单个不同相交值)。

数据读取减少化简器组件920的并行执行的结果组合到单个分析文件903中。因此，分析文件现在包含关于源列中的数据值以及相应列对中的相交值的统计信息。

基于该数据，在步骤932中，合并分析模块930为每个源列计算该列是其表的键列的概率。键列通常被认为是标识表格中特定记录的列。因此，当用作主键时，这样的列通常包括每个记录的唯一值，唯一地识别该记录。然而，应该注意的是，数据集可能是不完美的和/或包括重复，因此列可能不需要具有完全唯一的值，以被视为潜在的键列。因此，本方法将严格意义上的主键(其中，每个记录包括不同的识别键值)和具有大比例不同值的列视为候选键。

在步骤934中，该处理为源列的每个可能配对计算该对列呈现外键关系的概率。例如，这可以指示一个表中的特定列，其可以是该表的主键(例如，“客户”表中的客户标识符)，可以与另一表中的列相关(例如，“订单”表包括客户标识符，作为每个订单的外键)。

基于列是其相应表的键的相应概率(如步骤932中所确定的)和列之间的重叠或交叉程度(如下面更详细描述的)，来确定该概率，并且在本文称为列对的“组合概率”。列对的组合概率可以被视为表示列之间存在关系的置信水平，或者可以被理解为列之间的关系强度的指示。

在步骤936中，生成输出文件906，包括关于所识别的表关系的信息。分析组件可以基于强度对所识别的关系进行排序，并且可以基于关系的概率或强度(例如，强关系/弱关系/可能不存在关系)将列对另外分类成不同的关系类别，并且在输出文件中包括分类/排序信息。

所识别的关系可以例如用作在数据分析任务期间(例如，由分析模块112)执行的连接查询的基础，如稍后更详细描述的。

在该示例中，算法分成(至少在概念上)不同的组件或模块，包括数据映射器组件910；数据读取化简器组件920和合并分析组件930。然而，该算法可以以任何适当的方式构造。类似地，分成“步骤”是为了说明的目的，并且实际上，实现方式可以不同地构造处理，并且步骤的顺序可以变化。

在优选实施例中，映射器和化简器组件中的一个或两个可以并行化(多个映射器和化简器在Hadoop集群中并行操作)，优选地使用Hadoop映射化简架构实现为映射化简算法，而分析组件230作为单个处理操作。然而，应该注意的是，基本算法可以以任何适当的方式实现(包括以串行化的形式或可选的并行实现方式)。

处理示例

现在将使用具体示例更详细地描述上述分析处理。对于不同的处理阶段，图10-图14A示出了该示例中正在处理的数据。

图10示出了图9的步骤912，其中，数据值映射到其列位置，识别每个数据值的源表和列。

在该示例中，正在处理两个源表1002(“表1”)和1004(“表格2”)，每个源表包括三行(编号为1-3)和三列(标记为A-C)。注意，行和列的数量仅是示例性的，并且表格不需要具有相同数量的行或列。此外，列标签A-C是用于说明目的的任意标签(实际上，每个表将包括一组相应的命名列)。如前所述，每个表可以在HDFS中分成多个文件。因此，在映射阶段的这个初始步骤中，可以并行处理组成源表的文件(在使用Java映射简化和/或火花的这个实现方式中)。

对于每个选定的表，每行中每列的单独数据值都映射到其表和列位置。特殊值(录入，空值和其他预定义的异常值)作为异常来处理，在下面描述的计算中不被视为普通数据值。

优选地，在配置文件中定义异常，该配置文件指定了在处理中要忽略的值，以提高性能和准确性。除了忽略特定的值之外，可以忽略特定列(例如，基于检测到的列特征)。例如，该工具可以被配置为忽略仅包含单个值的列，因为这不会增加准确性并提高性能。另一示例是忽略作为数据挖掘吸引处理的一部分添加的管理数据列，因为这些列不是源数据的一部分，并且可能会扭曲结果。此外，对于某些数据源，发现一些列包含许多零，作为文本字符串；因此，在这种情况下，该工具可以被配置为忽略包含三个或更多零的任何列值。可以以任何合适的方式配置异常，例如，通过指定要排除的特定值或者通过提供可以被评估的表达式(或其他可执行代码)来确定给定值或列是否与异常匹配。

此外，为每列和每个表格捕捉某些概述数据，例如，忽略的数据量(例如，忽略的值的数量和/或忽略的数据字节的数量)。

映射记录在映射表1006中。映射表的主要部分1008包括出现在一个源表中的每个数据值的条目，在“值”列中指定数据值。从中读取值的表位置存储在位置(“Loc”)列中。在此处，位置由位置引用指定，该位置引用指示源表(表1“T1”或表格2“T2”)和从中读取数据值的表(A、B或C)中的列。因此，“T1A”表示表1中的列A，“T2C”表示表格2中的列C，依此类推。实际上，可以使用任何适当的编码或引用来识别每个值的源表和列。

在这个阶段，条目按照其被处理的顺序出现在表中(在此处，表1中逐行和从左到右，随后，表格2中也一样)，当读取每个数据值时，条目添加到映射表中。

此外，累积的统计存储在输出的部分1010和1012中。

部分1010包括列统计，为每个列指定(由其列代码识别)：

·该列中出现的非空值的数量(重复值单独计数；换言之，这是具有任何非空值的记录数，而不是不同值的计数)。定义为要忽略的异常的“空值”以外的值优选地也排除在该计数之外；

·该列中出现的空值数量(即，相应字段具有“空值”或未指定值的记录数量)；

·相关列中的值与异常匹配且在处理中忽略的记录数量。

部分1012包括每个表的表统计，指定表标识符、每个表处理的行数和忽略的行数。

除了上述数据之外，可以在部分1010和1012中收集其他累积的特定于列或特定于表的统计数据或概述信息。

在此处，所有部分1008、1010和1012的输出被描绘为包含在单个映射表1006内(在“类型”列中，条目由“值”、“列(col)”或“表”指示符区分，分别指示值数据、列统计和表统计的不同部分)。然而，在替代实施例中，不同的部分可以存储在不同的数据结构中。例如，值数据1008可以存储在主映射表中，统计1010/1012存储在一个或多个单独的数据结构中。此外，输出1006可以存储在单个文件中，或者可以分成多个文件。

虽然实际上示出了单个映射器输出，但是映射步骤通常由在相应的表或(对于分区表)相应的表分区上操作的多个映射器并行执行。每个映射器然后基于由该映射器处理的数据子集产生相应的映射表1006。

图11示出了图9的步骤914，其中，映射表条目聚集、计数和排序。

在该步骤中，再次处理在前一步骤中产生的每个映射表文件，优选地并行处理(在该实施方式中，使用Java映射化简和/或火花)。每个文件中的单独数据值按位置计数并排序。列和表概述数据在该步骤中不修改，而是简单地传递给这些聚集文件。

在图11中，表1006对应于上一步骤输出的映射表，表1100显示了处理后的映射表。可以看出，来自表1006的条目已经聚集在值和位置标识符字段上，因此聚集的表1100现在包括用于数据值和源列的每个不同组合的单个条目，并且添加了指示该值在该特定列中出现的次数的“计数”字段。例如，表1100中的行“1”表示值“0”在表1的列A(“T1A”)中出现两次。该表已按数据值(即，“值”字段的内容)排序。

图12示出了图9的步骤916，其中，来自前一步骤的输出分成多个数据集，用于并行处理。

划分文件，因此没有值键跨越多个文件。在一个优选的实现方式中，文件输出的数量大约是在阶段开始时输入的文件数量的10％，尽管这是可配置的。

在该示例中，聚集表1100(表示来自前一处理阶段的输出)分成两个文件1202和1204。文件1202包括来自表1100的条目1-6，而文件1204包括条目7-14。每个特定数据值的条目(记录在“值”列中)一起保存在输出的单个文件中，以便在下一阶段由相同的处理处理。概述数据基于Java映射化简分区分成输出文件(为了清楚起见，此处只显示了概述数据的最后一行，即，第22行)。

图13示出了计算列和列对的相关统计的图9的步骤922、924和926。

在该步骤中，由前一步骤输出的文件(在示例文件1202、1204中)优选地并行处理(在该实现方式中，使用Java映射化简和/或火花)。结果然后组合到分析文件1300中，在必要时聚集为单独文件计算的部分结果。

首先，通过对每个输入文件1202、1204中每个特定表列的条目数进行计数来确定出现在每个列中的不同值的数量。在这个示例中，列“T1C”在文件1202中有一个条目，在文件1204中有两个条目。由于每个条目对应一个不同的数据值，这意味着T1C列总共有三个不同的值。生成的分析文件1300包括原始源表中每列的条目(见分析文件1300中的条目1302)，每个条目包括列标识符和不同的值计数(“不同”字段)。

其次，为具有至少一个公共值的每一对可能的列计算不同相交值的数量。不同的相交值是出现在给定对的两列中的不同值(即，只有列之间的唯一值匹配被视为不同的相交)。因此，在本示例表中，“T1A”(表1列A)仅具有一个与“T1C”(表1列C)不同的相交值，即，值“0”，而“T1B”(表1列B)具有三个与“T2B”(表格2列B)不同的相交值，即，值“1”、“3”和“5”。

在一个实施例中，这些值可以通过循环输入文件1202、1204中的数据值来计算，并且对于“值”列中列出的每个数据值，确定共享该值的可能的列组合，并且为每个列组合增加计数器。例如，文件1202示出了值“1”出现在四列(T1A、T1B、T2A和T2B)中，并且这四列有六个唯一的列对(其中，排序不相关，即，<列1，列2>与<列2，列1>是相同的对，并且列不能与其自身配对)。因此，共同具有值“1”的六个可能对是<T1A、T1B>、<T1A、T2A>、<T1A、T2B>、<T1B、T2A>、<T1B、T2B>、<T2A、T2B>。因此，这些表对中每一个的计数器递增(在该步骤之前，对于每个可能的列组合，计数器初始化为零)。当生成最终输出1300时，来自相应文件1202、1204的单独处理处理的计数器然后聚集(求和)。在此处，文件1202示出了列对<T1B、T2B>(值“1”)的一个不同值，而文件1204示出了两个(“3”和“5”)，因此该列对的不同相交值的总数被确定为三个。

优选地，在输出中仅报告具有不同交叉数据值的成对列的唯一组合。没有相交值的列对优选地不包括在输出中。输出作为一组条目1304添加到输出文件1300中，每个列对的一行具有至少一个相交值(见行7-15)，每个条目识别列对和不同相交值的数量。

列和表概述数据1306继续传递到单个排序的输出文件，用于在最后阶段稍后分析(为了清楚起见，在此处仅再次示出行22)。再次，部分1302、1304和1306被示为单个文件的部分，但是可替换地，这些部分可以存储在单独的文件/数据结构中。

图14A示出了最终分析阶段(图9的步骤932、934和936)。

在这个最后阶段，处理在前一步骤中产生的单个分析文件1300。

计算任何给定列作为键的概率，并在本文称为键概率(KP)。在一个优选实施例中，这被计算为不同有效值的数量(不为空值并且由于其他原因(例如，基于定义的异常)不被忽略的值)除以列中非空有效值的总数(或者可替换地，除以列中行数的总数，即，包括空条目或无效条目)。因此，键概率给出了列中值的区别或分布的指示；具有许多重复值的列将具有低KP值，而具有很少重复的列将具有高KP值。对于真正的主键字段，列中的每个值都是不同的，因此不同值的数量将等于值的总数，因此KP将等于1。

在计算每一列的键KP后，每一个可能的列对将有两个与之相关联的键概率(每一列一个)。这些在本文称为该对的第一列的左键概率(LKP)以及该对的第二列的右键概率(RKP)。最大键概率(MKP)被识别为该对的LKP和RKP中的较大者。因此，MKP提供了该对的一列可能作为其表的主键列的可能性的指示。

对于每一列对，还计算该列对的不同相交数据值的数量与每一列内不同值的总数的相应比率。这些在本文称为左相交概率或LIP(不同相交值的数量除以该对的第一列中不同值的总数)和右相交概率或RIP(不同相交值的数量除以该对的第二列中不同值的总数)。然后，最大相交概率(MIP)被确定为LIP和RIP中的较大者。MIP提供包含在列对的相应列中的信息的重叠程度的指示，其中，高重叠可以被视为表示这些列之间的关系(例如，主键-外键关系)。在上述计算中，空值和其他定义的异常(无效值)优选地不计入“不同”值的任何计数中。

然后，基于MKP和MIP计算组合概率。在一个示例中，CP被计算为MKP和MIP的乘积，并且表示列之间存在的连接类型关系的组合概率(或者可替代地，CP可以被视为指示关系强度)。

在一个实施例中，仅当MKP和/或MIP值满足预定标准时，才执行CP的计算。标准可以用MKP和/或MIP的最小阈值来表示。低于阈值的列对被标记为不太可能呈现关系，并且不被进一步考虑(在一个示例中，MKP和MIP值低于0.1的对被标记为不太可能。)所应用的阈值和/或其他标准优选地在配置数据中指定。

注意，具体的计算是以示例的方式提供的，并且可以使用替代统计数据，或者各种指示符的计算可以根据需求、数据的性质和其他因素而变化。例如，可将CP计算为MKP和MIP的总和(可能加权)，或者MKP和MIP的最大值或最小值可用作CP。类似地，一方面是LKP和RKP，另一方面是LIP和RIP，可以以某种其他方式(例如，作为加权和)组合，以导出MKP/MIP值(而不是选择左值和右值的最大值)。

下面参考图14B概述了计算的统计数据，图14B示出了说明两列A和B的列值之间重叠的文氏图。在此处，“A”表示出现在列A中的一组不同的有效值(非空值且不排除)，而“b”表示列B的一组不同的有效值(非空值且不排除)。交集“c”表示一组唯一的相交值；即，列A和列B共有(同时出现在这两列中)的不同有效值。计算的统计如下：

·键概率(KP)是给定列的不同有效值的数量除以有效值/记录的总数；

·左键概率(LKP)是列A成为键的概率(即，为列A计算的KP值)；

·右键概率(RKP)是列B成为键的概率(即，为列B计算的KP值)；

·最大键概率(MKP)是LKP和RKP中的较大者；

·左相交概率(LIP)是不同有效相交值(c)与列A(即，集合A)中不同有效值总数的比率；

·右相交概率(RIP)是不同相交有效值(c)与列B(即，集合B)中不同有效值总数的比率；

·最大相交概率(MIP)是LIP和RIP中的较大者；

·组合概率(CP)是MKP和MIP的乘积。

然后基于CP对列对进行排序，该CP取0(低关系概率)到1(高关系概率)之间的值，以识别或多或少可能表现出关系的列对。可以为每个列对计算并存储指示列对相对于其他分析的列对的排序的排序值(例如，以排序顺序上升或下降的简单数字序列)。

注意，如上所述，可以仅针对满足特定标准的合格列对来计算CP，其他列被标记为不太可能的关系候选，后续处理(例如排序)仅针对合格列对来执行。

此外，对于每对不同的表(此处，只有两个输入表，所以只有一对)，可以确定表之间存在关系的可能性的指示符。在优选实施例中，这是基于表的列之间的最佳/最强列关系(最高CP值)。

计算的数据添加到输出文件1400。在本示例中，输出文件包括：

·具有表标识符的每个表的条目(第1-2行)；

·每个表列(第3-8行)的条目都与列标识符和为该列计算的键概率(KP)相关联；

·基于表之间的最强的列关系，可以可选地为一个或多个(或每个)表对(此处，唯一对是T1、T2)提供条目(行9)，给出键和相交概率以及指示关系强度的等级值。在一个实施例中，在这个阶段，输出中没有明确包含该信息，但是相关的表对是从表之间最强的列关系中推断出来的；

·可能存在关系的每一列对的条目(第10-13行)(例如，计算了CP)，具有计算的概率值和计算的等级值。在优选实施例中，存储所有中间计算度量(LKP、RKP、MKP、LIPRIP、MIP和CP)(尽管可替换地，可以仅保留一些数据)；

·每个列对的条目(第14-18行)被确定为不太可能显示出关系(例如，由于MKP和/或KIP值较低而没有计算出CP)，可选地具有上述其他计算出的度量；

·通过早期处理执行的概述数据(为清楚起见，仅显示最后一行)。

每个可能的列对本质上定义了候选关系，各种计算度量(尤其是CP值)指示候选关系的关系强度(例如，CP值越高，列之间的潜在关系越强)。最终输出文件因此识别列之间的关系的最可能候选项(包括统计和排序信息，以允许进一步评估关系)。

在图10-图14所示的示例中，表格分析器对两个输入表进行操作，但实际上，可以对任意数量的表进行操作(在处理能力限制内)，以识别输入表中任意列对之间的列关系。输入和输出文件的大小和数量也纯粹是示例性的。处理的数据量和并行化程度可以根据需求和可用的处理资源而变化。

上述方法能够识别输入表集中任意两列之间的关系，包括同一表的不同列之间的关系(因此，原则上，算法可以在单个输入表上运行)。这种关系可能是有用的，例如，在数据库优化中。

然而，或者，表格分析器可以约束为仅识别来自不同表的列之间的关系(即，候选关系将由包括来自一个表的一列和来自不同第二表格的第二列的列对限定)。这种关系对应于关系数据库模型中经常使用的主键与外键关系，以便在执行查询时连接不同的表。在这种情况下，来自同一表的列组合可以从考虑的候选关系集合中忽略，这可以减少处理负担。

所描述的算法依赖于来自不同数据源的表列之间的数据值的比较(因此对于相似的数据使用了不同的数据格式或表示)。在优选实施例中，数据挖掘工具106在导入到数据湖期间标准化数据格式。这可能涉及将所有数据转换为单个数据类型(通常是字符串)，优选地，不管源表示如何，都使用源数据类型的一致表示(例如，时间/日期值的一致字符串表示)。这种方法可以提高表格分析器正确识别匹配数据的能力。然而，或者(或额外)，数据转换或格式化也可以由表格分析器执行(例如，在初始读取/映射步骤912期间)，以确保数据值处于允许有效比较的一致数据类型和格式。

表格分析器的输出(如图14A中的输出表1400所示)可用于表中数据的后续分析。例如，来自不同来源的数据可以自动组合并进一步处理/分析。在一个特定应用中，表格分析器的输出数据可以用于对导入数据湖108的数据创建查询(见图1)。提供查询构建器工具113，来帮助创建这样的查询，并将在下面更详细地描述。

组合键和部分匹配的扩展

在以上示例中，定义了相应表的单独列之间的关系。这可以扩展到允许如下组合键。

图14C示出了示例表，其中，需要多个字段(列)来定义能够识别表的单个记录的唯一键。在此处，在表1中，字段ID1和ID2都需要唯一地标识行，而在表格2中，字段ID3、ID4和ID5都需要唯一地标识行。在字段的组合唯一地标识记录的情况下，列组合称为组合键。

在组合键的每个字段本身就是键的情况下，这种组合键也称为组合键。图14D显示了一个示例，其中，需要ID1、ID2和ID3列，以唯一识别表4中的行(因此充当该表的组合主键)，但是每一列也充当另一表的外键(参见标记为Rel1、Rel2、Rel3的关系)。图14E显示了另一示例，其中，ID5和ID6都需要唯一地标识表5中的一行，并且通过关系Rel5和Rel6与表6的相应列相关联。

将前面描述的算法应用于图14D的示例，该算法将在表1、2和3中将字段ID1、ID2和ID3识别为强主键候选，并且与表4中的字段ID1、ID2和ID3具有高比率的不同数据交集。因此，该算法将正确识别关系Rel1、Rel2和Rel3。

在图14E的示例中，上述算法将在表5和表6中将字段ID5和ID6识别为弱主键候选。为了解决这个问题，该算法可以扩展，以连接表(例如，表5)中的预期组合主键字字段，该表可以与另一表(在此处是表6)内的预期字段进行比较。原则上，对于穷举搜索，需要评估每个置换，因此为了提高性能，该算法优选地从级联处理中消除不太可能的组合主键候选。

组合主键候选减少如图14F所示。

组合键检测基于预期字段的串联，以便检查数据交集。为了提高效率和性能，不太可能的组合主键对优选地在级联之前忽略。

在本示例中，用100行分析候选键段，在候选键段中包含85个不同的值。有80次不同的值出现一次(即，是唯一的)。也有5次不同的值出现4次。在该示例中，列串联优选地只与包含四个或更多不同值的其他列一起执行，因为在另一字段中需要至少四个不同值，以使基于字段的组合键唯一。因此，不符合该要求的所有其他列都将忽略。

在消除不合适的字段之后，与其他表中的字段(或字段组合，也以类似的方式连接)相比，对于每个置换和数据交集，剩余的字段对连接。图14G显示了将字段ID5和ID6串联成一个组合键的示例。

然后，算法的剩余部分如前所述继续进行，使得能够为复合列组计算组合概率(CP)，因此，允许在图14E示例中识别关系Rel5/Rel6。在这个示例中，分析了两列的组合键；原则上，这可以扩展到任意数量的列的组合键，受包括执行时间在内的计算资源的实际限制。

作为进一步的扩展，算法(对于单列键和组合键)可以扩展，以满足部分匹配的字段，如图14H所示。在本示例中，增强数据交集检查，以检查一个字段中的数据子集包含在另一字段中。

因此，在这种情况下，不是将键列的全部内容视为关系的候选键，而是由截断版本的字段值形成候选键。更一般地，这可以扩展，以允许以任何适当的方式从表的一个或多个字段中导出表的候选键，包括通过字符串操作(例如，截断、资本化等)或通过数学操作(例如，值的舍入或缩放)。可以自动选择适当的操作(例如，将一个字段中的字符串截断到与另一潜在键字段的最大长度相同的长度)和/或可以由用户配置。这允许在具有相似数据的列之间识别关系，即使在列中没有以相同的方式编码数据。

累积关系学习

表格分析器可以在一组源表上重复运行(或者甚至在数据湖中的所有表上)。在这种情况下，表格分析器优选地可配置的，不重新分析先前运行中已经分析过的关系，而是只寻找新关系。例如，如果列已经添加到一个或多个表中，或者如果已经添加整个表，则表格分析器可以仅考虑涉及新列的候选关系(例如，仅添加的列/表之间的关系或者添加的列/表和先前存在的列/表之间的关系)。通过这种方式，建立潜在数据关系的累积视图，而无需全面分析所有可能的列组合。

元数据管理器工具

返回图1，元数据管理器工具109包括一组用户界面和工作流，允许用户输入、编辑和查看元数据，以便记载数据湖108中保存的数据，例如，定义特定表/表列的性质并指定列之间的关系。

在优选实施例中，由元数据管理器管理的元数据主要用于记载目的。该记载元数据应该与源数据库的配置元数据区分开来，例如，当将数据导入定义源数据库中数据结构的数据湖108时，数据挖掘工具从源数据库102读取的模式元数据。然而，原则上，元数据管理器可以对与存储在数据湖中的数据相关的任何形式的元数据进行操作，包括源模式元数据和/或其他配置元数据(例如，用于配置辅助系统)。

元数据管理工作流的高级概述如图15所示。

该处理从要为其收集元数据的一组对象开始，称为记载队列1500。“对象”是与数据库实体相关的元数据的容器，这些数据库实体与导入到数据湖中的数据相关联。可以为其收集元数据并在元数据管理器中表示为元数据对象的实体包括结构/功能数据库实体以及可以保存在源数据库或数据湖中或与源数据库或数据湖相关联的其他形式的信息。数据实体和相应的元数据对象的示例可以包括：

·源数据库；

·表格；

·示图；

·表格列；

·表格/表格列之间的关系；

·询问；

·报告；

·商业规则。

因此，元数据对象可以提供定义数据库表的目的和组织、表列的含义、查询的功能、报告的描述等信息。元数据的性质通常因对象而异。纯粹作为示例，提供报告描述的“报告”元数据对象，可以包括诸如所有者、目的、有效期、描述等元数据项。商业规则可以是纯文本定义和/或可以包括逻辑，也可以用于存储商业术语(例如，客户、家庭、销售)的一组定义。

注意，该列表纯粹是作为示例给出的，并且给定的实现方式可能不使用所有上述内容和/或可能使用其他对象类型。

元数据管理器工具很灵活，优选地允许用户或操作员创建其他类型的对象，将选定的元数据项分配给对象，然后确定哪些角色可以编辑，哪些角色可以批准这些对象/项。元数据对象也可以用于记载系统本身的配置，作为一个示例，数据挖掘工具的源连接设置可以作为对象添加到元数据管理器工具，具有元数据，例如，文本描述和所有者，用于以正常方式记载和批准。

在一个示例中，当执行导入时，数据挖掘工具可以直接在记载队列1500中为导入的数据对象自动创建条目。或者，导入的对象(例如，表和列)可以记录在单独的数据清单中，元数据管理器工具根据该清单创建记载队列。首先，记载队列中的对象用状态指示符标记，指示其正在“记载”的处理中。

记载定义处理1502然后用于收集和记录记载队列1500中的对象的元数据。主要经由使用记载界面的用户交互发生元数据的记录。然而，一些元数据可能会在导入期间或随后自动生成。

对象的记录元数据形成了该对象的“定义”。为其记录了定义(即，一项或多项元数据)的对象更新了其状态指示符，以将其标记为“已记载”。这些对象放置在批准队列1504中。

批准队列中的对象定义随后经历批准处理，其中，用户(通常是除了已经创建原始定义的用户之外的用户)审查记录的元数据，并且批准该定义(步骤1506)或者提出争议(步骤1510)。在此阶段，状态指示符设置为“正在批准”。一旦接收到对对象定义的批准，状态指示符变为“完成”，并且这些对象定义添加到整组定义1508。

如果审查用户不同意该定义或认为其包含错误，则遵循争议处理。争议对象定义添加到争议队列1512，状态指示符被设置为“争议”。然后审查该定义(例如，由第三用户)；如果审查用户拒绝争议(步骤1514)，则对象返回到批准队列1504，并且状态指示符重置为“正在批准”。如果审查用户同意争议(例如，用户认为记录的元数据中存在错误)，则对象返回到记载队列1500，并且其状态被重置为“正在记载”(步骤1516)。

记载队列1500、批准队列1504、争议队列1512和整组1508在此被呈现为逻辑实体，并且可以经由任何合适的数据结构来实现。在一个示例中，可以提供存储识别对象的条目的元数据数据库。数据库中的每个条目可以引用数据湖中的相关结构(例如，关系中涉及的表、列、列)或其他实体(例如，存储的查询)，并且可以与对象的元数据集和指示记载状态的状态指示符相关联。队列可以通过简单地检索具有特定状态的条目来动态确定。或者，队列可以表示为引用对象定义数据库条目的队列/列表数据结构。可以记录额外数据，例如，指示何时完成各种行动(记载、批准、争论等)并且为完成该动作的用户指定用户标识符的日期/时间戳。

下表1概述了对象的可能状态值：

表1

各种队列中的对象还可以分配给特定用户，从而形成(逻辑)用户特定的工作队列。记载定义、批准和争议处理由一组用户界面支持，允许用户输入和查看元数据并记录问题或顾虑。此外，提供工作流界面，以允许用户查看分配给其用于定义(1502)、批准(1506/1510)或争议解决(1514/1516)的对象，选择要处理的对象，并触发相应的处理。

图16提供了上述处理的替代表示。

首先，在步骤1600，数据对象被数据挖掘工具吸引到数据湖中。独立地(例如，在数据导入之前或之后)，在1602，定义元数据集策略，例如，为每种类型的对象指定：

·应该收集哪些元数据；

·哪些元数据项是强制性的；

·哪些用户应该记记载对象；

·需要哪些用户来批准对象定义。

在1604，系统将不完整的对象放入记载队列。在1606，对象元数据对记载角色中的那些个人开放，以供输入。这些角色特定于单独的元数据项。在1608，一旦记载了所有强制性元数据，系统将记载的对象放入批准队列，并锁定该对象，以供编辑。

在1610，元数据对处于批准角色的那些个人开放，以供批准。这些角色也是特定于单个元数据项的。在1612，一旦所有批准者都批准了所有元数据定义，对象就转换到“完成”状态(1614)，这意味着对象现在已经被批准使用。

在1616，如果批准者对定义提出异议，则系统将争议对象放入争议队列(1618)，并锁定该对象，以防止进一步批准。在1620，如果争议被拒绝，则系统将该对象传递回批准队列，并解锁该对象，以供批准。在1622，如果维持争议，则系统将该对象传递回记载队列，并解锁该对象进行编辑。

图17示出了用于显示工作队列的示例用户界面。该界面包括列出要输入元数据的对象的“未完成定义”部分1702、列出需要批准的数据对象的“未完成批准”部分1704和列出已经引起争议的数据对象的“未完成争议”部分1706。对于每个对象，对象的类型连同对象的名称(“实体”)一起指示(“类型”)。也识别父母对象和祖父母对象的名称(根据如下所述的相关分层“层”结构)。

虽然工作队列界面可以列出所有未完成的动作，但是更通常，工作队列可以特定于用户，列出分配给该用户的那些动作。然后，用户可以选择队列1702、1704、1706中的一个中的项目，以调用元数据输入、批准和争议处理的相关界面屏幕。

该界面还可以提供允许用户搜索特定对象的搜索功能。可以对对象名称、任何收集的对象元数据、对象状态等执行搜索(单独或组合)。在一个示例中，搜索结果可以在用户界面中呈现，显示对象类型、名称以及父母和/或祖父母信息，如图17所示，并允许用户选择要处理的对象(例如，根据状态启动元数据输入、批准或争议解决)。

在优选实施例中，元数据管理器工具保持对象的层次结构(例如，存储在树表示中)。可以通过检查界面来检查该层次结构，图18A示出了其简化示例。

在所示示例中，层次视图的最高级别1802表示不同类别的数据源。这些顶级实体在本文称为层次结构，并且是可配置的。每个层次结构都有许多子层，树显示可以展开和折叠，以便显示所需的部分。

在此处，显示了层次结构“操作数据存储”的展开视图。在这个层次结构中，第一层1804对应于不同的源数据库，在这个示例中，列出了已经导入到数据湖中的两个操作数据库。层次结构的下一层1806列出了从给定数据库导入的表；此处显示了从“客户关系管理”数据库导入的两个表，即，“CRM_CLIENT”和“CRM_ADDR”表。下一层1808列出了从给定表导入的组成字段或列。为每一列显示了各种信息，在该示例中，列名1810、键指示符(例如，私钥主键或外键FK)1812(如果适用/已知)和描述1814。该描述可以是作为元数据集处理的一部分获得的描述性标签。其他元数据当然也可以在此处显示。还可以显示指示元数据集状态的状态指示符(例如，使用上面表1中概述的状态值)。

用户可以与所显示的条目交互(例如，通过在每个条目旁边显示的一组按钮，未示出)，例如，调用特定数据对象的元数据输入、批准和争议功能，或者查看元数据集动作的历史(条目/批准/争议等)。还可以基于选定的表或列调用查询构建器工具(如下所述)，以便使用该表或列创建数据查询。

如上所述，层次结构是用户可配置的。图18B示出了一个配置屏幕的示例，在此处，用于配置“操作数据存储”层次结构。对于每个层次，用户可以指定一个或多个子层；在此处，定义了三个子层，即，“数据源”(即，源数据库)、“表”和“字段”(其中，字段对应于表列)。

层次结构的每一层对应于可以为其收集元数据的对象类型。因此，先前描述的元数据集和批准工作流可以应用于任何层的所有对象。

代替所描述的分层关系，系统可以替代地允许元数据对象使用基于图关系的更一般化的模型彼此关联，其中，任何对象可以与任何其他对象相关联。然后，可以相应地调整对象浏览界面，例如，允许显示元数据对象的图形。

元数据

对于每种类型的对象，对应于上面讨论的“层”，可以收集的元数据可以由系统的用户配置。具体地，用户可以定义任意数量的元数据项，并且可以进一步指定每个元数据项与哪个(哪些)对象类型相关。

在一个实施例中，由用户指定的定义元数据项的信息可以包括：

·姓名；

·标签；

·描述；

·占位符(一个值，当它为空时，将出现在元数据项的输入字段中)；

·数据类型(例如，元数据项是作为自由格式文本还是数字信息还是通过从选项列表中选择而输入的)；

·元数据项的一组预定义列表选项(如果元数据项限于一组特定的值，而不允许自由形式的文本输入)；

·元数据项适用的对象类型(对应于定义的层次结构中的层)；

·需要批准元数据项的用户类别；

·可以编辑元数据项的用户类别；

·指示是否需要元数据项的标志(强制)。

图19示出了用于指定元数据项的界面1900的示例截屏。该界面包括用于输入关于元数据项的各种信息的部分1902、用于指示元数据项适用的对象类型(或层)的部分1904、用于指示所需批准者(通过指定用户角色)的部分1906以及用于指示所允许的编辑用户(同样根据角色)的部分1908。在这种情况下，元数据项被命名为“lnformation_Security_Classification”，并被定义为适用于“字段”和“结果列”层(对象类型)。该特定对象将由“数据管理器”和“业务数据所有者”角色批准，并且可以由“开发人员”和“数据管理器”角色编辑。注意，为了清楚起见，在用户界面的简化描述中并未显示在实际实现方式中使用的所有输入字段和选项。

元数据输入和批准

图20示出了用于执行元数据输入和/或批准的用户界面2000的简化表示。该界面列出了一组元数据项2002，其适用于具有输入字段(根据元数据项的定义，输入字段可以是自由形式文本或数字输入字段、复选框、下拉列表选择字段或任何其他合适的输入字段)的所选对象的给定对象类型。为了清楚起见，只显示了少量的元数据项。

此外，该界面提供了一组按钮2004，用于执行各种动作，包括保存变化、批准元数据或提出争议。虽然为了简明起见，只显示了一个界面，但实际上，输入和批准可能有不同的界面。例如，元数据输入屏幕可以仅包括“取消”、“保存”和“保存并提交”按钮，而批准屏幕可以仅包括“取消”、“批准”和“争议”按钮。批准用户可以看到只读形式的元数据值，或者也能够在批准或重新提交之前进行编辑(在这种情况下，可以在该模式下提供所有按钮)。

按钮动作可能如下：

·取消：放弃变化并返回最后一个屏幕；

·保存：保存元数据变化，而不改变对象状态；

·保存并提交：保存元数据变化，并将状态从“正在记载”变为“正在批准”，结果，对象将添加到批准队列中；

·批准：确认审查用户的批准。如果所有必需的用户都已批准(或者只需要一个批准)，则这将导致对象状态变为“已记载”，否则状态保持为“正在批准”；

·争议：引发争议；可以显示另一界面，例如，作为弹出框，允许审查用户输入原因(例如，从一组预定义的原因中选择)以及详细的评论调解释(例如，指定在元数据中发现的任何错误)。

元数据输入/显示表单优选地是动态生成的。为此，在接收到对要记载的特定对象的选择之后(例如，经由图17所示的工作队列、图18A的层次显示或经由搜索)，系统识别对象类型(对应于层次层)，并从元数据项数据库中选择那些被定义为适用于该对象类型的元数据项。然后，生成带有相关元数据项的输入字段的形式。在数据库中创建定义(其可以是例如引用相关项目类型的多个元数据项记录的定义记录的形式)。用户保存变化后，输入的元数据项值存储在元数据数据库中对象的元数据记录中。

配置关系

在优选实施例中，元数据集工具还允许用户定义表之间的关系(或者更具体地，表列之间的关系)，和/或使用先前描述的相同元数据集处理通过元数据来记载关系。因此，在这样的实施例中，关系可以形成系统可以记载的额外类型的对象(除了数据源、表和字段/列之外)。然后，关系也可以在信息层次结构中表示(如图18A所示)，例如，作为“表”层之下的一层，或者可以单独列出和访问。

图21示出了用于查看、编辑和/或添加关系的简化用户界面2100。在这个示例中，假设用户已经选择了要检查关系的特定表。用户可以经由选择输入2102选择如何显示关系，例如，以文本或图形格式(在这种情况下，已经选择了图形视图)。然后，在视图区域2104中显示所选表格的关系；此处示出了涉及列2106和2108的单个关系(其中，列2108是另一表中的列)。标记的箭头2110和2112连接列的图示，并提供定义关系性质的描述性文本。

提供搜索功能2114，以允许定义新的关系。用户可以使用搜索功能来查找要为其定义关系的列，然后可以使用另一界面(未示出，例如，弹出窗口)来指定关于关系的信息，包括指示关系类型的标签。

经由界面描述和操纵的关系可以包括源数据中已知存在的关系(例如，如果关系信息是从源数据库中提取的)以及用户经由界面输入的那些关系。

此外，关系可以包括由表格分析器工具发现的关系，如上面更详细描述的(发现的关系的元数据对象可以自动添加到元数据管理器工具/记载队列)。可以在界面中指示关系的来源(例如，区分自动发现的关系)。

在优选实施例中，用户可以进一步选择关系来查看其元数据集状态和/或调用工作流来输入/编辑关系的元数据、批准/争议元数据定义、解决争议等，如上所述。关系的元数据集和批准优选地基本上如前面已经描述的那样操作。

历史

用户可以显示任何选定对象的元数据集处理的历史。历史可以显示为按时间顺序排列的列表，识别所做的元数据编辑和批准/争议/争议解决动作，指示日期/时间和完成动作的用户。历史列表可以显示对象的状态变化(即，根据表1的状态值和图15/16所示的处理识别对应于状态变化的事件)。

用户角色

该系统优选地实现基于角色的访问控制，用于限制特定用户对元数据对象的访问。在这种方法中，系统的用户可以分配到不同的角色。角色是可配置的。角色示例包括：

·开发人员；

·解决方案架构师；

·数据管理员；

·管理；

·用户；

·业务数据所有者。

用户的角色确定了用户可以在系统中采取的操作。例如，如前所述，元数据项可以指定可以编辑该项的用户角色以及需要批准特定项的角色。

系统还可以允许为每个角色定义SLA(服务级别协议)，指示处理对象(例如，记载或批准对象)的预期周转时间。这可以允许分析和报告，以检查元数据集处理是否有效运行。

该系统还可以提供报告功能，例如，显示单独用户、用户组(例如，特定角色)或所有用户在定义周期内的用户活动。在一个示例中，报告可以指示用户已经添加或编辑的对象定义的数量以及被批准和有争议的对象定义的数量。也可以随着时间的推移来概述活动，例如，以图表的形式。

因此，元数据管理器工具允许许多用户合作，创建与导入数据湖的数据对象相关的元数据定义。元数据管理处理也可以扩展到包括报告、商业规则以及组织处理的任何其他形式的信息。所描述的方法可以有许多好处，包括：

·可以为数据、商业规则、报告和其他信息实体创建商定的标准定义；

·信息系统的加速设计；

·支持最终用户对大型复杂数据的“自助”访问；

·捕捉的元数据记载可能有助于遵守法律法规；

·该系统支持众包或联合方法来收集和填充元数据信息。

数据湖同步

在优选实施例中，元数据管理器工具通过自动同步功能与数据湖和数据挖掘工具集成，允许元数据管理器保持Hadoop数据湖的内容的最新视图。

同步组件自动提供驻留在Hadoop平台上的数据结构、对象和相关技术元数据的细节。

随着新对象出现在Hadoop平台中，可以自动触发工作流，开始记载和分类与其相关的描述性元数据。随着时间的推移，这使单独用户和企业能够保持驻留在Hadoop平台上的整个大数据区的当前和历史视图。

同步处理如图22所示。在该示例中，数据湖(Hadoop平台)108被示出为包括多个Hadoop/Hive数据库，每个数据库来自多个数据源，并且包括对应于这些数据源的表格的数据。元数据储存库2210包含由元数据管理器工具管理的元数据对象和相关元数据，并且周期性地与Hadoop平台108上的数据结构同步。

捕捉处理2202用于收集当前驻留在Hadoop平台108上的数据结构和相关技术元数据(例如，模式元数据)的细节。随后的差值计算处理2204使用该信息，并将其与储存库2210中已经保存的数据结构和元数据进行比较。处理2204确定自上次执行以来结构和元数据的差值，并计算需要应用于储存库2210以使其保持最新的变化列表，并且这些存储为变化细节2205。

然后执行变化更新处理2206，以将所识别的变化应用于储存库2210。这些变化可以用储存库2210创建、更新或标记为删除的对象。变化处理还用所做的任何变化的细节来更新审计历史2212，从而保持随时间变化的完整列表。优选地，不在储存库2210中执行物理删除，以便保持先前活动和对象细节的完整历史，而是信息可以被标记为不再有效。

例如，如果新表已经导入Hadoop数据湖，则捕捉处理2202将从Hadoop获得该表及其组成列的描述(以Hive/Hadoop数据库的“技术”或模式元数据的形式)。差值计算处理将把这些识别为新实体，因为元数据储存库2210中不存在相应的记载元数据。变化更新处理2206然后可以在储存库中创建对应于数据湖中新实体的元数据对象，例如，表示新表的对象以及表示表的每一列的对象。然后，这些对象可以自动添加到记载队列1500，从而触发图15的记载工作流，以允许为新的数据库实体收集记载元数据。

查询构造器

数据储存库通常使用“写入模式”(早期绑定)方法构建。在将任何数据加载到平台之前，通常需要花费大量的时间和精力来设计其物理数据结构，以适应所有可能的数据消费方式。这是为了确保所有的数据维度都正确一致，并且所有的业务转换都包含正确的逻辑。这通常意味着业务和软件开发团队之间需要一个需求/解决方案设计周期。

在本系统的优选实施例中，使用“读取模式”(后期绑定)方法构建数据湖。这意味着数据直接加载到平台上(通过数据挖掘工具)，而不需要考虑如何使用数据。此时，根据用户的角色和权限，用户可以访问原始数据进行消费。这种方法可以提供更快的数据访问，并且需要更少的努力；然而，确实要求消费用户在构建新数据集和/或报告时，有效地将他们自己的模式构建到其查询中。“查询构建器”工具使用户能够创建、存储和记载这些查询，以便可以在单独的角色之间搜索和重用，同时利用元数据管理器工具保持的数据和表格分析器工具发现的关系。因此，随着时间的推移，知识得到了发展和演变，详细示出了数据是如何在源表/文件之间分布的以及如何组合/连接和选择/过滤数据，以产生有用的数据资产。

在传统方法中，数据仓库或类似系统的每个消费用户通常将彼此隔离地管理他们自己的查询，有可能使用不一致的逻辑和不同的数据，或者浪费时间和精力来复制已经存在的查询。

查询构建器工具113(见图1)试图解决这些困难中的一些，并提供了一种避免潜在的不一致逻辑、不同数据和重复的方法，以便节省时间和精力，并促进重用和最佳实践。

这是通过使保存的查询构造器查询可供其他用户使用来实现的，这取决于其角色和权限。

在优选实施例中，每个保存的查询在元数据管理器中表示为对象，遵循上述针对其他对象的相同元数据集/批准工作流。因此，查询将记载、批准并完全可搜索。

用户能够通过使用与元数据管理器的查询相关联的元数据，例如，通过搜索查询描述、键和/或主题区域，来搜索现有的经批准的查询。一旦找到特定的查询，用户可以按原样运行，或者(如果需要修改)在保存和运行修改后的查询之前克隆副本并编辑。

查询构造器工具还允许用户经由图形用户界面从头开始构建自己的查询。该工具使用户能够根据元数据管理器工具中包含的元数据从数据湖中存储的表中选择列，然后根据表格分析器工具识别的关系选择表连接。此外，用户能够指定额外标准，例如，过滤标准(例如，“哪里(WHERE)”限制)和分组/聚集标准(例如，“分组依据(GROUP BY)”、“计数(COUNT)”、“总和(SUM)”和“排序(SORT)”标准)。

在优选实施例中，查询构建器工具使用最佳方法在数据湖平台上直接执行查询，以提供最佳性能。这可能包括诸如火花、Java映射化简、TES和/或Hive等技术。

查询构建器工具允许用户选择数据湖108中的Hive表110来形成查询的基础。查询构建器工具然后可以基于手动定义的关系以及基于如上所述由表格分析器工具执行的关系发现处理的输出，来建议可能的连接类型关系。

在使用自动发现的关系的情况下，该工具优选地还指示关于可能关系的强度的信息，例如，先前计算的CP或等级。虽然表格分析器可以在为查询选择表格之后按需运行，但是出于性能原因，优选的是提前运行表格分析器(例如，每当新表或现有表的新数据导入到数据湖108中时)，使得关系信息在查询构造器中需要时可用。

然后，用户可以检查建议的关系、表元数据(可能还有表内容)，并为查询的构造选择适当的连接关系。

图23A和图23B中描绘了查询构建器工具的示例用户界面。图23A示出了查询构建器的界面2300，显示了用户为查询选择的两个表格2302和2304。这些表可能来自不同的数据源，因此表之间的关系可能不是先验已知的。该界面还提出了可能已经被表格分析器发现的表格之间的许多可能的关系2306(被示为连接相应表的相应列/字段名称的标记线)。关系强度的视觉指示(基于如上所述的由表格分析器计算的数据)是通过用于表示表格之间的连接的颜色和/或线宽来提供的，在此处，表格2302的CUSTID列和表格2304的CUSTID列之间的关系被识别为最强的关系。用户可能能够查看每个关系的更详细的关系信息，包括收集的元数据和/或由表格分析器计算的各种统计信息(例如，通过点击或悬停在界面中的关系上)。

例如，用户随后通过点击链接或标签来选择所需的关系。此时，可以显示第二屏幕2310(图23B)，以允许用户指定查询的额外参数，例如，要在查询输出中包括哪些列、查询标准以及要执行的任何分组/聚集/排序。

在定义查询之后，可以执行查询，以从数据湖中检索数据。在优选实施例中，基于用户输入，根据适当的数据查询语言，例如，HQL或SQL，生成查询语句或脚本。所生成的查询包括基于所选关系的表连接，即，在与该关系相关的表列上定义的连接(这可以通过例如添加WHERE语句或类似语句来完成，例如，“WHERET1.A＝T2.B，以定义表1列A和表2列B之间的连接条件)。连接类型(例如内/外和左/右/全连接等)可以由用户指定，或者可以使用默认的连接类型。

然后执行查询，例如，在Hadoop系统的情况下，将生成的HQL语句提交给Hive。Hive执行查询并将结果返回给查询构造器或其他相关组件(例如，数据分析组件112)。查询结果也可以传输到用户装置116(例如，个人计算机终端或移动装置)，以显示给用户，作为新表，存储在数据湖108中，或者传输到远程计算机系统，以供进一步处理。

除了直接执行之外，查询还可以保存在系统中，并在适当的情况下发布，以供其他用户使用。一旦查询添加到系统中，就可以由元数据管理器工具来处理(即，通过表示添加到元数据储存库中并经由如前所述的元数据集/批准处理来处理的查询的元数据对象)。

虽然图23A-图23B示出了具有两个表的相对简单的查询，但是可以构建更复杂的查询，包括两个以上的源表和/或多个连接关系。查询也可以通过嵌套来组合(例如，通过使用来自一个查询的查询输出，作为另一查询的输入，来代替源表)。

图24示出了可以利用查询构建器工具(由查询构建器用户界面支持，例如，如图23A-图23B所示)执行的各种处理。

首先，在步骤2402中，可以查看、浏览和/或搜索关于元数据储存库2210中保存的现有查询的信息，并且可以选择查询。

可以调用新的查询创建处理2404，并且可以包括以下说明性步骤：

·步骤2406：选择用于查询的数据，例如，选择要从中获得数据的特定表。该选择可以利用储存库2210中的表元数据来完成(例如，经由元数据搜索功能)；

·步骤2408：指定用作查询的表连接的表格之间的一种或多种关系，这些关系可以是预定义关系或由表格分析器找到的关系(在这种情况下，储存库2210中的关系元数据可以用于识别合适的关系)。或者，连接关系可以由用户明确指定；

·步骤2410：可以指定过滤和分类/聚集标准等；

·步骤2412：优选地生成查询输出的预览，以帮助用户验证正确的操作；

·步骤2414：保存查询(可选地，供其他用户重用)。

用户可以改变执行步骤的顺序，可以省略一些步骤，并且可以在完成后面的步骤之后在任何时候返回到前面的步骤，来修改查询定义。

可以为现有存储的查询调用查询克隆/编辑处理2416。在这种情况下，查询构造器根据存储的查询创建查询定义的副本，然后该处理可以包括以下说明性步骤：

·步骤2418：可以修改数据选择(例如，添加、移除或改变选定的源表)；

·步骤2420：可以修改连接(例如，通过改变用作表连接基础的关系)；

·步骤2422：可以改变分类/聚集和过滤标准；

·步骤2424：生成输出预览；

·步骤2426：保存编辑后的查询。

用户可以改变执行步骤的顺序，可以省略一些步骤，并且可以在完成后面的步骤之后在任何时候返回到前面的步骤，来修改查询定义。

记载和测试处理2428可以包括以下说明性步骤：

·步骤2430：为查询输入元数据；

·步骤2432：批准查询元数据(可以在元数据管理器工具中执行步骤2430和2432)；

·步骤2434：可以例如通过执行查询和检查结果来测试查询；

·步骤2436：可以调度查询，用于例如在特定时间和/或周期性地执行。对于计划的查询，系统随后根据指定的计划自动执行查询，存储结果，以供后续访问、查看和处理。

这些步骤可以以不同的顺序执行，并且并非所有步骤都必须执行(例如，调度可能仅适用于某些查询)。

系统架构

图25A示出了用于实现所述系统的高级软件架构(包括数据挖掘、表格分析器、元数据管理器和查询构建器工具)。

该系统基于数据湖108。这包括：分布式存储器2504，用于存储由数据挖掘工具从源数据库提取的表数据；以及数据库2502，用于存储管理数据，例如，包含由元数据管理器工具收集的元数据、用户数据和系统使用的其他数据的元数据储存库。

提供了用于与存储在分布式存储器2504和数据库2502中的信息交互的API(应用编程界面)2506。使用该API实现一组工作流处理2508，例如，实现数据挖掘数据吸引、表格分析器关系发现和元数据集/批准处理。客户端用户界面(Ul)2510处理用户交互。虽然可以提供独立的客户端应用程序，但是在优选实施例中，客户端Ul优选地实现为在浏览器中运行的网络应用程序。其他应用程序2512可以经由API 2506与系统集成。报告功能2514可以直接访问数据库2502或数据湖中的其他信息(尽管也可以通过对该API的扩展来访问该信息)。

元数据可以版本化的形式存储在数据库2502中，例如，允许撤销变化或检查变化的历史。

图25B示出了上述架构的具体示例。在此处，分布式存储器2504经由如上所述的Apache Hive HDFS来实现。数据库2502被实现为MySQL数据库。API 2506是基于Scalatra网络微框架实现的，客户端Ul 2510是使用AngularJS网络应用框架实现的。提供了QlikView报告解决方案2514。架构的一种变化如图25C所示，其中，Apache HBASE数据库用作数据库2502(可能驻留在Hadoop HDFS中)。

上述系统的各方面可以在一个或多个计算节点上实现，例如，硬件服务器集群。

图26示出了服务器节点2600的硬件/软件架构的示例，其可用于实现本文描述的方法和技术。

服务器包括一个或多个处理器2602以及易失性/随机存取存储器2606，用于存储临时数据和正在执行的软件代码。

提供网络界面2604，用于与其他系统组件(例如，Hadoop集群2620中的其他服务器，其中，服务器2600作为集群的一部分运行)和更宽的网络2622(例如，局域网和/或广域网，包括互联网)通信，例如，用于连接到数据源102、用户终端116和其他装置。

永久存储器2608(例如，以硬盘存储、光存储、固态存储等形式)永久存储用于执行各种功能的软件，包括以下中的一个或多个：用于将数据从数据源102导入数据湖108的数据挖掘模块106、用于使用上述方法识别表关系的表格分析器模块107、用于实现上述元数据集和批准处理的元数据管理器模块109、以及用于基于识别的关系创建和执行查询的查询构建器模块113。

永久存储器还包括其他服务器软件和数据(未示出)，例如，服务器操作系统。服务器将包括本领域技术人员已知的其他常规硬件和软件组件，并且这些组件通过数据总线互连(这实际上可以由若干不同的总线组成，例如，存储器总线和I/O总线)。

虽然作为示例，在图25A-图25C和图26中示出了特定的软件和硬件架构，但是可以使用任何合适的硬件/软件架构，并且可以使用任何合适的硬件、数据库、API和Ul技术。

此外，指示为独立的功能组件可以组合，反之亦然。虽然在该示例中，一系列不同的处理106、107、109和113被示出为在服务器上实现，但是实际上，这些处理可以分布在多个服务器上，例如，不同的服务器处理数据导入、表格分析和元数据集功能。因此，功能可以以任何合适的方式分布在任何数量的计算装置上。在优选实施例中，在适当的情况下，模块可以在Hadoop集群中的多个物理或虚拟服务器或计算节点上以并行方式操作(例如，使用Hadoop映射化简)，如已经针对表格分析器工具更详细阐述的。

数据湖108(图1)可以被实现为分布在Hadoop集群中的多个服务器上的持久存储(例如，以Hadoop分布式文件系统的形式)。这些服务器可以仅提供数据存储，或者可以将数据存储与任何前述处理功能相结合。

应当理解，上面已经纯粹通过示例的方式描述了本发明，并且可以在本发明的范围内对细节进行修改。

附录-脚本样本

样本1：下面是样本Sqoop脚本，用于为“TJ30T”源表104执行初始加载，如图5B所示：

source $1

sqoop import-Doraoop.jdbc.url.verbatim＝true-D

mapred.job.queue.name＝${queueName}-D

mapred.job.name＝TJ30T_SQOOP_INITIAL_LOAD-

Djava.security.egd-file：/dev/../dev/urandom-D

mapred.child.java.opt5＝″-

Djava.security.egd＝file：/dev/../dev/urandom″--direct--connect

jdbc：oracle：thin：@//${host_name}：${port_number}/${db_inst ance}--username${username}--password″${password}″--num-mappers${sqoopMappers}--hive-import--hive-overwrite--hive-delims-replacement″--null-string″--null-non-string″--table sourcedb.″TJ30T″--target-dir/user/hdp_batch/sourcedb//initial/crm/crm_tj30t--map-column-hive

MANDT＝STRING，STSMA＝STRING，ESTAT＝STRING，SPRAS＝STRING，TXT00＝STRING，TXT30＝STRING，LTEXT＝STRING--hive-table prod_landing_initial_area.crm_tj30t

样本2：下面是样本HQL脚本，用于在对应于图5B表的数据湖中创建Hive表：

样本3：下面是样本HQL脚本示例，用于执行Hive表初始加载：

USE ${hivevar：DATABASE}；

SET mapred.job.queue.name＝${hivevar：QUEUE_NAME}；

SET hive.merge.size.per.task＝100000000；

SET hive.merge.smallfiles.avgsize＝100000000；

SET hive.exec.parallel＝true；

SET hive.exec.parallel.thread.number＝50；

SET hive.exec.compress.output＝true；

SET

mapred.output.compression.codec＝org.apache.hadoop.io.compress.G

zipCodec；

SET mapred.output.compression.type＝BLOCK；

INSERT INTO TABLE crm_tj30t PARTITION

{tech_datestamp＝′${hivevar：DATESTAMP}′，tech_type＝′ORIGINAL′，

tech_num＝′${hivevar：NUM}′)SELECT′${hivevar：DATESTAMP}

00：00：00.0′as jrn_date，′ORIGINAL′as jrn_flag，NULL as

tech_closure_flag，NULL as tech_start_date，NULL as

tech_end_date，mandt，stsma，estat，spras，txt04，txt30，ltext

FROM${hivevar：INITIAL_DB}.crm_tj30t；

还将提供相应的Sqoop和Hive脚本，用于执行后续增量加载。

样本4：下面是样本HQL脚本，用于修改表定义，以添加列：

USE${hivevar：DATABASE}；

ALTER TABLE crm_tj30t ADD COLUMN(COL1 STRING)；

样本5：下面是样本更新的Sqoop脚本，用于导入修改后的表(初始加载；还将生成相应的修改后的增量加载脚本)：

source $1

sqoop import-D oraoop.jdbc.url.verbatim＝true-D

mapred.job.queue.name＝${queueName}-D

mapred.job.name＝TJ30T_SQOOP_INITIAL_LOAD-

Djava.security.egd＝file：/dev/../dev/urandom-D

mapred.child.java.opts＝″-

Djava.security.egd＝file：/dev/../dev/urandom″--direct--connect

jdbc：oracle：thin：@//S{host_name}：S{port_number}/${db_inst ance}--username ${username}--password″${password}″--num-mappers ${sqoopMappers}--hive-import--hive-overwrite--hive-delims-replacement″--null-string″--null-non-string″--table SAPCRM.″TJ30T″--target-dir/user/hdp_batch/sapcrm//initial/crm/crm_tj30t--map-column-hive

MANDT＝STRING，STSMA＝STRING，ESTAT＝STRING，SPRAS＝STRING，TXT04＝STRING，TXT30＝STRING，LTEXT＝STRING，CoL1＝STRING--hive-table prod_landing_initial_area.crm_tj30t

也可以根据需要生成相应的修改后的HQL初始/增量加载脚本。

样本6：下面是样本Sqoop模板。

该模板包括使用相关参数调用Sqoop工具，包括用于从源数据库检索所需数据的嵌入式数据库查询(此处为SQL)。模板包含格式为${variable_name}的占位符变量。这些占位符变量在脚本生成处理中用适用的值替换。例如，${sqoop_table_name}被相关的表名替换，${sqoop_col_str_tmp}被导入的列列表替换。可以用类似的方式构建Hive模板。

Claims (26)

1.一种识别数据表格之间的关系的计算机实现的方法，每个所述数据表格包括多个数据记录，所述方法包括：

评估多个候选关系，每个所述候选关系在与第一数据表格相关联的第一数据列和与第二数据表格相关联的第二数据列之间被定义，所述评估包括计算每个所述候选关系的关系度量，其中，所述候选关系的关系度量提供第一列和第二列之间的关系的度量，所述计算包括：

计算指示所述第一列和所述第二列中的至少一个的值的差异度的第一度量；

计算指示所述第一列的值和所述第二列的值之间重叠的度量的第二度量；

所述方法还包括根据所计算的所述关系度量来识别所述数据表格之间的一种或多种关系；

其中，所述方法通过多个处理阶段来执行，所述多个处理阶段包括：

第一处理阶段，包括将出现在所述数据表格中的值映射到数据值的列位置；

第二处理阶段，包括计算相应列的不同数据值的数量和相应列对的不同相交值的数量，所述第二处理阶段包括并行处理映射表格的多个分区；以及

第三处理阶段，包括基于所述第二处理阶段的输出计算关系指示符。

2.根据权利要求1所述的方法，包括计算一个或多个所述候选关系的关系指示符，其中，所述候选关系的关系指示符指示形成所述候选关系的列之间的关系的强度或存在关系的可能性，并且所述候选关系的关系指示符是基于所述候选关系的第一度量和第二度量来计算的。

3.根据权利要求1或2所述的方法，其中，所述第一度量包括指示所述第一列或第二列是其数据集的主键的概率的键概率指示符。

4.根据权利要求3所述的方法，其中，计算键概率指示符包括：

为所述第一列和所述第二列计算指示相应的列是其数据集的主键的概率的相应的第一概率指示符和第二概率指示符，并且

基于所述第一概率指示符和所述第二概率指示符确定所述候选关系的键概率指示符。

5.根据权利要求4所述的方法，包括将所述候选关系的键概率计算为所述第一概率指示符和所述第二概率指示符中的较大者。

6.根据权利要求3所述的方法，包括基于所述列的不同值的数量与所述列的值的总数之间的比率，确定所述列定义其数据集的主键的概率。

7.根据权利要求3所述的方法，其中，所述第二度量包括指示所述第一列和所述第二列的值之间的相交程度的相交指示符。

8.根据权利要求7所述的方法，其中，计算所述相交指示符包括：

计算所述第一列和所述第二列之间的不同相交值的数量，其中，所述相交值是出现在所述第一列和所述第二列两者中的值；

基于所述不同相交值的数量和所述第一列或所述第二列的不同值的总数之间的比率来计算所述候选关系的相交指示符。

9.根据权利要求8所述的方法，包括：

计算所述不同相交值的数量和所述第一列的不同值的总数之间的第一比率；

计算所述不同相交值的数量和所述第二列的不同值的总数之间的第二比率；并且

根据所述第一比率和所述第二比率计算所述相交指示符。

10.根据权利要求9所述的方法，包括将所述相交指示符计算为所述第一比率和所述第二比率中的较大者。

11.根据权利要求7所述的方法，包括基于所述键概率指示符和所述相交指示符的乘积来计算所述候选关系的关系指示符。

12.根据权利要求1所述的方法，其中，识别一种或多种关系，包括响应于所述候选关系的所述第一度量、所述第二度量和所述关系指示符中的一个或多个超过相应预定阈值来识别相应数据表格的列之间的存在关系的可能性。

13.根据权利要求1所述的方法，包括：将多个所述候选关系根据它们的关系指示符进行排序，和/或将排序值与所述候选关系相关联。

14.根据权利要求1所述的方法，识别步骤包括：生成输出数据集合，所述输出数据集合包括识别一个或多个识别的关系的信息，输出数据包括所计算的关系指示符、度量和/或排序。

15.根据权利要求1所述的方法，其中，所述第一处理阶段还包括以下中的一个或多个：对所映射的数据值进行聚集、分类和划分。

16.根据权利要求1所述的方法，其中，所述第一处理阶段、所述第二处理阶段和所述第三处理阶段中的一个或多个由并行操作的多个计算节点执行。

17.根据权利要求1所述的方法，通过映射化简算法实现所述方法，其中，使用映射操作来实现所述第一处理阶段，通过化简操作来实现所述第二处理阶段。

18.根据权利要求1所述的方法，包括：在和/或执行数据查询时使用所识别的至少一种关系来从一个或多个数据表格检索数据，所述数据查询指定在所述数据表格的相应键之间定义的连接，所述键对应于其间定义所述关系的列。

19.根据权利要求18所述的方法，其中，所述数据查询指定所选表格之间的连接，所述连接相对于与所选关系相关的列来定义。

20.根据权利要求18或19所述的方法，其中，所述数据查询包括数据查询语言语句，其中，所述查询语言语句是SQL(结构化查询语言)或HQL(Hive查询语言)语句。

21.根据权利要求18或19所述的方法，包括执行所述查询，以从数据表格检索数据，并且可选地存储查询输出和/或向用户装置发送所述查询输出。

22.一种数据处理系统，包括：

数据存储器，用于存储数据表格；以及

表格分析器模块，被配置为：

为多个键对中的每一个计算关系指示符，每个所述键对包括从一个或多个数据表格选择的相应的第一候选键和第二候选键，其中，所述关系指示符包括所述第一候选键的数据和所述第二候选键的数据之间的关系的度量；所述关系指示符基于所述第一候选键和所述第二候选键中的至少一个的不同值的度量和/或基于所述第一候选键的值和所述第二候选键的值之间的重叠的度量来计算；并且

根据所计算的关系指示符，输出指定数据表格的候选键之间的一种或多种关系的数据；

其中，所述表格分析器模块被配置为以多个处理阶段进行操作，所述多个处理阶段包括：

第一处理阶段，包括将出现在所述数据表格中的值映射到数据值的列位置；

第二处理阶段，包括计算相应列的不同数据值的数量和相应列对的不同相交值的数量，所述第二处理阶段包括并行处理映射表格的多个分区；以及

第三处理阶段，包括基于所述第二处理阶段的输出计算关系指示符。

23.根据权利要求22所述的系统，还包括查询模块，被配置为使用在输出数据中指定的关系，创建和/或执行对数据表格的数据查询。

24.根据权利要求22或23所述的系统，被配置为执行根据权利要求1至21中任一项所述的方法。

25.一种系统或设备，具有以使处理器与存储器相关联的形式执行根据权利要求1至21中任一项所述的方法的装置。

26.一种包括软件代码的计算机可读介质，当在数据处理设备上执行时，所述软件代码适于执行根据权利要求1至21中任一项所述的方法。