CN110651265A - 数据复制系统 - Google Patents

Abstract

公开了一种数据复制系统，包括被配置为在第一数据储存库运行的变化事件检测模块和被配置为在第二数据储存库运行的变化事件实现模块。还提供了一种被配置为根据消息订阅传输接收到的消息的消息服务。事件检测模块被配置为检测对第一数据储存库所做的变化，并将变化事件消息传输到消息服务。事件实现模块被配置为在消息服务处订阅变化事件消息，并且响应于接收到变化事件消息，在第二数据储存库实现变化事件。

Description

数据复制系统

技术领域

本发明涉及用于在不同数据存储系统之间复制数据的系统和方法。

背景技术

组织管理越来越大的数据量。一种替代方法是将数据汇集到大规模的数据储存库中，有时也称为数据仓库或数据湖，而不是依赖于许多单独的传统数据库(例如，关系数据库)。通常需要在另一位置维护来自这种数据仓库的数据副本。这可能是为了数据安全和灾难恢复，但也是为了允许不同系统(例如，操作和分析系统)访问，而这些系统不会中断彼此的操作。然而，许多大规模数据仓库解决方案中采用的相当自由、非结构化的数据存储方法在实现数据复制时带来了挑战。所涉及的数据量也可能非常大，并且因此数据提取和传输过程可能会影响任何一个数据存储的操作(这可能会有问题，尤其是如果源数据支持具有高交易量的组织的操作)。一种常见的方法是在安静的时间(例如，夜间)以相对不频繁的批处理方式复制数据。然而，这意味着目标数据存储(例如，可以支持分析和报告功能)通常不是完全最新的，仅提供特定时间点的数据的近似历史视图。此外，现有的数据复制工具通常在功能上受到限制，并且不一定允许源数据存储的所有必需方面高效地复制到目标数据存储。例如，虽然基于Apache Hadoop的存储集群上可用的“distcp”分布式复制工具可用于执行基本的复制操作，但这仅在文件级别操作，并且因此比实时数据复制更适合于计划的批量复制操作。

发明内容

本发明力图减轻已知数据复制方法的一些问题。

在本发明的第一方面，提供了一种在目标数据储存库处复制对源数据储存库所做的变化的方法，该方法包括在目标数据储存库处：接收变化事件消息，包括指定在源数据储存库处检测到的数据变化事件的信息，所述数据变化事件包括写入源数据储存库的一个或多个数据值；响应于变化事件消息，向源数据储存库发送对一个或多个数据值的请求；从源数据储存库接收一个或多个数据值；并且基于所接收的数据值更新存储在目标数据储存库中的数据。

这种方法允许将源储存库中所做的变化的通知与修改数据的检索分开，从而提高效率和可靠性。一个或多个数据值可以包括写入源储存库的新数据(例如，插入数据表的行或附加到文件的数据)，或者可以包括替换现有数据值的修改后的数据值(例如，数据表的行更新或覆盖文件中现有数据的数据)。该请求可以是特定的并且仅针对新的/修改的数据值的请求，和/或作为响应，可以仅传输/接收新的/修改的数据值(例如，修改行中的特定字段值)。可选地，可以请求和/或响应于该请求传输/接收包括新的/修改的数据值的更大的数据单元。例如，对于行插入或行更新，可以请求/传输整行，或者可以请求/传输包含包括新的/修改的数据值(例如，包含多个表行)的表数据的整个文件。对于文件更新，可以请求/传输整个文件或其相关部分。

该消息优选地指定在源数据储存库处执行的操作。该操作可以包括插入操作和更新操作中的一个(例如，用于插入或更新数据表中的一行或多行)。该操作还可以包括文件创建/更新/附加操作。

优选地，消息不包括一个或多个数据值。因此，该消息可以指定所执行的操作的类型和/或识别修改的数据，而不包括修改的数据。优选地，该消息包括允许识别一个或多个数据值的识别信息，该请求包括识别信息(例如，行或文件标识符)。

该消息优选地经由消息服务接收。这种消息服务优选地被设置为从一个或多个消息源接收消息，并将接收到的消息传送到一个或多个消息目的地，其中，消息目的地已经注册了对消息的兴趣(即订阅)。因此，该方法可以包括由目标数据储存库订阅来自消息服务的变化事件消息。

优选地，该方法包括在源数据储存库处：检测变化事件；并且基于检测到的变化事件输出变化事件消息。输出步骤可以包括向消息服务发送变化事件消息。

检测变化事件优选地包括监视或检查与源数据储存库相关联的变化日志。变化日志优选地是记录对源数据储存库所做的变化的数据结构(例如，如下文进一步讨论的HDFS编辑日志或Hive通知表)。优选地周期性地(例如，以可配置的频率)或响应于触发来执行检查。

更新步骤优选地包括修改目标储存库处的数据，以复制目标储存库处的变化事件。复制可以涉及以与源储存库相同的方式修改目标储存库(例如，通过将新的或修改的数据值存储在目标储存库的相应表、文件或其他数据结构中)。可选地或另外，可以执行额外处理，例如，在存储在目标储存库中之前预处理或修改所接收的数据值。

发送请求和接收一个或多个数据值的步骤可以包括将包括一个或多个数据值的文件从源数据储存库传输到目标数据储存库。数据变化事件可以包括在源储存库处创建或修改文件，在这种情况下，接收步骤可以包括从源储存库接收所创建或修改的文件的副本。数据变化事件可以包括插入或更新数据库表中的一行或多行，并且优选地，其中，接收步骤包括接收一行或多行或者接收存储数据库表的插入或更新数据(例如，行或列)的一个或多个文件的副本。

