CN114356945A - 数据处理方法、装置、计算机设备和存储介质 - Google Patents
数据处理方法、装置、计算机设备和存储介质 Download PDFInfo
- Publication number
- CN114356945A CN114356945A CN202210003312.2A CN202210003312A CN114356945A CN 114356945 A CN114356945 A CN 114356945A CN 202210003312 A CN202210003312 A CN 202210003312A CN 114356945 A CN114356945 A CN 114356945A
- Authority
- CN
- China
- Prior art keywords
- data
- source
- source data
- incremental
- null
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请涉及一种数据处理方法、装置、计算机设备、存储介质和计算机程序产品。所述方法包括：获取各源系统中的增量源数据；将增量源数据与源系统快照数据进行匹配，识别增量源数据的数据状态，源系统快照数据包括有获取增量源数据之前，从各源系统中获取的源数据的属性信息；根据增量源数据的数据状态，修正增量源数据，获得修正源数据；基于配置的业务元数据，将修正源数据进行规范化处理，获得规范化后的修正源数据，并发布规范化后的修正源数据，业务元数据包括修正源数据的元数据及其属性元数据。采用本申请实施例的方法，能够确保数据的规范性和有效性，提高数据处理的效率。
Description
技术领域
本申请涉及数据处理技术领域，特别是涉及一种数据处理方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。
背景技术
为了满足核电各类业务的需要，建立了大量的业务源系统，产生了各种各样的业务数据。随着核电各类业务的深入开展，往往需要应用某一对象的跨业务主题的数据，而这些数据可能会来自不同的源系统。
目前，为了获取分散在各源系统之间的数据，一般是在源系统之间进行数据层面的同步，建立很多数据同步的接口，以使各源系统之间的数据能够流转，然而，这种方式的接口数量与源系统数量呈指数关系，数据开发和维护的工作量很大，而且无法确保数据的规范性和有效性，导致数据处理效率不高。
发明内容
基于此，有必要针对上述技术问题，提供一种能够提高数据处理效率的数据处理方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。
一种数据处理方法，所述方法包括：
获取各源系统中的增量源数据；
将所述增量源数据与源系统快照数据进行匹配，识别所述增量源数据的数据状态，所述源系统快照数据包括有获取所述增量源数据之前，从各所述源系统中获取的源数据的属性信息；
根据所述增量源数据的数据状态，修正所述增量源数据，获得修正源数据；
基于配置的业务元数据，将所述修正源数据进行规范化处理，获得规范化后的修正源数据，并发布规范化后的所述修正源数据，所述业务元数据包括所述修正源数据的元数据及其属性元数据。
在其中一个实施例中，所述获取各源系统中的增量源数据，包括：
确定技术元数据中配置的增量数据同步方案；
根据所述增量数据同步方案，从各所述源系统中获取所述增量源数据。
在其中一个实施例中，所述将所述增量源数据与源系统快照数据进行匹配，识别所述增量源数据的数据状态，包括：
确定所述增量源数据的属性信息；
将所述增量源数据的属性信息，与所述源系统快照数据进行匹配，确定所述增量源数据的数据状态，所述数据状态包括是否更新、主键是否变化、是否为物理删除中的任意一种。
在其中一个实施例中，所述根据所述增量源数据的数据状态，修正所述增量源数据，获得修正源数据，包括：
若所述增量源数据的数据状态为主键变化，根据所述源系统快照数据，确定所述增量源数据对应的更新前数据；
恢复所述更新前数据，并将所述更新前数据的数据状态设置为删除，所述修正源数据包括所述增量源数据与所述更新前数据。
在其中一个实施例中，在所述获得规范化后的修正源数据之后，在所述发布规范化后的所述修正源数据之前，包括：
对所述规范化后的所述修正源数据进行数据预处理，得到预处理后的规范化后的所述修正源数据，所述数据预处理包括数据去重处理和数据清洗处理中的至少一种。
在其中一个实施例中，所述增量源数据存储在数据缓存区，所述源系统快照数据存储在数据快照区；
在所述获得修正源数据之后，所述方法还包括：
将所述修正源数据更新至所述数据快照区，并清空所述数据缓存区。
一种数据处理装置，所述装置包括：
获取模块，用于获取各源系统中的增量源数据；
识别模块，用于将所述增量源数据与源系统快照数据进行匹配，识别所述增量源数据的数据状态，所述源系统快照数据包括有获取所述增量源数据之前，从各所述源系统中获取的源数据的属性信息；
修正模块，用于根据所述增量源数据的数据状态，修正所述增量源数据，获得修正源数据；
发布模块，用于基于配置的业务元数据，将所述修正源数据进行规范化处理，获得规范化后的修正源数据，并发布规范化后的所述修正源数据，所述业务元数据包括所述修正源数据的元数据及其属性元数据。
一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述的数据处理方法的步骤。
一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的数据处理方法的步骤。
一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述的数据处理方法的步骤。
上述数据处理方法、装置、计算机设备、存储介质和计算机程序产品，获取各源系统中的增量源数据；将增量源数据与源系统快照数据进行匹配，识别增量源数据的数据状态，源系统快照数据包括有获取增量源数据之前，从各源系统中获取的源数据的属性信息；根据增量源数据的数据状态，修正增量源数据，获得修正源数据；基于配置的业务元数据，将修正源数据进行规范化处理，获得规范化后的修正源数据，并发布规范化后的修正源数据，业务元数据包括修正源数据的元数据及其属性元数据。采用上述实施例的方法，通过获取源系统增量更新的增量源数据并进行后续处理，能够避免在源系统中进行数据转换，减轻源系统的负载，提高数据集成的效率，通过源系统快照数据识别增量源数据的具体变化情况，并对增量源数据进行规范化处理后发布，能够确保数据的规范性和有效性，提高数据处理的效率。
附图说明
图1为一个实施例中数据处理方法的应用环境图；
图2为一个实施例中数据处理方法的流程示意图；
图3为一个实施例中获取源系统中的增量源数据的示意图；
图4为一个实施例中对数据进行数据清洗的示意图；
图5为一个实施例中对数据进行参数化和配置化的示意图；
图6为一个具体实施例中计算机设备的内部层次划分的示意图；
图7为一个具体实施例中数据处理方法的整体方案的示意图；
图8为一个具体实施例中数据处理方法的示意图；
图9为另一个具体实施例中数据处理方法的示意图；
图10为一个实施例中数据处理装置的结构框图；
图11为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
在其中一个实施例中，本申请提供的数据处理方法，可以应用于如图1所示的应用环境中。其中，设备102通过网络与服务器104进行通信。数据存储系统可以存储服务器104需要处理的数据。数据存储系统可以集成在服务器104上，也可以放在云上或其他网络服务器上。
具体地，服务器104获取设备102中的源系统中的增量源数据；将增量源数据与源系统快照数据进行匹配，识别增量源数据的数据状态，源系统快照数据包括有获取增量源数据之前，从各源系统中获取的源数据的属性信息；根据增量源数据的数据状态，修正增量源数据，获得修正源数据；基于配置的业务元数据，将修正源数据进行规范化处理，获得规范化后的修正源数据，并发布规范化后的修正源数据，业务元数据包括修正源数据的元数据及其属性元数据。
其中，设备102可以用独立的终端或者是多个终端组成的终端集群来实现，终端可以但不限于是各种个人计算机、智能手机、平板电脑、物联网设备和便携式可穿戴设备，物联网设备可为智能电视、智能空调、智能车载设备等，便携式可穿戴设备可为智能手表、智能手环等。设备102还可以采用独立的服务器或者是多个服务器组成的服务器集群来实现。服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
在传统方式中，为了获取分散在各源系统上的数据，一种方式是在源系统之间进行数据层面的同步，建立各源系统之间的数据同步的接口，以使各源系统在本系统内就能使用其他源系统的数据。
然而，此方式存在以下问题：其一，点对点接口开发模式导致数据接口数量与源系统的数量呈指数关系，开发、维护工作量巨大，仅解决了源系统之间的数据流转问题，源数据仍然存放在各自的系统之中，不利于数据的综合应用。其二，在各源系统中若存在重复的数据，无法确认哪个数据是有效数据，且不同的源系统中相同数据的语义、值域等可能不一致，即数据规范不一致，数据同步的越多，会造成更多的数据规范性和有效性问题。
传统方式中的另一种方式是建立统一的数据库，使用ETL技术进行数据集成。需要针对不同的源数据，建立数据规范后，创建与之相关的数据库表，进行数据ETL操作，在此过程中进行相同数据的去重、整合和规范。其中，ETL(Extract-Transform-Load)用来描述将数据从源数据端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程。
然而，此方式存在以下问题：其一，在数据集成前对每种类型的源数据都需要进行数据规范，并建立相关的数据库表，在数据ETL过程中也会用到这些数据规范，数据规范与数据库表、数据处理过程强耦合。源数据的类型多则会造成开发工作量巨大。每新增一类数据集成，则需要将ETL过程重新开发一次。其二，核电业务往往多变，造成源数据结构发生变化，数据规范也会随之发生变化，进而导致数据库表、ETL过程的巨大变化，导致数据集成的维护工作巨大。其三，数据集成过程与源数据强耦合，无法进行参数化、配置化的开发。
在其中一个实施例中，为了解决上述问题，如图2所示，提供了一种数据处理方法，以该方法应用于图1中的服务器104为例进行说明，包括：
步骤S202，获取各源系统中的增量源数据。
在其中一个实施例中，源数据是指核电各类业务数据，源数据存储在源系统中，源系统也可以称为是业务系统或业务源系统。其中，源系统可以是自主开发的系统，也可以是商业采购的系统，不同的源系统中存储的源数据的数据结构、语义等往往有很大区别。
具体地，源系统将源数据存储在数据库中，数据库可以但不限于是关系型数据库、非关系型数据库和键值数据库系统等，具体可以包括Oracle数据库、Sqlserver数据库等。其中，sql是一种结构化查询语言，用于存取数据以及查询、更新和管理关系型数据库系统。
在其中一个实施例中，随着核电各类业务的不断开展，源数据在不断地产生，源系统的数据库中的源数据会不断地更新，将源系统中更新的源数据称为增量源数据。其中，数据库的更新方式为全量更新和增量更新中的其中一种。因此，为了有效提高数据获取的效率，仅获取各源系统中的增量源数据即可。
具体地，在获取各源系统中的增量源数据之前，还包括：获取各源系统中的源数据，即初次加载源数据，以便根据初次加载的源数据确定是否产生了增量源数据，在产生了增量源数据的情况下才会进行增量更新。即本申请实施例中的初次加载源数据是采用全量更新的方式，而后加载源数据以增量更新的方式进行，以此将全量更新与增量更新进行统一，减少源系统的复杂度，提高后续的数据处理效率。
在其中一个实施例中，增量源数据为预设时间窗口内变化的源数据。其中，初次加载源数据时，时间窗口的起始时间设置为源系统中最早的时间初始值。获取各源系统中的增量源数据的过程，也可以称为数据抽取过程，获取预设时间窗口内变化的源数据，也即根据预设时间间隔对源系统内的数据进行抽取，获得增量源数据。
具体地，获取各源系统中的增量源数据，包括：确定技术元数据中配置的增量数据同步方案；根据增量数据同步方案，从各源系统中获取增量源数据。
其中，在初次加载了源数据之后，可以根据源数据确定技术元数据。技术元数据是元数据的一种，技术元数据是指数据仓库的设计和管理人员用于开发和日常管理数据库时使用的数据，可以用于支撑数据抽取过程的运行，对于源系统的各类源数据的数据抽取方式等进行配置，即基于技术元数据可以确定源系统对应的数据抽取方式。
在其中一个实施例中，本申请实施例中将技术元数据规范为技术元数据表，技术元数据表包括：字段，字段对应的类型、说明、主键信息、索引信息、分布键信息、可否为空信息以及备注信息。字段、字段对应的类型、可否为空信息均以英文进行表示。主键信息用于表示该字段是主键，或不是主键。
其中，字段包括：系统代理键值、数据状态、数据库连接地址、服务器机器名、源数据编码、源系统代码、源数据对应的业务类型、数据同步类型、数据同步信息、抽取数据的sql语句、创建日期、创建人员工号、创建人姓名、修改日期、修改人员工号和修改人姓名。
其中，系统代理键值即源系统对应的主键的键值，主键即主关键字(primarykey)，可以由一个或多个字段共同组成，其可以唯一的确定技术元数据表中的一行数据，或者可以唯一确定一个实体，主键的列不能包含空值，主键是可选的，具体可以根据实际技术需要进行定义。数据状态包括删除、未生效和生效，数据状态以数值表示，具体可以根据实际技术需要进行设置，一个实施例中删除表示为0，未生效表示为1，生效表示为1000。数据库连接地址(url)可以使用ip地址。源数据编码可以用于建立临时表，也是源数据的位移索引，具体可以根据实际技术需要进行编码。源系统代码可以用于标识源系统，具体可以根据实际技术需要进行设置，一个实施例中表示为aed、emp等。数据同步类型包括时间戳和更改跟踪中的任意一种，其可以以数值进行表示，具体可以根据实际技术需要进行设置，一个实施例中1表示时间戳，2表示更改跟踪。数据同步信息与数据同步类型相对应，包括同步日期或变更版本。其中，变更版本是更改跟踪中数据库数据更新的版本，每更新一次，版本会增加1。数据库会记录一定时间内每个版本变更对应的数据条目，通过数据库查询语句即可获取当前的变更版本。
其中，字段对应的类型包括：字符串/文本数据使用不区分大小写的数据类型citext、精确数值数据类型smallint、json数据类型中的jsonb类型、将数据库服务器所在的时间转化为当前时区的时间timestamp with time zone。
其中，Y表示是，N表示否。具体地，技术元数据表包括以下内容：
字段id、字段对应的类型为citext、说明为系统代理键值、主键信息为Y、索引信息为Y、分布键信息为Y、可否为空信息为N、备注信息为主键；
字段status、字段对应的类型为smallint、说明为数据状态、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为0：删除、1：未生效、1000：生效；
字段jdbc_url、字段对应的类型为citext、说明为数据库连接url、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为使用ip地址；
字段host_name、字段对应的类型为citext、说明为服务器机器名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段source_category、字段对应的类型为citext、说明为源数据编码、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为该编码用于建立临时表，唯一索引；
字段source_system_code、字段对应的类型为citext、说明为源系统代码、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为aed、emp等；
字段business_category、字段对应的类型为citext、说明为源数据业务类型、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段syn_type、字段对应的类型为smallint、说明为数据同步类型、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为1表示时间戳、2表示更改跟踪；
字段syn_info、字段对应的类型为citext、说明为数据同步信息、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为同步日期或变更版本；
字段extract_sql_statement、字段对应的类型为jsonb、说明为抽取数据的sql语句、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段create_date、字段对应的类型为timestamp with time zone、说明为创建日期、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段creator_num、字段对应的类型为citext、说明为创建人员工号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段creator_name、字段对应的类型为citext、说明为创建人姓名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modify_date、字段对应的类型为timestamp with time zone、说明为修改日期、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modifier_num、字段对应的类型为citext、说明为修改人员工号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modifier_name、字段对应的类型为citext、说明为修改人姓名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空。其中，技术元数据中配置的增量数据同步方案主要包括数据同步类型、数据同步信息以及抽取数据的sql语句。在确定技术元数据中配置的增量数据同步方案之后，根据增量数据同步方案，即可确定该源系统的数据抽取方式，即可对应抽取获取增量源数据。其中，将从各源系统中获取的增量源数据存储在数据缓存区中，将数据缓存区表示为t区。即，数据缓存区用于接收和存储从源系统抽取出来的增量源数据，
如图3所示为获取源系统中的增量源数据的示意图，具体地，根据增量数据同步方案，从各源系统中获取增量源数据，可以是根据时间戳获取更新数据，还可以是更改跟踪获取更新数据，更新数据即指增量源数据，并将获取的增量源数据存储在数据缓存区中，即存储在t区中。
其中，若是根据时间戳获取增量源数据，为了有效避免增量源数据遗漏，在获取增量源数据时，将时间戳增量更新的起始时间向前推预设时长，其中，预设时长可以根据实际技术需要进行设置，一个实施例中设置为30秒。
需要说明的是，为了节约存储空间，在每次增量源数据进行了数据处理后，即数据处理完成后，清空数据缓存区，以便下一次获取增量源数据。
步骤S204，将增量源数据与源系统快照数据进行匹配，识别增量源数据的数据状态，源系统快照数据包括有获取增量源数据之前，从各源系统中获取的源数据的属性信息。
在其中一个实施例中，将获取增量源数据之前，即初次加载源数据时，将从各源系统中获取的源数据的属性信息称为源系统快照数据。其中，将源系统快照数据存储在数据快照区中。具体地，数据快照区用于存放源系统数据的快照，即源系统快照数据，并通过json序列化的方式原样保存源数据库中的数据属性信息。数据快照区根据源数据库表的主键与数据缓存区中增量更新的增量源数据进行匹配后更新，同时识别数据是否发生修改以及主键是否变化。
具体地，本申请实施例中将数据快照区中的源系统快照数据规范为快照数据表，快照数据表包括：字段，字段对应的类型、说明、主键信息、索引信息、分布键信息、可否为空信息以及备注信息。字段、字段对应的类型、可否为空信息均以英文进行表示。
其中，字段包括：系统代理键、数据清洗标识、数据状态、源系统主键组合、业务对象分类、业务对象名、业务对象名(旧名)、业务对象单值属性json格式、业务对象多值属性json格式、业务对象aspect单值属性json格式、业务对象aspect多值属性json格式、创建日期、创建人员工号、创建人姓名、修改日期、修改人员工号和修改人姓名。
其中，系统代理键为Kettle使用uuid函数生成，非分布键，无法建立唯一索引，需要说明的是，Kettle是一种开源的ETL工具，主要用于数据库间的数据迁移。数据清洗标识包括失败和成功，清洗标识以数值表示，具体可以根据实际技术需要进行设置，一个实施例中失败表示为0，成功表示为1000。数据状态包括删除、修改和新增，数据状态以数值表示，具体可以根据实际技术需要进行设置，一个实施例中删除表示为0，修改表示为1，新增表示为2。源系统若是复合键，即源系统的主键并非一个字段，则源系统主键组合采用符号^进行分割，不同的源系统对应的主键是Y或是N组合起来。业务对象单值属性json格式对应源系统的代理键字段建立唯一索引。
其中，字段的类型包括：字符串/文本数据使用不区分大小写的数据类型citext、精确数值数据类型smallint、json数据类型中的jsonb类型、将数据库服务器所在的时间转化为当前时区的时间timestamp with time zone。
具体地，快照数据表包括以下内容：
字段etl_id、字段对应的类型为citext、说明为系统代理键、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为Kettle使用uuid函数生成，非分布键，无法建立唯一索引；
字段etl_clean_flag、字段对应的类型为smallint、说明为数据清洗标识、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为0：失败、1000：成功；
字段etl_status、字段对应的类型为smallint、说明为数据状态、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为0：删除、1：修改、2：新增；
字段entity_source_key、字段对应的类型为citext、说明为源系统主键组合、主键信息为Y、索引信息为Y、分布键信息为Y、可否为空信息为N、备注信息为源系统若是复合键，则使用符号'^'联合；
字段entity_category、字段对应的类型为citext、说明为业务对象分类、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段entity_name、字段对应的类型为citext、说明为业务对象名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段entity_name_old、字段对应的类型为citext、说明为业务对象名(旧名)、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段entity_attribute_s、字段对应的类型为jsonb、说明为业务对象单值属性json格式、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为对应源系统的代理键字段建立唯一索引；
字段entity_attribute_r、字段对应的类型为jsonb、说明为业务对象多值属性json格式、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段aspect_wfinfo_attribute_s、字段对应的类型为jsonb、说明为业务对象aspect单值属性json格式、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段aspect_wfinfo_attribute_r、字段对应的类型为jsonb、说明为业务对象aspect多值属性json格式、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段create_date、字段对应的类型为timestamp with time zone、说明为创建日期、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段creator_num、字段对应的类型为citext、说明为创建人员工号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段creator_name、字段对应的类型为citext、说明为创建人姓名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modify_date、字段对应的类型为timestamp with time zone、说明为修改日期、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modifier_num、字段对应的类型为citext、说明为修改人员工号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modifier_name、字段对应的类型为citext、说明为修改人姓名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空。在其中一个实施例中，由于源系统快照数据中包括数据状态相关信息，因此，在获取增量源数据后，可以将增量源数据与源系统快照数据进行匹配，以识别增量源数据的实际的数据状态，从而排查假更新的增量源数据、主键变化的增量源数据以及被物理删除的增量源数据。
具体地，将增量源数据与源系统快照数据进行匹配，识别增量源数据的数据状态，包括：确定增量源数据的属性信息；将增量源数据的属性信息，与源系统快照数据进行匹配，确定增量源数据的数据状态，数据状态包括是否更新、主键是否变化、是否为物理删除中的任意一种。
其中，将增量源数据与源系统快照数据进行匹配，即，将t区中的数据与e区中的数据进行匹配。具体地，根据entity_source_key属性信息，将t区和e区中的数据进行匹配，确定增量源数据中假更新的增量源数据、主键变化的增量源数据以及被物理删除的增量源数据。其中，主键变化的数据，表示旧的主键对应的数据删除，新建了新的主键数据。
需要说明的是，将t区与e区中的数据进行匹配时，是根据系统代理键进行匹配，其中，系统代理键在源系统中是唯一的，通常无意义。
在其中一个实施例中，在确定增量源数据的数据状态之后，还可以根据增量源系统的数据状态，更新数据快照区中的源系统快照数据，以便进行下一次获取的增量源数据的匹配。例如，若增量源数据为物理删除的增量源数据，则将源系统快照数据中，该物理删除的增量源数据所对应的源系统快照数据删除。
步骤S206，根据增量源数据的数据状态，修正增量源数据，获得修正源数据。
在其中一个实施例中，在确定增量源数据的数据状态之后，还可以根据增量源数据的数据状态，修正增量源数据，即对数据缓存区中的数据进行增删改的操作，以便进行数据整合、清洗等后续的数据处理。其中，将对增量源数据进行修正后得到的数据成为修正源数据。
其中，根据增量源数据的数据状态，修正增量源数据，获得修正源数据，包括：若增量源数据的数据状态为主键变化，根据源系统快照数据，确定增量源数据对应的更新前数据；恢复更新前数据，并将更新前数据的数据状态设置为删除，修正源数据包括增量源数据与更新前数据。
具体地，若增量源数据的数据状态为主键变化，需要在数据缓存区中增加一条旧的主键对应的数据，将旧的主键对应的数据称为更新前数据。其中，旧的主键对应的数据可以根据源系统快照数据确定。将更新前数据进行恢复，并将更新前数据的数据状态设置为删除，表示该更新前数据在实质不存在。
在其中一个实施例中，在获得修正源数据之后，还包括：将修正源数据更新至数据快照区，并清空数据缓存区。其中，将修正源数据更新至数据快照区，即将最新数据同步至数据快照区，以便进行后续的数据处理。
步骤S208，基于配置的业务元数据，将修正源数据进行规范化处理，获得规范化后的修正源数据，并发布规范化后的修正源数据，业务元数据包括修正源数据的元数据及其属性元数据。
在其中一个实施例中，在初次加载了源数据之后，可以根据加载的源数据确定业务元数据。业务元数据是元数据的一种，业务元数据包括各源数据的元数据及其属性元数据，是用户访问时了解业务数据的途径，可以用于将各种类型的源数据的数据属性进行清洗，支持数据集成过程中的参数化和配置化。其中，本申请实施例中将业务元数据规范为业务元数据表，具体包括业务类表和业务类属性表，分别对应于元数据和属性元数据。
具体地，业务类表包括：字段，字段对应的类型、说明、主键信息、索引信息、分布键信息、可否为空信息以及备注信息。字段、字段对应的类型、可否为空信息均以英文进行表示。
其中，字段包括：系统代理键值、数据状态、业务对象分类、业务类型说明、最新一次etl进展、etl结果说明、数据缓存区到数据发布区处理数据的sql语句、创建日期、创建人员工号、创建人姓名、修改日期、修改人员工号和修改人姓名。
其中，数据状态包括删除、未生效和生效，数据状态以数值表示，具体可以根据实际技术需要进行设置，一个实施例中删除表示为0，生效表示为1，未生效表示为1000。最新一次etl进展包括成功和失败，最新一次etl进展以数值表示，具体可以根据实际技术需要进行设置，一个实施例中1000表示成功，1000以下表示失败。etl结果说明是指最近一次的etl结果说明。数据缓存区到数据发布区处理数据的sql语句，包括删除临时表、不同源数据合并。其中，将规范化后的修正源数据发布到数据发布区中，数据发布区表示为p区。具体地，数据发布区用于存储各源系统整合及清洗后并规范化的业务数据，提供对于业务数据的统一查询，可以用于根据业务实体对象在不同源系统之中的属性映射关系和规范等，将不同业务系统中的相同数据和属性进行去重、规范化等数据融合及属性规范化处理，形成对外发布的标准数据。数据发布区中的数据表以业务类型来区分，将数据统一到一个表中，而其业务属性通过元数据管理进行识别和规范。
其中，字段的类型包括：字符串/文本数据使用不区分大小写的数据类型citext、精确数值数据类型smallint、json数据类型中的jsonb类型、将数据库服务器所在的时间转化为当前时区的时间timestamp with time zone、整型类型int2。
具体地，业务类表包括以下内容：
字段id、字段对应的类型为citext、说明为系统代理键值、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段status、字段对应的类型为smallint、说明为数据状态、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为0：删除、1：未生效、1000：生效；
字段category、字段对应的类型为citext、说明为业务对象分类、主键信息为Y、索引信息为Y、分布键信息为Y、可否为空信息为N、备注信息为空；
字段description、字段对应的类型为citext、说明为业务类型说明、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段etl_progress、字段对应的类型为int2、说明为最近一次etl进展、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为1000表示成功，1000以下表示失败；
字段etl_remarks、字段对应的类型为citext、说明为etl结果说明、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为最近一次elt结果说明；
字段sql_statement、字段对应的类型为jsonb、说明为t区到p区处理数据的sql语句、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段create_date、字段对应的类型为timestamp with time zone、说明为创建日期、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段creator_num、字段对应的类型为citext、说明为创建人员工号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段creator_name、字段对应的类型为citext、说明为创建人姓名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modify_date、字段对应的类型为timestamp with time zone、说明为修改日期、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modifier_num、字段对应的类型为citext、说明为修改人员工号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modifier_name、字段对应的类型为citext、说明为修改人姓名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空。具体地，业务类属性表包括：字段，字段对应的类型、说明、主键信息、索引信息、分布键信息、可否为空信息以及备注信息。字段、字段对应的类型、可否为空信息均以英文进行表示。
其中，字段包括：系统代理键值、数据状态、业务对象分类、业务对象属性名、业务属性说明、业务对象属性类型、业务对象属性是否多值、业务对象属性长度、业务对象属性精度、业务对象属性序号、创建日期、创建人员工号、创建人姓名、修改日期、修改人员工号和修改人姓名。
其中，数据状态包括删除、未生效和生效，数据状态以数值表示，具体可以根据实际技术需要进行设置，一个实施例中删除表示为0，生效表示为1，未生效表示为1000。
其中，字段的类型包括：字符串/文本数据使用不区分大小写的数据类型citext、精确数值数据类型smallint、将数据库服务器所在的时间转化为当前时区的时间timestamp with time zone、布尔对象boolean。
具体地，业务类属性表包括以下内容：
字段id、字段对应的类型为citext、说明为系统代理键值、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段status、字段对应的类型为smallint、说明为数据状态、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为0：删除、1：未生效、1000：生效；
字段category、字段对应的类型为citext、说明为业务对象分类、主键信息为Y、索引信息为Y、分布键信息为Y、可否为空信息为N、备注信息为空；
字段attr_name、字段对应的类型为citext、说明为业务对象属性名、主键信息为Y、索引信息为Y、分布键信息为Y、可否为空信息为N、备注信息为空；
字段attr_description、字段对应的类型为citext、说明为业务属性说明、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段attr_type、字段对应的类型为citext、说明为业务对象属性类型、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段attr_repeating、字段对应的类型为boolean、说明为业务对象属性是否多值、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段attr_length、字段对应的类型为smallint、说明为业务对象属性长度、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段attr_restriction、字段对应的类型为smallint、说明为业务对象属性精度、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段attr_identifier、字段对应的类型为smallint、说明为业务对象属性序号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段create_date、字段对应的类型为timestamp with time zone、说明为创建日期、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段creator_num、字段对应的类型为citext、说明为创建人员工号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段creator_name、字段对应的类型为citext、说明为创建人姓名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modify_date、字段对应的类型为timestamp with time zone、说明为修改日期、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modifier_num、字段对应的类型为citext、说明为修改人员工号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modifier_name、字段对应的类型为citext、说明为修改人姓名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空。在其中一个实施例中，基于配置的业务元数据，将修正源数据进行规范化处理，获得规范化后的修正源数据。其中，将修正源数据进行规范化处理，是为了在数据发布的过程中对数据进行清洗、相同的数据进行整合等处理，最后才将数据发布到数据发布区。具体地，将数据从数据缓存区装载到数据发布区的过程中，主要进行数据整合、数据清洗等数据预处理。
在其中一个实施例中，在获得规范化后的修正源数据之后，在发布规范化后的修正源数据之前，还包括：对规范化后的修正源数据进行数据预处理，得到预处理后的规范化后的修正源数据，数据预处理包括数据去重处理和数据清洗处理中的至少一种。
其中，数据预处理包括不同业务系统之间业务数据的识别和整合，并进行数据去重处理。数据预处理还包括根据预先设定的数据标准，进行数据规范化，统一属性名和属性类型。数据预处理还包括进行业务系统内以及业务系统间的数据清洗。其中，业务系统内的数据清洗，是根据业务规则，对业务系统内的数据进行清洗。业务系统间的数据清洗，是根据业务系统之间的属性映射和优先级，确定最终业务数据的唯一有效源数据，消除各业务系统之间的语义区别。
其中，数据去重处理主要包括不同业务系统的相同数据实体去重、相同属性去重和属性值的规范化、数据融合。
具体地，数据实体去重可以以业务数据的业务唯一标识，即业务键为准，首先将数据缓存区的数据进行去重处理，然后更新数据发布区对应的数据。数据属性去重与规范化可以通过每类业务数据的数据类型和标准属性编码，建立js脚本文件及属性清洗函数，在该函数中确认数据的优先级以及规范。
具体地，数据融合可以采用json序列化的方式将数据的业务属性进行整合，降低数据库中数据模型的复杂度，例如，采用业务元数据表管理元数据，从而降低业务数据融合的复杂度。其中，如图4所示为对数据进行数据清洗的示意图，ETL引擎会在数据集成过程中调用js脚本文件及属性清洗函数进行数据清洗。
需要说明的是，将数据从数据缓存区装载到数据发布区的过程中时，主要根据业务键进行上述的数据预处理，其中，业务键主要用于不同源系统的数据整合、去重等操作，业务键可以是核电的功能位置码。
在其中一个实施例中，在基于配置的业务元数据，将修正源数据进行规范化处理的过程中，由于各源系统中的源数据所对应的业务类型不同，通过将获取的增量源数据进行分类和编码，将增量源数据进行高层次抽象，并进行相关的配置，其中，ETL引擎根据编码进行参数化绑定，实现各类业务源数据集成的配置化、参数化。
如图5所示为对数据进行参数化和配置化的示意图，对于从不同的源系统中获取的不同业务类型的源数据，进行一次开发，其余参数化、配置化即可完成数据的集成过程，而在参数化和配置化的过程中，就可以实现上述的数据预处理，即完成数据清洗、数据去重等过程。
在其中一个实施例中，在获得规范化后的修正源数据之后，发布规范化后的修正源数据，即，将规范化后的修正源数据发布在数据发布区中。其中，本申请实施例中将数据发布区中的发布成功的数据进行了规范。
具体地，数据发布区表包括：字段，字段对应的类型、说明、主键信息、索引信息、分布键信息、可否为空信息以及备注信息。字段、字段对应的类型、可否为空信息均以英文进行表示。
其中，字段包括：系统代理键、数据状态、业务对象分类、业务对象名、业务对象属性json格式、业务对象属性(联合)、etl过程中产生的错误信息、创建日期、创建人员工号、创建人姓名、修改日期、修改人员工号和修改人姓名。
其中，字段的类型包括：字符串/文本数据使用不区分大小写的数据类型citext、精确数值数据类型smallint、json数据类型中的jsonb类型、将数据库服务器所在的时间转化为当前时区的时间timestamp with time zone。
具体地，数据发布区表包括以下内容：
字段id、字段对应的类型为citext、说明为系统代理键、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段status、字段对应的类型为smallint、说明为数据状态、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段category、字段对应的类型为citext、说明为业务对象分类、主键信息为Y、索引信息为Y、分布键信息为Y、可否为空信息为N、备注信息为空；
字段name、字段对应的类型为citext、说明为业务对象名、主键信息为Y、索引信息为Y、分布键信息为Y、可否为空信息为N、备注信息为空；
字段attribute、字段对应的类型为jsonb、说明为业务对象属性json格式、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段attribute_combined、字段对应的类型为jsonb、说明为业务对象属性(联合)、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段error_info、字段对应的类型为citext、说明为etl过程中产生的错误信息、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为Y、备注信息为空；
字段create_date、字段对应的类型为timestamp with time zone、说明为创建日期、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段creator_num、字段对应的类型为citext、说明为创建人员工号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段creator_name、字段对应的类型为citext、说明为创建人姓名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modify_date、字段对应的类型为timestamp with time zone、说明为修改日期、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modifier_num、字段对应的类型为citext、说明为修改人员工号、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空；
字段modifier_name、字段对应的类型为citext、说明为修改人姓名、主键信息为空、索引信息为空、分布键信息为空、可否为空信息为N、备注信息为空。具体地，在数据发布在数据发布区之后，即为统一的标准数据结构，以便用户进行数据查询和调用。
上述数据处理方法中，获取各源系统中的增量源数据；将增量源数据与源系统快照数据进行匹配，识别增量源数据的数据状态，源系统快照数据包括有获取增量源数据之前，从各源系统中获取的源数据的属性信息；根据增量源数据的数据状态，修正增量源数据，获得修正源数据；基于配置的业务元数据，将修正源数据进行规范化处理，获得规范化后的修正源数据，并发布规范化后的修正源数据，业务元数据包括修正源数据的元数据及其属性元数据。采用上述实施例的方法，通过数据缓存区存储源系统增量更新的增量源数据，能够避免在源系统中进行数据转换，减轻源系统的负载，提高数据集成的效率，通过数据快照区存储源系统快照数据，可以识别源数据的具体变化情况，通过建立通用的数据表，在数据发布区中发布清洗后的数据，可以提高整个数据系统的弹性、易用性和可扩展性，确保数据的规范性和有效性，从而提高数据处理的效率。
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及一个具体实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
一个具体实施例中，如图6所示为计算机设备的内部层次划分的示意图，具体地，计算机设备内部划分有源数据层、数据抽取层和数据层。
其中，源数据层中包括多个不同的源系统，分别表示为源系统1，源系统2……源系统n，每个源系统中存储有各业务类型的源数据，具体为核电各类业务数据。
其中，数据抽取层用于将源数据层的增量源数据定时抽取到数据层，且对于不同的源系统，采用不同的数据抽取方式。
其中，数据层用于存放清洗后整合的业务数据，通过将源数据进行分类和编码，并将源数据的数据属性序列化为json格式存储，将来自不同源系统的源数据高度抽象为统一的数据模型后，存储在关系型数据库中。这种方式既支持对业务数据使用sql语法查询，还可以增加系统的弹性和易用性。
具体地，数据层还划分有数据缓存区(t区)、数据快照区(e区)和数据发布区(p区)。
其中，数据缓存区(t区)用于接收和存储从源系统抽取出来的源数据或是增量源数据，其数据表结构与数据快照区(e区)中的表结构一致。每次增量源数据发布成功后，数据缓存区(t区)的数据会清空。
其中，数据快照区(e区)用于存放源系统数据的快照，即源系统快照数据，并通过json序列化的方式原样保存源数据库中的数据属性信息。数据快照区(e区)中的各表根据源数据库表的主键与数据缓存区(t区)中增量更新的增量源数据进行匹配后更新，同时识别数据是否发生修改以及主键是否变化。此外，还可以采用xml序列化方式或自定义格式。
其中，数据发布区(p区)用于存储各源系统整合及清洗后并规范化的业务数据，可以提供对于业务数据的统一查询，可以用于根据业务实体对象在不同源系统之中的属性映射关系和规范等，将不同业务系统中的相同数据和属性进行去重、规范化等数据融合及属性规范化处理，形成对外发布的标准数据。数据发布区中的数据表以业务类型来区分，将数据统一到一个表中，而其业务属性通过元数据管理进行识别和规范。
一个具体实施例中，如图7所示为数据处理方法的整体方案的示意图，其中，以数据存储采用分布式关系型数据库Greenplum为例，该数据库作为大数据平台，便于横向扩展，同时作为关系型数据库，便于数据使用。该数据库支持json格式，因此可以将不同的业务数据进行高层次的抽象和简化，序列化为json进行存储。此外，数据存储还可以采用其他的关系型数据库，例如，Mysql数据库、MongoDB数据库等。
以数据集成引擎采用Kettle为例，该引擎可以以多线程的方式运行，并支持参数化、脚本化的操作，可以通过windows任务计划进行任务调度。源数据可以来源于Oracle数据库、Sqlserver数据库等。
一个具体实施例中，如图8所示为数据处理方法的示意图，以抽取的为同一业务类型的数据为例，其数据处理方法的具体步骤如下：
在确定需要抽取增量源数据的源系统之后，确定技术元数据中配置的增量数据同步方案；根据增量数据同步方案，从各源系统中获取增量源数据，将增量源数据存储在t区；具体地，技术元数据表结构如表1所示。
表1技术元数据表结构
确定增量源数据的属性信息，将增量源数据的属性信息与e区中的源系统快照数据进行代理键匹配，确定增量源数据的数据状态，其中，e区中的源系统快照数据包括有获取增量源数据之前，从各源系统中获取的源数据的属性信息；数据状态包括是否更新、业务唯一键(主键)是否变化、是否为物理删除等；具体地，快照数据表结构如表2所示。
表2快照数据表结构
根据增量源数据的数据状态，更新e区中的数据，并修正t区中每条增量源数据的数据状态，获得修正源数据，其中，若增量源数据的数据状态为主键变化，根据源系统快照数据，确定增量源数据对应的更新前数据；恢复更新前数据，并将更新前数据的数据状态设置为删除，修正源数据包括增量源数据与更新前数据；
基于配置的业务元数据，将修正源数据进行规范化处理，获得规范化后的修正源数据，对规范化后的修正源数据进行数据去重、数据清洗和数据合并处理，并将处理后的规范化后的修正源数据发布在p区中；
具体地，业务元数据中的业务类表结构如表3所示。
表3业务类表结构
具体地，业务元数据中的业务类属性表结构如表4所示。
表4业务类属性表结构
具体地，数据发布区表结构如表5所示。
表5数据发布区表结构
一个具体实施例中，如图9所示为数据处理方法的示意图，以先抽取同一业务类型的数据，对同一业务类型的数据进行处理后，再抽取不同业务类型的数据，并进行数据集成为例，其数据处理方法的具体步骤如下：
在确定需要抽取增量源数据的源系统之后，确定技术元数据中配置的增量数据同步方案；根据增量数据同步方案，从各源系统中获取同一业务类型的增量源数据，分别表示为数据1.1、数据1.2和数据1.n，并将抽取的增量源数据存储在t区；
确定增量源数据的属性信息，将增量源数据的属性信息与e区中的源系统快照数据进行代理键匹配，确定增量源数据的数据状态，其中，e区中的源系统快照数据包括有获取增量源数据之前，从各源系统中获取的源数据的属性信息；数据状态包括是否更新、业务唯一键(主键)是否变化、是否为物理删除等；
根据增量源数据的数据状态，更新e区中的数据，并修正t区中每条增量源数据的数据状态，获得修正源数据，其中，若增量源数据的数据状态为主键变化，根据源系统快照数据，确定增量源数据对应的更新前数据；恢复更新前数据，并将更新前数据的数据状态设置为删除，修正源数据包括增量源数据与更新前数据；
获取不同业务类型的增量源数据，分别表示为数据2和数据n，并将抽取的不同业务类型的增量源数据存储在t区，此时返回执行根据增量源数据的数据状态，更新e区中的数据，并修正t区中每条增量源数据的数据状态，获得修正源数据的步骤，直至获得最终的修正源数据；
基于配置的业务元数据，将修正源数据进行规范化处理，获得规范化后的修正源数据，对规范化后的修正源数据进行数据去重、数据清洗和数据合并处理，并将处理后的规范化后的修正源数据发布在p区中。
应该理解的是，虽然如上所述的各实施例涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
基于同样的发明构思，本申请还提供了一种用于实现上述涉及的数据处理方法的数据处理装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个数据处理装置实施例中的具体限定可以参见上文中对于数据处理方法的限定，在此不再赘述。
在其中一个实施例中，如图10所示，提供了一种数据处理装置，包括：获取模块1010、识别模块1020、修正模块1030和发布模块1040，其中：
获取模块1010，用于获取各源系统中的增量源数据。
识别模块1020，用于将所述增量源数据与源系统快照数据进行匹配，识别所述增量源数据的数据状态，所述源系统快照数据包括有获取所述增量源数据之前，从各所述源系统中获取的源数据的属性信息。
修正模块1030，用于根据所述增量源数据的数据状态，修正所述增量源数据，获得修正源数据。
发布模块1040，用于基于配置的业务元数据，将所述修正源数据进行规范化处理，获得规范化后的修正源数据，并发布规范化后的所述修正源数据，所述业务元数据包括所述修正源数据的元数据及其属性元数据。
在其中一个实施例中，所述获取模块1010，包括：
增量数据同步方案确定单元，用于确定技术元数据中配置的增量数据同步方案。
增量源数据获取单元，用于根据所述增量数据同步方案，从各所述源系统中获取所述增量源数据。
在其中一个实施例中，所述识别模块1020，包括：
属性信息确定单元，用于确定所述增量源数据的属性信息。
数据状态确定单元，用于将所述增量源数据的属性信息，与所述源系统快照数据进行匹配，确定所述增量源数据的数据状态，所述数据状态包括是否更新、主键是否变化、是否为物理删除中的任意一种。
在其中一个实施例中，所述修正模块1030，包括：
更新前数据确定单元，用于若所述增量源数据的数据状态为主键变化，根据所述源系统快照数据，确定所述增量源数据对应的更新前数据。
数据修正单元，用于恢复所述更新前数据，并将所述更新前数据的数据状态设置为删除，所述修正源数据包括所述增量源数据与所述更新前数据。
在其中一个实施例中，所述数据处理装置，还包括：
预处理单元，用于对所述规范化后的所述修正源数据进行数据预处理，得到预处理后的规范化后的所述修正源数据，所述数据预处理包括数据去重处理和数据清洗处理中的至少一种。
在其中一个实施例中，所述增量源数据存储在数据缓存区，所述源系统快照数据存储在数据快照区；所述数据处理装置，还包括：
数据更新单元，用于将所述修正源数据更新至所述数据快照区，并清空所述数据缓存区。
上述数据处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
在其中一个实施例中，提供了一种计算机设备，其内部结构图可以如图11所示。该计算机设备包括通过系统总线连接的处理器、存储器和通信接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、移动蜂窝网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种数据处理方法。
在其中一个实施例中，该计算机设备还可以包括显示屏和输入装置，该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。
本领域技术人员可以理解，图11中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在其中一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述的数据处理方法的步骤。
在其中一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述的数据处理方法的步骤。
在其中一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述的数据处理方法的步骤。
需要说明的是，本申请所涉及的数据，包括但不限于用于分析的数据、存储的数据、展示的数据等，均为经各方充分授权的信息和数据。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。
以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。
Claims (10)
1.一种数据处理方法，其特征在于，所述方法包括：
获取各源系统中的增量源数据；
将所述增量源数据与源系统快照数据进行匹配，识别所述增量源数据的数据状态，所述源系统快照数据包括有获取所述增量源数据之前，从各所述源系统中获取的源数据的属性信息；
根据所述增量源数据的数据状态，修正所述增量源数据，获得修正源数据；
基于配置的业务元数据，将所述修正源数据进行规范化处理，获得规范化后的修正源数据，并发布规范化后的所述修正源数据，所述业务元数据包括所述修正源数据的元数据及其属性元数据。
2.根据权利要求1所述的数据处理方法，其特征在于，所述获取各源系统中的增量源数据，包括：
确定技术元数据中配置的增量数据同步方案；
根据所述增量数据同步方案，从各所述源系统中获取所述增量源数据。
3.根据权利要求2所述的数据处理方法，其特征在于，所述将所述增量源数据与源系统快照数据进行匹配，识别所述增量源数据的数据状态，包括：
确定所述增量源数据的属性信息；
将所述增量源数据的属性信息，与所述源系统快照数据进行匹配，确定所述增量源数据的数据状态，所述数据状态包括是否更新、主键是否变化、是否为物理删除中的任意一种。
4.根据权利要求3所述的数据处理方法，其特征在于，所述根据所述增量源数据的数据状态，修正所述增量源数据，获得修正源数据，包括：
若所述增量源数据的数据状态为主键变化，根据所述源系统快照数据，确定所述增量源数据对应的更新前数据；
恢复所述更新前数据，并将所述更新前数据的数据状态设置为删除，所述修正源数据包括所述增量源数据与所述更新前数据。
5.根据权利要求1所述的数据处理方法，其特征在于，在所述获得规范化后的修正源数据之后，在所述发布规范化后的所述修正源数据之前，包括：
对所述规范化后的所述修正源数据进行数据预处理，得到预处理后的规范化后的所述修正源数据，所述数据预处理包括数据去重处理和数据清洗处理中的至少一种。
6.根据权利要求1所述的数据处理方法，其特征在于，所述增量源数据存储在数据缓存区，所述源系统快照数据存储在数据快照区；
在所述获得修正源数据之后，所述方法还包括：
将所述修正源数据更新至所述数据快照区，并清空所述数据缓存区。
7.一种数据处理装置，其特征在于，所述装置包括：
获取模块，用于获取各源系统中的增量源数据；
识别模块，用于将所述增量源数据与源系统快照数据进行匹配，识别所述增量源数据的数据状态，所述源系统快照数据包括有获取所述增量源数据之前，从各所述源系统中获取的源数据的属性信息；
修正模块，用于根据所述增量源数据的数据状态，修正所述增量源数据，获得修正源数据；
发布模块，用于基于配置的业务元数据，将所述修正源数据进行规范化处理，获得规范化后的修正源数据，并发布规范化后的所述修正源数据，所述业务元数据包括所述修正源数据的元数据及其属性元数据。
8.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述的数据处理方法的步骤。
9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的数据处理方法的步骤。
10.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至6中任一项所述的数据处理方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210003312.2A CN114356945A (zh) | 2022-01-04 | 2022-01-04 | 数据处理方法、装置、计算机设备和存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210003312.2A CN114356945A (zh) | 2022-01-04 | 2022-01-04 | 数据处理方法、装置、计算机设备和存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114356945A true CN114356945A (zh) | 2022-04-15 |
Family
ID=81105788
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210003312.2A Pending CN114356945A (zh) | 2022-01-04 | 2022-01-04 | 数据处理方法、装置、计算机设备和存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114356945A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115098477A (zh) * | 2022-06-23 | 2022-09-23 | 中核核电运行管理有限公司 | 核电站生产数据的数据标准管理方法及装置 |
-
2022
- 2022-01-04 CN CN202210003312.2A patent/CN114356945A/zh active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115098477A (zh) * | 2022-06-23 | 2022-09-23 | 中核核电运行管理有限公司 | 核电站生产数据的数据标准管理方法及装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10853338B2 (en) | Universal data pipeline | |
| US20230334030A1 (en) | System and method for slowly changing dimension and metadata versioning in a multidimensional database environment | |
| CN109997126B (zh) | 事件驱动提取、变换、加载（etl）处理 | |
| US11709878B2 (en) | Enterprise knowledge graph | |
| CN105144080B (zh) | 用于元数据管理的系统 | |
| US20120158795A1 (en) | Entity triggers for materialized view maintenance | |
| US8805777B2 (en) | Data record collapse and split functionality | |
| Chavan et al. | Survey paper on big data | |
| US11194840B2 (en) | Incremental clustering for enterprise knowledge graph | |
| US20170255708A1 (en) | Index structures for graph databases | |
| Vajk et al. | Automatic NoSQL schema development: A case study | |
| GB2513329A (en) | Method and system for scoring data in a database | |
| CN112818048A (zh) | 数据仓库的分层构建方法、装置、电子设备及存储介质 | |
| CN115543198A (zh) | 非结构化数据入湖方法、装置、电子设备及存储介质 | |
| CN115544007A (zh) | 标签预处理方法、装置、计算机设备和存储介质 | |
| US10185757B2 (en) | Non-uniform multi-row text file loading | |
| CN114356945A (zh) | 数据处理方法、装置、计算机设备和存储介质 | |
| US20220222225A1 (en) | Model generation service for data retrieval | |
| CN115329011A (zh) | 数据模型的构建方法、数据查询的方法、装置及存储介质 | |
| US12061585B2 (en) | Systems and methods of modeling and querying dynamic temporal graph on massive parallel graph processing and storage engine | |
| US20190303462A1 (en) | Methods and apparatuses for automated performance tuning of a data modeling platform | |
| Hasan et al. | An approach for metadata extraction and transformation for various data sources using R programming language | |
| Ahmed et al. | Generating data warehouse schema | |
| CN113760600A (zh) | 一种数据库备份方法、数据库还原方法和相关装置 | |
| CN110727672A (zh) | 数据映射关系查询方法、装置、电子设备及可读介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |