CN114116842B - 多维医疗数据实时获取方法、装置、电子设备及存储介质 - Google Patents

多维医疗数据实时获取方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
CN114116842B
CN114116842B CN202111413929.3A CN202111413929A CN114116842B CN 114116842 B CN114116842 B CN 114116842B CN 202111413929 A CN202111413929 A CN 202111413929A CN 114116842 B CN114116842 B CN 114116842B
Authority
CN
China
Prior art keywords
data
medical data
topic
multidimensional
preset database
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.)
Active
Application number
CN202111413929.3A
Other languages
English (en)
Other versions
CN114116842A (zh
Inventor
秦晓宏
黄主斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Clinbrain Information Technology Co Ltd
Original Assignee
Shanghai Clinbrain Information Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Shanghai Clinbrain Information Technology Co Ltd filed Critical Shanghai Clinbrain Information Technology Co Ltd
Priority to CN202111413929.3A priority Critical patent/CN114116842B/zh
Publication of CN114116842A publication Critical patent/CN114116842A/zh
Application granted granted Critical
Publication of CN114116842B publication Critical patent/CN114116842B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2477—Temporal data queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2282—Tablespace storage structures; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/548—Queue
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

本申请实施例提供了一种多维医疗数据实时获取方法、装置、电子设备及存储介质，包括：对医院各业务系统的binlog进行实时解析，得到对应的第一增量医疗数据，并将第一增量医疗数据写入kafka的第一topic；通过flink消费第一topic中的第一增量医疗数据，并将第一增量医疗数据存储至第一预设数据库中，将第一增量医疗数据中事实表对应的数据写入kafka的第二topic中；获取CDR对应的至少一个查询脚本，基于每一查询脚本对应的数据表关联关系，通过flink对第一预设数据库和第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据。该方案不仅实现患者多维医疗数据获取，还保证了进行flink流上关联的实时性，进而保证了获取患者多维医疗数据的是实时性。

Description

多维医疗数据实时获取方法、装置、电子设备及存储介质
技术领域
本申请涉及计算机技术领域，具体而言，本申请涉及一种多维医疗数据实时获取方法、装置、电子设备及存储介质。
背景技术
患者到医院就诊，需要经过挂号、问诊、检验、开药过程，这些过程都会在相应的业务系统中产生医疗数据。而医院的业务系统(例如：检验系统，检查系统，影像系统，血库系统，护士站系统，电子病例(Electronic Medical Record，EMR)系统，临床信息系统(ClinicalInformation System，CIS)，体检系统等)都是独立运行的，各业务系统产生的医疗数据也是独立存储的。医生在对患者病情进行诊断的时，为了对患者的情况进行全方位了解，需要查看各个业务系统的医疗数据，则需要在各个业务系统中频繁进行切换。
如果医生能够通过一次查看获取患者在多个业务系统的医疗数据，即一次获取患者的多维医疗数据，将大大减小医生的工作量，而应对这样实时多维查看的需求，现有技术中并没有相应的针对性的多维医疗数据获取方法，因此，有必要提出一种多维医疗数据实时获取方法、装置、电子设备及计算机可读存储介质。
发明内容
本申请的目的旨在至少能解决上述的技术缺陷之一，本申请实施例所提供的技术方案如下：
第一方面，本申请实施例提供了一种多维医疗数据实时获取方法，包括：
对医院各业务系统的二进制日志binlog进行实时解析，得到对应的第一增量医疗数据，并将第一增量医疗数据写入卡夫卡kafka消息队列的第一主题topic；
通过flink消费第一topic中的第一增量医疗数据，并将第一增量医疗数据存储至第一预设数据库中，将第一增量医疗数据中事实表对应的数据写入kafka消息队列的第二topic中；
获取临床数据中心CDR对应的至少一个查询脚本，基于每一查询脚本对应的数据表关联关系，通过flink对第一预设数据库和第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，并将第一多维医疗数据存储至CDR中与该查询脚本对应的数据表中。
在本申请的一种可选实施例中，该方法还包括：
每间隔预设时间段，对各业务系统的binlog进行解析，得到对应的第二增量医疗数据，并将第二增量医疗数据写入kafka消息队列的第三topic；
通过flink消费第三topic中的第二增量医疗数据，并将第二增量医疗数据存储至数据湖层；
基于每一查询脚本，通过presto从数据湖层，查询得到该查询脚本对应的第二多维医疗数据；
若第二多维医疗数据与对应的第一多维医疗数据之间满足预设条件，则利用第二多维医疗数据替换CDR中对应的第一多维医疗数据。
在本申请的一种可选实施例中，数据湖层设置有第二预设数据库和第三预设数据库，且第二预设数据库的读写速度高于第三预设数据库的读写速度，将第二增量医疗数据存储至数据湖层，包括：
将第二增量医疗数据中事实表对应的数据存储至第二预设数据库中、将第二增量医疗数据中维度表对应的数据存储至第三预设数据库中；
相应地，基于每一查询脚本，通过presto从数据湖层，查询得到该查询脚本对应的第二多维医疗数据，包括：
基于每一查询脚本，通过presto从第二预设数据库和/或第三预设数据库中，查询得到该查询脚本对应的第二多维医疗数据。
在本申请的一种可选实施例中，第二多维医疗数据与对应的第一多维医疗数据之间满足预设条件，则利用第二多维医疗数据替换CDR中对应的第一多维医疗数据，包括：
若第一多维医疗数据的生成时间早于第二多维医疗数据的生成时间，则利用第二多维医疗数据替换第一多维医疗数据。
在本申请的一种可选实施例中，该方法还包括：
在将第一增量医疗数据存储至第一预设数据库中之前，将各业务系统的全量医疗数据存储至第一预设数据库。
在本申请的一种可选实施例中，基于每一查询脚本对应的数据表关联关系，通过flink对第一预设数据库和第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，包括：
基于每一查询脚本对应的数据表关联关系，获取该查询脚本对应的关联主表标识和至少一个关联副表标识；
通过flink获取二topic中带有关联主表标识的数据作为关联主表数据，通过flink获取第一预设数据库中带有关联副表标识的数据作为关联副表数据；
通过flink对关联主表数据和关联副表数据进行关联，得到该查询脚本对应的第一多维医疗数据。
在本申请的一种可选实施例中，通过flink对关联主表数据和关联副表数据进行关联，得到该查询脚本对应的第一多维医疗数据，包括：
通过flink将关联主表数据映射为对应的关联主表，并将关联副表数据映射为对应的关联副表；
将关联主表与关联副表进行关联，得到对应的临时数据表，临时数据表中的数据即为对应的第一多维医疗数据。
第二方面，本申请实施例提供了一种多维医疗数据实时获取装置，包括：
日志解析模块，用于对医院各业务系统的二进制日志binlog进行实时解析，得到对应的第一增量医疗数据，并将第一增量医疗数据写入卡夫卡kafka消息队列的第一主题topic；
数据存储模块，用于通过flink消费第一topic中的第一增量医疗数据，并将第一增量医疗数据存储至第一预设数据库中，将第一增量医疗数据中事实表对应的数据写入kafka消息队列的第二topic中；
数据关联模块，用于获取临床数据中心CDR对应的至少一个查询脚本，基于每一查询脚本对应的数据表关联关系，通过flink对第一预设数据库和第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，并将第一多维医疗数据存储至CDR中与该查询脚本对应的数据表中。
在本申请的一种可选实施例中，该装置还包括离线修复模块，用于：
每间隔预设时间段，对各业务系统的binlog进行解析，得到对应的第二增量医疗数据，并将第二增量医疗数据写入kafka消息队列的第三topic；
通过flink消费第三topic中的第二增量医疗数据，并将第二增量医疗数据存储至数据湖层；
基于每一查询脚本，通过presto从数据湖层，查询得到该查询脚本对应的第二多维医疗数据；
若第二多维医疗数据与对应的第一多维医疗数据之间满足预设条件，则利用第二多维医疗数据替换CDR中对应的第一多维医疗数据。
在本申请的一种可选实施例中，数据湖层设置有第二预设数据库和第三预设数据库，且第二预设数据库的读写速度高于第三预设数据库的读写速度，离线修复模块具体用于：
将第二增量医疗数据中事实表对应的数据存储至第二预设数据库中、将第二增量医疗数据中维度表对应的数据存储至第三预设数据库中；
相应地，离线修复模块具体用于还用于：
基于每一查询脚本，通过presto从第二预设数据库和/或第三预设数据库中，查询得到该查询脚本对应的第二多维医疗数据。
在本申请的一种可选实施例中，离线修复模块进一步用于：
若第一多维医疗数据的生成时间早于第二多维医疗数据的生成时间，则利用第二多维医疗数据替换第一多维医疗数据。
在本申请的一种可选实施例中，该装置还包括全量医疗数据存储模块，用于：
在将第一增量医疗数据存储至第一预设数据库中之前，将各业务系统的全量医疗数据存储至第一预设数据库。
在本申请的一种可选实施例中，数据关联模块具体用于：
基于每一查询脚本对应的数据表关联关系，获取该查询脚本对应的关联主表标识和至少一个关联副表标识；
通过flink获取二topic中带有关联主表标识的数据作为关联主表数据，通过flink获取第一预设数据库中带有关联副表标识的数据作为关联副表数据；
通过flink对关联主表数据和关联副表数据进行关联，得到该查询脚本对应的第一多维医疗数据。
在本申请的一种可选实施例中，数据关联模块进一步用于：
通过flink将关联主表数据映射为对应的关联主表，并将关联副表数据映射为对应的关联副表；
将关联主表与关联副表进行关联，得到对应的临时数据表，临时数据表中的数据即为对应的第一多维医疗数据。
第三方面，本申请实施例提供了一种电子设备，包括存储器和处理器；
存储器中存储有计算机程序；
处理器，用于执行计算机程序以实现第一方面实施例或第一方面任一可选实施例中所提供的方法。
第四方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现第一方面实施例或第一方面任一可选实施例中所提供的方法。
第五方面，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行时实现第一方面实施例或第一方面任一可选实施例中所提供的方法。
本申请提供的技术方案带来的有益效果是：
通过实时获取各业务系统中患者的新增医疗数据，并将新增医疗数据存储至第一预设数据库，同时将新增医疗数据中事实表对应的数据写入kafka的第二topic，再通过flink基于CDR中数据库对应的查询脚本包含的数据表关联关系对第二topic和第一预设数据库中的数据进行关联，得到了患者的多维医疗数据。该方案通过将各业务系统中新增的医疗数据中数据表对应的数据单独写入kafka，不仅实现患者多维医疗数据获取，还保证了进行flink流上关联的实时性，进而保证了获取患者多维医疗数据的是实时性。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。
图1为本申请实施例提供的多维医疗数据实时获取方案执行所依赖的系统架构图；
图2为本申请实施例提供的一种多维医疗数据实时获取方法的流程示意图；
图3为本申请实施例的一个示例中实时处理过程的示意图；
图4为本申请实施例的一个示例中离线处理过程的示意图；
图5为本申请实施例提供的一种多维医疗数据实时获取装置的结构框图；
图6为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。
本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
针对上述问题，本申请实施例提供了一种多维医疗数据实时获取方法、装置、电子设备及存储介质。下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
首先对本申请涉及的几个名词进行介绍和解释：
kafka(卡夫卡)：是由LinkedIn公司开发并开源的消息中间件。kafka消息中间件主要由生产者producer、代理服务器broker和消费者consumer组成，生产者发布消息，代理服务器将消息从生产者转发到消费者，消费者接收并处理消息。生产者producer和代理服务器broker分别作为消息的客户端和服务端。在实际运用中，一般会将多个kafka代理服务器以集群的方式运行形成kafka。kafka以时间复杂度为O(1)的方式提供消息持久化能力，时间复杂度O(1)指的是无论输入数据的规模如何增大，都不会影响kafka的处理性能，即kafka的时间复杂度与输入的数据规模无关，即使对TB级以上数据也能保证常数时间的访问性能。kafka同时支持离线数据处理和实时数据处理。
flink(流式计算引擎)：是指Apache Flink，是由Apache软件基金会开发的开源流处理框架，其核心是用Java和Scala编写的分布式流数据流引擎。flink以数据并行和流水线方式执行任意流数据程序，flink的流水线运行时系统可以执行批处理和流处理程序。此外，flink的运行时本身也支持迭代算法的执行。
presto：是一种应用于大数据方面的分布式SQL(Structured Query Language，结构化查询语言)查询引擎，所有数据处理和传输都是基于内存和网络，计算过程一气呵成，不分阶段，没有中间temp阶段，避免了不必要的I/O和延迟开销，因此总体查询效率比Hive高出很多。presto在计算过程中，需要把所有参与计算的元数据拆分并加载到各个计算节点的内存中完成计算，例如：查询、排序、存放中间结果集等。presto支持多个作业并行执行，因此需要设定单个计算任务在每个计算节点服务器上可以使用的内存最大值。
如图1所示，为本申请实施例提供的多维医疗数据实时获取方案执行所依赖的系统架构图，该系统包括多个业务系统101、多维医疗数据获取单元102以及CDR 103，多维医疗数据获取单元102中通过执行本申请实施例提供的多维医疗数据实时获取方案得到患者的多维医疗数据。具体来说，多维医疗数据获取单元102首先获取患者在多个业务系统中新增的医疗数据，然后利用本申请实施例提供的多维医疗数据实时获取方案，基于从多个业务系统101中获取的新增医疗数据，得到患者的多维医疗数据，并将患者的多维医疗数据存储至CDR 103中。当医生需要全面了解患者病情时，即需要查看患者的多维医疗数据时，只需要访问CDR 103一次即可查看到相应的多维医疗数据。下面将对多维医疗数据的获取过程进行详细说明。
图2为本申请实施例提供的一种多维医疗数据实时获取方法的流程示意图，如图2所示，该方法可以包括：
步骤201，对医院各业务系统的binlog进行实时解析，得到对应的第一增量医疗数据，并将第一增量医疗数据写入kafka消息队列的第一topic。
其中，医院的业务系统可以包括检验系统，检查系统，影像系统，血库系统，护士站系统，电子病例(Electronic Medical Record，EMR)系统，临床信息系统(ClinicalInformation System，CIS)，体检系统等。这些业务系统在患者就诊产生医疗数据时，对这些医疗数据进行单独存储，并在存储时生成对应的binlog。这些医疗数据可以分别以事实表和维度表的形式进行存储，在后续获取患者的多维医疗数据过程中，由于患者的医疗数据分别存储于不同业务系统的事实表或维度表，需要将患者处于不同事实表或不同维度表中的数据进行关联，以获得对应的多维医疗数据。
具体地，在当前时刻，对医院里所有的业务系统的binlog进行解析，根据解析结果确定相对于上一时刻产生了哪些医疗数据，即确定第一新增医疗数据。将当前时刻对应的第一新增医疗数据写入kafka消息队列的第一topic，以供后续进行flink流上关联时消费。
需要说明的是，当前时刻指的是当前有第一新增医疗数据产生的时刻，上一时刻即上一个有第一新增医疗数据产生的时刻，可以理解的是，本申请实施例中只要有第一新增医疗数据产生，即开始进行上述第一多维医疗数据的获取，以保证一旦患者有第一新增医疗数据，即进行患者的第一多维医疗数据的获取。
步骤202，通过flink消费第一topic中的第一增量医疗数据，并将第一增量医疗数据存储至第一预设数据库中，将第一增量医疗数据中事实表对应的数据写入kafka消息队列的第二topic中。
其中，所述第一数据库可以为Hbase或Redis。
具体地，首先flink消费第一topic中的第一增量医疗数据，并将所有第一增量医疗数据存储至第一预设数据库中，同时将第一增量医疗数据中事实表对应的数据再次写入kafka消息队列的一个新的topic中，即写入第二topic中。后续进行数据关联的过程，即将第二topic中的事实表对应的数据与第一预设数据库中的数据进行关联。
需要说明的是，为了避免后续进行数据关联过程中，由于有些事实表的数据未能及时存储至第一预设数据库中，造成关联结果为空的情形，可以在将第一增量医疗数据存储至第一预设数据库中之前，将各业务系统的全量医疗数据存储至第一预设数据库。
由以上描述可知，在第一预设数据库中存储有当前时刻的全量数据，而在kafka的第二topic中写入了当前时刻新增的事实表对应的数据。
步骤203，获取临床数据中心CDR对应的至少一个查询脚本，基于每一查询脚本对应的数据表关联关系，通过flink对第一预设数据库和第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，并将第一多维医疗数据存储至CDR中与该查询脚本对应的数据表中。
其中，CDR中设置有多个数据表，每个数据表用于存储对应的多维医疗数据，且每个数据表对应一个查询脚本。具体来说，在CDR中设置有mpp(Massively ParallelProcessing，大规模并行处理)数据库Greenplum(简称GP)，上述多个数据表设置在GP中，各数据表存储对应的多维医疗数据，用户(如医生)可以通过查询GP中的数据表获取对应的多维医疗数据。
通过解析查询脚本可以得到对应的数据表关联关系，所谓数据表关联关系，其可以指示查询脚本对应的数据表中存储的多维医疗数据由哪些数据表中的数据关联得到。举例来说，GP中某一数据表对应的查询脚本“Insert into cdr_a select*from事实_A a；Left join事实_B b ona.bid＝b.id；Left join维度_C c on a.cid＝c.id”，其所指示的数据表关联关系即为：对应的多维医疗数据由事实表A、事实表B以及维度表C中对应的字段的数据进行关联的得到，其中事实表A为关联时的关联主表，事实表B和维度表C为关联时的关联副表。可以看出数据表关联关系中关联主表为事实表，因此，为了便于flink进行数据的实时流上关联，本申请实施例将第一新增医疗数据中的事实表对应的数据单独写入kafka的第二topic中。一旦第二topic中写入了新的事实表数据，即产生了新的关联主表数据，即可根据该新的关联主表数据找到对应的查询脚本，并完成对应的数据关联。通过这种方式可以保证数据关联的实时性，进而保证获取多维医疗数据的实时性。
具体地，获取CDR中的所有查询脚本，并获取每个查询脚本对应的数据表关联关系，根据该数据表关联关系，通过flink分别从第一预设数据库以及第二topic获取对应的数据进行关联，得到该数据表关联关系对应的关联结果，即得到了对应的查询脚本对应的第一多维医疗数据。对于每一查询脚本，在获取到对应的第一多维医疗数据后，将获取到的第一多维医疗数据存储至该查询脚本在GP中对应的数据表中。
可以理解的是，上述获取第一新增医疗数据是实时进行的，那么第一新增医疗数据中的事实表对应的数据将实时写入kafka的第二topic中。在不断产生第一新增医疗数据时，第一新增医疗数据中事实表对应的数据也将不断写入kafka的第二topic中，并不断被作为关联主表数据进行数据关联，即整个关联过程可以理解为数据流的处理过程，可称为flink流上关联。因此，可以保证用户(如医生)通过访问GP中的数据表实时获取患者的多维医疗数据。
本申请提供的方案，通过实时获取各业务系统中患者的新增医疗数据，并将新增医疗数据存储至第一预设数据库，同时将新增医疗数据中事实表对应的数据写入kafka的第二topic，再通过flink基于CDR中数据库对应的查询脚本包含的数据表关联关系对第二topic和第一预设数据库中的数据进行关联，得到了患者的多维医疗数据。该方案通过将各业务系统中新增的医疗数据中数据表对应的数据单独写入kafka，不仅实现患者多维医疗数据获取，还保证了进行flink流上关联的实时性，进而保证了获取患者多维医疗数据的是实时性。
在本申请的一种可选实施例中，基于每一查询脚本对应的数据表关联关系，通过flink对第一预设数据库和第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，包括：
基于每一查询脚本对应的数据表关联关系，获取该查询脚本对应的关联主表标识和至少一个关联副表标识；
通过flink获取二topic中带有关联主表标识的数据作为关联主表数据，通过flink获取第一预设数据库中带有关联副表标识的数据作为关联副表数据；
通过flink对关联主表数据和关联副表数据进行关联，得到该查询脚本对应的第一多维医疗数据。
其中，关联主表标识可以为从数据表关联关系中解析出的关联主表名称，例如事实表A，关联副表标识可以为从何数据表关联关系中解析出的关联副表名称，例如维度表C。
具体地，对每一查询脚本进行解析得到对应的数据表关联关系，然后进一步解析得到该数据表关联关系中的一个关联主表标识和至少一个关联副表标识。然后通过flink消费kafka的第二topic中的数据，即通过关联主表标识过滤kafka的第二topic中的数据，将带有关联主表标识的数据作为关联主表数据。同时，通过flink获取第一预设数据库中的数据，即通过关联副表标识过滤第一预设数据库中的数据，将带有关联副表标识的数据作为关联副表数据。最后，将关联主表数据和关联副表数据进行关联得到对应的第一多维医疗数据。对于多个关联副表数据，flink先获取一个关联副表数据与关联主表数据进行关联得到关联结果，然后flink再获取一个关联副表数据与上次关联结果进行关联，以此类推直至关联到所有关联副表数据，即得到了对应的第一多维医疗数据。
进一步地，通过flink对关联主表数据和关联副表数据进行关联，得到该查询脚本对应的第一多维医疗数据，包括：
通过flink将关联主表数据映射为对应的关联主表，并将关联副表数据映射为对应的关联副表；
将关联主表与关联副表进行关联，得到对应的临时数据表，临时数据表中的数据即为对应的第一多维医疗数据。
具体地，在flink进行关联主表数据和关联副表数据的流上关联时，首先需要将数据映射为对应的数据表后再进行关联。具体来说，通过flink将关联主表数据映射为对应的关联主表，并将关联副表数据映射为对应的关联副表。然后，通过关联主表中包含的外键的值，将外键的值对应的关联副表中的数据内容添加至主表的对应位置，进而得到临时数据表。该临时数据表中存储的数据即为对应的第一多维医疗数据。
举例来说，对于查询脚本“Insert into cdr_a select*from事实_A a；Left join事实_B b on a.bid＝b.id；Left join维度_C c on a.cid＝c.id”，flink从kafka(即kafka消息队列)的第二topic中获取到事实表A对应的新增数据“id:1，bid:2，cid:3”(即关联主表数据，对应的外键值分别为bid＝2和cid＝3)。
在关联过程中，通过“bid:2”这个外键值去查询第一预设数据库中事实表B中id＝2的数据内容(即关联副表数据)，如果有对应的数据内容，则将对应的数据内容添加至事实表A中的对应位置，如果没有，则返回“null”，本次关联结果为“id:1，bid:2，b.name:外科，cid:3”。然后，通过“cid:3”这个外键值去查询第一预设数据库中维度表C中id＝3的数据内容(即关联副表数据)，维度表C中id＝3的数据内容，如果有对应的数据内容，则将对应的数据内容添加至上次关联结果中的对应位置，如果没有，则返回“null”，本次关联结果为“id:1，bid:2，b.name:外科，cid:3，c.name:null”。至此即得到了该查询脚本对应的第一多维医疗数据“id:1，bid:2，b.name:外科，cid:3，c.name:null”，将该第一多维医疗数据存储至GP中与该查询脚本对应的数据表中。可以理解的是，每次关联过程中都是将对应的数据映射为对应的关联主表和关联副表后进行的，得到的第一多维医疗数据也是以临时表的形式进行存储，最终再将临时表中的第一多维医疗数据存储至GP中。
下面结合图3对前述处理过程进行进一步说明，如图3所示，该处理过从获取第一多维医疗数据的过程可以包括：
(1)当有第一新增医疗数据时，通过解析各业务系统的binlog，获取第一新增医疗数据，并写入kafka的第一topic；
(2)通过flink消费第一topic中的第一新增医疗数据，将第一医疗数据存储至Hbase中；
(3)将第一新增医疗数据中事实表对应的数据再次写入kafka的第二topic中；
(4)基于各查询脚本，通过flink进行流上数据关联，具体来说，若查询脚本对应的数据表关联关系关联主表为事实表A、关联副表为事实表B和维度表C，则通过flink将从第二topic中获取的事实表A的数据与从Hbase中获取的事实表B的数据进行关联，得到的关联结果记为事实表AB，再将事实表AB与从Hbase中获取的维度表C的数据进行关联，得到最终的关联结果，即存储有对应的第一多维医疗数据的临时表；
(5)将第一多维医疗数据存储至GP对应的数据表中。
由以上过程可知，kafka的第二topic中每写入一条事实表对应的数据则进行一次上述处理，当有源源不断的事实表对应的数据写入kafka的第二topic则源源不断的进行上述处理，即所谓flink实时流上处理。
前述处理过程，一旦有第一新增医疗数据产生，即会开始进行第一多维医疗数据的获取，该处理过程可以称为实时处理过程。但是，在实时处理过程中，在进行实时flink流上关联时，可能存在部分待关联数据缺失的情形(例如，第一预设数据库中某些事实表对应的数据未写入)，造成关联结果不准确，进而影响最终得到的第一多维医疗数据的准确性。为了提高GP中存储的多维医疗数据的准确性，可以进一步增加一个离线处理过程，通过离线处理过程得到的第二多维医疗数据对不准确的第一多维医疗数据进行修复。下面将对离线处理过程进行详细说明。
在本申请的一种可选实施例中，该方法还可以包括：
每间隔预设时间段，对各业务系统的binlog进行解析，得到对应的第二增量医疗数据，并将第二增量医疗数据写入kafka消息队列的第三topic；
通过flink消费第三topic中的第二增量医疗数据，并将第二增量医疗数据存储至数据湖层；
基于每一查询脚本，通过presto从数据湖层，查询得到该查询脚本对应的第二多维医疗数据；
若第二多维医疗数据与对应的第一多维医疗数据之间满足预设条件，则利用第二多维医疗数据替换CDR中对应的第一多维医疗数据。
其中，预设时间段的长度可以根据实际需求进行设定，例如，由于凌晨医院各业务系统处于计算低峰期，可以在每天的凌晨一点进行该离线处理过程，那么该预设时间段即为24小时。可以理解的是，在除凌晨一点以外的其他时间，都在进行实时处理过程。
具体地，每间隔预设时间段，开始进行离线处理过程。首先，与实时处理过程相同，通过解析binlog日志获取该预设时间段的新增医疗数据，即得到第二新增医疗数据。并将第二新增数据医疗数据写入kafka的第三topic中。很显然，由于间隔了预设时间段，第二新增医疗数据相较于第一新增医疗数据更完整。然后，通过flink消费kafka的第三topic中的第二新增医疗数据，并将第二新增医疗数据存储至数据湖层。然后，将每一查询脚本作为查询语句，通过presto从所述数据湖层中查询得到该查询脚本对应的数据，查询结果即为对应的第二多维医疗数据。由前文描述可知，第二新增医疗数据比第一新增医疗数据更完整，进而第二多维医疗数据比第一多维医疗数据的准确性更高。因此，在得到第二多维医疗数据后，可以将实时处理过程得到的第一多维医疗数据与离线处理得到的第二多维医疗数据进行比较，当两者满足预设条件时，利用第二多维医疗数据替换已经存储进GP中的第一多维医疗数据。在替换之后，可以提高GP中多维医疗数据的准确性。
需要说明的是，可以进行替换的是同一查询脚本对应的在离线处理过程产生的第二多维医疗数据和在实时处理过程产生的第一多维医疗数据。两者对比满足预设条件可以是数据中的相关字段满足指定条件，该预设条件可根据实际需求进行设置。例如，可以是第一多维医疗数据的指定字段对应的数据为空(即为“null”)，而对应的第二多维医疗数据的指定字段对应的数据不为空。或者，可以是第二多维医疗数据的生成时间晚于对应的第一多维医疗数据。
在本申请的一种可选实施例中，数据湖层设置有第二预设数据库和第三预设数据库，且第二预设数据库的读写速度高于第三预设数据库的读写速度，将第二增量医疗数据存储至数据湖层，包括：
将第二增量医疗数据中事实表对应的数据存储至第二预设数据库中、将第二增量医疗数据中维度表对应的数据存储至第三预设数据库中；
相应地，基于每一查询脚本，通过presto从数据湖层，查询得到该查询脚本对应的第二多维医疗数据，包括：
基于每一查询脚本，通过presto从第二预设数据库和/或第三预设数据库中，查询得到该查询脚本对应的第二多维医疗数据。
其中，第二预设数据库可以为hudi数据库，用于存储大表，例如本申请实施例中的事实表，第三预设数据库可以为Mysql数据库，用于存储小表，例如本申请实施例中的维度表。
具体地，通过flink消费kafka的第三topic中的第二新增医疗数据时，将第二新增数据中的事实表对应的数据存储至第二预设数据库中，而将第二新增数据中的维度表对应的数据存储至第三预设数据库中。然后，基于每一查询脚本，通过presto从第二预设数据库和/或第三预设数据库中，查询得到该查询脚本对应的第二多维医疗数据。
可以理解的是，通过将第二新增医疗数据中事实表和维度表分别存储至不同读写速度的数据库，在节约内存的基础上可以提高读写速度，进而兼顾了离线处理过程的小内存和高效率。
在本申请的一种可选实施例中，第二多维医疗数据与对应的第一多维医疗数据之间满足预设条件，则利用第二多维医疗数据替换CDR中对应的第一多维医疗数据，包括：
若第一多维医疗数据的生成时间早于第二多维医疗数据的生成时间，则利用第二多维医疗数据替换第一多维医疗数据。
具体地，为了避免实时处理过程中数据关联过程中部分数据缺失的问题，若第一多维医疗数据的生成时间早于第二多维医疗数据的生成时间，则认为第二多维医疗数据比第一多维医疗数据更准确，因此利用第二多维医疗数据替换对应的第一多维医疗数据。
下面结合图4对前述离线处理过程进行进一步说明，如图4所示，该离线处理过程可以包括：
(1)在经过预设时间段后，对各业务系统的binlog进行解析获取第二新增医疗数据，并写入kafka的第三topic；
(2)通过flink消费第三topic中的第二新增医疗数据，并将第二新增医疗数据中事实表对应的数据写入hudi中，将第二医疗数据中维度表对应的数据写入Mysql中；
(3)基于各查询脚本，通过presto从hudi和Mysql中查询得到各查询脚本对应的第二多维医疗数据；
(4)将第二多维医疗数据存储至GP对应的数据表中。
图5为本申请实施例提供的一种多维医疗数据实时获取装置的结构框图，如图5所示，该装置可以包括：
日志解析模块501用于对医院各业务系统的二进制日志binlog进行实时解析，得到对应的第一增量医疗数据，并将第一增量医疗数据写入卡夫卡kafka消息队列的第一主题topic；
数据存储模块502用于通过flink消费第一topic中的第一增量医疗数据，并将第一增量医疗数据存储至第一预设数据库中，将第一增量医疗数据中事实表对应的数据写入kafka消息队列的第二topic中；
数据关联模块503用于获取临床数据中心CDR对应的至少一个查询脚本，基于每一查询脚本对应的数据表关联关系，通过flink对第一预设数据库和第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，并将第一多维医疗数据存储至CDR中与该查询脚本对应的数据表中。
本申请提供的方案，通过实时获取各业务系统中患者的新增医疗数据，并将新增医疗数据存储至第一预设数据库，同时将新增医疗数据中事实表对应的数据写入kafka的第二topic，再通过flink基于CDR中数据库对应的查询脚本包含的数据表关联关系对第二topic和第一预设数据库中的数据进行关联，得到了患者的多维医疗数据。该方案通过将各业务系统中新增的医疗数据中数据表对应的数据单独写入kafka，不仅实现患者多维医疗数据获取，还保证了进行flink流上关联的实时性，进而保证了获取患者多维医疗数据的是实时性。
在本申请的一种可选实施例中，该装置还包括离线修复模块，用于：
每间隔预设时间段，对各业务系统的binlog进行解析，得到对应的第二增量医疗数据，并将第二增量医疗数据写入kafka消息队列的第三topic；
通过flink消费第三topic中的第二增量医疗数据，并将第二增量医疗数据存储至数据湖层；
基于每一查询脚本，通过presto从数据湖层，查询得到该查询脚本对应的第二多维医疗数据；
若第二多维医疗数据与对应的第一多维医疗数据之间满足预设条件，则利用第二多维医疗数据替换CDR中对应的第一多维医疗数据。
在本申请的一种可选实施例中，数据湖层设置有第二预设数据库和第三预设数据库，且第二预设数据库的读写速度高于第三预设数据库的读写速度，离线修复模块具体用于：
将第二增量医疗数据中事实表对应的数据存储至第二预设数据库中、将第二增量医疗数据中维度表对应的数据存储至第三预设数据库中；
相应地，离线修复模块具体用于还用于：
基于每一查询脚本，通过presto从第二预设数据库和/或第三预设数据库中，查询得到该查询脚本对应的第二多维医疗数据。
在本申请的一种可选实施例中，离线修复模块进一步用于：
若第一多维医疗数据的生成时间早于第二多维医疗数据的生成时间，则利用第二多维医疗数据替换第一多维医疗数据。
在本申请的一种可选实施例中，该装置还包括全量医疗数据存储模块，用于：
在将第一增量医疗数据存储至第一预设数据库中之前，将各业务系统的全量医疗数据存储至第一预设数据库。
在本申请的一种可选实施例中，数据关联模块具体用于：
基于每一查询脚本对应的数据表关联关系，获取该查询脚本对应的关联主表标识和至少一个关联副表标识；
通过flink获取二topic中带有关联主表标识的数据作为关联主表数据，通过flink获取第一预设数据库中带有关联副表标识的数据作为关联副表数据；
通过flink对关联主表数据和关联副表数据进行关联，得到该查询脚本对应的第一多维医疗数据。
在本申请的一种可选实施例中，数据关联模块进一步用于：
通过flink将关联主表数据映射为对应的关联主表，并将关联副表数据映射为对应的关联副表；
将关联主表与关联副表进行关联，得到对应的临时数据表，临时数据表中的数据即为对应的第一多维医疗数据。
下面参考图6，其示出了适于用来实现本申请实施例的电子设备(例如执行图2所示方法的终端设备或服务器)600的结构示意图。本申请实施例中的电子设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)、可穿戴设备等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图6示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
电子设备包括：存储器以及处理器，存储器用于存储执行上述各个方法实施例所述方法的程序；处理器被配置为执行存储器中存储的程序。其中，这里的处理器可以称为下文所述的处理装置601，存储器可以包括下文中的只读存储器(ROM)602、随机访问存储器(RAM)603以及存储装置608中的至少一项，具体如下所示：
如图6所示，电子设备600可以包括处理装置(例如中央处理器、图形处理器等)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储装置608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM603中，还存储有电子设备600操作所需的各种程序和数据。处理装置601、ROM 602以及RAM603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。
通常，以下装置可以连接至I/O接口605：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置606；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置607；包括例如磁带、硬盘等的存储装置608；以及通信装置609。通信装置609可以允许电子设备600与其他设备进行无线或有线通信以交换数据。虽然图6示出了具有各种装置的电子设备，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。
特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置609从网络上被下载和安装，或者从存储装置608被安装，或者从ROM 602被安装。在该计算机程序被处理装置601执行时，执行本申请实施例的方法中限定的上述功能。
需要说明的是，本申请上述的计算机可读存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。
在一些实施方式中，客户端、服务器可以利用诸如HTTP(HyperText TransferProtocol，超文本传输协议)之类的任何当前已知或未来研发的网络协议进行通信，并且可以与任意形式或介质的数字数据通信(例如，通信网络)互连。通信网络的示例包括局域网(“LAN”)，广域网(“WAN”)，网际网(例如，互联网)以及端对端网络(例如，ad hoc端对端网络)，以及任何当前已知或未来研发的网络。
上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。
上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：
对医院各业务系统的二进制日志binlog进行实时解析，得到对应的第一增量医疗数据，并将第一增量医疗数据写入卡夫卡kafka消息队列的第一主题topic；通过flink消费第一topic中的第一增量医疗数据，并将第一增量医疗数据存储至第一预设数据库中，将第一增量医疗数据中事实表对应的数据写入kafka消息队列的第二topic中；获取临床数据中心CDR对应的至少一个查询脚本，基于每一查询脚本对应的数据表关联关系，通过flink对第一预设数据库和第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，并将第一多维医疗数据存储至CDR中与该查询脚本对应的数据表中。
可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的模块或单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块或单元的名称在某种情况下并不构成对该单元本身的限定，例如，日志解析模块还可以被描述为“解析日志的模块”。
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。
在本申请的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的计算机可读介质被电子设备执行时实现的具体方法，可以参考前述方法实施例中的对应过程，在此不再赘述。
本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行时实现如下情况：
对医院各业务系统的二进制日志binlog进行实时解析，得到对应的第一增量医疗数据，并将第一增量医疗数据写入卡夫卡kafka消息队列的第一主题topic；通过flink消费第一topic中的第一增量医疗数据，并将第一增量医疗数据存储至第一预设数据库中，将第一增量医疗数据中事实表对应的数据写入kafka消息队列的第二topic中；获取临床数据中心CDR对应的至少一个查询脚本，基于每一查询脚本对应的数据表关联关系，通过flink对第一预设数据库和第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，并将第一多维医疗数据存储至CDR中与该查询脚本对应的数据表中。
应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (9)

