CN115203336A - 数据库数据实时同步方法、系统、计算机终端及存储介质 - Google Patents

Abstract

本发明属于数据处理技术领域，尤其涉及一种数据库数据实时同步方法、系统、计算机终端及存储介质，该方法包括：监听并读取当前数据库的日志数据，并将所述日志数据存入kafka集群的消息集合中；通过数据读取插件获取所述消息集合中的日志数据，并对所述日志数据进行数据清洗；根据下游数据库的类型，将经过数据清洗得到的日志数据解析成对应的格式，并写入所述下游数据库。通过利用kafka集群获取数据库的日志数据，人后对日志数据的处理，获取对下游数据库进行同步的数据格式，进行数据库数据同步。

Description

数据库数据实时同步方法、系统、计算机终端及存储介质

技术领域

本发明涉及数据处理技术领域，尤其涉及一种数据库数据实时同步方法、系统、计算机终端及存储介质。

背景技术

传统Oracle数据库OGG（Oracle GoldenGate，异构数据集成）/ADG（Advanced DataGuarding，高级数据保护）方案无法进行数据二次加工,只能实现端到端数据同步，对于上游数据如果有清洗的需求则需要复杂的SQL整合与拼接，也缺失数据二次加工的能力，且价格昂贵。随着数据规模的增加，会增大存储成本，内置组件透明，无法满足用户对数据进行整合和深度加工的需求，ADG虽然也可承担一定的数据同步能力，但考虑其是容灾方案的选择，数据延迟比较大，同步数据基本上都会有T+1的延迟，且需要较长的时间修复故障，并不适合金融科技领域里为客户提供陪伴式服务，不利于向客户及时发送一些通知，无法在第一时间同步实施数据。

发明内容

第一方面，本申请提供一种数据库数据实时同步方法，应用于分布式数据库集群中的数据同步，包括：

监听并读取当前数据库的日志数据，并将所述日志数据存入kafka集群的消息集合中；

通过数据读取插件获取所述消息集合中的日志数据，并对所述日志数据进行数据清洗；

根据下游数据库的类型，将经过数据清洗得到的日志数据解析成对应的格式，并写入所述下游数据库。

进一步的，所述根据下游数据库的类型，将经过数据清洗的所述日志数据解析成对应的格式，包括：

若所述下游数据库的类型为关系型数据库，则将所述日志数据解析成SQL语句；

若所述下游数据库的类型为非关系型数据库，则将所述日志数据解析成POJO对象，并进行序列化处理。

进一步的，所述写入所述下游数据库，包括：

写入所述下游数据库的数据池或数据仓库中；

所述写入所述下游数据库之后，还包括：

更新所述消息集合中的补偿信息，所述补偿信息用于对出现异常故障的组件进行数据恢复。

进一步的，所述监听并读取数据库的日志数据，并将所述日志存入消息集合中，包括：

通过kafka-connector-oracle插件监听并获取所述日志数据，将所述日志数据转换成预设格式，存放到消息集合中；

所述日志数据包括重做日志和回滚日志。

进一步的，所述预设格式为JSON格式。

进一步的，所述通过数据读取插件获取所述消息集合中的日志数据，包括：

通过kafka-oracle-sink插件监听多个所述消息集合，实时获取所述日志数据。

进一步的，所述对所述日志数据进行数据清洗，包括：

通过sync-factory插件对所述日志数据进行清洗和格式化加工，并解析所述日志数据，形成摘要数据或宽表数据，所述摘要数据或宽表数据用于写入所述下游数据库。

第二方面，本申请还提供一种数据实时同步系统，包括：核心数据库、kafka集群和若干个下游数据库，所述核心数据库设置于核心系统内；

当需要进行数据同步时，所述kafka集群用于监听并读取所述核心数据库的日志数据，并将所述日志数据存入所述kafka集群的消息集合中；

所述kafka集群通过数据读取插件，获取所述消息集合中的日志数据，并对所述日志数据进行数据清洗；

所述kafka集群根据各个所述下游数据库的类型，将经过数据清洗得到的日志数据解析成对应的格式，并写入各个所述下游数据库中。

第三方面，本申请还提供一种计算机终端，包括处理器和存储器，所述存储器存储有计算机程序，所述计算机程序在所述处理器上运行时执行所述的数据库数据实时同步方法。

