CN112559475A - 数据实时捕获和传输方法及系统 - Google Patents

Abstract

本申请实施例提供了一种数据实时捕获和传输方法，所述方法包括：将数据源的全量数据写入到分析系统中；将位于所述分析系统中的全量数据进行格式转换，得到支持实时更新的第一数据文件；捕获所述数据源中的多个数据变更事件，并根据所述多个数据变更事件生成数据变更日志；将所述数据变更日志写入到消息队列系统中；及根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件。在本申请实施例中，既可以得到数据变化趋势，又可以在数据源出现数据变更之后，确保分析系统中的数据同步时效性。

Description

数据实时捕获和传输方法及系统

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种数据实时捕获和传输方法、系统、计算机设备以及计算机可读存储介质。

背景技术

随着大数据的发展，人们开始依赖大数据来进行业务的计算、分析和预测等。为此，需要建立某种数据管道，通过数据管道使得数据可以从数据源(如，MySQL)到分析系统(如，HDFS)。为此，业界提出了CDC(数据实时捕获与传输)管道。CDC管道，可以确定和跟踪变更的数据，并将变更的数据导入数据湖。

现有技术中，CDC管道存在于HDFS中，即当数据源产生数据变更时，数据变更日志被存储到HDFS中。数据变更日志不适用于HIVE的操作。因此，需要到第二天拉起离线作业，将数据源在上一天产生所有数据变更日志中的变化数据进行清洗操作，并将最终的变化数据更新到HDFS的数据表中，这就导致：数据源在当天产生的增量数据，需要到第二天才能够被更新到HDFS的数据表中，时效性差。

发明内容

本申请实施例的目的是提供一种数据实时捕获和传输方法、系统、计算机设备及计算机可读存储介质，用于解决以下问题：出现数据变更之后，数据变更之后的增量数据同步时效性差。

本申请实施例的一个方面提供了一种数据实时捕获和传输方法，所述方法包括：将数据源的全量数据写入到分析系统中；将位于所述分析系统中的全量数据进行格式转换，得到支持实时更新的第一数据文件；捕获所述数据源中的多个数据变更事件，并根据所述多个数据变更事件生成数据变更日志；将所述数据变更日志写入到消息队列系统中；及根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件。

可选的，所述数据源的全量数据为在所述预设时间节点时所述数据源中的全部数据；捕获所述数据源中的多个数据变更事件，并根据所述多个数据变更事件生成数据变更日志，包括：从所述预设时间节点起始，实时捕获所述多个数据变更事件；及根据所述多个数据变更事件生成所述数据变更日志；其中，所述数据变更日志包括用于记录所述多个数据变更事件的多个数据变更内容。

可选的，所述分析系统为HDFS；将位于所述分析系统中的全量数据进行格式转换，得到支持实时更新的第一数据文件，包括：将位于所述HDFS中的全量数据转换为HUDI初始快照，所述HUDI初始快照即所述第一数据文件。

可选的，根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件，包括：实时读取所述消息队列系统中的数据变更日志；及根据从所述消息队列系统实时读取的数据变更日志，更新所述HUDI初始快照以得到HUDI文件；其中，所述HUDI文件即所述第二数据文件。

可选的，根据从所述消息队列系统实时读取的数据变更日志，更新所述HUDI初始快照以得到HUDI文件，包括：判断每个数据变更内容在所述HUDI初始快照中是否存在具有相同标识的记录；当其中一个数据变更内容在所述HUDI初始快照中存在相应记录，且该数据变更内容的时间戳晚于所述相应记录的时间戳，则根据该数据变更内容更新所述相应记录，其中，所述相应记录为与所述数据变更内容具有同一标识的记录；及当其中一个数据变更内容在所述HUDI初始快照中不存在所述相应记录，则将该数据变更内容对应的新增记录添加到所述HUDI初始快照中。

可选的，还包括：监控以下一个或多个过程的数据输入量和数据输出量：(1)将数据源的全量数据写入到分析系统中；(2)将位于所述分析系统中的全量数据进行格式转换；(3)将所述数据变更日志写入到消息队列系统中；及(4)根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件；根据监控结果进行数据流的可视化处理，和/或判断所述一个或多个过程是否出现异常。