1.一种多维医疗数据实时获取方法，其特征在于，包括：
对医院各业务系统的二进制日志binlog进行实时解析，得到对应的第一增量医疗数据，并将所述第一增量医疗数据写入卡夫卡kafka消息队列的第一主题topic；
通过流式计算引擎flink消费所述第一topic中的第一增量医疗数据，并将所述第一增量医疗数据存储至第一预设数据库中，将所述第一增量医疗数据中事实表对应的数据写入所述kafka消息队列的第二topic中；
获取临床数据中心CDR对应的至少一个查询脚本，基于每一查询脚本对应的数据表关联关系，通过所述flink对所述第一预设数据库和所述第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，并将所述第一多维医疗数据存储至所述CDR中与该查询脚本对应的数据表中；
每间隔预设时间段，对所述各业务系统的binlog进行解析，得到对应的第二增量医疗数据，并将所述第二增量医疗数据写入所述kafka消息队列的第三topic；
通过所述flink消费所述第三topic中的第二增量医疗数据，并将所述第二增量医疗数据存储至数据湖层；
基于每一查询脚本，通过presto从所述数据湖层，查询得到该查询脚本对应的第二多维医疗数据；
若所述第二多维医疗数据与对应的第一多维医疗数据之间满足预设条件，则利用所述第二多维医疗数据替换所述CDR中对应的第一多维医疗数据。
2.根据权利要求1所述的方法，其特征在于，所述数据湖层设置有第二预设数据库和第三预设数据库，且所述第二预设数据库的读写速度高于所述第三预设数据库的读写速度，所述将所述第二增量医疗数据存储至数据湖层，包括：
将所述第二增量医疗数据中事实表对应的数据存储至所述第二预设数据库中、将所述第二增量医疗数据中维度表对应的数据存储至所述第三预设数据库中；
相应地，所述基于每一查询脚本，通过查询引擎presto从所述数据湖层，查询得到该查询脚本对应的第二多维医疗数据，包括：
基于每一查询脚本，通过presto从所述第二预设数据库和/或第三预设数据库中，查询得到该查询脚本对应的第二多维医疗数据。
3.根据权利要求2所述的方法，其特征在于，所述第二多维医疗数据与对应的第一多维医疗数据之间满足预设条件，则利用所述第二多维医疗数据替换所述CDR中对应的第一多维医疗数据，包括：
若第一多维医疗数据的生成时间早于所述第二多维医疗数据的生成时间，则利用所述第二多维医疗数据替换所述第一多维医疗数据。
4.根据权利要求1所述的方法，其特征在于，所述方法还包括：
在将所述第一增量医疗数据存储至第一预设数据库中之前，将各业务系统的全量医疗数据存储至所述第一预设数据库。
5.根据权利要求1或4所述的方法，其特征在于，所述基于每一查询脚本对应的数据表关联关系，通过所述flink对所述第一预设数据库和所述第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，包括：
基于每一查询脚本对应的数据表关联关系，获取该查询脚本对应的关联主表标识和至少一个关联副表标识；
通过所述flink获取所述第二topic中带有所述关联主表标识的数据作为关联主表数据，通过flink获取所述第一预设数据库中带有所述关联副表标识的数据作为关联副表数据；
通过所述flink对所述关联主表数据和所述关联副表数据进行关联，得到该查询脚本对应的第一多维医疗数据。
6.根据权利要求5所述的方法，其特征在于，所述通过所述flink对所述关联主表数据和所述关联副表数据进行关联，得到该查询脚本对应的第一多维医疗数据，包括：
通过flink将所述关联主表数据映射为对应的关联主表，并将所述关联副表数据映射为对应的关联副表；
将所述关联主表与所述关联副表进行关联，得到对应的临时数据表，所述临时数据表中的数据即为对应的第一多维医疗数据。
7.一种多维医疗数据实时获取装置，其特征在于，包括：
日志解析模块，用于对医院各业务系统的二进制日志binlog进行实时解析，得到对应的第一增量医疗数据，并将所述第一增量医疗数据写入卡夫卡kafka消息队列的第一主题topic；
数据存储模块，用于通过流式计算引擎flink消费所述第一topic中的第一增量医疗数据，并将所述第一增量医疗数据存储至第一预设数据库中，将所述第一增量医疗数据中事实表对应的数据写入所述kafka消息队列的第二topic中；
数据关联模块，用于获取临床数据中心CDR对应的至少一个查询脚本，基于每一查询脚本对应的数据表关联关系，通过所述flink对所述第一预设数据库和所述第二topic两者中的数据进行关联，得到该查询脚本对应的第一多维医疗数据，并将所述第一多维医疗数据存储至所述CDR中与该查询脚本对应的数据表中；
离线修复模块，用于每间隔预设时间段，对所述各业务系统的binlog进行解析，得到对应的第二增量医疗数据，并将所述第二增量医疗数据写入所述kafka消息队列的第三topic；通过所述flink消费所述第三topic中的第二增量医疗数据，并将所述第二增量医疗数据存储至数据湖层；基于每一查询脚本，通过presto从所述数据湖层，查询得到该查询脚本对应的第二多维医疗数据；若所述第二多维医疗数据与对应的第一多维医疗数据之间满足预设条件，则利用所述第二多维医疗数据替换所述CDR中对应的第一多维医疗数据。
8.一种电子设备，其特征在于，包括存储器和处理器；
所述存储器中存储有计算机程序；
所述处理器，用于执行所述计算机程序以实现权利要求1至6中任一项所述的方法。
9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法。
CN202111413929.3A 2021-11-25 2021-11-25 多维医疗数据实时获取方法、装置、电子设备及存储介质 Active CN114116842B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111413929.3A CN114116842B (zh) 2021-11-25 2021-11-25 多维医疗数据实时获取方法、装置、电子设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111413929.3A CN114116842B (zh) 2021-11-25 2021-11-25 多维医疗数据实时获取方法、装置、电子设备及存储介质