在本发明的另一方面(其可以与上述方面相结合)，提供了一种在目标数据储存库处复制对源数据储存库所做的变化的方法，该方法包括在目标数据储存库处：接收变化事件消息，包括指定在源数据储存库检测到的数据变化事件的信息；并且根据变化事件消息更新目标数据储存库；其中，数据变化事件包括数据内容变化和数据结构变化，该方法包括：响应于指定数据内容变化的变化事件消息，基于变化事件消息更新目标数据储存库中的数据；并且响应于指定数据结构变化的变化事件消息，在目标数据储存库处实现数据结构变化。

通过这种方式，数据内容变化和数据结构变化都可以经由通用机制来复制。数据内容变化可以包括添加到源储存库中、在源储存库中更新和/或从源储存库中删除的数据。对于存储在数据表中的数据，这可能涉及向表中添加一行或多行、更新一行或多行或删除一行或多行。对于存储在文件中的数据，这可能涉及写入或附加到数据文件。数据结构变化可以包括模型变化(例如，通过对定义数据模型的元数据的变化)。对于存储在数据表中的数据，这可能涉及向表中添加列或从表中删除列、改变列定义(例如，数据类型、长度等)、创建或删除表、视图或分区、索引变化等。

因此，在变化事件消息指定源储存库处的表定义的变化的情况下，实现数据结构变化可以包括修改目标储存库中的表定义，以将相应的变化应用于目标储存库的表。在变化事件消息指定在源储存库处创建或删除表的情况下，实现数据结构变化可以包括在目标数据储存库处创建或删除相应的表。

另一方面，响应于指定数据内容变化的变化事件消息，相应的数据变化可以应用于目标数据储存库。这优选地涉及执行如上所述的方法(例如，根据本发明的第一方面)。

在可与上述任一方面相结合的另一方面，本发明提供了一种在目标数据储存库处复制对源数据储存库所做的变化的方法，该方法包括在目标数据储存库处：接收变化事件消息，包括指定在源数据储存库检测到的数据变化事件的信息；基于变化事件消息，确定数据变化事件包括写入源数据储存库的新的或更新的数据，新的或更新的数据不包括在变化事件消息中；响应于该确定，从源数据储存库检索新的或更新的数据；并且基于检索到的数据和变化事件消息更新存储在目标数据储存库中的数据。

根据该方面的方法可以包括任何前述方面的任何进一步步骤或特征。

以下特征可以另外提供有任何上述方面。

源和/或目标数据储存库可以包括非结构化的数据储存库或灵活结构化的数据储存库，例如，数据仓库或数据湖。优选地，源和目标数据储存库中的至少一个(可选地两者)包括分布式数据存储集群，优选地基于Apache Hadoop和/或Apache Hive。

在使用Apache Hive或类似的数据抽象层实现源储存库的情况下，该方法可以包括复制Hive元数据变化，其中，变化事件消息涉及Hive表的创建或Hive表定义的修改，更新步骤优选地包括将相应的变化应用于目标数据储存库处的数据结构(例如，相应的Hive表)。可选地或另外，该方法可以包括复制Hive表数据变化，其中，变化事件消息涉及Hive表中一行或多行的插入、删除或更新，更新步骤包括基于所接收的数据值将相应的变化应用于目标储存库中的Hive表。

在另一方面，本发明提供了一种系统，该系统具有用于执行本文所述的任何方法的装置。本发明还提供了一种包括软件代码的计算机可读介质，当在数据处理设备上执行时，该软件代码适于执行本文所述的任何方法。

在本发明的另一方面，提供了一种数据复制系统，包括：变化事件检测子系统，其被配置为在源数据储存库处运行；变化事件实现子系统，其被配置为在目标数据储存库运行；以及消息服务，其被配置为根据消息订阅传输所接收的消息；其中，变化事件检测子系统被配置为检测对源数据储存库做出的变化，并将变化事件消息传输到消息服务；并且其中，变化事件实现子系统被配置为：订阅消息服务中的变化事件消息；并且响应于接收到变化事件消息，在目标数据储存库实现变化事件。

消息服务或系统的使用可以允许高效、灵活和可动态配置地传输复制信息，从而允许高效地实现各种复制场景。

例如，该系统可以包括多个目标数据储存库，每个目标数据储存库包括相应的变化事件实现子系统，每个变化事件实现子系统适于订阅来自源数据储存库的变化事件消息，并在相应的目标数据储存库处实现相应的变化事件。

可选地或另外，该系统可以包括多个源数据储存库，每个源数据储存库包括相应的变化事件检测子系统，变化事件子系统适于将变化事件消息传输到与相应的源数据储存库处的变化事件相对应的消息服务。来自多个源数据储存库的变化事件消息优选地由消息服务转发到至少一个目标数据储存库，用于在至少一个目标数据储存库处复制变化事件。

变化事件实现子系统可以被配置为过滤所接收的消息和/或在目标储存库处复制变化事件的选定子集。变化事件实现子系统可以适于响应于接收到对应于写入源数据储存库的新的或修改的数据的变化事件消息，从源数据储存库检索新的或修改的数据的至少一部分(或全部)，优选地，其中，新的或修改的数据的至少一部分不包括在变化事件消息中。因此，虽然可以经由消息服务将变化事件推送到目标储存库，但是目标储存库的实现子系统可以响应于变化事件从源储存库中提取数据内容(例如，新的/修改的数据值)。