可选的，所述日志系统为Kafka；将所述数据变更日志写入到消息队列系统中包括：通过增量日志同步系统，将所述数据变更日志实时同步到所述Kafka的日志主题下。

本申请实施例的再一个方面提供了一种数据实时捕获和传输系统，所述系统包括：第一写入模块，用于将数据源的全量数据写入到分析系统中；格式转换模块，用于将位于所述分析系统中的全量数据进行格式转换，得到支持实时更新的第一数据文件；日志生成模块，用于捕获所述数据源中的多个数据变更事件，并根据所述多个数据变更事件生成数据变更日志；第二写入模块，用于将所述数据变更日志写入到消息队列系统中；及文件获取模块，用于根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件。

本申请实施例的再一个方面提供了一种计算机设备，所述计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时用于实现上述数据实时捕获和传输方法的步骤。

本申请实施例的又一个方面提供了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时用于上述数据实时捕获和传输方法的步骤。

本申请实施例提供的数据实时捕获和传输方法、系统、计算机设备及计算机可读存储介质，将全量数据写入到分析系统中并将分析系统中的全量数据转换为支持实时更新的第一数据文件，另外通过消息队列系统实时得到数据更变日志，并可以根据所述数据变更日志更新所述第一数据文件，以得到第二数据文件。可知，本申请实施例既可以得到数据变化趋势，又可以确保分析系统中的数据同步时效性。

附图说明

图1示意性示出了CDC管道的的链路图；

图2示意性示出了根据本申请实施例一的数据实时捕获和传输方法的流程图；

图3示意性示出了根据本申请实施例一的数据实时捕获和传输方法的另一流程图；

图4为图2或图3中步骤S204的子流程图；

图5为图2或图3中步骤S208的子流程图；

图6为图5中步骤S208B的子流程图；

图7示意性示出了根据本申请实施例一的数据实时捕获和传输方法的新增流程图；

图8示意性示出了根据本申请实施例一的具体示例图；

图9示意性示出了根据本申请实施例二的数据实时捕获和传输系统的框图；以及

图10示意性示出了根据本申请实施例三的适于实现数据实时捕获和传输方法的计算机设备的硬件架构示意图。

具体实施方式

为了使本申请实施例的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

在本申请的描述中，需要理解的是，步骤前的数字标号并不标识执行步骤的前后顺序，仅用于方便描述本申请及区别每一步骤，因此不能理解为对本申请的限制。

以下为本申请涉及到的一些术语解释：

全量数据，是数据源(数据表)中所有的数据。

增量数据，是上次导出之后的新数据。

数据湖(Data Lake)，是一个以原始格式存储数据的存储库或系统。

MySQL数据库，是一种基于关系型数据库管理系统的数据库。

Canal，是阿里巴巴集团提供的一个开源工具。Canal可以基于MySQL数据库增量日志解析，提供增量数据订阅和消费，以将增量数据同步到其他的存储应用。

Spark，是Apache开源社区的一个分布式计算引擎，基于内存计算，速度快于Hadoop。

Spark Job，表示执行一次行动(Action)，其可以被Spark Scheduler转换成大量的任务分发给Spark集群处理。

Spark Streaming，用于对新增数据进行流式处理。

Spark Streaming Job，每隔一段时间动态生成，每个Spark Streaming Job根据具体数据的业务逻辑生成。

Kafka，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统，也可以作为消息队列系统。Kafka可以用于web/nginx日志、访问日志，消息服务等。Kafka是按秒进行任务的计算和应用，用于实时推荐、实时计算等场景中。

HDFS(Hadoop Distributed File System，Hadoop分布式文件系统)，是一个分布式文件系统。HDFS的数据写入是按天进行任务的计算和应用。

HUDI(Apache Hudi)，采用并管理通过DFS(HDFS或云存储)存储大型分析数据集，支持在当前数据表中进行更新操作。

