CN108053863B - 适合大小文件的海量医疗数据存储系统及数据存储方法 - Google Patents

Abstract

本发明实施例提供的适合大小文件的海量医疗数据存储系统及数据存储方法，属于数据存储技术领域。该系统针对医疗领域适合海量大文件、小文件并存的应用场景，解决了传统关系型数据库不适合非结构化数据的问题、解决了redis不适合海量数据存储的问题、改善了只采用hbase做存储时候面临的系统不稳定的问题、极大改善了单纯采用hdfs中解决小文件存储所面临的不适合大文件和文件不方便检索的问题。

Description

适合大小文件的海量医疗数据存储系统及数据存储方法

技术领域

本发明涉及数据存储技术领域，具体而言，涉及适合大小文件的海量医疗数据存储系统及数据存储方法。

背景技术

随着医疗卫生信息化建设进程不断加快，医疗数据的类型与规模正在以前所未有的速度增长，并且在临床诊疗工作中，有大量的知识需求亟待通过计算机来提供。至少包括如下几类：一是基础知识库。主要是指合理用药、医学公式、医学术语集等“静态”规则类知识。二是临床诊疗知识库。主要是指经过人工不断总结形成的知识，包括临床路径、临床指南、疾病诊治知识库等。三是参考文献。特别是罕见病诊治更需要国内外参考文献提供借鉴。四是从历史病例挖掘形成的知识。然而这些数据，有些属于大文件有些属于小文件，面对这些海量的大小不等的数据，如何更好的存储并方便后续高效分析使用成为一个难题。

传统的数据存储方法可选用关系型数据库，常用的就是关系型数据库管理系统Mysql或Orcal，它可支持数据的存储和复杂的查询，但会遇到如下问题：

首先，对海量数据和数据更新操作支持力度不够。当数据量比较大或者数据读写更新的频率频繁的情况下，Mysql或Orcal的性能很差，即使对数据库内存表的锁进行优化，其性能也随着数据量的增大而下降；

其次，数据的类型比较复杂，有结构化、半结构化和非结构化数据之分，单纯选择关系型数据库就变得不适用。另外一种就是选用高性能的key－value存储系统Redis数据库，它支持复杂的数据类型，并且所有数据都可保存在内存中，在数据量大或者读写更新操作频繁的情况下，可保证消息处理的时效性，但会遇到如下问题：Redis的数据一般不要求实时落地，也不太适合大量数据的存储。常见的另外一种提高数据存储的方法是选用分布式的、面向列的Hbase数据库，它可以搭建分布式的数据存储集群，但是也存在如下问题：虽然Hbase对海量数据的存储支持性比较好，但并不是完全高可用，并且当数据量很大的时候，Hbase的Region因经常做Split产生抖动，使得存储和检索都不是很稳定。

目前，当数据量比较大的时候，常采用HDFS系统，但是HDFS针对小文件也存在因文件数目多而导致的整个系统缓慢的问题。为改善这个问题，目前常通过Hadoop提供的SequenceFile、MapFile，把小文件先组合成一个大文件进行存储，但是也存在一些问题，比如无法简单快速的列出小文件目录，从而无法实现快速检索。因此，现有技术中存在无法简单快速的列出小文件目录，以及无法实现快速检索的技术问题。

发明内容

本发明提供的适合大小文件的海量医疗数据存储系统及数据存储方法，旨在改善上述问题。

本发明提供的适合大小文件的海量医疗数据存储系统，包括：用户注册模块、监控报警模块、处理模块、数据索引模块、接口模块和负载均衡模块；所述用户注册模块用于管理院区信息、科室信息以及用户名信息；并且还用于在进行用户注册新增操作时，使得用户需要按照预设规则进行注册，当不满足所述预设规则时，发送提示信息至用户终端；当注册成功时，为所述用户赋予文件操作权限，以及将所述用户信息按照预设格式进行存储；所述监控报警模块用于实时监控各个存储服务器和各个服务模块的运行状态，以及当所述系统或服务状态异常时发送邮件或短信报警，使得第一时间通知系统管理人员，以及在状态恢复后发出正常的邮件或短信通知，以使用户能够在正常后进行及时使用；所述处理模块用于将用户上传的海量小文件按照预设处理规则分组合并成sequenceFile，并根据不同的队列进行合并所述文件，进而减少用户访问数据的压力；所述数据索引模块用于为用户所上传的数据分配唯一标识符和索引；所述接口模块用于提供上传、查看下载、删除文件的接口，以使用户通过所述接口模块完成用户文件上传、下载或删除操作；所述负载均衡模块用于根据用户发送的消息包中所携带的用户的IP和操作信息，对所述用户发送的消息包进行解析，然后根据IP和操作的类型选择对应的服务器组；以及还用于获得各个服务器的性能状态，然后再根据每个所述服务器的性能状态选择多个所述服务器中的任意一个所述服务器，从而将数据报文中的目标地址修改为所述服务器所对应的地址。