第四方面，本申请还提供一种可读存储介质，其存储有计算机程序，所述计算机程序在处理器上运行时执行所述的数据库数据实时同步方法。

本发明实施例公开了数据库数据实时同步方法、系统、计算机终端及存储介质，该方法包括：监听并读取当前数据库的日志数据，并将所述日志数据存入kafka集群的消息集合中；通过数据读取插件获取所述消息集合中的日志数据，并对所述日志数据进行数据清洗；根据下游数据库的类型，将经过数据清洗得到的日志数据解析成对应的格式，并写入所述下游数据库。因此，本发明提供的数据库数据实时同步方法可以支持任何数据组件的接入。并且相较于现有的存储方案，本申请通过kafka集群获取日志数据，再通过日志数据进行数据同步，避开了使用数据库内置的解决方案，同时通过kafka集群更容易去处理这些数据，并且减轻数据库的负担，避免因为数据规模达到一定量级，需要增大成本的问题。本申请可以通过低廉的存储设备支持超大规模的数据量存储，并避免使用Oracle数据库内置方案，节约了存储成本。

附图说明

为了更清楚地说明本发明的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对本发明保护范围的限定。在各个附图中，类似的构成部分采用类似的编号。

图1示出了本申请实施例一种数据库数据实时同步系统结构示意图；

图2示出了本申请实施例一种数据库数据实时同步方法流程示意图；

图3示出了本申请实施例数据流的处理流程示意图；

图4示出了本申请实施例一种数据库数据实时同步装置结构示意图。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。

通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

在下文中，可在本发明的各种实施例中使用的术语“包括”、“具有”及其同源词仅意在表示特定特征、数字、步骤、操作、元件、组件或前述项的组合，并且不应被理解为首先排除一个或更多个其它特征、数字、步骤、操作、元件、组件或前述项的组合的存在或增加一个或更多个特征、数字、步骤、操作、元件、组件或前述项的组合的可能性。

此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

除非另有限定，否则在这里使用的所有术语(包括技术术语和科学术语)具有与本发明的各种实施例所属领域普通技术人员通常理解的含义相同的含义。所述术语(诸如在一般使用的词典中限定的术语)将被解释为具有与在相关技术领域中的语境含义相同的含义并且将不被解释为具有理想化的含义或过于正式的含义，除非在本发明的各种实施例中被清楚地限定。

本申请的技术方案应用于如金融科技及其他领域中的数据库的数据同步，如实时更新当前最新的期货数据，更新产品赎回申购等信息，这些数据一般存储在核心系统中，为了将这些信息实时同步到其他关联方，需要将这些数据从核心系统同步到各个关联方的数据源中，然后再根据用户的需要予以显示。

本申请通过对数据库日志数据的监听和读取，数据库中的日志会记录数据库中各个数据或者结构的变化，可以根据日志内容确定同步的数据内容。同时还会对日志数据进行关联清洗和二次清洗，然后将日志解析成对应的文件格式，再根据下游数据库的类型，将这些数据同步过去。

如图1所示，为本申请整个数据库数据实时同步系统结构示意图，该系统包括核心系统100、核心数据库110，kafka集群200和若干个下游数据库300。

核心系统100中设置有核心数据库110，核心系统100可以是银行系统或者各种金融机构的系统，该核心系统100主要是用于生成和更新当前最新的各个金融信息，这些信息会存储在核心数据库110中。这些信息即可以是金融信息，也可以是各种交易信息，例如基金产品的价格、开放日、波动比例之类的。这些信息对于用户来讲，越是早知道，越是有利，因此需要尽快的同步到各个下游数据库300中，而同步时则需要处理大量的数据，并且还需要注意清洗脏数据以及数据重构等操作。

下游数据库300可以是关系型数据库或者非关系式数据库等多种数据库，这些数据库可以隶属于各种客户，例如核心系统隶属银行，那么下游数据库则隶属于各个投资机构或者各地网点等，例如各种炒股炒基金的软件的数据库，或者分行的数据库。具体而言，这些数据库种类可以是Oracle/MySQL/MS SQLServer/PostGre等。