Binlog日志，是记录所有数据库表结构变更(如CREATE、ALTER TABLE)及表数据修改(INSERT、UPDATE、DELETE)的二进制日志。Binlog日志的格式为JSON。

CDC(CHANGE DATA CAPTURE，数据实时捕获与传输)管道：用于确定和跟踪已变更的数据，以便可以对更改后的数据采取措施，例如捕获MySQL变更的记录，然后导入数据湖。在申请实施例的技术方案在于提供一种新的CDC管道或基于该CDC管道的方法，它们可以同时支持数据变化和提高数据更新的时效性。

Clickhouse，用于联机分析处理(OLAP，on-Line Analytic Processing)的列式数据库管理系统。

在数据传输流程中，可以通过流式数据传输链路提供流式的数据传输服务，如用于实时流和离线流两大场景的数据收集和分发。实时流场景，对应于秒级别的数据时效性，主要用于将数据写入到Kafka、hbase等数据库中。离线流场景，对应于天级别的数据时效性，主要用于将数据写入到HDFS、hive等数据库中。

上述数据传输流程，可以包括从数据源(如，事务处理系统MySQL等)到分析系统(如，HDFS)。为了能够将数据从事务处理系统传输到分析系统，提出了CDC管道。

现有技术中，CDC管道存在于HDFS中，即当数据源产生数据变更时，数据变更日志被存储到HDFS中。数据变更日志不适用于HIVE的操作。因此，需要到第二天拉起离线作业，将数据源在上一天产生所有数据变更日志中的变化数据进行清洗操作，并将最终的变化数据更新到HDFS的数据表中，这就导致：数据源在当天产生的增量数据，需要到第二天才能够被更新到HDFS的数据表中，时效性差。

相较而言，本申请实施例引入了新的CDC管道方案，其通过引入HUDI数据库架构实现CDC管道的实时性。在该方案中，将MYSQL数据库中的全量数据转化为HUDI初始快照，并实时获取数据变更日志中的数据变更内容，并根据该实时得到的数据变更内容实时更新HUDI初始快照，从而实现了实时获取的增量数据能实时更新到分析系统中，从而有效地提高了分析系统的数据时效性。

以MYSQL数据库为例，其存储的数据为结果数据。本申请实施例的CDC管道方案在于：

(1)从MYSQL拿取到结果数据(即，全量数据)；

(2)从MYSQL实时拿取数据变更日志(如Binlog日志)，以得到数据变化趋势；

(3)将所述全量数据转换为支持数据表实时更新的HUDI初始快照，并基于数据变更日志实时更新HUDI初始快照，从而得到包括实时变化数据的HUDI文件。

可知，上述方案既可以得到数据变化趋势，又可以确保分析系统中的数据表的时效性。

以下提供本申请示例性的CDC管道的实现示例。该CDC管道可以通过以下节点得以实现：

(1)离线数据同步工具(如，Datax)，将MYSQL数据库中的全量数据写入到HDFS中；

(2)Spark Job，用于将落地到HDFS中的全量数据转换为基于HUDI的HUDI初始快照；

(3)数据库增量订阅与消费工具(如，Canal)，用于将MYSQL数据库的Binlog日志同步到Kafka中；

(4)Spark Streaming Job，用于根据Kafka提供的Binlog日志更新所述HUDI初始快照，以得到HUDI文件。

通过上述工具，实现了全量数据和增量数据的传输与融合，其具有如下技术优势：

在不需要数据变化的时候，直接获取与MYSQL类型一致的全量数据。

在需要数据变化的时候，获取Binlog日志并将该Binlog日志放入到Kafka中，以支持数据变化。

为保障实时性，引入HUDI数据库架构，将全量数据转换为HUDI初始快照，实时同步Binlog日志，并基于Binlog日志实时更新HUDI初始快照，即对当前数据表进行更新。

下文将提供多个实施例，下文提供的各个实施例用于描述数据实时捕获与传输方案。

实施例一