可选地，所述处理模块具体用于：从kafka的未消费缓存队列集合中逐个获取用户文件，并写入到预设的维护的序列文件集合中；判断所述序列文件集合的值是否达到预设值；若是，将所述序列文件集合中的文件合并写入到HDFS中的序列文件中；当写入成功后，将操作日志写入到log中，并将所述用户文件的索引写到所述数据索引模块所在的服务器上，同时将所述kafka中刚刚消费的队列中相应文件记录删除；若否，则进行休眠。

可选地，所述处理模块包括控制器和操作日志模块。

可选地，还包括元数据模块，所述元数据模块，用于存储用户的注册信息和文件名的编号信息，以使用户注册后能够快速进行查询和更新操作。

可选地，还包括数据缓存模块，所述数据缓存模块，用于缓存用户上传或下载的数据。

可选地，还包括索引存储模块，所述索引存储模块用于存储文件索引。

本发明提供的数据存储方法，应用于上述的适合大小文件的海量医疗数据存储系统，包括：所述负载均衡模块获取用户上传的用户文件，并将所述用户文件发送至所述接口模块；所述接口模块将所接收到的所述用户文件发送至缓存模块，以使所述缓存模块将所述用户文件上传至所述处理模块；所述处理模块从kafka的未消费缓存队列集合中逐个获取用户文件，并写入到预设的维护的序列文件集合中；所述处理模块判断所述序列文件集合的值是否达到预设值；若是，所述处理模块将所述序列文件集合中的文件合并写入到HDFS中的序列文件中；当写入成功后，所述处理模块将操作日志写入到log中，并将所述用户文件的索引写到所述数据索引模块所在的服务器上，同时所述处理模块将所述kafka中刚刚消费的队列中相应文件记录删除；若否，所述处理模块则进行休眠。

可选地，所述的所述处理模块判断所述序列文件集合的值是否达到预设值，包括：所述处理模块判断所述序列文件集合的值是否等于128兆。

可选地，所述的所述处理模块从kafka的未消费缓存队列集合中逐个获取用户文件，并写入到预设的维护的序列文件集合中，之前还包括：判断本地服务器预设目录下是否有数据；若有，获取所述数据。

可选地，所述的若否，所述处理模块则进行休眠，包括：若否，所述处理模块进行等待直到所述序列文件集合的值达到所述预设值。

上述本发明提供的适合大小文件的海量医疗数据存储系统及数据存储方法的有益效果是：通过用户注册模块来监控实际注册用户，从而有效地防止非法用户进行注册，进而有效地避免了非法用户进行数据的访问，通过监控报警模块可以实时监控各个存储服务器和各个服务模块的运行状态，以及当所述系统或服务状态异常时发送邮件或短信报警，使得第一时间通知系统管理人员，以及在状态恢复后发出正常的邮件或短信通知，以使用户能够在正常后进行及时使用，再通过处理模块、数据索引模块、接口模块和负载均衡模块使得针对医疗领域适合海量大文件、小文件并存的应用场景，解决了传统关系型数据库不适合非结构化数据的问题、解决了redis不适合海量数据存储的问题、改善了只采用hbase做存储时候面临的系统不稳定的问题、极大改善了单纯采用hdfs中解决小文件存储所面临的不适合大文件和文件不方便检索的问题。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明实施例提供的一种电子设备的结构框图；

图2为本发明第一实施例提供的数据存储方法的流程图；

图3为本发明第二实施例提供的适合大小文件的海量医疗数据存储系统的功能模块示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，为本发明实施例提供的一种电子设备的结构框图。所述电子设备300包括适合大小文件的海量医疗数据存储系统400、存储器302、存储控制器303、处理器304及外设接口305。

所述存储器302、存储控制器303、处理器304及外设接口305各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。所述适合大小文件的海量医疗数据存储系统400包括至少一个可以软件或固件(firmware)的形式存储于所述存储器302中或固化在所述电子设备300的操作系统(operating system，OS)中的软件功能模块。所述处理器304用于执行存储器302中存储的可执行模块，例如所述适合大小文件的海量医疗数据存储系统400包括的软件功能模块或计算机程序。

其中，存储器302可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read－Only Memory，PROM)，可擦除只读存储器(Erasable Programmable Read－Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read－Only Memory，EEPROM)等。其中，存储器302用于存储程序，所述处理器304在接收到执行指令后，执行所述程序，前述本发明实施例任一实施例揭示的流过程定义的服务器100所执行的方法可以应用于处理器304中，或者由处理器304实现。

处理器304可能是一种集成电路芯片，具有信号的处理能力。上述的处理器304可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述外设接口305将各种输入/输入装置耦合至处理器304以及存储器302。在一些实施例中，外设接口305、处理器304以及存储控制器303可以在单个芯片中实现。在其他一些实例中，他们可以分别由独立的芯片实现。

