第二篇　技术篇

随着医疗和健康产业信息化的普及推广和快速发展，健康医疗数据已具备了大数据的典型特征。健康医疗数据，在来源上可以分为业务系统数据、物联网设备数据、生物医学数据、互联网络数据等类型；在数据格式上可分为结构化、非结构化和半结构化数据等类型。在采集技术上可分为传统数据采集、分布式文件系统采集、日志文件数据采集、流数据采集和网站数据采集等几类技术。数据采集后，需要传输到数据中心，并进行数据集成和数据清洗。本章将从数据来源、数据采集、数据传输、数据预处理几个维度来介绍健康医疗大数据的获取技术。

1.互联网大数据一般来源有以下几种：

（1）企业应用产生的数据：企业经营活动产生的，存放在企业内部的关系型数据库或数据仓库中。

（2）网络活动产生的数据：用户使用互联网应用、移动应用，如搜索、浏览、评论、发布消息等行为产生的数据，存放在公众网站或网站服务器的日志文档中。

（3）物联网设备产生的数据：各种物联网设备，如天气、水、电、各种传感器、视频监控设备、电子标签识别采集设备等每时每刻产生着巨量数据。

（4）科学观测与实验产生的数据：光学观测和监控、高能物理、计算生物学、天文学等科学应用产生的海量数据。

2.从数据生成模式上看，上述几种数据产生领域的生成模式可分为：

（1）被动记录模式：服务提供方受理服务请求时被动记录到信息系统。

（2）主动生成模式：服务消费方主动搜索、主动发布社交信息到信息系统。

（3）自动生成模式：不需要服务提供方或服务消费方操作，由设备持续不断生成信息并发送给信息系统。

将大数据的业务范围聚焦在健康医疗这个领域上，健康医疗大数据的来源一样可以分为业务系统数据、互联网络数据、物联网设备数据、生物医学数据几类，如图3-1所示。

健康医疗业务系统可以分为两类：一类是医院内部运行的业务系统，统称医院信息系统；另一类是在区域范围内运行的业务系统，统称区域卫生信息系统。

医院内部运行的业务系统，产生的数据可以称为医院医疗大数据，是健康医疗大数据的最主要的组成部分。医院信息系统分为医院管理信息系统和临床信息系统两大类。

包含：门急诊挂号系统、门急诊划价收费系统、住院患者入出转管理系统、患者住院收费系统、药品库存管理系统、病案管理系统、物资管理系统、设备管理子系统、财务管理系统、人事管理系统、院长查询与分析系统等。

包括：医生工作站、护士工作站、医嘱处理系统、患者床边系统、重症监护系统、移动输液系统、合理用药监测系统、临床检验信息系统、医学影像系统、输血及血库管理系统、手术麻醉管理系统等。

医院信息系统记录着大量的诊疗数据，产生于医院的临床诊疗、管理过程中，包括门急诊记录、住院记录、医嘱处方信息、执行记录、检验报告、影像记录、医保费用情况等。这些诊疗数据多数是医生、护士的业务过程记录，以医学专业方式书写的原始临床记录，可能存在数据不完善甚至错误，但是从临床管理和研究的角度看，这些数据都可能隐藏了有待挖掘的重要医学价值。

医院医疗大数据通常可分为三种类型：

1.结构化类型　如医嘱处方、医疗费用、检验记录等。医护人员通过医嘱系统、门急诊划价收费系统、患者住院收费系统，规范地记录了患者的药物治疗及其他检查治疗项目信息，形成患者的医疗费用支出情况，这些数据都以固定的格式存在于关系型数据库中。医学检验数据来自检验设备，如血常规、生化免疫指标等，遵循检验标准接口规范，形成结构化数据。

2.半结构化数据　如电子病历病程记录数据。病历数据是由医生在问诊、体格检查、诊断鉴别、治疗等过程中记录产生的以文字描述为主体的数据。电子病历系统一般定义不同颗粒度的病历模板，记录不同的医疗文书，因此电子病历数据是一种半结构化的数据。

3.非结构化类型　如放射影像、超声影像、内镜影像、病理图像等。这类记录产生于各类医学检查环节，以大量影像小文件的形式存放在服务器的文件目录中。

医院医疗大数据具有大容量、快速更新、多类型、高价值等特征。首先，业务系统产生的数据量大、数据丰富。以一家三甲医院为例，年诊疗人次为200万左右，每年将生产大量的电子病历数据信息，而且院方还必须保存往年的电子病历。根据《医疗机构管理条例实施细则》规定，医疗机构的门诊病历的保存期不得少于15年，住院病历的保存期不得少于30年。其次，系统数据更新很快。现代医疗护理越来越依赖于各种检查和检验结果。检查和化验的人数正在迅速增加，其数据也迅速更新。再次，业务系统数据，包括数值、图像、文本、视频和图形等多种类别。最后，电子病历数据中隐藏着极其宝贵的医疗和医学信息，通过数据挖掘技术找出有价值的信息，医生能够进一步分析患者的病因并形成更好的医疗方案。

区域范围内运行的业务系统，例如区域医疗卫生信息平台或区域协同类的应用系统，是健康医疗大数据的另一类系统数据来源。首先，区域协同通过医疗卫生信息平台汇集了该地区多家医院和相关医疗机构的医疗健康数据，导致数据量显着增加。其次，因为平台数据在采集前已经进行了充分、科学的论证和规划，所以会比来自单一医院的数据更为规范化。区域业务系统产生的数据，包括区域卫生信息平台采集的居民健康档案、疾病监控系统实时采集的数据等。区域范围内运行的业务系统还逐步延伸到医药、医保等相关领域的信息共享和数据融合。

国务院办公厅《关于促进和规范健康医疗大数据应用发展的指导意见》中，鼓励各类医疗卫生机构推进健康医疗大数据采集、存储，加强应用支撑和运维技术保障，打通数据资源共享通道。加快建设和完善以居民电子健康档案、电子病历、电子处方等为核心的基础数据库。建立卫生计生、中医药、教育、科技、工业和信息化、公安、民政、人力资源社会保障、环保、农业、商务、安全监管、检验检疫、食品药品监管、体育、统计、旅游、气象、保险监管、残联等跨部门密切配合、统一归口的健康医疗数据共享机制。健康医疗业务系统的数据来源逐步从健康医疗领域扩展到各相关部门领域的业务系统。

