CN113505172B - 数据处理方法、装置、电子设备及可读存储介质 - Google Patents
数据处理方法、装置、电子设备及可读存储介质 Download PDFInfo
- Publication number
- CN113505172B CN113505172B CN202110754395.4A CN202110754395A CN113505172B CN 113505172 B CN113505172 B CN 113505172B CN 202110754395 A CN202110754395 A CN 202110754395A CN 113505172 B CN113505172 B CN 113505172B
- Authority
- CN
- China
- Prior art keywords
- target
- data
- index
- partition
- time
- 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
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 25
- 238000005192 partition Methods 0.000 claims abstract description 343
- 238000004364 calculation method Methods 0.000 claims abstract description 224
- 238000000034 method Methods 0.000 claims abstract description 45
- 230000014509 gene expression Effects 0.000 claims description 109
- 238000012545 processing Methods 0.000 claims description 34
- 238000012216 screening Methods 0.000 claims description 14
- 230000002123 temporal effect Effects 0.000 claims description 6
- 238000013075 data extraction Methods 0.000 claims description 4
- 230000004044 response Effects 0.000 claims description 4
- 239000012634 fragment Substances 0.000 claims description 3
- 238000012163 sequencing technique Methods 0.000 claims 1
- 230000008569 process Effects 0.000 description 18
- 230000002776 aggregation Effects 0.000 description 5
- 238000004220 aggregation Methods 0.000 description 5
- 238000010276 construction Methods 0.000 description 5
- 238000010586 diagram Methods 0.000 description 5
- 239000000284 extract Substances 0.000 description 5
- 230000003416 augmentation Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 4
- 238000000605 extraction Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 2
- 230000011218 segmentation Effects 0.000 description 2
- 230000002194 synthesizing effect Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 239000003814 drug Substances 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
- G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
-
- 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/2228—Indexing structures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
- G06Q10/06393—Score-carding, benchmarking or key performance indicator [KPI] analysis
-
- 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
- G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
- G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Entrepreneurship & Innovation (AREA)
- General Engineering & Computer Science (AREA)
- Medical Informatics (AREA)
- Strategic Management (AREA)
- Public Health (AREA)
- Economics (AREA)
- Educational Administration (AREA)
- Development Economics (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Marketing (AREA)
- Biomedical Technology (AREA)
- Epidemiology (AREA)
- Software Systems (AREA)
- Game Theory and Decision Science (AREA)
- Pathology (AREA)
- Primary Health Care (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- General Business, Economics & Management (AREA)
- Computing Systems (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
本发明公开了一种数据处理方法和装置。该方法包括：接收指标计算请求，基于该请求中的时间周期确定目标时间分区，在该目标时间分区的索引对应的存储空间中获取该目标时间分区的医疗结算数据，对每个目标分区的医疗结算数据进行指标计算，将计算结果累加生成该时间周期内的指标结果。本发明可以提升对指标的计算速度，降低延迟，还可以降低对机器内存的要求和对机器数量的要求。
Description
技术领域
本发明属于计算机领域，进一步属于医疗技术领域，具体涉及一种数据处理方法、装置、电子设备及可读存储介质。
背景技术
在医疗领域，国家局需要对一些医疗指标进行监管，医疗指标的计算需要依托于患者在就医过程中所产生的医疗数据、结算主单数据和结算明细数据等。
以一线城市上海为例，一年定点医疗机构的结算主单数据在5亿左右，结算明细数据基本是结算主单数据的10倍多，基本在50亿-80亿，因此，在计算指标时所需要处理的数据量是庞大的；而各地市政府、医院信息化建设程度不一样，对于这块信息化建设预算较少；而国家局给出的监管指标不仅多，而且计算逻辑复杂，需要经过多次聚合计算。因此，面对百亿级的数据通过传统的关系型数据库来直接计算指标的方法很难支撑。
所以，相关技术中给出了通过搭建大数据平台来对百亿级的数据计算监管指标，例如借助于hive(数据指标算法仓库工具)、spark(计算指标计算引擎端)、Hadoop(Hadoop是一个能够对大量数据进行分布式处理的软件框架)等来搭建大数据平台。但大数据平台在计算指标时，需要对数据做不断的清洗和加工，使得计算指标时的延迟较高；而且，搭建大数据平台需要的服务器规模比较大(例如10台服务器以上)，又需要投入较多的人力进行每个指标分步骤进行计算，且由于需要处理的数据达到百亿级的量级，平台需要将数据加载到内存进行计算，因此对机器内存要求也比较高。
因此，相关技术中通过大数据平台在计算医疗指标的方案普遍存在着计算延迟高、对服务器的数量要求较多以及对服务器内存要求较高的问题。
发明内容
本发明实施例的目的是提供一种数据处理方法、装置、电子设备及可读存储介质，能够解决相关技术中通过大数据平台计算医疗指标所存在的计算延迟高、对服务器的数量要求较多以及对服务器内存要求较高的问题。
第一方面，本发明实施例提供了一种数据处理方法，该方法包括：
接收指标计算请求，其中，所述指标计算请求包括目标时间范围；
响应于所述指标计算请求，识别与目标时间范围匹配的目标时间分区；
在预先生成的医疗结算数据的候选索引中，确定每个所述目标时间分区分别对应的目标索引；
对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作指标计算，生成每个所述目标时间分区的子指标结果；
在所述目标时间分区的数量为多个的情况下，将多个所述目标时间分区的多个所述子指标结果进行累加，生成所述目标时间范围的目标指标结果；
其中，所述候选索引包括预先对所述医疗结算数据按照时间分区所创建的索引，所述目标分区数据包括所述医疗结算数据中结算时间在所述目标时间分区的时间范围内的数据。
第二方面，本发明实施例提供了一种数据处理装置，该装置包括：
接收模块，用于接收指标计算请求，其中，所述指标计算请求包括目标时间范围；
识别模块，用于响应于所述指标计算请求，识别与目标时间范围匹配的目标时间分区；
确定模块，用于在预先生成的医疗结算数据的候选索引中，确定每个所述目标时间分区分别对应的目标索引；
第一计算模块，用于对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作指标计算，生成每个所述目标时间分区的子指标结果；
第二计算模块，用于在所述目标时间分区的数量为多个的情况下，将多个所述目标时间分区的多个所述子指标结果进行累加，生成所述目标时间范围的目标指标结果；
其中，所述候选索引包括预先对所述医疗结算数据按照时间分区所创建的索引，所述目标分区数据包括所述医疗结算数据中结算时间在所述目标时间分区的时间范围内的数据。
第三方面，本发明实施例提供了一种电子设备，该电子设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤。
第四方面，本发明实施例提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤。
第五方面，本发明实施例提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面所述的方法。
在本发明实施例中，在对医疗指标进行计算时，预先可以按照时间分区来对医疗结算数据进行划分，以及按照时间分区来创建索引，并将划分的分区数据存储至对应时间分区的索引的存储空间中，那么在计算医疗指标时，则可以基于指标计算请求中的目标时间范围，来确定目标时间分区，从而按照目标时间分区来查找对应时间分区的目标索引，并在该时间分区的目标索引中获取所需要的目标分区数据进行指标计算，然后，将多个目标时间分区的指标计算结果进行累加，得到医疗指标的目标指标结果。在这个过程中，按照时间分区，来查找对应索引中的目标分区数据，来计算指标，可以对多个时间分区的目标分区数据进行并行处理，不仅可以快速查找到所需要计算的医疗结算数据，而且可以提升数据处理速度，相比于传统计算中采用大数据平台，从海量数据中读取所需数据计算指标，可以降低计算延迟，加快处理速度；而且，医疗结算数据按照时间分区存储到对应的索引的存储空间中，实现了数据的物理化存储，无需加载到内存中进行存储，可以降低对计算指标的服务器的内存的要求；另外，医疗结算数据通过索引物理化存储到各时间分区的索引的存储空间中，占用磁盘空间较少，相比于大数据平台的传统方案，对服务器的数量要求较低。
附图说明
图1是本发明一个实施例的数据处理系统的结构框图；
图2是本发明一个实施例的数据处理方法的流程图；
图3是本发明另一个实施例的数据处理方法的流程图；
图4是本发明另一个实施例的数据处理系统的结构框图；
图5是本发明又一个实施例的数据处理方法的流程图；
图6是本发明再一个实施例的数据处理方法的流程图；
图7是本发明一个实施例的数据处理装置的框图；
图8是本发明一个实施例的电子设备的硬件结构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本发明保护的范围。
本发明的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。
国发办文中提到大数据监管为依托，目前国家局给出的需要监管的医疗指标包括医疗费用总额增幅、住院总费用增幅、门诊总费用增幅、门诊次均费用、门诊次均费用增幅，住院次均费用、住院次均费用增幅等。这些医疗指标依赖的数据是患者在就医过程中的医疗数据、结算主单数据和结算明细数据。
目前各地市政府、医院信息化建设程度不一样，对于这块信息化建设预算较少，而且医保基金监管的医疗指标多并且复杂，指标计算依托数据量大，能达到百亿级，这个数量级的数据通过传统的关系型数据库直接计算方法，很难支撑。
为此，本发明实施例提供了一种基金监管指标计算平台，该平台可以部署在一台服务器中，也可以部署在多台服务器中。该平台以ES(elasticsearch，一种搜索服务器，用于分布式全文检索)、logstash(一个数据收集器，将各种格式各种渠道的数据通过收集解析之后格式化输出到ES)、ES-sql(ES数据库查询)开源插件为基础，并对ES和logstash的功能进行改进增强，提升了大数据场景下的聚合和实时计算能力；同时结合基金监管实际场景以医疗结算数据为数据处理基础，能够没有高配置服务器的情况下，通过极少服务器资源实现对百亿级医疗结算数据进行医疗指标的自动、实时聚合计算。
具体而言，如图1所示，该平台(也可以称为数据处理系统)可以包括接入管道端、指标计算引擎端、指标算法仓库这三个模块，这三个模块可以部署在不同的服务器中，也可以部署在同一台服务器中；此外，不论是这三个模块中的每个模块还是整个该平台还都可以部署到服务器集群中。
示例地，该平台部署到服务器集群中，使得服务器集群中的每台服务器都部署有该平台的三个模块，从而可以利用服务器集群来提高数据处理量，降低处理时延。
示例地，接入管道端可以是一个中间件工具，指标计算引擎端可以是一台服务器，指标算法仓库可以是一个数据库。
接入管道端可以包括本发明增强改进后的logstash，指标计算引擎端可以包括本发明增强改进后的ES以及支持ES-sql插件，而指标算法仓库则由本发明配置了专门用于计算上述医疗指标的公式以及公式中所用的参数变量等信息。
如图1所示，该平台可以通过JDBC连接来与社保系统进行数据交互，数据接入管道端负责通过JDBC来拉取医保系统中的医疗结算数据(包括结算主单数据和结算明细数据)；由于基于ES构建的指标计算引擎端不支持跨表查询，这里的接入管道端需要对拉取到的数据进行数据合并处理(即下文的合成宽表的操作)；接入管道端将合并处理后的数据，按照时间分区推送到指标计算引擎端中该时间分区的索引中；指标计算引擎端负责根据算法指标算法仓库请求的公式计算指标；其中，指标算法仓库的作用是存储指标公式及公式中代入的变量；在指标算法仓库接收到指标计算请求后，可以根据该请求中所需要计算的指标，在预先配置的公式中找到所需的公式，将公式通过HTTP请求发送至指标计算指标计算引擎端进行指标计算；指标计算引擎端可以根据指标计算请求中指标计算的时间范围自动在指标计算引擎端中寻址各时间分区的医疗结算数据；如果从医保系统中拉取到的医疗结算数据的数据量超过预设阈值(例如10亿、20亿、100亿等)数据，则指标计算引擎端需要对各时间分区的医疗结算数据分别计算指标后，将计算结果进行聚合累加，以便统计出该指标计算请求对应的每家医院的指标值，最后，指标计算指标计算引擎端将聚合结果发送回指标算法仓库，以便指标算法仓库对指标值进行存储。
由此可见，本发明实施例的上述平台实现了大数据量级的指标实时计算，由于其仅需要有限的服务器资源就可以实现平台的配置，那么不仅仅在信息化程度高、拥有云机房环境的一线城市可以实现该平台的方案，在预算有限的二、三线城市医院和医保局也可以实现大数据基金监管指标的实时计算；并且，未来基金监管将是国家医保机构大力推广的重要方向，因此，本发明实施例所提供的该平台的解决方案可以适用于任何基金监管开展的城市，具有广泛的使用及复用场景；该平台不仅控制了信息化建设的投入成本，规范了国家医保基金使用规范，而且减少了骗取医保基金违法犯罪的行为。
此外，本发明还提供了一种数据处理方法，该数据处理方法可以由上述平台中的上述三个模块来执行实现，下面结合各个实施例的数据处理方法来对图1中的上述平台的数据处理流程做详细阐述。
参照图2，示出了本发明一个实施例的数据处理方法的流程图，所述方法具体可以包括如下步骤：
步骤101，提取医疗结算数据的结算时间；
其中，医疗结算数据可以包括结算主单数据和结算明细数据，看病医疗的医疗场景下，结算主单数据的载体可以为不带明细的发票，结算明细数据的载体可以为带有明细的明细单，因此，一张发票所关联的一条明细单中具有至少两条明细数据；当然，如果明细数量较少，该结算明细数据也可以作为发票的部分内容直接打印在发票中。
那么每组医疗结算数据都是存在结算时间的，其中，相互关联的结算主单数据和结算明细数据的结算时间显然是相同的。
本步骤可以由上述平台的接入管道端和指标计算引擎端分别来实现，也可以由二者之一来实现，并通知对方该结算时间。
步骤102，基于所述结算时间，按照时间分区对所述医疗结算数据进行数据提取，生成与不同时间分区匹配的多组分区数据，其中，在所述医疗结算数据的数据量大于预设阈值的情况下，所述时间分区的时间单位的时长小于年的时长；
其中，本步骤可以由接入管道端来实现，接入管道端主要是从社保系统拉取医疗结算数据，那么如果判断拉取到的医疗结算数据的数据量超过预设阈值(例如10亿，但不限于此)，则说明数据量较大，采用传统方案延迟高，因此，接入管道端按照时间单位的时长小于年的时长的时间分区从医疗结算数据中提取各分区数据，例如按半个月、按月、按季度、按6个月等单位小于年的时间分区来对医疗结算数据进行划分。
步骤104，基于所述结算时间，按照所述时间分区创建索引，生成与不同时间分区匹配的多个候选索引；
其中，本步骤可以由指标计算引擎端来实现，指标计算引擎端在确定医疗结算数据的数据量超过例如10亿的情况下，则按照步骤102相同的时间分区进行索引的创建，例如按月创建医疗结算数据的索引，以对2020年一年的医疗结算数据进行索引创建为例，则可以生成2020年1月至12月的12个候选索引。
其中，本发明对于步骤102和步骤104之间的执行顺序不做限制，二者都在步骤101之后执行，步骤105则在步骤102和步骤104均执行完成之后执行。
步骤105，对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据存储至匹配于所述第一时间分区的候选索引的存储空间中，其中，所述第一时间分区为所述不同时间分区中的每个时间分区。
例如，接入管道端可以将按月划分的分区数据，推送到指标计算引擎端的对应月的候选索引的存储空间中进行存储。
可选地，在将分区数据按照时间分区存储到对应时间分区的索引的存储空间中时，可以通过对分区数据做压缩处理，来进一步降低医疗结算数据对磁盘空间的占用率，以及进一步降低对服务器的数量要求。
下面结合图3和图4来对上述实施例的数据处理方法进行举例说明：
首先，在图1中的平台启动后，接入管道端和指标计算引擎端可以并行执行下述操作：
具体而言，接入管道端从社保系统的社保数据库拉取医疗结算数据(这里为1年的医疗结算数据，例如图4所示出的结算时间在2020年这1年的的医疗结算数据，该医疗结算数据包括结算主单数据和结算明细数据，在其他实施例中，该医疗结算数据可以是社保系统中的任意时间长度的医疗结算数据，例如半年、一年、两年、全部等时间长度)，提取结算时间，基于结算时间按年统计结算明细数据的数据条数(例如2020年这一年的结算明细数据的数据条数)，按年判断数据条数是否超过10亿(这里判断2020年这一年的结算明细数据的数据条数是否超过10亿，当然，如果拉取到的是两年或两年以上的医疗结算数据，则分别判断每年的结算明细数据是否超过10亿，针对超过10亿的该年份内的医疗结算数据按照按月创建索引和按月抽取数据的流程执行，针对不超过10亿的该年份的医疗结算数据按照按年创建索引和按年抽取数据的流程执行)；如果是，则接入管道端对该年的医疗结算数据按照月的单位抽取医疗结算数据，从而实现对该年的医疗结算数据的按月划分提取，生成该年的各月的分区数据；如果否，则接入管道端直接抽取该年的全年的医疗结算数据，即按年抽取医疗结算数据；
此外，在按年或按月抽取医疗结算数据之前，由于社保数据库是关系型数据库，接入管道端需要将拉去的医疗结算数据转换为非关系型数据，然后，进行按年或按月的提取。
指标计算引擎端按照与接入管道端相同的方式从社保系统的社保数据库拉取医疗结算数据(包括结算主单数据和结算明细数据)，提取结算时间，基于结算时间按年统计结算明细数据的数据条数，按年判断数据条数是否超过10亿；如果是，则指标计算引擎端对该年的医疗结算数据按照月的单位创建索引，生成该年的各月的候选索引；如果否，则指标计算引擎端对该年的医疗结算数据按年的单位创建索引；
其中，指标计算引擎端对ES做了功能增强，因此，在平台启动时，指标计算引擎端可以自动检测医保数据库的数据，如果数据量超过10亿，指标计算引擎端会按月进行医疗结算数据的划分并自动创建索引，索引是对划分后的一组分区数据所建立的索引，那么当需要计算指标时，指标计算引擎端则可以利用该索引快速对对应月的一组分区数据进行查询和聚合计算，其中，ES的10亿数据级，在索引的数据结构中每行数据包括25个字段的情况下，指标计算引擎端在进行聚合计算时，在1分钟之内可以计算出结果，而计算过程超过一分钟会影响用户体验。因此，本发明实施例以10亿数据量为建单个索引的标准。
其中，指标计算引擎端所创建的索引可以是倒排索引，由于医疗结算数据中的每条医疗结算数据具有多个属性，而指标计算引擎端为了能够提升在计算指标时对所需要的医疗结算数据的检索效率，因此，可以对一些属性创建倒排索引；例如索引涉及的医疗结算数据的属性可以包括医院级别、医院等级、医院类别等。其中，医院级别的属性值可以包括三级、二级、一级；医院等级可以包括甲等、乙等、丙等；医院类别可以包括具体专科类别(例如儿科、中医、妇科等)、全科等。倒排索引源于实际应用中需要根据属性的值来查找记录。这种索引表中的每一项都包括一个属性值和具有该属性值的各记录的地址。由于不是由记录来确定属性值，而是由属性值来确定记录的位置，因此称作倒排索引。
然后，在指标计算引擎端中的索引建立完毕后，需要将医疗结算数据拉到对应的索引中，这部分工作由接入管道端来负责；如果数据量大于10亿，则平台会自动调度logstash按月抽取数据任务，使logstash可以将按月抽取的医疗结算数据推送到ES对应月的索引的存储空间中，其中，接入管道端可以按照索引的时间段(即时间分区)来将相应时间段的分区数据推送到索引的存储空间中。例如，对于2020年10月的医疗结算数据，可以按照2020年10月的索引涉及的属性，将2020年10月的医疗结算数据中的所述属性的数值添加到2020年10月的索引中。
需要说明的是，不同索引的数据结构是相同的，也就是说，不同月的索引所对应的属性是相同的，例如2020年1月的索引涉及的属性包括医院级别、医院等级、医院类别；2020年2月的索引涉及的属性也包括医院级别、医院等级、医院类别。那么通过将医疗结算数据按月存储到对应月的索引的存储空间中，可以将结算数据和结算明细数据按照索引作物理磁盘的分区，从而在对大数据量进行指标计算时，能够通过倒排索引来查找分区数据中的所需数据，降低对机器内存要求，只需要一台服务器就可以存储按月分区后的分区数据。
其中，如图4所示，指标计算引擎端对2020年的医疗结算数据按月创建了12个候选索引，分别命名为数据_202001、数据_202002、数据_202003、数据_202004……数据_202011、数据_202012来表示2020年12个月的索引，而接入管道端中的Logstash则可以将2020年按月划分的12个月的分区数据，分别推送到指标计算引擎端中的上述对应月的索引的存储空间中，这里索引对应的存储空间为服务器A和服务器B的存储空间。示例的，索引“数据_202001”对应的存储空间中存储的是医保数据库的医疗结算数据中结算数据为2020年1月的医疗结算数据这一分区数据。这里为了确保服务器的可靠性，避免存储分区数据的服务器崩溃导致无法实现指标计算，可以将分区数据存储到两台服务器中；当然，在服务器稳定性较强的情况下，一台服务器也可以满足百亿级数据的存储需求。
在本发明实施例中，在医疗结算数据的数据量大于预设阈值的情况下，可以通过提取医疗结算数据的结算时间，然后基于该结算时间，按照时间单位的时长小于年的时长的时间分区(例如按月)来对医疗结算数据进行提取医疗结算数据，从而生成与不同时间分区匹配的多组分区数据，以及基于该结算时间，例如按月的时间分区来分区创建候选索引，然后，将各时间分区的分区数据推送到对应的时间分区的候选索引的存储空间中，使得百亿级的医疗结算数据可以例如按月做到物理磁盘的分区存储，能够降低对服务器的内存要求以及减少服务器资源的投入；而且，在对时间分区的分区数据存储时是存储到对应的时间分区的候选索引中，能够通过索引来快速获取所需要的医疗结算数据进行指标计算，那么面对百亿级数据的医疗指标的计算需求时，则可以实现低延迟的实时指标计算。
可选地，在执行步骤105时，对于所述多组分区数据，对每组分区数据作分片处理，生成每组分区数据的分片数据；对所述每组分区数据中的分片数据生成副本数据；对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据存储至匹配于所述第一时间分区的候选索引的存储空间中，其中，每组分区数据中同一分片的所述分片数据和所述副本数据存储在不同的服务器中。
如图4所示，以结算时间为2020年1月这一组分区数据为例，指标计算引擎端可以将索引名称为“数据_202101”的索引中该2020年1月的这一组分区数据作分片处理，生成了3片分片数据，并对每一片分片数据各生成一个副本数据，这里部署了两台服务器用于存储索引中的分区数据，则指标计算引擎端将分片数据和其副本数据存储在不同的服务器中，分别为服务器A和服务器B。
在本发明实施例中，为了确保平台系统的高可用，可以将索引中的数据存储在不同的服务器中，避免一台服务器崩溃导致无法查询获取所需要的分区数据进行指标计算；此外，还可以对每组分区数据作分片处理，并将分片数据生成副本数据，并将同一分片的分片数据和副本数据存储到不同的服务器中，这样可以在读取索引中的分区数据进行指标计算时，并行地从不同服务器中读取所需的分区数据，提升指标计算效率，降低指标计算时延。
可选地，所述多组分区数据中的每组所述分区数据包括结算主单数据和与所述结算主单数据关联的结算明细数据；
其中，在对医疗结算数据未按照时间分区做划分之前，医疗结算数据就是包括结算主单数据和结算明细数据的，而生成的多组分区数据是按照结算时间对应的时间分区所划分的，例如按月划分的，因此，每月的分区数据(也是医疗结算数据)仍旧包括结算主单数据和结算明细数据，它们之间的关联关系参照上文，这里不再赘述。
可选地，上述步骤102之后，根据本发明实施例的方法还可以包括步骤103；
步骤103，对于所述每组分区数据中的结算明细数据，在与所述结算主单数据关联的所述结算明细数据的数量为多条的情况下，将所述结算主单数据冗余地关联至每条所述结算明细数据，生成宽表数据；
其中，每条医疗结算数据可以包括一条结算主单数据和与之关联的结算明细数据。
如果一条结算主单数据只关联有一条结算明细数据，则无需做本发明的合成宽表的操作；但是，如果一条结算主单数据关联有多条结算明细数据，那么需要对结算主单数据做冗余存储。
具体而言，一条医疗结算数据包括一条结算主单数据以及多条结算明细数据，其中，每条结算明细数据具有一个明细ID，而结算主单数据也有一个主单ID，则可以借助于主单ID，来将这里的每条结算明细数据与该主单ID关联，来实现该结算主单数据的冗余存储，这样一组分区数据中的每条数据是生成的宽表数据，具体包括一条结算明细数据以及该结算明细数据所关联的结算主单数据。
例如一条医疗结算数据中，主单ID1的结算主单数据关联的结算明细数据的明细ID分别为明细ID1、明细ID2，则对这条医疗结算数据所生成的宽表结构如表1所示：
| 明细ID | 明细内容 | 主单ID | 主单内容 |
| 明细ID1 | 明细内容1 | 主单ID1 | 主单ID1的主单内容3 |
| 明细ID2 | 明细内容2 | 主单ID1 | 主单ID1的主单内容3 |
表1
那么在执行步骤105时，则对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据中的所述宽表数据存储至匹配于所述第一时间分区的候选索引的存储空间中。
并且，在上述步骤102中，是在所述结算明细数据的数据量超过预设阈值的情况下，基于所述结算时间，按照时间单位的时长小于年的时长的时间分区(例如按月，按季度等)对所述医疗结算数据进行数据提取，生成与不同时间分区匹配的多组分区数据。
参照图3的示例，在将按月抽取的分区数据存储至对应月的索引之前，可以将每月的分区数据(包括结算主单数据和结算明细数据)按照步骤103，构建结算主单和结算明细表数据为一张宽表数据，然后，再在指标计算引擎端中找到对应月的索引，并将生成的该月的宽表数据存储到对应月的索引的存储空间中。
而在图4的示例中，存储在服务器A和服务器B中的分区数据也是以结算明细数据为维度，并该结算明细数据的结算主单进行冗余存储的宽表结构的数据，对这样宽表结构的数据做分片处理和存储。
在本发明实施例中，可以通过将抽取的结算主单数据和结算明细数据，按照结算明细数据的维度，对结算主单数据进行冗余存储，从而合并成宽表数据，然后，将宽表数据按月存储至对应月的索引的存储空间中，合并成一张宽表的设计的原因在于，指标计算引擎端中的ES自身支持的SDL语法复杂、维护难度大，使用成本高，为了降低计算医疗指标的成本，平台引入ES-sql插件到指标计算引擎端中，使得指标计算引擎端可以直接支持SQL算法公式，不仅降低了成本，而且指标计算引擎端可以对指标算法仓库中配置的涉及SQL的公式进行SQL计算；但是，由于ES-sql插件目前不支持多表关联查询，因此，本发明实施例的方法将结算主单数据和结算明细数据合并成一张宽表，来避免在读取分区数据进行指标计算时的跨表查询问题。
与上述任意一个数据处理方法的实施例相结合，本发明还提供了一种数据处理方法，该方法的具体流程如图5所示，该方法可以包括如下步骤：
步骤201，接收指标计算请求，其中，所述指标计算请求包括目标时间范围；
其中，该指标计算请求还可以包括所需要计算的医疗指标，即目标指标，该目标指标的数量可以是一个或多个，因此，可以以指标集合来表示所需要计算的指标。多数场景下，指标计算请求中所请求计算的指标为多个指标，目的在于通过多维度的指标结果，来对各家医院做综合考量。
步骤202，响应于所述指标计算请求，识别与目标时间范围匹配的目标时间分区；
其中，图1中的指标算法仓库可以接收到指标接收请求，该指标计算请求可以包括需要计算的指标的时间范围，例如2020年1月至3月，当然，该时间范围也可以不是整月的，例如2020年1月15日至3月10日，目标时间分区均为2020年1月至3月；该时间范围也可以是整年的，例如2020年一整年，则目标时间分区为2020年1月至12月。
步骤203，在预先生成的医疗结算数据的候选索引中，确定每个所述目标时间分区分别对应的目标索引；
其中，指标算法仓库可以将目标时间分区通知给指标计算引擎端，以目标时间范围为2020年1月至3月为例，参照图4的示例，指标计算引擎端可以在候选索引中，确定目标索引；目标索引包括名称为“数据_202001”的索引、名称为“数据_202002”的索引、名称为“数据_202003”的索引。
步骤204，对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作指标计算，生成每个所述目标时间分区的子指标结果；
其中，名称为“数据_202001”的索引的存储空间中存储的目标分区数据为2020年1月的医疗结算数据，名称为“数据_202002”的索引的存储空间中存储的目标分区数据为2020年2月的医疗结算数据，名称为“数据_202003”的索引的存储空间中存储的目标分区数据为2020年3月的医疗结算数据；
指标计算引擎端可以对上述三个月中每个月的医疗结算数据分别进行指标计算，从而生成这3个月的子指标结果。
当然，如果目标时间范围不是整月的，例如2020年1月15日至3月10日，则在进行指标计算时，计算1月的子指标结果时，并不需要对2020年1月的索引中1月这一整个月的医疗结算数据进行计算，只需要对名称为“数据_202001”的索引的存储空间中存储的2020年1月1日至1月15的医疗结算数据进行指标计算；同理在计算3月的子指标结果时，也是同理。
也就是说，在计算子指标结果时，如果目标时间范围包括不是完整的时间分区(这里的时间分区的单位为月，那么不完整的时间分区表示不是整月)，则还可以进一步按照该目标时间范围来从目标索引的目标分区数据中确定所需要计算的目标医疗结算数据，进行子指标结果的计算。
可选地，参照图4的示例，名称为“数据_202001”的索引的存储空间中的目标分区数据包括结算时间在2020年1月的三片分片数据，并且，三片分片数据还分别具有副本数据，且同一分片的分片数据和副本数据存储在不同的服务器中，因此，为了提升对指标计算的效率，降低计算延迟，可以并行的从图4的两个服务器中读取目标分区数据。例如，指标计算引擎端可以从服务器A按照指标计算请求从服务器A读取“数据_202001_分片01”、“数据_202001_分片02_副本”，从服务器B读取“数据_202001_分片03副本”，来达到获取2020年1月的索引中的目标分区数据进行2020年1月的子指标结果的计算的目的。
可选地，在执行上述步骤204时，可以通过步骤301、步骤302和步骤303来实现：
步骤301，根据所述指标计算请求中所请求计算的目标指标，在用于计算指标的预设表达式中获取用于计算所述目标指标的目标表达式，以及在预设的与不同指标关联的多个指标参数表中获取与所述目标指标关联的目标参数表；
其中，指标算法仓库中预先配置有各个医疗指标的计算公式(即预设表达式)，那么指标算法仓库可以根据所接收到的请求计算的目标指标，来从预设表达式中选取能够用于计算目标指标的目标表达式；此外，考虑到不同场景下需要计算同一个指标，例如门诊的指标1和住院的指标1，因此，可以将上述预设表达式配置的更加通用化，所以，指标算法仓库中还会对每个医疗指标配置指标参数表，那么由于还对每个医疗指标配置了预设表达式，因此，预设表达式与指标参数表可以通过同一医疗指标进行关联；并且，指标参数表包括参数和参数值，该参数为与该指标参数表关联的预设表达式中的参数。这样，指标计算引擎端借助于指标算法仓库中的预设表达式以及其指标参数表则可以进行指标计算。其中，指标算法仓库中用于计算指标的表达式及其参数表都是可配置的，可以自定义的新增和变更，从而灵活满足指标计算需求的变化。
步骤302，采用所述目标参数表中每个参数的参数值，对所述目标表达式中的相应参数进行替换，生成所述目标指标的目标公式；
其中，指标算法仓库可以利用目标参数表来对目标表达式中的参数替换为目标参数表中的参数值，从而生成能够用于计算该目标指标的目标公式。
步骤303，采用所述目标公式，对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作所述目标指标的计算，生成每个所述目标时间分区的子指标结果。
其中，指标计算引擎端可以根据目标时间范围，来从相应的目标时间分区的目标索引中找到目标分区数据，然后，根据目标公式中所需要计算的属性，来从目标分区数据中获取相应的属性值，并按照该目标公式进行计算，从而生成该目标时间分区的子指标结果。
在本发明实施例中，通过预先配置用于计算各个医疗指标的表达式，以及配置每个医疗指标的表达式中参数对应的参数表，来进行医疗指标的计算，从而可以通过简单的配置满足自定义的医疗指标新增和变更操作；此外，利用预设表达式和该预设表达式的指标对应的预设参数表，来计算指标，而非设置计算指标的单一公式，而是配置了通用的表达式，以及个性化场景下的该表达式的参数表，使得配置的表达式可以适用于计算各种场景下的同一指标，例如门诊的指标1和住院的指标1。
可选地，所述预设表达式包括相互关联的主表达式和至少一个子表达式，其中，所述主表达式包括至少一个子表达式之间的计算逻辑关系，所述指标参数表包括不同指标的每个子表达式的参数表；
那么在执行步骤301时，则可以根据所述指标计算请求中所请求计算的目标指标，在用于计算指标的预设表达式中获取用于计算所述目标指标的目标主表达式和至少一个目标子表达式，以及在预设的与不同指标关联的多个指标参数表中，获取与所述目标指标关联的所述至少一个目标子表达式的至少一个目标参数表；
本步骤可以由图1中的指标算法仓库来执行，然后，指标算法仓库将获取的用于计算所述目标指标的目标主表达式和至少一个目标子表达式以及与所述目标指标关联的所述至少一个目标子表达式的至少一个目标参数表传递给指标计算引擎端，以便指标计算引擎端进行指标计算。
那么在执行步骤302时，则可以对所述目标子表达式中的参数进行排序，依据所述目标参数表中的参数序号和参数值，对所述目标子表达式中排列在相应位置的参数进行所述参数值的替换，生成所述目标指标的目标公式，所述目标公式包括参数被参数值替换的目标子表达式以及表达了至少一个目标子表达式的计算逻辑关系的目标主表达式。
其中，本步骤可以由指标算法仓库来执行。
可选地，在上述实施例中，可以首先获取用于计算目标指标的子表达式，以及获取该目标指标的该子表达式所对应的参数表，将该子表达式中的参数，按照该参数表带入参数值，生成完整的子表达式，待完整的子表达式计算完成后，再将子表达式的计算结果带入到该子表达式对应的主表达式，从而按照主表达式中各子表达式之间的逻辑关系，来计算目标指标的子指标结果。
示例地，指标算法仓库存储着指标算法公式和指标公式变量(即上述指标参数表)。其中，指标算法公式存储指标编号、指标名称、指标算法模板(即预设表达式)，表达式类型，表达式编号；指标公式变量存储内容为指标编号，参数名称，参数序号，参数值。通过指标编号可以将指标算法公式与指标公式变量关联；通过指标编号可以将主表达式和子表达式进行关联；每个指标都包括一个主表达式和至少一个子表达式。
表2示意性的示出了住院次均费用增幅这一医疗指标的指标算法公式；
表3示意性的示出了住院次均费用增幅这一医疗指标的指标公式变量(也称参数表)；
表2
表3
如表3所示，一个指标中的子表达式对应多个参数，这些参数是传到表2中的指标算法模板中的变量。例如“住院次均费用增幅”这个医疗指标的“本年度住院总费用”对应的子表达式为select hospital_id,sum(fee_total)from％swhere medical_id in(％s)anddate_discharge>＝cast('％s'as datetime)and date_discharge<＝cast('％s'asdatetime)group by hospital_id，该子表达式中的％s为参数，需要使用表3所示的指标公式变量，这一变量表中的内容进行替换的，并且，在将该子表达式中的参数替换为参数值时，可以按照该参数的排序进行参数值的替换。
这里之所以对子表达式配置参数表，目的在于使得表2的指标算法模板具有通用性。例如计算区间段的指标，如果对计算该指标的公式中的时间不设置参数，则该公式无法通用于各种时间段的同一指标的计算。而通过设置参数表，则只需要设置通用公式，将变化的值通过传参数的方式来计算指标；再如，有些指标计算的是门诊，或者住院，那么可以采用同一公式，通过传递门诊或住院的不同参数，来进行不同场景下同一指标的计算，不需要跳转公式，只需要将参数值变化为门诊或住院即可。
此外，通过表2和表3可以看出，根据指标编号和表达式编号，可以找到表达式和参数的对应关系。
步骤205，在所述目标时间分区的数量为多个的情况下，将多个所述目标时间分区的多个所述子指标结果进行累加，生成所述目标时间范围的目标指标结果；
其中，所述候选索引包括预先对所述医疗结算数据按照时间分区所创建的索引，所述目标分区数据包括所述医疗结算数据中结算时间在所述目标时间分区的时间范围内的数据。
下面结合图6和上述表2和表3，来对利用表达式和参数表来计算目标指标的过程进行描述，其中，图6中的步骤415由指标计算引擎端执行，除该步骤415之外的步骤均可以由指标算法仓库来执行：
步骤401，读取指标信息；
其中，当所述平台接收到指标计算请求，平台中的指标算法仓库可以读取该指标计算请求对应的目标指标的指标信息，指代表达式信息；
如果需要计算多个指标，则指标算法仓库可以读取多个目标指标的表达式信息，以便多个目标指标分别向指标计算引擎端发起计算请求。
其中，一个指标的预设表达式可以包含一个主表达式和至少一个子表达式，其中，主表达式表示各个子表达式的计算逻辑关系；
当一个预设表达式包括一个主表达式和一个子表达式时，则说明该主表达式表示该子表达式，因为不存在其他的子表达式，例如表2中本年度住院总费用这一指标，当该本年度住院总费用作为一个医疗指标时，则其主表达式为{1}，表达式类型为0，表达式编号为0，而其子表达式为“select hospital_id,sum(fee_total)from％s where medical_id in(％s)and date_discharge>＝cast('％s'as datetime)and date_discharge<＝cast('％s'as datetime)group by hospital_id”，表达式类型为1(即表示是子表达式)，表达式编号为1。
当一个预设表达式包括一个主表达式和多个子表达式时，例如表2所示的指标算法公式的表格中，指标名称为“住院次均费用增幅”这个指标，对应的主表达式是({1}/{2}-{3}/{4})/({3}/{4})，里面的{1}，{2}，{3}，{4}对应的都是子表达式的计算结果。当子表达式计算完毕后会将数据代入到主表达式中完成计算。
步骤402，遍历该指标下的表达式；
其中，当指标算法仓库读取完指标信息后，可以遍历目标指标的表达式，这里所遍历的表达式包括该指标的主表达式和子表达式；
步骤403，判断是否还有表达式需要遍历；
其中，如果一个指标的主表达式和子表达式均遍历完成，则指标算法仓库确定没有该指标的表达式需要遍历，还需要进一步判断是否还有其他指标的表达式需要遍历。因为，指标计算请求中所需要计算的指标大多数情况下不是一个指标，而是一个指标集合，即多个指标。那么当需要计算多个指标时，则需要对多个指标的表达式进行逐个遍历，因此，当所有需要计算的指标下的表达式均遍历完成，则确定没有表达式需要遍历了。
在步骤403之后，若是，则步骤404，判断当前遍历的表达式是否是主表达式；
在步骤403之后，若否，则转至步骤406；
在步骤404之后，若是，则步骤405，将当前遍历的主表达式进行缓存，然后，转至步骤406；
在步骤404之后，若否，则说明当前遍历的表达式是该指标下的子表达式，则转至步骤409；
步骤409，将指标计算请求中的目标时间范围按月分区；
例如请求计算周期(即目标时间范围)为2020年1月到2020年3月，则分为2020年1月的时间分区，2020年2月的时间分区，2020年3月的时间分区；
步骤410，向下遍历分区；
其中，指标计算引擎端可以依次遍历2020年1月、2020年2月、2020年3月这三个月的时间分区对应的索引中的分区数据。
步骤411，在缓存中按分区查找当前遍历的子表达式的计算结果；
其中，指标计算引擎端可以在缓存中查找当前遍历的子表达式对2020年1月的分区数据的计算结果，对2020年2月的分区数据的计算结果，对2020年3月的分区数据的计算结果。
步骤412，判断在缓存中是否找到该子表达式的计算结果；
步骤412之后，若否，则说明该子表达式还没有对目标时间范围对应的多个分区数据中的任意一个分区数据进行计算，则执行步骤413；
步骤413，根据指标计算请求所需要计算的目标指标的指标编号，获取该目标指标对应的参数表，并对当前遍历的子表达式中的变量进行排序；
步骤414，按照排序后的变量的排列顺序，依据参数表中的参数序号，来对当前遍历的子表达式中的参数依次进行参数值的赋值，以构建完整的子表达式；
其中，在采用子表达式对分区数据进行计算之前，首先通过步骤413将子表达式中的参数(例如上述表2中的％s)进行排序，再依照参数表将每个子表达式中的参数用参数值替换。例如，参照表2和表3，“住院次均费用增幅”这个指标的“本年度住院总费用”子表达式为select hospital_id,sum(fee_total)from％s where medical_id in(％s)and date_discharge>＝cast('％s'as datetime)and date_discharge<＝cast('％s'as datetime)group by hospital_id，这里可以对该子表达式中的％s变量进行赋值，构建完整的表达式，参照表3可知，该“本年度住院总费用”子表达式中的第一个％s带入table的值，table是分区的索引名称；如果是2020年1月份的时间分区，这里的table就带入tk24_01，tk24_01代表去2020年的第一个分区索引中计算，例如tk24_01是系统对2020年1月的分区数据自动创建的索引名；“本年度住院总费用”子表达式的公式中的第二个％s按照表3所示的参数表，则带入‘20’，其中，‘20’代表住院的标识，并非门诊的标识。该“本年度住院总费用”子表达式中第三个％s带入{start_time}，表示开始时间，“本年度住院总费用”子表达式中第四个％s带入{end_time}，表示结束时间，从而可以构建出“本年度住院总费用”的完整的子表达式。
步骤415，将构建的完整的子表达式提交给线程池，向指标计算引擎端发起聚合计算请求；
其中，指标算法仓库确定请求计算的指标对应的子表达式，并将该子表达式涉及的参数的参数值按照表3带入子表达式，然后将带入参数值的子表达式发送给指标计算引擎端请求计算，由于需要计算2020年1月至3月这三个月的子表达式的结果，因此，需要对2020年1月至3月这三个月分别请求计算。
在步骤415之后，指标计算引擎端可以根据该聚合计算请求，来通过构建完整的子表达式对目标时间范围对应的各个分区数据进行计算，这里首先按照该完整的子表达式来计算2020年1月的分区数据，将计算结果发送给指标算法仓库，步骤416，指标算法仓库将计算结果进行缓存，然后，转至步骤417；
在步骤412之后，若是，则说明该子表达式已经计算，但是不确定是否该目标时间范围对应的多个时间分区都已经按照子表达式进行了计算，因为，需要采用该子表达式分别计算2020年1月、2020年2月、2020年3月三个月的时间分区的表达式结果。因此，需要转至步骤417；
步骤417，判断目标时间范围对应的多个时间分区是否都已经按照该子表达式进行计算完成；
在步骤417之后，若否，则转至步骤410，例如只找到了该子表达式对2020年1月的分区数据的计算结果，则需要继续遍历2020年2月的分区数据，来按照该子表达式进行计算，以此类推。
在步骤417之后，若是，则转至步骤418；
步骤418，将目标时间范围对应的每个时间分区，在该子表达式下的计算结果进行累加，计算出该子表达式的值，然后，转至步骤403；
步骤406，等待子表达式计算完毕；
这里等待主表达式所包括的多个子表达式全部计算完毕，以及等待主表达式所包括的子表达式对目标时间范围对应的每个时间分区的分区数据都计算完成；
步骤407，将子表达式计算结果带入主表达式；
其中，由于子表达式计算结果已经是目标时间范围对应的多个分区数据，在该子表达式下的计算结果的累加值，因此，可以将各个子表达式计算结果直接带入主表达式。
步骤408，通过主表达式计算出指标结果，结束。
在本发明实施例中，通过对计算指标的表达式配置有主表达式和子表达式，以及子表达式的参数表，那么在利用表达式来进行指标计算时，则可以首先对子表达式中的参数进行排序，按照排序和该子表达式的参数表中的参数序号，来对子表达式中的参数替换为参数表中的参数值，从而构建完整的子表达式，这样，可以使得构建的子表达式通用于各个场景下的同一指标的计算；然后，再基于主表达式中子表达式之间的逻辑关系，对各子表达式的计算结果进行逻辑运算，从而得到该指标的主表达式的计算结果；在这个过程中，还需要考虑到目标时间范围对应的多个时间分区，按照时间分区来采用构建完整的主表达式对各时间分区的分区数据进行指标计算，然后将计算结果累加，从而得到目标指标的计算结果，提升了指标计算结果的准确度。
在本发明实施例中，在对医疗指标进行计算时，预先可以按照时间分区来对医疗结算数据进行划分，以及按照时间分区来创建索引，并将划分的分区数据存储至对应时间分区的索引的存储空间中，那么在计算医疗指标时，则可以基于指标计算请求中的目标时间范围，来确定目标时间分区，从而按照目标时间分区来查找对应时间分区的目标索引，并在该时间分区的目标索引中获取所需要的目标分区数据进行指标计算，然后，将多个目标时间分区的指标计算结果进行累加，得到医疗指标的目标指标结果。在这个过程中，按照时间分区，来查找对应索引中的目标分区数据，来计算指标，可以对多个时间分区的目标分区数据进行并行处理，不仅可以快速查找到所需要计算的医疗结算数据，而且可以提升数据处理速度，相比于传统计算中采用大数据平台，从海量数据中读取所需数据计算指标，可以降低计算延迟，加快处理速度；而且，医疗结算数据按照时间分区存储到对应的索引的存储空间中，实现了数据的物理化存储，无需加载到内存中进行存储，可以降低对计算指标的服务器的内存的要求；另外，医疗结算数据通过索引物理化存储到各时间分区的索引的存储空间中，占用磁盘空间较少，相比于大数据平台的传统方案，对服务器的数量要求较低。
可选地，所述指标计算请求还包括所述医疗结算数据的目标属性信息；
可选地，在执行步骤303时，可以按照所述目标属性信息，对预先存储至每个所述目标索引的存储空间中的目标分区数据进行数据筛选；对经过所述数据筛选后的每个目标分区数据，按照不同医院进行分组，生成不同医院的经过所述数据筛选后的每个目标分区数据；然后，按照医院，对经过所述数据筛选后的每个目标分区数据分别作指标计算，生成每个医院的所述目标时间分区的子指标结果；
继续以目标时间范围为2020年1月至3月为例，该指标计算请求不仅可以包括所请求计算的目标指标(例如住院次均费用增幅)，还可以包括上述目标时间范围，以及医疗结算数据的目标属性信息，例如目标属性包括医院级别和医院等级，目标属性信息为三级甲等医院，也就是说，用户希望获取每家三级甲等医院在2020年1月至3月这三个月内的住院次均费用增幅这一指标的指标值。这里的目标属性信息可以理解为预先建立的候选索引中所涉及的属性的属性值。
那么本步骤中，指标计算引擎端可以从2020年1月的索引的存储空间中存储的分区数据中，筛选三级甲等医院的2020年1月的医疗结算数据；类似的，也可以利用上述目标属性信息和目标索引，来筛选到三级甲等医院的2020年2月的医疗结算数据，以及三级甲等医院的2020年3月的医疗结算数据；
然后，指标计算引擎端可以对上述三个月的每个月的三级甲等医院的医疗结算数据，按照医院ID进行分组，从而对于上述三个月中每个月的医疗结算数据能够按照医院进行分组，以2020年1月的三级甲等医院的医疗结算数据为例，其中分为医院1、医院2和医院3这三所三级甲等医院的2020年1月的医疗结算数据；然后，按照住院次均费用增幅这一指标的公式，对于医院1的2020年1月的医疗结算数据进行指标计算，得到医院1在2020年1月的目标指标的子指标结果；同理可以得到医院1在2020年2月和3月这两个月的目标指标的两个子指标结果。
需要说明的是，不同时间分区的医疗结算数据涉及的满足目标属性信息的医院可以相同，也可以存在差异，例如医院2仅具有2020年1月的医疗结算数据，医院3仅有2020年2月的医疗结算数据。
那么在执行上述步骤205时，在所述目标时间分区的数量为多个的情况下，将同一医院的多个所述目标时间分区的多个所述子指标结果进行累加，生成每个医院的所述目标时间范围的目标指标结果。
示例地，可以将医院1的2020年1月至3月的目标指标的三个子指标结果进行累加，从而得到医院1在2020年1月至3月内的目标指标的指标结果；同理，得到医院2在2020年1月至3月内的目标指标的指标结果，以及医院3在2020年1月至3月内的目标指标的指标结果。
在本发明实施例中，指标计算请求中可以包括医疗结算数据的目标属性信息，那么在对指标计算请求进行响应来计算目标指标时，可以基于该目标属性信息来对各目标时间分区的目标分区数据进行筛选，从而能够利用按照时间分区配置的索引，快速找到所需要计算的医疗结算数据；并且，对于筛选后的目标分区数据可以按照医院进行分组，从而能够按照不同医院来计算各医院的目标指标的指标结果，与医疗指标的计算场景更加贴合，能够灵活地计算出满足目标属性信息的筛选条件的各家医院的医疗指标。
在实际应用中，医保基金监管指标计算是判定医保基金违规使用的重要标准，医保基金管理员可以通过本发明实施例的上述平台所提供的管理端，输入指标计算周期，例如前文举例的2020年的1月至3月，该平台就可以利用上述数据处理方法对海量的数据进行实时的指标计算，并将计算结果反馈给用户，计算过程可以在1-2台普通服务器上运行，可实现低成本，实时，便捷。
需要说明的是，本发明实施例提供的数据处理方法，执行主体可以为数据处理装置，或者该数据处理装置中的用于执行数据处理方法的控制模块。本发明实施例中以数据处理装置执行数据处理方法为例，说明本发明实施例提供的数据处理装置。
参照图7，示出了本发明一个实施例的数据处理装置的框图。该数据处理装置包括：
接收模块601，用于接收指标计算请求，其中，所述指标计算请求包括目标时间范围；
识别模块602，用于响应于所述指标计算请求，识别与目标时间范围匹配的目标时间分区；
确定模块603，用于在预先生成的医疗结算数据的候选索引中，确定每个所述目标时间分区分别对应的目标索引；
第一计算模块604，用于对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作指标计算，生成每个所述目标时间分区的子指标结果；
第二计算模块605，用于在所述目标时间分区的数量为多个的情况下，将多个所述目标时间分区的多个所述子指标结果进行累加，生成所述目标时间范围的目标指标结果；
其中，所述候选索引包括预先对所述医疗结算数据按照时间分区所创建的索引，所述目标分区数据包括所述医疗结算数据中结算时间在所述目标时间分区的时间范围内的数据。
可选地，所述装置还包括：
第一提取模块，用于提取所述医疗结算数据的所述结算时间；
第二提取模块，用于基于所述结算时间，按照时间分区对所述医疗结算数据进行数据提取，生成与不同时间分区匹配的多组分区数据，其中，在所述医疗结算数据的数据量大于预设阈值的情况下，所述时间分区的时间单位的时长小于年的时长；
生成模块，用于基于所述结算时间，按照所述时间分区创建索引，生成与不同时间分区匹配的多个候选索引；
存储模块，用于对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据存储至匹配于所述第一时间分区的候选索引的存储空间中，其中，所述第一时间分区为所述不同时间分区中的每个时间分区。
可选地，所述存储模块包括：
分片子模块，用于对于所述多组分区数据，对每组分区数据作分片处理，生成每组分区数据的分片数据；
创建副本子模块，用于对所述每组分区数据中的分片数据生成副本数据；
存储子模块，用于对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据存储至匹配于所述第一时间分区的候选索引的存储空间中，其中，每组分区数据中同一分片的所述分片数据和所述副本数据存储在不同的服务器中。
可选地，所述多组分区数据中的每组所述分区数据包括结算主单数据和与所述结算主单数据关联的结算明细数据；
所述装置还包括：
关联模块，用于对于所述每组分区数据中的结算明细数据，在与所述结算主单数据关联的所述结算明细数据的数量为多条的情况下，将所述结算主单数据冗余地关联至每条所述结算明细数据，生成宽表数据；
所述存储模块，还用于对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据中的所述宽表数据存储至匹配于所述第一时间分区的候选索引的存储空间中。
可选地，所述第一计算模块604包括：
获取子模块，用于根据所述指标计算请求中所请求计算的目标指标，在用于计算指标的预设表达式中获取用于计算所述目标指标的目标表达式，以及在预设的与不同指标关联的多个指标参数表中获取与所述目标指标关联的目标参数表；
替换子模块，用于采用所述目标参数表中每个参数的参数值，对所述目标表达式中的相应参数进行替换，生成所述目标指标的目标公式；
第一计算子模块，用于采用所述目标公式，对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作所述目标指标的计算，生成每个所述目标时间分区的子指标结果。
可选地，所述预设表达式包括相互关联的主表达式和至少一个子表达式，其中，所述主表达式包括至少一个子表达式之间的计算逻辑关系，所述指标参数表包括不同指标的每个子表达式的参数表；
所述获取子模块，还用于根据所述指标计算请求中所请求计算的目标指标，在用于计算指标的预设表达式中获取用于计算所述目标指标的目标主表达式和至少一个目标子表达式，以及在预设的与不同指标关联的多个指标参数表中，获取与所述目标指标关联的所述至少一个目标子表达式的至少一个目标参数表；
所述替换子模块，还用于对所述目标子表达式中的参数进行排序，依据所述目标参数表中的参数序号和参数值，对所述目标子表达式中排列在相应位置的参数进行所述参数值的替换，生成所述目标指标的目标公式，所述目标公式包括参数被参数值替换的目标子表达式以及表达了至少一个目标子表达式的计算逻辑关系的目标主表达式。
可选地，所述指标计算请求还包括所述医疗结算数据的目标属性信息；
所述第一计算模块604包括：
筛选子模块，用于按照所述目标属性信息，对预先存储至每个所述目标索引的存储空间中的目标分区数据进行数据筛选；
分组子模块，用于对经过所述数据筛选后的每个目标分区数据，按照不同医院进行分组，生成不同医院的经过所述数据筛选后的每个目标分区数据；
第二计算子模块，用于按照医院，对经过所述数据筛选后的每个目标分区数据分别作指标计算，生成每个医院的所述目标时间分区的子指标结果；
所述第二计算模块605，还用于在所述目标时间分区的数量为多个的情况下，将同一医院的多个所述目标时间分区的多个所述子指标结果进行累加，生成每个医院的所述目标时间范围的目标指标结果。
在本发明实施例中，在对医疗指标进行计算时，预先可以按照时间分区来对医疗结算数据进行划分，以及按照时间分区来创建索引，并将划分的分区数据存储至对应时间分区的索引的存储空间中，那么在计算医疗指标时，则可以基于指标计算请求中的目标时间范围，来确定目标时间分区，从而按照目标时间分区来查找对应时间分区的目标索引，并在该时间分区的目标索引中获取所需要的目标分区数据进行指标计算，然后，将多个目标时间分区的指标计算结果进行累加，得到医疗指标的目标指标结果。在这个过程中，按照时间分区，来查找对应索引中的目标分区数据，来计算指标，可以对多个时间分区的目标分区数据进行并行处理，不仅可以快速查找到所需要计算的医疗结算数据，而且可以提升数据处理速度，相比于传统计算中采用大数据平台，从海量数据中读取所需数据计算指标，可以降低计算延迟，加快处理速度；而且，医疗结算数据按照时间分区存储到对应的索引的存储空间中，实现了数据的物理化存储，无需加载到内存中进行存储，可以降低对计算指标的服务器的内存的要求；另外，医疗结算数据通过索引物理化存储到各时间分区的索引的存储空间中，占用磁盘空间较少，相比于大数据平台的传统方案，对服务器的数量要求较低。
本发明实施例中的数据处理装置可以是装置，也可以是终端中的部件、集成电路、或芯片。该装置可以是移动电子设备，也可以为非移动电子设备。示例性的，移动电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personaldigital assistant，PDA)等，非移动电子设备可以为服务器、网络附属存储器(NetworkAttached Storage，NAS)、个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本发明实施例不作具体限定。
本发明实施例中的数据处理装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为IOS操作系统，还可以为其他可能的操作系统，本发明实施例不作具体限定。
本发明实施例提供的数据处理装置能够实现上述方法实施例实现的各个过程，为避免重复，这里不再赘述。
可选地，如图8所示，本发明实施例还提供一种电子设备2000，包括处理器2002，存储器2001，存储在存储器2001上并可在所述处理器2002上运行的程序或指令，该程序或指令被处理器2002执行时实现上述数据处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
需要注意的是，本发明实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。
本发明实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述数据处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。
本发明实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述数据处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
应理解，本发明实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本发明实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本发明的保护之内。
Claims (9)
1.一种数据处理方法，其特征在于，所述方法包括：
接收指标计算请求，其中，所述指标计算请求包括目标时间范围；
响应于所述指标计算请求，识别与目标时间范围匹配的目标时间分区；
在预先生成的医疗结算数据的候选索引中，确定每个所述目标时间分区分别对应的目标索引；
对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作指标计算，生成每个所述目标时间分区的子指标结果；
在所述目标时间分区的数量为多个的情况下，将多个所述目标时间分区的多个所述子指标结果进行累加，生成所述目标时间范围的目标指标结果；
其中，所述候选索引包括预先对所述医疗结算数据按照时间分区所创建的索引，所述目标分区数据包括所述医疗结算数据中结算时间在所述目标时间分区的时间范围内的数据；
所述对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作指标计算，生成每个所述目标时间分区的子指标结果，包括：
根据所述指标计算请求中所请求计算的目标指标，在用于计算指标的预设表达式中获取用于计算所述目标指标的目标表达式，以及在预设的与不同指标关联的多个指标参数表中获取与所述目标指标关联的目标参数表；
采用所述目标参数表中每个参数的参数值，对所述目标表达式中的相应参数进行替换，生成所述目标指标的目标公式；
采用所述目标公式，对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作所述目标指标的计算，生成每个所述目标时间分区的子指标结果；
所述预设表达式包括相互关联的主表达式和至少一个子表达式，其中，所述主表达式表示各个子表达式的计算逻辑关系，所述指标参数表包括不同指标的每个子表达式的参数表。
2.根据权利要求1所述的方法，其特征在于，所述接收指标计算请求之前，所述方法还包括：
提取所述医疗结算数据的所述结算时间；
基于所述结算时间，按照时间分区对所述医疗结算数据进行数据提取，生成与不同时间分区匹配的多组分区数据，其中，在所述医疗结算数据的数据量大于预设阈值的情况下，所述时间分区的时间单位的时长小于年的时长；
基于所述结算时间，按照所述时间分区创建索引，生成与不同时间分区匹配的多个候选索引；
对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据存储至匹配于所述第一时间分区的候选索引的存储空间中，其中，所述第一时间分区为所述不同时间分区中的每个时间分区。
3.根据权利要求2所述的方法，其特征在于，所述对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据存储至匹配于所述第一时间分区的候选索引的存储空间中，包括：
对于所述多组分区数据，对每组分区数据作分片处理，生成每组分区数据的分片数据；
对所述每组分区数据中的分片数据生成副本数据；
对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据存储至匹配于所述第一时间分区的候选索引的存储空间中，其中，每组分区数据中同一分片的所述分片数据和所述副本数据存储在不同的服务器中。
4.根据权利要求2所述的方法，其特征在于，所述多组分区数据中的每组所述分区数据包括结算主单数据和与所述结算主单数据关联的结算明细数据；
所述基于所述结算时间，按照时间分区对所述医疗结算数据进行数据提取，生成与不同时间分区匹配的多组分区数据之后，所述对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据存储至匹配于所述第一时间分区的候选索引的存储空间中之前，所述方法还包括：
对于所述每组分区数据中的结算明细数据，在与所述结算主单数据关联的所述结算明细数据的数量为多条的情况下，将所述结算主单数据冗余地关联至每条所述结算明细数据，生成宽表数据；
所述对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据存储至匹配于所述第一时间分区的候选索引的存储空间中，包括：
对于所述多组分区数据和所述多个候选索引，将匹配于第一时间分区的分区数据中的所述宽表数据存储至匹配于所述第一时间分区的候选索引的存储空间中；
其中，所述医疗结算数据的数据量包括所述结算明细数据的数据量。
5.根据权利要求1所述的方法，其特征在于，所述根据所述指标计算请求中所请求计算的目标指标，在用于计算指标的预设表达式中获取用于计算所述目标指标的目标表达式，以及在预设的与不同指标关联的多个指标参数表中获取与所述目标指标关联的目标参数表，包括：
根据所述指标计算请求中所请求计算的目标指标，在用于计算指标的预设表达式中获取用于计算所述目标指标的目标主表达式和至少一个目标子表达式，以及在预设的与不同指标关联的多个指标参数表中，获取与所述目标指标关联的所述至少一个目标子表达式的至少一个目标参数表；
所述采用所述目标参数表中每个参数的参数值，对所述目标表达式中的相应参数进行替换，生成所述目标指标的目标公式，包括：
对所述目标子表达式中的参数进行排序，依据所述目标参数表中的参数序号和参数值，对所述目标子表达式中排列在相应位置的参数进行所述参数值的替换，生成所述目标指标的目标公式，所述目标公式包括参数被参数值替换的目标子表达式以及表达了至少一个目标子表达式的计算逻辑关系的目标主表达式。
6.根据权利要求1所述的方法，其特征在于，所述指标计算请求还包括所述医疗结算数据的目标属性信息；
所述对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作指标计算，生成每个所述目标时间分区的子指标结果，包括：
按照所述目标属性信息，对预先存储至每个所述目标索引的存储空间中的目标分区数据进行数据筛选；
对经过所述数据筛选后的每个目标分区数据，按照不同医院进行分组，生成不同医院的经过所述数据筛选后的每个目标分区数据；
按照医院，对经过所述数据筛选后的每个目标分区数据分别作指标计算，生成每个医院的所述目标时间分区的子指标结果；
所述在所述目标时间分区的数量为多个的情况下，将多个所述目标时间分区的多个所述子指标结果进行累加，生成所述目标时间范围的目标指标结果，包括：
在所述目标时间分区的数量为多个的情况下，将同一医院的多个所述目标时间分区的多个所述子指标结果进行累加，生成每个医院的所述目标时间范围的目标指标结果。
7.一种数据处理装置，其特征在于，所述装置包括：
接收模块，用于接收指标计算请求，其中，所述指标计算请求包括目标时间范围；
识别模块，用于响应于所述指标计算请求，识别与目标时间范围匹配的目标时间分区；
确定模块，用于在预先生成的医疗结算数据的候选索引中，确定每个所述目标时间分区分别对应的目标索引；
第一计算模块，用于对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作指标计算，生成每个所述目标时间分区的子指标结果；
第二计算模块，用于在所述目标时间分区的数量为多个的情况下，将多个所述目标时间分区的多个所述子指标结果进行累加，生成所述目标时间范围的目标指标结果；
其中，所述候选索引包括预先对所述医疗结算数据按照时间分区所创建的索引，所述目标分区数据包括所述医疗结算数据中结算时间在所述目标时间分区的时间范围内的数据；
所述第一计算模块，具体用于：根据所述指标计算请求中所请求计算的目标指标，在用于计算指标的预设表达式中获取用于计算所述目标指标的目标表达式，以及在预设的与不同指标关联的多个指标参数表中获取与所述目标指标关联的目标参数表；采用所述目标参数表中每个参数的参数值，对所述目标表达式中的相应参数进行替换，生成所述目标指标的目标公式；采用所述目标公式，对预先存储至每个所述目标索引的存储空间中的目标分区数据分别作所述目标指标的计算，生成每个所述目标时间分区的子指标结果；
所述预设表达式包括相互关联的主表达式和至少一个子表达式，其中，所述主表达式表示各个子表达式的计算逻辑关系，所述指标参数表包括不同指标的每个子表达式的参数表。
8.一种电子设备，其特征在于，包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1至6中任意一项所述的数据处理方法的步骤。
9.一种可读存储介质，其特征在于，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如权利要求1至6中任意一项所述的数据处理方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110754395.4A CN113505172B (zh) | 2021-07-02 | 2021-07-02 | 数据处理方法、装置、电子设备及可读存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110754395.4A CN113505172B (zh) | 2021-07-02 | 2021-07-02 | 数据处理方法、装置、电子设备及可读存储介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113505172A CN113505172A (zh) | 2021-10-15 |
| CN113505172B true CN113505172B (zh) | 2023-10-24 |
Family
ID=78011538
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110754395.4A Active CN113505172B (zh) | 2021-07-02 | 2021-07-02 | 数据处理方法、装置、电子设备及可读存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113505172B (zh) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114490845A (zh) * | 2021-12-31 | 2022-05-13 | 珠海华发集团科技研究院有限公司 | 异构算法迁移同化的方法、装置及设备 |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107783980A (zh) * | 2016-08-24 | 2018-03-09 | 阿里巴巴集团控股有限公司 | 索引数据生成及数据查询方法及装置、存储和查询系统 |
| CN108256088A (zh) * | 2018-01-23 | 2018-07-06 | 清华大学 | 一种基于键值数据库的时序数据的存储方法及系统 |
| EP3483685A1 (en) * | 2017-11-10 | 2019-05-15 | ABB Schweiz AG | Data processing device and method for performing problem diagnosis in a production system with a plurality of robots |
| CN111276231A (zh) * | 2020-02-27 | 2020-06-12 | 平安医疗健康管理股份有限公司 | 医疗数据监控方法、装置、计算机设备和存储介质 |
| CN111858706A (zh) * | 2020-07-02 | 2020-10-30 | 中国建设银行股份有限公司 | 一种数据处理的方法和装置 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111259089B (zh) * | 2020-01-14 | 2023-03-21 | 平安医疗健康管理股份有限公司 | 医保数据处理方法、装置、计算机设备和存储介质 |
-
2021
- 2021-07-02 CN CN202110754395.4A patent/CN113505172B/zh active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107783980A (zh) * | 2016-08-24 | 2018-03-09 | 阿里巴巴集团控股有限公司 | 索引数据生成及数据查询方法及装置、存储和查询系统 |
| EP3483685A1 (en) * | 2017-11-10 | 2019-05-15 | ABB Schweiz AG | Data processing device and method for performing problem diagnosis in a production system with a plurality of robots |
| CN108256088A (zh) * | 2018-01-23 | 2018-07-06 | 清华大学 | 一种基于键值数据库的时序数据的存储方法及系统 |
| CN111276231A (zh) * | 2020-02-27 | 2020-06-12 | 平安医疗健康管理股份有限公司 | 医疗数据监控方法、装置、计算机设备和存储介质 |
| CN111858706A (zh) * | 2020-07-02 | 2020-10-30 | 中国建设银行股份有限公司 | 一种数据处理的方法和装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113505172A (zh) | 2021-10-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9798831B2 (en) | Processing data in a MapReduce framework | |
| US8943059B2 (en) | Systems and methods for merging source records in accordance with survivorship rules | |
| US9858326B2 (en) | Distributed data warehouse | |
| CN107408114B (zh) | 基于事务访问模式识别联结关系 | |
| CN103593418B (zh) | 一种面向大数据的分布式主题发现方法及系统 | |
| CN113836131B (zh) | 一种大数据清洗方法、装置、计算机设备及存储介质 | |
| CN112000773B (zh) | 基于搜索引擎技术的数据关联关系挖掘方法及应用 | |
| CA2919878C (en) | Refining search query results | |
| CN103139256B (zh) | 一种多租户网络舆情监控方法及系统 | |
| KR20160075971A (ko) | 공공민원 데이터 서비스를 위한 빅 데이터 관리시스템 | |
| CN103646078B (zh) | 一种实现互联网宣传监测目标评估的方法及装置 | |
| CN106055621A (zh) | 一种日志检索方法及装置 | |
| KR20130049111A (ko) | 분산 처리를 이용한 포렌식 인덱스 방법 및 장치 | |
| Deshpande et al. | Efficient reverse skyline retrieval with arbitrary non-metric similarity measures | |
| CN113407785B (zh) | 一种基于分布式储存系统的数据处理方法和系统 | |
| CN105426449A (zh) | 海量数据查询方法和装置、服务器 | |
| CN105095436A (zh) | 数据源数据自动建模方法 | |
| CN113505172B (zh) | 数据处理方法、装置、电子设备及可读存储介质 | |
| JP2017537398A (ja) | 一組の構造化データタームからの非構造化検索クエリの生成 | |
| CN111680072B (zh) | 基于社交信息数据的划分系统及方法 | |
| CN113505117A (zh) | 基于数据指标的数据质量评估方法、装置、设备及介质 | |
| Huang et al. | Design a batched information retrieval system based on a concept-lattice-like structure | |
| WO2016206395A1 (zh) | 周报信息处理方法及装置 | |
| CN113312410B (zh) | 数据图谱的构建方法、数据查询方法及终端设备 | |
| CN114706625A (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 |