请参阅图2，是本发明第一实施例提供的数据存储方法的流程图。所述数据存储方法应用于适合大小文件的海量医疗数据存储系统，下面将对图2所示的具体流程进行详细阐述。

步骤S101，所述负载均衡模块获取用户上传的用户文件，并将所述用户文件发送至所述接口模块。

其中，所述的所述负载均衡模块获取用户上传的用户文件中的用户是指已经注册通过的用户。

步骤S102，所述接口模块将所接收到的所述用户文件发送至缓存模块，以使所述缓存模块将所述用户文件上传至所述处理模块。

步骤S103，所述处理模块从kafka的未消费缓存队列集合中逐个获取用户文件，并写入到预设的维护的序列文件集合中。

例如，所述处理模块在完成初始化后，获取数据缓存模块中缓存的数据，如果本地服务器指定目录下有数据，则同时先将本地目录下的数据加载到处理模块中；再通过所述处理模块中的控制器开始合并文件，当达到预设的文件大小时，将文件合并成一个文件。

在本实施例中，作为一种实施方式，在步骤S103之前还包括：判断本地服务器预设目录下是否有数据；若有，获取所述数据。其中，所述的获取所述数据是指将所述数据加入到所述处理模块。

步骤S104，所述处理模块判断所述序列文件集合的值是否达到预设值。

其中，所述预设值的选取可以根据实际需求进行选取，例如，所述预设值可以是64兆，也可以是128兆，还可以是256兆等。在本实施例中，优选地，所述预设值为128兆。

步骤S105，若是，所述处理模块将所述序列文件集合中的文件合并写入到HDFS中的序列文件中。

步骤S106，当写入成功后，所述处理模块将操作日志写入到log中，并将所述用户文件的索引写到所述数据索引模块所在的服务器上，同时所述处理模块将所述kafka中刚刚消费的队列中相应文件记录删除。

步骤S107，若否，所述处理模块则进行休眠。

其中，所述若否是指所述处理模块判断所述序列文件集合的值没有达到预设值。例如，当没有达到预设值的时候，处理模块中的控制器处在等待状态，直到数据达到128M。

请参阅图3，是本发明第二实施例提供的适合大小文件的海量医疗数据存储系统的功能模块示意图。所述适合大小文件的海量医疗数据存储系统400包括用户注册模块410、监控报警模块420、处理模块430、数据索引模块440、接口模块450、负载均衡模块460、元数据模块470、数据缓存模块480和索引存储模块490。

所述用户注册模块410用于管理院区信息、科室信息以及用户名信息；并且还用于在进行用户注册新增操作时，使得用户需要按照预设规则进行注册，当不满足所述预设规则时，发送提示信息至用户终端；当注册成功时，为所述用户赋予文件操作权限，以及将所述用户信息按照预设格式进行存储。具体地，所述用户注册模块410用于获取用户输入的注册信息，其中，所述注册信息包括用户所属院区信息、科室信息、密码以及用户名信息；再根据用户输入的所属院区信息与科室信息以及用户名信息查询医院系统中与所述院区信息与科室信息以及用户名信息对应的匹配信息，判断是否匹配，如果不匹配，则不通过注册，并且发送提示信息至用户终端，以告知用户注册失败。否则，通过注册。

在本实施例中，为了避免非法用户通过网络查询该医院的医生信息后，冒名使用，优选地，通过预设规则对所述注册信息进行加密运算，所述注册信息满足：M＝A(x)+B(y)+C(z)，其中，

A(x)＝(a₁+a₂+a₃+···+a_x)÷xx＝1、2、3、4、5....，

B(y)＝(b₁+b₃+b₅+b_2y-1)÷yy＝1、2、3、4、5....，

其中，当z＝1时C(z)＝h₁，当z大于1时，C(z)＝c₁+c₂-c₃+c₄-c₅+c_2z-c_2z+1，其中，a₁表示所述院区信息所对应的数值的第一位的数值，依次类推，所述a_x表示所述院区信息所对应的数值的第x位的数值，b₁表示科室信息所对应的数值的第一位的数值，b₃表示科室信息所对应的数值的第三位的数值，依次类推b_2y－1表示科室信息所对应的数值的第2y－1位的数值，c₁表示所述用户名信息所对应的数值的第一位的数值，c₂表示所述用户名信息所对应的数值的第二位的数值，依次类推c_2z+1表示所述用户名信息所对应的数值的第2z+1位的数值。

在本实施例中，所述院区信息所对应的数值、所述科室信息所对应的数值以及所述用户名信息所对应的数值为预先设定的。例如，可以根据对用户的每个姓赋予一个数值，在此，不作具体限定。