移动健康（mobile health，mHealth）是将通信技术应用于卫生健康领域，提供健康服务和信息，实现“移动通信平台+健康传感终端+健康服务”，从而提供实时、连续、长期的健康服务。基于移动物联网的个人活动和身体特征的自我量化数据是一种新型的健康医疗大数据。除了帮助大众及时了解自己的健康状况外，该数据所包含的心率、血压、血糖、呼吸、体能锻炼和睡眠等信息，经过长时间的累积，在医学上变得很有价值，有助于确定疾病的原因，或者预防和控制疾病，还有助于个性化的临床诊断和治疗，从而创造出一种全新的医疗健康管理模式。

现有的穿戴式传感器和移动终端可获得的数据如下：

在实现移动健康的心电信号监测中，与Holter系统、TTM心电监护系统有所区别，其具有的移动通信功能可以为用户提供更大活动范围、更为灵活的通讯方式。以往需要在医院使用传统心电图机才能开展的心电测试可以很方便地在居家环境中用移动终端实现，用户只需经过简单的操作就可以完成心电信号的采集。

生命四大体征包括脉搏、呼吸、血压、体温，医学上称为四大体征。它们是维持机体正常活动的支柱，用户生命体征数据的釆集对用户疾病预防及治疗跟踪具有重要的意义。穿戴式设备以及智能终端可以通过集成的生物传感器实现对用户生命体征数据的采集。

伴随移动互联网的快速发展，运动健康类的移动应用以其关注程度和实现便利性得到了最为广泛的推广。利用移动终端的定位、记录和交互式的引导功能，用户的健康数据、个人信息得到了有效积累。在运动健康的健康数据采集中，主要分为两种数据类型：①基于用户的行为模式以及活动记录相关的数据，主要集中在地理信息、锻炼信息、习惯记录等，部分会采用传感器用以辅助完成；②基于运动传感器的身体运动信息的监测，通过传感器对用户行为状态进行监测，可以分析跌倒状态、步态等信息，构建基于人体传感器网络的健康监护系统。

实际上，现有的健康监测技术往往是多参数的同步提取，比如在基于图像信息的生理参数提取技术中，可以通过PPG图像完成脉率、呼吸率的提取；又如在基于织物的生理参数采集系统中，可以完成心电、体温、呼吸、运动等多参数的采集，还有针对糖尿病患者的血糖监测，针对运动员的肌电信号、脑电信号监测等。基于多参数的传感系统传感器技术的发展，带来的是对人体参数的检测和更加全面地记录，对个人的健康和状态的分析与认识也更加清楚，但是所带来的数据类型也越来越多，数据的结构更加复杂。

移动健康的监测数据，有很多是在医生的指导下完成的，移动互联网技术为这些信号的采集、存储带来了相应的便利，但相关的数据或者记录会被存储在医院的医疗业务系统之中。也有部分健康数据不是存储在医院医疗业务系统，而是存储在移动健康传感终端的服务提供方，如WellDoc公司研发的基于云端大数据和手机APP的糖尿病管理平台，是获得美国食品和药品监督管理局批准的手机应用，用户可以通过手机实时记录、存储和利用糖尿病数据。移动健康监测数据的特点是数据量大、种类繁多，但准确性较差，需进行有效校准和过滤方可使用。

生物检测仪器可产生大量的生物医学数据，这类数据具有很强的生物专业性，主要是关于基因测序和生物样本的信息。从人体的血液或唾液中可以检测得出基因全序列，用来揭示一个人的生命密码。据估计，人类基因全序列测序，单次可生成的数据量高达100～600GB。目前，每年全球产生的生物数据总量已达EB级，使得生命科学已经成为大数据科学。

虽然生物医学大数据与上述医疗大数据、移动健康监测大数据在信息内容表达方式上有很大差异，但它来源于人体生物标本，且与临床的个性化诊疗及精准医疗有关系，所以也被归于健康医疗大数据的一类。

生物检测仪器的使用方可以自行建设生物医学数据库，也可将检测结果数据共享到公共的生物数据库中。互联网的各类公共生物数据库提供了有关生物分子、微生物分类等的详细信息。中国最新建设的“国家人口与健康科学数据共享平台”，也已经包含237个数据集，数据量达到49.1TB，覆盖包括生物医学、基础医学、临床、公共卫生、中医药学、药学、人口与生殖健康七大类，将带动生物医学数据资源的整合与共享。

健康医疗网站数据丰富多样，可以提供多种服务，通过服务呈现有价值的数据。社交互联网关于健康、疾病或寻医的话题、在互联网上搜索相关内容和购买药品的行为以及访问健康网站等行为所产生的数据构成网络健康医疗数据。具体包含以下几种：

1.对大众提供专业的健康资讯，满足公众对医疗健康知识的迫切需求，为各类人群提供医学、健康等领域的各种信息资讯服务。

2.患者间、患者和专科医生之间的互动可通过专家频道或健康论坛等形式形成。

3.通过网站与其他医疗机构的互动和网友分享的经验，给患者提供一站式的就医信息指导，提供专科疾病的就医建议，为患者选择正确的医院和合适的医生提供有价值的参考。

互联网来源获取的健康医疗相关数据往往杂乱无章，同一主题的数据既可来自不同的网站，也可来自同一网站中不同的网络用户，而且有时会包含大量文本、音视频、图片等异构性数据，随机性非常大，数据中包含的信息缺乏稳定性。由于信息噪声高、缺乏医疗专业规律，所以网站来源的数据能提供的医学价值很有限。即使一小部分可被用于分析，但也必须要进行数据预处理和专业设计。

除了健康医疗网站，还有部分数据来源于专业医疗文献站点。该类站点中包含大量临床诊疗相关的学术资料，主要面向专业的医疗从业者，多采用会员制，因此采集数据时也需要考虑网站的限制。

上述数据来源类型繁多，数据格式也多种多样，包括视频、文本、图片、网页、数据库等各类结构化、非结构化和半结构化数据。大数据应用的关键，就是从海量的看似无关的数据中，通过分析关联关系，从而获取有价值的信息。因此，有效获取来源数据成为大数据应用必须解决的首要问题。大数据处理的第一步是从数据源采集数据并进行预处理和集成操作，为后续流程提供高质量的统一的数据集。根据来源类型的不同，需要使用不同的数据采集技术：