图2示意性示出了根据本申请实施例一的数据实时捕获和传输方法的流程图。下面计算机设备为执行主体进行示例性描述。需要说明的是，该计算机设备可以服务器集群。

如图2所示，该数据实时捕获和传输方法可以包括步骤S200～步骤S208，

其中：

步骤S200，将数据源的全量数据写入到分析系统中。

所述数据源可以为事务处理系统中MYSQL数据库等，其会根据用户操作等变更数据。以记录商品库存的MYSQL数据库为例，其会根据用户购买行为更改商品的库存记录。

所述全量数据，所述数据源的全量数据为在所述预设时间节点时所述数据源中的全部数据，例如在2020年12月4日00:00:00时所述数据源的数据表中的全部数据。

所述分析系统，可以为HDFS。用户可以根据所述分析系统内的数据进行业务的分析等。

步骤S202，将位于所述分析系统中的全量数据进行格式转换，得到支持实时更新的第一数据文件。

当所述分析系统为HDFS时，Hadoop并不支持数据表的实时更新，因此，需要对所述分析系统中的全量数据进行格式转换，例如，可以转换为HUDI格式的数据。在示例性的实施例中，如图3所示，所述步骤S202可以包括步骤S202A，将位于所述HDFS中的全量数据转换为基于所述HDFS的HUDI初始快照(HUDI Init Snapshot)。其中，所述HUDI初始快照即可以支持实时更新的第一数据文件。

步骤S204，捕获所述数据源中的多个数据变更事件，并根据所述多个数据变更事件生成数据变更日志。

所述数据源出现增量数据时，为了获取数据变化，不是直接读取所述数据源中发生变更的数据，而是实时获取用于描述数据变化的数据变更日志。所述数据变更日志包括多个数据变更内容，每个数据变更内容可以对应一个数据变更事件。

作为示例，所述数据源的全量数据为在所述预设时间节点时所述数据源中的全部数据。为了获取有效的数据变更日志，如图4所示，所述步骤S204可以包括步骤S400～S402，其中：步骤S400，从所述预设时间节点起始，实时捕获所述多个数据变更事件；及步骤S402，根据所述多个数据变更事件生成所述数据变更日志。其中，所述数据变更日志包括用于记录所述多个数据变更事件的多个数据变更内容。其中，所述数据变更日志可以为Binlog日志。例如，所述数据源在2020年12月4日00:00:00时所存储的所有数据作为全量数据，该全量数据可以以离线方式写入到所述分析系统中。然后，所述数据源在2020年12月4日00:00:00之后产生的增量数据并未写入到所述分析系统中。此时，需要通过Binlog日志记录所述数据源在2020年12月4日00:00:00之后产生的数据变更。该数据变更日志既可以用于得到所述数据源在2020年12月4日00:00:00之后的数据变化趋势，又可以用于准确且实时地在全量数据的基础上进行实时更新。

步骤S206，将所述数据变更日志写入到消息队列系统中。

所述数据变更日志，可以通过各类消息队列系统传送到所述数据变更日志的消费者。

作为示例，为高效同步，如图5所示，所述日志系统为Kafka且所述步骤S206可以通过如下步骤实现：通过增量日志同步系统，将所述数据变更日志实时同步到所述Kafka的日志主题下。该增量日志同步系统可以为Canal，并且以毫秒级的频率同步。

步骤S208，根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件。

所述消息队列系统中的数据变更日志，并非结果数据，而是描述数据变更的数据变更内容。以数据变更内容A为例，当数据变更内容A的时间戳晚于所述第一数据文件的相应记录B的时间戳，则根据数据变更内容A更新所述第一数据文件中的相应记录B。数据变更内容A的标识ID和相应记录B的标识ID是相同的。

作为示例，所述第一数据文件为HUDI初始快照。继续参考图3，所述步骤S208可以包括步骤S208A～S208B，其中：步骤S208A，实时读取所述消息队列系统中的数据变更日志；步骤S208B，根据从所述消息队列系统实时读取的数据变更日志，更新所述HUDI初始快照以得到HUDI文件。其中，所述HUDI文件即所述第二数据文件。