在本实施例中，所述用户名信息为用户的真实姓名。

作为一种实施场景，所有的注册是面向医院的工作人员，必须是真实实名的信息。管理操作权限主要分为两种：系统管理员权限及院区管理员权限。院区管理员权限只能管理和查看系统管理员账户注册的某一院区下的科室、用户及系统运行信息；而系统管理员权限则可管理所有院区下面的各种信息，并且可以监控整个系统的运行情况。系统管理员—院区管理员—用户，用户管理系统分成三层，更便于申请人员的审核，并且做到多层审核，进而保障系统数据安全。用户分匿名用户和注册用户，其中匿名用户是未注册的用户，该类用户也可以使用该系统，只是权限控制严格，仅仅是查看系统发布的公开文档，这些文档一般是系统管理员发布的一些基本的公开的医学知识文档。而不能查看其它数据，主要是考虑医用数据的敏感性，防止数据泄密。注册用户拥有上传文档、查完部分公开文档、下载部分公开文档、删除自己上传的文档的权利，并且当该用户想要下载该公开文档的时候，可以向系统再次发送验证即可完成全文下载，且分配一定的初始存储空间且根据用户的使用情况会自动调整空间大小。用户申请的时候，可个性化定制权限。会确定申请者工种、科室和院区，针对不同的工种、科室及院区，分配不同的权限，尤其针对查看数据和下载数据的权限，针对医生、护士和科研人员以及人员所在的科室和院区，用户对文件操作权限不同。为便于后续获取文件的时候匹配权限，用户名在后台存储的时候格式为：院区＿科室＿身份＿姓名。用户注册模块用于管理院区信息、科室信息以及用户名信息。在进行新增操作时，需要按照院区－＞科室－＞用户工种－＞用户名的顺序来进行，其中前两个是必须先注册创建好的，如果没有则需要和系统管理员或者院区管理员联系创建。用户注册的时候，先经过院区管理员的审核同意，之后再经过系统管理员的审核同意。申请成功之后，系统会为用户分配用户名及登录密码，并且会通过短信的方式发送一条注册成功的短信，短信中包含用户名和密码。例如，用户输入用户名或者手机号+验证码，就可以访问大数据存储平台。如用户为首次登陆，系统将提示用户修改初始密码。通过这样的过程，保障用户的真实身份访问，做到任何操作可以追溯，从而减少外来无关人员和使用用户对信息泄露的风险。并且用户在注册的时候，会发出提示信息，以告知用户是否注册成功，并且一旦注册不成功，则会给出失败原因的提示。

所述监控报警模块420用于实时监控各个存储服务器和各个服务模块的运行状态，以及当所述系统或服务状态异常时发送邮件或短信报警，使得第一时间通知系统管理人员，以及在状态恢复后发出正常的邮件或短信通知，以使用户能够在正常后进行及时使用。

作为一种实施方式，所述监控报警模块420实现三个层面的监控和告警：一、系统层面：通过预设的插件来监控服务器的CPU、内存、硬盘使用率、I/O负载；二、软件层面：根据进程的pid定时检查进程的状态，对挂掉的进程显示报警；三、业务层面：系统各个模块可以自定义告警。所述监控报警模块420可以定时周期性的检测各个被监控的状态。并且可自定义报警内容，包括系统运行情况、各服务器的情况、各个模块的运行的情况。例如，所述各个模块可以是负载均衡模块460、元数据模块470、数据缓存模块480和/或索引存储模块490，当出现异常情况的时候，根据异常的定位，可以并实现部分模块的自动重启，例如，所述部分模块可以是负载均衡模块460、元数据模块470、数据缓存模块480和/或索引存储模块490。监控报警模块420会维持一个队列，所有插件返回来的状态信息都进入队列，监控报警模块420每次都从队首开始读取信息，并进行处理后，把状态结果通过web显示出来，一方面方便管理员查看整个系统的运行状态，另一方便，当遍历队列时候查看到异常的状态，则先邮件或者短信通知，并且针对常见的问题给出邮件或者短信的处理方法，并且针对部分简单的问题，完全实现系统自主解决。所述监控报警模块420可以对为了对其产生的各种数据进行特定地分析与管理。并且所述监控报警模块420支持记录的功能，当用户需要查询某些用户或自身的操作记录时，可以通过点击菜单栏中的“历史快照”选项进行管理。历史快照中记录了所有人员的所有操作，并且里面具体包含“不良操作”，监控报警模块420中记录所有用户的所有不符合该用户权限或者占用资源过多的操作，各级管理员定时查看该记录表，从而针对的进行用户操作的指导。

所述处理模块430用于将用户上传的海量小文件按照预设处理规则分组合并成sequenceFile，并根据不同的队列进行合并所述文件，进而减少用户访问数据的压力。