数据复制系统优选适于执行本文所述的任何方法(例如，根据本发明的任何前述方面)。

本文使用的术语“行”通常指存储在数据表中的数据单元，通常包括一个或多个字段值(其中，字段对应于表的列)，这些字段值一起形成表的条目。行也可以称为记录(具有字段)或数据对象(具有属性)。注意，在基于列的数据存储中，可以逐列地存储和处理数据，并且因此本文讨论的涉及行传输(例如，用于复制数据变化)的任何机制可以适于传输数据的列(或其部分，例如，列分区)。术语“行”和“列”因此可以互换使用，除非上下文另有要求。

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

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

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

附图说明

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

图1概述了数据复制系统；

图2示出了数据复制系统的架构；

图3示出了数据复制系统的操作；

图4示出了数据复制过程；

图5示出了可用于执行所描述的复制过程的处理节点的硬件/软件架构；

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

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

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

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

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

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

图11示出了表差值计算器的操作；以及

图12示出了表差计算的示例。

具体实施方式

本发明的实施例提供了用于在大规模非结构化或灵活结构化数据储存库之间复制数据的系统和方法。这种数据复制系统如图1所示。

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

数据复制系统包括源数据储存库110、目标数据储存库130和复制系统120。

数据储存库110、130通常是通常称为“数据湖”或“数据仓库”类型的大型数据储存库，并且可以包括任何数据存储技术。优选地，数据储存库允许以非结构化或灵活结构化的方式存储数据。例如，这样的储存库可能不需要固定或预定义的数据模式。每个储存库可以是(或可以包括)NoSQL数据库或其他非关系数据库，例如，将数据存储为“文档”数据对象(例如，JSON文档)的面向文档的数据库、键值存储、面向列的数据库、存储平面文件的文件系统或任何其他合适的数据存储或以上任何内容的组合。然而，在其他实施例中，数据储存库可以替代地包括传统的结构化数据库，例如，关系数据库或对象数据库。储存库110和130可以基于相同的底层存储技术，或者可以使用不同的存储技术，并且可以以相同或不同的方式构造数据。

在本文描述的示例中，每个储存库都被实现为Hadoop数据储存库，该储存库采用了带有Apache Hive数据仓库基础设施的Hadoop分布式文件系统(HDFS)。数据可以各种形式存储在储存库中，包括：

·结构化数据可以存储为由Hive子系统管理的一组Hive表108。Hive为存储在HDFS中的数据提供了一个类似表的抽象，其中，表数据存储在HDFS的文件中，而描述Hive表的元数据存储在名为Hive Metastore的元数据数据库中。Hive查询语言(HQL)用于创建和操作Hive表。

·其他数据可以作为简单文件109存储在HDFS。

在本示例中，源数据储存库110可以被认为是主储存库或操作储存库，包含用于例如支持(例如，在操作系统116中)组织的操作的实时数据。目标储存库130可以被认为是备份储存库，其可以用作备份，和/或支持次要功能(例如，数据分析和/或报告)。注意，以示例的方式提供这种区别，并且储存库可以支持其他目的和功能。

在本示例中，源储存库110中的数据可以由操作系统116直接提供。可选地或另外，数据可以源自任意数量的源数据储存库(例如，102-1、102-2)。与数据储存库110不同，这些可以是传统结构的数据库(例如，关系或对象数据库)，但是可以使用任何形式的数据源，例如，平面文件、实时数据馈送等。在以下示例中，源数据库102是由传统关系数据库管理系统(RDBMS)管理的关系数据库，例如，Oracle/MySQL/Microsoft SQL服务器等。源数据储存库可以例如包括传统数据库、外部数据库(例如，来自第三方数据提供商)或者支持依赖于传统数据库架构并且不能直接与数据储存库110接合的操作系统(例如，系统115)的数据库。

数据挖掘工具106允许将这样的数据源导入源数据储存库110。假设源数据库是传统的关系数据库或类似数据库，则给定的源数据库102由多个表组成(其中，一个表包括一组行或记录，每个行或记录分成一个或多个字段或列)。数据挖掘工具可以导入整个数据库(即包括所有表)，或者可以只导入一个或多个选定的表。此外，系统可以将来自单个数据源或多个数据源的表和数据导入到同一数据储存库110中。因此，源自具有不同原始数据模式的不同结构数据源的数据可以在源数据储存库110中共存。

在源储存库110中，存储结构化数据(无论是例如经由操作系统116直接提供/操作的还是经由数据挖掘工具106导入的)，作为Hive表108的集合。Hive表体现在HDFS的一个或多个文件中(例如，Hadoop SEQUENCEFILE格式中)。实际上，除了可以存储在单个文件中的非常小的Hive表之外，在HDFS中，一个给定的表可以拆分为多个文件。

当从源数据库102导入时，数据挖掘工具优选地以并行方式作为映射化简算法(此处使用Hadoop Java映射化简框架实现)操作，并且为导入的表生成的文件数量取决于使用多少映射器来创建文件。例如，对于小型表，可以使用默认的十个映射器，为一个表生成十个文件，但是非常大的表可能会分成数千个文件。

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

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

