针对现有的多生理参数实时监测系统中,由于终端用户数量增加和上传数据加大所导致的服务后台数据一致性无法保证、生理参数存储与处理能力不足、实时性较差以及数据利用率低等问题,提出了基于云计算的多生理参数监测后台数据集群存储与并行处理新模式。通过对监测系统云平台的基础设施即服务层资源虚拟化、平台即服务层实时计算平台的构建、软件即服务层数据流的接收与分析,以及多生理参数流传输通路瓶颈问题等方面的研究,实现了生理信息大数据量的实时传输、存储与集群处理,并可利用批处理对患者的历史数据实现纵向分析。仿真测试结果表明:基于云平台的远程多生理参数监测系统在集群数据处理时间和负载平衡方面,比传统的服务器模式具有明显的优势。该平台解决了传统远程医疗服务中数据周转时间长、实时分析算法误差较大和架构拓展困难等问题,为多生理参数无线监测以专业的"穿戴式无线传感+移动终端无线传输+云计算服务"模式走向家庭健康监测提供了技术支撑。
引用本文： 朱凌云, 李连杰, 孟春艳. 远程多生理参数实时监测云服务平台的构建与分析. 生物医学工程学杂志, 2014, 31(6): 1377-1383. doi: 10.7507/1001-5515.20140261 复制
引言
目前，基于无线通信终端的多生理参数监测系统在医院患者集群监控、亚健康人群生命体征在线监测以及疾病预警等方面发挥了重要的作用。随着监测人数和监测生理参数类别的不断增加，需要传输的数据量日益庞大。但是，现有远程实时监控的数据处理及服务端大多设在医院，多生理参数监测模式则是将数据传输至医院进行集中分析和管理。这种模式存在如下问题：首先，大多数医院工作站采用计算机单机或者简单的计算机集群，存在数据分析能力不足、存储空间受限等问题；其次，现有的模式是将数据上传至服务器，再转发至医院监护中心进行分析和处理，不同的监测系统、不同的医院都有一套自身的数据传输模式、监测模式和数据管理模式，导致用户在不同医院的数据一致性不能得到保障；再次，数据从终端到工作站要经过多次中转才能分析与处理，存在数据延迟，影响系统的实时性，无形中为监测结果的实时性服务设置了技术障碍。另外，在现代多生理参数实时监测中，由于手机的运用，数据规模在后台数据存储中呈爆炸式增长，特别是当数据基数达到一定程度成为大数据(Big Data)后，在考虑如何高效分析集群实时海量数据的同时，如何对每位患者的大量历史数据进行纵向分析、对区域及特定年龄段患者的大数据进行关联分析，以生成可供参考及决策的报表，也日益成为医院大数据库亟待解决的问题。
近年来，移动互联网、无线体域网(Wireless Body Area Network，WBAN)及针对大数据处理的云端并行计算高速发展，使得无线数据高速采集、并行计算和实时处理性能得到进一步的提升[1]。这些都为多生理参数架构向普适性、大数据量、强实时性以及高准确率方向发展提供了技术支持，同时也对传统远程多生理参数服务平台提出了更高的要求。因此，针对当前环境，研究面向手机用户的，提供实时集群分析、大数据存储和处理的生理参数监测与服务平台是非常必要的。
1 面向大数据实时处理的多生理参数监测架构
基于云服务平台的远程多生理参数实时监测系统，主要由用户前端体域网、移动监护终端机(智能手机)以及云计算(Cloud Computing)数据管理与服务中心组成，其系统架构如图 1所示。云计算数据中心接收到前端采集模块的患者生理数据流后，将完成用户现有数据的实时分析、现有数据与历史数据的关联分析以及其它统计段数据的实时分析，以充分利用云服务端较强的并行处理能力。云端还可对前端数据采集模块和移动监护终端进行反馈控制，可实现多用户集群数据的云端存储、数据分析结果分级推送、用户综合信息管理，并能根据数据处理结果由医生给出全面的医疗决策与服务。在这种设计模式中，云端不但为用户、医生和医院构建了一个公共的数据池，同时也为三者提供了技术共享与更好的专业服务。
图1
多生理参数云端监测架构
Figure1.
Cloud computing architecture for multiple physiological parameters
2 多生理参数实时监测云服务平台的相关技术
2.1 云计算及Storm实时计算框架
云计算将计算任务分布在多台计算机构成的资源池上，使各种应用系统能够根据需要获取计算能力、存储空间和信息服务[2]。云计算一般包括多种层次的服务：基础设施即服务(Infrastructure as a Service,IaaS)、平台即服务(Platform as a Service,PaaS)和软件即服务(Software as a service,SaaS)。目前，应用最广泛的开源云平台是Google的Hadoop云平台[3]。但是，Hadoop及其相关技术都不是针对数据流实时处理系统的，对于多生理参数监测这种集群用户数据流并行处理要求较高的情况不太适用。随着终端用户的急剧增长，大规模实时数据处理已经成为移动互联网亟待解决的问题。特别是对于实时性要求比较高的多生理参数在线监测系统，Storm以其独特的设计风格显示了实时处理的技术优势[4]。与其他大数据解决方案不同，Storm对于数据处理的方式存在较大差别：支持创建拓扑结构来转换没有终点的数据流，并可持续处理到达的数据；数据从外部来源流入Storm拓扑结构中，根据具体分析算法来处理数据。这种与MapReduce截然不同的设计风格，使得Storm能够保证大数据处理的实时性[5]。
2.2 多生理参数实时监测私有云的资源虚拟化
构成云计算的核心部分之一就是虚拟化(Virtualization)技术，也是将各种计算资源及存储资源充分整合和高效利用的关键技术[6]。虚拟化是云计算区别于其它并行计算的重要特征，通过虚拟化可以为一组类似资源提供通用的抽象接口集，从而隐藏属性和操作之间的差异，并允许采用通用的方式来查看和维护资源[7]。由于虚拟机是一类特殊的软件，能够完全模拟硬件的执行，因此可在虚拟机上运行操作系统，进而能够保留一整套运行环境语义[8]。将虚拟化技术应用到云计算平台，可以获得普通并行计算所不具备的良好特性。多生理参数监测云平台属于私有云规模，其资源的虚拟化则应根据监测用户的规模、用户上传数据规模以及所提供的服务内容来确定。
2.3 Topology编程模型
Topology是Storm云平台的主要编程模型，由多个spout和bolt组成，是任务运行时所有计算节点拓扑结构的集合[9]。消息源spout是Topology的消息生产者，可从外部源读取数据并且向topology发出消息tuple，而所有的消息处理逻辑都封装在bolts里面。bolts可以完成过滤、聚合、查询数据库等操作，也可以传递简单的消息流。而对于复杂的消息流处理，如多生理参数的监测处理，往往需要较多步骤，也就需要多个bolts协同完成[10]。因此，可以将多生理参数的分析算法拆分为多个细粒度的子分析过程，从而为规模数据与复杂算法的并行化处理提供技术支撑。
3 多生理参数监测云平台数据中心的构建
3.1 多生理参数云端硬件资源的虚拟化设计
云服务平台IaaS层的主要任务是把计算和存储等物理资源虚拟为可供调度的资源池，并为用户以云计算的模式提供使各种资源。IaaS层主流开源平台有Eucalyptus、OpenStack和ConVirt等[11]。Eucalyptus 是一种开源GPL协议下，通过计算集群或服务集群上的部署，实现云计算环境弹性需求的软件基础结构。结合多生理参数实时监测的需求，数据中心选择Eucalyptus作为资源虚拟化工具，其云平台IaaS层架构如图 2所示。通过虚拟化设计，可构建符合多生理参数监测等特定需求的私有云及混合云，将电脑、网络和存储等数据中心资源纳入可控制的云，用户在该平台上可运行和控制部署在各种虚拟物理资源上的应用实例。Eucalyptus管理系统的服务最终依赖于底层云计算资源提供，搭建底层云计算环境的目的在于为资源的虚拟化管理应用提供支持环境，使用户可以通过中间件访问底层云计算资源。多生理参数云端的这种设计，不仅让医院从投资、维护庞大的远程医疗平台硬件中解脱出来，使得医生和监护者不再担心平台运行的稳定性和可靠性，更重要的是使得不同医院监护者的数据在实现共享的同时，也保证了其数据资源的一致性。同时，也使得监护者、医院和医生更加关注云端的服务内容和服务质量。
图2
IaaS层架构示意图
Figure2.
Schematic diagram of IaaS layer architecture
3.2 多生理参数云端数据中心的架构设计
多生理参数监测服务平台数据中心采用典型的层次化服务模型架构，其体系构成如图 3所示。数据中心将从IaaS、PaaS、SaaS三个层次分别提供多生理参数监测的云端数据存储、管理和服务。IaaS提供数据中心的基础设施共享和虚拟化服务，其中的基础设施包括各种提供计算和存储能力的硬件资源；PaaS提供数据管理的平台服务，如安全数据访问、高效数据存储、实时计算等；SaaS则提供远程医疗的智能化信息服务，如海量数据接收、智能化数据分析和诊断结果前端推送等。为满足多生理参数实时监测的需求，选用Twitter公司的Storm云平台提供实时计算基础服务，以此为基础在SaaS层整合了Hbase分布式数据库和Kestrel分布式队列，以便安全、高效地实现监测数据的实时分析与存储。
图3
数据中心整体架构示意图
Figure3.
Schematic diagram of data center architecture
3.3 多生理参数监测云端的数据存储
远程多生理参数监测服务平台需要存储多种类型的数据，包括生理数据和系统管理中各实体信息。为此，其数据存储采用分布式数据库和关系型数据库的双数据库设计。分布式数据库主要负责大数据的存储，其底层采用HDFS实现，数据库则采用Hbase。HDFS采用master/slave架构，主要设计部署在大量廉价机器上的分布式文件系统。每个HDFS集群由一个NameNode节点和一组DataNode节点组成，适合多生理参数等大数据集的应用程序。医疗信息管理系统的数据库则采用MySql实现，可适应复杂的数据逻辑关系，并使云平台与java主流的web框架集成度显著增加。
3.4 多生理参数集的关联分析
大数据或称海量数据，是指所涉及的数据量规模巨大，无法通过目前主流软件工具在合理时间内进行撷取、管理、处理[8]。云端存储的多生理参数监测用户较多，而用户的数据记录也较多，除了需要实现某一时段的集群用户不同数据段的分析外，还要求实现用于预测单个用户健康态势的现有数据与历史数据的关联分析，以及某年龄段或某区域人群的感兴趣数据分析。对于上述大数据关联分析需求，现有的远程医疗软件平台和医院服务器集群都无法实现。为此，鉴于上述数据分析的时效性要求不太苛刻，对其采用Hadoop批处理平台以满足上述需求，并通过运用MapReduce编程模型，实现患者海量历史数据的不同需求分析。例如，在对不同年龄段数据进行分析时，可用Map函数接受患者生理数据并将其转换为一个键/值对列表，输入域中的每个元素对应一个键/值对，Reduce函数接受Map函数生成的列表，然后根据不同年龄段的键值缩小键/值对列表，最后输出每一年龄组的分析结果。
3.5 多生理参数监测云平台的数据流程
云端数据中心服务流程如图 4所示，主要分为数据输入、数据计算、数据持久化与前端展示三部分。数据输入端负责处理患者监控节点的数据传输请求，并把接收到的生理数据放入分布式队列，作为数据中心的待处理数据源。数据中心可根据当前待处理数据量的大小合理分配资源，并把处理后的数据存放在分布式数据库或者前端进行展示。
图4
云平台服务流程图
Figure4.
Flow chart of cloud platform services
集群处理分为实时计算和批处理计算两个部分。实时计算Storm平台根据节点处理功能的不同又将节点分为两类:控制节点(master node)和工作节点(worker node)。控制节点上面运行后台程序Nimbus，负责代码在集群里面的分布，给机器分配工作，并且监控运行状态。每一个工作节点上面运行一个Supervisor的节点，以监听相应的机器，并根据需要启动/关闭工作进程。计算任务可根据具体算法流程封装成相应的Topology，患者数据流入Topology后由工作进程负责每一步具体的数据计算，每个工作进程都执行一个Topology的子集；而每个Topology都由运行在大量机器上的很多工作进程组成，患者的数据流在这些工作进程上进行计算，完成实时分析与处理。
在批处理方面，Hadoop平台存在两类节点：JobTracer和TaskTracker。JobTracer是Hadoop 集群中唯一负责控制MapReduce应用程序的系统。在应用程序提交之后，将提供包含在HDFS中的输入和输出目录。MapReduce应用程序被复制到每个出现输入文件块的节点，将为特定节点上的每个文件块创建唯一的从属任务，每个TaskTracker将状态和完成信息报告给JobTracker。在特定的时间段，如每天或者每个星期，Hadoop集群会定时启动，以完成用户数据关联分析，并生成报表供参考或者决策。这样，既充分利用数据资源，实现了对多生理参数实时分析的补充，也使得生理数据分析的准确度性和完备性进一步提高。
多生理参数监测状况前端展示主要面向监护者和医院。由于两类用户所要求展示信息有所区别，例如监护者更关注自己有无疾病、身体是否健康，而医院和医生可能更关注数据分析的结果以及数据分析本身，因此推送的结果和内容存在差异。多生理参数监测状况前端展示设计有两种模式，一种是面向医院所采用的富客户端B/S模式，另一种是面向监护者智能手机的App模式。考虑到医生对心电、血压、血氧饱和度等重要参数的实时波形显示等特殊需求，web前端采用javascript和flex等工具实现富客户端，从而增加本地数据处理逻辑，并减少服务器负载水平。
4 多生理参数监测云平台服务性能的优化
4.1 高性能网络服务器的优化
引入云平台之后，多生理参数监测过程中数据实时计算能力得到提高，数据资源的有效利用率得到了大幅度提升，但平台入口接收实时数据的能力还有待改进。由于在实际应用中可能存在数以千计的移动终端同时连接服务器申请服务，因此，需要针对并发连接进行优化。Netty是由JBOSS提供的一个java开源框架，提供异步的、事件驱动的网络应用程序框架和工具，吸收了多种协议的实现经验，包括FTP、SMTP、HTTP、各种二进制以及文本协议等，使其稳定性和伸缩性得到提高。因此，多生理参数监测云服务平台采用Netty快速开发高性能、高可靠性的网络服务器和客户端程序。
4.2 分布式消息队列
由于医疗行业必须保证数据的可靠性与完整性，因此系统引入了分布式队列来作为技术保障。分布式消息队列可提供更好的可靠性和安全性，主要表现在如下几方面：消息会被持久化到分布式存储中，避免了单台机器存储的消息由于机器问题导致消息的丢失；当网络环境不佳时，保证只有当消息的接收者确实收到消息时才从队列中删除该消息；各业务的消息内容是安全存储的，其它业务不能访问到非自身业务的数据；当访问量和数据量增大时，分布式消息队列服务可以自动扩展。
上述设计使得当服务器负载水平显著增加时，可在不改动体系架构的情况下迅速增强系统的处理能力。
5 系统仿真与结果分析
为验证多生理参数实时监测云端平台构建的效果与合理性，对云服务器的相关性能进行了系统仿真与测试。在测试环境构建时，所采用的Eucayptus版本是最新的开源版本2.0.2版，虚拟机版本为Xen3.4.2，采用源码方式安装；各物理机安装的JDK版本为JDK1.6.0_13，使用的操作系统均为Ubuntu10.04。其中一台物理机安装Eucayptus的CLC、CC、WS3和SC节点，共有四台虚拟机安装在NC节点，每台均安装了Ubuntu10.04操作系统、Storm云平台及其它支撑软件。将其中的一台虚拟机设置为主服务器，负责接收手机端发送的数据并管理Storm集群。
为了测试云服务器的性能，在手机端分别模拟100~500个请求同时连接服务器并发送数据，云平台则对生理参数进行FFT变换，以实现多生理参数的预处理。在测试数据序列长度N=1 024、每台终端连续发送3 min的情况下，云服务器与传统服务器处理情况对比效果如图 5和图 6所示。
图5
云服务器与传统服务器负载水平对比
Figure5.
Cloud server load capacity compared with the traditional server
图6
云服务器与传统服务器处理时间对比
Figure6.
Cloud server processing time compared with the traditional server
由此可以看出，在数据量比较小的时候，由于传统服务器环境下数据都在本地处理，因此速度要快于集群云端。随着数据量的增长，传统服务器负载水平上升较快，而云服务器依赖负载均衡调度算法，把任务分给多个计算节点，提供了强大的服务能力，较好地解决了大数据量多生理参数的复杂计算问题。
6 结束语
针对多生理参数监测中数据量大和实时性高等特点进行了集群数据处理的云端平台构建与设计。与传统远程医疗系统服务平台相比，主要有以下特点：在弹性计算和存储方面，数据中心对底层硬件资源进行了虚拟化，使其能根据系统实际的负载状况合理分配资源，在运算任务较少的时间段可关闭部分服务器，降低运营成本；在数据库构建方面，由于数据中心需要对大数据和关系紧密型数据进行分别处理，因此采用了关系型数据库和非关系型数据库共存的双数据库设计，解决了大数据的处理、存储和内部实体关系复杂的医疗信息管理系统需求的矛盾，使系统的逻辑层和数据库设计更加合理；在分布式计算方面，将实时计算与批处理计算共存，在Sorm实时计算的基础上，引入Hadoop批处理用于对患者历史数据的纵向分析，两部分以HDFS分布式数据存储作为结合点，使患者生理数据分析的准确性和完备性得到进一步的提高。上述平台的构建，克服了传统多生理参数监测平台数据容量有限、分析能力不足、数据资源利用率低、共享数据的一致性较差等弊端，解决了传统远程医疗服务中数据周转时间长、架构拓展困难等问题，为多生理参数无线监测以专业的“穿戴式无线传感+移动终端无线传输+云计算服务”模式走向家庭健康监测提供了技术支撑。
引言
目前，基于无线通信终端的多生理参数监测系统在医院患者集群监控、亚健康人群生命体征在线监测以及疾病预警等方面发挥了重要的作用。随着监测人数和监测生理参数类别的不断增加，需要传输的数据量日益庞大。但是，现有远程实时监控的数据处理及服务端大多设在医院，多生理参数监测模式则是将数据传输至医院进行集中分析和管理。这种模式存在如下问题：首先，大多数医院工作站采用计算机单机或者简单的计算机集群，存在数据分析能力不足、存储空间受限等问题；其次，现有的模式是将数据上传至服务器，再转发至医院监护中心进行分析和处理，不同的监测系统、不同的医院都有一套自身的数据传输模式、监测模式和数据管理模式，导致用户在不同医院的数据一致性不能得到保障；再次，数据从终端到工作站要经过多次中转才能分析与处理，存在数据延迟，影响系统的实时性，无形中为监测结果的实时性服务设置了技术障碍。另外，在现代多生理参数实时监测中，由于手机的运用，数据规模在后台数据存储中呈爆炸式增长，特别是当数据基数达到一定程度成为大数据(Big Data)后，在考虑如何高效分析集群实时海量数据的同时，如何对每位患者的大量历史数据进行纵向分析、对区域及特定年龄段患者的大数据进行关联分析，以生成可供参考及决策的报表，也日益成为医院大数据库亟待解决的问题。
近年来，移动互联网、无线体域网(Wireless Body Area Network，WBAN)及针对大数据处理的云端并行计算高速发展，使得无线数据高速采集、并行计算和实时处理性能得到进一步的提升[1]。这些都为多生理参数架构向普适性、大数据量、强实时性以及高准确率方向发展提供了技术支持，同时也对传统远程多生理参数服务平台提出了更高的要求。因此，针对当前环境，研究面向手机用户的，提供实时集群分析、大数据存储和处理的生理参数监测与服务平台是非常必要的。
1 面向大数据实时处理的多生理参数监测架构
基于云服务平台的远程多生理参数实时监测系统，主要由用户前端体域网、移动监护终端机(智能手机)以及云计算(Cloud Computing)数据管理与服务中心组成，其系统架构如图 1所示。云计算数据中心接收到前端采集模块的患者生理数据流后，将完成用户现有数据的实时分析、现有数据与历史数据的关联分析以及其它统计段数据的实时分析，以充分利用云服务端较强的并行处理能力。云端还可对前端数据采集模块和移动监护终端进行反馈控制，可实现多用户集群数据的云端存储、数据分析结果分级推送、用户综合信息管理，并能根据数据处理结果由医生给出全面的医疗决策与服务。在这种设计模式中，云端不但为用户、医生和医院构建了一个公共的数据池，同时也为三者提供了技术共享与更好的专业服务。
图1
多生理参数云端监测架构
Figure1.
Cloud computing architecture for multiple physiological parameters
2 多生理参数实时监测云服务平台的相关技术
2.1 云计算及Storm实时计算框架
云计算将计算任务分布在多台计算机构成的资源池上，使各种应用系统能够根据需要获取计算能力、存储空间和信息服务[2]。云计算一般包括多种层次的服务：基础设施即服务(Infrastructure as a Service,IaaS)、平台即服务(Platform as a Service,PaaS)和软件即服务(Software as a service,SaaS)。目前，应用最广泛的开源云平台是Google的Hadoop云平台[3]。但是，Hadoop及其相关技术都不是针对数据流实时处理系统的，对于多生理参数监测这种集群用户数据流并行处理要求较高的情况不太适用。随着终端用户的急剧增长，大规模实时数据处理已经成为移动互联网亟待解决的问题。特别是对于实时性要求比较高的多生理参数在线监测系统，Storm以其独特的设计风格显示了实时处理的技术优势[4]。与其他大数据解决方案不同，Storm对于数据处理的方式存在较大差别：支持创建拓扑结构来转换没有终点的数据流，并可持续处理到达的数据；数据从外部来源流入Storm拓扑结构中，根据具体分析算法来处理数据。这种与MapReduce截然不同的设计风格，使得Storm能够保证大数据处理的实时性[5]。
2.2 多生理参数实时监测私有云的资源虚拟化
构成云计算的核心部分之一就是虚拟化(Virtualization)技术，也是将各种计算资源及存储资源充分整合和高效利用的关键技术[6]。虚拟化是云计算区别于其它并行计算的重要特征，通过虚拟化可以为一组类似资源提供通用的抽象接口集，从而隐藏属性和操作之间的差异，并允许采用通用的方式来查看和维护资源[7]。由于虚拟机是一类特殊的软件，能够完全模拟硬件的执行，因此可在虚拟机上运行操作系统，进而能够保留一整套运行环境语义[8]。将虚拟化技术应用到云计算平台，可以获得普通并行计算所不具备的良好特性。多生理参数监测云平台属于私有云规模，其资源的虚拟化则应根据监测用户的规模、用户上传数据规模以及所提供的服务内容来确定。
2.3 Topology编程模型
Topology是Storm云平台的主要编程模型，由多个spout和bolt组成，是任务运行时所有计算节点拓扑结构的集合[9]。消息源spout是Topology的消息生产者，可从外部源读取数据并且向topology发出消息tuple，而所有的消息处理逻辑都封装在bolts里面。bolts可以完成过滤、聚合、查询数据库等操作，也可以传递简单的消息流。而对于复杂的消息流处理，如多生理参数的监测处理，往往需要较多步骤，也就需要多个bolts协同完成[10]。因此，可以将多生理参数的分析算法拆分为多个细粒度的子分析过程，从而为规模数据与复杂算法的并行化处理提供技术支撑。
3 多生理参数监测云平台数据中心的构建
3.1 多生理参数云端硬件资源的虚拟化设计
云服务平台IaaS层的主要任务是把计算和存储等物理资源虚拟为可供调度的资源池，并为用户以云计算的模式提供使各种资源。IaaS层主流开源平台有Eucalyptus、OpenStack和ConVirt等[11]。Eucalyptus 是一种开源GPL协议下，通过计算集群或服务集群上的部署，实现云计算环境弹性需求的软件基础结构。结合多生理参数实时监测的需求，数据中心选择Eucalyptus作为资源虚拟化工具，其云平台IaaS层架构如图 2所示。通过虚拟化设计，可构建符合多生理参数监测等特定需求的私有云及混合云，将电脑、网络和存储等数据中心资源纳入可控制的云，用户在该平台上可运行和控制部署在各种虚拟物理资源上的应用实例。Eucalyptus管理系统的服务最终依赖于底层云计算资源提供，搭建底层云计算环境的目的在于为资源的虚拟化管理应用提供支持环境，使用户可以通过中间件访问底层云计算资源。多生理参数云端的这种设计，不仅让医院从投资、维护庞大的远程医疗平台硬件中解脱出来，使得医生和监护者不再担心平台运行的稳定性和可靠性，更重要的是使得不同医院监护者的数据在实现共享的同时，也保证了其数据资源的一致性。同时，也使得监护者、医院和医生更加关注云端的服务内容和服务质量。
图2
IaaS层架构示意图
Figure2.
Schematic diagram of IaaS layer architecture
3.2 多生理参数云端数据中心的架构设计
多生理参数监测服务平台数据中心采用典型的层次化服务模型架构，其体系构成如图 3所示。数据中心将从IaaS、PaaS、SaaS三个层次分别提供多生理参数监测的云端数据存储、管理和服务。IaaS提供数据中心的基础设施共享和虚拟化服务，其中的基础设施包括各种提供计算和存储能力的硬件资源；PaaS提供数据管理的平台服务，如安全数据访问、高效数据存储、实时计算等；SaaS则提供远程医疗的智能化信息服务，如海量数据接收、智能化数据分析和诊断结果前端推送等。为满足多生理参数实时监测的需求，选用Twitter公司的Storm云平台提供实时计算基础服务，以此为基础在SaaS层整合了Hbase分布式数据库和Kestrel分布式队列，以便安全、高效地实现监测数据的实时分析与存储。
图3
数据中心整体架构示意图
Figure3.
Schematic diagram of data center architecture
3.3 多生理参数监测云端的数据存储
远程多生理参数监测服务平台需要存储多种类型的数据，包括生理数据和系统管理中各实体信息。为此，其数据存储采用分布式数据库和关系型数据库的双数据库设计。分布式数据库主要负责大数据的存储，其底层采用HDFS实现，数据库则采用Hbase。HDFS采用master/slave架构，主要设计部署在大量廉价机器上的分布式文件系统。每个HDFS集群由一个NameNode节点和一组DataNode节点组成，适合多生理参数等大数据集的应用程序。医疗信息管理系统的数据库则采用MySql实现，可适应复杂的数据逻辑关系，并使云平台与java主流的web框架集成度显著增加。
3.4 多生理参数集的关联分析
大数据或称海量数据，是指所涉及的数据量规模巨大，无法通过目前主流软件工具在合理时间内进行撷取、管理、处理[8]。云端存储的多生理参数监测用户较多，而用户的数据记录也较多，除了需要实现某一时段的集群用户不同数据段的分析外，还要求实现用于预测单个用户健康态势的现有数据与历史数据的关联分析，以及某年龄段或某区域人群的感兴趣数据分析。对于上述大数据关联分析需求，现有的远程医疗软件平台和医院服务器集群都无法实现。为此，鉴于上述数据分析的时效性要求不太苛刻，对其采用Hadoop批处理平台以满足上述需求，并通过运用MapReduce编程模型，实现患者海量历史数据的不同需求分析。例如，在对不同年龄段数据进行分析时，可用Map函数接受患者生理数据并将其转换为一个键/值对列表，输入域中的每个元素对应一个键/值对，Reduce函数接受Map函数生成的列表，然后根据不同年龄段的键值缩小键/值对列表，最后输出每一年龄组的分析结果。
3.5 多生理参数监测云平台的数据流程
云端数据中心服务流程如图 4所示，主要分为数据输入、数据计算、数据持久化与前端展示三部分。数据输入端负责处理患者监控节点的数据传输请求，并把接收到的生理数据放入分布式队列，作为数据中心的待处理数据源。数据中心可根据当前待处理数据量的大小合理分配资源，并把处理后的数据存放在分布式数据库或者前端进行展示。
图4
云平台服务流程图
Figure4.
Flow chart of cloud platform services
集群处理分为实时计算和批处理计算两个部分。实时计算Storm平台根据节点处理功能的不同又将节点分为两类:控制节点(master node)和工作节点(worker node)。控制节点上面运行后台程序Nimbus，负责代码在集群里面的分布，给机器分配工作，并且监控运行状态。每一个工作节点上面运行一个Supervisor的节点，以监听相应的机器，并根据需要启动/关闭工作进程。计算任务可根据具体算法流程封装成相应的Topology，患者数据流入Topology后由工作进程负责每一步具体的数据计算，每个工作进程都执行一个Topology的子集；而每个Topology都由运行在大量机器上的很多工作进程组成，患者的数据流在这些工作进程上进行计算，完成实时分析与处理。
在批处理方面，Hadoop平台存在两类节点：JobTracer和TaskTracker。JobTracer是Hadoop 集群中唯一负责控制MapReduce应用程序的系统。在应用程序提交之后，将提供包含在HDFS中的输入和输出目录。MapReduce应用程序被复制到每个出现输入文件块的节点，将为特定节点上的每个文件块创建唯一的从属任务，每个TaskTracker将状态和完成信息报告给JobTracker。在特定的时间段，如每天或者每个星期，Hadoop集群会定时启动，以完成用户数据关联分析，并生成报表供参考或者决策。这样，既充分利用数据资源，实现了对多生理参数实时分析的补充，也使得生理数据分析的准确度性和完备性进一步提高。
多生理参数监测状况前端展示主要面向监护者和医院。由于两类用户所要求展示信息有所区别，例如监护者更关注自己有无疾病、身体是否健康，而医院和医生可能更关注数据分析的结果以及数据分析本身，因此推送的结果和内容存在差异。多生理参数监测状况前端展示设计有两种模式，一种是面向医院所采用的富客户端B/S模式，另一种是面向监护者智能手机的App模式。考虑到医生对心电、血压、血氧饱和度等重要参数的实时波形显示等特殊需求，web前端采用javascript和flex等工具实现富客户端，从而增加本地数据处理逻辑，并减少服务器负载水平。
4 多生理参数监测云平台服务性能的优化
4.1 高性能网络服务器的优化
引入云平台之后，多生理参数监测过程中数据实时计算能力得到提高，数据资源的有效利用率得到了大幅度提升，但平台入口接收实时数据的能力还有待改进。由于在实际应用中可能存在数以千计的移动终端同时连接服务器申请服务，因此，需要针对并发连接进行优化。Netty是由JBOSS提供的一个java开源框架，提供异步的、事件驱动的网络应用程序框架和工具，吸收了多种协议的实现经验，包括FTP、SMTP、HTTP、各种二进制以及文本协议等，使其稳定性和伸缩性得到提高。因此，多生理参数监测云服务平台采用Netty快速开发高性能、高可靠性的网络服务器和客户端程序。
4.2 分布式消息队列
由于医疗行业必须保证数据的可靠性与完整性，因此系统引入了分布式队列来作为技术保障。分布式消息队列可提供更好的可靠性和安全性，主要表现在如下几方面：消息会被持久化到分布式存储中，避免了单台机器存储的消息由于机器问题导致消息的丢失；当网络环境不佳时，保证只有当消息的接收者确实收到消息时才从队列中删除该消息；各业务的消息内容是安全存储的，其它业务不能访问到非自身业务的数据；当访问量和数据量增大时，分布式消息队列服务可以自动扩展。
上述设计使得当服务器负载水平显著增加时，可在不改动体系架构的情况下迅速增强系统的处理能力。
5 系统仿真与结果分析
为验证多生理参数实时监测云端平台构建的效果与合理性，对云服务器的相关性能进行了系统仿真与测试。在测试环境构建时，所采用的Eucayptus版本是最新的开源版本2.0.2版，虚拟机版本为Xen3.4.2，采用源码方式安装；各物理机安装的JDK版本为JDK1.6.0_13，使用的操作系统均为Ubuntu10.04。其中一台物理机安装Eucayptus的CLC、CC、WS3和SC节点，共有四台虚拟机安装在NC节点，每台均安装了Ubuntu10.04操作系统、Storm云平台及其它支撑软件。将其中的一台虚拟机设置为主服务器，负责接收手机端发送的数据并管理Storm集群。
为了测试云服务器的性能，在手机端分别模拟100~500个请求同时连接服务器并发送数据，云平台则对生理参数进行FFT变换，以实现多生理参数的预处理。在测试数据序列长度N=1 024、每台终端连续发送3 min的情况下，云服务器与传统服务器处理情况对比效果如图 5和图 6所示。
图5
云服务器与传统服务器负载水平对比
Figure5.
Cloud server load capacity compared with the traditional server
图6
云服务器与传统服务器处理时间对比
Figure6.
Cloud server processing time compared with the traditional server
由此可以看出，在数据量比较小的时候，由于传统服务器环境下数据都在本地处理，因此速度要快于集群云端。随着数据量的增长，传统服务器负载水平上升较快，而云服务器依赖负载均衡调度算法，把任务分给多个计算节点，提供了强大的服务能力，较好地解决了大数据量多生理参数的复杂计算问题。
6 结束语
针对多生理参数监测中数据量大和实时性高等特点进行了集群数据处理的云端平台构建与设计。与传统远程医疗系统服务平台相比，主要有以下特点：在弹性计算和存储方面，数据中心对底层硬件资源进行了虚拟化，使其能根据系统实际的负载状况合理分配资源，在运算任务较少的时间段可关闭部分服务器，降低运营成本；在数据库构建方面，由于数据中心需要对大数据和关系紧密型数据进行分别处理，因此采用了关系型数据库和非关系型数据库共存的双数据库设计，解决了大数据的处理、存储和内部实体关系复杂的医疗信息管理系统需求的矛盾，使系统的逻辑层和数据库设计更加合理；在分布式计算方面，将实时计算与批处理计算共存，在Sorm实时计算的基础上，引入Hadoop批处理用于对患者历史数据的纵向分析，两部分以HDFS分布式数据存储作为结合点，使患者生理数据分析的准确性和完备性得到进一步的提高。上述平台的构建，克服了传统多生理参数监测平台数据容量有限、分析能力不足、数据资源利用率低、共享数据的一致性较差等弊端，解决了传统远程医疗服务中数据周转时间长、架构拓展困难等问题，为多生理参数无线监测以专业的“穿戴式无线传感+移动终端无线传输+云计算服务”模式走向家庭健康监测提供了技术支撑。
