1.本技术涉及数据库
技术领域：
：，尤其涉及一种推送数据配置方法、装置、设备、介质及程序产品。
背景技术：
：：2.随着经济和社会的不断发展，特别是互联网技术普及之后，很多业务活动都需要网络系统来辅助运营和管理。一般在网络系统中，业务节点负责具体业务活动的执行，并向监管机构所在的监管节点上报业务活动的数据，以使监管机构监督业务节点的业务活动是否符合规范要求。3.而业务节点所产生的业务数据一般存储在业务数据库中，而监管节点需要通过读取监管数据库中的数据来审核业务节点的业务活动。因此就需要将业务数据库中的数据推送到监管数据库中。然而，现有技术中，由于两个数据库单独构建和维护，一般来说，数据库的构建会采用较为成熟的数据库技术，如mysql关系型数据库，但是两个关系型数据库之间数据的推送需要专门定制sql语言代码的开发来实现。4.然而，随着业务的快速发展，业务节点不断增加，随之而来的是更多的监管节点也需要对应接入数据推送平台，这就使得数据推送平台的运营维护陷入到了不断定制开发各个数据库之间数据推送的重复性工作当中，耗时耗力，增加运维成本。因此，现有技术中存在两个关系型数据库之间数据的转移映射需要额外定制开发编写专门代码的技术问题。技术实现要素：5.本技术提供一种推送数据配置方法、装置、设备、介质及程序产品，以解决现有技术中两个关系型数据库之间数据的转移映射需要额外定制开发编写专门代码的技术问题。6.第一个方面，本技术提供一种推送数据配置方法，包括：7.解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，第一数据库用于向监管节点推送至少一个业务节点的业务数据，第一数据库包括关系型数据库；8.将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，第二数据库包括关系型数据库，第三数据库包括非关系型数据库；9.利用预设配置工具，将目标数据配置到监管数据采集表中。10.在一种可能的设计中，将目标数据以预设格式推送到第三数据库中，包括：11.利用预设转换工具，将第二数据库中的目标数据表转换为键值对数据，目标数据表用于存储目标数据；12.向第三数据库中发送键值对数据。13.在一种可能的设计中，非关系型数据库包括文档型数据库，向第三数据库中发送键值对数据，包括：14.将键值对数据按预设顺序存储到至少一个文档中；15.其中，文档型数据库用于存储文档。16.在一种可能的设计中，文档包括文本型文件，利用预设配置工具，将目标数据配置到监管数据采集表中，包括：17.利用预设配置工具，根据预设对应关系，将文本型文件中的字符串数据对应配置给，监管数据采集表中对应的字段。18.在一种可能的设计中，目标数据包括：基本数据以及业务数据，基本数据包括业务节点的特征参数，对应的，第二数据库中的数据表包括：基本数据表以及业务数据表，将业务数据抽取到第二数据库中进行预处理以确定目标数据，包括：19.利用数据抽取工具，根据基本数据表，抽取业务节点对应的基本数据；20.利用数据抽取工具，根据业务数据表，抽取业务节点对应的业务数据。21.可选的，在解析至少一个监管节点发布的监管要求信息之前，还包括：22.在检测到预设触发信号时，获取目标监管节点的监管信息。23.在一种可能的设计中，预设触发信号，包括：新增业务节点、新增监管节点、监管节点所管辖的业务节点范围发生变化、监管节点的上报要求信息发生了变化。24.第二方面，本技术提供一种推送数据配置装置，包括：25.解析模块，用于解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，第一数据库用于向监管节点推送至少一个业务节点的业务数据，第一数据库包括关系型数据库；26.抽取模块，用于将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，第二数据库包括关系型数据库，第三数据库包括非关系型数据库；27.配置模块，用于利用预设配置工具，将目标数据配置到监管数据采集表中。28.在一种可能的设计中，抽取模块，具体用于：29.利用预设转换工具，将第二数据库中的目标数据表转换为键值对数据，目标数据表用于存储目标数据；30.向第三数据库中发送键值对数据。31.在一种可能的设计中，非关系型数据库包括文档型数据库，抽取模块，用于将键值对数据按预设顺序存储到至少一个文档中；32.其中，文档型数据库用于存储文档。33.在一种可能的设计中，文档包括文本型文件，配置模块，用于利用预设配置工具，根据预设对应关系，将文本型文件中的字符串数据对应配置给，监管数据采集表中对应的字段。34.在一种可能的设计中，目标数据包括：基本数据以及业务数据，基本数据包括业务节点的特征参数，对应的，第二数据库中的数据表包括：基本数据表以及业务数据表；35.对应的，抽取模块，具体用于：36.利用数据抽取工具，根据基本数据表，抽取业务节点对应的基本数据；37.利用数据抽取工具，根据业务数据表，抽取业务节点对应的业务数据。38.可选的，解析模块，还用于在检测到预设触发信号时，获取目标监管节点的监管信息。39.在一种可能的设计中，预设触发信号，包括：新增业务节点、新增监管节点、监管节点所管辖的业务节点范围发生变化、监管节点的上报要求信息发生了变化。40.第三个方面，本技术提供一种电子设备，包括：41.存储器，用于存储程序指令；42.处理器，用于调用并执行所述存储器中的程序指令，执行第一方面所提供的任意一种可能的推送数据配置方法。43.第四方面，本技术提供一种存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序用于执行第一方面所提供的任意一种可能的推送数据配置方法。44.第五方面，本技术还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面所提供的任意一种可能的推送数据配置方法。45.本技术提供了一种推送数据配置方法、装置、设备、介质及程序产品，通过解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，然后将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，再利用预设配置工具，将目标数据配置到监管数据采集表中，其中，第一数据库用于向监管节点推送业务节点的业务数据，第二数据库用于提取业务节点的业务数据，第一数据库和第二数据库包括关系型数据库，第三数据库包括非关系型数据库。借助非关系型的第三数据库，解决了现有技术中两个关系型数据库之间数据的转移映射需要额外定制开发编写专门代码的技术问题。达到了节省业务节点向监管节点上报数据时，需要为每个业务节点都单独定制数据上报逻辑代码的步骤，简化了数据推送平台的运维工作量的技术效果。附图说明46.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。47.图1为本技术实施例提供的一种数据推送平台的结构示意图；48.图2为本技术实施例提供的一种推送数据配置方法的流程示意图；49.图3为本技术实施例提供的另一种推送数据配置方法的流程示意图；50.图4为本技术实施例提供的一种推送数据配置装置的结构示意图；51.图5为本技术提供的一种电子设备的结构示意图。52.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。具体实施方式53.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，包括但不限于对多个实施例的组合，都属于本技术保护的范围。54.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。55.下面对本技术的发明构思形成的逻辑进行介绍：56.一个业务管理系统一般包括多个业务节点以及至少一个监管节点，随着现实中业务的不断发展，业务节点数量不断增多，同时，其可能引起监管节点的增加，或是监管节点更新了监管范围或者监管数据的提交要求。57.上述的各种情况，都需要业务管理系统的运维人员对业务管理系统进行二次开发及维护。通常业务管理系统会利用一个业务数据库来提取和存储各个业务节点的业务数据。然后通过数据推送平台，向不同监管机构所对应的监管节点推送其所要求上报的数据，以便于监管机构对业务节点所对应的业务机构进行监管。58.在推送前，数据推送平台可以构建一个专门存储推送数据的监管配置数据库，在向监管节点推送数据前，监管配置数据库先从业务数据库中提取并配置数据采集表。59.进一步的，为了满足多监管节点和多业务节点间数据推送要求多样化，格式不统一的需求，需要开发人员不断进行更新推送代码和配置代码二次开发，而这也是本技术需要进一步解决的问题。60.一般来说，数据库分为关系型数据库和非关系型数据库两类，其中，关系型数据库的应用较为广泛与成熟。sql(structuredquerylanguage，结构化查询语言)数据库就是应用最广泛的数据库，上述的业务数据库、监管节点自己所建立与管理的数据库，监管配置数据库一般都是关系型数据库。61.本技术发明人发现，正是由于关系型数据库之间数据推送要遵循sql语言的严格规范化要求，使得数据推送需要专门的代码定制开发。62.而本技术的发明构思就是想要打破这种惯性思维，利用非关系型数据库作为中间媒介，将严格死板的结构化数据进行解耦拆解，简化数据推送时的要求，使得数据推送的可拓展性得到提高，只需要简单设置配置参数即可完成业务数据从业务数据库向监管配置数据库的推送配置，而监管配置数据库向监管节点的推送就不需要二次开发，大大减少了开发人员的工作量，降低了运维成本。63.下面以具体地实施例对本技术的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本技术的实施例进行描述。64.图1为本技术实施例提供的一种数据推送平台的结构示意图。如图1所示，数据推送平台的两端分别连接着业务层10和监管层30，业务层10中包括多个业务节点11，监管层30中包括多个监管节点31。65.每个业务节点11都要向其对应的监管节点31上报其业务数据，以满足法规要求的监管规定，实现监管节点31对业务节点11的监督管理职能。66.任意一个业务节点11产生的业务数据会被第一数据库21定时采集并存储，然后按照预设格式，如填入了与业务节点对应的预先设计好的记录表中，并附加上业务节点11对应的特征参数，如业务节点11对应的机构名称、代码等基本信息后，定时推送到第三数据库22中，第三数据库22是非关系型数据库，对第一数据库推送上来的数据，进行逆结构化解耦，如将其打散为键值对的形式存储，这样就不会受到第一数据库中表格的结构性限制，在新增业务节点11时，就不需要单独再定制从第一数据库21到第二数据库23的推送代码，避免了重复性地开发工作，降低了运维成本。67.当监管节点31向数据推送平台发出数据上报请求时，第二数据库23从第三数据库22中提取对应的目标数据配置到对应的数据采集表中，然后推送给监管节点31。68.下面以分步介绍上述场景中推送数据配置的具体步骤。69.图2为本技术实施例提供的一种推送数据配置方法的流程示意图。如图2所示，该推送数据配置方法的具体步骤包括：70.s201、解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表。71.在本步骤中，当数据推送平台新增业务节点，或者是监管节点发布了新的监管要求，即更改了数据提交格式时，就会触发本实施例的推送数据重新配置。72.在本实施例中，第一数据库用于向监管节点推送至少一个业务节点的业务数据，第一数据库包括关系型数据库。73.需要说明的是，关系型数据库，是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。用户通过查询来检索数据库中的数据，而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型，而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。74.由于关系型数据库是最早出现的，也是目前使用最为广泛且技术最为成熟的数据库解决方案，因此，本实施例中的第一数据库保留了关系型数据库的设定。75.监管节点发布的监管要求信息一般也是以表格的形式进行发布的，数据推送平台在接收到此监管要求表格后，对表格中的各个字段进行提取。就能够得到需要配置的各个数据字段。76.s202、将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中。77.在本实施例中，第二数据库包括关系型数据库，第三数据库包括非关系型数据库。78.在本步骤中，在第一预设时间，第二数据库利用数据抽取工具从各个业务节点抽取业务数据，并存储到第二数据库根据每个业务节点不同的个性化业务特点设计的数据表中。可选的，第一预设时间可以是固定的时间周期，也可以是根据各个业务节点触发的上报时间，也可以是对每个业务节点分别设置不同的抽取周期。79.需要说明的是，第二数据库一般也设计为关系型数据库，这样可以保证抽取数据的精确性及逻辑严谨性。80.这样在一种可能的设计中，第一数据库和第二数据库都是采用sql语言编写管理逻辑的关系型数据库，保证了业务数据的输入和输出的结构严谨，逻辑严密，提高数据的精确性。81.接下来，要解决的就是，在数据推送平台内部数据传递时，要求数据库的可拓展性，或者数据管理的灵活性需求。本实施例引入了非关系型数据库即第三数据库来作为中介媒介，实现第一数据库和第二数据库之间数据推送时的逆结构化解耦。82.非关系型的数据库(nosql)：随着互联网web2.0网站的兴起，传统的关系型数据库在处理web2.0网站，特别是超大规模和高并发的sns类型的web2.0纯动态网站已经显得力不从心，出现了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。nosql数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，特别是大数据应用难题。83.非关系型的数据库包括：84.(1)键值(key‑value)存储数据库：这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。key/value模型对于it系统来说的优势在于简单、易部署。举例如：tokyocabinet/tyrant，redis，voldemort，oraclebdb。85.(2)列存储数据库：这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：cassandra，hbase，riak。86.(3)文档型数据库：文档型数据库的灵感是来自于lotusnotes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如json。文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值，在处理网页等复杂数据时，文档型数据库比传统键值数据库的查询效率更高。如：couchdb，mongodb.国内也有文档型数据库sequoiadb，已经开源。87.(4)图形(graph)数据库：图形结构的数据库同其他行列以及刚性结构的sql数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。nosql数据库没有标准的查询语言(sql)，因此进行数据库查询需要制定数据模型。许多nosql数据库都有rest式的数据接口或者查询api。如：neo4j，infogrid，infinitegraph。88.在一种可能的设计中，第二数据库对抽取到的业务数据进行分类，如分为业务基础数据及节点基本信息数据，然后将其以键值对的形式转换为字符串，如json字符串，然后按照一定顺序组合，并存储到一个document文档中，存入第三数据库中。或者是，将业务基础数据及节点基本信息数据转化为图像数据，如二维码存储到第三数据库中。89.本实施例通过引入非关系型的数据库即第三数据库，使得在业务节点新增，监管节点新增，监管节点对应的监管范围变化或者是监管节点所需要的数据报表形式发生变化时，开发人员或者运维人员，只需要在第三数据库中进行简单的对应关系设置，即可完成推送数据配置映射的更新，无需再像现有技术那样重新去设计和编写sql代码来增、删、改、查第一数据库和第二数据库，从而达到降低运维成本，减轻开发人员工作量的技术效果。90.s203、利用预设配置工具，将目标数据配置到监管数据采集表中。91.在本步骤中，监管数据采集表是第一数据库推送给各个监管节点的数据，其所需要填写的内容数据，通过预设配置工具，从第三数据库中进行提取。92.需要说明的是，预设配置工具中设置有第三数据库与第一数据库数据映射的规则，如第三数据库为json字符串，那么其与第一数据库中的字段名称需要预先建立对应关系。93.目标数据包括两个部分：业务节点的基础信息以及业务节点产生的业务数据。94.本实施例提供了一种推送数据配置方法，通过解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，然后将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，再利用预设配置工具，将目标数据配置到监管数据采集表中，其中，第一数据库用于向监管节点推送业务节点的业务数据，第二数据库用于提取业务节点的业务数据，第一数据库和第二数据库包括关系型数据库，第三数据库包括非关系型数据库。借助非关系型的第三数据库，解决了现有技术中两个关系型数据库之间数据的转移映射需要额外定制开发编写专门代码的技术问题。达到了节省业务节点向监管节点上报数据时，需要为每个业务节点都单独定制数据上报逻辑代码的步骤，简化了数据推送平台的运维工作量的技术效果。95.为了便于理解，下面以各省级医疗监管部门对各个医疗机构的监管为例，进行进一步的细化说明。96.图3为本技术实施例提供的另一种推送数据配置方法的流程示意图。如图3所示，该推送数据配置方法的具体步骤包括：97.s301、在检测到预设触发信号时，获取目标监管节点的监管信息。98.在本实施例中，预设触发信号，包括：新增业务节点、新增监管节点、监管节点所管辖的业务节点范围发生变化、监管节点的上报要求信息发生了变化。99.在本实施例中，各个业务节点对应各个医疗机构，各个监管节点对应医疗结构所在地对应的省级监管机构。100.当有新的医疗机构加入到业务管理平台时，业务管理平台就会检测其是否落入到现有的监管节点所对应的监管范围内，若是，则识别出其对应的目标监管节点，并读取目标监管节点所发布的监管信息，如需要医疗机构上报的诊疗数据采集表。101.s302、解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表。102.在本步骤中，第一数据库用于向所述监管节点推送至少一个业务节点的业务数据，且第一数据库包括关系型数据库。103.需要说明的是，在本实施例中，第一数据库为mysql数据库集群，其中包括多个mysql关系型数据库。104.mysql是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。mysql所使用的sql语言是用于访问数据库的最常用标准化语言。但是，这些优点的实现是基于严格的sql代码的定制开发所决定的，也正是关系型数据库在面对越来越频繁的更新维护或迁移拓展时，给开发人员增加了很多重复性开发工作的根源。105.在本实施例中，对于监管配置数据库即第一数据库，仍然保留其使用关系型数据库的优点，这样可以继续利用其成熟完善的优势，对原有代码的影响较小。106.但是，本技术发明人为了使得第一数据库能够适应本实施所提供的推送数据配置方法，对其数据表即监管数据采集表进行了重新设计，不再是像原先只有一张表，而是对其进行了层次化分类。107.在本实施例中，监管数据采集表包括：业务节点表、接口表、业务数据表。108.业务节点表，用于：存储业务节点的代号、简介、运营情况概述等信息。109.接口表，用于：存储与业务节点对应的接口id号，接口描述等内容。110.业务数据表，用于：存储与接口对应的具体数据字段以及与第三数据库相同含义字段的对应关系信息。111.具体的，在本实施例中，业务节点表为医院表(hospital)：存储相应的医院代码id号,医院介绍，医院概述等信息；112.接口表为不同的医院需要的接口数据表(hospital_interface)：生成不同医院需要推送给监管平台的接口id,接口描述等，例如：针对惠爱医院生成的互联网诊疗病历、互联网诊疗处方、互联网诊疗基础信息等接口；113.业务数据表为不同医院需要的接口中字段数据表(hospital_interface_detail):生成不同医院不同数据接口需要的具体的字段与mongodb集群中相应表中字段所示的相同含义字段的jsonpath表达形式的对应关系。114.例如：mongodb中患者数据为：{"name":"张三","age":20,"sex":"男"}，但是监管平台需要的患者数据字段不同则对用关系，如表一所示：[0115][0116][0117]表一[0118]需要说明的是，mongodb集群为本实施例第三数据库所采用的数据库具体实现方式。jsonpath表达形式为第三数据库中数据的存储形式，是一种文本型的数据类型。[0119]s303、将业务数据抽取到第二数据库中进行预处理以确定目标数据。[0120]在本实施例中，目标数据包括：基本数据以及业务数据，基本数据包括业务节点的特征参数，对应的，第二数据库中的数据表包括：基本数据表以及业务数据表。[0121]需要说明的是，第二数据库为关系型数据库。如hive数据仓库。[0122]具体的，将各个微服务中的数据抽取到hive数据仓库中，方便进行数据的关联处理。具体步骤包括：[0123]s3031、利用数据抽取工具，根据基本数据表，抽取业务节点对应的基本数据。[0124]在本实施例中，数据抽取工具类似sqoop,主要用于在hadoop(hive)与传统的数据库(mysql、postgresql...)间进行数据的传递，可以将一个关系型数据库(例如：mysql,oracle,postgres等)中的数据导进到hadoop公司提供的hdfs(hadoopdistributedfilesystem，分布式文件系统)中，也可以将hdfs的数据导进到关系型数据库中。[0125]例如，数据抽取到数据仓库中之后，通过hivesql的方式按照不同的医院需要的字段不同，整合不同的数据，存入指定的hivetable中。[0126]使用hivesql组装从业务数据层定时抽取的业务数据，形成基本数据和业务数据两种：[0127]基本数据包括：患者数据、医生数据、科室数据、医院数据。[0128]s3032、利用数据抽取工具，根据业务数据表，抽取业务节点对应的业务数据。[0129]在本实施例中，业务数据这里只设计一张表：[0130]患者的诊疗业务数据(包括患者数据部分必要数据，医生部分必要数据，科室数据部分必要数据，医院数据部分必要数据，问诊订单数据，处方单数据，购药订单数据)。[0131]这样，基本数据加业务数据组成了推送监管节点的目标数据。[0132]s304、利用预设转换工具，将第二数据库中的目标数据表转换为键值对数据。[0133]在本实施例中，目标数据表用于存储目标数据。[0134]需要说明的是，[0135]s305、向第三数据库中发送键值对数据。[0136]在一种可能的设计中，具体包括：[0137]将键值对数据按预设顺序存储到至少一个文档中；[0138]其中，文档型数据库用于存储文档。[0139]需要说明的是，在本实施例中，第三数据库被设置为mongodb数据库集群。[0140]mongodb是非关系型数据库(nosql),属于文档型数据库。文档是mongodb中数据的基本单元，类似关系数据库的行，多个键值对有序地放置在一起便是文档，语法类似javascript面向对象的查询语言，它是一个面向集合的，模式自由的文档型数据库。[0141]存储方式：虚拟内存 持久化。[0142]查询语句：是独特的mongodb的查询方式。[0143]适合场景：事件的记录，内容管理或者博客平台等等。[0144]架构特点：可以通过副本集，以及分片来实现高可用。[0145]数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。[0146]而第一数据库被设置为mysql数据库集群。[0147]mysql是关系型数据库。[0148]优势：在不同的引擎上有不同的存储方式。[0149]查询语句是使用传统的sql语句，拥有较为成熟的体系，成熟度很高。[0150]缺点：在海量数据处理的时候效率会显著变慢。[0151]在本实施例中，[0152]1)mysql数据库集群设计三张核心表:[0153]医院表、不同的医院需要的接口数据表、不同医院需要的接口中字段数据表。[0154]2)mongodb库中核心数据表(针对不同的医院都设计一套数据表)：[0155]mongodb中存放的数据与hive数据仓库中整合的基本数据和业务数据相对应。包括：[0156]基本数据：患者数据、医生数据、科室数据、医院数据。[0157]业务数据：患者的诊疗业务数据(包括患者数据部分必要数据，医生部分必要数据，科室数据部分必要数据，医院数据部分必要数据，问诊订单数据，处方单数据，购药订单数据)。[0158]s306、利用预设配置工具，根据预设对应关系，将文本型文件中的字符串数据对应配置给监管数据采集表中对应的字段。[0159]具体地，当医疗业务数据层即图1中的业务层10，中有不同医院数据的时候，hive数仓中进行数据加工，将不同医院的患者数据、医生数据、科室数据、医院数据、患者的诊疗业务数据推送到mongodb数据库中。通过定时任务循环不同医院的，不同的接口数据表(hospital_interface)中的接口，按照不同医院需要的接口中字段数据表(hospital_interface_detail)中存储的监管平台需要的字段与mongodb中字段的jsonpath表达式对应关系，将数据从mongodb中提取出来，组装成相应的数据，推送到监管平台。[0160]通过本实施例提供的推送数据配置方法，省了多省多家医院对接监管的时间，只需要在页面上录入医院信息，医院需要的接口信息，医院接口需要的各个字段信息与原有的mongodb库表中各个字段jsonpath表达式的映射关系，就可以配置化的将数据推送到不同省份的监管平台，不涉及额外的开发工作。[0161]本实施例提供了一种推送数据配置方法，通过解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，然后将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，再利用预设配置工具，将目标数据配置到监管数据采集表中，其中，第一数据库用于向监管节点推送业务节点的业务数据，第二数据库用于提取业务节点的业务数据，第一数据库和第二数据库包括关系型数据库，第三数据库包括非关系型数据库。借助非关系型的第三数据库，解决了现有技术中两个关系型数据库之间数据的转移映射需要额外定制开发编写专门代码的技术问题。达到了节省业务节点向监管节点上报数据时，需要为每个业务节点都单独定制数据上报逻辑代码的步骤，简化了数据推送平台的运维工作量的技术效果。[0162]图4为本技术实施例提供的一种推送数据配置装置的结构示意图。[0163]该推送数据配置装置400可以通过软件、硬件或者两者的结合实现。[0164]如图4所示，该推送数据配置装置400包括：[0165]解析模块401，用于解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，第一数据库用于向监管节点推送至少一个业务节点的业务数据，第一数据库包括关系型数据库；[0166]抽取模块402，用于将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，第二数据库包括关系型数据库，第三数据库包括非关系型数据库；[0167]配置模块402，用于利用预设配置工具，将目标数据配置到监管数据采集表中。[0168]在一种可能的设计中，抽取模块402，具体用于：[0169]利用预设转换工具，将第二数据库中的目标数据表转换为键值对数据，目标数据表用于存储目标数据；[0170]向第三数据库中发送键值对数据。[0171]在一种可能的设计中，非关系型数据库包括文档型数据库，抽取模块402，用于将键值对数据按预设顺序存储到至少一个文档中；[0172]其中，文档型数据库用于存储文档。[0173]在一种可能的设计中，文档包括文本型文件，配置模块402，用于利用预设配置工具，根据预设对应关系，将文本型文件中的字符串数据对应配置给，监管数据采集表中对应的字段。[0174]在一种可能的设计中，目标数据包括：基本数据以及业务数据，基本数据包括业务节点的特征参数，对应的，第二数据库中的数据表包括：基本数据表以及业务数据表；[0175]对应的，抽取模块402，具体用于：[0176]利用数据抽取工具，根据基本数据表，抽取业务节点对应的基本数据；[0177]利用数据抽取工具，根据业务数据表，抽取业务节点对应的业务数据。[0178]可选的，解析模块401，还用于在检测到预设触发信号时，获取目标监管节点的监管信息。[0179]在一种可能的设计中，预设触发信号，包括：新增业务节点、新增监管节点、监管节点所管辖的业务节点范围发生变化、监管节点的上报要求信息发生了变化。[0180]值得说明的是，图4所示实施例提供的装置，可以执行上述任一方法实施例中所提供的方法，其具体实现原理、技术特征、专业名词解释以及技术效果类似，在此不再赘述。[0181]图5为本技术实施例提供的一种电子设备的结构示意图。如图5所示，该电子设备500，可以包括：至少一个处理器501和存储器502。图5示出的是以一个处理器为例的电子设备。[0182]存储器502，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。[0183]存储器502可能包含高速ram存储器，也可能还包括非易失性存储器(non‑volatilememory)，例如至少一个磁盘存储器。[0184]处理器501用于执行存储器502存储的计算机执行指令，以实现以上各方法实施例所述的方法。[0185]其中，处理器501可能是一个中央处理器(centralprocessingunit，简称为cpu)，或者是特定集成电路(applicationspecificintegratedcircuit，简称为asic)，或者是被配置成实施本技术实施例的一个或多个集成电路。[0186]可选地，存储器502既可以是独立的，也可以跟处理器501集成在一起。当所述存储器502是独立于处理器501之外的器件时，所述电子设备500，还可以包括：[0187]总线503，用于连接所述处理器501以及所述存储器502。总线可以是工业标准体系结构(industrystandardarchitecture，简称为isa)总线、外部设备互连(peripheralcomponent，pci)总线或扩展工业标准体系结构(extendedindustrystandardarchitecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。[0188]可选的，在具体实现上，如果存储器502和处理器501集成在一块芯片上实现，则存储器502和处理器501可以通过内部接口完成通信。[0189]本技术实施例还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：u盘、移动硬盘、只读存储器(read‑onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有程序指令，程序指令用于上述各方法实施例中的方法。[0190]本技术实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的方法。[0191]本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本
技术领域：
：中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由本技术的权利要求书指出。[0192]应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求书来限制。[0193]最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。当前第1页12当前第1页12
技术领域：
：，尤其涉及一种推送数据配置方法、装置、设备、介质及程序产品。
背景技术：
：：2.随着经济和社会的不断发展，特别是互联网技术普及之后，很多业务活动都需要网络系统来辅助运营和管理。一般在网络系统中，业务节点负责具体业务活动的执行，并向监管机构所在的监管节点上报业务活动的数据，以使监管机构监督业务节点的业务活动是否符合规范要求。3.而业务节点所产生的业务数据一般存储在业务数据库中，而监管节点需要通过读取监管数据库中的数据来审核业务节点的业务活动。因此就需要将业务数据库中的数据推送到监管数据库中。然而，现有技术中，由于两个数据库单独构建和维护，一般来说，数据库的构建会采用较为成熟的数据库技术，如mysql关系型数据库，但是两个关系型数据库之间数据的推送需要专门定制sql语言代码的开发来实现。4.然而，随着业务的快速发展，业务节点不断增加，随之而来的是更多的监管节点也需要对应接入数据推送平台，这就使得数据推送平台的运营维护陷入到了不断定制开发各个数据库之间数据推送的重复性工作当中，耗时耗力，增加运维成本。因此，现有技术中存在两个关系型数据库之间数据的转移映射需要额外定制开发编写专门代码的技术问题。技术实现要素：5.本技术提供一种推送数据配置方法、装置、设备、介质及程序产品，以解决现有技术中两个关系型数据库之间数据的转移映射需要额外定制开发编写专门代码的技术问题。6.第一个方面，本技术提供一种推送数据配置方法，包括：7.解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，第一数据库用于向监管节点推送至少一个业务节点的业务数据，第一数据库包括关系型数据库；8.将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，第二数据库包括关系型数据库，第三数据库包括非关系型数据库；9.利用预设配置工具，将目标数据配置到监管数据采集表中。10.在一种可能的设计中，将目标数据以预设格式推送到第三数据库中，包括：11.利用预设转换工具，将第二数据库中的目标数据表转换为键值对数据，目标数据表用于存储目标数据；12.向第三数据库中发送键值对数据。13.在一种可能的设计中，非关系型数据库包括文档型数据库，向第三数据库中发送键值对数据，包括：14.将键值对数据按预设顺序存储到至少一个文档中；15.其中，文档型数据库用于存储文档。16.在一种可能的设计中，文档包括文本型文件，利用预设配置工具，将目标数据配置到监管数据采集表中，包括：17.利用预设配置工具，根据预设对应关系，将文本型文件中的字符串数据对应配置给，监管数据采集表中对应的字段。18.在一种可能的设计中，目标数据包括：基本数据以及业务数据，基本数据包括业务节点的特征参数，对应的，第二数据库中的数据表包括：基本数据表以及业务数据表，将业务数据抽取到第二数据库中进行预处理以确定目标数据，包括：19.利用数据抽取工具，根据基本数据表，抽取业务节点对应的基本数据；20.利用数据抽取工具，根据业务数据表，抽取业务节点对应的业务数据。21.可选的，在解析至少一个监管节点发布的监管要求信息之前，还包括：22.在检测到预设触发信号时，获取目标监管节点的监管信息。23.在一种可能的设计中，预设触发信号，包括：新增业务节点、新增监管节点、监管节点所管辖的业务节点范围发生变化、监管节点的上报要求信息发生了变化。24.第二方面，本技术提供一种推送数据配置装置，包括：25.解析模块，用于解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，第一数据库用于向监管节点推送至少一个业务节点的业务数据，第一数据库包括关系型数据库；26.抽取模块，用于将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，第二数据库包括关系型数据库，第三数据库包括非关系型数据库；27.配置模块，用于利用预设配置工具，将目标数据配置到监管数据采集表中。28.在一种可能的设计中，抽取模块，具体用于：29.利用预设转换工具，将第二数据库中的目标数据表转换为键值对数据，目标数据表用于存储目标数据；30.向第三数据库中发送键值对数据。31.在一种可能的设计中，非关系型数据库包括文档型数据库，抽取模块，用于将键值对数据按预设顺序存储到至少一个文档中；32.其中，文档型数据库用于存储文档。33.在一种可能的设计中，文档包括文本型文件，配置模块，用于利用预设配置工具，根据预设对应关系，将文本型文件中的字符串数据对应配置给，监管数据采集表中对应的字段。34.在一种可能的设计中，目标数据包括：基本数据以及业务数据，基本数据包括业务节点的特征参数，对应的，第二数据库中的数据表包括：基本数据表以及业务数据表；35.对应的，抽取模块，具体用于：36.利用数据抽取工具，根据基本数据表，抽取业务节点对应的基本数据；37.利用数据抽取工具，根据业务数据表，抽取业务节点对应的业务数据。38.可选的，解析模块，还用于在检测到预设触发信号时，获取目标监管节点的监管信息。39.在一种可能的设计中，预设触发信号，包括：新增业务节点、新增监管节点、监管节点所管辖的业务节点范围发生变化、监管节点的上报要求信息发生了变化。40.第三个方面，本技术提供一种电子设备，包括：41.存储器，用于存储程序指令；42.处理器，用于调用并执行所述存储器中的程序指令，执行第一方面所提供的任意一种可能的推送数据配置方法。43.第四方面，本技术提供一种存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序用于执行第一方面所提供的任意一种可能的推送数据配置方法。44.第五方面，本技术还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面所提供的任意一种可能的推送数据配置方法。45.本技术提供了一种推送数据配置方法、装置、设备、介质及程序产品，通过解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，然后将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，再利用预设配置工具，将目标数据配置到监管数据采集表中，其中，第一数据库用于向监管节点推送业务节点的业务数据，第二数据库用于提取业务节点的业务数据，第一数据库和第二数据库包括关系型数据库，第三数据库包括非关系型数据库。借助非关系型的第三数据库，解决了现有技术中两个关系型数据库之间数据的转移映射需要额外定制开发编写专门代码的技术问题。达到了节省业务节点向监管节点上报数据时，需要为每个业务节点都单独定制数据上报逻辑代码的步骤，简化了数据推送平台的运维工作量的技术效果。附图说明46.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。47.图1为本技术实施例提供的一种数据推送平台的结构示意图；48.图2为本技术实施例提供的一种推送数据配置方法的流程示意图；49.图3为本技术实施例提供的另一种推送数据配置方法的流程示意图；50.图4为本技术实施例提供的一种推送数据配置装置的结构示意图；51.图5为本技术提供的一种电子设备的结构示意图。52.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。具体实施方式53.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，包括但不限于对多个实施例的组合，都属于本技术保护的范围。54.本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。55.下面对本技术的发明构思形成的逻辑进行介绍：56.一个业务管理系统一般包括多个业务节点以及至少一个监管节点，随着现实中业务的不断发展，业务节点数量不断增多，同时，其可能引起监管节点的增加，或是监管节点更新了监管范围或者监管数据的提交要求。57.上述的各种情况，都需要业务管理系统的运维人员对业务管理系统进行二次开发及维护。通常业务管理系统会利用一个业务数据库来提取和存储各个业务节点的业务数据。然后通过数据推送平台，向不同监管机构所对应的监管节点推送其所要求上报的数据，以便于监管机构对业务节点所对应的业务机构进行监管。58.在推送前，数据推送平台可以构建一个专门存储推送数据的监管配置数据库，在向监管节点推送数据前，监管配置数据库先从业务数据库中提取并配置数据采集表。59.进一步的，为了满足多监管节点和多业务节点间数据推送要求多样化，格式不统一的需求，需要开发人员不断进行更新推送代码和配置代码二次开发，而这也是本技术需要进一步解决的问题。60.一般来说，数据库分为关系型数据库和非关系型数据库两类，其中，关系型数据库的应用较为广泛与成熟。sql(structuredquerylanguage，结构化查询语言)数据库就是应用最广泛的数据库，上述的业务数据库、监管节点自己所建立与管理的数据库，监管配置数据库一般都是关系型数据库。61.本技术发明人发现，正是由于关系型数据库之间数据推送要遵循sql语言的严格规范化要求，使得数据推送需要专门的代码定制开发。62.而本技术的发明构思就是想要打破这种惯性思维，利用非关系型数据库作为中间媒介，将严格死板的结构化数据进行解耦拆解，简化数据推送时的要求，使得数据推送的可拓展性得到提高，只需要简单设置配置参数即可完成业务数据从业务数据库向监管配置数据库的推送配置，而监管配置数据库向监管节点的推送就不需要二次开发，大大减少了开发人员的工作量，降低了运维成本。63.下面以具体地实施例对本技术的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本技术的实施例进行描述。64.图1为本技术实施例提供的一种数据推送平台的结构示意图。如图1所示，数据推送平台的两端分别连接着业务层10和监管层30，业务层10中包括多个业务节点11，监管层30中包括多个监管节点31。65.每个业务节点11都要向其对应的监管节点31上报其业务数据，以满足法规要求的监管规定，实现监管节点31对业务节点11的监督管理职能。66.任意一个业务节点11产生的业务数据会被第一数据库21定时采集并存储，然后按照预设格式，如填入了与业务节点对应的预先设计好的记录表中，并附加上业务节点11对应的特征参数，如业务节点11对应的机构名称、代码等基本信息后，定时推送到第三数据库22中，第三数据库22是非关系型数据库，对第一数据库推送上来的数据，进行逆结构化解耦，如将其打散为键值对的形式存储，这样就不会受到第一数据库中表格的结构性限制，在新增业务节点11时，就不需要单独再定制从第一数据库21到第二数据库23的推送代码，避免了重复性地开发工作，降低了运维成本。67.当监管节点31向数据推送平台发出数据上报请求时，第二数据库23从第三数据库22中提取对应的目标数据配置到对应的数据采集表中，然后推送给监管节点31。68.下面以分步介绍上述场景中推送数据配置的具体步骤。69.图2为本技术实施例提供的一种推送数据配置方法的流程示意图。如图2所示，该推送数据配置方法的具体步骤包括：70.s201、解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表。71.在本步骤中，当数据推送平台新增业务节点，或者是监管节点发布了新的监管要求，即更改了数据提交格式时，就会触发本实施例的推送数据重新配置。72.在本实施例中，第一数据库用于向监管节点推送至少一个业务节点的业务数据，第一数据库包括关系型数据库。73.需要说明的是，关系型数据库，是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。用户通过查询来检索数据库中的数据，而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型，而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。74.由于关系型数据库是最早出现的，也是目前使用最为广泛且技术最为成熟的数据库解决方案，因此，本实施例中的第一数据库保留了关系型数据库的设定。75.监管节点发布的监管要求信息一般也是以表格的形式进行发布的，数据推送平台在接收到此监管要求表格后，对表格中的各个字段进行提取。就能够得到需要配置的各个数据字段。76.s202、将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中。77.在本实施例中，第二数据库包括关系型数据库，第三数据库包括非关系型数据库。78.在本步骤中，在第一预设时间，第二数据库利用数据抽取工具从各个业务节点抽取业务数据，并存储到第二数据库根据每个业务节点不同的个性化业务特点设计的数据表中。可选的，第一预设时间可以是固定的时间周期，也可以是根据各个业务节点触发的上报时间，也可以是对每个业务节点分别设置不同的抽取周期。79.需要说明的是，第二数据库一般也设计为关系型数据库，这样可以保证抽取数据的精确性及逻辑严谨性。80.这样在一种可能的设计中，第一数据库和第二数据库都是采用sql语言编写管理逻辑的关系型数据库，保证了业务数据的输入和输出的结构严谨，逻辑严密，提高数据的精确性。81.接下来，要解决的就是，在数据推送平台内部数据传递时，要求数据库的可拓展性，或者数据管理的灵活性需求。本实施例引入了非关系型数据库即第三数据库来作为中介媒介，实现第一数据库和第二数据库之间数据推送时的逆结构化解耦。82.非关系型的数据库(nosql)：随着互联网web2.0网站的兴起，传统的关系型数据库在处理web2.0网站，特别是超大规模和高并发的sns类型的web2.0纯动态网站已经显得力不从心，出现了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。nosql数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，特别是大数据应用难题。83.非关系型的数据库包括：84.(1)键值(key‑value)存储数据库：这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。key/value模型对于it系统来说的优势在于简单、易部署。举例如：tokyocabinet/tyrant，redis，voldemort，oraclebdb。85.(2)列存储数据库：这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：cassandra，hbase，riak。86.(3)文档型数据库：文档型数据库的灵感是来自于lotusnotes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如json。文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值，在处理网页等复杂数据时，文档型数据库比传统键值数据库的查询效率更高。如：couchdb，mongodb.国内也有文档型数据库sequoiadb，已经开源。87.(4)图形(graph)数据库：图形结构的数据库同其他行列以及刚性结构的sql数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。nosql数据库没有标准的查询语言(sql)，因此进行数据库查询需要制定数据模型。许多nosql数据库都有rest式的数据接口或者查询api。如：neo4j，infogrid，infinitegraph。88.在一种可能的设计中，第二数据库对抽取到的业务数据进行分类，如分为业务基础数据及节点基本信息数据，然后将其以键值对的形式转换为字符串，如json字符串，然后按照一定顺序组合，并存储到一个document文档中，存入第三数据库中。或者是，将业务基础数据及节点基本信息数据转化为图像数据，如二维码存储到第三数据库中。89.本实施例通过引入非关系型的数据库即第三数据库，使得在业务节点新增，监管节点新增，监管节点对应的监管范围变化或者是监管节点所需要的数据报表形式发生变化时，开发人员或者运维人员，只需要在第三数据库中进行简单的对应关系设置，即可完成推送数据配置映射的更新，无需再像现有技术那样重新去设计和编写sql代码来增、删、改、查第一数据库和第二数据库，从而达到降低运维成本，减轻开发人员工作量的技术效果。90.s203、利用预设配置工具，将目标数据配置到监管数据采集表中。91.在本步骤中，监管数据采集表是第一数据库推送给各个监管节点的数据，其所需要填写的内容数据，通过预设配置工具，从第三数据库中进行提取。92.需要说明的是，预设配置工具中设置有第三数据库与第一数据库数据映射的规则，如第三数据库为json字符串，那么其与第一数据库中的字段名称需要预先建立对应关系。93.目标数据包括两个部分：业务节点的基础信息以及业务节点产生的业务数据。94.本实施例提供了一种推送数据配置方法，通过解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，然后将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，再利用预设配置工具，将目标数据配置到监管数据采集表中，其中，第一数据库用于向监管节点推送业务节点的业务数据，第二数据库用于提取业务节点的业务数据，第一数据库和第二数据库包括关系型数据库，第三数据库包括非关系型数据库。借助非关系型的第三数据库，解决了现有技术中两个关系型数据库之间数据的转移映射需要额外定制开发编写专门代码的技术问题。达到了节省业务节点向监管节点上报数据时，需要为每个业务节点都单独定制数据上报逻辑代码的步骤，简化了数据推送平台的运维工作量的技术效果。95.为了便于理解，下面以各省级医疗监管部门对各个医疗机构的监管为例，进行进一步的细化说明。96.图3为本技术实施例提供的另一种推送数据配置方法的流程示意图。如图3所示，该推送数据配置方法的具体步骤包括：97.s301、在检测到预设触发信号时，获取目标监管节点的监管信息。98.在本实施例中，预设触发信号，包括：新增业务节点、新增监管节点、监管节点所管辖的业务节点范围发生变化、监管节点的上报要求信息发生了变化。99.在本实施例中，各个业务节点对应各个医疗机构，各个监管节点对应医疗结构所在地对应的省级监管机构。100.当有新的医疗机构加入到业务管理平台时，业务管理平台就会检测其是否落入到现有的监管节点所对应的监管范围内，若是，则识别出其对应的目标监管节点，并读取目标监管节点所发布的监管信息，如需要医疗机构上报的诊疗数据采集表。101.s302、解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表。102.在本步骤中，第一数据库用于向所述监管节点推送至少一个业务节点的业务数据，且第一数据库包括关系型数据库。103.需要说明的是，在本实施例中，第一数据库为mysql数据库集群，其中包括多个mysql关系型数据库。104.mysql是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。mysql所使用的sql语言是用于访问数据库的最常用标准化语言。但是，这些优点的实现是基于严格的sql代码的定制开发所决定的，也正是关系型数据库在面对越来越频繁的更新维护或迁移拓展时，给开发人员增加了很多重复性开发工作的根源。105.在本实施例中，对于监管配置数据库即第一数据库，仍然保留其使用关系型数据库的优点，这样可以继续利用其成熟完善的优势，对原有代码的影响较小。106.但是，本技术发明人为了使得第一数据库能够适应本实施所提供的推送数据配置方法，对其数据表即监管数据采集表进行了重新设计，不再是像原先只有一张表，而是对其进行了层次化分类。107.在本实施例中，监管数据采集表包括：业务节点表、接口表、业务数据表。108.业务节点表，用于：存储业务节点的代号、简介、运营情况概述等信息。109.接口表，用于：存储与业务节点对应的接口id号，接口描述等内容。110.业务数据表，用于：存储与接口对应的具体数据字段以及与第三数据库相同含义字段的对应关系信息。111.具体的，在本实施例中，业务节点表为医院表(hospital)：存储相应的医院代码id号,医院介绍，医院概述等信息；112.接口表为不同的医院需要的接口数据表(hospital_interface)：生成不同医院需要推送给监管平台的接口id,接口描述等，例如：针对惠爱医院生成的互联网诊疗病历、互联网诊疗处方、互联网诊疗基础信息等接口；113.业务数据表为不同医院需要的接口中字段数据表(hospital_interface_detail):生成不同医院不同数据接口需要的具体的字段与mongodb集群中相应表中字段所示的相同含义字段的jsonpath表达形式的对应关系。114.例如：mongodb中患者数据为：{"name":"张三","age":20,"sex":"男"}，但是监管平台需要的患者数据字段不同则对用关系，如表一所示：[0115][0116][0117]表一[0118]需要说明的是，mongodb集群为本实施例第三数据库所采用的数据库具体实现方式。jsonpath表达形式为第三数据库中数据的存储形式，是一种文本型的数据类型。[0119]s303、将业务数据抽取到第二数据库中进行预处理以确定目标数据。[0120]在本实施例中，目标数据包括：基本数据以及业务数据，基本数据包括业务节点的特征参数，对应的，第二数据库中的数据表包括：基本数据表以及业务数据表。[0121]需要说明的是，第二数据库为关系型数据库。如hive数据仓库。[0122]具体的，将各个微服务中的数据抽取到hive数据仓库中，方便进行数据的关联处理。具体步骤包括：[0123]s3031、利用数据抽取工具，根据基本数据表，抽取业务节点对应的基本数据。[0124]在本实施例中，数据抽取工具类似sqoop,主要用于在hadoop(hive)与传统的数据库(mysql、postgresql...)间进行数据的传递，可以将一个关系型数据库(例如：mysql,oracle,postgres等)中的数据导进到hadoop公司提供的hdfs(hadoopdistributedfilesystem，分布式文件系统)中，也可以将hdfs的数据导进到关系型数据库中。[0125]例如，数据抽取到数据仓库中之后，通过hivesql的方式按照不同的医院需要的字段不同，整合不同的数据，存入指定的hivetable中。[0126]使用hivesql组装从业务数据层定时抽取的业务数据，形成基本数据和业务数据两种：[0127]基本数据包括：患者数据、医生数据、科室数据、医院数据。[0128]s3032、利用数据抽取工具，根据业务数据表，抽取业务节点对应的业务数据。[0129]在本实施例中，业务数据这里只设计一张表：[0130]患者的诊疗业务数据(包括患者数据部分必要数据，医生部分必要数据，科室数据部分必要数据，医院数据部分必要数据，问诊订单数据，处方单数据，购药订单数据)。[0131]这样，基本数据加业务数据组成了推送监管节点的目标数据。[0132]s304、利用预设转换工具，将第二数据库中的目标数据表转换为键值对数据。[0133]在本实施例中，目标数据表用于存储目标数据。[0134]需要说明的是，[0135]s305、向第三数据库中发送键值对数据。[0136]在一种可能的设计中，具体包括：[0137]将键值对数据按预设顺序存储到至少一个文档中；[0138]其中，文档型数据库用于存储文档。[0139]需要说明的是，在本实施例中，第三数据库被设置为mongodb数据库集群。[0140]mongodb是非关系型数据库(nosql),属于文档型数据库。文档是mongodb中数据的基本单元，类似关系数据库的行，多个键值对有序地放置在一起便是文档，语法类似javascript面向对象的查询语言，它是一个面向集合的，模式自由的文档型数据库。[0141]存储方式：虚拟内存 持久化。[0142]查询语句：是独特的mongodb的查询方式。[0143]适合场景：事件的记录，内容管理或者博客平台等等。[0144]架构特点：可以通过副本集，以及分片来实现高可用。[0145]数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。[0146]而第一数据库被设置为mysql数据库集群。[0147]mysql是关系型数据库。[0148]优势：在不同的引擎上有不同的存储方式。[0149]查询语句是使用传统的sql语句，拥有较为成熟的体系，成熟度很高。[0150]缺点：在海量数据处理的时候效率会显著变慢。[0151]在本实施例中，[0152]1)mysql数据库集群设计三张核心表:[0153]医院表、不同的医院需要的接口数据表、不同医院需要的接口中字段数据表。[0154]2)mongodb库中核心数据表(针对不同的医院都设计一套数据表)：[0155]mongodb中存放的数据与hive数据仓库中整合的基本数据和业务数据相对应。包括：[0156]基本数据：患者数据、医生数据、科室数据、医院数据。[0157]业务数据：患者的诊疗业务数据(包括患者数据部分必要数据，医生部分必要数据，科室数据部分必要数据，医院数据部分必要数据，问诊订单数据，处方单数据，购药订单数据)。[0158]s306、利用预设配置工具，根据预设对应关系，将文本型文件中的字符串数据对应配置给监管数据采集表中对应的字段。[0159]具体地，当医疗业务数据层即图1中的业务层10，中有不同医院数据的时候，hive数仓中进行数据加工，将不同医院的患者数据、医生数据、科室数据、医院数据、患者的诊疗业务数据推送到mongodb数据库中。通过定时任务循环不同医院的，不同的接口数据表(hospital_interface)中的接口，按照不同医院需要的接口中字段数据表(hospital_interface_detail)中存储的监管平台需要的字段与mongodb中字段的jsonpath表达式对应关系，将数据从mongodb中提取出来，组装成相应的数据，推送到监管平台。[0160]通过本实施例提供的推送数据配置方法，省了多省多家医院对接监管的时间，只需要在页面上录入医院信息，医院需要的接口信息，医院接口需要的各个字段信息与原有的mongodb库表中各个字段jsonpath表达式的映射关系，就可以配置化的将数据推送到不同省份的监管平台，不涉及额外的开发工作。[0161]本实施例提供了一种推送数据配置方法，通过解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，然后将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，再利用预设配置工具，将目标数据配置到监管数据采集表中，其中，第一数据库用于向监管节点推送业务节点的业务数据，第二数据库用于提取业务节点的业务数据，第一数据库和第二数据库包括关系型数据库，第三数据库包括非关系型数据库。借助非关系型的第三数据库，解决了现有技术中两个关系型数据库之间数据的转移映射需要额外定制开发编写专门代码的技术问题。达到了节省业务节点向监管节点上报数据时，需要为每个业务节点都单独定制数据上报逻辑代码的步骤，简化了数据推送平台的运维工作量的技术效果。[0162]图4为本技术实施例提供的一种推送数据配置装置的结构示意图。[0163]该推送数据配置装置400可以通过软件、硬件或者两者的结合实现。[0164]如图4所示，该推送数据配置装置400包括：[0165]解析模块401，用于解析至少一个监管节点发布的监管要求信息，以确定第一数据库中的监管数据采集表，第一数据库用于向监管节点推送至少一个业务节点的业务数据，第一数据库包括关系型数据库；[0166]抽取模块402，用于将业务数据抽取到第二数据库中进行预处理以确定目标数据，并将目标数据以预设格式推送到第三数据库中，第二数据库包括关系型数据库，第三数据库包括非关系型数据库；[0167]配置模块402，用于利用预设配置工具，将目标数据配置到监管数据采集表中。[0168]在一种可能的设计中，抽取模块402，具体用于：[0169]利用预设转换工具，将第二数据库中的目标数据表转换为键值对数据，目标数据表用于存储目标数据；[0170]向第三数据库中发送键值对数据。[0171]在一种可能的设计中，非关系型数据库包括文档型数据库，抽取模块402，用于将键值对数据按预设顺序存储到至少一个文档中；[0172]其中，文档型数据库用于存储文档。[0173]在一种可能的设计中，文档包括文本型文件，配置模块402，用于利用预设配置工具，根据预设对应关系，将文本型文件中的字符串数据对应配置给，监管数据采集表中对应的字段。[0174]在一种可能的设计中，目标数据包括：基本数据以及业务数据，基本数据包括业务节点的特征参数，对应的，第二数据库中的数据表包括：基本数据表以及业务数据表；[0175]对应的，抽取模块402，具体用于：[0176]利用数据抽取工具，根据基本数据表，抽取业务节点对应的基本数据；[0177]利用数据抽取工具，根据业务数据表，抽取业务节点对应的业务数据。[0178]可选的，解析模块401，还用于在检测到预设触发信号时，获取目标监管节点的监管信息。[0179]在一种可能的设计中，预设触发信号，包括：新增业务节点、新增监管节点、监管节点所管辖的业务节点范围发生变化、监管节点的上报要求信息发生了变化。[0180]值得说明的是，图4所示实施例提供的装置，可以执行上述任一方法实施例中所提供的方法，其具体实现原理、技术特征、专业名词解释以及技术效果类似，在此不再赘述。[0181]图5为本技术实施例提供的一种电子设备的结构示意图。如图5所示，该电子设备500，可以包括：至少一个处理器501和存储器502。图5示出的是以一个处理器为例的电子设备。[0182]存储器502，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。[0183]存储器502可能包含高速ram存储器，也可能还包括非易失性存储器(non‑volatilememory)，例如至少一个磁盘存储器。[0184]处理器501用于执行存储器502存储的计算机执行指令，以实现以上各方法实施例所述的方法。[0185]其中，处理器501可能是一个中央处理器(centralprocessingunit，简称为cpu)，或者是特定集成电路(applicationspecificintegratedcircuit，简称为asic)，或者是被配置成实施本技术实施例的一个或多个集成电路。[0186]可选地，存储器502既可以是独立的，也可以跟处理器501集成在一起。当所述存储器502是独立于处理器501之外的器件时，所述电子设备500，还可以包括：[0187]总线503，用于连接所述处理器501以及所述存储器502。总线可以是工业标准体系结构(industrystandardarchitecture，简称为isa)总线、外部设备互连(peripheralcomponent，pci)总线或扩展工业标准体系结构(extendedindustrystandardarchitecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等，但并不表示仅有一根总线或一种类型的总线。[0188]可选的，在具体实现上，如果存储器502和处理器501集成在一块芯片上实现，则存储器502和处理器501可以通过内部接口完成通信。[0189]本技术实施例还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：u盘、移动硬盘、只读存储器(read‑onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有程序指令，程序指令用于上述各方法实施例中的方法。[0190]本技术实施例还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的方法。[0191]本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本
技术领域：
：中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由本技术的权利要求书指出。[0192]应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求书来限制。[0193]最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