由操作系统116直接操纵的数据可以以类似的方式或任何其他合适的方式存储。例如，如上所述，一些数据可以存储为Hive表108的集合，并经由HQL查询进行操作。其他数据可以作为简单文件109存储在HDFS中。

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

目标数据储存库130是储存库110的复制版本。因此，包含来自源储存库的数据副本。注意，这可以是所有数据的完整复制，也可以只是已定义子集的完整复制。此外，目标数据储存库可以使用相同的数据结构来存储数据，或者可以以不同的方式来构造数据。在以下描述中，将假设目标数据储存库是完整的副本，并且数据结构和内容是相同的。

外部过程和装置可获得任一数据储存库中的数据，例如，操作系统116、分析组件112和报告组件114。外部过程和装置被示为与目标储存库130相关联，因为在该示例中，目标储存库旨在支持分析/报告功能，但是通常，任何合适的过程和系统都可以访问任一储存库中的数据。

复制系统

复制系统120负责从源数据储存库到目标数据储存库的复制。复制优选地基本上在连续的基础上执行，使得目标数据储存库保持与源数据储存库同步。这可能意味着数据变化在发生时复制，或者定期/周期性地执行复制，但是频率相对较高(例如，每秒或每几秒一次、每分钟一次或每五分钟或每十分钟一次)。通过这种方式，数据保持基本同步(不像夜间批处理)。

通常，变化检测/复制频率优选地是可配置的。通过使用足够高的变化检测/复制频率，可以实现基本上实时(或至少接近实时)的同步。较低的变化检测/复制频率可用于实现异步复制(例如，类似于夜间批量复制)。

复制系统的操作如图2所示。

复制系统120基于以事件传送组件206为中心的事件分布模型进行操作。该系统还包括源储存库处的事件跟踪器服务202和事件调度器204以及目标储存库处的事件接收器服务208和事件执行器服务210。

发生在源储存库110处的相关事件被事件跟踪器服务202捕获并提供给事件调度器服务204。相关事件包括在源储存库中发生的任何事件，这些事件可能需要在目标储存库中采取措施，以确保储存库保持同步。

广义而言，相关事件包括：

·涉及存储在源储存库中的Hive表中的数据结构变化的事件(例如，数据模型变化)，

·对Hive表数据本身(即数据内容)的变化，以及

·对其他文件的变化(即不包含Hive表数据的普通HDFS文件)。

对于Hive表变化，结构变化通常包括由数据定义语言(DDL)命令导致的变化，并且可以包括例如：

·创建/删除/截断表

·添加/删除列

·改变对象

·创建/删除视图

·添加/删除分区

Hive表的数据内容变化通常包括由数据操作语言(DML)命令导致的变化，并且可以包括例如：

·向Hive表中添加一行或多行(例如，HQL INSERT语句)

·更新Hive表中的一行或多行(例如，HQL UPDATE语句)

·删除Hive表中的一行或多行(例如，HQL DELETE语句)

DML和DDL命令通常是数据库接口语言(例如，SQL/HQL)的一部分，但是变化可以以任何合适的方式实现(例如，经由合适的API以编程方式实现)。

普通HDFS文件的变化事件可以包括：

·创建数据文件

·将数据附加到文件中

·改变数据文件

·删除数据文件

注意，在一些实施例中，系统可以仅支持创建、附加和删除HDFS文件，而不支持其他形式的文件更新(例如，重写/随机访问)。

以上是事件跟踪器服务202可以捕获的事件的示例。可以基于存储技术、同步要求等捕获额外和/或替代事件和事件类型。

事件调度器服务204将事件格式化为事件消息，并将这些消息传输到事件传送子系统206。事件传送子系统206将接收到的事件传送到通过事件传送子系统注册为事件接收者的任何目的地。在当前情况下，目标储存库130处的事件接收器服务208被注册为事件的接收者(在其他实施例中，可以注册事件的多个接收器，并且不同的接收者可以注册，以接收不同类型的事件，如稍后更详细讨论的)。接收到的事件提供给事件执行器服务210，事件执行器服务210执行由目标储存库210中的事件导致的任何变化。

在优选实施例中，传输的事件描述了在源储存库处发生的变化，但是不包括数据内容(或者至少不总是包括所有必要的数据内容)。当实施变化时，事件执行器服务210从源储存库中检索与源储存库中的变化相关的任何所需数据内容。

因此，信息流涉及两条独立的路径：携带变化元数据(定义源储存库110中已经做出的变化的信息)的事件经由事件传送子系统主动推送(流程212)，而当在目标储存库中实现变化时，事件执行器服务210提取(检索)数据内容(流程214)。

例如，可以将一组行添加到源储存库中的现有表中，例如，经由INSERT操作。这将触发事件，该事件经由事件传送子系统推送到目标储存库。事件(或者可以是一组相关事件)包括描述变化的信息。例如，该信息可以包括以下一个或多个：

·修改后的表的表标识符，

·操作标识符，在这种情况下表示已经执行了行插入操作

·插入行数的指示；

·插入行的一个或多个行标识符。

然而，在这种方法中，事件不包括行数据本身(即插入行的字段值)。

事件执行器服务210接收事件(经由事件传送系统206和事件接收器服务208)，并将读取请求传输到源储存库110，以检索行数据(例如，通过传送插入行的行标识符)。源储存库检索请求的数据，并将其作为响应传输给事件执行器。事件执行器210然后使用接收到的数据在目标储存库中执行行插入操作(例如，通过发出适当的HQL命令)，以将行插入到目标储存库中识别的表中(可选地，可以在文件级传输数据，如下面进一步讨论的)。