1.健康医疗业务系统产生的业务数据，以及生物医学检测仪器产生的生物数据，存储在传统关系型数据库中，需要使用传统ETL工具来抽取数据，再进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。典型的ETL工具有Datastage、Kettle、Informatica等。

2.ETL工具抽取、清洗并完成加载后的形态，仍然是传统关系型数据库或数据仓库，具有硬件成本高、扩展能力有限、无法分析海量非结构化数据等缺点，因此需要使用Sqoop等工具将传统数据库的数据以及非结构化数据加载到分布式文件系统，如Hadoop文件系统（HDFS）中，以实现海量超大文件的分布式并行分析处理。

3.业务系统与用户交互过程中产生大量的日志和审计数据，常用日志搜集和监测系统来获取数据，如Hadoop的Chukwa、Facebook的Scribe、Cloudera的Flume等。这些工具都使用分布式架构，可满足每秒数百MB的日志数据采集和传输需求。

4.各类移动健康传感终端设备产生大量实时流数据，常用数据流处理系统来获取数据，本书其他部分会对流处理技术进行详细阐述，本部分仅阐述流数据采集接入环节所使用的技术。在分布式系统中一般使用分布式消息队列产品来实现分布式系统的进程间通信，如Apache kafka。

5.健康医疗互联网数据，是用户在互联网活动中产生的数据，常用到的数据获取技术有网络爬虫或网络嗅探等。

下面分别进行介绍。

对于传统数据库数据，一般使用传统ETL工具进行采集。ETL，用于描述从来源经提取（extract）、转换（transform）、加载（load）数据至目的地的过程。传统数据库是指关系型数据库，如Oracle、MySQL、Sql Server等。关系型数据库是使用关系模型来组织数据的数据库。

关系型数据库具有如下特点：①易于理解，二维表结构是非常接近逻辑世界的一个概念；②使用方便，通过SQL语言使得程序员可以方便地在逻辑层面操作数据库而无须了解其底层实现；③易于维护，完备的数据表关联规则大大降低了数据冗余和数据不一致的概率。鉴于传统数据库的这些特点，现阶段大部分商业软件系统仍使用传统的关系型数据库。

从传统数据库中提取数据通常分为如下几个步骤：抽取、清洗、转换、装载。

主要是针对分散数据，如各个业务系统和不同网点的数据，充分了解数据定义后，规划需要的数据源及数据定义，制订可操作的数据源和量抽取的规则。

主要是针对系统的各个环节可能出现的数据二义性、重复、不完整以及违反业务规则等问题。允许通过试抽取，先剔除有问题的记录，并根据实际情况调整相应的数据读写操作。

主要是基于数据仓库建立的模型，通过一系列的转换实现将数据从业务模型到分析模型，通过自定义脚本、内置的库函数或其他的扩展方式，实现多种复杂转换，并且支持调试环境，可清晰监控数据转换状态。

主要是将转换后的数据装载到数据仓库中，通过直接装载数据文件或直接连数据库的方式进行数据装载。

在业务应用中，数据采集工作的ETL运行方式可以随时调整，并可灵活集成到其他管理系统中。典型的ETL工具有：Datastage、Kettle、Informatica等。

IBM WebSphere DataStage（下面简称为DataStage）是IBM提供的一种数据集成软件平台，为整个ETL过程提供了图形化开发环境。它是一个集成工具，可简化和自动化处理多个数据源的数据提取、转换和维护过程，并将它们导入数据集或数据仓库。它是目前使用比较广泛的工具之一。

DataStage能够直接连接非常多的数据源，包括Oracle、DB2、SQL Server等关系型数据库，IMS层次数据库，以及FTP、XML等文件系统。DataStage内部使用UTF-8编码，可以支持多国语言，这也是它被广泛使用的重要原因之一。DataStage企业版还可以在装有DataStage Server的多台机器上并行执行，从而可以高效处理大量数据。

在实现异构数据转换时，Datastage主要使用两种模式——复杂模式和基本模式。①复杂模式：通过改变数据的格式及存储方式，实现数据在不同类型数据库之间移动；②基本模式：主要针对两个或者更多的具有相同结构的数据库，实现数据在它们之间的移动。这两种方式都是通过定期更新数据库中的数据，实现在数据库级别上的数据共享。

但是DataStage也存在一些缺点。例如，当表被定义后，将被作为模板使用并且不能被修改。若手动修改表格结构时，Datastag将无法发挥同步的作用。再者，Datastage很难捕获业务上的错误，难以实现对数据监控等应用要求。

关于Datastage的工具，IBM在开发过程中提供了一套图形化客户工具，这套工具是基于客户机/服务器的数据集成架构。它主要包括管理器（Manager）、设计器（Designer）和控制器（Director）。①管理器的职责：组织管理各个单元，包括定义表格、转换数据、连接元数据等；②设计器的职责：创建数据集成任务，并且对数据流转化过程的可视化演示；③控制器的主要职责：启动、停止和监视控制等。

DataStage数据集成的总体过程是将来自不同形式的数据源按照不同的分析主题需要进行采集，将其清洗成干净的数据源，并将其传输到目标数据仓库。Datastage通过运行Job来完成数据集成，一般流程是：定制抽取—转换和载入数据的Job—检测Job的可行性—运行Job—查看Job运行报告。

Kettle是一款开源免费的、元数据驱动ETL工具，可以用来管理来自不同数据库的数据源，可运行在Windows、Linux、Unix之上。Kettle中文名称叫水壶，该项目的主程序员希望把各种数据放到一个壶里，然后以一种指定的格式流出来。Kettle的出发点是面向解决方案，并把工作流作为其核心的商业智能套件。它提供的解决方案，大多是针对大中型企业的，强调与业务流程相整合。该软件是在Java平台上开发的，除了web server以外，它还包括报表、图表、数据挖掘等商业智能的相关工具。

Kettle主要包含了两种工作脚本，分别是Transformation和Job。

Transformation完成针对数据的基础转换，转换包括数据输入、转换过程和数据输出三部分。①输入：Kettle对常规数据库数据文件都有支持；②转换：转换的工作比较丰富，可以查询数据库，也可以执行Sql和Shell等脚本；③输出：数据的输出形式涵盖了目前常见的各种形式。