可以理解的是，下游数据库之间也会有层级关系，如核心数据库110为银行系统中的数据库，而银行各地网点的网点数据库作为核心数据库110的下游数据库，直接从核心数据库中获取同步数据，是二级数据库，同时也存在其他和各地网点进行合作的金融公司的数据库，这些金融公司的数据库从网点数据库中获取同步数据，是这些网点数据库的下游数据库，在整个系统中是三级数据库。以此类推，还会有四级数据库五级数据库之类的层级关系。也就是说本申请的数据同步方法可以用于任何拥有下游数据库的数据库。

kafka集群200通过数据读取插件，获取所述消息集合中的日志数据，并对所述日志数据进行数据清洗，并根据各个所述下游数据库的类型，将经过数据清洗得到的日志数据解析成对应的格式，并写入各个所述下游数据库中。

Kafka集群是一个分布式消息系统，一般用于分布式状态管理、分布式协调管理、分布式配置管理和分布式锁服务等，其可以通过订阅的方式，获取各个topic的消息内容，并利用topic来对消息进行组织，以起到对消息的传递和控制，本身是一个消息控制和消息传递的系统，是独立于核心数据库存在的一个消息处理系统，本申请通过kafka的消息处理能力，将来自数据库的日志作为消息进行处理整合，再通过消息分布式管理的方式进行数据同步，实现了数据库数据的实时同步。

接下来以具体实施例，说明本申请的技术方案。

实施例1

如图2所示，本申请的技术方案包括以下步骤：

步骤S100，监听并读取当前数据库的日志数据，并将所述日志数据存入kafka集群的消息集合中。

本申请中的当前数据库可以是核心数据库，也可以是上述的二级数据库等需要将本数据库的数据同步到下游数据库的数据库。为了方便说明，本实施例以核心数据库作为当前数据库说明本申请的技术方案。

为了可以在数据库的内容发生更新时，可以快速实时的将更新的数据同步到下游数据库，需要实时监听数据库的动态，为此，监听数据库的日志数据可以知道数据库的变化。

本实施例日志数据包括redo（重做）日志和undo（回滚）日志，undo日志记录所有的前操作，用于数据库回滚，redo日志记录所有的操作，可以用于数据库恢复。通过这两个日志，可以整体把握数据库的数据更新状态，在本实施例中，主要是从这两个日志里获取核心数据库所发生的一些列数据变化。

本实施例中，核心数据库110可以是oracle数据库系统，也可以是其他的分布式数据库系统等，并且为了使得日志数据可以生成，需要数据库开启归档机制，再通过Logminer工具来进行日志分析，生成对应的redo日志和undo日志。

生成的日志需要实时获取，为此，可以使用kafka-connector-oracle这个插件就是用来进行连接和数据读取的，可以使用该插件进行实时读取，以获取最新的日志数据。获取的日志会存入kafka集群中消息集合中。

本申请的kafka集群其主要是用于对来自核心数据库110中的日志数据进行解析，针对各个更新数据进行处理。

kafka-connector-oracle插件是用于读取oracle数据库的日志内容的插件，通过将插件解压到指定目录下，通过命令行即可激活打开对应的日志读取功能。

本实施例的消息集合是kafka集群下的topic，这里的消息集合是预先创建好的，可以理解的是，根据数据体量和数据类别等因素，消息集合的数量可以有多个。

本申请topic可以是connect-offsets或connect-configs或connect-status。

其中，获取到的日志数据还会转换成预设格式后，再存放到消息集合中，这里的预设格式可以是json格式或者avro格式等标准化格式。

可以理解，因为将日志解析成类似json这类标准化格式的数据，所以对于各种类型的数据源都可以进行对接，不会有兼容性的问题。

具体而言，当数据库里出现数据变更时，例如基金的产品信息里的价格发生变更，则Logminer工具会产生对应的日志数据，这些日志数据被kafka-connector-oracle插件监听获取，并存储到消息集合中，这些消息集合为kafka下的topic，且还将日志数据进行了格式化处理，成为json格式的数据，将日志数据从单纯的oracle数据库系统中剥离出来，从而避过了传统OGG的管控。

显然该消息集合中会包含该价格的变动，这些数据就是接下来需要同步到其他下游数据库300的数据。

步骤S200，通过数据读取插件获取所述消息集合中的日志数据，并对所述日志数据进行数据清洗。