在本实施例中，复制器系统120包括位于源储存库110和目标储存库130处(或形成其一部分)的软件组件以及源储存库和目标储存库外部的软件组件。然而，在实践中，组件可以以任何适当的方式分布，并且可以形成源/目标储存库的一部分和/或在源/目标储存库的外部。

图3提供了复制过程在HDFS/Hive数据储存库环境中实现的更多细节。在本示例中，复制系统支持Hive表和普通HDFS文件的复制。

如上所述，事件跟踪器202监视源储存库110中的变化。具体而言，在该实现中，事件跟踪器监视HDFS编辑日志302和Hive通知表304。

HDFS编辑日志302提供储存库接收的所有文件创建/附加/删除请求的记录。Hive通知表304包含与Hive表相关的所有相关更新(例如，包括DDL类型和DML类型事件)的记录。可选地，可以从与DML类型(即内容变化)不同的来源获得关于DDL类型(即结构)变化的信息(例如，数据库可以提供单独的元数据变化日志和数据内容变化日志)。事件跟踪器202是一个后台进程，持续监视编辑日志和通知表中的新条目。在一个示例中，事件跟踪器每隔几秒钟监视一次编辑日志文件/通知表。精确的频率优选地是可配置的，以适合特定的实现。

事件跟踪器202将检测到的事件转发给事件调度器204，事件调度器204将其格式化为事件消息，并将事件消息提交给事件传送系统。

事件传送系统206通过消息服务320来实现。在特定的实施例中，这是使用ApacheKafka消息服务实现的，尽管其他技术也可以替代。事件调度器204将消息提交给消息服务。消息服务维护消息的消息队列310，用于传送。事件接收器208在消息服务320订阅期望的消息。因此，相关消息由消息服务传送到事件接收器208。

事件执行器210根据事件类型进行适当的变化。由事件执行器实现的变化可以包括应用数据变化312和/或元数据变化314。

对于Hive数据(即在储存库中作为Hive表存储的数据)，数据变化(其可以对应于如上所述的DML命令)可以包括在表中插入行、更新行和删除行，并且这些由事件执行器210通过在目标储存库中(在Hive数据318中)执行相应的操作来实现。元数据变化涉及对定义数据结构的元数据的变化，并因此涉及对数据结构本身的变化(例如，对应于DDL命令)，并且这种变化可以包括创建新表或删除表、修改现有表的结构(例如通过添加或删除列来)等。事件执行器通过将相同的DDL变化应用于目标储存库来实现这些(这可以包括根据需要更新Hive数据318和Hive元存储)。

在数据变化312的情况下，所需数据(例如，插入/更新行的行/字段数据)从源储存库110中的相关源数据结构中检索(“提取”)，包括HDFS数据306和HIVE数据308。

对于Hive数据更新，可以通过向源储存库发送适当的HQL查询来执行数据检索。可选地，这可以通过复制包含更新的Hive表数据的文件来完成(在对表进行分区的情况下，可能只需要用已变化的数据复制文件)。对于HDFS文件，可以复制新的或修改的文件(例如，整个文件，或者只是文件的相关部分)。文件复制可以使用诸如distcp的工具，但也可以使用任何合适的方法来复制文件。

数据更新312和元数据变化312应用于目标储存库中相应的HDFS数据316和Hive数据318。例如，从源储存库110检索的数据可以通过发布适当的Hive DML语句写入目标Hive表318，并且元数据变化(即数据结构变化)可以通过发布相关的Hive DDL语句来实现。

对于HDFS文件事件，如果已经创建了一个新文件或者现有文件被新版本替换，则执行器将文件复制(提取)到目标储存库。如果删除文件，则执行器将删除目标储存库中的文件。

在优选实施例中，复制系统组件被设计成作为服务运行，因此不需要调度器。

作为事件一部分发送的事件数据可能因事件类型而异，并且在与Hive表变化和普通文件变化相关的事件之间可能有所不同。这些事件包括源储存库中发生的表和文件变化的具体细节。如上所述，目标储存库订阅事件消息，并且然后在本地应用事件。如果事件需要复制的数据，则从源储存库中提取事件。

图4是概述同步过程的流程图。该过程以三列显示，左边一列包括在源储存库中执行的步骤，中间一列包括在消息服务中执行的步骤，右边一列包括在目标储存库中执行的步骤。控制流显示为实线，消息流显示为虚线。

在步骤402中，事件跟踪器检查源储存库日志/通知表，以识别需要通知目标储存库的任何变化。在步骤404中，为任何识别的变化生成事件消息。在步骤406，事件消息被提交给消息系统。连续重复过程402、404、406。例如，该过程可以周期性地重复，例如，每分钟或每五分钟。可选地，该过程可以通过更新日志或以任何其他合适的方式触发。

在步骤408，消息服务接收事件消息。在步骤410中，消息服务将消息传输给任何订户(即，先前已经注册为接收相关消息类别的实体)，此处包括目标储存库处的事件接收器服务。

在步骤412，目标储存库的事件接收器接收消息。在步骤414中，事件执行器确定事件消息所涉及的变化类型。如果事件涉及储存库元数据和/或数据结构的变化，则在步骤416中，根据需要更新目标储存库元数据和/或修改数据结构(例如，向数据表添加列)。随后，或者如果没有元数据变化发生，则事件执行器确定(步骤418)是否需要对数据内容进行任何改变。如果没有，则同步过程结束。