作为示例，为保障数据不重不丢，每个数据变更内容一一对应一个时间戳和一个标识。如图6所示，所述步骤S208B可以包括步骤S600～S604，其中：步骤S600，判断每个数据变更内容在所述HUDI初始快照中是否存在具有相同标识的记录；步骤S602，当其中一个数据变更内容在所述HUDI初始快照中存在相应记录，且该数据变更内容的时间戳晚于所述相应记录的时间戳，则根据该数据变更内容更新所述相应记录，其中，所述相应记录为与所述数据变更内容具有同一标识的记录；步骤S604，当其中一个数据变更内容在所述HUDI初始快照中不存在所述相应记录，则将该数据变更内容对应的新增记录添加到所述HUDI初始快照中。

作为示例，所述数据实时捕获与传输方法还可以设置全链路质量监控，例如通过Trace(追踪)系统，底层基于Clickhouse存储，统计各个环节的数据输出量和数据输入量。通过该各个环节的数据输出量和数据输入量，即可以得到数据流向图，亦可以得到各个环节是否出现数据丢失。如图7所示，所述方法还可以包括步骤S700～S702，其中：

步骤S700，监控以下一个或多个过程的数据输入量和数据输出量：

(1)将数据源的全量数据写入到分析系统中；

(2)将位于所述分析系统中的全量数据进行格式转换；

(3)将所述数据变更日志写入到消息队列系统中；及

(4)根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件；

步骤S702，根据监控结果进行数据流的可视化处理，和/或判断所述一个或多个过程是否出现异常。

以清晰表述，如图8所示，以下提供一个示例进行说明。

步骤S800，将MYSQL数据库的全量数据写入到HDFS中。

其中，所述数据源的全量数据为在所述预设时间节点时所述数据源中的全部数据。

步骤802，将位于所述HDFS中的全量数据转换为基于所述HDFS的HUDI初始快照。

步骤804，从所述预设时间节点起始，捕获MYSQL数据库中的多个数据变更事件以生成Binlog日志。

步骤906，通过Canal，将Binlog日志实时同步到Kafka的Binlog主题下。

Kafka可以采用事务机制。

步骤808，从所述Binlog主题下读取Binlog日志。

步骤810，基于读取的Binlog日志实时更新HUDI初始快照，以得到HUDI文件。

Binlog日志记录有MYSQL数据库的数据更改内容，每个数据均对应有一个全局唯一ID。同一个数据发生多次变更时，则只需要时间戳最晚的那个变更记录，并将时间戳最晚的那个变更记录作为HUDI初始快照中相应的数据的修改依据。具体的：

(1)对Binlog日志的多条记录，进行去重和排序操作：

如果包括相同ID的若干个数据变更事件，则筛选出所述若干个数据变更事件中的时间戳最晚的数据变更事件，并删除所述若干个数据变更事件中的其余数据变更事件。

(2)将所述至少部分数据变更事件转换为HUDI增量数据；及

(3)根据所述HUDI初始快照和所述HUDI增量数据，通过HUDI增量数据替换HUDI初始快照中的相应记录，以得到HUDI文件，所述HUDI文件即第二数据文件。

本方案的技术优势如下：

在不需要数据变化的时候，直接获取与MYSQL类型一致的全量数据。

在需要数据变化的时候，获取Binlog日志并将该Binlog日志放入到Kafka中，以支持数据变化。

为保障实时性，引入HUDI数据库架构，将全量数据转换为HUDI初始快照，实时同步Binlog日志，并基于Binlog日志实时更新HUDI初始快照，即对当前表进行更新。

实施例二

图9示出了根据本申请实施例二的数据实时捕获和传输系统的框图，该数据实时捕获和传输系统可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例中各程序模块的功能。如图9所示，所述数据实时捕获和传输系统900可以包括以下组成部分：

第一写入模块902，用于将数据源的全量数据写入到分析系统中；

格式转换模块904，用于将位于所述分析系统中的全量数据进行格式转换，得到支持实时更新的第一数据文件；