其中，所述处理模块430具体用于：从kafka(卡夫卡)的未消费缓存队列集合中逐个获取用户文件，并写入到预设的维护的序列文件集合中；判断所述序列文件集合的值是否达到预设值；若是，将所述序列文件集合中的文件合并写入到HDFS中的序列文件中；当写入成功后，将操作日志写入到log中，并将所述用户文件的索引写到所述数据索引模块所在的服务器上，同时将所述kafka中刚刚消费的队列中相应文件记录删除；若否，则进行休眠。

作为一种实施方式，所述处理模块430将用户上传的海量小文件分组合并成sequenceFile，其中，这个分组的依据就是根据缓存模块中Kafka上传缓存队列的topic标记。这个topic标记组合为“院区＿科室＿用户工种＿用户名”，同一topic下的数据具有相同的处理逻辑以及存储文件夹，以上四个概念的范畴从大到小依次递减。根据不同的队列进行合并文件，这样方便后续不同权限的用户获取数据，减少访问数据的压力。所述处理模块430由多个预设程序块TopicImporter组成，其中，TopicImporter为预先设置的主题导入进程程序模块。每个Kafka Topic对应一个TopicImporter，TopicImporter依赖于KafkaReader从kafka中获取上传缓存的数据，kafka中的每一个topicName(所述topicName为主题名称)中“院区＿科室＿身份＿姓名”的对应一个DataReader，所述DataReader为预设的数据读取进程模块，其中，每一个DataReader作为单线程从Kafka中读取原始数据，获取其中的DATA对象中的“Time(时间戳)”字段和“FileName(文件名)”字段，在和topicName组合在一起，做Hash，根据hash值将原始数据分发到不同的DataWriter，其中，所述DataWriter为预设设置的数据写入进程查询模块。DataWriter中有一个队列来接收分发过来的原始数据，用Map表用于保存不同的HDFS目标文件对应的DataHDFSWriter，当数据达到128M或者数据没有新数据来的时候，每个DataWriter都有一个线程来读取队列中的原始数据，并根据原始数据中的[院区＿科室＿身份＿姓名＿文件名id]作为KEY，去本地的Map表中取DataHDFSWriter(取值为Null则创建并PUT到Map表)，调用DataHDFSWriter执行写入操作。然后将合并的sequencefile文件持久化到hadoop集群的HDFS文件系统中。同时所述处理模块430会将用户文件的索引数据(包括其与合并文件的对应关系以及在合并文件中的偏移量)写入索引模块服务器上，以便用户访问文件。当异常导致数据无法写入HDFS时，则数据临时写入本地文件。定时扫描本地文件夹一次，及时将数据以上述流程写入集群。当用户上传文件时所述处理模块430的运行过程是控制器启动线程从kafka的未消费缓存队列集合中逐个获取用户文件，并写入到维护的序列文件集合(map)中。如果文件集合值达到128M时，控制器将集合中的文件合并写入到HDFS中的序列文件中。当写入成功，控制器将操作日志写入到log中，并将用户文件的索引写到索引模块所在的服务器上，同时将kafka中刚刚消费的队列中相应文件记录删除。这样一次完整的合并操作完成。kafka继续获取用户文件并保存到对应的缓存topic队列中，如果上传文件获取结束但是处理模块维护的序列文件集合未达到128M，则进行休眠，等待下次执行。其中，Map表中预设数据写入HDFS进程的DataHDFSWriter的更新策略说明：DataHDFSWriter对象中保持最新的操作时间戳，DataWriter对象中保持上一次扫描Map列表的时间，线程根据上一次的扫描时间与当前时间的差大于阈值则对Map列表中的DataHDFSWriter进行扫描更新，判断当前时间和HDFSWriter最后的操作时间差是否大于阈值，线程读取队列设置超时时间。同时，DataHDFSWriter还进行写入文件大小的更新，当超过一定的阀值的时候，创建一个新的文件接收数据。

其中，所述处理模块430包括控制器和操作日志模块。

其中，所述操作日志模块用于记录控制器的操作信息，包括HDFS合并文件创建信息、小文件合并信息、索引数据信息、缓存删除信息等。

在本实施例中，通过记录HDFS合并文件创建信息、小文件合并信息、索引数据信息、缓存删除信息等，可以使得管理员随时查看日志信息时，能够准确获取所有的小文件合并信息，进而对小文件的合并进行监管。

操作日志模块是针对小文件建立高效的索引系统，当用户检索小文件的时候，只需要获得该索引，则直接可与对应的Hadoop集群中的服务器直连，读取对应的文件数据。针对大文件的索引直接使用Hadoop系统自带的namenode索引系统即可。目的是保障整个系统数据的可追溯，保障数据不丢失。日志结构如下：