如果需要改变数据内容，则在步骤420，事件执行器(或相关联的更新模块)向源储存库传输对相关数据的请求。在步骤422中，源储存库检索所请求的数据(例如，从相关的Hive表中)，并在步骤424中传输所请求的数据。在步骤426中，目标储存库接收所请求的数据，并对目标储存库的相关文件或数据表执行必要的更新(例如，执行行插入或更新)。同步过程随后结束。

注意，某些数据变化(特别是删除(例如，删除表行或整个表或文件))可能不需要从源储存库中获取数据。在这种情况下，可以省略步骤420、422和424，并且过程可以前进到更新步骤428，例如，从表中删除特定行。

基于事件的复制的扩展

在所描述的实施例中，复制系统使用基于事件的方法。每个事件都可以被视为一个单独的操作，并且源储存库中的每个操作都经由事件通知复制到目标储存库中。

优选地，目标储存库中不同目录或表的事件可以异步和并行消耗(例如，通过事件执行器服务的多个并行实例)。

所描述的基于事件消息分发的方法特别灵活，并且可以实现多种复制场景。

例如，系统可以扩展到允许同时复制到多个目标数据储存库(一对多复制)。为此，另一目标储存库可以向消息服务注册，以接收相关事件消息。然后，消息服务将相关的事件消息传送到两个目标储存库，其中，可以执行相关的变化事件。以这种方式可以支持任意数量的复制目标。

类似地，从多个源储存库到单个目标储存库的复制(多对一复制)可以通过使多个源储存库以所描述的方式向消息服务输出事件消息来实现，其中，单个目标储存库订阅来自两个源储存库的事件消息，并根据需要实现接收到的变化事件(例如，形成包含来自两个源储存库的所有或选定数据的单个备份数据存储)。

此外，该系统可以支持异构系统之间的复制，例如，Hadoop/HIVE源和非Hadoop目标系统(例如，传统关系数据库)之间的复制。这可以通过在备选目标系统处实施合适的事件接收器/执行器服务来实现，其中，执行器服务适于根据目标系统处采用的数据存储范例和技术来实现所需的变化。

也可以实现选择性复制。例如，给定的事件接收器可以仅订阅特定的相关事件消息，或者可以过滤接收到的消息，仅相关消息被处理/转发给事件执行器(可选地，可以在事件执行器处发生过滤)。作为一个具体的示例，给定的目标储存库可以选择仅接收源储存库中Hive表的特定子集的消息(例如，在目标储存库支持仅数据子集相关的分析功能的情况下)。作为另一示例，被设计用于维护历史记录的目标储存库可以选择仅复制记录插入，而不复制记录删除(或者可以通过将记录标记为目标储存库中已删除而不从Hive表中实际删除来实施删除)。

通常，事件执行器可以实现额外的处理，例如，在数据写入目标储存库之前重新格式化或修改数据。事件过滤或数据修改/预处理可选地/另外在源储存库处执行，例如，由事件跟踪器202和/或事件调度器204执行。

虽然在前面描述的示例中，复制基本上是实时(或接近实时)进行的，但是复制也可以延迟进行。例如，可以在指定的延迟持续时间之后(例如，24小时之后)或者在指定的时间(例如，在午夜、周末等)将改变应用于目标储存库。当出于备份目的执行复制时，这可能是合适的。复制延迟优选地是可配置的。

因此，基于事件的复制机制允许系统提供功能，而不仅仅是维护源储存库的同步备份。

各种方法和场景可以以任何适当的方式组合，以提供复杂的复制系统，例如，源储存库可以将数据子集复制到第一目标储存库，并将另一子集复制到第二目标储存库(可以具有不同的复制延迟，例如，一个可以是实时的，另一个可以延迟)，第二目标储存库将该数据与从另一源储存库复制的另一组数据组合(多对多复制)。同时，目标储存库可以执行数据过滤或预处理(例如，计算数据聚合，以支持分析查询)。

复制系统优选地可由操作员动态配置。例如，可以提供基于网络的或其他图形用户界面，允许操作员启动/停止服务、通过一个或多个事件接收器配置事件订阅、配置复制频率和时间表/延迟以及执行报告任务。

示例计算机节点架构

图5示出了可用于实现上述过程的计算节点。在此处，第一处理节点500实现源储存库的功能，而第二处理节点510实现目标储存库的功能。处理节点可以例如包括传统的计算机服务器。

第一处理节点500可以包括处理器504、易失性存储器(RAM)506(例如，用于存储正在执行的软件代码和瞬态数据)和永久存储器508(例如，硬盘或固态存储装置)，用于存储供处理器执行的软件和永久数据。持久数据可能包括HDFS文件，包括Hive表、Hive元存储等。

该软件可以包括服务器操作系统和Hadoop/Hive软件(未示出)以及事件跟踪器模块202、事件调度器模块204和数据挖掘模块106。虽然在该示例中，各种功能被示为在单个节点500中组合，但是可以有多个这样的节点(例如，形成实现源储存库的Hadoop集群)，其中，功能以任何适当的方式分布在集群节点上。

计算节点还包括用于与网络520(其可以包括局域网和广域网，例如，互联网)通信的网络接口502。该节点可以经由网络520与消息服务器522通信，并且从而(间接地)与目标数据储存库处的节点510通信。在一些实施例中，直接通信也是可能的(例如，在消息服务集成到节点500和/或节点510中的情况下，或者在不使用消息服务的情况下实现系统的情况下)。