在上一个步骤中，从数据库内读取的日志数据被存入了消息集合中，该消息集合是kafka下的topic，则可以通过数据读取插件进行数据读取，具体而言，针对oracle数据库，可以是通过kafka-oracle-sink插件这类插件来监听这些topic的数据，以实时获取所述日志数据，并解析所述日志数据。

因为kafka-oracle-sink可以同时监听多个topic，也就是说可以同时间获取多个更新后的日志数据，了解新数据的内容。同时因为获取的是日志数据，其带有明确的时间信息，因此也不会被旧的数据内容影响。

同时，因为可以监听多个topic，获取多个类别的日志数据，因此也可以从全局的角度，对复杂的数据进行整合与拼接。

得到日志数据后，还会对这些日志数据进行解析，如上一步所述，日志数据被整合成了json或者avro这类标准化的格式数据，因此，只需要从这些格式中提取主要关键的数据，即最新的需要同步到各地的数据内容就可以进行接下来的同步操作。

例如，一个基金产品中，包含当前价格、历史价格等这些价格相关的数据，也会包括历任基金经理和基金内相关投资占比等数据，这些不同类型的数据会存储在不同的topic上，而对于前段客户可能有一些客制化需求，要将这些不同类型的数据关联显示。例如每个基金经理的任期内，基金的价格走势等，为此就需要将这些数据进行整合拼接，以生成多维度报表，同时要避免出现错误，而因为可以同时获取多个topic下的日志数据，因此可以将多个不同类型的数据进行整合和拼接。

可以理解的是，在获取了多个topic中的日志数据后，若是对数据有清洗的需求，也可以在所有topic中的日志数据的基础上，进行数据清洗，保证数据清洗的效率。

在获取日志数据后，对数据的清洗可以是通过kafka中的sync-factory插件来进行，该插件可以同步所有topic内的日志数据，以实现对所有数据的清洗。

除了清洗外，还会对这些日志数据进行加工形成摘要数据或宽表数据。即对这些日志数据进行解析，以形成各业务方想要的字段，即各种最终显示给用户时的样式，可以理解的是，不同的客户方，针对同样的数据，会有不同的显示需求，最终显示给用户的表格图表之类的也会不同，因此这里会需要对这些数据进行加工处理，形成各个下游数据库所需要的数据类型。

如图3所示，图中的核心系统可以是银行金融系统，该系统中存储了各种理财产品的信息，并且这些理财产品的信息第一时间是会在核心系统的数据库中更新的。核心系统中的数据库可以是Oracle，其更新后的日志数据会被读取到kafka集群中，也就是上述步骤S100中，通过kafka-connector-oracle来获取日志数据，这样所需要更新的数据以日志的形式在另一个集群中被存储，然后这些数据经过本步骤的处理后，才执行后续的下发操作。可以理解的是，本申请的方案脱离了orcale数据库的ogg方案，通过kafka消息集群，实现了对更新数据的获取后处理，不需要再在数据库内部进行同步操作，并且因为独立于数据库，对于数据的处理更加方面快捷。

步骤S300，根据下游数据库的类型，将经过数据清洗得到的日志数据解析成对应的格式，并写入所述下游数据库。

因为下游数据库的类型驳杂，不可能所有的数据源和核心系统所使用的数据库相同，因此需要针对这些不同的数据源，生成不同的数据对象，以成功将这些日志数据中的更新数据同步到这些数据源中。

例如，若所述下游数据库的类型为关系型数据库，则将所述日志数据解析成SQL语句。可以理解的是，要对关系型数据库进行更新，可以使用SQL语句的插入、删除等方式进行处理，以更新这类数据库内的数据。

若所述下游数据库的类型为大数据组件或分布式存储系统中的一种，则将所述日志数据解析成POJO(Plain Ordinary Java Object，简单java对象)对象，并进行序列化推送。针对大数据组件或分布式存储系统，可以将上述经过清洗处理的日志数据解析成POJO对象，最终存储到data warehouse（数据仓库）或者data Lake（数据池）中。

