应用需求决定平台架构，平台架构决定基础架构。三甲医院大数据应用场景主要分成临床、运营、科研三大类，分别对应临床数据中心（CDR），运营数据中心（ODR）和科研数据中心（RDR），临床数据以电子病历为核心，目前随着结构化电子病历的普及，纯文本的数据越来越少，NLP的技术依然适合，运营数据则大多数为结构化数据，科研数据则在临床数据的基础上有更多的多媒体数据（多数为影像数据）、实验数据和随访数据。大数据平台基础架构设计需要支撑上述需求的实现，计算能力、存储能力和安全是基础架构建设的三个重要方面。计算能力主要在数据采集、预处理、实时计算和分析阶段进行支持。存储能力则是支持分析数据所需要存储资源和存储空间的支持。三甲医院大数据平台大多数基于Hadoop等分布式平台，采用内存数据库或图数据库进行数据存储。
为帮助三甲医院用户更好地建设大数据平台基础架构，专家与医院同行一起从四个角度出发交流，供更多同行参考，包括：基于临床、运营和科研大数据平台的内容和要求角度、基于医院大数据平台建设的技术架构角度、基于大数据平台建设标准和目标角度、基于大数据的存储规划角度，以及交流达成的共识总结。
通过本场医院同行的交流活动达成了一些交流共识如下，仅供参考：
（1）从大数据平台建设内容方面来说，医院大数据平台围绕临床、运营以及科研等三个主要层面进行，新技术，新手段也都需要围绕这三个方面，因此，CDR、ODR、RDR的建设应该说是囊括了医院信息化大数据平台的主要内容。（2）从技术架构角度来说，基于分布式存储的架构平台似乎成为主流，但是目前正在逐步从分布式过渡到云，主要以医院的私有云+公有云的混合模式出现。（3）从建设标准和目标角度，大数据平台应具有异构数据的标准化，数据处理流程，分析过程标准化的功能，同时，数据可视化也应是目标之一。（4）从数据存存储选型角度，混合SSD和传统SATA的存储器搭建SAN网络是一种路线，分布式存储的效果主要体现在不少医院早些年建成的基于Hadoop架构。从科研平台未来的发展看,采用支持Hadoop的分布式存储，实现计算与存储的分离，是未来的一个趋势。一、基于临床、运营和科研大数据平台的内容和要求角度
1、三甲医院大数据平台如何建设，才能满足具有多模态，异构化，海量化的临床、运营以及科研数据的整合？
【问题描述】众所周知，三级医院经过十几年、几十年的信息化建设，已经建设成为具有临床数据支撑，科研支撑，以及运营支撑的全方位信息化应用的场景，但是随着大数据分析广泛应用，海量数据的整合挖掘及再利用也提上日程，部分医院走在了前列，但是在开展的过程中遇到了不少问题，比如，数据的模式的多样性造成了对数据使用的难点。医疗数据中包含了文本，图像，视频等，还有不同模式的数据。如何将这些数据整合利用，以便发挥数据的最大利用价值成为目前医疗大数据平台的研究方向之一？数据的多模态、异构化、海量化必然导致其支撑架构的多样性。哪些数据适合关系型数据库，哪些数据适合分布式数据库，存储的选择亦是如此，也要结合数据类型，数据的重要性、时效性要求以及业务的实际要求等因素综合考虑。数据的整合利用离不开如下几个方面的工作：
可以考虑先建立数据湖，把数据整合后，再按主题做筛选和清洗。
2、信息部门该如何规划CDR、ODR、RDR的裸金层？
【问题描述】当前建设CDR、ODR、RDR数据中心是医疗圈热门的话题，信息部门该如何规划CDR、ODR、RDR的裸金层，一次把基础架构搭建立起来，避免重复建设？目前，CDR、ODR、RDR的定位和作用医疗圈是有共识的，但是其建设方式、模式及数据交互方式尚处于百花齐放的阶段。不同的公司有各自的解决方案，不同的医院和机构也根据自己实际业务的需求和特点进行着有针对性的建设，所以我理解因为其建设的非标准化特性，希望有一种规划、或者一种模式把基础架构搭建起来，然后后续不再变动，不再调整，从而避免重复建设，这种本身是与信息化技术与发展的日新月异的特性和特点相违背的。当下，数字中国日益提上日程、物联网、5G的快速应用、区块链、数字孪生、人工智能等新技术与医疗的融合也将日益紧密，数据中台的讨论也不绝于耳。所以CDR、ODR、RDR这种适合当下的数据层架构和方法论是否适合未来3-5年的技术发展尚不可知，所以其基础架构的不确定性也更加不能形成定论。目前就CDR、ODR、RDR的建设而言，个人觉得，应该把握几个建设原则：（1）分类原则。不管技术如何发展，架构如何调整，数据的分类应该是不会有太大的调整。结构化、半结构化、非结构化，其适宜的存储架构是有明确的规范和要求的，数据的重要性与否，数据的响应时效要求，数据容灾要求，这些都是数据分类的具体指标，也为我们底层架构的建设提供指引，避免低需高配和高需低配的情况出现，保证需求和配置的相适宜；所以针对不同数据类型和数据要求，要有与之相适应的存储底层，故数据中心的裸金层也是存在多种架构存在的。（2）可扩展原则。CDR、ODR和RDR，在建设初期，因为需求的不明确、中心数据的磨合、与各业务系统的交互和上层应用的梳理等原因，前期数据体量不会太大，随着业务的推进，技术、流程和方法的日趋成熟，需求也会处于井喷期，其数据增长也会指数型增长，原来的架构应该要充分考虑其可扩展性，以及扩展后保证数据性能、数据时效响应等方面不会下降。
3、医疗大数据方面如何解决数据孤岛和数据安全问题？
【问题描述】在医疗数据收集方面存在很多检查设备，例如：纤支镜 等单设备无法提取数据的问题。大数据处理过程中，如何保障数据的安全，以及隐私隐私问题？目前，的确存在很多单体设备的数据提取、存储的问题，尤其是对一些专有设备如 纤支镜 、脑电图等，这些数据的采集要相应的设备厂家能开放相应的数据接口，目前很多这些设备的厂家基本都会有自己开发的系统，也有一些厂家会开发相应的系统，对市面上的比较高占有率的产品类型进行数据的提取开发。所以建议在采购该类设备的时候，一定要注意关注数据提取这块，数据接口是否开放？通过特定数据线抑或是网络传输？是否要专有信息系统抑或是市面上有可以统一汇集提取的软件？这些都要考虑并且也要写入采购合同中。大数据处理要严格执行等保2.0的相关要求，数据的处理可以通过堡垒机等安全措施进行操作，另外可以通过脱敏设备对敏感数据进行脱敏，并且形成相应的规范流程便于操作。数据安全要重视设备的投入、人员的管理、技术的提升，也要关注架构的合理、流程的规范、举措的到位。检查设备数据传输问题还是设备本身是否支持数据输出接口，这个需要联合设备科在购买设备的时候就要把数据传输接口需求写入招标文件。大数据处理过程中的数据安全也应该基于三级等保2.0的要求严格执行，隐私问题还要增加动态脱敏、数据库防火墙等设备
4、关于科研大数据平台底层基础架构
【问题描述】科研大数据平台现在发展方向主要有四个方向：影像，大样本分析，多模态，真实世界研究，目前以真实世界研究居多，但是趋势是往多模态方向发展，这就要求传统的文本，结构化数据处理外，还需要结合影像图片，甚至是超声之类的视频，对于这类数据处理，底层基础架构如何支撑？存储层面可以考虑分布式存储、对象存储等方式；数据层面可以考虑分布式数据库、图数据库等方式。
5、三甲医院科研大数据平台应该具备哪些主要功能？
【问题描述】结合现今人工智能，数据科学的流行，三甲医院对科研的发展愈加的重视，对于一个能够完美支撑三甲医院科研的数据平台是非常必要的，但是从业务和建设者角度来看，临床科研的需求和计算机专业从业者之间对于技术平台的理解还有一定的差异，那么科研平台应该具有什么样的功能，才能满足或推动临床科研的进一步发展十分重要，这也是具备信息技术的从业人员需要搞清楚的问题。科研平台作为医院科研领域重要的业务平台，要结合科研业务的特点进行功能的设计。因为科研业务的复杂性和多样性，所以也就导致科研平台的功能是十分复杂、十分多样的成体系的存在。但是几个大的功能科研平台还是应该具备的：1、数据的查询和提取功能。科研业务的重要对象就是对数据的分析，针对某一科研项目需求，能从平台中查询并提取出研究所需要的数据，这个应该是平台必备的功能；2、科研信息图谱的查询。科研业务在开展前，需要进行回顾性分析，对前人类似的科研业务、文献、网络资源等进行综合性查询和分析，能让研究者了解该研究的整体的信息图谱，为本次科研项目研究提供有效信息支撑；3、科研人员图谱查询。要做好科研，要有合适的对的人参与进来或者进行相关业务的合作，科研平台能全方位的展示相关人员的科研信息，为科研人员提供选择参考将有利于科研项目的推进。
6、医院科研大数据平台，如何对临床医生真正有所帮助，无论是数据还是图像？
任何技术手段、架构、方法、系统抑或是平台，包括医院科研大数据平台也是如此，其目标都是结合业务对数据、流程、模式等进行再组织，从而实现用户既定目标。系统平台的建设，表面看是信息化层面的建设，但是其实质是业务流程的再造、知识的再重组梳理、数据的再组织，结合技术的特点和优势，从而实现业务自动化乃至智能化。所以如果系统和平台要建的好，相应用户如临床医生的深度参与是密不可分，需求目标要能明确提出、功能体系要充分验证，数据质量要监控把关，只有这样，医院科研大数据平台的建设才能实现为临床医生提供真正意义上，有感的帮助。
1、互联网医院的建设中，如何规划大数据平台的架构？
按照卫健委发布的《互联网医院管理办法（试行）》，互联网医院包括作为实体医疗机构第二名称的互联网医院，以及依托实体医疗机构独立设置的互联网医院。互联网医院作为互联网+医疗的组织表现形式，不管是哪种形式的互联网医院，其业态是目前为止是一定的，如我们熟知的预约挂号、在线缴费、在线查询检验检查报告、在线入出院等。随着互联网+医疗的深入结合，其服务模式等也会有相应创新性的发展。规划互联网医院的大数据平台架构时，要充分考虑互联网医院现有业务模式下的数据概况，也要充分预留未来互联网+医疗业务爆炸式、井喷式发展时，基础架构的可扩展性、灵活度要能与之适配。
2、基础架构与医院信息系统的融合问题？
【问题描述】如果医院已经建立集成平台，但缺乏专业的临床科研数据平台，怎样将科研，管理，临床平台与现有集成平台融合。基础架构与新建信息平台的融合！首先，应该要先理清各平台的定位和作用，以及我们需要实现的目标。集成平台是为了解决医院系统间星状交互导致的各类问题而提出来的系统交互平台，其目标在于实现系统间的互联互通，系统间的互联互通主要是通过平台的标准化接口实现。科研、管理、临床作为医院不同的业务领域，其实际业务目标是不相同的。又因为这三大业务领域中的具体业务各式各样，所以业务系统数量和种类也是多而杂。集成平台可以解决临床、科研和管理等业务领域各类系统互联、数据交互共享的问题，但是如果是临床、科研、管理等业务系统的数据的融合利用，则需要通过CDR、ODR、RDR等各类数据中心去实现，通过对逻辑数据的治理、存储、利用，充分发挥数据资源的价值。
3、大数据平台底层架构规划？
【问题描述】大数据平台架构需要数据存储和计算能力。医疗数据是多源异构的，有结构化、半结构化和非结构化，同时随着未来物联网、设备等数据的增长，对大数据平台的数据存储要求会更高；大数据平台需要满足各种AI能力，这部分体现在算力上，算力需要的软件和硬件两个层面的支撑。综上，在建设大数据平台的时候，做好应用的规划的同时，也需要充分规划好底层基础架构，底层基础架构需要满足先进性、成熟性、使用性、开放性、和扩充性。问题：如何做好这部分规划？个人觉得对于大数据平台的底层基础架构，也应该根据其上层的应用类型、数据类型、时效要求、容灾要求等综合考虑选取合适的，与之相适应的底层架构。笼统的把整个大数据平台放在某一种架构中，不考虑其实际情况，将容易导致资源利用与实际需求的不相符。大数据平台的数据类型及业务场景都是多种多样的，与之相适应的，底层基础架构也应该进行分类讨论。就存储底层而言，存储IO要求高的，结构化的数据则应该用ssd全闪乃至NVMe全闪，要求不高，数据量较大，非结构化的数据，则应该考虑其他类型的存储、分布式存储乃至对象存储架构。大数据平台的底层架构主要是3个方面：数据的存储、算力和算法，在这之上来支撑数据的应用，反哺业务。
4、三甲医院大数据平台基础架构？
【问题描述】应用需求决定平台架构，平台架构决定基础架构，说明医院尤其是大型三甲医院大数据平台基础架构是很重要的，我的问题是针对医院不同类型的数据类型，要充分考虑医院数据的存储方式和存储能力，同时还要考虑系统的计算能力，这是建设基础架架的前提，希望有这方面建设的实例针对性的分析，谢谢。目前很多医院在建设基础架构时，正在逐步云化过渡，有些在建自己的私有云，有一些会将一些业务放在公有云，都在做相应的积极探索，当然有利有弊。在医院基础架构云化的大背景下，我们在建设时应该要以池的概念去综合考虑计算、存储以及业务的问题。现在很多医院都是区分内外网，并且系统都做了不同程度的容灾，还有很多系统正在上线开发，需要大量的测试环境，还有很多对外交互的业务需要在DMZ区，如医保、支付宝、银联支付等。所以从业务层面来划分，可以分为内网云、外网云、对外交互云、测试云、容灾云。而针对不同云的特点要求，可以选取不同级别、不同性能、不同容量的设备和技术体系进行支撑，重要的、稳定性要求高的、时延要求小的用高性能高可靠的架构体系，非结构化、数据量大，访问频率低的，可以考虑分布式存储或对象存储，以此类推。另外计算和存储能力，在云化下，针对性的进行池化分析，计算池是否满足计算要求，是否有GPU计算需求等，都要结合业务去具体分析，容量池亦是如此，在此不再赘述。
5、医疗大数据平台不同的建设路线底层基础架构设计时有什么要求？
【问题描述】目前医疗大数据平台大多采用HADOOP+MapReduce、内存数据库(以SAP HANA为代表的)以及图数据库（GP为代表），这几种模式在底层基础架构构设计时有何区别？底层基础架构设计不仅要考虑技术因素（性能、一致性要求、SQL兼容性要求），也要考虑包括架构产品的生态成熟度、应用架构适配度、团队适应度等非技术因素。Hadoop+MapReduce是典型的分布式文件系统+分布式计算的技术框架，其组件HDFS就是典型的分布式存储架构，分布式存储架构更为适合其技术体系。内存数据库其主要的设计目标是为了解决高并发低时延的数据管理需求，依靠内存来存储数据。从存储速度来说，CPU寄存器>CPU缓存>DDR DRAM>持久型内存>NAND SSD>磁盘驱动器（HDD）>磁带，内存数据应该使用DDR DRAM或持久型存储，区别在于DRAM目前为易失性存储，使用时速度较高，但是应该要充分考虑业务类型和备份容灾方案，保证在极端情况下业务业务连续性，持久型内存相对来说速度较慢，但是非易失，容量和价格也占优势。图数据库根据其图存储和处理方式分为不同类型，其底层的存储架构也要视图数据库采用的技术类型而选择与之适应的存储类别。另外，值得提出的是，不管是何种存储架构，要注意存储的物理块要与文件系统或数据库中的逻辑块大小上要适配，减少同一数据操作频次。而且在基础架构设计时，也要关注业务类型、成本和投入的影响。
6、医疗大数据平台在做存储容量的规划时应考虑哪些因素？
（1）业务的需求及增长预期：要考虑现存数据的体量以及未来3-5年业务数据的增长量；（2）数据的保存周期：数据保存期限多久，基础数据，过程数据、结果数据等类型数据的比例如何？保存周期的要求如何？（3）架构及容灾要求：是集中式架构？还是分布式架构？选择的存储产品的存储内部组织方式如何？集中式架构是否包括RAID抑或是全局打散？RAID的划分要求、热备盘的要求如何？分布式架构高可用要求如何？副本如何配置？容灾要求如何，备份方式如何选择？全备、差异，备份的方式、频率及备份的保存周期如何？（1）业务的数据量预估，比如每周、每月、每年数据增量。（3）数据分析需要多少个副本，全量的还是差异量的副本。（4）是否有备份、容灾的需求，备份频率、保存周期等。（1）硬盘的进制一般是1000进制，操作系统是1024，需要折算一下单盘容量。（2）存储设备的数据冗余方式，多副本还是EC/RAID？根据校验盘的比例来算裸盘数量。（3）还要查看所选中的存储系统自己存储元数据会消耗多少硬盘空间，把这部分扣除才是系统可用容量。（4）算了RAID/EC以后存储可提供的容量以后，一般还要考虑加一个经验系数，比如10%或者20%的余量，作为风险余量。主要是小文件一般都有写放大。
1、医疗大数据团队如何建设？
【问题描述】对于医院建立医疗大数据，如何组建团队，需要哪些方面的人，如何建立标准操作规范，如何确定目标方向？如何考核和推进工作？（1）管理人才：有较高的管理素养，熟悉医疗大数据的业务方向和发展趋势，能团结团队人员朝着目标努力和推进工作；（2）技术人才：包括懂标准规范方面、大数据技术能力（架构的设计、搭建、开发、应用等）等多方面大数据所需人才。（3）数据治理人才：包括了解业务，有较强的数据治理能力、数据处理能力和分析挖掘能力等的人才；标准操作规范的确立要结合业务流，形成本团队操作SOP，结合行业的研究热点、技术趋势以及本单位医疗数据、人员等优势，确立目标方向，目标的确定可以分为近期目标和远期目标，通过目标的逐步实现慢慢积累经验，逐步深入，进而确定远期及战略性目标。考核工作应该以人为主体维度，推进工作应以事或项目为主体维度，形成行之有效的绩效考核目标、成立项目推进工作组等相关临时组织，制定任务明晰、目标明确的责任任务清单，将任务具体分解，落实到人，进而形成合理共同推进相关工作。
2、临床数据中心必须符合医院的数据管理规范？
无规不成方圆，标准化、规范化将极大促进数据交互共享及后期的分析挖掘利用。所以临床数据中心的建设必须要符合数据管理规范，不仅要符合医院层面的数据管理规范，还要参考遵循国家、行业等层面的相关标准规范。但是值得提出的是，目前很多医院重系统建设，轻标准建设。信息系统的建设和运维已经让医院的信息部门不堪重负，极少会开展相应数据标准的研究，也极少有医院会成立相应的数据管理部门，专责于开展数据标准、数据治理及数据利用。答案是肯定的，临床数据中心的数据也在医院管理范畴内，必须遵从管理规范。
3、临床大数据中心，怎样将临床医生和护士的结构化电子病历数据直观显示在临床科室？
【问题描述】临床数据中心的数据应该是医院最核心的数据，怎样从结构化电子病历中提取医生和管理部门所需要的数据，保障从数据到转化，应该是关键问题。目前，临床数据中心的利用有很多方式，包括360患者全息视图、临床决策支持系统等，都可以基于数据中心中汇集的各业务系统（包括HIS、LIS、PACS等）的数据，提供利用转化。临床数据中心的利用，取决于医院医生和管理部门数据需求的明晰化，这个是利用的目标，前提则是业务系统中有相关的数据源，而重点在于数据源提供的数据有较高的数据质量。不然数据的转化利用效果则会大打折扣。围绕上面几点，临床数据中心要扎实持续做好数据需求的分析，保障数据源的稳定，形成规范的数据治理体系，为后续数据的利用提供基础。
4、医院各部门数据归口不一致，如何解决？
医院部门间的数据归口不一致是业务使然，是正常状态，如医务部门的数据统计口径和统计部门的数据统计口径往往是不一样的，如就诊人次数的统计，他们各自取的有可能是不同业务表的数据，医务部门可能统计挂号人次数作为就诊人次数，而统计部门统计的是医生看诊人次数作为就诊人次数。面对这样的问题，个人理解应该从如下方面解决：
（1）统一数据口径。要梳理医院现有各部门数据需求，充分分析研究各部门的数据需求所对应的业务目标，充分沟通协商，形成有效的、统一规范的统计数据集；（2）统一数据来源。业务数据统一汇聚在数据中心中，所有数据需求应从数据中心中获取，从而避免从不同业务系统获取数据导致的不一致情况。这个问题现在是绝大部分医院面临的问题，我个人建议是划分业务域，建立指标库。业务域：就诊、计费，业务活动：门诊就诊、门诊结算，原子指标：门诊就诊人次、门诊计算金额，派生指标：月度门诊就诊人次、月度门诊药品结算金额，复合指标：月度门诊药品均次费用。针对这个例子结合业务域将原子指标归口科室：门办和财务科，那么通过原子指标衍生的派生指标和复合指标口径就可以保持一致。需要注意的是：建立指标库的前提是要建立医院的数据资产，关键就是元数据、数据质量、数据血缘等。现在很多行业做大数据都会面临这种问题，各部门分属不同的领域，所以在构建大数据之前，首先我觉得要明确的就是项目的架构，信息化逐渐的已经不再是企业的辅助系统，而是逐渐成为决策系统，要做大数据，那么首先要做的就是把信息化做到一定的高度。底层的数据如病例，患者信息，医院信息还有综合的财务等信息要打通，这部分需要多个部门来配合，并且由独立的信息化部门来牵头完成的，梳理出数据的共性和特点，然后建立公共的数据仓库，再根据业务的特点梳理出哪些信息是需要进行挖掘的。很多时候，大数据平台的逻辑构建要比物理建设更重要，要综合现有的数据资源，共同分析才能形成更好的思路。
5、CDR、ODR、RDR三者的边界怎么划分？面向临床医疗医生的数据呈现方式是什么？
【问题描述】临床数据中心（CDR），运营数据中心（ODR）和科研数据中心（RDR），三者存在交集，那么他们的边界怎么划分？面向临床医疗医生的数据呈现方式是什么？三大数据中心实际上就是三个业务主题，边界取决于业务数据属于哪个主题类别，但由于业务数据也存在多个类别，所以存在交集，特别是临床和科研，数据交集比较多。面向医疗临床医生的数据呈现方式主要还是患者360视图，也就是基于一个患者的全生命周期的诊疗数据，如果数据能打通院外，那就可以以电子健康档案的方式呈现。CDR、ODR和RDR都是基于业务领域进行的逻辑层面的数据划分和再组织，而实际业务数据的产生也就是数据源是相同的，都是基于实际的业务系统，如HIS、LIS、PACS、HRP等。这三类数据中心的目标都是为了其相应领域的上层业务应用的需求，在对实际业务数据多元化采集加工基础上，进行的主题化汇聚，进而知识化应用。三大数据中心基于的业务领域分别为临床、管理和科研，虽然使用的数据源和维度可能有时相同，但是其基于此服务的应用目标是不一样的。举个例子，急诊就诊人员信息表，在CDR和ODR都可能有这部分数据，但是CDR中可能服务的上层应用是为某个急诊医生查询本人看诊人员数量或者查询剩余就诊人数，ODR中该部分数据主要是为医务管理人员查询某天、某月乃至某年急诊人次数抑或是通过可视化的方式展现急诊就诊人数的趋势图，或者结合时间、职业等进行关联分析得出相关的趋势分析。所以我个人认为三者的边界是模糊的，要基于业务领域和场景具体情况具体分析。面向临床医疗医生的数据展现方式有十分多的类型和方式，可视化、多维度，相关的技术和工具以及相关的人员及业务都是相对较为成熟和成体系的。重点不在于有哪些类型和方式，重点在于展现的需求是否明确，展现的数据是否有来源，展现的数据质量是否足够高，这三个是对临床医疗医生的数据呈现问题需要解决的三大问题。【问题描述】建设科研大数据平台，一般都是将各个业务系统的数据重新收集整理，结构化的数据也还好，并不占用空间，而非结构化的数据例如影像数据，一个大型三甲医院的增量是非常大的，如果这些数据都抽取到科研大数据平台医院相当于又要重新建设存储，如何平衡这些非结构化的数据的存储？对于这类数据，应该要做好统筹规划，医院的数据都是会做容灾备份的，所以一般医院存放同类数据基本都是2份或2份以上，在业务系统、科研大数据平台或者别的其他应用系统对某个非结构化数据有读取或使用需求的时候，应该充分利用容灾备份环境中的同类数据。另外，在软件设计和数据库存放时，该类增量较大的非结构化数据以地址指针的方式存放，如需要调用时再通过地址调转到实际的数据存放路径。这样将极大的缓解该部分数据的读写压力。
2、医院大数据平台、科研平台等推荐什么存储架构？
【问题描述】医院大数据平台、科研平台等平台，推荐存储架构是？除了分布式架构的分布式存储，能否做个分析，用哪种类型的存储适合非特大型三甲医院呢？医院大数据平台、科研平台等平台，鉴于其数据的多模态、异构化、海量化，建议存储架构也是混合多样的，要针对数据类型、业务需求、性能要求等综合考虑，结合分析。即使是非特大型三甲医院，其基本业务也是和三家医院相差无几的，只是同样的系统，体量不同而已。如果体量不大、增量不高，为了方便维护，可以考虑超融合的架构体系也可以考虑一体化存储的方式，存储中涵盖了闪存等高速盘，也有SAS、SATA等低速盘，支持NFS、ISCSI等协议方式，但是值得提出的是这类存储虽然支持容量的扩展，但是存储机头的缓存、性能等可能会成为后续扩容、扩展的瓶颈，所以要对这方面特别关注。避免后续成为性能瓶颈。
3、关系型数据库，非关系型数据库还是分布式数据库，医疗大数据平台基础架构如何考虑？大型的数据整合平台如何将异构化数据统一整合，是使用传统数据库技术还是采用其他方案？
要考虑数据类型、业务场景、时效要求、性能要求等因素。因为数据的多样性必然导致基础架构的复杂性、差异性和多样性。多种类型的数据库、存储架构并存应该是医疗大数据平台的常态，鉴于底层架构对数据及应用上层的透明性特点，结构化关系型数据虽然也能存放在分布式或对象存储中，但是其性能必然大打折扣，不同的数据库设计是，其适宜存储和处理的数据对象是一定的，所以我们在考虑医疗大数据平台基础架构是，要结合业务场景、数据类型、以及各类数据库、存储架构的技术特点综合去考虑。
4、如何解决存储扩容时不同厂商技术之间差异化问题？
可以通过云存储的方式去解决。其中有两种比较常见的方式：（1）网关的方式。如IBM的SVC，EMC的Vplex，通过存储网关将不同厂家的存储汇集起来再对外开放；（2）外接存储的方式。通过某一高性能的存储其自带的虚拟化套件，然后将其他存储外接到其上面，相当于外置硬盘一样，统一由该高端存储汇集后对外开放。
5、对于医院各种类型的数据，分别用什么方式、什么设备存储最适合？
不仅要根据数据类型如结构化、半结构化、非结构化来区分存储的选择，而且还要根据数据的重要性、时效性、数据量大小、成本投入等来区分存储的选择。一般来说重要的、时效性要求高的结构化数据，一般采用高端的全闪存储或同类级别的存储，并且配以双活等高可用手段；重要性一般的非结构化数据可以采用分布式存储或者对象存储；重要性一般，共享需求较高的，则可以采用NFS类型的存储。当然上述存储选择的建议也非绝对的，还是要根据具体的业务情况具体分析。
6、医院大数据平台数据是如何备份的？
【问题描述】医院大数据平台数据是如何备份的？环境是非hadoop环境，是基于数据库环境做的大数据平台，怎么备份呢？推荐规划备份频率是？？备份方式建议分类备份。针对大数据平台的应用部分，一般体量较小，建议是根据更新频率进行，每次更新后进行全量备份。针对大数据平台的数据部分，因为是数据库，建议可以采用数据库专有技术做实时容灾，如oracle的dataguard，sqlserver的mirror等。除了实时容灾外，在数据库建立后做一次全量备份，并且可以根据数据增长情况及数据恢复时限要求做每周、每2周或每月一次的全量备份，中间时间辅以差异备份。