日志生成模块906，用于捕获所述数据源中的多个数据变更事件，并根据所述多个数据变更事件生成数据变更日志；

第二写入模块908，用于将所述数据变更日志写入到消息队列系统中；及

文件获取模块910，用于根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件。

可选的，所述数据源的全量数据为在所述预设时间节点时所述数据源中的全部数据；所述日志生成模块906，还用于从所述预设时间节点起始，实时捕获所述多个数据变更事件；及根据所述多个数据变更事件生成所述数据变更日志；其中，所述数据变更日志包括用于记录所述多个数据变更事件的多个数据变更内容。

可选的，所述分析系统为HDFS；所述格式转换模块904，还用于将位于所述HDFS中的全量数据转换为HUDI初始快照，所述HUDI初始快照即所述第一数据文件。

可选的，所述文件获取模块910，还用于：实时读取所述消息队列系统中的数据变更日志；及根据从所述消息队列系统实时读取的数据变更日志，更新所述HUDI初始快照以得到HUDI文件；其中，所述HUDI文件即所述第二数据文件。

可选的，所述文件获取模块910，还用于判断每个数据变更内容在所述HUDI初始快照中是否存在具有相同标识的记录；当其中一个数据变更内容在所述HUDI初始快照中存在相应记录，且该数据变更内容的时间戳晚于所述相应记录的时间戳，则根据该数据变更内容更新所述相应记录，其中，所述相应记录为与所述数据变更内容具有同一标识的记录；及当其中一个数据变更内容在所述HUDI初始快照中不存在所述相应记录，则将该数据变更内容对应的新增记录添加到所述HUDI初始快照中。

可选的，所述系统还包括监控模块，用于：监控以下一个或多个过程的数据输入量和数据输出量：(1)将数据源的全量数据写入到分析系统中；(2)将位于所述分析系统中的全量数据进行格式转换；(3)将所述数据变更日志写入到消息队列系统中；及(4)根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件；根据监控结果进行数据流的可视化处理，和/或判断所述一个或多个过程是否出现异常。

可选的，所述日志系统为Kafka；所述第二写入模块908，还用于：通过增量日志同步系统，将所述数据变更日志实时同步到所述Kafka的日志主题下。

实施例三

图10示意性示出了根据本申请实施例三的适于实现数据实时捕获和传输方法的计算机设备的硬件架构示意图。所述计算机设备10其是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是多个服务器所组成的服务器集群，所述多个服务器可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器等。如图10所示，计算机设备10至少包括但不限于：可通过系统总线相互通信链接存储器1010、处理器1020、网络接口1030。其中：

