基于Spark的医疗行业大数据平台方案设计Word文件下载.docx
《基于Spark的医疗行业大数据平台方案设计Word文件下载.docx》由会员分享，可在线阅读，更多相关《基于Spark的医疗行业大数据平台方案设计Word文件下载.docx（20页珍藏版）》请在冰点文库上搜索。
各个业务系统数据库割裂，很难满足数据的一致性要求和信息安全共享。
4）服务的实时性需要提高：
医院信息服务中会存在大量在线或实时数据分析处理的需求，例如临床中的诊断和用药建议、健康指标预警等。
实时数据分析，而非传统的批量处理分析，数据以流的方式进入系统，进行抽取和分析，对于实时运行中的每个时间节点产生影响，而不是事后处理。
5）提高大数据的价值：
医疗数据对国家乃至全球的疾病防控、新药研发和顽疾攻克都有着巨大的作用。
医院传统的数据中心已经不能满足医疗行业大数据发展的要求，需要建设数据集成平台并寻求一套具有高可靠性、高扩展性，高性价比并且能支持开展更多高级分析、建立更多大数据功能的IT基础架构。
1.3、项目价值
1.大数据建设的业务价值
1）大数据分析获取最佳性价比治疗方案：
通过全面分析病人特征数据和疗效数据，然后比较多种干预措施的有效性，可以找到针对特定病人的最佳治疗途径。
研究表明，对同一病人来说，医疗服务提供方不同，医疗护理方法和效果不同，成本上也存在很大差异。
将有可能减少过度治疗（比如避免那些副作用比疗效明显的治疗方式），以及治疗不足。
2）临床决策支持系统，提高准确性，减少医疗事故率：
临床决策支持系统可提高工作效率和诊疗质量。
临床决策支持系统分析医生输入条目，比较其与医学指引不同地方，提醒医生防止潜在的错误，如药物不良反应。
医疗服务提供方可以降低医疗事故率和索赔数，尤其是那些临床错误引起的医疗事故。
大数据分析技术将使临床决策支持系统更智能，如可以使用图像分析和识别技术，识别医疗影像（X光、CT、MRI）数据，或者挖掘医疗文献数据建立医疗专家数据库，从而给医生提出诊疗建议。
3）医疗数据透明度，实现高效管理，降低成本：
提高医疗过程数据的透明度，可以使医疗从业者、医疗机构绩效更透明，间接促进医疗服务质量提高。
数据分析可以带来业务流程的精简，通过精益生产降低成本，找到符合需求的工作更高效的员工，从而提高护理质量并给病人带来更好的体验，也给医疗服务机构带来额外的业绩增长潜力。
公开发布医疗质量和绩效数据还可以帮助病人做出更明智的健康护理决定，这也将帮助医疗服务提供方提高总体绩效，从而更具竞争力
4）公众健康：
大数据使用可改善公众健康监控。
公共卫生部门可以通过覆盖全国的患者电子病历数据库，快速检测传染病，进行全面的疫情监测，并通过集成疾病监测和响应程序，快速进行响应。
卫生部门可以更快地检测出新的传染病和疫情。
通过提供准确和及时的公众健康咨询，将会大幅提高公众健康风险意识，同时也将降低传染病感染风险。
所有的这些都将帮助人们创造更好生活。
2.大数据建设的IT价值
1）IT价值：
在业务系统和数据没有整合之前x86服务器的资源利用率是很低的，每一台服务器或一个双机或多机集群运行一套应用系统，各个应用系统之间是相互割裂的，交互和接口都很复杂，现在业务系统和数据整合后，一个双机集群配合虚拟化软件可以实现过去10多台服务器所完成的工作量，资源利用率可以达到80%以上，功耗节约70%以上，如果二期项目采用linuxone架构工作量还能提升4倍，空间和功耗节省可以达到90%以上。
2）运维价值：
实现存储和服务器虚拟化后，单台存储和服务器的物理故障不影响业务系统的正常运行，提高和业务系统的可靠性和可用性，原有的老旧存储和服务器是最易出现故障的，这些设备可以供测试系统使用，进而发挥设备的“余热”。
实现存储和服务器虚拟化后，可以让更少的存储和服务器完成更多工作量，参与生产的服务器和存储的数量减少了、而可靠性、可用性和可扩展性却提高了，运维人员的工作也就相对轻松了。
1.4、项目风险管理
项目的风险包括业务风险和项目风险两个方面，医疗数据标准化是医疗大数据建设的基础，为了满足临床业务应用数据需求，实现数据统一入口和多系统共用目标。
医疗数据标准化建设过程中遇到以下风险：
1.业务风险
1）数据标准化涉及多个应用系统（包括数据提供方和数据消费方），协调接口改造进度和接口质量把控难度大，该问题处理不好易导致工期延迟，项目成本上升，需要协调好数据提供方和数据消费方的改造进度，把具体的进度目标落到纸面上，双方签字确认，严格按照进度表执行，双方的责任划分清楚，如需更改改造进度需要上会商议，商议通过按新进度执行，从而保障接口质量的把控。
2）数据标准化以消费方系统为建设起点，收集各消费方系统对数据标准化需求，先建立数据基本集和预留部分扩充字段，避免接口改造反复修改，提高接口稳定性；
数据基本集和部分扩充字段的预留要充分的考虑现有的业务对应用系统的要求并且为业务的长期发展考虑，按照确定的目标执行。
3）数据标准化确认业务流程，通知相关科室（数据提供方）维护数据要求，给出必填字段及业务流程，以免维护数据错误或空缺而影响消费系统数据；
4）数据标准化采用双向（拉和取）接口模式，以拉（数据消费方提供服务，给数据提供方调用）为主，以取（数据提供方提供服务，由数据消费方调用）为辅，确保数据冗余访问机制；
2.项目风险
1）项目进度的估算是否准确：
对于估算是否准确是对项目进度计划安排影响最大的一个因素，估算不准确的原因很多，主要的两个方面是缺少有经验的估算专家和项目缺少历史数据的收集，对于这两点只有通过项目多个版本的积累才可能得以改善，而没有捷径。
另外估算过程中还需要考虑一些特殊因素的影响，如项目新进了几名新员工可能会降低项目的平均生产率，项目过程中需要采用某种新技术而需要投入额外的预研时间等；
2）关键资源是否应用在了关键路径上：
在进度计划安排中是否优先保证了项目关键路径上的资源，是否通过人员技能矩阵对项目关键资源进行分析和安排。
在我们任务安排过程中是否对关键资源进行了保护（尽量减少关键资源上非关键任务的安排）。
另外我们在进度计划安排上应该适当安排10%-15%的余量，这样在项目遇到突发事件，或项目风险转变为实际问题时候才能够有人员和时间进行处理。
3）项目中的资源是否充分利用：
由于存在关键路径和岗位角色矩阵，所以项目中人力资源往往并不能充分利用起来。
在中小型项目中为了充分利用相关资源，项目更应该采用敏捷和迭代的开发方法，需求阶段开发人员可以先熟悉需求和进行公有组件的开发，而测试阶段我们的需求人员也可以介入测试。
所以对一个软件项目而言，需要保证到项目成员的整体利用程度在70%以上，否则就应该考虑采用新的开发模式和生命周期模型。
1.5、项目预算
医院实施大数据项目的成本包括以下几个部分，新增硬件成本，新增软件成本，软件二次开发成本，运维成本，其它成本（管理成本、其它突发性成本等）。
1.运营运维成本估算
新采购的设备通常提供三年原厂质保，设备过保后运维成本大约是设备采购成本的6%～10%，运维成本是否包含硬件损坏的免费更换价格略有浮动。
2.控制成本的建议措施与技巧
1）控制风险：
事先评估项目所蕴含的风险，因为风险往往意味着要用更多的资金去弥补。
在评估风险之后，你就能采取相应的措施来预防、降低或承受风险。
2）明确服务：
在实施前确保没有遗漏任何所需的服务，并与厂商达成明确的共识。
有时，一些小疏漏也会点点滴滴地增加你的预算开支，比如测试时间被延后、bug解决时间被拉长等。
3）技术路线的选择：
选择正确的技术。
斥巨资，试图让错误的软件去做它原本无法做到的事是一种最大的资源浪费。
所以在双方签订合同前，一定要明确所有的条款内容。
1.6、产品选型
大数据架构通常采用批处理或是流处理这两种数据处理方式，批处理适用于海量的静态数据，这个数据集代表数据的有限集合，数据需要持久保存并在计算完成后返回结果。
流处理是随时对进入系统的数据进行计算，流处理的数据集是无边界的，除非被停止，流处理的结果随时可用，结果随着对新数据的计算而更新。
打个不太恰当的比方：
批处理的数据类似于一个大型水库，水库中的水就是所有数据；
而流处理的数据类似于一个水龙头，水龙头放出的水就是数据。
现在主流的大数据架构有Hadoop、Storm和Spark等几种，下表是几种大数据架构的对比：
经过对几种大数据架构的比较，结合医院现有应用系统的建设情况和数据量的规模以及数据类型的复杂度（医疗数据包括结构化和非结构化还有半结构化数据，数据类型多种多样，有的数据适合批处理，而有的数据适合流处理），所以选用开源大数据架构的ApacheSpark建设医院大数据分析平台。
上图是Hadoop和Spark的处理性能对比图，处理相同的数据Spark使用了更少的节点、消耗了更少的时间,完成了更多的分类工作，MapReduce是Hadoop的第一代计算引擎，采用了一种比较简化的计算模型，只有Map和Reduce两个计算过程，可以处理大数据领域的很多问题，但是MapReduce的程序开发与接口调用很复杂，对于延迟要求较低、希望程序调用简洁的应用场景不会选择磁盘级计算的MapReduce，MapReduce基于HDFS，需要对输入数据进行切分、产生中间数据文件、再进行排序、数据压缩等操作，因此MapReduce效率相对较低，所以我们选择更有效率，速度更快的内存级计算的Spark来构建医疗大数据分析平台。
ApacheSpark是专为大规模数据处理而设计的快速通用的计算引擎。
Spark是开源的类HadoopMapReduce的通用并行框架，Spark拥有HadoopMapReduce所具有的优点；
但不同于MapReduce的是——Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于医疗行业海量数据的数据挖掘与机器学习等需要迭代的MapReduce的算法。
Spark是一种与Hadoop相似的开源集群计算环境，但是两者之间还存在一些不同之处，这些有用的不同之处使Spark在某些工作负载方面表现得更加优越，换句话说，Spark启用了内存分布数据集，除了能够提供交互式查询外，它还可以优化迭代工作负载。
Spark与Hadoop性能比较如下图：
从图中可以看到hadoop是通过磁盘存储计算数据的，而spark是通过内存存储计算数据的，所以Spark比Hadoop快100倍。
Spark主要有三个特点：
·
首先，高级API剥离了对集群本身的关注，Spark应用开发者可以专注于应用所要做的计算本身。
其次，Spark很快，在内存计算下，Spark比Hadoop快100倍且支持交互式计算和复杂算法。
最后，Spark具有易用性和通用性，Spark是一个通用引擎，可用它来完成各种各样的运算，包括SQL查询、文本处理、机器学习等，而在Spark出现之前，我们一般需要学习各种各样的引擎来分别处理这些需求。
医疗行业数据量非常大，每日增量数据也很大，数据类型复杂，选择通用性更强、运算效率更高的Spark架构来构建医疗大数据分析平台，可以实现更好的业务价值和IT价值。
二、医疗大数据项目方案设计
2.1、项目设计目标
1）解决医院海量数据的存储问题，满足未来三到五年的数据存储要求。
2）实现医院数据的标准化。
3）实现医院大数据分析功能包括：
临床中的诊断和用药建议、健康指标预警、提高临床决策支持系统的准确性，减少医疗事故率，大数据分析获取最佳性价比治疗方案，为全民健康奠定基础。
2.2、项目数据建模
需求模型的确认分三步走：
第一步是以卫计委给出的医院信息化建设的要求和相关数据模型为基础，卫计委数据模型如下图：
结合医院的业务流程对现有业务进行梳理，确定业务中的问题形成总体设计，第二步是制定数据标准、接口标准、消息标准、文档标准和服务标准。
第三步是根据总体设计和标准规范同步进行大数据平台实施。
医疗大数据处理流程包括采集、处理、存储、检索、计算和应用等五个步骤，处理流程如下图：
基于患者就诊过程的医疗大数据分析与应用模型如下：
该模型展现了从患者入院到出院过程中产生的相关数据，主要包括患者特征数据、病种数据、治疗方案与费用数据、治疗状态数据及在该过程中产生的管理类数据。
1）患者特征数据：
患者特征数据主要有主诉、现病史、检查检验类数据。
涵盖了疾病的主要症状、体征、发病过程、检查、诊断、治疗及既往疾病信息、不良嗜好甚至职业、居住地等全部信息（例如：
患者信息中的国籍、性别、民族、婚姻、职业、地址、电话等等。
）
2）病种数据：
即患者疾病的诊断结果，一般有第一诊断、第二诊断、第三诊断等。
目前使用ICD-10进行疾病的分类与编码（国际疾病分类（internationalClassificationofdiseases,ICD），是依据疾病的病因、部位、病理及临床表现的特征，按照规则将疾病分门别类，并用编码的方法来表示的系统。
）。
3）治疗方案与费用数据:
根据诊断结果为患者提供的治疗方案与费用数据主要包括药品、检查、检验、手术、护理、治疗6大类，此外费用数据还有材料费、床位费、护理费、换药费用等。
4）治疗状态数据:
治疗状态数据即患者出院时的治疗结论，一般分为治愈、好转、未愈、死亡4类。
5）管理类数据:
除患者就医过程产生的服务于医院管理的数据外，还包括医院运营和管理系统中的数据，如物资系统、HRP、财务系统、绩效考核系统等产生的数据。
患者的检查信息，图像序列表的生成，系统图像记录，业务参数如下图：
标准化数据字典包括：
1）药品字典。
2）治疗、护理项目编码字典。
3）医疗仪器、设备编码字典。
4）医疗费用计价编码字典。
5）国际疾病分类代码（ICD-10）。
6）医院职工编码字典。
7）医院科室、病区编码字典。
2.3、项目整体架构设计
1、智慧医疗大数据项目逻辑架构
智慧医疗大数据项目逻辑架构图从功能上划分包括三个方面：
一是资源层，资源层又包括云基础设施（涉及隐私的数据放在私有云、可以对外公开的数据放在公有云上可以节约私有云的建设投入）、服务器、存储、网络安全等基础设施以及对这些设施的监管和运维；
物理资源层（包括各种数据库和数据仓库等）、虚拟资源池（包括健康档案、电子病历和公共卫生、临床诊断等）和应用资源中心；
二是服务层包括医院的各个业务系统，决策支持与管理系统以及基于这些系统建设的大数据分析平台；
三是展现层主要是各服务对像的接入，在这三个层面中低层为高层提供服务。
2、智慧医疗大数据项目物理架构
智慧医疗大数据项目物理架构分为内网和外网两个部分，内外网核以层和汇聚层都是双冗余架构的（一台交换机或线路故障不影响业务的正常运行），内外网有数据的交互，为了保障内网的数据安全和网络安全，外网用户需要通过授权的sslvpn帐号才可以访问内网的数据。
所有的业务系统和数据库均采用集群架构，从而实现业务系统的高可靠性和高可用性。
医院于三年前按分级存储的原则重新规划了PACS存储系统，PACS数据除了少部分PACS索引、日志数据外，绝大部分为医学影像图片数据。
存储通常采用三级模式：
第一级为在线数据，保存最近半年的病人影像数据；
第二级为近线数据，保存半年以上、2年以内的影像数据（PACS系统软件可以配置保存周期）；
第三级为离线数据，保存15年内的影像数据。
同时，还有考虑备份系统的建设。
2.4、大数据分析平台架构设计
医疗大数据分析平台由数据获取、数据整合，数据加工和数据展现四个模块组成。
医疗大数据处理模型如下图：
1）数据获取：
这个过程要先问自己要收集哪些数据，大数据分析并不是对医院所有的数据都进行收集，而是相关的，有直接或者间接联系的数据，要知道哪些数据是对于战略性的决策或者一些细节决策有帮助的，分析出来的数据结果是有价值的，这也是考验一个数据分析员的时刻。
例如哪些数据可以得出信息对于一个临床诊疗是有帮助，或者是更好的实现辅助诊疗目标。
在进行大数据分析规划的时候，一般是针对一个业务的目标进行精确的分析，比较容易满足业务的目标。
2）数据整合：
为了得到更加精确的结果，在大数据分析的过程当中，数据整合是关键的环节，数据整合是将从医院信息平台抽取的业务数据按照统一的存储和定义进行集成。
医院信息化经过多年的发展，积累了很多基础性和零散的业务数据。
但是数据分散在临床、辅助、管理等不同部门，致使数据查询访问困难，医院管理层人员无法直接查阅数据和对数据进行分析利用，数据整合需要综合不同格式、不同业务系统的数据。
3）数据加工：
医院原有的业务数据必须经过标准化处理后才能够迁入大数据平台。
由于医院的大数据来自各个不同的业务系统，数据格式和标准不统一，很难对数据进行统一的管理和利用。
一般大数据平台的建设都会针对结构化和非结构化数据建立不同的主索引数据，然后对源数据进行清洗后导入数据集。
拥有或创造一个干净、结构良好的数据集是必须的。
使用数据清洗软件工具可以帮助细化数据并将其重塑为可用的数据集。
4）数据展现：
数据展现即数据可视化，为方便医护人员、患者和管理人员理解和阅读数据，而采用相关技术按业务规则进行的数据转换。
这就要求医院相关的业务规则都是已经确定好的，这些业务规则可以帮助数据分析员评估他们的工作，将数据进行分析得出有价值的结果。
2.5、关键技术难点分析
在医疗大数据的应用的同时，还存在数据的抽取、存储、清洗、整合、挖掘、分析、展现等问题需要解决。
一是非结构化文档及自然语言的结构化处理。
包括中文分词、标准化、XML解析、本体构建、语义标注等。
例如，电子病历的“结构化”是从医学信息学的角度将以自然语言方式录入的医疗文书按照医学术语的要求进行结构化分析，并将这些语义结构最终以关系型结构的方式保存到数据库中。
二是医疗大数据标准化与整合。
将不同科室，不同业务系统的非结构化、零乱的数据整合成有利用价值的数据；
对大数据进行过滤，设计脏数据过滤规则；
数据一致性检查，无效值和缺失值处理。
三是数据聚类分析、算法与建模。
包括贝叶斯模型、人工神经网络、随机森林算法、决策树理论、d-s证据理论、临床决策指标矩阵理论等，有可能在一类应用中要涉及多个模型与算法。
四是大数据快速检索与处理。
包括基础设施建设；
大容量医疗数据的组织、存储与索引技术，实现数据的高并发访问与快速提取等。
采用全闪存阵列实现对原有存储系统加速的方式，为大数据分析平台的搭建提供存储架构的支持。
五是数据安全。
要确保医疗大数据利用过程中，不被外界窃取和修改，要建立相应的数据加密技术和数据访问授权机制等。
数据加密采用sslvpn技术加密，保障数据的传输安全和内容安全，数据的访问要实现双因子认证，帐号密码加专用密钥的方式。
2.6、关键设备配置算法
1、网络配置
网络划分：
内网（业务办公）和外网（移动用户和远程用户）。
网络冗余：
内外网核以层和汇聚层都是双冗余架构的。
网络速率：
千兆核心百兆到桌面。
网络安全：
外网用户需要通过授权的sslvpn帐号才可以访问内网的数据，网络部署防火墙、IPS、IDS、上网行为管理、防病毒网关等网络安全设备。
2、在线存储配置
医院数据交换平台每天新增数据量200G，为医生提供1年内的在线资料查询，因此需保存的在线可用容量是：
200GB/日x365天=73000GB=73TB，当存储空间的使用率达到80%时，其性能将下降，另外考虑冗余空间20%，因此总空间需求为：
73TB/80%=91.25TB。
考虑到数据的安全及高可用，存储采用RAID5的方式，存储祼容量应为：
91.25TB/75%=121.7TB，另外再考虑到热备盘、数据库空间及文件的损耗，推荐配置150TB的总存存储容量。
3、近线存储配置
近线存储主要用来存储一些非热点数据和交换数据，按照在线存储的数据量，近线存储只需要配置在线存储的1/3容量即可。
150TB/3=50TB。
升级会员 