Job则完成整个工作流的控制，做预处理和清理的工作，预先执行脚本，转换完成后清理资源文件，定制执行任务，日志和邮件报告任务情况等，脚本可以是Javascript、Sql、Shell等。

Kettle有四个主要产品：Spoon、Pan、Chef和Kitchen。Spoon允许将ETL的转换过程通过图形界面来设计；Pan允许由Spoon设计的ETL转换批量运行；Chef允许创建任务（Job）；Kitchen允许由Chef设计的任务批量使用。

Kettle可以完成多种任务：①不同应用程序或数据库之间的数据迁移；②大量数据加载到数据库；③数据库与文件之间数据的导入、导出；④数据清洗；⑤应用集成等。Spoon设计的转换Job是一个控制数据流，因此Kettle的数据集成是面向数据流的。

Kettle的优点是工具免费且完全开源，使用过程相对稳定，Job发生错误的概率很小，开发效率高，控件可以通过拖拽的方式完成。缺点是功能版本更新不够及时，对于错误的信息提示不够详细，个别特殊功能还有待改进，例如FTP数据下载功能不足。

Informatics PowerCenter是Informatics公司开发的世界级的企业数据集成平台。Informatics Power-Center提供了一个非编码的图形化设计工具，用于用户调试使用，具有功能强大的数据集成引擎，在内存中执行数据抽取、转换、整合、装载等所有功能，开发人员不需要手工编写这些过程的代码。引擎是元数据驱动的，通过知识库和引擎的配对管理，可以确保数据集成过程得到最佳实施。可通过辅助产品Informatics PowerConnect，提供对特殊数据源和格式的支持，包括SAP、Siebel、PeopleSoft等ERP数据源。具有数据高效并行功能（Data smart parallelism），使用户能够自定义分区并提供优化的数据并行处理。

作为企业级核心数据集成引擎，Informatics PowerCenter可以单独部署或部署在分布式体系结构中。如果部署在分布式体系结构中，Informatica PowerCenter需协调和管理由Informatica PowerMart或Informatica PowerCenter引擎在局域网或广域网内执行的多个基于主题的数据集市。PowerCenter for Remote-Data是Informatica PowerCenter一个分布式数据整合选项，提供安全的、高性能的、高投资回报率的方法，使用户能够跨广域网与供应商、合作伙伴以及其他远程数据源交换信息。

Informatica的产品还包括：①Data Quality：主要负责控制数据质量；②PowerExchange：主要负责访问数据；③Infomnatica Cloud：提供了一个数据间集成云应用；④B2B Data Exchange：负责多个企业之间的数据交换；⑤Master Data Management：负责整合关键业务数据等。

Infonmatica的产品强调管理的重要性，而且逻辑设计与数据库相互独立，开发人员无须直接接触实体数据库，满足IT管理需要。整个的实施过程通过甘特图进行展现，图形化地跟踪执行状态与消耗的资源等情况。其日志可以存储在数据库中，以方便后续的查询和集成操作。

2003年，Google公司宣布推出两款高性能、高可扩展的分布式海量数据处理框架Google File System（GFS）和MapReduce，并验证了处理框架在海量网页数据处理方面的优势。上述框架实现了分布式存储和分布式计算更高层次的抽象，使用户无须关注复杂的内部并行工作机制，并且不用具备丰富的分布式系统知识及开发经验，即可实现大规模分布式系统的部署以及海量数据的并行处理。Hadoop还提供了一系列的数据采集并行传输接口，用于实现HDFS和不同数据源之间的数据交换，例如HDFS与关系型数据库进行数据交换的工具Sqoop，本地文件系统和HDFS进行数据交换的服务FTP等。

对传统数据库与Hadoop之间数据导入、导出，Sqoop提供了较好的解决方案。

Sqoop是一个用来将关系型数据库和Hadoop中的数据进行相互转移的工具，可以将一个关系型数据库（如Mysql、Oracle）中的数据导入Hadoop（如HDFS、Hive、Hbase）中，也可以将Hadoop（如HDFS、Hive、Hbase）中的数据导入关系型数据库（如Mysql、Oracle）中（图3-2）。

Hive是由FaceBook开发并构建于Hadoop集群之上的数据仓库应用，由FaceBook贡献出来，成为Apache下面的开源项目。Hive可以将结构化的数据文件映射为一张数据库表，并提供丰富的类似SQL的数据处理功能。Hive使用名为HQL的脚本语句，用户编写的HQL脚本语句被Hive解析为MapReduce作业并在Hadoop集群上运行。与自己编写MapReduce代码相比，Hive的优点是代码量小，学习成本低，用户可以通过少数的HQL语句快速实现更复杂的MapReduce数据处理逻辑。最终结果也可以以Hive数据表的形式存储在HDFS上。

HQL是一种声明式语言，它的逻辑与工作流的相似性很小，这使得基于它的设计组件变得难度相对大一些。此外，Hive需要定义与数据相关的元数据并管理这些数据。Hive提供外壳环境来接收并执行用户直接输入的HQL脚本，Hive还为客户端提供一系列服务，客户端可以通过JDBC、Thrift和ODBC三种方式来与服务端进行交互。

随着企业业务系统规模的迅速扩大，服务器集群节点数不断扩增，运维日志规模随之急剧增加。日志分析一直是体现应用系统运行状况和用户行为的重要方式。越来越多的企业通过日志分析处理拓展了更多的创新方向，比如用户行为分析和个性化推荐等。

日志文件的数据形态包括MySQL数据库、Oracle数据库、网络数据、文本文件等。存储位置可能在多个集群机器的分布式存储中，因而日志采集需要增量实时获取类似于流处理的日志文件。当日志规模很大时，需要分布式平台来存储和处理数据。常用的日志搜集和监测系统有Hadoop的Chukwa、Facebook的Scribe、Cloudera的Flume等。

Chukwa是Hadoop系列产品，因此使用了很多Hadoop的组件（用HDFS存储，用MapReduce处理数据），它提供了很多模块以支持Hadoop集群日志分析。主要特点如下：①灵活动态可控的数据源；②高性能，高可扩展的存储系统；③合适的框架，用于对收集到的大规模数据进行分析。