存储器1010至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器1010可以是计算机设备10的内部存储模块，例如该计算机设备10的硬盘或内存。在另一些实施例中，存储器1010也可以是计算机设备10的外部存储设备，例如该计算机设备10上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，存储器1010还可以既包括计算机设备10的内部存储模块也包括其外部存储设备。本实施例中，存储器1010通常用于存储安装于计算机设备10的操作系统和各类应用软件，例如数据实时捕获和传输方法的程序代码等。此外，存储器1010还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器1020在一些实施例中可以是中央处理器(Central Processing Unit，简称为CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器1020通常用于控制计算机设备10的总体操作，例如执行与计算机设备10进行数据交互或者通信相关的控制和处理等。本实施例中，处理器1020用于运行存储器1010中存储的程序代码或者处理数据。

网络接口1030可包括无线网络接口或有线网络接口，该网络接口1030通常用于在计算机设备10与其他计算机设备之间建立通信连接。例如，网络接口1030用于通过网络将计算机设备10与外部终端相连，在计算机设备10与外部终端之间的建立数据传输通道和通信连接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(Global System of Mobile communication，简称为GSM)、宽带码分多址(Wideband CodeDivision Multiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。

需要指出的是，图10仅示出了具有部件1010-1030的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。

在本实施例中，存储于存储器1010中的数据实时捕获和传输方法还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器1020)所执行，以完成本申请。

实施例四

本实施例还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现实施例中的数据实时捕获和传输方法的步骤。

本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例中的数据实时捕获和传输方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

1.一种数据实时捕获和传输方法，其特征在于，所述方法包括：

将数据源的全量数据写入到分析系统中；

将位于所述分析系统中的全量数据进行格式转换，得到支持实时更新的第一数据文件；

捕获所述数据源中的多个数据变更事件，并根据所述多个数据变更事件生成数据变更日志；

将所述数据变更日志写入到消息队列系统中；及

根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件。

2.根据权利要求1所述的数据实时捕获和传输方法，其特征在于，所述数据源的全量数据为在所述预设时间节点时所述数据源中的全部数据；捕获所述数据源中的多个数据变更事件，并根据所述多个数据变更事件生成数据变更日志，包括：

从所述预设时间节点起始，实时捕获所述多个数据变更事件；及

根据所述多个数据变更事件生成所述数据变更日志；

其中，所述数据变更日志包括用于记录所述多个数据变更事件的多个数据变更内容。

3.根据权利要求2所述的数据实时捕获和传输方法，其特征在于，所述分析系统为HDFS；将位于所述分析系统中的全量数据进行格式转换，得到支持实时更新的第一数据文件，包括：

将位于所述HDFS中的全量数据转换为HUDI初始快照，所述HUDI初始快照即所述第一数据文件。

4.根据权利要求3所述的数据实时捕获和传输方法，其特征在于，根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件，包括：

实时读取所述消息队列系统中的数据变更日志；及

根据从所述消息队列系统实时读取的数据变更日志，更新所述HUDI初始快照以得到HUDI文件；

其中，所述HUDI文件即所述第二数据文件。

5.根据权利要求4所述的数据实时捕获和传输方法，其特征在于，根据从所述消息队列系统实时读取的数据变更日志，更新所述HUDI初始快照以得到HUDI文件，包括：

判断每个数据变更内容在所述HUDI初始快照中是否存在具有相同标识的记录；

当其中一个数据变更内容在所述HUDI初始快照中存在相应记录，且该数据变更内容的时间戳晚于所述相应记录的时间戳，则根据该数据变更内容更新所述相应记录，其中，所述相应记录为与所述数据变更内容具有同一标识的记录；及

当其中一个数据变更内容在所述HUDI初始快照中不存在所述相应记录，则将该数据变更内容对应的新增记录添加到所述HUDI初始快照中。

6.根据权利要求1至5任意一项所述的数据实时捕获和传输方法，其特征在于，还包括：

监控以下一个或多个过程的数据输入量和数据输出量：

(1)将数据源的全量数据写入到分析系统中；

(2)将位于所述分析系统中的全量数据进行格式转换；

(3)将所述数据变更日志写入到消息队列系统中；及

(4)根据所述第一数据文件和所述消息队列系统中的数据变更日志，

获取支持实时更新的第二数据文件；

根据监控结果进行数据流的可视化处理，和/或判断所述一个或多个过程是否出现异常。

7.根据权利要求1至5任意一项所述的数据实时捕获和传输方法，其特征在于，所述日志系统为Kafka；将所述数据变更日志写入到消息队列系统中包括：

通过增量日志同步系统，将所述数据变更日志实时同步到所述Kafka的日志主题下。

8.一种数据实时捕获和传输系统，其特征在于，包括：

第一写入模块，用于将数据源的全量数据写入到分析系统中；

格式转换模块，用于将位于所述分析系统中的全量数据进行格式转换，得到支持实时更新的第一数据文件；

日志生成模块，用于捕获所述数据源中的多个数据变更事件，并根据所述多个数据变更事件生成数据变更日志；

第二写入模块，用于将所述数据变更日志写入到消息队列系统中；及

文件获取模块，用于根据所述第一数据文件和所述消息队列系统中的数据变更日志，获取支持实时更新的第二数据文件。

9.一种计算机设备，所述计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时用于实现权利要求1至7任一项所述数据实时捕获和传输方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时用于实现权利要求1至7任一项所述数据实时捕获和传输方法的步骤。

Images