Log(操作日志)记录运行过程是当在HDFS上创建好sequenceFile时，记录A，相当于给出在HDFS上建立一个文件夹目录，同时也会在Hadoop集群中建立对应的文件名索引标记。控制器从序列文件集合中逐个写入云存储完成时，记录B，这个过程是真正写入hdfs集群的过程。当小文件合并写入结束后，记录C，该记录给出该消费队列中数据消费完成的标记。接着向redis写入索引数据，并记录D，给出建立索引的进度和标记。删除在kafka中的消费队列中的数据，记录E。在完成所有操作并清空集合后，记录F。整个合并过程完成后删除Log，并创建新的日志文件。

所述数据索引模块440用于为用户所上传的数据分配唯一标识符和索引。通过为用户所上传的数据分配唯一标识符和索引，使得用户在进行检索时，能够更加快捷与便利，以及使得不同用户所上传的数据之间相互区别，进而有效地避免了数据混乱。以及通过分配唯一的标识符可以有效地保障系统中同一权限下文件的唯一性，提高系统的性能。

作为一种实施方式，所述数据索引模块440包括两个部分。第一个部分是系统中文件的唯一标识的分配字段，包括上传文件的分配字段和整合后的文件分配字段，分配唯一的ID可以保障系统中同一权限下文件的唯一性，提高系统的性能。这两个文件分配字段，分别对应两个64位的有符号整数字段，因此，所述适合大小文件的海量医疗数据存储系统400可以支持的文件数为2的63次方－1个，这样可以尽可能保障系统存储文件的多样性。第二部分是文件的索引，每条索引的数据形式是集合，采用集合的原因是每条索引需要记录小文件相关的一些属性。集合的Key是上传时为文件分配的唯一标识，集合中的元素包括：小文件的文件名ID(用于后去获得文件名)、包含该小文件的SequenceFile的标识(用于在存储集群中找到具体的存储文件夹)、该文件在SequenceFile中的偏移量(用于在存储集群中对应的文件中找到具体的数据)、该文件是否属于公开文件(初步判断该文件的权限)、文件的权限范围(当文件是非公开的时候，详细定位该文件的使用范围)、是否已被删除(判断文件是否被删除)。

在本实施例中，通过为上传文件的分配字段和整合后的文件分配字段分配64位的有符号整数字段，从而有效地提高了存储文件的多样性。使得文件的存储类型更加丰富，同时使得用户在进行数据查询时，能够查询更加多的资源，进一步为用户提供了便利。

在本实施例中，通过在每条索引的数据形式中设置判断“该文件是否属于公开文件”属性，从而使得用户在进行检索或者是其他用户在进行检索时，能够快速判断该文件是否公开，进一步使得用户能够快速获取文件正文，减少用户检索文件时间，从而增强了用户体验感。

所述接口模块450用于提供上传、查看下载、删除文件的接口，以使用户通过所述接口模块完成用户文件上传、下载或删除操作。

例如，当用户进行文件上传时，用户先通过所述负载均衡模块460，获得当前时刻条件下，最优的所述接口模块450所在的服务器。所述接口模块450作为缓存模块的一个客户端，使用事物机制(该机制可以确保每次读写id分配字段是一个完整的事物，会排斥多线程情况下其他客户端的读写请求)操作文件id分配字段自增，获取一个唯一的id，同时根据登录的账户获得“院区＿科室＿身份＿用户名”信息。再通过所述接口模块450使用获取的唯一id和“院区＿科室＿身份＿用户名”信息，将这个组合作为key，将上传的文件写入到数据缓存模块480中的上传缓存集合中，并且根据不同的topic(院区＿科室＿身份＿姓名)分配不同的队列。具体数据上传的时候使用MINA框架将数据根据通讯协议打包成一个完整的协议数据包后放入数据缓冲队列。最后再通过所述处理模块430遍历各个topic的上传缓存队列，将还未写入HDFS的小文件进行分别聚合，并记录下每个小文件在聚合文件中的偏移量，在达到聚合文件的大小上限后，将聚合文件上传到HDFS中，同时在Redis中为每个已被整合的小文件添加索引，然后删除上传缓存中已被整合的小文件。当某一台接口模块服务器出现故障或者负载过高的时候，下次任务会自动分配到其他没有故障或者性能好的服务器上。当所述处理模块430所在服务器集群出现故障或者数据一直没有达到128M，则会将数据先持久化到本地磁盘。

又如，当用户进行文件下载查看时，先通过所述负载均衡模块460判断出该用户的此处操作是查看下载。当判断用户的操作是查看下载的时，则查找所述数据缓存模块480中的下载缓存中的热点文件，该保存也是key－value，通过key判断文件是否存在以及权限是否满足，当同时满足的时候，即可返回数据到，同时更新该文件在下载缓存中的时间和下载次数。再通过所述数据索引模块440中检索对应的小文件，当存在的时候，用户对应的接口模块450直接跟索引存储模块490的服务器交互，得到文件数据流。同时将该文件的索引和内容加重到数据缓存模块480中的下载缓存队列中。当没有得到数据的时，再直接去hadoop存储集群的namenode的文件索引中查找文件，如果有，再去索引存储模块490中的大文件索引文件中匹配文件权限，当满足条件的时候，直接获得文件所在的存储服务器，用户的接口模块450直接与对应的存储服务器通信获取数据。同时，将该文件的索引和内容加重到数据缓存模块480中的下载缓存队列中。若仍没有数据返回，则返回“无匹配数据”。

