数据调用方法、装置、电子设备和存储介质
技术领域
本申请涉及大数据处理技术领域,具体而言,涉及一种数据调用方法、装置、电子设备和存储介质。
背景技术
目前,为了适应业务数据的灵活易变、频繁迭代的特性,大部分的企业级区块链通常采用CouchDB、LevelDB等非结构化的数据库。然而,传统的ERP(Enterprise ResourcePlanning,企业资源计划)系统为了保证系统的性能和稳定,通常采用的是关系型数据库存储数据。
因此,若某些企业需要采用区块链技术保护其交易数据,会导致ERP系统的数据库和区块链数据库无法兼容,数据无法交互。
在面对上述问题时,现有的做法是离线提取已有的关系型数据,针对不同的区块链底层数据进行定制化迁移,但当数据量较多时,此种方式会占用大量的存储空间,同时,由于数据需要离线提取,为了不影响关系型数据库的读写性能,只能进行周期性地离线提取,但周期性离线提取的方式会导致提取出来的数据的时效性较差。
发明内容
有鉴于此,本申请的目的在于提供数据调用方法、装置、电子设备和存储介质,以实现区块链应用和传统的基于关系型数据库的ERP系统之间的数据同步。
第一方面,本申请实施例提供一种数据调用方法,方法包括:
读取关系型数据库的操作日志,其中,操作日志包括针对关系型数据库进行操作的至少一个操作条目,每个操作条目包括操作的类型、被操作的数据表的名称、该操作对应的数据内容以及被操作的数据表的外键信息,其中,所述外键信息为所述被操作的数据表所引用的其他数据表中的主键信息;
对操作日志进行解析,获得操作日志的中间表示形式,其中,中间表示形式用于将操作日志中被操作的数据表的数据内容与被操作的数据表中所引用的其他数据表的主键信息进行关联;
根据非结构化数据库的调用接口,基于操作日志的中间表示形式进行接口调用请求转换。
在可选的实施方式中,对操作日志进行解析,获得操作日志的中间表示形式,包括:
对操作日志包括的各操作条目中的外键信息进行解析获得扩展后的操作日志;
将扩展后的操作日志解析为JSON格式的中间表示形式。
在可选的实施方式中,读取关系型数据库的操作日志,包括:
通过日志解析工具异步读取关系型数据库的操作日志。
在可选的实施方式中,日志解析工具包括LogMiner。
在可选的实施方式中,在根据非结构化数据库的调用接口将操作日志的中间表示形式转换为接口调用请求之后,方法还包括:
基于非结构化数据库,通过接口调用请求调用关系型数据库中的数据。
第二方面,本申请实施例提供一种数据调用装置,装置包括:
日志读取模块,用于读取关系型数据库的操作日志,其中,操作日志包括针对关系型数据库进行操作的至少一个操作条目,每个操作条目包括操作的类型、被操作的数据表的名称、该操作对应的数据内容以及被操作的数据表的外键信息,其中,所述外键信息为所述被操作的数据库所引用的其他数据表的主键信息;
日志解析模块,用于对操作日志进行解析,获得操作日志的中间表示形式,其中,中间表示形式用于将操作日志中被操作的数据表的数据内容与被操作的数据表中所引用的其他数据表的主键信息进行关联;
日志转换模块,用于根据非结构化数据库的调用接口,基于操作日志的中间表示形式进行接口调用请求转换。
在可选的实施方式中,日志解析模式具体用于:
对操作日志包括的各操作条目中的外键信息进行解析获得扩展后的操作日志;
将扩展后的操作日志解析为JSON格式的中间表示形式。
在可选的实施方式中,装置还包括:
调用模块,用于基于非结构化数据库,通过接口调用请求调用关系型数据库中的数据。
第三方面,本申请实施例提供一种电子设备,包括:处理器、存储介质和总线,存储介质存储有处理器可执行的机器可读指令,当电子设备运行时,处理器与存储介质之间通过总线通信,处理器执行机器可读指令,以执行如前述实施方式任一方法的步骤。
第四方面,本申请实施例提供一种存储介质,存储介质上存储有计算机程序,计算机程序被处理器运行时执行如前述实施方式任一方法的步骤。
本申请实施例提供的数据调用方法、装置、电子设备和存储介质,通过对获取到的关系型数据库的操作日志进行解析,以获得该操作日志的中间表达形式,该操作日志的中间表达形式包括了关系型数据库中被操作的数据表的外键信息,其中,外键信息为被操作的数据表所引用的其他数据表的主键信息,可以避免数据丢失。由于操作日志中包括了对各个数据表的数据的插入、修改或删除等动作,因此基于操作日志的中间表示形式进行接口调用请求转换,即可实现基于非结构化数据库的区块链应用和基于关系型数据库的ERP系统之间的数据同步,无需进行周期性的离线获取数据,保证了关系型数据库正常的读写功能。
为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1为本申请实施例提供的数据调用方法的流程图之一;
图2为本申请实施例提供的Oracle数据库的操作日志示意图;
图3为本申请实施例提供的步骤S102的子步骤流程图;
图4为本申请实施例提供的数据调用方法的流程图之二;
图5为本申请实施例提供的数据调用装置的功能模块图;
图6为本申请实施例提供的电子设备的结构示意图。
主要元件符号说明:60-电子设备;61-处理器;62-存储器;63-总线;110 -数据调用装置;101-日志读取模块;102-日志解析模块;103-日志转换模块;104-调用模块。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
结构化数据是指数据范式相对化固定的数据,此类数据通常以数据条目的形式存储于Oracle、SQLServer、MySQL等关系型数据库中,非结构化数据一般没有固定的范式,通常以JSON文档或键值对的形式存储于MongoDB、CouchDB、LevelDB、Neo4j等非关系型数据库中。
目前,为了将基于结构化数据库的区块链应用与基于关系型数据库的ERP应用对接,通常是在离线情况下提取关系型数据库中的数据,再根据不同的区块链应用进行定制化迁移。但由于关系型数据库中的数据需要实时更新,因此在提取数据时,只能周期性地进行提取,这将导致数据的时效性较差,同时提取出来的数据还需要额外存放,需要占用大量的存储空间。
考虑到上述现有技术存在的技术问题,本申请提出了一种数据调用方法、装置、电子设备和存储介质。该数据调用方法通过关系型数据库的操作日志可以实现关系型数据库和非结构化数据库之间的数据交互。下面对本申请实施例提供的数据调用方法进行详细介绍。
请参照图1,图1为本申请实施例提供的数据调用方法的流程图之一。在本实施例中,方法包括:
步骤S101,读取关系型数据库的操作日志。其中,操作日志包括针对关系型数据库进行操作的至少一个操作条目,每个操作条目包括操作的类型、被操作的数据表的名称、该操作对应的数据内容以及被操作的数据表的外键信息。其中,所述外键信息为所述被操作的数据表所引用的其他数据表中的主键信息。
步骤S102,对操作日志进行解析,获得操作日志的中间表示形式。
其中,中间表示形式用于将操作日志中被操作的数据表的数据内容与被操作的数据表所引用的其他数据表的主键信息进行关联;
步骤S103,根据非结构化数据库的调用接口,基于操作日志的中间表示形式进行接口调用请求转换。
上述步骤通过对获取到的关系型数据库的操作日志进行解析,以获得该操作日志的中间表达形式,该操作日志的中间表达形式包括了关系型数据库中被操作的数据表所引用的引用表的数据内容,可以避免数据丢失。随后,基于操作日志的中间表示形式进行接口调用请求转换,即可实现基于非结构化数据库的区块链应用和基于关系型数据库的ERP系统之间的数据同步,无需进行周期性的离线获取数据,保证了关系型数据库正常的读写功能。
进一步地,在本实施例中,传统的企业级关系型数据库(如Oracle,SQL Server)一般拥有较完善的日志机制,可以将用户的操作记录存储为单独的数据表。
如图2所示,图2为本申请实施例提供的Oracle数据库的操作日志示意图。操作日志通常包括多个操作条目,图2所示为其中一个操作条目,在该操作条目中包括有操作者ID(即username)、操作的类型(即operation)、被操作的数据表的名称(即seg_name)、修订语句(即sql_redo,用于表示此次的修改内容)、被操作的时间(即timestamp)、操作序列号(即scn,用于表示多个操作条目的先后顺序)。
在图2所示的操作条目中,操作者ID为BUSINESS_ADMIN、操作的类型为插入(即insert)、被操作的数据表的名称为ORDER_HEADER、操作序列号为3049955、操作时间为2019年02月28日的下午1点42分25秒。
然而,由于考虑到关系型数据库中的数据具有固定的数据范式,结构化数据库中的数据并没有固定的数据范式,以及关系型数据库为了避免数据冗余,数据表之前通常使用外键相互关联,而结构化数据库则没有外键。因此,关系型数据库的操作日志中的数据字段并不能直接应用于区块链应用,需要将操作日志解析为中间表示形式。
进一步地,请参照图3,图3为本申请实施例提供的步骤S102的子步骤流程图。在本实施例中,步骤S102包括:
子步骤S1021,对操作日志包括的各操作条目中的外键信息进行解析获得扩展后的操作日志;
子步骤S1022,将扩展后的操作日志解析为JSON格式的中间表示形式。
首先,需要说明的是,在关系型数据库中,通常会包括多个数据表,每个表通常有若干个属性,但其中有一个属性能唯一标识一条记录,该属性即为该表的主键。例如,数据表A是学生表,其中记录了每个学生的学号、姓名、性别、班级等属性,其中,学号可以作为每个学生的唯一标识,则学号即为表A的主键。表B(成绩表)中记录了学号、课程号和成绩等属性,其中学号和课程号组合可以用于标识数据表B的唯一一条记录,因此,学号和课程号的组合为表B的主键。
在关系型数据库中,为了避免数据冗余,数据表之间可能会互相引用,外键则用来表示数据表之间的引用关系。具体来说,若表A中的一个属性是B表的主键,那该属性则是A表的外键。
在上述子步骤中,为了保证在解析过程中外键信息不被损失,则需要先对外键信息进行解析,以获得扩展后的操作日志。
例如,若操作日志中的修订语句为:
insert into
"ORDER_HEADER"("OWNER","PONO","POTYPE","SUPPLIERID")
values ('O2', 'P2', 'PO','aaaa')
其中,SUPPLIERID为ORDER_HEADER的外键信息,且SUPPLIERID为数据表CUSTOMER表中的主键。则可以得出,此次操作的内容是:在数据表ORDER_HEADER的OWNER列增加数值O2,在ORDER_HEADER的PONO列增加数值P2,在ORDER_HEADER的POTYPE列中增加数值PO,另外还需要到CUSTOMER表中查询SUPPLIERID列中数值为aaaa对应的内容。
根据上述内容,通过解析历史日志或查询源数据表对外键信息进行解析,即可获得在CUSTOMER表中的SUPPLIERID列中数值为aaaa对应的内容。
另外,在对外键信息解析后,还需要进一步将扩展后的操作日志解析为JSON格式的中间表示形式。例如,上述提供的修订语句在解析后可以为:
{
"OWNER":"O2",
"PONO":"P2",
"POTYPE":"PO",
"SUPPLIER": {
"DESCR_E": null,
"DESCR_C": null,
"CUSTOMERID": "aaaa",
"ACTIVE_FLAG": "1",
"CUSTOMERNAME": "C5",
"CUSTOMERTYPE": "VE"
}
}
基于上述两个子步骤,即可完成对操作日志的解析,获得该操作日志的中间表示形式,即JSON格式的文档。
在将操作日志转换为JSON格式的中间表示形式之后,为了使非结构化数据库能够通过操作日志的中间表示形式完成对关系型数据库中的数据的调用,因此,还需要基于前述步骤获得的操作日志的中间表示形式,完成接口调用请求的转换。
例如,若区块链应用采用的是RESTful API作为应用接口,那么则可以基于操作日志的中间表示形式转换形成RESTful API接口调用请求,以实现数据调用。
以上述解析获得的JSON文档为例,转换后的RESTful API接口调用请求为:
POST /api/v1/orderHeader HTTP/1.1
Host: localhost:7001
Content-Type: application/json
{
"OWNER":"O2",
"PONO":"P2",
"POTYPE":"PO",
"SUPPLIER": {
"DESCR_E": null,
"DESCR_C": null,
"CUSTOMERID": "dff2c893-d84a-46e0-ae02-79d6d1e11c8d",
"ACTIVE_FLAG": "1",
"CUSTOMERNAME": "C5",
"CUSTOMERTYPE": "VE"
}
}
具体地,在本实施例中,可以通过日志解析工具,例如LogMiner异步读取关系型数据库的操作日志。
通过单独的线程读取操作日志的各个操作条目,不会占用关系型数据库的业务时间,不会影响关系型数据库的正常读写流程。
进一步地,请参照图4,图4为本申请实施例提供的数据调用方法的流程图之二。在本实施例中,在步骤S103之后,数据调用方法还包括:
步骤S104,基于非结构化数据库,通过接口调用请求调用关系型数据库中的数据。
在本步骤中,非结构化数据库通过相应地接口调用请求即可从关系型数据库中调用相应的数据,实现数据交互。
基于同一发明构思,本申请实施例中还提供了与数据调用方法对应的数据调用装置110 ,由于本申请实施例中的装置解决问题的原理与本申请实施例上述数据调用方法相似,因此装置的实施可以参见方法的实施,重复之处不再赘述。
具体请参照图5,图5为本申请实施例提供的数据调用装置110 的功能模块图。在本实施例中,数据调用装置110 包括:
日志读取模块101,用于读取关系型数据库的操作日志,其中,操作日志包括针对关系型数据库进行操作的至少一个操作条目,每个操作条目包括操作的类型、被操作的数据表的名称、该操作对应的数据内容以及被操作的数据表的外键信息。其中,外键信息为所述被操作的数据库所引用的引用其他数据表中被引用的数据内容的主键信息
日志解析模块102,用于对操作日志进行解析,获得操作日志的中间表示形式,其中,中间表示形式用于将操作日志中被操作的数据表的数据内容与被操作的数据表所引用的其他数据表的主键信息进行关联。
日志转换模块103,用于根据非结构化数据库的调用接口,基于操作日志的中间表示形式进行接口调用请求转换。
调用模块104,用于基于非结构化数据库,通过接口调用请求调用关系型数据库中的数据。
进一步地,在本实施例中,日志解析模式具体用于:
对操作日志包括的各操作条目中的外键信息进行解析获得扩展后的操作日志;将扩展后的操作日志解析为JSON格式的中间表示形式。
关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明,这里不再详述。
本申请实施例还提供了一种电子设备60,如图6所示,为本申请实施例提供的电子设备60的结构示意图,包括:处理器61、存储器62、和总线63。存储器62存储有处理器61可执行的机器可读指令(比如,图5中的装置中日志读取模块101、日志解析模块102、日志转换模块103、调用模块104对应的执行指令等),当电子设备60运行时,处理器61与存储器62之间通过总线63通信,机器可读指令被处理器61执行时执行上述实施例提供的方法。
本申请实施例还提供了一种存储介质,该存储介质上存储有计算机程序,该计算机程序被处理器61运行时执行上述实施例提供的方法。
具体地,该存储介质能够为通用的存储介质,如移动磁盘、硬盘等,该存储介质上的计算机程序被运行时,能够执行上述任一实施例的方法,从而解决目前的数据流分析技术无法实现跨包分析的问题,进而降低漏洞分析的误报率,提升分析结果的可信度。
在一些实施例中,处理器61可以包括一个或多个处理核(例如,单核处理器61(S)或多核处理器61(S))。仅作为举例,处理器61可以包括中央处理单元(Central ProcessingUnit, CPU)、专用集成电路(Application Specific Integrated Circuit, ASIC)、专用指令集处理器61(Application Specific Instruction-set Processor, ASIP)、图形处理单元(Graphics Processing Unit, GPU)、物理处理单元(Physics Processing Unit, PPU)、数字信号处理器61 (Digital Signal Processor, DSP)、现场可编程门阵列( FieldProgrammable Gate Array, FPGA)、可编程逻辑器件(Programmable Logic Device,PLD)、控制器、微控制器单元、简化指令集计算机(Reduced Instruction Set Computing,RISC)、或微处理器61等,或其任意组合。
本申请实施例所提供的数据调用装置100可以为电子设备60上的特定硬件或者安装于电子设备60上的软件或固件等。本申请实施例所提供的装置,其实现原理及产生的技术效果和前述方法实施例相同,为简要描述,装置实施例部分未提及之处,可参考前述方法实施例中相应内容。
在本申请所提供的实施例中,应该理解到,所揭露装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
另外,在本申请提供的实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
最后应说明的是:以上实施例,仅为本申请的具体实施方式,用以说明本申请的技术方案,而非对其限制,本申请的保护范围并不局限于此,尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围。都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应以权利要求的保护范围为准。