Chukwa的框架中主要有3种角色，分别为：Adaptor、Collector、Agent。

可封装其他数据源，如File、Unix命令行工具等。目前可用的数据源有Hadooplogs、应用程序度量数据、系统参数数据（如Linux Cpu使用率流）。

Chukwa采用了HDFS作为存储系统。HDFS旨在支持大文件存储和小并发高速写入的应用场景，而日志系统的特点恰好相反，它需支持高并发、低速率的写入和大量小文件的存储。需要注意的是，在关闭文件之前直接写HDFS的小文件是不可见的，HDFS不支持文件重新打开。

为了克服上述问题，增加了Agent和Collector阶段。

Agent的作用是给Adaptor提供各种服务，包括启动和关闭Adaptor，将数据通过HTTP传递给Collector；定期记录Adaptor状态，以便崩溃后恢复。

Collector的作用是对多个数据源发过来的数据进行合并，然后加载到HDFS中；隐藏HDFS实现的细节，如HDFS版本更换后，只需修改Collector即可。

Scribe是Facebook开源的日志收集管理系统，在Facebook内部大量服务器上已经得到广泛的应用。它主要包括三部分，分别为Scribe Agent、Scribe和存储系统。

Scribe Agent实际上是一个Thrift Client。向Scribe发送数据的唯一方法是使用Thrift Client，Scribe内部定义了一个Thrift接口，用户使用该接口将数据发送给服务器。

Scribe接收到Thrift Client发送过来的原始数据，根据配置文件，将不同Topic的数据发送给不同的对象。Scribe提供了各种各样的Store，如File、HDFS等，Scribe将数据加载到这些Store中。

存储系统实际上就是Scribe中的Store，当前Scribe支持非常多的库，包括File、Buffer、Network、Bucket等不同存储形态。

Flume是Cloudera于2009年7月开源的日志系统。它内置的各种组件非常齐全，用户几乎不必进行任何额外开发即可使用。Flume采用的三层构架：

Agent的作用是将数据源的数据发送给Collector。

Collector的作用是将多个Agent的数据汇总后，加载到Storage中。它的Source和Sink与Agent类似。

Storage是存储系统，可以是一个普通File，也可以是Hdfs、Hive、Hbase等。

其中，Agent和Collector均由两部分组成：Source和Sink，Source是数据来源，Sink是数据去向。

Flume的主要特点是：

1.可靠性　当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：

（1）End-To-End：收到数据Agent首先将Event写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。

（2）Store On Failure：这也是Scribe采用的策略，当数据接收方Crash时，将数据写到本地，待恢复后，继续发送。

（3）Best Effort：数据发送到接收方后，不会进行确认。

2.可扩展性　三层架构的每一层均可以水平扩展。其中，Master统一管理所有Agent和Collector，这使得系统易于监控和维护，且允许有多个Master（使用Zookeeper进行管理和负载均衡），从而避免了单点故障问题。

3.可管理性　Master统一管理所有Agent和Collector，这使得系统易于维护。用户可以在Master上查看每个数据源或者数据流执行情况，并且可以配置和动态加载各个数据。Flume提供了Web和Shell脚本命令两种形式对数据流进行管理。

4.功能可扩展性　用户可以根据需要添加自己的Agent、Collector或者Storage。此外，Flume自带了很多组件，包括各种Agent（File、Syslog等）、Collector和Storage（File、Hdfs等）。

ELK是Elasticsearch、Logstash和Kibana三种软件产品的首字母缩写。这三者都是开源软件，通常配合使用，而且又先后归于Elastic.co公司名下，所以被简称为ELK Stack。目前，ELK Stack已经成为最流行的集中式日志解决方案。

分布式搜索和分析引擎，具有高可伸缩、高可靠和易管理等特点。基于Apache Lucene构建，能对大容量的数据进行接近实时的存储、搜索和分析操作。通常被用作某些应用的基础搜索引擎，使其具有复杂的搜索功能。

数据收集引擎。它支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储到用户指定的位置。

数据分析和可视化平台。通常与Elasticsearch配合使用，对其中数据进行搜索、分析和以统计图表的方式展示。

ELK协议栈的新成员，一个轻量级开源日志文件数据搜集器，基于Logstash-Forwarder源代码开发，是对它的替代。在需要采集日志数据的Server上安装Filebeat，并指定日志目录或日志文件后，Filebeat就能读取数据，迅速发送到Logstash进行解析，或直接发送到Elasticsearch进行集中式存储和分析。

在ELK的常用架构中，一般只有一个Logstash、Elasticsearch和Kibana实例。Logstash通过输入插件从多种数据源（比如日志文件、标准输入Stdin等）获取数据，再经过滤插件加工数据，然后经Elasticsearch输出插件至Elasticsearch，通过Kibana展示。图3-3为ELK常用架构图。

在实际应用中，业务开发人员可以通过对Logstash搜索搜集点进行多点扩展，或者引入Beats作为日志搜集器对系统进行扩展和性能提升。Logstash还支持Kafka、Redis、RabbitMQ等常见消息队列。因此，可以在架构中加入消息队列，Logstash从各个数据源搜集数据，然后经消息队列输出插件至消息队列中。业务开发人员可以根据业务的实际情况选择合适的架构来完成项目。

需要注意的是，免费的ELK没有任何安全机制，因此在使用ELK架构时需要注意对应的安全防护。

流数据挖掘（stream data mining）指在“流数据”上发现并提取隐含的、事先未知的、潜在有用的信息和知识的过程。在流数据环境下，数据连续、快速、源源不断地到达，反复存取操作变得不可行，其隐含的聚类可能随时间动态地变化而导致聚类质量降低，这就要求流数据聚类算法快速增量地处理新数据，简洁地表示聚类信息，稳健地处理噪声和异常数据。基于流数据挖掘的特点，流数据一般通过定制接口或订阅的方式进行数据接入，Apache Kafka可提供较好的解决方案。

Apache Kafka是一个分布式发布-订阅消息系统和一个强大的队列，可以处理大量的数据，并使用户能够将消息从一个端点传递到另一个端点。Kafka适合离线和在线消息消费。Kafka消息保留在磁盘上，并在群集内复制以防止数据丢失。Kafka构建在Zookeeper同步服务之上，它与Apache Storm和Spark非常好地集成，用于实时流式数据分析。