所述负载均衡模块460用于根据用户发送的消息包中所携带的用户的IP和操作信息，对所述用户发送的消息包进行解析，然后根据IP和操作的类型选择对应的服务器组。

以及还用于获得各个服务器的性能状态，然后再根据每个所述服务器的性能状态选择多个所述服务器中的任意一个所述服务器，从而将数据报文中的目标地址修改为所述服务器所对应的地址。

作为一种实施方式，所述负载均衡模块460使用7层负载均衡模式。当用户使用所述适合大小文件的海量医疗数据存储系统400的时候，用户访问首先要经过所述负载均衡模块460，并且根据用户发送的消息包中包含用户的IP和操作等信息，所述负载均衡模块460先对用户发送的消息包进行解析，然后根据IP和操作的类型选择对应的服务器组，并且所述负载均衡模块460中也获得各个服务器的性能状态，然后再根据这些服务器的性能状态选择该组里面的某一个服务器，从而将数据报文中的目标地址改成具体的某台RealServer，端口也改成RealServer的端口，当给用户分配好服务器后，该次操作就直接与该服务器进行通信，上传、下载、删除文件等操作就不在通过所述负载均衡模块460。从而可以平衡服务器的压力，方便后续系统的扩容，同时也提高了系统的稳定性。

所述元数据模块470，用于存储用户的注册信息和文件名的编号信息，以使用户注册后能够快速进行查询和更新操作。

所述数据缓存模块480，用于缓存用户上传或下载的数据。

作为一种实施方式，所述数据缓存模块480采用消息队列的方式实现。其中，消息队列是设计大规模分布式系统时经常使用的中间件产品。分布式系统构件之间通过传递消息可以解除相互之间的功能耦合，这样可以减轻子系统之间的依赖，使得各个子系统或者构件可以独立演进、维护或重用。消息队列是在消息传输过程中保存消息的容器或中间件，其主要目的是提供消息路由并保障消息可靠传递。Kafka消息队列在系统中的作用主要在于作为缓存，其缓存的数据包括新上传的等待处理模块整合小文件、热点数据。优选地，所述数据缓存模块480包括上传缓存和下载缓存。其中，所述上传缓存用来缓存等待处理模块430整合的小文件，它消息队列中以集合的形式存在。集合中的每个元素是缓存的小文件，以Key－Value形式存在于集合中，Key是上传文件时接口层为它分配的唯一标识，Value是序列化后的文件内容，并且开头是用户的身份等信息。并且对数据进行批量消费，当一个topic中的数据达到128M的时候，则调用数据处理模块，将数据以sequencefile形式写入存储集群。当没有及时消费或者后端模块出现消费问题的时候，例如，所述后端模块可以是索引存储模块490或数据索引模块440等，则将数据先持久化到磁盘并做replication防止数据丢失，当数据达到128M或者问题恢复，则先从磁盘中消费数据。其中，所述下载缓存用于存储最近访问的热点文件，在数据库中，它的存在形式也是集合，元素形式与上传缓存相同。例如，当用户访问了一个小文件后，通过热点文件的统计机制和时间热度将其加载到下载缓存中。

所述索引存储模块490用于存储文件索引。

在本实施例中，为了避免文件索引存储错乱，优选地，所述索引存储模块490根据预设规则对每个文件索引进行存储，其中，所述预设规则为所述索引存储模块490获取每个文件索引的首字符，再通过ASCII进行转换，获取每个文件索引的首字符所对应的数值，以及将每个文件索引所对应的唯一标识符通过ASCII进行转换，获取每个文件索引所对应的唯一标识符所对应的数值，将所述每个文件索引的首字符所对应的数值与每个文件索引所对应的唯一标识符所对应的数值进行相加，最后按照大小顺序进行排序，并存储。

综上所述，本发明提供的适合大小文件的海量医疗数据存储系统及数据存储方法，通过用户注册模块来监控实际注册用户，从而有效地防止非法用户进行注册，进而有效地避免了非法用户进行数据的访问，通过监控报警模块可以实时监控各个存储服务器和各个服务模块的运行状态，以及当所述系统或服务状态异常时发送邮件或短信报警，使得第一时间通知系统管理人员，以及在状态恢复后发出正常的邮件或短信通知，以使用户能够在正常后进行及时使用，再通过处理模块、数据索引模块、接口模块和负载均衡模块使得针对医疗领域适合海量大文件、小文件并存的应用场景，解决了传统关系型数据库不适合非结构化数据的问题、解决了redis不适合海量数据存储的问题、改善了只采用hbase做存储时候面临的系统不稳定的问题、极大改善了单纯采用hdfs中解决小文件存储所面临的不适合大文件和文件不方便检索的问题。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本发明各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read－Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