计算节点可以包括技术人员已知的其他传统硬件和软件元件。

目标储存库处的计算节点510包括相应的硬件和软件组件(例如，网络接口512、处理器514、存储器516和永久存储器518)。然而，代替事件跟踪器和事件调度器，节点510包括事件接收器模块208和事件执行器模块210。至于节点500，节点510可以是形成实现目标储存库的Hadoop集群的节点集合中的一个。

消息服务器522可以类似地基于传统的服务器架构，包括一个或多个计算节点，其具有用于存储事件消息的存储器和用于接收和分发消息的网络设施。

数据挖掘

如前所述，除了用于在数据储存库之间复制的数据复制系统之外，该系统还可以包括称为“数据挖掘”的工具，用于将数据从诸如传统关系数据库的外部数据源导入到储存库中。在图1中显示为元件106的数据挖掘工具将参考图6A至图12在以下部分进行描述。在此处，数据储存库也称为“数据湖”。

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

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

2)差值计算器；

3)历史捕获。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

元数据生成和模式演化

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

在运行时为源数据储存库中的任何物化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源的元数据(并识别对元数据的任何变化)。如果在数据源改变了表的模式，则数据湖中表示的模式也会相应地修改。

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

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

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

表名称；

表描述；

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

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

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

列数据类型；

列描述；

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

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

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

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

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

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

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

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

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

向表中添加一列

表的唯一索引变化

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

删除列

列的重命名

列长度/大小的变化

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

列的顺序变化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

导入脚本的生成和操作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

添加列

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

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

删除列

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

表的唯一索引变化

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

其他变化

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

差值计算器

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

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

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

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

自动识别记录的DML类型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

历史捕获

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

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

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