在本步骤中，可以通过配置项sync.plugin.dialect来指定所需要存入的数据源。这里针对可以进行同步的数据源来讲，只要配置了相应的dialect，即可选择对应的数据源进行写入。例如sync.plugin.dialect=fhive，程序会根据这个配置项，加载对应的hive-plugin插件，然后将数据推送到配置的hive数据源中。针对多个数据源，只要对多个数据源进行依次配置，即可完成数据的写入。同时，加载的插件类型和上述配置项相关，可以通过配置项的值，确定数据源的类型，从而确定该将上述的日志数据解析成怎样的数据库操作方法。

其中上述的hive-plugin需要根据数据源的类型扩展实现，除了hive外，也可以是jdbc，hbase，doris，druid，es，spark这些类型。针对不同的数据源实现各自的扩展，系统启动时，这些都会加载到内存中，当需要对下游数据库进行写入时，会根据数据源的类型进行匹配，以获取对应的sync.plugin.dialect，从而触发对应的plugin插件，然后再将上述日志数据解析成对应的格式，进行数据源的操作更新。

在写入完毕后，还会更新kafka topic中的补偿信息，即offset中，并持久化到本地，当如kafka-sync或 sync-factory组件发生异常故障，可随时从offset处恢复数据读取点，保证数据不丢失。

可以理解的是，上述更新所存储的补偿信息为一次同步时所同步的数据内容，因此当上述组件发生故障，可以根据这一次同步的内容进行数据恢复，因为下游数据库的数据其实都是从kafka集群中同步过去的，因此只要通过offset进行恢复，修复了这些组件的异常，那么也可以快速的修复因为这些异常带来的同步问题。

如图3所示，本步骤将经过数据处理后的数据发送给了下游数据库，完成了对数据的同步，整个过程中，通过kafka这个分布式消息系统，使得快速的数据获取与数据处理成为了可能，并且不必受制于ogg方案本身的不足。同时因为是独立于数据库的系统，易于二次开发，不会对数据库本身进行大范围的修改操作。

此外，其支持的数据源种类丰富，并且在获取日志后，采用标准的json或者avro格式进行处理，因此可以支持任何数据组件接入，因此可以根据用户的需求，基于原始数据进行任意下游数据库的接入。

以实际的金融系统更新为例，当系统中更新了某个理财产品的数据后，需要对客户进行新数据的显示，为此，从核心系统中需要将该数据同步到各个关联下游数据库中。核心系统是银行，则下游数据库可以是各个机构的数据库，例如，不同的用户会使用不同的平台对同一个基金进行操作，则这些数据需要发送给不同的平台。当核心系统更新数据后，其数据库内会产生日志数据，这些日志数据通过kafka-connector-oracle获取到kafka集群中，在kafka集群中进行处理，再根据下游数据库的类型，生成对应的数据库操作方法，对各个数据源进行更新，完成对各个下游数据库的数据同步。

本申请的数据库数据实时同步方法，通过使用kafka消息集群以及对应的插件，对数据库的日志进行获取，以得到数据库内的更新数据，将这些日志数据作为消息进行处理。从而在第三方的kafka消息集群中，实现对这些日志数据进行对应的清洗、整合、格式化等处理，因为是将所有的日志消息进行整合处理，可以避开在数据库系统中进行数据处理的麻烦，并且从日志数据中获取更新数据后，也可以对这些数据进行清洗操作，并可以对所有数据进行这呢个，然后再将这些数据根据下游数据库的类型，生成对应的数据样式，如SQL语言或者POJO对象。以内通过消息传递的方式进行数据同步，速度快捷，并且在写入后还会将数据在kafka集群本地进行持久化，以在组件出现意外故障时可以恢复。因为实际的更新数据全在kafka消息集群中，数据也可以来自多个消息集合，因此可以对这些数据进行清洗和客制化处理，具有很好的延展性，并且避免使用昂贵的OGG方案，且易于二次开发，可以基于该方案对特定的业务场景进行定制，在金融行业中有较高的适配度。并且因为将日志数据格式化成对应的json这些数据，可以支持任何数据组件的接入。并且相较于现有的存储方案，一旦数据规模达到一定量级，需要增大成本，本申请的方案通过kafka中的sync，可以将数据同步到数据仓库或者分布式数据库中，可以通过低廉的存储设备支持超大规模的数据量存储，进而节约的存储成本。

实施例2