Kafka专为分布式高吞吐量系统而设计，与其他消息传递系统相比，Kafka具有更好的吞吐量、内置分区、复制和固有的容错能力，这使得它非常适合大规模消息处理应用程序。

1.通过磁盘数据结构提供消息的持久化，即使数以TB的消息存储也能够保持长期稳定的性能。

2.高吞吐量　即使是非常普通的硬件，Kafka也可以支持每秒数十万的消息。

3.支持同步和异步复制两种HA。

4.Consumer客户端Pull，随机读，利用Sendfile系统调用，Zero-Copy，批量拉数据。

5.消费状态保存在客户端。

6.消息存储顺序读写。

7.数据迁移、扩容对用户透明。

8.支持Hadoop并行数据加载。

9.支持Online和Offline的场景。

10.持久化　通过将数据持久化到硬盘以及Replication防止数据丢失。

11.Scaleout：无须停机即可扩展机器。

12.定期删除机制：支持设定Partitions的Segmentfile保留时间。

Kafka有4个核心的API：

允许一个应用程序发布一串流式的数据到一个或者多个Kafka Topic。

允许一个应用程序订阅一个或多个Topic，并且对发布给它们的流式数据进行处理。

允许一个应用程序作为一个流处理器，消费从一个或者多个Topic产生的输入流，然后生产一个输出流到一个或多个Topic中去，在输入输出流中进行有效的转换。

允许构建和运行可重用的生产者或者消费者，将Kafkatopic连接到已存在的应用程序或者数据系统，如连接到一个关系型数据库，捕捉每一个对表的改变。

Kafka核心API关系如图3-4所示。

互联网上的信息多种多样，数据的格式也多种多样，这样的数据一般是通过网络爬虫对所需数据进行一个定制化的采集，针对不同的网站建立不同的采集模版。将采集到的数据通过HTTP传输给到Flume，Flume写入Kafka消息队列中。Flink获取该消息队列的信息，通过自定义的处理方式，处理对应的数据存储到数据仓库当中。

根据需求的不同，将网络爬虫技术分为不同种类：

通过Url链接获取此Html页面中指定的链接，存储这些链接，然后使用这些链接作为源再次爬取链接指向Html页面中的链接……如此层层递归下去，普遍使用的方法是深度优先或者广度优先，并且根据不同级别的抓取需求选择不同的方法以获得最佳的效果，效率优化是爬虫的一个关键。通过爬虫获取必要的链接或者数据是搜索引擎的第一个步骤，将其存储在数据库中，建立索引，然后定义查询语句，解析查询语句并利用检索器检索数据库里的数据。

如图片、文本信息等，根据需要通过某种手段获取数据样本供后续数据分析使用，常用的方法是爬虫利用现有的公共数据库或获取指定数据样本。

网络爬虫的原理：由关键字指定的Url把所有相关的Html页面全抓下来（Html集为字符串），解析Html文本（通过正则表达式或者现成工具包Jsoup），提取健康医疗信息，然后把信息存储起来。网络爬虫的框架如图3-5所示。

基本工作流程如下：

1.首先选取一部分精心挑选的种子URL。

2.将这些URL放入待抓取URL队列。

3.从待抓取URL列队中取出待抓取URL，解析DNS，并且得到主机的IP地址，并将URL对应的网页下载下来，存储进已下载网页库中。此外，将这些URL放进已抓取URL队列。

4.分析已抓取URL列队中的URL，分析其中的其他URL，并且将URL放入待抓取URL队列，从而进行下一个循坏。

数据采集后，需要传输到相应的服务器节点或数据中心，并进行预处理操作，包括数据集成和数据清洗。

除非设备很少且距离很短，否则要在每两台设备之间提供一条专线是不实际的。解决这一问题的办法是将所有设备都连接到一个通信网络上。传统上，通信网络被归结为两大类——广域网（WAN）和局域网（LAN）。近年来，不管是从技术的角度，还是从应用的角度，这两类网络之间的区别已经变得越来越模糊，但不管怎样，这种划分对网络构成的认识还是很有用的。

不同信息系统之间通过网络进行传输，常用的数据交互方式主要包括如下几种：

文件传输是实现系统之间数据交互最早也是最通用的一种方式。各系统事先定义好需要进行数据交互的文件格式，包括文件名、文件结构、文件存放位置、文件读写时间等，使双方的系统都能识别，以满足交互的要求。例如：FTP服务器共享方式即建立一个FTP服务器，为不同的系统分配账号、密码、目录的操作权限等，要交换数据的两个系统要约定好数据格式（如XML文件、Excel文件、Csv文件等）、文件命名方式、存放路径等规则等。交互时，一个系统按约定的时间将数据写入FTP目录中，另一个系统定期取走并进行相应的业务操作。

共享数据库方式能够满足结构化数据的交互要求，交互双方基于同一个共享数据库实现对交互数据的存储和访问。

套接字方式应该说是一种基于通信协议实现的数据交互方式，双方系统通过在指定的IP地址和端口的套接字上进行数据传输。这种方式也需要系统双方事先定义交互格式，而且是以字节的方式进行定义。

远程过程调用RPC（Remote Process Call）提供了一种系统之间直接进行进程调用的机制。RPC为一个进程提供了访问其他进程服务的能力，这些进程往往处于不同的计算机。RPC是一种客户机/服务器形式的服务，一个客户机进程可以执行另一台计算机上的进程，向这个进程提供数据，获取这个进程运行的结果等。

消息传递方式是指交互双方按照统一的消息格式进行消息的发送和接收，消息的结构一般分为消息头和消息体。消息头封装了发送方或接收方的基本信息，一次交互过程可能会由多次消息传递来完成。

使用基于数据库级的成熟的集成软件工具，如IBMDatastage、Oracle数据集成套件，来满足健康医疗机构环境下的数据转换。实现数据集中交互模式，通过分析数据库的日志文件实现数据同步转换，大大提高了数据的实时性，降低了系统集成难度。分离基础业务与综合业务，从而提高基础业务系统的稳定性，以适应医疗机构不断更新的综合业务需求。