Publications (2)

Publication Number Publication Date
CN114116842A CN114116842A (zh) 2022-03-01
CN114116842B true CN114116842B (zh) 2023-05-19

Family

ID=80373151

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111413929.3A Active CN114116842B (zh) 2021-11-25 2021-11-25 多维医疗数据实时获取方法、装置、电子设备及存储介质

Country Status (1)

Country Link
CN (1) CN114116842B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114116842B (zh) * 2021-11-25 2023-05-19 上海柯林布瑞信息技术有限公司 多维医疗数据实时获取方法、装置、电子设备及存储介质
CN117032950A (zh) * 2023-07-10 2023-11-10 企迈科技有限公司 基于日志的实时数据透传方法及系统

Citations (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104166666A (zh) * 2014-05-15 2014-11-26 杭州斯凯网络科技有限公司 PostgreSQL高并发流式大数据多维度准实时统计的方法
CN106326470A (zh) * 2016-08-31 2017-01-11 无锡雅座在线科技发展有限公司 流式大数据的处理方法和装置
CN107038162A (zh) * 2016-02-03 2017-08-11 滴滴（中国）科技有限公司 基于数据库日志的实时数据查询方法和系统
CN107169070A (zh) * 2017-05-08 2017-09-15 山大地纬软件股份有限公司 一种基于大数据的社保指标仓库的构建系统及其方法
CN107330238A (zh) * 2016-08-12 2017-11-07 中国科学院上海技术物理研究所 医疗信息采集、处理、存储与显示方法与装置
CN107689998A (zh) * 2017-09-14 2018-02-13 平安科技（深圳）有限公司 一种增量数据同步方法及终端设备
CN109800234A (zh) * 2019-01-25 2019-05-24 苏州科达科技股份有限公司 业务平台数据库系统、升级方法、设备及存储介质
CN110019357A (zh) * 2017-09-29 2019-07-16 北京国双科技有限公司 数据库查询脚本生成方法及装置
CN110083647A (zh) * 2019-03-31 2019-08-02 广州建皓信息技术有限公司 一种大数据管理平台
CN110245158A (zh) * 2019-06-10 2019-09-17 上海理想信息产业（集团）有限公司 一种基于Flink流计算技术的多源异构数据实时处理系统及方法
CN110543478A (zh) * 2019-07-17 2019-12-06 阿里巴巴集团控股有限公司 公共层宽表建设方法、装置及服务器
CN111291047A (zh) * 2020-01-16 2020-06-16 北京明略软件系统有限公司 一种时空数据存储方法、装置、存储介质及电子设备
CN111367984A (zh) * 2020-03-11 2020-07-03 中国工商银行股份有限公司 高时效的数据加载入数据湖的方法及系统
CN111435344A (zh) * 2019-01-15 2020-07-21 中国石油集团川庆钻探工程有限公司长庆钻井总公司 一种基于大数据的钻井提速影响因素分析模型
CN111831713A (zh) * 2019-04-18 2020-10-27 阿里巴巴集团控股有限公司 一种数据处理方法、装置及设备
CN112256523A (zh) * 2020-09-23 2021-01-22 贝壳技术有限公司 业务数据处理方法及装置
CN112286905A (zh) * 2020-10-15 2021-01-29 北京沃东天骏信息技术有限公司 数据迁移方法及装置、存储介质、电子设备
CN112650777A (zh) * 2020-12-23 2021-04-13 深圳前海微众银行股份有限公司 数据仓库的制作方法、装置、终端设备及计算机存储介质
CN112653703A (zh) * 2020-12-25 2021-04-13 杭州中科先进技术研究院有限公司 一种基于边缘计算的多医疗协议转换解析方法和系统
CN112711634A (zh) * 2020-12-29 2021-04-27 科技谷（厦门）信息技术有限公司 一种基于数据中台的数据开发方法
CN112989135A (zh) * 2021-04-15 2021-06-18 杭州网易再顾科技有限公司 实时风险团伙的识别方法、介质、装置和计算设备
CN113130039A (zh) * 2021-04-16 2021-07-16 广州中康数字科技有限公司 一种基于微信公众号的在线开方系统及方法
CN113282555A (zh) * 2021-06-18 2021-08-20 北京奇艺世纪科技有限公司 一种数据处理方法、装置、设备及存储介质
CN113347249A (zh) * 2021-05-31 2021-09-03 中国工商银行股份有限公司 一种作业加载方法、装置及设备
CN113342502A (zh) * 2021-06-30 2021-09-03 招商局金融科技有限公司 数据湖的性能诊断方法、装置、计算机设备及存储介质
CN113407617A (zh) * 2021-06-25 2021-09-17 交控科技股份有限公司 基于大数据技术的实时与离线业务统一处理方法和装置
CN113407635A (zh) * 2021-07-09 2021-09-17 浙江明度智控科技有限公司 一种用于智能制造的多终端数据同步方法和系统
CN113468199A (zh) * 2021-07-29 2021-10-01 上海哔哩哔哩科技有限公司 索引更新方法及系统
CN113779048A (zh) * 2020-06-18 2021-12-10 北京沃东天骏信息技术有限公司 一种数据处理方法和装置
CN114116842A (zh) * 2021-11-25 2022-03-01 上海柯林布瑞信息技术有限公司 多维医疗数据实时获取方法、装置、电子设备及存储介质

Patent Citations (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104166666A (zh) * 2014-05-15 2014-11-26 杭州斯凯网络科技有限公司 PostgreSQL高并发流式大数据多维度准实时统计的方法
CN107038162A (zh) * 2016-02-03 2017-08-11 滴滴（中国）科技有限公司 基于数据库日志的实时数据查询方法和系统
CN107330238A (zh) * 2016-08-12 2017-11-07 中国科学院上海技术物理研究所 医疗信息采集、处理、存储与显示方法与装置
CN106326470A (zh) * 2016-08-31 2017-01-11 无锡雅座在线科技发展有限公司 流式大数据的处理方法和装置
CN107169070A (zh) * 2017-05-08 2017-09-15 山大地纬软件股份有限公司 一种基于大数据的社保指标仓库的构建系统及其方法
CN107689998A (zh) * 2017-09-14 2018-02-13 平安科技（深圳）有限公司 一种增量数据同步方法及终端设备
CN110019357A (zh) * 2017-09-29 2019-07-16 北京国双科技有限公司 数据库查询脚本生成方法及装置
CN111435344A (zh) * 2019-01-15 2020-07-21 中国石油集团川庆钻探工程有限公司长庆钻井总公司 一种基于大数据的钻井提速影响因素分析模型
CN109800234A (zh) * 2019-01-25 2019-05-24 苏州科达科技股份有限公司 业务平台数据库系统、升级方法、设备及存储介质
CN110083647A (zh) * 2019-03-31 2019-08-02 广州建皓信息技术有限公司 一种大数据管理平台
CN111831713A (zh) * 2019-04-18 2020-10-27 阿里巴巴集团控股有限公司 一种数据处理方法、装置及设备
CN110245158A (zh) * 2019-06-10 2019-09-17 上海理想信息产业（集团）有限公司 一种基于Flink流计算技术的多源异构数据实时处理系统及方法
CN110543478A (zh) * 2019-07-17 2019-12-06 阿里巴巴集团控股有限公司 公共层宽表建设方法、装置及服务器
CN111291047A (zh) * 2020-01-16 2020-06-16 北京明略软件系统有限公司 一种时空数据存储方法、装置、存储介质及电子设备
CN111367984A (zh) * 2020-03-11 2020-07-03 中国工商银行股份有限公司 高时效的数据加载入数据湖的方法及系统
CN113779048A (zh) * 2020-06-18 2021-12-10 北京沃东天骏信息技术有限公司 一种数据处理方法和装置
CN112256523A (zh) * 2020-09-23 2021-01-22 贝壳技术有限公司 业务数据处理方法及装置
CN112286905A (zh) * 2020-10-15 2021-01-29 北京沃东天骏信息技术有限公司 数据迁移方法及装置、存储介质、电子设备
CN112650777A (zh) * 2020-12-23 2021-04-13 深圳前海微众银行股份有限公司 数据仓库的制作方法、装置、终端设备及计算机存储介质
CN112653703A (zh) * 2020-12-25 2021-04-13 杭州中科先进技术研究院有限公司 一种基于边缘计算的多医疗协议转换解析方法和系统
CN112711634A (zh) * 2020-12-29 2021-04-27 科技谷（厦门）信息技术有限公司 一种基于数据中台的数据开发方法
CN112989135A (zh) * 2021-04-15 2021-06-18 杭州网易再顾科技有限公司 实时风险团伙的识别方法、介质、装置和计算设备
CN113130039A (zh) * 2021-04-16 2021-07-16 广州中康数字科技有限公司 一种基于微信公众号的在线开方系统及方法
CN113347249A (zh) * 2021-05-31 2021-09-03 中国工商银行股份有限公司 一种作业加载方法、装置及设备
CN113282555A (zh) * 2021-06-18 2021-08-20 北京奇艺世纪科技有限公司 一种数据处理方法、装置、设备及存储介质
CN113407617A (zh) * 2021-06-25 2021-09-17 交控科技股份有限公司 基于大数据技术的实时与离线业务统一处理方法和装置
CN113342502A (zh) * 2021-06-30 2021-09-03 招商局金融科技有限公司 数据湖的性能诊断方法、装置、计算机设备及存储介质
CN113407635A (zh) * 2021-07-09 2021-09-17 浙江明度智控科技有限公司 一种用于智能制造的多终端数据同步方法和系统
CN113468199A (zh) * 2021-07-29 2021-10-01 上海哔哩哔哩科技有限公司 索引更新方法及系统
CN114116842A (zh) * 2021-11-25 2022-03-01 上海柯林布瑞信息技术有限公司 多维医疗数据实时获取方法、装置、电子设备及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
基于数据中台的企业赋能体系构建研究;徐文杰;《中国新技术新产品》;第440卷(第10期);43-45 *

Also Published As

Publication number Publication date
CN114116842A (zh) 2022-03-01

Similar Documents

Publication Publication Date Title
CN109086409B (zh) 微服务数据处理方法、装置、电子设备及计算机可读介质
CN114116842B (zh) 多维医疗数据实时获取方法、装置、电子设备及存储介质
CN112069773A (zh) 数据处理系统、方法、装置、电子设备和计算机可读介质
CN114049927A (zh) 疾病数据处理方法、装置、电子设备及可读介质
CN111950857A (zh) 基于业务指标的指标体系管理方法、装置以及电子设备
CN111857720B (zh) 用户界面状态信息的生成方法、装置、电子设备及介质
CN108363741B (zh) 大数据统一接口方法、装置、设备及存储介质
CN111680799B (zh) 用于处理模型参数的方法和装置
CN113190517B (zh) 数据集成方法、装置、电子设备和计算机可读介质
CN113326305A (zh) 一种处理数据的方法和装置
CN116433388B (zh) 数据存储资源划分方法、装置、电子设备和计算机介质
CN114328700B (zh) 医疗数据etl任务中的数据核查方法及装置
CN114036107B (zh) 基于hudi快照的医疗数据查询方法及装置
CN111241137A (zh) 数据处理方法、装置、电子设备及存储介质
CN112100211B (zh) 数据存储方法、装置、电子设备和计算机可读介质
CN111143355B (zh) 数据处理方法及装置
CN114328486A (zh) 基于模型的数据质量核查方法及装置
CN114040014B (zh) 内容推送方法、装置、电子设备及计算机可读存储介质
CN116050358B (zh) 应用于动态数据的数据处理方法、装置和电子设备
CN114153620B (zh) Hudi运行环境资源优化分配方法及装置
CN111581305B (zh) 特征处理方法、装置、电子设备和介质
CN111857879B (zh) 数据处理方法、装置、电子设备和计算机可读介质
CN114566244B (zh) 电子病历质量评估方法、装置及计算机可读存储介质
CN116431523B (zh) 一种测试数据管理方法、装置、设备及存储介质
CN111984645B (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
GR01 Patent grant
GR01 Patent grant