本申请还提供一种基于kafka的数据实时同步装置，如图4所示，包括：

监听模块10，监听并读取当前数据库的日志数据，并将所述日志数据存入kafka集群的消息集合中；

数据处理模块20，通过数据读取插件获取所述消息集合中的日志数据，并对所述日志数据进行数据清洗；

更新模块30，根据下游数据库的类型，将经过数据清洗得到的日志数据解析成对应的格式，并写入所述下游数据库。

本申请还提供一种计算机终端，包括处理器和存储器，所述存储器存储有计算机程序，所述计算机程序在所述处理器上运行时执行所述的数据库数据实时同步方法。

该计算及终端可以是上述核心系统的服务器，用于管理数据库的电脑，或者是中控电脑。

本申请还提供一种可读存储介质，其存储有计算机程序，所述计算机程序在处理器上运行时执行所述的数据库数据实时同步方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和结构图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，结构图和/或流程图中的每个方框、以及结构图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本发明各个实施例中的各功能模块或单元可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或更多个模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是智能手机、个人计算机、服务器、或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。

Claims (10)

1.一种数据库数据实时同步方法，应用于分布式数据库集群中的数据同步，其特征在于，包括：

监听并读取当前数据库的日志数据，并将所述日志数据存入kafka集群的消息集合中；

通过数据读取插件获取所述消息集合中的日志数据，并对所述日志数据进行数据清洗；

根据下游数据库的类型，将经过数据清洗得到的日志数据解析成对应的格式，并写入所述下游数据库。

2.根据权利要求1所述的数据库数据实时同步方法，其特征在于，所述根据下游数据库的类型，将经过数据清洗得到的日志数据解析成对应的格式，包括：

若所述下游数据库的类型为关系型数据库，则将所述日志数据解析成SQL语句；

若所述下游数据库的类型为非关系型数据库，则将所述日志数据解析成POJO对象，并进行序列化处理。

3.根据权利要求1或2所述的数据库数据实时同步方法，其特征在于，所述写入所述下游数据库，包括：

写入所述下游数据库的数据池或数据仓库中；

所述写入所述下游数据库之后，还包括：

更新所述消息集合中的补偿信息，所述补偿信息用于对出现异常故障的组件进行数据恢复。

4.根据权利要求1所述的数据库数据实时同步方法，其特征在于，所述监听并读取当前数据库的日志数据，并将所述日志数据存入kafka集群的消息集合中，包括：

通过kafka-connector-oracle插件监听并获取所述日志数据，将所述日志数据转换成预设格式，存放到消息集合中；

所述日志数据包括重做日志和回滚日志。

5.据权利要求4所述的数据库数据实时同步方法，其特征在于，所述预设格式为JSON格式。

6.根据权利要求1所述的数据库数据实时同步方法，其特征在于，所述通过数据读取插件获取所述消息集合中的日志数据，包括：

通过kafka-oracle-sink插件监听多个所述消息集合，实时获取所述日志数据。

7.根据权利要求1所述的数据库数据实时同步方法，其特征在于，所述对所述日志数据进行数据清洗，包括：

通过sync-factory插件对所述日志数据进行清洗和格式化加工，并解析所述日志数据，形成摘要数据或宽表数据，所述摘要数据或宽表数据用于写入所述下游数据库。

8.一种数据实时同步系统，其特征在于，包括：核心数据库、kafka集群和若干个下游数据库，所述核心数据库设置于核心系统内；

当需要进行数据同步时，所述kafka集群用于监听并读取所述核心数据库的日志数据，并将所述日志数据存入所述kafka集群的消息集合中；

所述kafka集群通过数据读取插件，获取所述消息集合中的日志数据，并对所述日志数据进行数据清洗；

所述kafka集群根据各个所述下游数据库的类型，将经过数据清洗得到的日志数据解析成对应的格式，并写入各个所述下游数据库中。

9.一种计算机终端，其特征在于，包括处理器和存储器，所述存储器存储有计算机程序，所述计算机程序在所述处理器上运行时执行权利要求1至7中任一项所述的数据库数据实时同步方法。

10.一种可读存储介质，其特征在于，其存储有计算机程序，所述计算机程序在处理器上运行时执行权利要求1至7中任一项所述的数据库数据实时同步方法。

Images