目前各电子病历产品间非关系型电子病历数据存贮差异巨大，这与CDA文件交换标准不符，并且也无法脱离各自系统环境进行电子病历展示。通过接口开展数据采集和格式转换，数据中心可能实现非关系型电子病历展示格式的统一，实现符合CDA标准交换文档的生成。通过分析整合平台的应用，理清数据仓库数据架构，将需要频繁查询且不变的的信息存入数据库关系型字段名中，将个性化的信息存入数据库中XML非关系型字段中，最终形成统一的数据平台数据架构。

目前，各医疗机构实施的集成平台的接口方案大多基于WebService在线应用服务。WebService的主要目标是实现跨平台的可互操作性，易通信。为实现这一目标，WebService完全基于XML（可扩展标记语言）、XSD（XMLSchema）等独立于平台、独立于软件供应商的标准。使用WebService通讯接口将为跨防火墙、异构数据库系统、B2B的数据交易集成带来巨大优势。WebService工作流程如图3-6所示。

但对于医疗机构内部局域网而言，不需要跨跃防火墙，并为同构数据库系统，使用DCOM会比SOAP/HTTP有效得多。这与区域数据中心面向多家医疗机构的接口环境完全不同。

将各个系统需要交互的数据通过统一的ETL接口模式，实时同步、转换并保存到数据中心平台的数据仓库中，各业务系统需要访问其他业务系统的数据时，可通过平台数据仓库获得。此方案实现了统一的同步数据转换配置方案，减少了系统间构造与解析XML文档环节，提高了工作效率。对于设备与系统间的信息传递，不能直接传递到数据仓库中，需要通过各子系统完成数据转换后传递至数据仓库。

数据中心平台可以使用CDA架构传输和存储非关系型结构文档，例如医疗机构中患者检验检查申请、检查报告与电子病历文书等。这些文档可以由各系统构造完成，也可以由数据中心的数据适配转换集中完成。CDA的目的是将单一患者的纵向临床文档进行交换，它是描述临床文档的结构和语义的文档标记标准。但CDA不适合在医疗机构内部实时高效的大数据量数据交换。若将医嘱、处方、患者入院等关系型简单数据的传递通过CDA文档构造与解析进行交互，会大大降低系统运行效率。

医疗系统往往运行在相对封闭的网络中，跨机构进行数据传输需要解决跨网传输问题。数据的跨网传输，一般通过光闸（网闸）来完成。

光闸，也被成为“安全隔离网闸”或“物理隔离网闸”，用以实现不同安全级别网络之间的安全隔离，并提供适度可控的数据交换硬件系统和软件系统。

安全隔离网闸是实现两个相互业务隔离的网络之间的数据交换，通用的网闸模型设计一般具有三个基本部分：

该部分包括内网接口单元与内网数据缓冲区。接口部分负责与内网的连接，并终止内网用户的网络连接，对数据进行病毒检测、防火墙、入侵防护等安全检测后剥离出“纯数据”，准备进行交换；也完成来自内网对用户身份的确认，确保数据的安全。数据缓冲区是存放并调度剥离后的数据，负责与隔离交换单元的数据交换。

该部分处理的是外网连接，与内网处理单元功能相同。

该部分是网闸隔离控制的摆渡控制，控制交换通道的开启与关闭。控制单元中包含一个数据交换区，就是数据交换中的摆渡船。目前有两种技术用于控制交换通道，分别是摆渡开关和通道控制。①摆渡开关：是电子倒换开关，它允许数据交换区与内外网在任意时刻的不同时连接，形成空间间隔，实现物理隔离。②通道控制：是改变内外网之间的通讯模式，中断了内部和外部网络的直接连接，并使用私密的通讯手段形成内外网的物理隔离。该单元中有一个数据交换区，作为数据交换的中转站。

由于职能和业务的不同，用户的应用系统及其数据交换方式也各不相同：各种汇总系统、数据采集系统需要在网络间传输和交换指定文件；各种业务系统、数据查询系统需要在网络间传输和交换指定数据库记录；各种复杂的应用系统需要传输和交换定制数据。因此目前主流的安全隔离网闸一般具有以下功能模块：文件模块、数据库模块、浏览模块和消息模块。

各医院信息系统构建时，没有遵循统一的标准，系统平台、技术手段、实现方式、数据接口、字段定义等都不相同，如何有效集成各医院的医疗数据信息，建立平台与各医院信息系统的无缝连接，解决异构数据源之间的关联问题，成了构建整个健康医疗大数据平台的核心问题。

异构数据源，指涉及同一类型但在处理方法上存在各种差异的数据。内容上，不仅可以是不同的数据库，如Oracle或SQL Server的数据；而且可以指不同结构的数据，如结构化的数据库数据和半结构化的XML数据。

异构数据集成是以逻辑或者物理的方式把不同来源、格式、特点性质的数据有机整合，从而为用户提供全面的数据共享。每个数据源在集成之前就已经存在，并拥有自己的DBMS，在数据源集成后每个数据源仍然保有自己的应用特性、完整性控制和安全性控制，并且各数据库间数据能实现数据透明访问，彼此共享。

数据集成的难点可以归纳为如下两个主要方面：

整合的数据源通常是独立开发的，数据模型是异构的，这给集成带来相当大的困难。异构性主要表现在：相同语义数据的表达形式，数据语义、数据源的使用环境等。

数据源是异地分布的，依赖网络传输数据，而网络传输存在性能和安全性问题。XML技术的诞生为异构数据集成提供了一种简单、廉价、有效的技术支持，它为在不同节点上运行的应用系统之间进行数据交换奠定了基础，XML的外部特征以及网络技术促进了数据库集成的发展。目前，基于XML数据的集成，其原理是使用中间Java程序存储关系型数据库，然后转换为XML格式文档，再将XML格式转换成最终的数据库。

Java作为一门针对网络的纯面向对象的编程语言，与其他编程语言相比具有稳定、安全、跨异构环境等优势，能开发出跨平台的应用组件和应用程序。XML可扩展标示语言是互联网国际标准组织W3C于1998年2月发布的标示数据语义信息的标准，以其自描述性、可扩展性、开放性的优点已经逐渐成为信息表示和信息交换的标准，可以很好地实现不同平台、不同系统间应用程序的集成和数据的交换。将Java技术与XML相结合，构建异构数据库的集成功能可使平台具有可移植及可扩展性。