在一个实施例中，历史捕获处理被实现为用于更新两个主要操作数据库(即，OPEN和CLOSED)的Java映射化简程序。该处理使用来自每日增量处理的输出(例如，来自如上所述的数据挖掘差值计算器，或者来自源数据储存库提供的表增量，例如，经由OracleGoldenGate/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，源储存库110可以存储支持操作系统116的数据，其中，一些可以从外部数据库102定期更新。数据挖掘模块的每次运行(例如，每天)可以导致储存库110中的数据的变化，例如，添加/更新/删除。这些然后被复制系统120自动复制到目标储存库130。对源数据库102的数据模型的任何改变(例如，表列的添加)也可以通过对Hive表108进行相应修改的数据挖掘来捕获。复制系统也复制这些类型的变化，从而允许目标储存库在数据内容和数据模型中保持同步。

类似地，可以通过数据挖掘将新的源表导入到源储存库中，同时配置选项可以声明该表应该从源储存库复制到一个或多个目标储存库(例如，具有不同的配置复制延迟)。

在另一示例中，数据复制系统和数据挖掘组件可以依赖于定义存储数据的数据模型的共享元数据储存库。当该元数据储存库将源数据导入储存库110时，可以由数据挖掘更新，并且然后由数据复制系统用于执行复制。

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

附录-脚本样本

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

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

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

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

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

USE${hivevar:DATABASE}；

ALTER TABLE crm_tj30t ADD COLUMN(COL1STRING)；

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

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

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

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

Claims (33)

1.一种在目标数据储存库处复制对源数据储存库所做的变化的方法，所述方法包括在所述目标数据储存库处：

接收变化事件消息，所述变化事件消息包括指定在所述源数据储存库处检测到的数据变化事件的信息，所述数据变化事件包括写入所述源数据储存库的一个或多个数据值；

响应于所述变化事件消息，向所述源数据储存库发送对所述一个或多个数据值的请求；

从所述源数据储存库接收所述一个或多个数据值；并且

基于所接收的数据值更新存储在所述目标数据储存库中的数据。

2.根据权利要求1所述的方法，其中，所述消息指定在所述源数据储存库处执行的操作，所述操作优选包括插入操作和更新操作中的一个。

3.根据权利要求1或2的方法，其中，所述消息不包括所述一个或多个数据值。

4.根据前述权利要求中任一项所述的方法，其中，所述消息包括允许识别所述一个或多个数据值的识别信息，所述请求包括所述识别信息。

5.根据前述权利要求中任一项所述的方法，其中，经由消息服务接收所述消息。

6.根据权利要求5所述的方法，包括由所述目标数据储存库订阅来自所述消息服务的变化事件消息。

7.根据前述权利要求中任一项所述的方法，包括在所述源数据储存库处：

检测所述变化事件；并且

基于检测到的变化事件输出所述变化事件消息。

8.根据权利要求7所述的方法，包括向所述消息服务发送所述变化事件消息。

9.根据前述权利要求中任一项所述的方法，其中，检测所述变化事件包括检查与所述源数据储存库相关联的变化日志。

10.根据权利要求9所述的方法，其中，周期性地执行所述检查。

11.根据前述权利要求中任一项所述的方法，其中，所述更新步骤包括修改所述目标储存库处的数据，以复制所述目标储存库处的所述变化事件。

12.根据前述权利要求中任一项所述的方法，其中，发送请求和接收所述一个或多个数据值的步骤包括将包括所述一个或多个数据值的文件从所述源数据储存库传输到所述目标数据储存库。

13.根据前述权利要求中任一项所述的方法，其中，所述数据变化事件包括在所述源储存库处创建或修改文件，并且优选地，其中，所述接收步骤包括从所述源储存库接收所创建或修改的文件的副本。

14.根据前述权利要求中任一项所述的方法，其中，所述数据变化事件包括插入或更新数据库表中的一行或多行，并且优选地，其中，所述接收步骤包括接收所述一行或多行或者接收存储所述数据库表的插入或更新行的一个或多个文件的副本。

15.一种在目标数据储存库处复制对源数据储存库所做的变化的方法，所述方法包括在所述目标数据储存库处：

接收变化事件消息，所述变化事件消息包括指定在所述源数据储存库检测到的数据变化事件的信息；并且

根据所述变化事件消息更新所述目标数据储存库；

其中，所述数据变化事件包括数据内容变化和数据结构变化，所述方法包括：

响应于指定数据内容变化的变化事件消息，基于所述变化事件消息更新所述目标数据储存库中的数据；并且

响应于指定数据结构变化的变化事件消息，在所述目标数据储存库处实现所述数据结构变化。

16.根据权利要求15所述的方法，其中，所述变化事件消息指定所述源储存库处的表定义的变化，并且其中，实现所述数据结构变化包括修改所述目标储存库中的表定义，以将相应的变化应用于所述目标储存库的表。

17.根据权利要求15所述的方法，其中，所述变化事件消息指定在所述源储存库处创建或删除表，并且其中，实现所述数据结构变化包括在所述目标数据储存库处创建或删除相应的表。

18.根据权利要求15至17中任一项所述的方法，所述方法包括响应于指定数据内容变化的变化事件消息，执行根据权利要求1至14中任一项所述的方法。

19.一种在目标数据储存库处复制对源数据储存库所做的变化的方法，所述方法包括在所述目标数据储存库处：

接收变化事件消息，所述变化事件消息包括指定在所述源数据储存库检测到的数据变化事件的信息；

基于所述变化事件消息，确定所述数据变化事件包括写入所述源数据储存库的新的或更新的数据，所述新的或更新的数据不包括在所述变化事件消息中；

响应于所述确定，从所述源数据储存库检索所述新的或更新的数据；并且

基于检索到的数据和所述变化事件消息更新存储在所述目标数据储存库中的数据。

20.根据权利要求19的方法，包括权利要求2至18中任一项所述的进一步的步骤或特征。

21.根据前述权利要求中任一项所述的方法，其中，所述源数据储存库和/或所述目标数据储存库包括非结构化的数据储存库或灵活结构化的数据储存库，例如，数据仓库或数据湖。

22.根据前述权利要求中任一项所述的方法，其中，所述源数据储存库和所述目标数据储存库中的至少一个包括分布式数据存储集群，优选地基于Apache Hadoop和/或ApacheHive。

23.根据前述权利要求中任一项所述的方法，包括复制Hive元数据变化，其中，所述变化事件消息涉及Hive表的创建或Hive表定义的修改，所述更新步骤包括将相应的变化应用于所述目标数据储存库处的数据结构。

24.根据前述权利要求中任一项所述的方法，包括复制Hive表数据变化，其中，所述变化事件消息涉及Hive表中一行或多行的插入、删除或更新，所述更新步骤包括基于所接收的数据值将相应的变化应用于所述目标储存库中的Hive表。

25.一种具有用于执行根据前述权利要求中任一项所述方法的装置的系统。

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

27.一种数据复制系统，包括：

变化事件检测子系统，被配置为在源数据储存库处运行；

变化事件实现子系统，被配置为在目标数据储存库运行；以及

消息服务，被配置为根据消息订阅传输所接收的消息；

其中，所述变化事件检测子系统被配置为检测对所述源数据储存库做出的变化，并将变化事件消息传输到所述消息服务；并且

其中，所述变化事件实现子系统被配置为：

订阅所述消息服务处的变化事件消息；并且

响应于接收到变化事件消息，在所述目标数据储存库实现所述变化事件。

28.根据权利要求27所述的数据复制系统，包括：

多个目标数据储存库，每个目标数据储存库包括相应的变化事件实现子系统，每个变化事件实现子系统适于订阅来自所述源数据储存库的变化事件消息，并在相应的目标数据储存库处实现相应的变化事件。

29.根据权利要求27或28所述的数据复制系统，包括：

多个源数据储存库，每个源数据储存库包括相应的变化事件检测子系统，所述变化事件检测子系统适于将变化事件消息传输到与相应的源数据储存库处的变化事件相对应的所述消息服务。

30.根据权利要求29所述的数据复制系统，其中，来自所述多个源数据储存库的变化事件消息由所述消息服务转发到至少一个目标数据储存库，用于在所述至少一个目标数据储存库处复制所述变化事件。

31.根据权利要求27至30中任一项所述的数据复制系统，其中，所述变化事件实现子系统被配置为过滤所接收的消息和/或在所述目标储存库处复制变化事件的选定子集。

32.根据权利要求27至31中任一项所述的数据复制系统，其中，所述变化事件实现子系统适于响应于接收到对应于写入所述源数据储存库的新的或修改的数据的变化事件消息，从所述源数据储存库检索所述新的或修改的数据的至少一部分，优选地，其中，所述新的或修改的数据的至少一部分不包括在所述变化事件消息中。

33.根据权利要求27至32中任一项所述的数据复制系统，适于执行根据权利要求1至24中任一项所述的方法。

Images