Claims (9)

1.一种适合大小文件的海量医疗数据存储系统，其特征在于，包括：用户注册模块、监控报警模块、处理模块、数据索引模块、接口模块和负载均衡模块；

所述用户注册模块用于管理院区信息、科室信息以及用户名信息；并且还用于在进行用户注册新增操作时，使得用户需要按照预设规则进行注册，当不满足所述预设规则时，发送提示信息至用户终端；当注册成功时，为所述用户赋予文件操作权限，以及将所述用户信息按照预设格式进行存储；

所述监控报警模块用于实时监控各个存储服务器和各个服务模块的运行状态，以及当所述系统或服务状态异常时发送邮件或短信报警，使得第一时间通知系统管理人员，以及在状态恢复后发出正常的邮件或短信通知，以使用户能够在正常后进行及时使用，以及用于在出现部分单一性的错误问题时，所述监控报警模块实现自动修复同时发出报错信息和恢复信息；

所述处理模块用于将用户上传的海量小文件按照预设处理规则分组合并成sequenceFile，并根据不同的队列进行合并所述文件，进而减少用户访问数据的压力；

所述数据索引模块用于为用户所上传的数据分配唯一标识符和索引；

所述接口模块用于提供上传、查看下载、删除文件的接口，以使用户通过所述接口模块完成用户文件上传、下载或删除操作；

所述负载均衡模块用于根据用户发送的消息包中所携带的用户的IP和操作信息，对所述用户发送的消息包进行解析，然后根据IP和操作的类型选择对应的服务器组；

以及还用于获得各个服务器的性能状态，然后再根据每个所述服务器的性能状态选择多个所述服务器中的任意一个所述服务器，从而将数据报文中的目标地址修改为所述服务器所对应的地址。

2.根据权利要求1所述的系统，其特征在于，所述处理模块具体用于：

从kafka的未消费缓存队列集合中逐个获取用户文件，并写入到预设的维护的序列文件集合中；

判断所述序列文件集合的值是否达到预设值；

若是，将所述序列文件集合中的文件合并写入到HDFS中的序列文件中；

当写入成功后，将操作日志写入到log中，并将所述用户文件的索引写到所述数据索引模块所在的服务器上，同时将所述kafka中刚刚消费的队列中相应文件记录删除；

若否，则进行等待直到所述序列文件集合的值达到所述预设值。

3.根据权利要求2所述的系统，其特征在于，所述处理模块包括控制器和操作日志模块。

4.根据权利要求1所述的系统，其特征在于，还包括元数据模块，所述元数据模块，用于存储用户的注册信息和文件名的编号信息，以使用户注册后能够快速进行查询和更新操作。

5.根据权利要求1所述的系统，其特征在于，还包括数据缓存模块，所述数据缓存模块，用于缓存用户上传或下载的数据。

6.根据权利要求1所述的系统，其特征在于，还包括索引存储模块，所述索引存储模块用于存储文件索引。

7.一种数据存储方法，其特征在于，应用于如权利要求1所述的适合大小文件的海量医疗数据存储系统，包括：

所述负载均衡模块获取用户上传的用户文件，并将所述用户文件发送至所述接口模块；

所述接口模块将所接收到的所述用户文件发送至缓存模块，以使所述缓存模块将所述用户文件上传至所述处理模块；

所述处理模块从kafka的未消费缓存队列集合中逐个获取用户文件，并写入到预设的维护的序列文件集合中；

所述处理模块判断所述序列文件集合的值是否达到预设值；

若是，所述处理模块将所述序列文件集合中的文件合并写入到HDFS中的序列文件中；

当写入成功后，所述处理模块将操作日志写入到log中，并将所述用户文件的索引写到所述数据索引模块所在的服务器上，同时所述处理模块将所述kafka中刚刚消费的队列中相应文件记录删除；

若否，所述处理模块进行等待直到所述序列文件集合的值达到所述预设值。

8.根据权利要求7所述的方法，其特征在于，所述的所述处理模块判断所述序列文件集合的值是否达到预设值，包括：

所述处理模块判断所述序列文件集合的值是否等于128兆。

9.根据权利要求7所述的方法，其特征在于，所述的所述处理模块从kafka的未消费缓存队列集合中逐个获取用户文件，并写入到预设的维护的序列文件集合中，之前还包括：

判断本地服务器预设目录下是否有数据；

若有，获取所述数据。

Images