数据源的异构性是异构数据集成的核心问题。异构数据集成所表示的形式为：在数据源的独立性不受影响的情况下，将不同的数据合成为新的数据中心，每个数据源都可以通过数据中心建立互相通信，实现对数据的透明访问。建立数据源和数据中心的中间件，消除异构数据之间语法和语义上的异构，实现数据库与XML文档之间的转换。异构性的难点主要体现在语法异构和语义异构上。语法异构通常是指源数据和目的数据之间命名规则及数据类型存在差异，对于数据库命名规则指表名和字段名。语法异构相对简单，只要实现字段到字段、记录到记录的映射，解决名称冲突和数据类型冲突，这种映射相对容易实现。因此，语法异构不需要关心数据的内容和含义，只需要知道数据结构信息并完成源数据结构到目的数据结构之间的映射。

当数据集成需要考虑数据内容和含义时，就进入语义结构的层面。语义结构比语法结构复杂得多，它通常需要破坏字段的原始性，也就是说需要直接处理数据内容。常见的语义结构包括如下一些形式：字段合并、字段数据格式变换、记录间字段转移、字段拆分等。

语法异构和语义异构之间的差异可以追溯到数据源构建时。当数据源的实体关系模型相同但命名规则不同时，只会引起数据源之间的语法异构；当数据源构建实体模型时，如果采用不同的方式划分，不同的实体间关系用不同的字段数据语义表示，必然会造成数据源间的语义异构，给数据集成带来很大麻烦。实际上，数据集成系统的语法异构现象在现实中是普遍存在的。上述提到的语法异构问题属于较为规范的语法异构，可以用特定的映射方法解决。可以使用XMLSchema的特性根据关系模型建立的XMLSchema保存重要信息，如关系表间的关系、数值约束、字段的数据类型等，这实现了关系模式到XML模式的完全转化，并消除了数据源之间的语法语义差异。它不仅可以作为数据转换时的测试依据，还可以作为将来向XML文档中直接增加新信息的依据。

数据集成的过程是将各健康医疗业务系统、物联网设备、公众网站等数据作为数据源，将这些数据源中的异构数据库数据集成起来，按照一定的规则将若干个XML文档集成为一个文档，并将它们上传到平台中央数据库。设计模型如图3-7所示。

当然，要实现集中统一的数据交换，还要考虑许多方面的问题，如数据交换的标准问题、用户管理机制和数据权限管理问题、交换数据传输过程的协议和加密问题、提供给各个应用系统的程序结构问题等。

数据清洗（data cleaning）是对数据进行重新审查和校验的过程。数据清洗从其名称上可以看出就是把“脏”的“洗掉”，目的是发现并纠正数据文件中可识别的错误，包括检查数据一致性、处理缺失值和无效值等，必须按一定规则清洗“脏数据”。数据清洗的任务是对不符合要求的数据进行过滤，将过滤后的结果提交给业务部门，以确认是否过滤掉还是由业务单位修正之后再进行抽取。不符合要求的数据主要是指不完整的数据、错误的数据、重复的数据三大类。数据清洗与问卷审核不同，录入后的数据清洗一般是由计算机完成。根据处理对象的不同，数据清洗可能会在整个数据处理流程的多个环节分别完成。

这类数据主要是缺失一些应该有的信息，如分公司的名称、供应商的名称、客户的区域信息、业务系统中主表与明细表不能匹配等。对于这类数据过滤后根据缺失的内容分别写入不同Excel文件中提交给客户，并要求在规定的时间内补全，完成后才可写入数据仓库。残缺数据的清洗可以在数据采集、数据存储及数据处理的任何一个环节完成。一般来说，残缺数据清洗的阶段越靠前，系统及人力资源的开销越低。

这类数据主要是业务系统不够健全产生的，在接收到输入后没有进行判断就直接写入后台数据库造成的，如字符串数据后面存在回车操作、数值数据输成全角数字字符、日期超出范围、日期格式不正确等。该类数据与残缺数据一样，对应的数据清洗也可以在数据采集、数据存储及数据处理的任何一个环节完成。

对于这类数据，需要将记录重复数据的所有字段导出来，让业务人员确认并处理。重复数据的处理一般不会在数据采集阶段完成。

1.余国培.医疗健康大数据的种类、性质及有关问题[C].中华医院信息网络大会，2014.

2.彭伟军.医疗行为及其法律规制问题的研究[D].兰州：兰州大学，2016.

3.钟九州.高职院校“工学结合”的网络教学信息系统设计与实现[D].成都：电子科技大学，2010.

4.操牡丹.基于知识库的企业异构数据集成[D].北京：北京邮电大学，2010.

5.李承泽.基于ETL的银行数据集成处理研究[D].大连：大连海事大学，2012.

6.黄佳.并行ETL工具可扩展技术的研究和开发[D].北京：北京邮电大学，2012.

7.吕佳.基于Elastic Search的分布式日志搜索系统设计[D].上海：复旦大学，2012.

8.张伟.个性化推荐开放平台的设计与实现[D].成都：电子科技大学，2013.

9.商建国.建立医院数据中心意义及技术方案探讨[C].中华医院信息网络大会暨第五届中美医院信息化论坛，2012.

10.肖辉.医院数据中心架构设计与应用分析[J].中国卫生信息管理杂志，2012.

11.刘博.多网综合集成系统的设计与实现[D].沈阳：东北大学，2013.

12.李贤阳.基于XML的高校校园网数据集成应用研究[J].福建电脑，2014.

13.国网山东省电力公司.一种数据集成方法201410123611.5[P].中文专利全文数据库，2013.

14.程建.基于网络爬虫的网络舆情分析系统的设计与实现[D].沈阳：东北大学，2014.

15.赵庆爱.基于主题网络爬虫的科研信息管理系统的研究与实现[D].合肥：安徽大学，2015.

16.李雪.基于大数据实时web防火墙日志安全审计系统的探究[J].网络安全技术与应用，2014.

17.王电经.基于hadoop的网站用户行为分析系统设计与实现[D].北京：中国科学院大学，2015.

18.王岩松.国家水资源监控能力建设中数据集成方式探讨—以辽宁省为例[J].人民长江，2016.

19.王锋.大数据驱动的高等教育质量监测评估关键技术研究[D].黑龙江高教研究，2017.