CN114153620B - Hudi运行环境资源优化分配方法及装置 - Google Patents

Hudi运行环境资源优化分配方法及装置 Download PDF

Info

Publication number
CN114153620B
CN114153620B CN202210117140.1A CN202210117140A CN114153620B CN 114153620 B CN114153620 B CN 114153620B CN 202210117140 A CN202210117140 A CN 202210117140A CN 114153620 B CN114153620 B CN 114153620B
Authority
CN
China
Prior art keywords
hudi
task
data
medical data
incremental
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
CN202210117140.1A
Other languages
English (en)
Other versions
CN114153620A (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 CN202210117140.1A priority Critical patent/CN114153620B/zh
Publication of CN114153620A publication Critical patent/CN114153620A/zh
Application granted granted Critical
Publication of CN114153620B publication Critical patent/CN114153620B/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
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

本申请提供了一种Hudi运行环境资源优化分配方法及装置，包括：启动预设数量的计算引擎会话Spark Session，并对各Spark Session按对应的资源大小进行分类，得到至少两个Spark Session集合，并确定每个Spark Session集合对应的任务数据量范围；若医院的业务系统有增量医疗数据产生，则获取增量医疗数据对应的Hudi表任务所对应的数据量大小，并将Hudi表任务加入任务执行队列；在Hudi表任务处于任务执行队列的头部时，基于Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标Spark Session，并利用目标Spark Session执行Hudi表任务，以将增量医疗数据添加至对应的Hudi表中。该方案节约了资源等待时间，同时能够为不同数据量大小的Hudi表任务匹配合适的目标Spark Session，提高了医疗数据存储的实时性。

Description

Hudi运行环境资源优化分配方法及装置
技术领域
本申请涉及计算机技术领域，具体而言，本申请涉及一种Hudi运行环境资源优化分配方法及装置。
背景技术
随着信息技术的发展，越来越多的医院采用Hudi技术进行医疗数据的存储，为了保证医院患者的正常就诊和治疗，必须保证各业务系统的数据能够实时存储。由于Hudi是基于spark运行的，在将医院的各业务系统的增量数据不断存储至对应的Hudi表中时，需要在每次进行增量数据存储时启动对应的Spark Session，目前的方案大多是根据产生增量数据的业务系统的类型来为对应的Spark Session的分配资源（CPU资源、内存资源等）。而医院对接有多种业务系统，例如：HIS（Hospital Information System，医院信息系统），LIS（Laboratory Information Management System，实验室信息管理系统），RIS（RadiographyInformation System，放射科信息系统）等，每种业务系统的库中动辄上百张表（还不包括从其他医院承接过来的业务系统的表），这些表的数据量差异巨大，例如：医嘱执行表为事实表，其数据量会很大，而科室表是维度表，其数据量相对来说就小很多。如果分配资源较小，会导致Hudi 性能低下，数据存储实时性较低，如果分配资源过大，使得每个SparkSession的进程使用资源较大，Spark Session的进程并发数较小，同样会导致数据存储实时性较低。
同时，Spark Session运行需要进行比较复杂的资源申请，资源申请后需要做容器和服务的初始化，初始化过程速度很慢，会有很长的资源等待时间，频繁的启动停止SparkSession不能让资源高效运行，进而导致在医院的业务系统产生的增量医疗数据较多时，医疗数据存储的实时性较差。
发明内容
本申请的目的旨在至少能解决上述的技术缺陷之一，本申请实施例所提供的技术方案如下：
第一方面，本申请实施例提供了一种Hudi运行环境资源优化分配方法，包括：
在进行医疗数据存储前，启动预设数量的计算引擎会话Spark Session，并对各Spark Session按对应的资源大小进行分类，得到至少两个Spark Session集合，并确定每个Spark Session集合对应的任务数据量范围；
在医院的业务系统有增量医疗数据产生时，将增量医疗数据写入卡夫卡kafka的第一topic，通过流式计算引擎flink消费第一topic得到增量医疗数据，并将增量医疗数据存储至分布式文件存储系统hdfs，并将增量医疗数据的数据表标识和在hdfs中的存储路径写入kafka的第二topic；
通过flink消费第二topic，获取增量医疗数据对应的Hudi表任务所对应的数据量大小，并获取Hudi表任务的优先级得分，基于优先级得分将Hudi表任务加入任务执行队列，Hudi表任务用于指示存储增量医疗数据至对应的Hudi表；
在Hudi表任务处于任务执行队列的头部时，基于Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标Spark Session，并利用目标SparkSession执行Hudi表任务，以将增量医疗数据添加至对应的Hudi表中。
在本申请的一种可选实施例中，通过flink消费第二topic，获取增量医疗数据对应的Hudi表任务所对应的数据量大小，包括：
通过flink消费第二topic得到增量医疗数据的数据表标识和存储路径，基于存储路径获取增量医疗数据，并基于数据表标识确定增量医疗数据对应的目标Hudi表；
将增量医疗数据的数据量大小和目标Hudi表中包含的数据量大小之和，作为Hudi表任务对应的数据量大小。
在本申请的一种可选实施例中，基于优先级得分将Hudi表任务加入任务执行队列，包括：
若任务执行队列中不包含增量医疗数据的数据表标识对应的其他Hudi表任务，则获取Hudi表任务的优先级得分，并基于Hudi表任务的优先级得分与任务执行队列中各Hudi表任务的优先级得分的大小关系，将Hudi表任务添加至任务执行队列；
若任务执行列表中包含增量医疗数据的数据表标识对应的其他Hudi表任务，则将Hudi表任务与其他Hudi表任务合并，并获取合并后的Hudi表的优先级得分，再基于合并后的Hudi表任务的优先级得分与任务执行队列中各Hudi表任务的优先级得分的大小关系，将合并后的Hudi表任务添加至任务执行队列。
在本申请的一种可选实施例中，获取Hudi表任务的优先级得分：
获取Hudi表任务的延迟时间，并获取该Hudi表任务对应的增量医疗数据的数据表标识和数据量大小；
基于延迟时间获取第一优先级得分，基于数据表标识确定增量医疗数据对应的数据表类型，并基于数据表类型获取第二优先级得分，基于数据量大小获取第三优先级得分；
基于第一优先级得分、第二优先级得分以及第三优先级得分，获取该Hudi表任务的优先级得分。
在本申请的一种可选实施例中，基于Hudi表任务的数据量大小和各SparkSession集合对应的任务数据量范围，确定出目标Spark Session，包括：
将Hudi表任务的数据量大小满足的任务数据量范围对应的Spark Session集合确定为目标Spark Session集合；
将目标Spark Session集合中任一空闲Spark Session，确定为目标SparkSession。
在本申请的一种可选实施例中，该方法还包括：
若目标Spark Session集合没有空闲Spark Session，则将任务数据量范围的下限值大于Hudi表任务的数据量大小的Spark Session集合确定为候补Spark Session集合；
将候补Spark Session集合中任一空闲Spark Session，确定为目标SparkSession。
在本申请的一种可选实施例中，方法还包括：
若目标Spark Session集合和候补Spark Session集合都没有空闲SparkSession，则延迟执行Hudi表任务。
第二方面，本申请实施例提供了一种Hudi运行环境资源优化分配装置，包括：
Spark Session启动模块，用于在进行医疗数据存储前，启动预设数量的SparkSession，并对各Spark Session按对应的资源大小进行分类，得到至少两个Spark Session集合，并确定每个Spark Session集合对应的任务数据量范围；
增量数据流上处理模块，用于在医院的业务系统有增量医疗数据产生时，将增量医疗数据写入卡夫卡kafka的第一topic，通过流式计算引擎flink消费第一topic得到增量医疗数据，并将增量医疗数据存储至分布式文件存储系统hdfs，并将增量医疗数据的数据表标识和在hdfs中的存储路径写入kafka的第二topic；
Hudi表任务加入模块，用于通过flink消费第二topic，获取增量医疗数据对应的Hudi表任务所对应的数据量大小，并获取Hudi表任务的优先级得分，基于优先级得分将Hudi表任务加入任务执行队列，Hudi表任务用于指示存储增量医疗数据至对应的Hudi表；
Hudi表任务执行模块，用于在Hudi表任务处于任务执行队列的头部时，基于Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标SparkSession，并利用目标Spark Session执行Hudi表任务，以将增量医疗数据添加至对应的Hudi表中。
在本申请的一种可选实施例中，Hudi表任务加入模块具体用于：
通过flink消费第二topic得到增量医疗数据的数据表标识和存储路径，基于存储路径获取增量医疗数据，并基于数据表标识确定增量医疗数据对应的目标Hudi表；
将增量医疗数据的数据量大小和目标Hudi表中包含的数据量大小之和，作为Hudi表任务对应的数据量大小。
在本申请的一种可选实施例中，Hudi表任务加入模块具体用于：
若任务执行队列中不包含增量医疗数据的数据表标识对应的其他Hudi表任务，则获取Hudi表任务的优先级得分，并基于Hudi表任务的优先级得分与任务执行队列中各Hudi表任务的优先级得分的大小关系，将Hudi表任务添加至任务执行队列；
若任务执行列表中包含增量医疗数据的数据表标识对应的其他Hudi表任务，则将Hudi表任务与其他Hudi表任务合并，并获取合并后的Hudi表的优先级得分，再基于合并后的Hudi表任务的优先级得分与任务执行队列中各Hudi表任务的优先级得分的大小关系，将合并后的Hudi表任务添加至任务执行队列。
在本申请的一种可选实施例中， Hudi表任务加入模块进一步用于：
获取Hudi表任务的延迟时间，并获取该Hudi表任务对应的增量医疗数据的数据表标识和数据量大小；
基于延迟时间获取第一优先级得分，基于数据表标识确定增量医疗数据对应的数据表类型，并基于数据表类型获取第二优先级得分，基于数据量大小获取第三优先级得分；
基于第一优先级得分、第二优先级得分以及第三优先级得分，获取该Hudi表任务的优先级得分。
在本申请的一种可选实施例中，Hudi表任务执行模块具体用于：
将Hudi表任务的数据量大小满足的任务数据量范围对应的Spark Session集合确定为目标Spark Session集合；
将目标Spark Session集合中任一空闲Spark Session，确定为目标SparkSession。
在本申请的一种可选实施例中，Hudi表任务执行模块进一步用于：
若目标Spark Session集合没有空闲Spark Session，则将任务数据量范围的下限值大于Hudi表任务的数据量大小的Spark Session集合确定为候补Spark Session集合；
将候补Spark Session集合中任一空闲Spark Session，确定为目标SparkSession。
在本申请的一种可选实施例中，Hudi表任务执行模块进一步用于：
若目标Spark Session集合和候补Spark Session集合都没有空闲SparkSession，则延迟执行Hudi表任务。
第三方面，本申请实施例提供了一种电子设备，包括存储器和处理器；
存储器中存储有计算机程序；
处理器，用于执行计算机程序以实现第一方面实施例或第一方面任一可选实施例中所提供的方法。
第四方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现第一方面实施例或第一方面任一可选实施例中所提供的方法。
第五方面，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行时实现第一方面实施例或第一方面任一可选实施例中所提供的方法。
本申请提供的技术方案带来的有益效果是：
通过预先启动多个执行Hudi表任务的Spark Session，然后按资源大小将这些Spark Session分为多个Spark Session集合，且每个Spark Session集合对应一个任务数据量范围，当医院的业务系统有增量医疗数据产生时，将增量医疗数据写入kafka并结合flink流上处理实时获取增量医疗数据对应的Hudi表任务的数据量大小，根据该增量医疗数据对应的Hudi表任务所对应的数据量大小以及各Spark Session集合的任务数据量范围，确定出执行该Hudi表任务的目标Spark Session，从而采用该目标Spark Session执行该Hudi表任务，进而将增量医疗数据存储至对应的Hudi表中。该方案在进行医疗数据存储时，一方面，由于事先启动了多个Spark Session，按资源大小对Spark Session进行了分类，不用频繁的申请资源启动或停止Spark Session，节约了资源等待时间，提高了医疗数据存储的实时性；第二方面，能够为不同数据量大小的Hudi表任务匹配合适的目标SparkSession，提高了资源分配的准确性，进而提高了数据存储的实时性；第三方面，将增量医疗数据写入kafka，并结合flink进行相应的流上处理，可以保证增量医疗数据被写入后马上进入医疗数据存储处理，进一步提高了数据存储的实时性。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。
图1为本申请实施例提供的一种Hudi运行环境资源优化分配方案实施所依赖的系统的架构图；
图2为本申请实施例提供的一种Hudi运行环境资源优化分配方法的流程图；
图3为本申请实施例的一个示例中Hudi运行环境资源优化分配过程的示意图；
图4为本申请实施例提供的一种Hudi运行环境资源优化分配装置的结构框图；
图5为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。
本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
针对上述问题，本申请实施例提供了一种Hudi运行环境资源优化分配方法、装置及计算机可读存储介质。下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
首先对本申请涉及的几个名词进行介绍和解释：
Hudi（胡迪）：摄取和管理大型分析数据集的存储系统。
Spark（计算引擎）：全称Apache Spark，是专为大规模数据处理而设计的快速通用的计算引擎。Spark是UC Berkeley AMP lab (加州大学伯克利分校的AMP实验室)所开源的类Hadoop MapReduce的通用并行框架，Spark，拥有Hadoop MapReduce所具有的优点；但不同于MapReduce的是——Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。
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的运行时本身也支持迭代算法的执行。
图1为本申请实施例提供的一种Hudi运行环境资源优化分配实施所依赖的系统的架构图，该系统可以包括协调器模块101和Hudi合并模块102，该两个模块通过Netty（网络通讯框架）进行网络通信。其中，协调器模块101首先用于启动多个Spark Session，然后在有增量医疗数据产生时，将其对应的事件消息转换为Hudi表任务，并为Hudi表任务匹配合适的目标Spark Session。Hudi合并模块102利用协调器模块101确定出的目标SparkSession执行该Hudi表任务，从而将增量医疗数据存储至对应的Hudi表中。对于协调器模块101和Hudi合并模块102中的具体处理过程将在后文进行详细描述。
图2为本申请实施例提供的一种Hudi运行环境资源优化分配方法的流程图，该方法的执行主体可以是如图1中所示的协调器模块，如图2所示，该方法可以包括：
步骤S201，在进行医疗数据存储前，启动预设数量的Spark Session，并对各SparkSession按对应的资源大小进行分类，得到至少两个Spark Session集合，并确定每个SparkSession集合对应的任务数据量范围。
其中，在对某一医院按本申请实施例提供的方案进行Hudi运行环境资源优化分配前，可以首先分析该医院的各业务系统中不同表对应的目标hudi表的数据量，并基于该数据量确定出各数据量被处理所要申请的各资源大小。然后根据所要申请的各资源大小分别启动对应的Spark Session，得到预设数量的Spark Session。通过上述操作，可以使得各业务系统中不同表对应的增量医疗数据，都能从预设数量的Spark Session匹配到合适的Spark Session。
具体地，在图1所示的系统启动时，协调器模块101会启动预设数量的SparkSession，具体来说，协调器获取对每个Spark Session的配置信息，并基于配置信息为每个Spark Session申请不同大小的资源，并监控每个Spark Session的运行情况，即确定每个Spark Session是否处于空闲状态。可以理解的是，预设数量可以由用户根据实际需求进行设定，且每个Spark Session的配置信息可以由用户根据实际需求进行设定。
进一步地，在启动了多个Spark Session后，需要对这多个Spark Session按对应的资源大小进行分类，每个分类构成一个Spark Session集合，且为每个Spark Session集合确定一个任务数据量范围，即该Spark Session集合中的Spark Session能够执行的Hudi表任务对应的数据量的范围，换言之，如果Hudi表任务对应的数据量大小处于某一SparkSession集合的任务数据量范围，那么该Spark Session集合中任一Spark Session都可以执行这一Hudi表任务。其中，对多个Spark Session按对应的资源大小进行分类，具体分成几类得到多少个集合，也可以根据实际需求进行设定。
其中，确定每个Spark Session集合对应的任务数据量范围可以根据该SparkSession集合中各Spark Session申请到的资源大小确定，该任务数据量范围的下限与该Spark Session集合中最小资源大小正相关，该任务数据量范围的上限与该Spark Session集合中最大资源大小正相关。基于以上原则，确定出各Spark Session集合的任务数据量范围，用于后续为Hudi表任务匹配合适的Spark Session。
步骤S202，在医院的业务系统有增量医疗数据产生时，将增量医疗数据写入卡夫卡kafka的第一主题topic，通过流式计算引擎flink消费第一topic得到增量医疗数据，并将增量医疗数据存储至分布式文件存储系统hdfs，并将增量医疗数据的数据表标识和在hdfs中的存储路径写入kafka的第二topic。
具体地，当医院的业务系统有增量医疗数据产生时，会将增量医疗数据写入到kafka的第一topic中。然后，再通过flink消费kafka的第一topic得到这些增量医疗数据，并将这些增量医疗数据存储至hdfs（Hadoop Distributed File System，分布式文件系统）（需要说明的是，此时这些增量医疗数据并不是以Hudi表的形式存储至hdfs中，可以理解为临时存储至hdfs中），同时将该增量医疗数据的数据表标识和其在hdfs的存储路径一起写入kafka的第二topic。
需要说明的是，将增量医疗数据写入kafka，并结合flink进行相应的流上处理，可以保证增量医疗数据被写入后马上进入本申请实施例中的数据存储处理，进而进一步提高本申请方案中增量数据存储的实时性。具体来说，本申请实施例中分别两次写入kafka，并两次通过flink对kafka对应主题进行消费。如前所述，第一次是将增量医疗数据整体写入kafka的第一topic，通过flink消费可以实时得到该增量医疗数据。第二次是将增量医疗数据的数据表标识和存储路径写入kafka的第二topic，通过flink消费可以实时得到数据表标识和存储路径，进而按后文描述的方式获取增量医疗数据的数据量大小。总而言之，从这两次写入kafak和flink流上消费进一步保证了数据存储过程的实时性。
步骤S203，通过flink消费所述第二topic，获取增量医疗数据对应的Hudi表任务所对应的数据量大小，并将Hudi表任务加入任务执行队列，Hudi表任务用于指示存储增量医疗数据至对应的Hudi表。
其中，增量医疗数据对应的Hudi表任务指的是将增量医疗数据存储至对应的Hudi表的任务。由于在进行增量医疗数据存储时，需要将增量医疗数据存储至对应的目标Hudi表中，因此后续存储过程中可以理解为对增量医疗数据和该目标Hudi表中已经存储的医疗数据进行合并处理，那么，该Hudi表任务对应的数据量大小包括增量医疗数据的大小和该增量医疗数据对应的目标Hudi表中已经存储医疗数据的数据量大小。其中，目标Hudi表就是该增量医疗数据所要存储至的Hudi表。
具体地，若医院的业务系统有增量医疗数据产生，则对于每一增量医疗数据，获取该增量医疗数据的数据量大小、以及其对应的目标Hudi表包含的已存储的医疗数据的数据量大小，将这两个数据量大小求和即刻得到该增量医疗数据对应的Hudi表任务的数据量大小。然后将该Hudi表任务加入任务执行队列中，以供后续执行该Hudi表任务。
步骤S204，在Hudi表任务处于任务执行队列的头部时，基于Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标Spark Session，并利用目标Spark Session执行Hudi表任务，以将增量医疗数据添加至对应的Hudi表中。
其中，在任务执行队列中，Hudi合并模块102每次从任务执行队列的头部获取Hudi表任务来执行。那么，在Hudi合并模块102执行Hudi表任务之前，协调器模块101需要先为Hudi表任务分配合适的Spark Session，即为Hudi表任务确定目标Spark Session。
具体地，在Hudi表任务处于任务执行队列的头部时，即该Hudi表任务马上要被Hudi合并模块102执行，协调器模块根101据上一步骤计算的该Hudi表任务对应的数据量大小，从各Spark Session集合对应中确定出一个目标Spark Session。具体来说，将的该Hudi表任务对应的数据量大小与各Spark Session集合的任务数据量范围进行匹配，然后根据匹配结果，确定出目标Spark Session。
可以理解的是，本申请的方案通过Hudi表任务对应的数据量来匹配与之对应的Spark Session集合，并从中确定出目标Spark Session，确定的目标Spark Session资源量更准确。
然后，协调器模块101将确定出的目标Spark Session告知Hudi合并模块102，Hudi合并模块102利用已经启动的该目标Spark Session执行该Hudi表任务，进而将该Hudi表任务对应的增量医疗数据存储至对应的Hudi表，即存储至其对应的目标Hudi表。
本申请提供的方案，通过预先启动多个执行Hudi表任务的Spark Session，然后按资源大小将这些Spark Session分为多个Spark Session集合，且每个Spark Session集合对应一个任务数据量范围，当医院的业务系统有增量医疗数据产生时，将增量医疗数据写入kafka并结合flink流上处理实时获取增量医疗数据对应的Hudi表任务的数据量大小，根据该增量医疗数据对应的Hudi表任务所对应的数据量大小以及各Spark Session集合的任务数据量范围，确定出执行该Hudi表任务的目标Spark Session，从而采用该目标SparkSession执行该Hudi表任务，进而将增量医疗数据存储至对应的Hudi表中。该方案在进行医疗数据存储时，一方面，由于事先启动了多个Spark Session，按资源大小对Spark Session进行了分类，不用频繁的申请资源启动或停止Spark Session，节约了资源等待时间，提高了医疗数据存储的实时性；第二方面，能够为不同数据量大小的Hudi表任务匹配合适的目标Spark Session，提高了资源分配的准确性，进而提高了数据存储的实时性；第三方面，将增量医疗数据写入kafka，并结合flink进行相应的流上处理，可以保证增量医疗数据被写入后马上进入医疗数据存储处理，进一步提高了数据存储的实时性。
在本申请的一种可选实施例中，通过flink消费所述第二topic，则获取增量医疗数据对应的Hudi表任务所对应的数据量大小，包括：
通过flink消费第二topic得到增量医疗数据的数据表标识和存储路径，基于存储路径获取增量医疗数据，并基于数据表标识确定增量医疗数据对应的目标Hudi表；
将增量医疗数据的数据量大小和目标Hudi表中包含的数据量大小之和，作为Hudi表任务对应的数据量大小。
具体地，协调器模块101通过消费kafka的第二topic得到该增量医疗数据的数据表标识和存储路径。那么，协调器模块101可以通过存储路径在hdfs中读取到该增量医疗数据，可以理解的是，该增量医疗数据还未存储至对应的Hudi表中，即该增量医疗数据还未以Hudi表的形式存储至hdfs中，后续需要将该增量医疗数据以Hudi表的形式存储至hdfs中，即存储至对应的Hudi表中。协调器模块可以通过数据表标识获取该增量医疗数据对应的目标Hudi表，该目标Hudi表即为该增量医疗数据所要存储至的Hudi表。在获取到了增量医疗数据和对应的目标Hudi表后，分别获取两者各自对应的数据量大小并求和，得到Hudi表任务对应的数据量大小，也即处理该医疗数据存储任务所需要处理的数据量大小。
需要说明的是，当在一个时间段内有较多增量医疗数据产生时，可以获取多个增量医疗数据对应的数据表标识和在hdfs的存储路径，并获取对应的Hudi表任务对应的数据量大小，再将这些信息缓存至Mysql数据库，数据表标识、存储路径和数据量大小这些可以统称为增量医疗数据的事件信息。换言之，可以将多个增量医疗数据的事件信息缓存至Mysql数据库，后续协调器模块101可以轮询Mysql数据库，从中获取对应的事件信息以供进行Hudi表任务执行。
在本申请的一种可选实施例中，基于优先级得分将Hudi表任务加入任务执行队列，包括：
若任务执行队列中不包含增量医疗数据的数据表标识对应的其他Hudi表任务，则获取Hudi表任务的优先级得分，并基于Hudi表任务的优先级得分与任务执行队列中各Hudi表任务的优先级得分的大小关系，将Hudi表任务添加至任务执行队列；
若任务执行列表中包含有增量医疗数据的数据表标识对应的其他Hudi表任务，则将Hudi表任务与其他Hudi表任务合并，并获取合并后的Hudi表的优先级得分，再基于合并后的Hudi表任务的优先级得分与任务执行队列中各Hudi表任务的优先级得分的大小关系，将合并后的Hudi表任务添加至任务执行队列。
具体地，当协调器模块101轮询到一个事件信息，则首先将其转化为对应的Hudi表任务，然后需要将该Hudi表任务加入任务执行队列中，在计入任务执行队列时，需要根据各Hudi表任务的优先级得分来进行排列。那么，需要获取当前的Hudi表任务的优先级得分，还需要获取任务执行队列中已有的Hudi表任务的优先级得分，然后按优先级得分从高到低进行排列，且优先级得分最高的Hudi表任务排在任务执行队列的头部。
具体来说，若任务执行队列中不包含增量医疗数据的数据表标识对应的其他Hudi表任务，则将当前的Hudi表任务作为新的Hudi表任务，按其优先级得分高低插入任务执行队列。若任务执行列表中包含有增量医疗数据的数据表标识对应的其他Hudi表任务，则将当前的Hudi表任务与对应的其他Hudi表任务合并后，再按合并后的优先级插入任务执行队列。
进一步地，获取Hudi表任务的优先级得分：
获取Hudi表任务的延迟时间，并获取该Hudi表任务对应的增量医疗数据的数据表标识和数据量大小；
基于延迟时间获取第一优先级得分，基于数据表标识确定增量医疗数据对应的数据表类型，并基于数据表类型获取第二优先级得分，基于数据量大小获取第三优先级得分；
基于第一优先级得分、第二优先级得分以及第三优先级得分，获取该Hudi表任务的优先级得分。
具体地，任意一个Hudi表任务的优先级得分的确定可以从三个方面进行考量：对应的增量医疗数据的数据表类型、对应的增量医疗数据的数据量大小以及其等待被执行的延迟时间。具体来说，可以通过整体规划和配置，为不同的数据表类型对应的Hudi表任务给出不同的第二优先级得分，例如，数据表一般可分为包含患者就诊信息的事实表和包含科室基本信息的维度表，那么事实表对应的Hudi表任务的第二优先级得分可以高于维度表对应的Hudi表任务的第二优先级得分。为不同的数据量大小对应的Hudi表任务给出不同的第三优先级得分，例如，数据量大的Hudi表任务的第三优先级得分可以高于数据量小的Hudi表任务的第三优先级得分。为不同的延迟时间的Hudi表任务给出不同的第一优先级得分，例如，延迟时间长的Hudi表任务的第一优先级得分可以高于延迟时间短的Hudi表任务的第一优先级得分，其中，延迟时间可以指Hudi表任务在任务执行队列中的等待时间。然后，在根据第一优先级得分、第二优先级得分以及第三优先级得分，获取该Hudi表任务的优先级得分。具体来说，可以为每个考量的方面赋予对应的权重值，进而通过获取各方面的优先等级得分的加权，即得到对应的优先级得分。举例来说，可以将每个考量的方面的权重值都设置为1（即各考量的方面同等重要），然后最终一个Hudi表任务的优先级得分等于其对应的第一优先等级得分、第二优先级得分以及第三优先级得分三者之和。
在本申请的一种可选实施例中，基于Hudi表任务的数据量大小和各SparkSession集合对应的任务数据量范围，确定出目标Spark Session，包括：
将Hudi表任务的数据量大小满足的任务数据量范围对应的Spark Session集合确定为目标Spark Session集合；
将目标Spark Session集合中任一空闲Spark Session，确定为目标SparkSession。
具体地，在将Hudi表任务加入任务执行队列后，在按顺序执行到该Hudi表任务时，即当该Hudi表任务处于任务执行队列头部时，需要首先确定用于执行该Hudi表任务的目标Spark Session。本申请实施例确定目标Spark Session可以采用对应的Hudi表任务的数据量大小与各Spark Session集合的任务数据量范围进行匹配。具体来说，若该Hudi表任务的数据量大小属于某一Spark Session集合的任务数据量范围，那么该Spark Session集合即可以被确定为目标Spark Session集合，然后从中选取任意一个空闲的Spark Session作为目标Spark Session。
进一步地，该方法还可以包括：
若目标Spark Session集合没有空闲Spark Session，则将任务数据量范围的下限值大于Hudi表任务的数据量大小的Spark Session集合确定为候补Spark Session集合；
将候补Spark Session集合中任一空闲Spark Session，确定为目标SparkSession。
具体地，若目标Spark Session集合没有空闲Spark Session，则说明在目标SparkSession集合中没有可获得的目标Spark Session。因此，可以获取那些任务数据量范围的下限值更高的Spark Session集合，这些集合中的Spark Session对应的资源大小能够执行该Hudi表任务，因此将这些Spark Session集合作为候选Spark Session集合。那么，从候选Spark Session集合中选取任意一个空闲的Spark Session作为目标Spark Session。
进一步地，该方法还可以包括：
若目标Spark Session集合和候补Spark Session集合都没有空闲SparkSession，则延迟执行Hudi表任务。
具体地，若该Hudi表任务的目标Spark Session集合和候补Spark Session集合中都没有空闲Spark Session，表明现在没有合适的Spark Session用于执行该Hudi表任务，因此需要延迟执行该Hudi表任务，直至有目标Spark Session集合或候补Spark Session集合有空闲的Spark Session出现。
下面通过一个示例来对本申请的方案进行进一步说明，如图3所示，给出了将增量医疗数据存储至对应的Hudi表的过程，需要说明的是，增量医疗数据产生后，已经通过flink消费第一topic得到增量医疗数据，并将增量医疗数据存储至hdfs，并将增量医疗数据的数据表标识和在hdfs中的存储路径写入第二topic。图中所示的存储过程可以包括以下几个步骤：
在协调器模块中：
（1）协调器在进行数据存储前，启动多个Spark Session，并将其分为大SparkSession集合、中Spark Session集合以及小Spark Session集合，并分别确定各集合的任务数据量范围。其中，大Spark Session集合、中Spark Session集合以及小Spark Session集合三个集合中各Spark Session所申请的资源由大到小，由前文描述可知，三个集合对应的任务数据量范围也有大到小，即大Spark Session集合的任务数据量范围的下限值大于中Spark Session集合的任务数据量范围的上限值，中Spark Session集合的任务数据量范围的下限值大于小Spark Session集合的任务数据量范围的上限值。
（2）协调器模块通过解析kafka的第二topic得到增量医疗数据的数据表标识和存储路径。
（3）基于存储路径从hdfs获取增量医疗数据，并基于数据表标识确定增量医疗数据对应的目标Hudi表。将增量医疗数据的数据量大小和目标Hudi表中包含的数据量大小之和，作为Hudi表任务对应的数据量大小。
（4）基于Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标Spark Session集合，即将Hudi表任务分配给对应的目标Spark Session集合，并从中确定出目标Spark Session。
在Hudi合并模块中：
根据协调器模块为各Hudi表任务匹配的目标Spark Session集合，分别执行各Hudi表任务，即将各增量医疗数据存储至对应的目标Hudi表中。
图4为本申请实施例提供的一种Hudi运行环境资源优化分配装置的结构框图，如图4所示，该装置400可以包括：Spark Session启动模块401、增量数据流上处理模块402、Hudi表任务加入模块403和Hudi表任务加入模块404，其中：
Spark Session启动模块401用于在进行医疗数据存储前，启动预设数量的SparkSession，并对各Spark Session按对应的资源大小进行分类，得到至少两个Spark Session集合，并确定每个Spark Session集合对应的任务数据量范围；
增量数据流上处理模块402，用于在医院的业务系统有增量医疗数据产生时，将增量医疗数据写入卡夫卡kafka的第一主题topic，通过流式计算引擎flink消费第一topic得到增量医疗数据，并将增量医疗数据存储至分布式文件存储系统hdfs，并将增量医疗数据的数据表标识和在hdfs中的存储路径写入kafka的第二topic。
Hudi表任务加入模块403用于若医院的业务系统有增量医疗数据产生，则获取增量医疗数据对应的Hudi表任务所对应的数据量大小，并将Hudi表任务加入任务执行队列，Hudi表任务用于指示存储所述增量医疗数据至对应的Hudi表；
Hudi表任务执行模块404用于在Hudi表任务处于任务执行队列的头部时，基于Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标Spark Session，并利用目标Spark Session执行Hudi表任务，以将增量医疗数据添加至对应的Hudi表中。
本申请提供的方案，通过预先启动多个执行Hudi表任务的Spark Session，然后按资源大小将这些Spark Session分为多个Spark Session集合，且每个Spark Session集合对应一个任务数据量范围，当医院的业务系统有增量医疗数据产生时，将增量医疗数据写入kafka并结合flink流上处理实时获取增量医疗数据对应的Hudi表任务的数据量大小，根据该增量医疗数据对应的Hudi表任务所对应的数据量大小以及各Spark Session集合的任务数据量范围，确定出执行该Hudi表任务的目标Spark Session，从而采用该目标SparkSession执行该Hudi表任务，进而将增量医疗数据存储至对应的Hudi表中。该方案在进行医疗数据存储时，一方面，由于事先启动了多个Spark Session，按资源大小对Spark Session进行了分类，不用频繁的申请资源启动或停止Spark Session，节约了资源等待时间，提高了医疗数据存储的实时性；第二方面，能够为不同数据量大小的Hudi表任务匹配合适的目标Spark Session，提高了资源分配的准确性，进而提高了数据存储的实时性；第三方面，将增量医疗数据写入kafka，并结合flink进行相应的流上处理，可以保证增量医疗数据被写入后马上进入医疗数据存储处理，进一步提高了数据存储的实时性。
在本申请的一种可选实施例中，Hudi表任务加入模块具体用于：
通过flink消费第二topic得到增量医疗数据的数据表标识和存储路径，基于存储路径获取增量医疗数据，并基于数据表标识确定增量医疗数据对应的目标Hudi表；
将增量医疗数据的数据量大小和目标Hudi表中包含的数据量大小之和，作为Hudi表任务对应的数据量大小。
在本申请的一种可选实施例中，Hudi表任务加入模块具体用于：
若任务执行队列中不包含增量医疗数据的数据表标识对应的其他Hudi表任务，则获取Hudi表任务的优先级得分，并基于Hudi表任务的优先级得分与任务执行队列中各Hudi表任务的优先级得分的大小关系，将Hudi表任务添加至任务执行队列；
若任务执行列表中包含增量医疗数据的数据表标识对应的其他Hudi表任务，则将Hudi表任务与其他Hudi表任务合并，并获取合并后的Hudi表的优先级得分，再基于合并后的Hudi表任务的优先级得分与任务执行队列中各Hudi表任务的优先级得分的大小关系，将合并后的Hudi表任务添加至任务执行队列。
在本申请的一种可选实施例中， Hudi表任务加入模块进一步用于：
获取Hudi表任务的延迟时间，并获取该Hudi表任务对应的增量医疗数据的数据表标识和数据量大小；
基于延迟时间获取第一优先级得分，基于数据表标识确定增量医疗数据对应的数据表类型，并基于数据表类型获取第二优先级得分，基于数据量大小获取第三优先级得分；
基于第一优先级得分、第二优先级得分以及第三优先级得分，获取该Hudi表任务的优先级得分。
在本申请的一种可选实施例中，Hudi表任务执行模块具体用于：
将Hudi表任务的数据量大小满足的任务数据量范围对应的Spark Session集合确定为目标Spark Session集合；
将目标Spark Session集合中任一空闲Spark Session，确定为目标SparkSession。
在本申请的一种可选实施例中，Hudi表任务执行模块进一步用于：
若目标Spark Session集合没有空闲Spark Session，则将任务数据量范围的下限值大于Hudi表任务的数据量大小的Spark Session集合确定为候补Spark Session集合；
将候补Spark Session集合中任一空闲Spark Session，确定为目标SparkSession。
在本申请的一种可选实施例中，Hudi表任务执行模块进一步用于：
若目标Spark Session集合和候补Spark Session集合都没有空闲SparkSession，则延迟执行Hudi表任务。
下面参考图5，其示出了适于用来实现本申请实施例的电子设备（例如执行图2所示方法的终端设备或服务器）500的结构示意图。本申请实施例中的电子设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA（个人数字助理）、PAD（平板电脑）、PMP（便携式多媒体播放器）、车载终端（例如车载导航终端）、可穿戴设备等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图5示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
电子设备包括：存储器以及处理器，存储器用于存储执行上述各个方法实施例所述方法的程序；处理器被配置为执行存储器中存储的程序。其中，这里的处理器可以称为下文所述的处理装置501，存储器可以包括下文中的只读存储器（ROM）502、随机访问存储器（RAM）503以及存储装置508中的至少一项，具体如下所示：
如图5所示，电子设备500可以包括处理装置（例如中央处理器、图形处理器等）501，其可以根据存储在只读存储器（ROM）502中的程序或者从存储装置508加载到随机访问存储器（RAM）503中的程序而执行各种适当的动作和处理。在RAM503中，还存储有电子设备500操作所需的各种程序和数据。处理装置501、ROM 502以及RAM503通过总线504彼此相连。输入/输出（I/O）接口505也连接至总线504。
通常，以下装置可以连接至I/O接口505：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置506；包括例如液晶显示器（LCD）、扬声器、振动器等的输出装置507；包括例如磁带、硬盘等的存储装置508；以及通信装置509。通信装置509可以允许电子设备500与其他设备进行无线或有线通信以交换数据。虽然图5示出了具有各种装置的电子设备，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。
特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在非暂态计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置509从网络上被下载和安装，或者从存储装置508被安装，或者从ROM 502被安装。在该计算机程序被处理装置501执行时，执行本申请实施例的方法中限定的上述功能。
需要说明的是，本申请上述的计算机可读存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑磁盘只读存储器（CD-ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF（射频）等等，或者上述的任意合适的组合。
在一些实施方式中，客户端、服务器可以利用诸如HTTP（HyperText TransferProtocol，超文本传输协议）之类的任何当前已知或未来研发的网络协议进行通信，并且可以与任意形式或介质的数字数据通信（例如，通信网络）互连。通信网络的示例包括局域网（“LAN”），广域网（“WAN”），网际网（例如，互联网）以及端对端网络（例如，ad hoc端对端网络），以及任何当前已知或未来研发的网络。
上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。
上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：
在进行医疗数据存储前，启动预设数量的计算引擎会话Spark Session，并对各Spark Session按对应的资源大小进行分类，得到至少两个Spark Session集合，并确定每个Spark Session集合对应的任务数据量范围；在医院的业务系统有增量医疗数据产生时，将增量医疗数据写入卡夫卡kafka的第一主题topic，通过流式计算引擎flink消费第一topic得到增量医疗数据，并将增量医疗数据存储至分布式文件存储系统hdfs，并将增量医疗数据的数据表标识和在hdfs中的存储路径写入kafka的第二topic；通过flink消费第二topic，获取增量医疗数据对应的Hudi表任务所对应的数据量大小，并获取Hudi表任务的优先级得分，基于优先级得分将Hudi表任务加入任务执行队列，Hudi表任务用于指示存储增量医疗数据至对应的Hudi表；在Hudi表任务处于任务执行队列的头部时，基于Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标SparkSession，并利用目标Spark Session执行Hudi表任务，以将增量医疗数据添加至对应的Hudi表中。
可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，上述程序设计语言包括但不限于面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机（例如利用因特网服务提供商来通过因特网连接）。
附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的模块或单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块或单元的名称在某种情况下并不构成对该单元本身的限定，例如，Spark Session启动模块还可以被描述为“启动Spark Session的模块”。
本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列（FPGA）、专用集成电路（ASIC）、专用标准产品（ASSP）、片上系统（SOC）、复杂可编程逻辑设备（CPLD）等等。
在本申请的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦除可编程只读存储器（EPROM或快闪存储器）、光纤、便捷式紧凑盘只读存储器（CD-ROM）、光学储存设备、磁储存设备、或上述内容的任何合适组合。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的计算机可读介质被电子设备执行时实现的具体方法，可以参考前述方法实施例中的对应过程，在此不再赘述。
本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行时实现如下情况：
在进行医疗数据存储前，启动预设数量的计算引擎会话Spark Session，并对各Spark Session按对应的资源大小进行分类，得到至少两个Spark Session集合，并确定每个Spark Session集合对应的任务数据量范围；在医院的业务系统有增量医疗数据产生时，将增量医疗数据写入卡夫卡kafka的第一主题topic，通过流式计算引擎flink消费第一topic得到增量医疗数据，并将增量医疗数据存储至分布式文件存储系统hdfs，并将增量医疗数据的数据表标识和在hdfs中的存储路径写入kafka的第二topic；通过flink消费第二topic，获取增量医疗数据对应的Hudi表任务所对应的数据量大小，并获取Hudi表任务的优先级得分，基于优先级得分将Hudi表任务加入任务执行队列，Hudi表任务用于指示存储增量医疗数据至对应的Hudi表；在Hudi表任务处于任务执行队列的头部时，基于Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标SparkSession，并利用目标Spark Session执行Hudi表任务，以将增量医疗数据添加至对应的Hudi表中。
应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种Hudi运行环境资源优化分配方法，其特征在于，包括：
在进行医疗数据存储前，启动预设数量的计算引擎会话Spark Session，并对各SparkSession按对应的资源大小进行分类，得到至少两个Spark Session集合，并确定每个SparkSession集合对应的任务数据量范围；
在医院的业务系统有增量医疗数据产生时，将所述增量医疗数据写入卡夫卡kafka的第一topic，通过流式计算引擎flink消费所述第一topic得到所述增量医疗数据，并将所述增量医疗数据存储至分布式文件存储系统hdfs，并将所述增量医疗数据的数据表标识和在所述hdfs中的存储路径写入所述kafka的第二topic；
通过flink消费所述第二topic，获取所述增量医疗数据对应的Hudi表任务所对应的数据量大小，并获取所述Hudi表任务的优先级得分，基于所述优先级得分将所述Hudi表任务加入任务执行队列，所述Hudi表任务用于指示存储所述增量医疗数据至对应的Hudi表；
在所述Hudi表任务处于所述任务执行队列的头部时，基于所述Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标Spark Session，并利用所述目标Spark Session执行所述Hudi表任务，以将所述增量医疗数据添加至对应的Hudi表中。
2.根据权利要求1所述的方法，其特征在于，通过flink消费所述第二topic，获取所述增量医疗数据对应的Hudi表任务所对应的数据量大小，包括：
通过flink消费所述第二topic得到所述增量医疗数据的数据表标识和存储路径，基于所述存储路径获取所述增量医疗数据，并基于所述数据表标识确定所述增量医疗数据对应的目标Hudi表；
将所述增量医疗数据的数据量大小和所述目标Hudi表中包含的数据量大小之和，作为所述Hudi表任务对应的数据量大小。
3.根据权利要求1所述的方法，其特征在于，基于所述优先级得分将所述Hudi表任务加入任务执行队列，包括：
若所述任务执行队列中不包含所述增量医疗数据的数据表标识对应的其他Hudi表任务，则获取所述Hudi表任务的优先级得分，并基于所述Hudi表任务的优先级得分与所述任务执行队列中各Hudi表任务的优先级得分的大小关系，将所述Hudi表任务添加至所述任务执行队列；
若所述任务执行队列 中包含所述增量医疗数据的数据表标识对应的其他Hudi表任务，则将所述Hudi表任务与所述其他Hudi表任务合并，并获取合并后的Hudi表的优先级得分，再基于所述合并后的Hudi表任务的优先级得分与所述任务执行队列中各Hudi表任务的优先级得分的大小关系，将所述合并后的Hudi表任务添加至所述任务执行队列。
4.根据权利要求1所述的方法，其特征在于，获取所述Hudi表任务的优先级得分：
获取所述Hudi表任务的延迟时间，并获取该Hudi表任务对应的增量医疗数据的数据表标识和数据量大小；
基于所述延迟时间获取第一优先级得分，基于所述数据表标识确定所述增量医疗数据对应的数据表类型，并基于所述数据表类型获取第二优先级得分，基于所述数据量大小获取第三优先级得分；
基于所述第一优先级得分、所述第二优先级得分以及所述第三优先级得分，获取该Hudi表任务的优先级得分。
5.根据权利要求1所述的方法，其特征在于，所述基于所述Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标Spark Session，包括：
将所述Hudi表任务的数据量大小满足的任务数据量范围对应的Spark Session集合确定为目标Spark Session集合；
将所述目标Spark Session集合中任一空闲Spark Session，确定为目标SparkSession。
6.根据权利要求5所述的方法，其特征在于，所述方法还包括：
若所述目标Spark Session集合没有空闲Spark Session，则将任务数据量范围的下限值大于所述Hudi表任务的数据量大小的Spark Session集合确定为候补Spark Session集合；
将所述候补Spark Session集合中任一空闲Spark Session，确定为目标SparkSession。
7.根据权利要求6所述的方法，其特征在于，所述方法还包括：
若所述目标Spark Session集合和所述候补Spark Session集合都没有空闲SparkSession，则延迟执行所述Hudi表任务。
8.一种Hudi运行环境资源优化分配装置，其特征在于，包括：
Spark Session启动模块，用于在进行医疗数据存储前，启动预设数量的SparkSession，并对各Spark Session按对应的资源大小进行分类，得到至少两个Spark Session集合，并确定每个Spark Session集合对应的任务数据量范围；
增量数据流上处理模块，用于在医院的业务系统有增量医疗数据产生时，将所述增量医疗数据写入卡夫卡kafka的第一topic，通过流式计算引擎flink消费所述第一topic得到所述增量医疗数据，并将所述增量医疗数据存储至分布式文件存储系统hdfs，并将所述增量医疗数据的数据表标识和在所述hdfs中的存储路径写入所述kafka的第二topic；
Hudi表任务加入模块，用于通过flink消费所述第二topic，获取所述增量医疗数据对应的Hudi表任务所对应的数据量大小，并获取所述Hudi表任务的优先级得分，基于所述优先级得分将所述Hudi表任务加入任务执行队列，所述Hudi表任务用于指示存储所述增量医疗数据至对应的Hudi表；
Hudi表任务执行模块，用于在所述Hudi表任务处于所述任务执行队列的头部时，基于所述Hudi表任务的数据量大小和各Spark Session集合对应的任务数据量范围，确定出目标Spark Session，并利用所述目标Spark Session执行所述Hudi表任务，以将所述增量医疗数据添加至对应的Hudi表中。
9.根据权利要求8所述的装置，其特征在于，Hudi表任务加入模块具体用于：
在医院的业务系统有增量医疗数据产生时，通过流式计算引擎flink消费卡夫卡kafka的第一主题topic得到所述增量医疗数据，并将所述增量医疗数据存储至分布式文件存储系统hdfs，并将所述增量医疗数据的数据表标识和在所述hdfs中的存储路径写入所述kafka的第二topic；
消费所述第二topic得到所述增量医疗数据的数据表标识和存储路径，基于所述存储路径获取所述增量医疗数据，并基于所述数据表标识确定所述增量医疗数据对应的目标Hudi表；
将所述增量医疗数据的数据量大小和所述目标Hudi表中包含的数据量大小之和，作为所述Hudi表任务对应的数据量大小。
10.根据权利要求8所述的装置，其特征在于，所述Hudi表任务加入模块具体用于：
获取所述任务执行队列中各Hudi表任务的优先级得分；
若所述任务执行队列中不包含所述增量医疗数据的数据表标识对应的其他Hudi表任务，则获取所述Hudi表任务的优先级得分，并基于所述Hudi表任务的优先级得分与所述任务执行队列中各Hudi表任务的优先级得分的大小关系，将所述Hudi表任务添加至所述任务执行队列；
若所述任务执行队列 中包含所述增量医疗数据的数据表标识对应的其他Hudi表任务，则将所述Hudi表任务与所述其他Hudi表任务合并，并获取合并后的Hudi表的优先级得分，再基于所述合并后的Hudi表任务的优先级得分与所述任务执行队列中各Hudi表任务的优先级得分的大小关系，将所述合并后的Hudi表任务添加至所述任务执行队列。
CN202210117140.1A 2022-02-08 2022-02-08 Hudi运行环境资源优化分配方法及装置 Active CN114153620B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210117140.1A CN114153620B (zh) 2022-02-08 2022-02-08 Hudi运行环境资源优化分配方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210117140.1A CN114153620B (zh) 2022-02-08 2022-02-08 Hudi运行环境资源优化分配方法及装置

Publications (2)

Publication Number Publication Date
CN114153620A CN114153620A (zh) 2022-03-08
CN114153620B true CN114153620B (zh) 2022-05-24

Family

ID=80450249

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210117140.1A Active CN114153620B (zh) 2022-02-08 2022-02-08 Hudi运行环境资源优化分配方法及装置

Country Status (1)

Country Link
CN (1) CN114153620B (zh)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110704206A (zh) * 2019-09-09 2020-01-17 上海凯京信达科技集团有限公司 一种实时计算方法、计算机存储介质及电子设备
CN110908788A (zh) * 2019-12-02 2020-03-24 北京锐安科技有限公司 基于Spark Streaming的数据处理方法、装置、计算机设备及存储介质
CN111177271A (zh) * 2019-12-31 2020-05-19 奇安信科技集团股份有限公司 kafka数据持久化到hdfs的数据存储方法、装置、计算机设备
CN111723160A (zh) * 2020-08-24 2020-09-29 国网浙江省电力有限公司 一种多源异构增量数据同步方法及系统
CN113407617A (zh) * 2021-06-25 2021-09-17 交控科技股份有限公司 基于大数据技术的实时与离线业务统一处理方法和装置
WO2021187682A1 (ko) * 2020-03-18 2021-09-23 숭실대학교산학협력단 클라우드 컴퓨팅 환경에서 분산 테이블 구조를 활용한 owl-horst 온톨로지 추론 방법 및 장치
CN113468199A (zh) * 2021-07-29 2021-10-01 上海哔哩哔哩科技有限公司 索引更新方法及系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9582355B2 (en) * 2014-07-09 2017-02-28 Qualcomm Incorporated Systems and methods for reliably storing data using liquid distributed storage

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110704206A (zh) * 2019-09-09 2020-01-17 上海凯京信达科技集团有限公司 一种实时计算方法、计算机存储介质及电子设备
CN110908788A (zh) * 2019-12-02 2020-03-24 北京锐安科技有限公司 基于Spark Streaming的数据处理方法、装置、计算机设备及存储介质
CN111177271A (zh) * 2019-12-31 2020-05-19 奇安信科技集团股份有限公司 kafka数据持久化到hdfs的数据存储方法、装置、计算机设备
WO2021187682A1 (ko) * 2020-03-18 2021-09-23 숭실대학교산학협력단 클라우드 컴퓨팅 환경에서 분산 테이블 구조를 활용한 owl-horst 온톨로지 추론 방법 및 장치
CN111723160A (zh) * 2020-08-24 2020-09-29 国网浙江省电力有限公司 一种多源异构增量数据同步方法及系统
CN113407617A (zh) * 2021-06-25 2021-09-17 交控科技股份有限公司 基于大数据技术的实时与离线业务统一处理方法和装置
CN113468199A (zh) * 2021-07-29 2021-10-01 上海哔哩哔哩科技有限公司 索引更新方法及系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Facilitating Role of Cloud Computing in Driving Big Data Emergence;Teah Yi Fan;《IEEE》;20220113;全文 *
基于分布式并行计算的铁路电子支付平台对账业务数据处理方案研究;王宁;《铁路计算机应用》;20210831;全文 *

Also Published As

Publication number Publication date
CN114153620A (zh) 2022-03-08

Similar Documents

Publication Publication Date Title
WO2021103479A1 (zh) 用于训练深度学习模型的方法和装置
CN111427706B (zh) 数据处理方法、多服务器系统、数据库、电子设备及存储介质
WO2023082914A1 (zh) 资源分配方法、装置、可读介质及电子设备
CN111985831A (zh) 云计算资源的调度方法、装置、计算机设备及存储介质
CN114116842B (zh) 多维医疗数据实时获取方法、装置、电子设备及存储介质
CN111857720B (zh) 用户界面状态信息的生成方法、装置、电子设备及介质
CN110781159B (zh) Ceph目录文件信息读取方法、装置、服务器及存储介质
CN112379982A (zh) 任务处理方法、装置、电子设备及计算机可读存储介质
WO2020199659A1 (zh) 用于确定推送优先级信息的方法和装置
CN115357350A (zh) 任务配置方法、装置、电子设备和计算机可读介质
CN110009101B (zh) 用于生成量化神经网络的方法和装置
CN115237589A (zh) 一种基于sr-iov的虚拟化方法、装置和设备
CN111309304A (zh) 一种生成idl文件的方法、装置、介质和电子设备
CN111262744B (zh) 多媒体信息发送方法、备份服务器及介质
CN110489219B (zh) 一种调度功能对象的方法、装置、介质和电子设备
CN111010453B (zh) 服务请求处理方法、系统、电子设备及计算机可读介质
CN114153620B (zh) Hudi运行环境资源优化分配方法及装置
WO2023056841A1 (zh) 一种数据服务方法、装置及相关产品
CN113792869B (zh) 基于神经网络芯片的视频处理方法、装置和电子设备
CN112667368A (zh) 一种任务数据处理方法和装置
CN110941683B (zh) 获取空间中对象属性信息的方法、装置、介质和电子设备
CN113204426A (zh) 资源池的任务处理方法及相关设备
CN113064704A (zh) 任务处理方法、装置、电子设备和计算机可读介质
CN116755889B (zh) 应用于服务器集群数据交互的数据加速方法、装置与设备
CN111581305B (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