基于云计算的海量电子病历文本分析系统研究

基于云计算的海量电子病历文本分析系统研究

ID:76164097

大小:1.22 MB

页数:66页

时间:2024-02-04

上传者:笑似︶ㄣ無奈
基于云计算的海量电子病历文本分析系统研究_第1页
基于云计算的海量电子病历文本分析系统研究_第2页
基于云计算的海量电子病历文本分析系统研究_第3页
基于云计算的海量电子病历文本分析系统研究_第4页
基于云计算的海量电子病历文本分析系统研究_第5页
基于云计算的海量电子病历文本分析系统研究_第6页
基于云计算的海量电子病历文本分析系统研究_第7页
基于云计算的海量电子病历文本分析系统研究_第8页
基于云计算的海量电子病历文本分析系统研究_第9页
基于云计算的海量电子病历文本分析系统研究_第10页
资源描述:

《基于云计算的海量电子病历文本分析系统研究》由会员上传分享,免费在线阅读,更多相关内容在学术论文-天天文库

申请上海交通大学工程硕士学位论文基于云计算的海量电子病历文本分析系统研究学校代码:10248作者姓名:郭建学号:1080379128第一导师:饶若楠第二导师:学科专业:软件工程答辩日期:2011年01月19日上海交通大学软件学院2010年12月 ADissertationSubmittedtoShanghaiJiaoTongUniversityforMasterDegreeofEngineeringRESEARCHOFLARGE-SCALEELECTRONICMEDICALRECORDTEXTANALYSISSYSTEMBASEDONCLOUDCOMPUTINGUniversityCode:10248Author:JianGuoStudentID:1080379128Mentor1:RuonanRaoMentor2:Field:SoftwareEngineeringDateofOralDefense:2011.01.19SchoolofSoftwareShanghaiJiaoTongUniversityDecember,2010 上海交通大学学位论文原创性声明本人郑重声明:所呈交的学位论文,是本人在导师的指导下,独立进行研究工作所取得的成果。除文中已经注明引用的内容外,本论文不包含任何其他个人或集体已经发表或撰写过的作品成果。对本文的研究做出重要贡献的个人和集体,均已在文中以明确方式标明。本人完全意识到本声明的法律结果由本人承担。 基于云计算的海量电子病历文本分析系统研究基于云计算的海量电子病历文本分析系统研究摘要电子病历是医疗卫生信息化的重要研究领域。作为病人在医疗机构历次就诊过程中产生和被记录的完整、详细的临床信息资源,结构化的电子病历中还包含有大量的非结构化文本信息,例如以自然语言记录的临床表现等医疗记录。在医院内部或跨医院的区域范围内电子病历数据是海量的,如何在海量的电子病历数据资源中对其中的非结构化文本信息进行标注和分析,从而建立索引以供查询是一个亟待解决的问题。针对上述问题,本文在深入分析非结构化信息管理架构UIMA(UnstructuredInformationManagementArchitecture)规范和云计算编程模型MapReduce等相关技术基础上,提出了一种在云计算环境下基于UIMA对海量电子病历中的非结构化文本信息进行分析并建立索引的解决方案,设计并实现了相应的原型系统。与传统的文本分析系统相比,本文工作具有以下特点:1)将UIMA框架与云计算编程模型MapReduce相结合,提出了一种在云计算环境下基于UIMA对海量电子病历中的非结构化文本信息进行分析并建立索引的解决方案。该方案既利用了基于MapReduce的云计算环境的并行处理能力,又保持了基于UIMA规范的系统架构的开放性,可根据不同的分析需求开发部署不同的分析引擎。2)基于上述解决方案的原型系统提供对基于跨机构文档共享规范XDS(Cross-EnterpriseDocumentSharing)的电子病历数据中心的接口,并可根据云计算平台Hadoop的输入要求对电子病历中的非结构化文本信息进行预处理;原型系统对这些非结构化文本信息的分析和索引建立实现并行处理。3)开发实现了一个基于UIMA规范的中文分析引擎。该引擎以开源的中文分词软件IKAnalyzer为基础,结合外部的受控医学词汇CMV(ControlledMedicalVocabulary)服务,可标注分析结构化电子病历中用自然语言记录的非结构化中文文本信息。第I页 基于云计算的海量电子病历文本分析系统研究实验数据和原型系统的应用情况表明,该系统是可行及有效的。关键词电子病历,非结构化信息,云计算,UIMA,Hadoop第II页 基于云计算的海量电子病历文本分析系统研究RESEARCHONLARGE-SCALEELECTRONICMEDICALRECORDTEXTANALYSISSYSTEMBASEDONCLOUDCOMPUTINGABSTRACTElectronicMedicalRecord(EMR)isanimportantresearchfieldofhealthandmedicalinformatization.Ascompleteanddetailedclinicalinformationresourcesofbeingproducedandrecordedduringpatients’treatment,structuredelectronicmedicalrecordalsocontainsalargenumberofunstructuredtextinformation,suchasmedicalrecordsofclinicalmanifestationsrecordedbynaturallanguage.Electronicmedicalrecorddataislargeinahospitalorcrosshospitalsarea,howtoannotateandanalyzeunstructuredtextinformationwithinlarge-scaleelectronicmedicalrecorddataandbuildindexforqueryisanurgentproblemtobesolved.Fortheproblemabove,thispaperpresentsasolutionofanalyzingtheunstructuredtextinformationofalargevolumeofelectronicmedicalrecordsandbuildingindexbasedonUIMAincloudcomputingenvironment,designsandimplementsaprototypesystemafterdeeplyresearchingunstructuredinformationmanagementarchitectureUIMA(UnstructuredInformationManagementArchitecture)specificationandcloudcomputingprogrammingmodelMapReduceandotherkeytechnologies.Contrastedwiththetraditionaltextanalysissystems,thispaperhasthefollowingcharacteristics:1)CombineUIMAframeworkwithcloudcomputingprogrammingmodelMapReduce,asolutionofanalyzingtheunstructuredtextinformationofalargevolumeofelectronicmedicalrecordsandbuildingindexbasedon第III页 基于云计算的海量电子病历文本分析系统研究UIMAincloudcomputingenvironmentisproposed.ThissolutionnotonlytakeadvantageofparallelprocessingcapacityofcloudcomputingenvironmentbasedonMapReduce,butalsokeeptheopennessofUIMAframeworkwhichcandevelopanddeploydifferentAnalysisEngineaccordingtodifferentrequirement.2)TheprototypesystembasedonthesolutionabovesuppliestheinterfaceofelectronicmedicalrecordrepositorybasedonXDS(Cross-EnterpriseDocumentSharing)andpreprocessestheunstructuredtextinformationofelectronicmedicalrecordsaccordingtotheinputrequirementsofcloudcomputingplatformHadoop.Theprototypesystemcananalyzetheunstructuredtextinformationandbuildindexparallelly.3)RealizingaChineseAnalysisEnginebasedonUIMAspecification.ThisAnalysisEngineisbasedonopensourceChinesewordsegmentationsoftwareIKAnalyzerusingexternalCMV(ControlledMedicalVocabulary)andcanannotateunstructuredChinesetextinformationrecordedbynaturallanguageofstructuredelectronicrecords.Experimentaldataandtheeffectoftheprototypesystemshowthatthesystemisfeasibleandeffective.KeywordsElectronicMedicalRecord,UnstructuredInformation,CloudComputing,UIMA,Hadoop第IV页 基于云计算的海量电子病历文本分析系统研究目录摘要.............................................................................................................................IABSTRACT................................................................................................................III第一章绪论................................................................................................................11.1课题研究背景及意义...................................................................................................11.2国内外研究现状...........................................................................................................31.2.1非结构化信息管理(UIM).............................................................................31.2.2云计算...............................................................................................................31.3研究目标及研究内容...................................................................................................41.4本文章节安排...............................................................................................................51.5本章小结.......................................................................................................................6第二章相关技术研究................................................................................................72.1文本分析.......................................................................................................................72.1.1中文分词...........................................................................................................72.1.2中文分词软件...................................................................................................92.2非结构化信息管理架构.............................................................................................102.2.1UIMA概述.........................................................................................................102.2.2UIMA类型系统.................................................................................................122.3云计算.........................................................................................................................132.3.1云计算概述.....................................................................................................132.3.2开源云计算平台.............................................................................................152.4MapReduce...................................................................................................................162.4.1HadoopMapReduce.........................................................................................172.5HDFS.............................................................................................................................182.5.1Namenode和Datanode.....................................................................................182.5.2文件系统的名字空间(namespace).............................................................192.5.3数据复制.........................................................................................................202.5.4文件系统元数据的持久化.............................................................................202.6本章小结.....................................................................................................................21第三章云环境下基于UIMA的电子病历文本分析方法..........................................223.1问题的提出.................................................................................................................223.2基于UIMA的文本分析方法.........................................................................................233.2.1UIMA关键组件.................................................................................................233.2.2基于UIMA的文本分析过程.............................................................................243.3基于云计算的海量文本分析方法.............................................................................263.3.1云计算平台的选择.........................................................................................263.3.2对小文件的处理.............................................................................................263.4基于云计算和UIMA的电子病历文本分析方法.........................................................303.4.1基本思路.........................................................................................................30第V页 基于云计算的海量电子病历文本分析系统研究3.4.2解决方案.........................................................................................................313.5本章小结.....................................................................................................................32第四章系统设计与实现..........................................................................................334.1系统架构.....................................................................................................................334.2文本分析模块.............................................................................................................344.2.1XDS电子病历数据的预处理...........................................................................344.2.2UIMA分析引擎构建.........................................................................................354.2.3文本处理流程.................................................................................................384.2.4Map和Reduce的实现.......................................................................................394.3索引建立.....................................................................................................................424.3.1倒排索引.........................................................................................................424.3.2索引库设计.....................................................................................................434.4配置管理模块.............................................................................................................444.4.1分析引擎配置.................................................................................................444.4.2医学词典配置.................................................................................................444.5本章小结.....................................................................................................................45第五章系统部署及实验结果..................................................................................465.1实现环境.....................................................................................................................465.2部署及应用案例.........................................................................................................465.2.1Hadoop的配置选项.........................................................................................465.2.2UIMA在Hadoop集群配置.................................................................................475.2.3应用案例.........................................................................................................485.3性能测试及结果分析.................................................................................................485.3.1测试环境.........................................................................................................485.3.2测试结果及分析.............................................................................................485.4本章小结.....................................................................................................................49第六章结语..............................................................................................................506.1工作总结.....................................................................................................................506.2工作展望.....................................................................................................................51参考文献......................................................................................................................52致谢..............................................................................................................................55攻读学位期间发表的学术论文目录..........................................................................56第VI页 基于云计算的海量电子病历文本分析系统研究第一章绪论1.1课题研究背景及意义计算机的普及和广泛应用以及信息数字化的迅猛发展促进了我国医疗卫生信息化的发展。医疗卫生信息化是指人们运用现代信息技术,收集、开发并利用医疗卫生信息资源,实现卫生信息资源的高度共享,是对传统的卫生管理规程和[49]工作流程进行信息化改造的过程。医疗卫生信息化的核心是病人信息的共享,包括医院各个科室之间、医院之间、医院与社区、医疗保险、卫生行政部门等的信息共享。病历是病人在医院诊断治疗全过程的原始记录,它包含有首页、病程记录、检查检验结果、医嘱、手术记录、护理记录等等。电子病历不仅指静态病历信息,还包括提供的相关服务。电子病历(EMR,ElectronicMedicalRecord)也叫计算机化的病案系统或称基于计算机的病人记录(CPR,Computer-BasedPatientRecord)。它是用电子设备(计算机、健康卡等)保存、管理、传输和重现的数字化的病人的医疗记录,取代手写纸张病历。它的内容包括纸张病历的所有信息。美国国立医学研究所将定义为:EMR是基于一个特定系统的电子化病人记录,该系统提供用户访问完整准确的数据、警示、提示和临床决策支持系统的能力[50]。电子病历侧重于病历信息的收集,整理和交换,其核心功能是病历数据的输入,分析和整理,并挖掘其中有用的信息。电子病历并不是传统纸质病历的电子化,主要内容由病历概要、门(急)诊病历记录、住院病历记录、健康体检记录、转诊记录、法定医学证明及报告、医疗机构信息等7个业务域的基本医疗服务活动记录构成。电子病历具有很广阔的前景,如辅助医生诊疗、病历数据的共享、远程诊疗和大规模医疗数据分析等。电子病历的组成信息包括基础信息和诊疗信息。诊疗信息是来自医务人员的信息,主要体现在体格检查、病情分析和诊断方面;还有来自实验室化验、检查的信息,主要体现在各种医疗仪器设备对患者进行检测表达出来的结果。治疗信息是医师根据患者诊断和病情所实施的治疗信息,主要包括两大类:医嘱和治疗记录。医嘱是经主治医师为患者下达的指令,分为长期医嘱和短期医嘱,其内容除了包括患者一般信息、时间信息、执行人员信息外,主要是具体诊疗内容。治疗记录是医生、护士为患者治疗前后所作的记录,通常包括治疗时间、地点、第1页 基于云计算的海量电子病历文本分析系统研究方式、过程、效果、病人反应等信息,例如麻醉记录、手术记录。电子病历的结构化是计算机可理解的电子病历的基础。但在结构化的电子病历中存在大量的非结构化信息,例如医嘱和治疗记录。如果医生在临床表现等治疗记录时尽量用自然语言描述可以不需要改变他们习惯的记录方式,从而可以自由地表达各种信息。但是对于计算机来说,理解这些记录是很困难的。例如一条某病人系统性红白狼疮(Systemiclupuserythematosus,SLE)治疗记录中的临床表现记录如下:2009年2月底出现发热,体温39度,双手出现雷诺氏现象,外院查WBC1.9,Hb89,PLT131,CPK439,CRP20.3,ESR66,于09年3月份本院就诊查IFANA+,SM+,RNP+,dsDNA>100,诊断SLE,病程中无明显皮疹,关节痛,无口溃、脱发等现象。信息共享是医疗卫生信息化的目的之一。在医院内部或跨医院区域范围内的电子病历数据中心,共享的电子病历数据将是海量的。假设医生想要检索具有“关节痛”的临床表现的患者的电子病历,就需要对电子病历中的这类非结构化信息进行标注分析从而建立索引。非结构化信息(UnstructuredInformation)是指其内在含义并未通过其格式[1][2]显现而是隐含在具体内容中的信息形式。媒体和研究报告说有85%以上的信息都是非结构化的,如电子本文、邮件、图片、音频及视频等。伴随着信息技术的广泛发展,企业中积累的非结构化数据资源迅速增长。所谓非结构化信息分析(UnstructuredInformationAnalysis,UIA)是指借助计算机将非结构化信息进行处理,从而转化为结构化信息。非结构化信息分析的关键是分析引擎,针对不同的具体问题,需要研发许多不同的分析引擎。尽管目前学术界和企业界已经研发了许多相关的工具,但是这些工具大都只能解决某些小的局部问题,对非结构化信息进行深度分析需要综合多种工具和方法。针对非结构化信息分析具有信息海量、信息源多种、分析技术多种多样等特点,结构化信息标准促进组织OASIS(OrganizationfortheAdvancementofStructuredInformationStandards)在2009年制订了通用的非结构化信息管理架构UIMA(UnstructuredInformationManagementArchitecture)V1.0规范。UIMA规范定义了一种开放的构件化软件架构以支持不同领域的非结构化信息处理,被广泛应用于自然语言处理等诸多领域。另一方面,针对海量数据处理的云计算(CloudComputing)技术研究及应用日益深入和广泛。云计算是网格计算(GridComputing)、分布式计算(DistributedComputing)、并行计算(ParallelComputing)、效用计算(UtilityComputing)、第2页 基于云计算的海量电子病历文本分析系统研究网络存储(NetworkStorageTechnologies)、虚拟化(Virtualization)、负载均衡(LoadBalance)等传统计算机技术和网络技术发展融合的产物。它旨在通过网络把多个成本相对较低的计算实体整合成一个具有强大计算能力的资源池,并借助SaaS、PaaS、IaaS、MSP等先进的商业模式提供给终端用户使用。本文工作是以实验室承担的上海科委重点科技攻关项目“面向规模互联的医院内部数据一体化整合建模技术研究(课题编号:08DZ1500507)”为背景,针对医院内部或跨医院区域范围内的电子病历数据中心的海量电子病历中非结构化信息检索问题,结合UIMA和云计算技术,提出一种在云计算环境下基于UIMA的海量电子病历文本分析方法并实现原型系统。1.2国内外研究现状1.2.1非结构化信息管理(UIM)[23]非结构化信息管理架构(UnstructuredInformationManagementArchitecture,UIMA)是一个为复用、整合非结构化信息处理管理组件而制订的标准规范,被广泛应用于自然语言处理等诸多领域。国外许多研究机构已经研发了许多基于UIMA的非结构化信息分析组件,如德国Darmstadt大学UKP[25][26](UbiquitousKnowledgeProcessing)实验室的DKPro,为快速开发复杂自[27]然语言处理应用提供灵活易用、可扩展的工具包;JULIE实验室研发的JCORE[28][29]是为开发复杂的文本分析器所研发的基本组件库。Picasso系统在UIMA的基础上,实现了记录、组织、分享和检索企业中与员工的活动相关非结构化信息的功能,提供包括关键字搜索、语义搜索、实体搜索、事实搜索等搜索功能。文[13]献提出一种基于本体的从文本中获取形式化知识的框架,研究了从文本中获取知识所面临的挑战,主要包括准确率、可扩展性等问题,并介绍了若干问题的解决思路。虽然UIMA对分布式计算具有较好的支持,但目前结合大规模并行计算的[14]应用研究不多。文献提出一种基于网格计算和UIMA的海量文本分析的解决[54]方案,使用Condor来管理UIMA文本分析任务的分发。文献介绍了一种结合UIMA和Hadoop对生物医学英文文本进行分析的工具。基于UIMA对中文电子病历进行分析处理的应用研究尚未见报道。1.2.2云计算[31]云计算(CloudComputing)是分布式处理(DistributedComputing)、并第3页 基于云计算的海量电子病历文本分析系统研究行处理(ParallelComputing)和网格计算(GridComputing)的发展,或者说是这些计算机科学概念的商业实现。IBM于2007年8月高调推出“蓝云(BlueCloud)”计划。同年10月,Google在全球宣布了自己云计划,同时与IBM公司合作,把全球多所大学纳入“云计算”计划当中。亚马逊于2007年开放了名叫“弹性计算机云”(ElasticComputeCloud,EC2)的服务,以便于让小软件公司可以按需要购买亚马逊(Amazon)数据中心的处理能力,这样就不需要这些小公司从硬件开始搭建系统。如今,Linux,Windows,JBoss,Eclipse等常用操作系统和软件都已经在EC2平台上得到了支持,其他应用软件也在不断地加入。截至2008年底,Amazon的云计算相关业务收入已达到1亿美元。2007年11月,Yahoo建立一个小规模的云,开放给了卡内基梅隆大学的研究人员。Microsoft于2008年10月推出了WindowsAzure操作系统,Azure(“蓝天”)的底层是微软全球基础服务系统,由遍布全球的第四代数据中心构成。2010年12月EMC和思科联合推出集成的云计算[36][38]交付平台,目前EMC一直致力于虚拟化解决方案,并提供云计算战略服务,EMC、VMware和Cisco云计算战略服务使用户的数据中心从传统的计算模型[37]转型为私有云服务提供商。Intel也一直致力于云计算的相关工作,目前正积[39]极推动实施开放式数据中心计划,以打造更加安全、高效且简化的云计算数据中心,为用户带来高度的IT灵活性和丰富的选择,帮助他们提高工作效率,同时显著降低成本。云计算在国内的起步稍晚,大概是从2008年开始的,但发展迅猛,如今中国IT界的各大企业基本都涉及该行业。例如,阿里巴巴集团于2009年9月成立阿里巴巴云计算公司,目标是打造以数据为中心的先进云计算服务平台,做自己[30]的云计算平台“飞天”。盛大集团也在规划成立专门的云计算部门。随着国内外云计算应用及研究的不断推进,其研究的技术要点也日益丰富,主要包括:虚拟化技术,云计算存储结构研究,云数据管理的研究,云编程模式的演示,云网络的研究以及云安全的研究。1.3研究目标及研究内容本文的研究目标是针对医院内部或跨医院区域范围内的电子病历数据中心的海量电子病历中非结构化信息检索问题,结合UIMA和云计算技术,提出一种在云计算环境下基于UIMA的海量电子病历文本分析方法,并构建原型系统对该方法进行验证。围绕上述目标,本文的研究内容主要包括:第4页 基于云计算的海量电子病历文本分析系统研究(1)对医院内部或跨医院区域范围内的海量电子病历中非结构化信息检索问题进行分析。(2)剖析UIMA框架并研究其关键组件,包括CollectionReader、分析引擎,CAS消费者等。(3)研究云计算的关键技术,包括数据存储技术,数据管理技术,编程模型,研究主流的开源云计算平台,包括Hadoop、Eucalyptus等。(4)提出一种在云计算环境下基于UIMA对海量电子病历中的非结构化文本信息进行分析并建立索引的解决方法。(5)结合外部医学词典,开发遵循UIMA规范并可对电子病历非结构化信息进行标注的分析引擎。(6)基于上述方法设计并实现相应的原型系统,以验证其有效性和可行性。1.4本文章节安排本文章节内容安排如下。第一章,绪论。介绍本课题的背景、研究意义、研究内容。第二章,相关技术研究。先是对非结构化信息框架进行解析,接着介绍云计算相关技术,并介绍了2个开源云计算平台Eucalyptus和Hadoop,接着详细介绍了Hadoop的架构及其关键技术MapReduce、HDFS,作业调度等。第三章,云环境下基于UIMA的海量电子病历文本分析的方法。先介绍中文分词技术,接着介绍一般的基于UIMA的文本分析方法,包括UIMA关键组件和UIMA的文本分析过程。然后介绍了Hadoop中小文件影响集群效率的问题,然后结合云计算和UIMA给出了海量电子病历文本分析的解决方案。第四章,系统设计与实现。首先分析系统的需求分析。接着介绍原型系统的总体设计,包括原型系统的架构,具体功能描述等。然后详解预处理模块和文本处理模块,文本处理模块包括UIMA分析引擎的构建、医嘱信息全文索引的建立以及Map、Reduce的实现。第五章,系统部署和实验结果。介绍软硬件条件、相关配置以及原型系统的启动,接着给出实验数据,说明原型系统的效果,包括加速比和效率。第六章,结语。对本文的工作作出总结及展望。第5页 基于云计算的海量电子病历文本分析系统研究1.5本章小结本章介绍了对医院内部或跨医院区域范围内的海量电子病历非结构化文本信息进行标注分析从而建立索引的意义;总结了基于UIMA的非结构化信息分析和云计算的国内外研究现状;阐明了本文的研究目标和研究内容;最后给出了本文的章节安排。第6页 基于云计算的海量电子病历文本分析系统研究第二章相关技术研究2.1文本分析[42]文本(text)是指经由具体化的过程所呈现的内容,这些内容可以来自于文件、图像、声音等。[48]文本分析是指对文本的表示及其特征项的选取;文本分析是文本挖掘、信息检索的一个基本问题,它把从文本中抽取出的特征词进行量化来表示文本信息。[44]信息检索(InformationRetrieval,IR)是查找文档中的信息、元数据,也查找关系数据库和万维网。[45]信息提取(InformationExtraction,IE)是指从一段文本中抽取指定的一类信息(例如事件、事实)、并将其(形成结构化的数据)填入一个数据库中供用户查询使用的过程。Web中99%的可分析信息都是以文本形式存在的,Web网页信息总量超过100亿,每天新增网页数千万条。机构内,90%的信息以文本形式存在,如数字化图书馆、数字化档案馆、数字化办公等。2.1.1中文分词在对英文文档进行分析时,由于单词之间是以空格作为自然分界符的,可以较容易的进行处理,如使用正则表达式分析。而对于中文文档而言,只有字、句和段有明显的分界符,词没有形式上的分界符,所以中文文档的分析要比英文文档分析复杂的多。[47]中文分词(ChineseWordSegmentation)指的是将一个汉字序列切分成一个一个单独的词。分词就是将连续的字序列按照一定的规范重新组合成词序列的过程。中文分词技术属于自然语言处理的范畴,同时也是文本挖掘的基础,因此是至关重要的,其处理过程就是分词算法。中文分词的难点主要有分词歧义和未登录词识别:(1)分词歧义歧义是指同样的一句话,可能有两种或者更多的切分方法。主要的歧义包括第7页 基于云计算的海量电子病历文本分析系统研究交集型歧义、组合型歧义以及混合型歧义。如果“AB”是词、“ABC”也是词,那么产生的切分歧义称为组合型歧义。假设“ABC”是一个词串,如果“AB”、“BC”都是词,那么计算机在切分时可以把“ABC”切分为“AB/C”,也可以切分为“A/BC”,这种切分歧义称为交集型歧义。混和型歧义是包含交集型歧义和组合型歧义的切分歧义。目前解决这些问题主要通过字典和统计学的方法。例如“该病人是红白狼疮患者”就是交集型歧义的例子,正确的切分结果应该为“该病人是红白狼疮患者”,可是如果没有医疗词库的支持,切分的结果将是“该病人是红白狼疮患者”。还有一种歧义是真歧义,即一句话由人去判断也不知道如何切分,这种必须要有上下文的语义才能正确切分。例如,“乒乓球拍卖完了”既可以切分成“乒乓球拍卖完了”,也可以切分成“乒乓球拍卖完了”。(2)未登录词识别未登录词即是那些在分词词典中没有收录,但又确实能称为词的那些词。未登录词识别包括数字识别、命名实体识别以及形式词、离合词等。未登录词识别的方法有基于规则的和概率统计的。未登录词中最典型的是人名,可能会于常规词产生交叉歧义。例如,“张三疯上课迟到了”这句话,我们可以很容易的理解“张三疯”是一个人名的词组,但是分词软件却容易对其识别,“张三疯了”句子中,“张三疯”就不再是一个词组。未登录词识别中除了人名以外,还有机构名、地名、产品名、商标名、简称、省略语等,这些词对于自动分词都是很难处理的问题,而这些词却又是人们经常使用的词,因此对于搜索引擎来说,分词系统中的未登录词识别十分重要。目前未登录词识别准确率已成为评价一个分词系统好坏的重要标志之一。常用的分词算法主要有最大匹配法、最大概率分词方法和最短路径分词方法:(1)最大匹配法最大匹配法是一种基于字符串匹配的分词方法。最大匹配法又分为正向最大匹配方法和逆向最大匹配方法。通常,逆向匹配的切分精度要略高于正向匹配,遇到的歧义现象也较少。(2)最大概率分词方法最大概率分词方法的基本思想是一个待分析的汉字串可能有多种分词结果,将其中概率最大的字串作为分词结果。其中分词结果的概率定义如下:第8页 基于云计算的海量电子病历文本分析系统研究P(S|W)×P(W)P(W|S)=≈P(W)P(S)P(W)=P(w1,w2,...,wi)≈P(w1)×P(w2)×...×P(wi)wi在语料库中的出现次数nP(wi)=预料库中的总次数N(3)最短路径分词方法最短路径分词方法的思想是在词图上选择一条词数最少的路径。它要比单向的最大匹配算法效果好,但是仍然不能解决大部分歧义。2.1.2中文分词软件当前中文分词器已经有很多,常见的基于lucene的中文分词器有庖丁解牛(PaodingAnalysis)、imdict-chinese-analyzer、mmseg4j及IKAnalyzer。[43]Paoding中文分词具有极高效率和高扩展性。引入隐喻,采用完全的面向对象设计,构思先进。在PIII1G内存个人机器上,1秒可准确分词100万汉字。采用基于不限制个数的词典文件对文章进行有效切分,能够对词汇分类定义。能够对未知的词汇进行合理解析。[7]imdict-chinese-analyzer是imdict智能词典的智能中文分词模块,算法基于隐马尔科夫模型(HiddenMarkovModel,HMM),是中国科学院计算技术研究所的ictclas中文分词程序的重新实现(基于Java),可以直接为lucene搜索引擎提供简体中文分词支持。[8]mmseg4j用Chih-HaoTsai的MMSeg算法实现的中文分词器,并实现lucene的analyzer和solr的TokenizerFactory以方便在Lucene和Solr中使用。[9]IKAnalyzer是一个开源的,基于java语言开发的轻量级的中文分词工具包。采用了特有的“正向迭代最细粒度切分算法“,具有60万字/秒的高速处理能力。采用了多子处理器分析模式,支持:英文字母(IP地址、Email、URL)、数字(日期,常用中文数量词,罗马数字,科学计数法),中文词汇(姓名、地名处理)等分词处理。优化的词典存储,更小的内存占用。支持用户词典扩展定义。IKAnalyzer3.x的架构如下图2-1所示。IKAnalyzer几个最重要的API如下:IKAnalyzer:IK分词器的主类,也是IK分词器的LuceneAnalyzer类实现。IKQueryParser:它是针对Lucene全文检索优化的查询分析器。IKSimilarity:IKAnalyzer的相似度评估器。该类重载了DefaultSimilarity的coord()方法,提高词元命中个数在相似度比较中的权重影响,当有多个词元第9页 基于云计算的海量电子病历文本分析系统研究得到匹配时,文档的相似度将提高。IKSegmentation:它是IK分词器的核心类,是真正意义上的分析器实现。Lexeme:它是IK分词器的语义单元对象,相当于Lucene中的Token词元对象。[9]图2-1IKAnalyzer3.x架构Fig.2-1ThearchitectureofIKAnalyzer3.x2.2非结构化信息管理架构2.2.1UIMA概述UIMA是非结构化信息管理架构(UnstructuredInformationManagementArchitecture,UIMA)在字处理文档、电子邮件、视频和其他非结构化信息中搜索特定的文本甚至概念,从而发现、组织和传送有用的知识给客户。在分析非结构化的信息的过程中,应用的算法有统计的方法、基于规则的自然语言处理(NLP)、信息修复(IR)、机器学习(MachineLearning)和本体论(Ontologies)等。IBM的UIMA就是一种Framework,该框架便于开发者实现、描述、组合、部署UIMA的组件和应用。UIMA既是一个架构,也是一个软件框架(Framework),最初由IBM研发,2006年经移交成为Apache的一个开源IncubatorProject,即实现了UIMASpecification5的ApacheUIMA。UIMA使得UIM应用中的关键技术能够解构为第10页 基于云计算的海量电子病历文本分析系统研究UIMA的组件(component),组件实现了框架定义的接口,并通过XML描述文件(descriptorfiles)提供其自描述的元数据信息。UIMA框架通过这些描述文件对组件和组件之间的数据流进行管理。UIMA提供了将组件包装成WebService的扩展能力,并藉此复制处理流水线到集群中子节点的方式对大规模数据进行并行处理。基于UIM应用程序可以理解为由两个阶段组成:分析和提交。UIMA的架构如图2-2所示。在分析阶段,文档集(CollectionsofDocuments)将被读取并被分析,分析的结果以一定得格式存储起来,并将作为提交阶段的输入。在提交阶段,上述分析结果,可能还有原始文档或者其他的结构化的信息,通过合适的接口和方法提供给最终用户。以文本分析为例,应用程序的分析阶段可能包括针对输入文档的分词、语义类检测(semanticclassdetection)。通过查阅结构化的数据源,比如目录和本体,应用程序可能发现并标识实体类(classesofentities),例如组织、人名、处所和事件等。除此之外,应用程序可能还能标注关系类(classesofrelationships),例如located_in,attends_event,is_the_CEO_of等。分析阶段的这些结果可以作为一个搜索索引,其中包含了标记以及检索到的实体和关系。在提交阶段,应用程序可以提供查询接口,允许用户通过语义搜索引擎搜索包含了上述标记、实体、关系的布尔组合的文档。[1]图2-2UIMA架构[1]Fig.2-2ArchitectureofUIMAUIMA致力于提供基础概念和底层组件,用于支持非结构化信息分析能力第11页 基于云计算的海量电子病历文本分析系统研究的发现、发展、组成和部署,以及它们和结构化信息数据源的集成。信息提交的操作是开放的,也是非常专业的,与领域知识、研究目标、应用场景都密切相关。因此,虽然提交阶段是UIM应用程序非常重要的方面,但它不是直接由架构给出的。非结构化信息分析(UIA)可分为两个级别:文档级别分析(Document-level,[1]D-L)和集合级别分析(Collection-level,C-L)。前者以单个文档作为输入,进行断词、句法解析、命名实体检测(named-entitydetection)、分类、总结、翻译。与分析结果相关联的元数据信息一般也会加入到分析结果中。相对地,后者则对整个文档集进行处理,并将文档集中每个文档分配给一个D-L分析任务,每个子任务之间可以并行进行。UIMA使用了多种技术分析非结构化信息,包括了统计、基于规则的自然语言处理(NLP),信息检索,机器学习,本体论,自动推理。UIM的应用使得构建结构化信息源解决非结构化信息的语义分析。比如,一个化学名称的数据库可以帮助解决对于医学摘要的分析。一个恐怖组织及其地点的数据库能够帮助分析涉及恐怖活动的文档。一个UIM的应用一般是产生从非结构化信息里继承并呈现其内容的结构化信息资源,这些资源可以很容易被终端用户通过一系列恰当的应用来访问。一个简单的例子就是检索目录和查询处理,这样使得文档能够快速地访问到,并且根据它们对于用户定制的关键词的相关程度来排位。2.2.2UIMA类型系统为了支持数据建模和数据交换,UIMA要求CAS作用于一个用户定义的域空间,即所谓的类型系统(TypeSystem,TS)。类型系统定义了在标注器中可以使用的数据类型。类型系统定义了两种实体:types和features。Types定义了在CAS中可以使用的objects。Features定义了Type中的slots。在Java中,types相当于类,features相当于类的成员。这些Features的值可以是原始数据类型,也可以是引用。我们称类型系统定义的类型的实例为featurestructures。每个CAS的类型都定义一个超类,本身是那个超类的子类。一个类型的features是它所有超类的features的集合。在CAS中有一个内建的类型叫uima.cas.TOP,这是继承树的根节点,它没有定义任何features。CAS另外有一个内建的类型是uima.tcas.Annotation,它继承uima.cas.AnnotationBase,相应地同时继承了uima.cas.TOP,它有两个features:begin和end。UIMA架构定义的基础类型系统(BaseTypeSystem)为用户的扩展和定制类型系统需求提供支持,开发人员通过对基础类型系统进行扩展来定义适合应用第12页 基于云计算的海量电子病历文本分析系统研究需求的类型系统。BaseTypeSystem中定义的原始数据类型有Boolean,Byte,Short,Integer,Long,Float,Double,String。BaseTypeSystem还定义了Annotation和Sofa,定义了标注的标准形式。UIMA基础类型系统关系如图2-3所示。图2-3UIMA基础类型系统Fig.2-3BaseTypeSystemofUIMA通常,标注指向领域本体中的一些元素,有些标注指向的是相同的元素。BaseTypeSystem就定义了标准的方法来标示这些信息:利用Annotation和Referent类型,occurrences和occurrenceOf属性。Annotation的occurrenceOf指向Referent对象,所有相同概念的标注只能指向同一个Referent。相反地,Referent的occurrences指向所有的标注对象。2.3云计算2.3.1云计算概述云计算是2007年底正式被提出的一个新概念,几乎所有的IT行业巨头都将[6]云计算作为未来发展的主要战略之一。云计算(Cloudcomputing)是一种新兴的共享基础架构的方法,可以将巨大的系统池连接在一起以提供各种IT服务使用。很多因素推动了对这类服务的需求,其中包括连接设备、实时数据流、SOA的采用以及搜索、开放协作、社会网络和移动商务等这样的Web2.0应用的急剧增长。狭义云计算是指IT基础设施的交付和使用模式,通过网络以按需、易扩展的方式获得所需的资源(硬件、平台、软件)。提供资源的网络被称为“云”。“云”中的资源在用户看来是可以被无限扩展的,并且可以随时随地获取,按需第13页 基于云计算的海量电子病历文本分析系统研究使用,随时扩展,按使用付费。这种特性被称为像使用水和电一样使用IT基础设施。广义云计算是指服务的交付和使用模式,指通过网络按需、易扩展的方式获得所需要的服务。这种服务可以是IT和软件、互联网相关的服务,也可以是任意其他的服务。云计算经常与并行计算(ParallelComputing)、分布式计算(Distributed[21]Computing)和网格计算(GridComputing)相混淆。云计算是虚拟化(Virtualization)、效用计算(UtilityComputing)、IaaS(基础设施即服务)、PaaS(平台即服务)、SaaS(软件即服务)等概念混合演进并跃升的结果。云计算有如下特点:(1)超大规模。“云”具有相当的规模,Google云计算已经拥有100多万台服务器,Amazon、IBM、微软、Yahoo等的“云”均拥有几十万台服务器。企业私有云一般拥有数百上千台服务器。“云”能赋予用户前所未有的计算能力。(2)虚拟化。云计算支持用户在任意位置、使用各种终端获取应用服务。所请求的资源来自“云”,而不是固定的有形的实体。应用在“云”中某处运行,但实际上用户无需了解、也不用担心应用运行的具体位置。只需要一台笔记本或者一个手机,就可以通过网络服务来实现我们需要的一切,甚至包括超级计算这样的任务。(3)高可靠性。“云”使用了数据多副本容错、计算节点同构可互换等措施来保障服务的高可靠性,使用云计算比使用本地计算机可靠。(4)通用性。云计算不针对特定的应用,在“云”的支撑下可以构造出千变万化的应用,同一个“云”可以同时支撑不同的应用运行。(5)高可扩展性。“云”的规模可以动态伸缩,满足应用和用户规模增长的需要。(6)按需服务。“云”是一个庞大的资源池,你按需购买;云可以象自来水,电,煤气那样计费。(7)极其廉价。由于“云”的特殊容错措施可以采用极其廉价的节点来构成云,“云”的自动化集中式管理使大量企业无需负担日益高昂的数据中心管理成本,“云”的通用性使资源的利用率较之传统系统大幅提升,因此用户可以充分享受“云”的低成本优势,经常只要花费几百美元、几天时间就能完成以前需要数万美元、数月时间才能完成的任务。第14页 基于云计算的海量电子病历文本分析系统研究2.3.2开源云计算平台云计算(CloudComputing)是一种新近提出的计算模式,是分布式计算(DistributedComputing)、并行计算(ParallelComputing)和网格计算(GridComputing)的发展。目前,Amazon,微软,Google,IBM,Intel等公司纷纷提[16]出了“云计划”。云计算的平台也是多样的,如亚马逊的EC2、IBM的蓝云、微软的Azure;还有很多开源云计算平台,如Hadoop、Eucalyptus。这里只介绍开源云计算平台Eucalyptus和Hadoop。Eucalyptus项目全称是ElasticUtilityComputingArchitectureforLinkingYourProgramsToUsefulSystems,由加利福尼亚大学(SantaBarbara)建立的开源项目,是主要实现云计算环境的弹性需求的软件,通过其在集群或者服务器组上的部署,并且使用常见的Linux工具和基本的基于web的服务。使用FreeBSDLicense,意味着可以直接使用在商业软件应用中,当前支持的商业服务只是亚马逊的EC2,今后会增加多种客户端接口。该系统使用和维护十分方便,使用SOAP安全的内部通信,且把可伸缩性作为主要的设计目标,具有简单易用,扩展方便的特点。这个软件层的工具可以用来通过配置服务器集群来实现私有云,并且其接口也是与公有云相兼容,可以满足私有云与公有云混合构建扩展的云计算环境。Hadoop是Apache开源组织的一个分布式计算开源框架,在很多大型网站上都已经得到了应用,如Amazon,Facebook,Yahoo!,IBM等等。Hadoop框架中最核心设计是MapReduce和HDFS(HadoopDistributedFileSystem)。MapReduce[10]的思想是由Google的一篇论文所提及而被广为流传的,简单的说MapReduce就是任务的分解与结果的汇总。HDFS是Hadoop分布式文件系统的缩写,为分[11]布式计算存储提供了底层支持。Hadoop由若干个成员组成,主要包括:HDFS、MapReduce、Hive、HBase、[11]Pig和ZooKeeper,其中HDFS是Google的GFS(GoogleFileSystem)开源实现,而ZooKeeper是Google的Chubby开源版本,而HBase是Google的BigTable[7]开源版本。Hadoop的架构如图2-4所示。第15页 基于云计算的海量电子病历文本分析系统研究图2-4Hadoop架构Fig.2-4ArchitectureofHadoop2.4MapReduce[10]MapReduce是一种能在大型计算机集群上并发地处理海量数据的框架模型。它是Google针对大规模分布式文件系统GFS和海量网页数据库系统BigTable提出来的,有效的解决了海量数据的处理问题。同时,它也是一种简化的分布式编程模型,可以将程序自动分布到一个超大规模的集群上并发执行,解决输入数据的分布细节,跨越及其集群的程序执行调度,处理机器的失效并管理机器之间的通讯请求。简单的说,MapReduce模型有一个Map函数和一个Reduce函数组成,map函数处理一个key/value键值对生成一组中间结果key/value键值对,reduce函数将所有具有相同key的中间结果合并起来。[10]在文献中,Map函数和Reduce函数的定义如下:Map函数是由用户实现的,以一对值为输入并产生一组中间key/value对。MapReduce框架把相同的中间结果keyI为分组的values并将它们传递给Reduce函数。Reduce函数也是用户实现的,接收一个中间keyI和这个key的一组values值。它将这些值合并形成一个更小的一组值。通常一个Reduce调用仅仅产生0个或1个输出值。中间结果values值是以一个iterator提供给用户的reduce函数的。这允许我们处理太大而无法在内存中处理的一组values值。MapReduce的执行流程如图2-5所示。在一些场合(比如单词统计),中间结果key可能存在很大的重复性,为了解决这个问题,MapReduce框架添加了可供用户选择的Combiner函数,它在将中间结果通过网络传递之前把一部分中间结果合并,也就是说它是在Map函数之后Reduce函数之前调用的。Combiner函数在执行一个map任务的每台机器上都会被执行。一般地会用相同的代码实现Reduce函数和Combiner函数,其中唯一的区别就是MapReduce框架如何处理函数的输出。Reduce函数的输出是写到最终的输出文件中,而Combiner函数的输出是写到将被传递给reduce任务的中第16页 基于云计算的海量电子病历文本分析系统研究间结果。[10]图2-5MapReduce的执行流程[10]Fig.2-5TheprocessingflowofMapReduce2.4.1HadoopMapReduce[17]HadoopMap/Reduce是一个使用简易的软件框架,基于它写出来的应用程序能够运行在由上千个商用机器组成的大型集群上,并以一种可靠容错的方式并行处理上T级别的数据集。一个Map/Reduce作业(job)通常会把输入的数据集切分为若干独立的数据块,由map任务(task)以完全并行的方式处理它们。框架会对map的输出先进行排序,然后把结果输入给reduce任务。通常作业的输入和输出都会被存储在文件系统中。整个框架负责任务的调度和监控,以及重新执行已经失败的任务。通常,Map/Reduce框架和分布式文件系统是运行在一组相同的节点上的,也就是说,计算节点和存储节点通常在一起。这种配置允许框架在那些已经存好数据的节点上高效地调度任务,这可以使整个集群的网络带宽被非常高效地利用。Map/Reduce框架由一个单独的masterJobTracker和每个集群节点一个slaveTaskTracker共同组成。master负责调度构成一个作业的所有任务,这些任务分布在不同的slave上,master监控它们的执行,重新执行已经失败的任务。而slave仅负责执行由master指派的任务。第17页 基于云计算的海量电子病历文本分析系统研究应用程序至少应该指明输入/输出的位置(路径),并通过实现合适的接口或抽象类提供map和reduce函数。再加上其他作业的参数,就构成了作业配置(jobconfiguration)。然后,Hadoop的jobclient提交作业(jar包/可执行程序等)和配置信息给JobTracker,后者负责分发这些软件和配置信息给slave、调度任务并监控它们的执行,同时提供状态和诊断信息给job-client。Map/Reduce框架运转在键值对上,也就是说,框架把作业的输入看为是一组键值对,同样也产出一组键值对做为作业的输出,这两组键值对的类型可能不同。由于框架需要对key和value的类(classes)进行序列化操作,因此,这些类需要实现Writable接口。另外,为了方便框架执行排序操作,key类必须实现WritableComparable接口。一个Map/Reduce作业的输入和输出类型如下所示:(input)-->map-->-->combine-->-->reduce-->(output)2.5HDFS[17]HDFS(HadoopDistributedFileSystem)是ApacheHadoopCore项目的一[22]部分,地址是http://hadoop.apache.org/core/,它是GFS的开源实现。同时,HDFS是一个高度容错性的系统,适合部署在廉价的机器上,它创建数据块的多个备份并且将它们分布式计算节点上,同时采用简单一致性模型,即“一次写入多次读取”。HDFS能提供高吞吐量的数据访问,非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束,来实现流式读取文件系统数据的目的。2.5.1Namenode和DatanodeHDFS采用master/slave架构,一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器,负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。集群中的Datanode一般是一个节点一个,负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间,用户能够以文件的形式在上面存储数据。从内部看,一个文件其实被分成一个或多个数据块,这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作,比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。HDFS架构如图2-6所示。第18页 基于云计算的海量电子病历文本分析系统研究Namenode和Datanode被设计成可以在普通的商用机器上运行。这些机器一般运行着GNU/Linux操作系统(OS)。HDFS采用Java语言开发,因此任何支持Java的机器都可以部署Namenode或Datanode。由于采用了可移植性极强的Java语言,使得HDFS可以部署到多种类型的机器上。一个典型的部署场景是一台机器上只运行一个Namenode实例,而集群中的其它机器分别运行一个Datanode实例。这种架构并不排斥在一台机器上运行多个Datanode,只不过这样的情况比较少见。集群中单一Namenode的结构大大简化了系统的架构。Namenode是所有HDFS元数据的仲裁者和管理者,这样,用户数据永远不会流过Namenode。[17]图2-6HDFS架构[17]Fig.2-6ArchitectureofHDFS2.5.2文件系统的名字空间(namespace)HDFS支持传统的层次型文件组织结构。用户或者应用程序可以创建目录,然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似:用户可以创建、删除、移动或重命名文件。当前,HDFS不支持用户磁盘配额和访问权限控制,也不支持硬链接和软链接。但是HDFS架构并不妨碍实现这些特性。Namenode负责维护文件系统的名字空间,任何对文件系统名字空间或属性的修改都将被Namenode记录下来。应用程序可以设置HDFS保存的文件的副本数目。文件副本的数目称为文件的副本系数,这个信息也是由Namenode保存的。第19页 基于云计算的海量电子病历文本分析系统研究2.5.3数据复制HDFS被设计成能够在一个大集群中跨机器可靠地存储超大文件。它将每个文件存储成一系列的数据块,除了最后一个,所有的数据块大小都是相同的。为了容错,文件的所有数据块都会有副本。每个文件的数据块大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定,也可以在之后改变。HDFS中的文件都是一次性写入的,并且严格要求在任何时候只能有一个写入者。Namenode全权管理数据块的复制,它周期性地从集群中的每个Datanode接收心跳信号和块状态报告(Blockreport)。接收到心跳信号意味着该Datanode节点工作正常。块状态报告包含了一个该Datanode上所有数据块的列表。HDFS的数据复制元数据和数据节点的存储如图2-7所示。[17]图2-7HDFS数据复制[17]Fig.2-7DataReplicationofHDFS2.5.4文件系统元数据的持久化Namenode上保存着HDFS的名字空间。对于任何对文件系统元数据产生修改的操作,Namenode都会使用一种称为EditLog的事务日志记录下来。例如,在HDFS中创建一个文件,Namenode就会在Editlog中插入一条记录来表示;同样地,修改文件的副本系数也将往Editlog插入一条记录。Namenode在本地操作系统的文件系统中存储这个Editlog。整个文件系统的名字空间,包括数据块到文件的映射、文件的属性等,都存储在一个称为FsImage的文件中,这个文件也是放在Namenode所在的本地文件系统上。Namenode在内存中保存着整个文件系统的名字空间和文件数据块映射第20页 基于云计算的海量电子病历文本分析系统研究(Blockmap)的映像。这个关键的元数据结构设计得很紧凑,因而一个有4G内存的Namenode足够支撑大量的文件和目录。当Namenode启动时,它从硬盘中读取Editlog和FsImage,将所有Editlog中的事务作用在内存中的FsImage上,并将这个新版本的FsImage从内存中保存到本地磁盘上,然后删除旧的Editlog,因为这个旧的Editlog的事务都已经作用在FsImage上了。这个过程称为一个检查点(checkpoint)。在当前实现中,检查点只发生在Namenode启动时,在不久的将来将实现支持周期性的检查点。Datanode将HDFS数据以文件的形式存储在本地的文件系统中,它并不知道有关HDFS文件的信息。它把每个HDFS数据块存储在本地文件系统的一个单独的文件中。Datanode并不在同一个目录创建所有的文件,实际上,它用试探的方法来确定每个目录的最佳文件数目,并且在适当的时候创建子目录。在同一个目录中创建所有的本地文件并不是最优的选择,这是因为本地文件系统可能无法高效地在单个目录中支持大量的文件。当一个Datanode启动时,它会扫描本地文件系统,产生一个这些本地文件对应的所有HDFS数据块的列表,然后作为报告发送到Namenode,这个报告就是块状态报告。2.6本章小结本章对文本分析和中文分词技术、非结构化信息管理架构UIMA和云计算技术进行了分析,着重分析了UIMA的类型系统和开源云计算平台Hadoop,包括MapReduce和HDFS。第21页 基于云计算的海量电子病历文本分析系统研究第三章云环境下基于UIMA的电子病历文本分析方法上一章对中文分词、非结构化信息管理架构UIMA以及开源云计算平台Hadoop进行了分析。本章结合UIMA和Hadoop提出一种在云计算环境下基于UIMA对海量电子病历中的非结构化文本信息进行分析并建立索引的解决方案。3.1问题的提出结构化的电子病历中存在大量的非结构化文本信息,如临床表现和医嘱等。这些信息是用自然语言表达的,这样可以方便医生在书写病历时不需要改变他们习惯的记录方式,可以自由地表达各种信息。但是对于计算机来说,理解这些记录是很困难的。另一方面,在医院内部或跨医院区域范围内的电子病历数据中心,共享的电子病历数据将是海量的。医生想要在这些海量的电子病历非结构化文本信息中检索出所需的电子病历,就需要对这类非结构化信息进行标注分析从而建立索引。对海量电子病历中的非结构化文本进行分析,其需求主要有如下几点:对电子病历中非结构化文本信息进行标注的分析引擎需要可定制。不同的分析需求需要不同的分析算法和分析引擎,因此分析引擎需要可定制。此外分析引擎还要支持中文分词,同时要能够支持医学术语词典的扩展。对海量电子病历进行分析处理的效率问题。对于海量文本信息,当用户需求发生改变时,知识获取过程中使用的词典、规则集、分析引擎、处理流程通常也随之变化,这就导致所有的海量数据被重新分析,这将是十分费时的。易于扩展。随着医疗信息化的发展,电子病历的增加速度是惊人的,短时间内可能会积累大规模的信息,因此系统必须能够应对这种需求,能够比较容易地扩展系统的处理能力。第22页 基于云计算的海量电子病历文本分析系统研究3.2基于UIMA的文本分析方法3.2.1UIMA关键组件UIMA中的基本功能组件有三种:CollectionReader(CR),分析引擎(AnalysisEngine,AE),CAS消费(CC),分别对应于非结构化信息的获取、分析、提交。简单分析引擎可以组合为复杂分析引擎(AggregateAE)以完成较复杂的功能。此外,UIMA还定义了集合处理引擎CPE(CollectionProcessingEngine)以及对其进行管理和控制的CPM(CollectionProcessingManager)。在介绍UIMA中三个关键组件之前,先给出几个重要的术语分析体、标注以及通用分析结构的定义。[1]分析体(artifact)是指应用层面上用于分析的信息单元,如一个文本文档、一段演讲或视频、一个文档集、或者这些文档的数据流等。[1]标注(annotation)是指非结构化信息中有价值的内容片段,如文本文档中的一段字符串,音频文件当中的一段声音。在程序运行阶段,标注是一个对象(object),具有特定的类型。如字符串“盛大网络”是Company类型的文本标注。通用分析结构(CommonAnalysisStructure,CAS)是UIMA中对分析体进行抽象的通用数据结构,是组件之间交互的数据通道,其中包含分析体的内容、标注集(annotations)以及分析体的元数据等信息。CollectionReader负责从分布的非结构化信息知识源站点中收集、读取文件并推送给分析组建。集合级别分析的内容和元数据就是通过CollectionReader获取的。UIMA提供的CollectionReader接口用于定制资源获取器,该接口的每个具体实现支持了一个或一种特定资源的访问。由CollectionReader获取到的每个分析体(如文本)在预处理阶段将被初始化为一个CAS对象,此时的CAS对象所包含的是一个空的标注集,同时还保存了资源站点的元数据信息以及该元素的元数据信息。分析引擎(AE)是非结构化信息分析阶段的主要功能组件,负责从非结构化信息中识别、定位关键信息并生成标注。分析引擎也称为标注器(annotators),它实现具体的分析算法。简单的AE仅仅包含单个annotator,复杂分析引擎有多个简单AE组合而成的。标注器创建标注集(annotations)。AE从CollectionReader获取CAS分析对象。CAS消费者(CASConsumer)从AE获取分析后的结果,根据用户需求对CAS中的标注和元数据等信息进行相应的处理,如持久化、生成索引,生成术第23页 基于云计算的海量电子病历文本分析系统研究[15]语表等。分析引擎组件的分析结构将根据不同的应用目的被推送给不同的CASConsumer。非结构化信息分析(UIA)分为文档级(Document-Level)分析和集合级(Collection-Level)分析。文档级别分析通过TAE完成,它只生成CAS而不需要维护文档间的任何状态信息。以文本分析为例,在文档级别分析中,由CollectionReader获取的CAS对象被分别送入相应的分析管道,经过分词、词性分类、句法分析、命名实体识别、翻译等复杂的自然语言处理,每种操作分别对应一个或一组AE,这些AE经常被组合成复杂分析引擎来完成复杂的分析任务。相比之下,集合级别分析对整个文档集进行处理,并首先分解为若干个文档级别的子任务,每个文档级别分析任务相互独立,可并行执行。当一个任务失败时可以即时被重启,同时不对其他任务造成影响。这些任务所得的结果集将被集成到一个任务中作统一处理,如进行跨文档共指消解、知识转换、推理等。集合级别分析需要维护每个子任务及其之间的状态信息,这个信息在分布式环境下显得尤为重要。可见集合级别分析在术语、中间结果和结果的形式上变化非常大,因此,必须维护文档间的状态而使得在分布式环境的管理变得十分复杂。为了支持集合级分析,UIMA定义了集合处理引擎(CollectionProcessingEngine,CPE)。一个CPE应用包括一个CollectionReader、一个文本分析引擎(TextAnalysisEngine,TAE)、一组CAS消费者(CASConsumer),如图3-1所示。图3-1UIMACPE处理流程Fig.3-1TheprocessingflowofUIMACPECPE是被称为CollectionProcessingManager(CPM)的UIMA基础组件执行的。CPM提供一系列服务和部署选项,包括CPE的实例化和执行,错误恢复,CPE组件的本地和分布式部署。3.2.2基于UIMA的文本分析过程我们先看看UIMA文本分析的流程,如下图3-2所示。首先UIMA框架通过CollectionReader组件获取未被处理的文档并传递给CASInitializer,它是获取原始文档以及产生初始CAS对象的组件,其中CAS将被文本分析引擎(Text第24页 基于云计算的海量电子病历文本分析系统研究AnalysisEngine,TAE)处理。例如,一个CollectionReader从一个Web爬虫获取HTML文档,但是TAE通常使用独立的标注处理普通的文本文档。CASInitializer的工作就是解析HTML并生成带有文本文档的CAS对象。其它可重用的CASInitializer实现可以被开发用于处理特定的XML方言或者其它文档格式如RTF或PDF。图3-2一个典型的UIMA应用的处理流程Fig.3-2TheprocessingflowofanUIMAapplication一旦CASInitializer处理完成,CPM使用TAE并传递包含在CAS对象中的分析结果给指定的CASConsumer。这个过程对于文档集中的每个实体是重复进行的。CASConsumer通常把文档级别的分析聚集到一个应用无关的数据结构中,例如分析引擎索引、术语表或者分类系统(taxonomy)。CPM也向应用提供额外的管理功能,如下:(1)过滤:保证只有特定的基于元数据约束的元素被处理;(2)错误处理:报告错误给用户并尝试重试失败的文档或者维护一个失败文档序列以便后面人工浏览;(3)性能监控:计量每个组件的处理时间并把当前性能统计展示给用户。(4)并行化:管理多个TAE实例的创建和执行以同时处理多个文档优化可用的计算资源。第25页 基于云计算的海量电子病历文本分析系统研究3.3基于云计算的海量文本分析方法3.3.1云计算平台的选择云计算的平台是多样的,如GoogleAppEngine,亚马逊的EC2、IBM的蓝云(BlueCloud)、微软的蓝天(Azure)等;还有很多开源云计算平台,如Hadoop、Eucalyptus。这里,实验系统采用开源的云计算平台。前面介绍了Hadoop框架和Eucalptus,下面就这两款平台进行比较。Eucalyptus用来通过计算集群或工作站群实现弹性的、实用的云计算,现在已经商业化,发展成为了EucalyptusSystemsInc。Eucalyptus是一种IaaS(InfrastructureasaService)服务,它兼容AWS(AmazonWebService)提供的EC2(ElasticComputeCloud)和S3(SimpleStorageService)接口。Hadoop最适合于海量数据的分析,Google最早提出MapReduce也是为了海量数据分析。同时HDFS最早是为了搜索引擎实现而开发的,后来才被用于分布式计算框架中。海量数据被分割于多个节点,然后由每一个节点并行计算,将得出结果归并到输出。同时第一阶段的输出又可以作为下一阶段计算的输入,形成一个树状结构的分布式计算图,在不同阶段都有不同产出,同时并行和串行结合的计算也可以很好的在分布式集群的资源下得以高效的处理。通过分析比较,Hadoop适用于海量信息的分析和检索,因此本方法选择Hadoop开源框架实现。Hadoop通过Google的MapReduce编程模型来创建并执行应用程序,还通过一个分布式文件系统(HDFS)透明地支持数据的可靠性和数据迁移。通过Hadoop,可以在合理的时间内对庞大的数据集并行执行,支持计算密集型服务,如对海量信息的分析及检索。目前很多企业都在使用Hadoop平台,如雅虎、Facebook、IBM、Intel、百度、阿里巴巴等。同时,Hadoop具有以下优点:可扩展(Scalable)、低成本、高效(Efficient)、可靠(Reliable)、易于使用。Hadoop集群具有很强的灵活性,可以根据用户的需求动态的增减集群规模,更进一步地说明Hadoop适合于海量文本分析系统的分析。3.3.2对小文件的处理小文件是一个典型的影响Hadoop处理效率的问题。下面用实验数据直观的说明该问题。以10GB文本输入为例,使用简单的UIMA的应用用时1956秒,而用如果输入文本是约5000个小文件,则在4台Hadoop集群下用时1595秒,可见处理效率改进不明显,而如果输入文本是一个大文件,在相同集群下用时仅第26页 基于云计算的海量电子病历文本分析系统研究655秒。下面结合HDFS和MapReduce的原理剖析这一问题并说明这一问题带来的挑战,最后给出几种解决方案。(1)HDFS中存储小文件的问题在Hadoop的应用中,小文件是指文件大小比HDFS的块大小(默认是64M)小的多的文件。如果在HDFS上存储小文件,那么这些小文件的数量将是十分惊人的(否则也没有必要放到Hadoop上来处理了),而HDFS不适合处理很多小文件。数量较多的小文件也会给Hadoop集群中的NameNode造成很大的压力。在HDFS中的文件、目录以及块都要在NameNode上进行注册,被表示成一个对象放在内存中,一般要占用150个字节,如果有1000万个文件,将要占用3GB内存,按照现在硬件水平,10亿数量级的文件就十分不可行。而且,HDFS并不是要为了提高小文件的访问效率的,它主要被设计用来对大文件的访问。读取小文件将会导致很多查找以及很多DataNode间检索小文件的访问,这些都不是高效的数据访问模式。(2)MapReduce小文件问题Map任务通常一次处理一个输入块(使用默认的FileInputFormat分块)。如果文件很小并且有很多这种小文件,那么每一次一个map任务只能处理很少的数据,必将导致有很多map任务,他们引发额外的记录延迟。1GB文件被切分成16个64M块和10,000个100KB的文件比较。10,000个文件每个使用一个Map,带来的额外开销不容忽视,Job的执行时间将比单个同大小的文件慢十倍甚至数百倍。产生小文件的情况主要有如下两种:这些文件是一个较大逻辑文件的分块。由于HDFS支持最近添加,保存没有上限文件(如log文件)的一个非常通用的模式就是把他们写到HDFS的组块中。这些文件本来就是小文件。假设有很多图像文件,每一个图像文件都是单一文件,并且没有什么好的办法把他们合并到一个大文件中去。(3)小文件问题的解决方法上面两种情况需要不同的解决方法。对于第一种情况,这个问题可以通过频繁地调用HDFS的sync()方法持续写大文件来避免。或者,可以写一个程序把这些小文件连接到一起。对于第二种情况,一些容器可以被用于把这些文件分组。Hadoop提供一下几种方法:使用MultiFileInputFormat类第27页 基于云计算的海量电子病历文本分析系统研究[41]MultiFileInputFormat是Hadoop框架提供的用于完成分块功能的类(可以替换Hadoop默认的分块类),它继承自FileInputFormat,它的核心方法getSplits(JobConfjob,intnumSplits)使用输入路径下的文件构建分块(splits),使得Hadoop获取的输入分块具有大致相等的文件长度。此时,即使有很多的小文件,也不会一个小文件占用一个map的情况,map还是会得到一个完整的块大小(Hadoop配置文件中的,默认是64MB),这样就可以大大加快实行的效率,因为根据经验法则,一个map的执行时间至少要达到1分钟才能体现出MapReduce的优势,而如果是一个小文件执行一次map,则map的执行时间只有5-10秒,甚至更短,使得MapReduce的优势荡然无存。FileInputFormat的类图如图3-3所示。从类图中可以看出,FileInputFormat实现了InputFormat接口,而且FileInputFormat的子类有CombineFileInputFormat,TextInputFormat,KeyValueTextInputFormat,MultiFileInputFormat,SequenceFileInputFormat等。图3-3InputFormat类图Fig.3-3ClassDiagramofInputFormatHAR归档文件HAR(HadoopArchives)文件是在0.18.0版本被引入到HDFS的,为的是缓解小文件对NameNode内存压力的问题。HAR是通过在HDFS上建立一层文件系统工作的。HAR文件是使用Hadoop的archive命令创建的,这个命令运行MapReduce的作业将多个文件存档到较少数量的HDFS文件中。使用HAR文件系统对于客户端来说什么都没有改变:所有原始文件都是可见的及可访问的(尽管使用har://URL的格式)。然而,HDFS中的文件数量已经减少了很多。第28页 基于云计算的海量电子病历文本分析系统研究通过HAR来读取一个文件并不会比直接从HDFS中读取文件高效,而且实际上可能还会稍微低效一点,因为对每一个HAR文件的访问都需要完成两层index文件的读取和文件本身数据的读取,如图3-4所示。图3-4HAR文件布局Fig.3-4HARFileLayout并且尽管HAR文件可以被用来作为MapReduce的输入,但是并没有特殊的方法来使maps将HAR文件中打包的文件当作一个HDFS文件处理。可以考虑通过创建一种输入格式(inputformat),利用HAR文件的优势来提高MapReduce的效率,但是目前还没有人作这种输入格式。需要注意的是:MultiFileInputSplit,即使在HADOOP-4565的改进,但始终还是需要寻找每一个小文件。顺序文件(SequenceFile)通常对于“小文件问题”的回应会是:使用SequenceFile。这种方法是说,使用文件名作为key,文件内容作为value。实践中这种方式非常管用。回到10000个100KB的文件,可以写一个程序来将这些小文件写入到一个单独的SequenceFile中去,然后就可以通过使用这个sequenceFile的流方式(直接地或者使用MapReduce)中来处理。不仅如此,SequenceFiles也是可分块的,所以MapReduce可以把他们分块,并且分别的被独立的处理。和HAR不同的是,这种方式还支持压缩。块的压缩在许多情况下都是最好的选择,因为它将多个记录压缩到一起,而不是一个记录一个压缩。将已有的许多小文件转换成一个SequenceFile可能会比较慢。但是,完全有可能通过并行的方式来创建一系列的SequenceFile。更进一步,如果有可能最好设计自己的数据流水线来将数据直接写入一个SequenceFile。SequenceFile文件格式如图3-5所示:图3-5SequenceFile文件格式Fig.3-5TheformatofSequenceFile第29页 基于云计算的海量电子病历文本分析系统研究3.4基于云计算和UIMA的电子病历文本分析方法3.4.1基本思路(1)UIMA和Hadoop整合基于UIMA的电子病历分析引擎运行在Hadoop平台上,标注分析结果通过Reduce函数并行地建立索引库。抽取出来的电子病历中非结构化的文本首先被写入到HDFS上面,接着由Hadoop框架获取Splits传递给map作为其输入,在map中我们只需要调用已经开发好的分析引擎组件,完成对输入文本的标注。在map中,先是将输入经过UIMA封装到CAS对象,被传到AE进行处理。而reduce可以完成对map输出结果的归并,将相同关键字的对应的value值一次处理,写入到索引库。直接将UIMA组件部署到Hadoop平台上运行,Hadoop框架无法找到相应的分析引擎组件,因为UIMA中的分析引擎组件是由xml文件描述的,而Hadoop框架需要将最终的Job分发到各个计算节点上,计算节点上并没有将要使用到的分析引擎文件,所以必须告知Hadoop框架,这些资源也是需要分发到计算节点上的。UIMA组件集成到Hadoop平台需要注意如下几点:所有UIMA组件的描述器(如分析引擎等)都要通过名字引入;读取资源文件都要通过Classloader完成;生成分析引擎或者CAS消费者时必须要使用ResourceManager。(2)电子病历的预处理为了后续文本分析的进行,首先需要将电子病历中的非结构化信息提取出来。如果提取出来单独存放将会产生很多的小文件,这将严重影响Hadoop的效率,使得MapReduce和HDFS的优势得不到很好地发挥。为了解决这个问题,这里采用前文中介绍过的顺序文件(SequenceFile)存储,以XDS中的电子病历文件的UUID(UniversallyUniqueIdentifier,通用唯一识别码)作为key值,以电子病历中的非结构化信息作为value值。这种格式不仅解决了小文件影响处理效率的问题,而且方便了检索时文件的定位。(3)分析引擎的定制UIMA是基于组件的非结构化信息管理架构,它降低了各个组件间的依赖关系,提高了组件的复用性,提高开发效率。UIMA的核心组件是CollectionReader、分析引擎(AnalysisEngine)、CAS消费者。电子病历中的临床症状等非结构化信息是使用中文描述的,所以,需要解决分析引擎中对自然语言进行中文分词的问题。在定制UIMA分析引擎时,使用第30页 基于云计算的海量电子病历文本分析系统研究中文分词器对临床症状等文本进行分析,然后在UIMA分析引擎的Annotator对分词结果进行标注,再结合UIMA的类型系统和描述文件构建出符合UIMA规范的分析引擎。符合UIMA规范的分析引擎是开放的,可以解决不同用户间需求不统一导致需要不同分析引擎的问题。3.4.2解决方案基于UIMA和Hadoop的海量电子病历文本分析的解决方案如图3-6所示。图3-6海量电子病历文本分析解决方案Fig.3-6Proposedsolutionoflarge-scaleelectronicmedicalrecordtextanalysis首先,需要从外部的基于跨机构文档共享规范XDS(Cross-EnterpriseDocumentSharing)的电子病历数据中心中获取原始的电子病历信息。外部数据源的文本可能是由很多小文件组成的,为了提高效率,需要使用预处理模块将大量的小文件合并成一个或较少个文件,可以更有效使用Hadoop的MapReduce的优势。所以在预处理的过程中,是将从电子病历中获取的医嘱等非结构化信息转换成顺序文件(SequenceFile)。同时,需要将最终的顺序文件拷贝到HDFS上,以便后续的处理。同时,由于原始的电子病历既可以以文件形式(CDA文档)存在的,也可以是在数据库中存放的,对于不同的输入电子病历源,预处理模块提供相应的适配接口。第31页 基于云计算的海量电子病历文本分析系统研究经过电子病历文本获取和预处理后,作业需要的输入数据已经准备就绪,此时就可以提交作业了。Hadoop框架中有一个JobTracker,它负责将Job分发到不同的TaskTracker上。从图中可以看到作业就是提交给了JobTracker,然后由JobTracker进行作业调度。下面核心的就是Map和Reduce部分,这里正是UIMA和Hadoop整合的关键点。Map执行时,使用读入的数据初始化一个CAS对象,然后调用UIMACPE中的分析引擎(AnalysisEngine)进行处理,分析引擎处理完成以后的CAS对象已经包含了由分析引擎添加的标注,再对CAS中的标注信息进行抽取,以<关键词,UUID>键值对作为Map的输出。对于分析引擎的实现,首先对封装在CAS中的文本进行中文分词,可以借助中文分词器完成。其次,由于要使用到医学词库,所以这一部分需要使用外部的CMV(ControlledMedicalVocabulary,受控医学词汇表),使用该词库对电子病历中的临床信息等非结构化信息进行分词。Reduce执行时,需要读取Map函数产生的中间结果,完成数据的汇总,将相同key的键值对合并,建立倒排索引至索引库中,供后续的检索服务模块使用,达到快速检索的目的。3.5本章小结本章提出了一种在云环境下基于UIMA的海量电子病历文本分析方法。首先分析了UIMA的关键组件及基于UIMA的文本分析方法;然后分析了基于Hadoop云计算平台的海量文本分析方法;最后,阐述了一种在云计算环境下基于UIMA的对海量电子病历文本进行标注分析从而建立索引的解决方案。第32页 基于云计算的海量电子病历文本分析系统研究第四章系统设计与实现上一章提出了一种在开源云计算平台Hadoop下基于UIMA的海量电子病历文本分析方法。本章阐述基于该方法的原型系统的设计与实现。4.1系统架构基于UIMA和Hadoop的海量电子病历文本分析系统LEMRAS(Large-scaleElectronicMedicalRecordTextAnalysisSystem)架构如图4-1所示。图4-1LEMRAS的架构Fig.4-1ThearchitectureofLEMRASLEMRAS采用了分层的体系架构,分为表现层、业务逻辑层、技术服务层和数据持久层。表现层向用户提供了电子病历非结构化信息的检索和配置管理。用户通过Web浏览器访问系统表现层,表现层使用RPC机制访问Web服务器中的各种服第33页 基于云计算的海量电子病历文本分析系统研究务。安全访问控制模块包含对用户的权限控制,登录系统后,医生可以使用检索服务,系统管理员可以使用配置管理模块。业务逻辑层提供了配置管理模块、文本分析模块、索引建立模块和检索模块。其中,系统管理员可以管理配置选项;文本分析模块包含对电子病历数据中心输入的预处理。技术服务层封装了第三方工具API如UIMA、Hadoop等。数据持久层提供系统的持久化,包括对HDFS的访问以及索引库的持久化。4.2文本分析模块文本处理模块是系统的核心模块,它通过运行在Hadoop集群上基于UIMA的可定制分析引擎对电子病历非结构化文本进行标注分析并建立索引。4.2.1XDS电子病历数据的预处理所谓XDS电子病历数据的预处理是指对遵循IHEXDS规范的医院内部或跨医院区域范围内的电子病历数据中心的海量电子病历数据的预处理,包括对非结构化文本信息提取和格式转换等。XDS规范主要提供一个基于标准的规范来管理各种医疗机构内部及其之间[53]的文档共享。XDS在某个指定的临床亲和域内,通过文档储存库(DocumentRepository)和文档注册库(DocumentRegistry)创建病人信息记录。XDS的角色和事务如图4-2。图4-2IHEXDS的角色和事务Fig.4-2IHEXDS’sRolesandTransactions第34页 基于云计算的海量电子病历文本分析系统研究图中,文档源(DocumentSource)、文档注册、文档消费者(DocumentConsumer)、病人标识源(PatientIdentifySource)、文档储存库是XDS角色;注册文档集(RegisterDocumentSet)、提供和注册文档集(ProvideandRegisterDocumentSet)、查询登记(QueryRegistry)、检索文档(RetrieveDocument)、登记被储存的查询(RegistryStoredQuery)、病人标识供应(PatientIdentityFeed)是XDS事务。文件格式的转换是指采用顺序文件(SequenceFile)存储,以电子病历文件的绝对路径作为key值,以电子病历中的非结构化信息作为value值,提高建立索引的速度以及方便索引的创建。其中,key和value之间用特殊字符分隔开,这里采用“u0001”分隔符。4.2.2UIMA分析引擎构建(1)简单分析引擎的构建AE的核心是分析算法,它承担分析文本和记录分析结果的所有工作。UIMA提供了一个基础的组件类型来封装AE中运行的核心分析算法,这个组件的实例被称为Annotators,在UIMA中,一个分析引擎由一个xml文件来描述。要定义和测试一个分析引擎,需要:定义annotator将要使用到的CAS类型;为CAS类型生成Java类;写annotatorJava代码;生成分析引擎描述符;测试annotator。所有Annotator都要实现一个标准接口(AnalysisComponent)。UIMA框架确保Annotator的实例在同一时间只有一个线程调用,不必考虑线程的同步问题。当需要改进性能需要多线程时,多个Annotator的实例被创建,各自只有一个线程。Annotator最重要的方法有如下几个:initialize方法:当一个Annotator实例被创建的时候,initialize方法被UIMA框架调用。可以在此方法中通过UimaContext获取配置参数。Annotator通过UimaContext来获取所有UIMA框架提供的工具和资源,比如日志工具和外部资源的访问。typeSystemInit方法:在process方法之前被调用,用于获取在process方第35页 基于云计算的海量电子病历文本分析系统研究法中需要用到的types和features。UIMA框架确保在process方法前,在typesystem有变化时调用此方法。process方法:由应用程序调用,如果使用CPM,则由CPM调用,用于处理CAS,分析引擎的工作就在process方法中完成。destroy方法:用于释放所有占用的资源。reconfigure方法:重新加载配置参数。UIMA框架永远不会主动调用,由应用程序调用。此处是唯一一个地方initialize方法被再次调用。UIMA框架默认的实现是调用destroy方法,然后再调用initialize方法。通常不需要覆盖这个方法,只有在initialize方法很复杂,重新加载配置不需要再次初始化所有东西时才覆盖次方法。initialize()方法将在框架第一次创建annotator类的实例的时候被创建;process()分析一次文件就被调用一次,它是annotator的核心函数。通常使用JCas的话,Annotator都继承JCasAnnotator_ImplBase,它实现了除process()方法以外所有需要的方法,因此在具体开发Annotator时,只需要实现process方法即可。在Annotator中,可以通过UimaContext来记录日志。下面以一个用于注释Email地址的分析引擎为例,讲解构建一个分析引擎的Annotator核心开发,假设采用简单的基于正则表达式(RegularExpression)的标注,标注Email的正则表达式为“[a-zA-Z]\w*(\.\w+)*@\w+(\.\w+)+”,开发出EmailAnnotator.java后,在使用分析引擎描述文件(xml文件)构建出一个UIMA的分析引擎。该Annotator核心代码如图4-3所示。图4-3EmailAnnotator核心代码Fig.4-3KeycodeofEmailAnnotator第36页 基于云计算的海量电子病历文本分析系统研究(2)组合分析引擎的构建一个简单的分析引擎是由一个标注器(Annotator)和一个本地语言的CAS组成的。一个复杂分析引擎是由两个或两个以上的组件分析引擎,但是暴露同简单分析引擎一样的外部接口。组合分析引擎的结构如下图4-4所示。运行中,组合分析引擎会被赋予组件分析引擎的执行顺序。组件分析结构代理(AnalysisStructureBroker)会根据工作流配置文件来决定分析引擎的调用顺序和CAS的传递路径。和其他的嵌套编程模型一样,这种递归的结构确保了组件可以被很容易的复用。一个组合分析引擎可以包含Java标注器和C++标注器,UIMA框架会处理所有的互用细节。使用UIMASDK将任何顺序的分析引擎构造成一个组合分析引擎变得很容易。只需要通过XML描述文件完成,不需要Java代码。例如,前面定义了一个标注Email的分析引擎,类似的再构造一个标注TelephoneNumber的分析引擎,则将标注Email的分析引擎和TelephoneNumber的分析引擎组合成EmailAndTelephoneNumber.xml描述文件的关键配置。至少需要配置delegateAnalysisEngine,flowConstraints,outputs三个选项。其中,delegateAnalysisEngine用于配置分析引擎描述文件的位置,flowConstraints用于配置多个分析引擎的执行顺序,outputs配置输出类型。图4-4组合分析引擎Fig.4-4AggregateAnalysisEngine(3)电子病历非结构化文本标注分析引擎设计由于电子病历中的非结构化文本如医嘱等信息是以中文表达的,索引要使用第37页 基于云计算的海量电子病历文本分析系统研究到中文分词器,在原型系统中使用了开源的分析器IKAnalyzer3.2.0。电子病历中的非结构化文本中含有很多的医学词汇,所以需要使用医学字典。IKAnalyzer支持字典的扩展。例如,一条医嘱中含有“该病人是红白狼疮患者”,如果没有医学词库的支持,切分的结果将是“该病人是红白狼疮患者”,如果使用这个切分结果建立索引,当使用“红白狼疮”作为关键字检索时是没有检索结果的,造成检索的不准确。有了医学词库的支持,正确的切分结果为“该病人是红白狼疮患者”。IKAnalyzer也支持过滤词典(Stopwords)。分析引擎的类图如图4-5所示。图4-5分析引擎实现类图Fig.4-4TheclassdiagramofAnalysisEngineimplemented图中,WordSegmentationAnnotator类的process()方法调用IKSegmentation分词,然后用WordSegmentation标注这些分词。4.2.3文本处理流程预处理阶段已经将待处理的数据写到分布式文件系统上,因此只需要指定HDFS上的输入目录(或文件)后,就可以交给Hadoop框架读取输入文本,其处理流程如图4-6所示。第38页 基于云计算的海量电子病历文本分析系统研究图4-6文本分析监控模块处理过程Fig.4-5ThedataflowofTextAnalysisandMonitormodule(1)根据输入路径,HadoopMap/Reduce框架为每一个InputSplit产生一个map任务,而每个InputSplit是由该作业的InputFormat产生的。然后把Split分配给不同的Map任务。(2)Map获取对,作为mapper的输入,其中key的值是一个无关的唯一的LongWritable的值,value默认是输入split里的一行,默认地,Hadoop是以行来读取数据的。在Mapper里用户自己根据需求处理及定义要产生的中间结果的形式。中间结果可能是Hadoop框架里提供的基本类型,也可以是用户自己定义的类,如前文讲到的CASData类。在Map中我们会调用UIMA框架中定制的分析引擎(AnalysisEngine),这样就可以把value标注完成。最后将中间结果输出到HDFS。(3)Combine(可选)和Sort的过程,这两者都是Key为标准的,即合并部分相同的Key及以Key来排序。(4)Reduce获取Map产生的中间结果作为输入,其中values是一个iterator。Reducer遍历所有节点取得所需的中间结果集,再进行去重、过滤等后期处理而得到结果。这里将最终结果写入Mysql索引表。(5)最后有OutputFormat类内嵌的RecordWriter将最终结果输出。输出的结果会放在用户设定的目录中,输出文件的个数和Reduce的个数相同。4.2.4Map和Reduce的实现Map和Reduce是文本处理模块的核心,它们的实现直接影响文本分析的效率。第39页 基于云计算的海量电子病历文本分析系统研究首先,经过预处理模块待处理的文本文件已经被放到已经格式化的HDFS文件系统中,这样,map就可以通过Hadoop框架获得要处理的数据,由于处理的是简单的文本文件,因此就不再需要使用UIMA框架中的CollectionReader组件。定义UIMAMapper类,它继承MapReduceBase类实现Mapper接口,需要重写(Override)map方法,UIMAMapper的类图如图4-7所示。UIMAMapper中最重要的成员变量是tae和cas,tae是文本分析引擎,cas是CAS对象,是UIMA各个组件间数据流通的桥梁。UIMAMapper类中最重要的方法是map和configure方法。在实现map()函数之前,需要初始化的操作,读取所要使用的分析引擎,而初始化操作在configure()方法中完成。初始化过程中,需要使用Hadoop框架中的ResourceManager获取UIMA分析引擎等组件的资源,即描述分析引擎等组件的xml文件,xml文件的读取需要使用XMLInputSource类和ClassLoader机制完成,最终调用UIMAFramework.produceAnalysisEngine()产生tae实例,最后调用tae.newCAS()获得cas对象,至此初始化完成。图4-7UIMAMapper类图Fig.4-7TheclassdiagramofUIMAMappermap方法中首先是对输入数据的分解。通过预处理模块后,采用顺序文件(SequenceFile)存储,而Hadoop默认是按行读取的,所以需要将map中读取的value模块解析出电子病历的url和医嘱的内容,由于采用了“u0001”分隔符分隔,处理起来很容易。cas对象在configure()中已经完成了初始化,在map第40页 基于云计算的海量电子病历文本分析系统研究方法中就可以直接使用了,因为map方法在每一个Map执行时都会调用,所以需要将cas对象清空,避免干扰。接着将Hadoop框架获取的value值放到cas对象中,交由AnalysisEngine对象tae的process方法处理,处理完成以后,对医嘱关键词标注已经存在cas对象中,只需要从cas中抽取出来,以<关键词,电子病历url>格式作为map输出。Reduce获取Map函数输出的中间结果,按关键词key归并,这样可以一次将相同关键词的索引建立完成,减少数据库访问。在原型系统中,只是记录关键词所在的电子病历文档,没有记录关键词出现的频率和位置。在Reduce中要完成关键词索引的建立,写到Mysql数据库中。在reduce方法中要写数据库,所以需要实现一个数据库的记录类KeywordRecord,它要实现Writable和DBWritable接口。UIMADriver、UIMAReducer及UIMAMapper之间关系的类图如图4-8所示。需要在UIMADriver中设置reduce方法的输出类型是DBOutputFormat,然后将KeywordRecord作为DBOutputFormat的setOutput的参数进行初始化设定,包括数据库表名和属性列名。还需要调用DBConfiguration的configureDB方法设定Mysql的相关参数,包括数据库Driver、数据库路径、用户名和密码。每个DBWritable的实例在传递给Reducer中的OutputCollector时都将调用其中的write(PreparedStatementstmt)方法。在Reduce过程结束时,PreparedStatement中的对象将会被转化成SQL语句中的INSERT语句,从而插入到数据库中。图4-8UIMADriver实现类图Fig.4-8TheclassdiagramofUIMADriverimplementation第41页 基于云计算的海量电子病历文本分析系统研究4.3索引建立索引的建立采用倒排索引的方式,存储于Mysql数据库中。4.3.1倒排索引倒排索引源于实际应用中需要根据属性的值来查找记录。这种索引表中的每一项都包括一个属性值和具有该属性值的各记录的地址。由于不是由记录来确定属性值,而是由属性值来确定记录的位置,因而称为倒排索引(invertedindex)。[46]带有倒排索引的文件我们称为倒排索引文件,简称倒排文件(invertedfile)。在搜索引擎收集完数据的预处理阶段,搜索引擎往往需要一种高效的数据结构来对外提供检索服务。而现行最有效的数据结构就是“倒排索引”,著名的全文检索和搜寻的开源程式库Lucene就是采用倒排索引原理实现的。下面结合实例说明,假设有2个文件,文件内容如下:文件1:她在住院。文件2:她是红白狼疮患者。使用IKAnalyzer分词获得分词结果如下:文件1:她在住院。文件2:她是红白狼疮红白狼疮患者。使用IKAnalyzer中的过滤词典将中文中的“的”、“是”等字通常也无具体含义的词过滤掉。得到的关键词如下:文件1:[她][住院]文件2:[她][红白狼疮][红白][狼疮][患者]使用上述关键词建立的倒排索引如表4-1所示:表4-1简单的倒排索引Table.4-1Simpleinvertedindex第42页 基于云计算的海量电子病历文本分析系统研究通常,只记录关键词在哪些文件中是不够的,还需要记录关键词在文章中出现的次数和出现的位置。通常,关键字的位置有两种:(1)字符位置,即该关键词是文章中的第几个字符,优点是关键词高亮显示时定位快。(2)关键词位置,即记录该词是文章中的第几个关键词,优点是节约索引空间以及词组(phase)查询快。增加关键词在文章中出现的频率和出现的位置,索引结果如表4-2所示:表4-2带有关键词频率和位置的倒排索引Table.4-2Invertedindexwithfrequencyandpositionofkeywords4.3.2索引库设计采用上节中介绍的倒排索引方式建立关键词索引。索引库的设计关键词索引表KeywordsIndex。KeywordsIndex表有keyword、emr_uuid和position三个字段,其中,keyword表示关键词,emr_uuid表示XDS电子病历数据中心中电子病历的通用唯一识别码,position表示关键词keyword在电子病历中非结构化信息的位置。关键词索引表KeywordsIndex字段的数据类型如表4-3所示。表4-3KeywordsIndex表字段数据类型Table.4-3DatatypeofKeywordsIndextablekeywordemr_uuidpositionVARCHAR(100)VARCHAR(100)TEXTKeywordsIndex表中,(keyword,emr_uuid)为主键,position作为扩展字段,用于关键词高亮显示时使用。记录的格式是“位置1,位置2...”,使用位置信息时需要先解析再使用。第43页 基于云计算的海量电子病历文本分析系统研究4.4配置管理模块配置管理模块向系统管理人员提供分析引擎及字典词库的配置功能。4.4.1分析引擎配置在UIMA中,分析引擎(AnalysisEngine)是xml文件描述的,还包括Annotator和类型系统。这里分析引擎的正确性验证是重要的而且是必须的,因为错误的分析引擎提交到集群上毫无意义,更主要的是集群上Job出错不是很方便定位错误种类,无法确定是UIMA分析引擎组件的问题还是Hadoop集群中的问题,所以有必要在Job提交之前就保证分析引擎组件的正确性。仅仅简单检查文件的类型是远远不够的,直接检测的难度非常大。由于最终使用的是UIMA框架里提供的分析引擎组件接口,这里我们采用一种简单有效的方法,我们会根据用户提供的AE(包括Annotator和类型系统以及描述文件)上传到服务器,并在服务器上启动一个简单的分析引擎的CPE应用,检测这个应用是不是能够正常执行,然后根据执行结果反馈给用户。当然,由于只是检测其正确性,所以测试文本选择很小(一般不超过100KB)即可。分析引擎检测流程如图4-9所示。图4-9分析引擎合法性检测Fig.4-9TheprocessingflowofcheckingAnalysisEngine4.4.2医学词典配置系统中使用的CMV(ControlledMedicalVocabulary,受控医学词汇表)是外部系统提供的。原型系统实现时使用的是仁济医院SLE系统中的医学词库,总共词条约20万条,采用中英文对照的方式存储的。医学词典是在配置文件中配置的,系统会根据配置文件获取相应的医学词典。第44页 基于云计算的海量电子病历文本分析系统研究4.5本章小结本章阐述了以云环境下基于UIMA的电子病历文本分析方法为基础的原型系统LEMRAS的设计与实现,包括架构设计和文本分析、索引建立及配置管理等功能模块的详细设计与具体实现。第45页 基于云计算的海量电子病历文本分析系统研究第五章系统部署及实验结果5.1实现环境LEMRAS系统实现工具环境如表5-1所示。为了系统使用的方便性,系统实现采用的是B/S架构,使用了JSP和TomcatWeb容器。ApacheUIMA2.2部[23]分实现了UIMASpecification1.0。为了保证系统的安全与使用效率,我们设计了用户的权限管理与控制,用户信息保存在Mysql数据库中。尽管Hadoop的版本发行较快(目前Hadoop最新版本是0.21.x),在本系统中采用0.19.2版本。系统的开发环境是Eclipse3.5.2。表5-1LEMRAS系统实现环境Table.5-1ImplementationenvironmentofLEMRAS名称实现环境Web容器Tomcat6.0表现层JSPUIMAApacheUIMA2.2数据库Mysql5.1Hadoop0.19.2Java1.6.0_20Eclipse3.5.25.2部署及应用案例部署涉及到很多的环境搭建,如JDK、Mysql、Tomcat等,这里仅介绍Hadoop环境下运行UIMA应用的关键部署,Hadoop集群详细部署步骤见Hadoop官方文档http://hadoop.apache.org/common/docs/r0.19.2/cluster_setup.html。Hadoop集群的部署,如SSH安装与配置,masters和slaves配置等,这里都不做赘述。需要注意的是,以上的4台机器都要使用相同的用户名,Hadoop-0.19.2目录要被放置在各台机器的相同路径下。5.2.1Hadoop的配置选项Hadoop的默认配置选项在conf/hadoop-default.xml文件中,而且建议不要直接修改hadoop-default.xml文件,如果想修改其中的选项,可以在hadoop-site.xml文件中修改,运行过程中,hadoop-site.xml中的配置选项将覆盖hadoop-default.xml第46页 基于云计算的海量电子病历文本分析系统研究文件中相同的配置项,从而使得配置生效。要搭建Hadoop集群,除了要配置在conf/hadoop-env.sh中配置JAVA_HOME环境变量外,还必须在hadoop-site.xml文件中至少要配置如下几项:fs.default.namehdfs://192.168.1.34:9000mapred.job.tracker192.168.1.34:9001dfs.replication3其中,fs.default.name是NameNode的URI(UniformResourceIdentifier,通用资源标志符),value的形式是“hdfs://主机名/”;mapred.job.tracker是JobTracker的主机(或者IP)和端口,value的形式是“主机:端口”;dfs.replication是文件在HDFS上的复制因子,即数据在HDFS上冗余存储的拷贝数,一般默认设置为3。5.2.2UIMA在Hadoop集群配置当UIMA应用提交到Hadoop集群上之后,Hadoop框架会将该Job的代码复制到每个TaskTracker上,由于在MapReduce里会使用到AnalysisEngine和CASConsumer组件,所以,Hadoop需要使用UIMAlib目录下的jar包,包括jVinci.jar,uima-adapter-soap.jar,uima-adapter-vinci.jar,uima-core.jar,uima-cpe.jar,uima-document-annotation.jar,uima-examples.jar,uimaj-bootstrap.jar,uima-tools.jar。需要把上述jar包拷贝到Hadoop-0.19.2的lib目录下,同时,需要集中中的所有TaskTracker都需要有这些jar包,否则会报找不到UIMA相关类的错误。第47页 基于云计算的海量电子病历文本分析系统研究5.2.3应用案例Hadoop集群配置完成后,再启动Hadoop集群,就可以开启原型系统了,接着启动Web服务容器Tomcat,然后在Firefox浏览器中输入http://localhost:8888/edu.sjtu.se.LEMRAS/index.jsp,输入“关节痛”关键字,结果如下图5-1所示。图5-1原型系统用户界面Fig.5-1UIofLEMRAS5.3性能测试及结果分析5.3.1测试环境采用4台PC机组成Hadoop集群,带宽为100M,其中1台为NameNode和DataNode,其他3台为DataNode节点。PC机的配置为内存2GB,硬盘为170GB,操作系统为Ubuntu9.10。测试数据采用了模拟数据,每个电子病历非结构化文本信息数据量平均约10KB,分别对80MB、1GB、10GB、20GB的数据量进行测试。5.3.2测试结果及分析对80MB、1GB、10GB、20GB的数据量的性能测试结果如表5-2所示:第48页 基于云计算的海量电子病历文本分析系统研究表5-2性能测试结果Table.5-2Resultofprototypesystem输入文本建立索引时间80MB45s1GB190s10GB985s20GB1583s从上表5-2中可以看出,随着文本量的增大,效果也越来越显著。由于实验条件的限制,实验测试数据的量不是很大,但从表中可以看出,随着文本输入量的增大,效果也越来越好,可见相同条件下,大数据量的输入文本会取得更好的效果。索引建立模块的加速比和效率如图5-2所示。图5-2实验中节点数加速比和效率Fig.5-2Thespeedupandtheefficiencyforvariousnumbersofnodes尽管Hadoop提供数据本地化的机制,但是由于各个计算节点之间需要数据的传输,所以网络的带宽和速度仍然是系统处理效率的瓶颈,特别是较大集群或者各个子集群之间的数据交换,会产生较大的时间开销。5.4本章小结本章介绍了原型系统的实现环境,部署及应用案例,性能测试及结果分析。测试及应用情况表明,原型系统是可行及有效的。第49页 基于云计算的海量电子病历文本分析系统研究第六章结语6.1工作总结电子病历的结构化是计算机可理解的电子病历的基础。但在结构化的电子病历中存在大量的非结构化信息,例如医嘱和治疗记录。如果医生在临床表现等治疗记录时尽量用自然语言描述可以不需要改变他们习惯的记录方式,从而可以自由地表达各种信息。但是对于计算机来说,理解这些记录是很困难的。另一方面,在医院内部或跨医院的区域范围内,电子病历数据是海量的。本文以实验室承担的上海科委重点科技攻关项目“面向规模互联的医院内部数据一体化整合建模技术研究(课题编号:08DZ1500507)”为背景,针对医院内部或跨医院区域范围内的电子病历数据中心的海量电子病历中非结构化信息检索问题,结合UIMA和云计算技术,提出一种在云计算环境下基于UIMA的海量电子病历文本分析方法并实现原型系统。本文工作主要包括:(1)分析研究了UIMA架构及其核心组件;深入研究了云计算关键技术、开源云计算框架Hadoop及其作业调度。(2)提出了一种在云计算环境下基于UIMA对海量电子病历中的非结构化文本信息进行分析并建立索引的解决方案。该方案将UIMA框架与云计算编程模型MapReduce相结合,首先对从遵循IHEXDS规范的海量电子病历数据源获取的非结构化文本信息进行预处理;然后通过执行Hadoop平台的Map函数,调用遵循UIMA规范的分析引擎进行分词及标注处理,结果以<关键词,UUID>键值对作为Map的输出;最后通过执行Reduce函数,读取Map函数产生的中间结果,完成数据的汇总,将相同key的键值对合并,建立倒排索引至索引库。(3)设计并实现了基于上述解决方案的原型系统。该系统采用分层的架构,整合了开源的UIMA参考实现和Hadoop平台,主要包括文本分析、索引建立和配置管理等功能模块。(4)开发实现了一个基于UIMA规范的中文分析引擎。该引擎以开源的中文分词软件IKAnalyzer为基础,结合外部的受控医学词汇CMV(ControlledMedicalVocabulary)服务,可标注分析结构化电子病历中用自第50页 基于云计算的海量电子病历文本分析系统研究然语言记录的非结构化中文文本信息。6.2工作展望由于时间和实验环境的限制,本系统目前功能还较为单一,后续可以考虑做成一个通用的海量电子病历信息处理平台,同时将抽取出的信息做后续处理,结合OWL等实现知识发现、知识管理,发挥更大的价值。实验中采用了Mysql做为医嘱索引的载体,不是很理想,因为在集群规模较小时效果不错,但对于大集群而言,Mysql就有很大的局限。考虑后期采用开放源代码的全文检索引擎工具包Lucene建立医嘱等非结构化信息的全文索引及信息检索。为了获得更高的处理效率,可以改进Hadoop的调度算法,使得集群的负载更加均衡。因为Hadoop的作业调度默认的是采用FIFO(FirstInFirstOut,先进先出)的调度策略,不能够达到有效的负载均衡,在一定程度上是Hadoop集群[11]应用的瓶颈。尽管Hadoop调度策略已经有改进,文献提出了一种基于优先级的加权轮询算法,但调度效果仍然不尽如人意。第51页 基于云计算的海量电子病历文本分析系统研究参考文献[1]DavidFerrucci,AdamLally,"UIMA:anarchitecturalapproachtounstructuredinformationprocessinginthecorporateresearchenvironment",NaturalLanguageEngineering,2004.[2]DavidFerrucci,AdamLally,"BuildinganexampleapplicationWithUIMA",IBMSystemsJournal,2004[3]http://www.tudou.com/events/join/about.html[4]杨茶.基于UIMA的内容搜索[硕士论文].电子科技大学,2008.[5]AnthonyLevas,EricBrown,J.WilliamMurdock,andDavidFerrucci,“TheSemanticAnalysisWorkbench(SAW):TowardsaFrameworkforKnowledgeGatheringandSynthesis”,ProceedingsoftheInternationalConferenceonIntelligenceAnalysisMcClean,VA,May2-6,2005.[6]AmazonElasticComputeCloud,http://aws.amazon.com/ec2/[7]imdict-chinese-analyzer.http://code.google.com/p/imdict-chinese-analyzer/[8]mmseg4j.http://code.google.com/p/mmseg4j/[9]IKAnalyzer.http://code.google.com/p/ik-analyzer/[10]J.Dean,S.Ghemawat,“MapReduce:SimplifiedDataProcessingonLargeCluster”,OSDI’04,SixthSymposiumonOperatingSystemDesignandImplementation,SanFrancisco,CA,December,2004[11]邓自立.云计算中的网络拓扑设计和Hadoop平台研究.中国科学技术大学,2009.[12]http://en.wikipedia.org/wiki/Unstructured_data[13]J.WilliamMurdock&ChristopherWelty.ObtainingFormalKnowledgefromInformalTextAnalysis.ComputerScience,2006.[14]MichaelThomasEgner,MarkusLorch,EddBiddle.UIMAGRID:DistributedLarge-scaleTextAnalysis,IEEE,2007.[15]邹志鹏.基于UIMA的企业知识管理系统研究.上海交通大学硕士学位论文,2010.[16]陈全,邓倩妮.云计算及其关键技术.计算机应,2009.[17]http://hadoop.apache.org/common/docs/r0.19.1/[18]ApacheUIMA.http://uima.apache.org/.第52页 基于云计算的海量电子病历文本分析系统研究[19]ApacheHadoop.http://wiki.apache.org/hadoop/.[20]Eucalyptus.http://www.oschina.net/p/eucalyptus.[21]http://en.wikipedia.org/wiki/Cloud_computing[22]SanjayGhemmawat,HowardGobioff,andShun-TakLeung.TheGoogleFileSystem.ACM,2003.[23]OASISStandard,2March2009,UnstructuredInformationManagementArchitecture(UIMA)Version1.0,http://docs.oasis-open.org/uima/v1.0/os/uima-spec-os.html[24]http://www.cloudera.com/blog/2009/02/the-small-files-problem/[25]IGurevych,MMuhlhauser,CMuller,etc."DarmstadtKnowledgeProcessingRepositoryBasedonUIMA".http://incubator.apache.org[26]Müller,etc,"FlexibleUIMAComponentsforInformationRetrievalResearch".InProceedingsoftheLREC2008Workshop,TowardsEnhancedInteroperabilityforLargeHLTSystems:UIMAforNLP,Marrakech,Morocco,May31,2008[27]UHahn,EBuyko,RLandefeld,MMuhlhausen,M."AnOverviewofJCORE,theJULIELabUIMAComponentRepository",TowardsEnhancedInteroperabilityforLargeHLTSystems[28]Guven,S.;Podlaseck,M.;Pingali,G.,"PICASSO:PervasiveInformationChronicling,Access,Search,andSharingforOrganizations,"PervasiveComputingandCommunications,2005.[29]Levas,A.;GopalPingali;Podlaseck,M.;etc.,"Exploitingpervasiveenterprisechroniclesusingunstructuredinformationmanagement",PervasiveServices,2005.ICPS'05,Proceedings.[30]盛大在线云计算在张江.http://www.cloudcomputing-china.cn/Article/cloudcomputing/201005/632.html[31]中国云计算网,什么是云计算:http://www.cloudcomputing-china.cn/Article/ShowArticle.asp?ArticleID=1[32]常兴龙.机器学习算法在文本分析中的研究.天津大学硕士学位论文,2008年5月.[33]卢群.UIMA架构下Web访问信息的研究和应用.上海交通大学硕士学位论文,2007.[34]UIMAtutorials_and_users_guidesdocs.[35]UHahn,EBuyko,KTomanek,SPJMNYTsuruoka,S,"AnAnnotationTypeSystemforaData-DrivenNLPPipeline",ACL2007[36]思科EMC联合推出集成的与计算交付平台.http://it.cri.cn/tech/264195/第53页 基于云计算的海量电子病历文本分析系统研究617141986495.shtml[37]EMC云计算战略服务.http://china.emc.com/services/consulting/infrastructure/offerings/cloud-computing-strategy-service.htm[38]从6亿到280亿:EMC云计算的偶然和必然?http://home.donews.com/donews/article/1/141682.html[39]Intel云计算.http://www.intel.com/zh_CN/itcenter/topics/cloud/index.htm[40]FSShell.http://hadoop.apache.org/common/docs/r0.19.1/hdfs_shell.html[41]MultiFileInputFormatsourcecode.http://code.google.com/p/hop/source/browse/trunk/src/mapred/org/apache/hadoop/mapred/MultiFileInputFormat.java?r=557[42]云安全。http://baike.baidu.com/view/1725454.htm[43]PaodingAnalysis.http://code.google.com/p/paoding/[44]Information_retrieval.http://en.wikipedia.org/wiki/Information_retrieval[45]孙斌.文本信息提取技术.北京大学计算机系计算语言所。http://www.chinaai.org/paper/pr/文本信息提取技术.ppt[46]百度百科:倒排索引。http://baike.baidu.com/view/676861.htm[47]中文分词。http://baike.baidu.com/view/19109.htm[48]文本分析。http://baike.baidu.com/view/3488135.htm[49]DomenicoM.Pisanelli,FabrizioConsorti,SupporttotheManagementofClinicalActivitiesontheContextofProtocol-BasedCare,Dec.1996ACMSIGBIONewsletter.[50]百度百科:电子病历。http://baike.baidu.com/view/18090.htm[51]百度百科:云计算。http://baike.baidu.com/view/1316082.htm[52]IHEITITechnicalFramework.RetrieveNov.05,2009,fromhttp://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol1_FT_2009-08-10-2.pdf.[53]AsumanDogac,GokceB.Laleci,ThomasAden,andMarcoEichelberg.EnhancingIHEXDSforFederatedClinicalAffinityDomainSupport.IEEETransactiononInformationTechnologyBiomedicine,VOL.11,NO.2,MARCH2007.[54]CarticRamakrishnan,etc."BuildingtheScientificKnowledgeMine(SciKnowMine1):acommunity-drivenframeworkfortextminingtoolsindirectservicetobiocuration",LREC2010,2010第54页 基于云计算的海量电子病历文本分析系统研究致谢首先要感谢我的导师饶若楠副教授。饶老师忘我的工作精神,严谨的科研态度令我敬佩不已。饶老师也从生活上关心我,指出我的不足,使我获得了长足的进步,是我受益匪浅,将是我终身的宝贵财富。同时,从论文的选题,思路的启发,资料的分析,到论文的撰写,饶老师都花了大量的时间指导、评阅并提出宝贵意见。正是有了饶老师的悉心指导,才使我能够顺利地完成本论文的工作。在此,谨向饶老师致以崇高的敬意和衷心的感谢。感谢项目组成员施惠俊在项目实施过程中的互助合作。感谢我的同学张健、张路杨等,两年多来,我们一起完成项目,一起学习,一起成长,我经常向你们请教,获得很多的帮助,通过和你们的讨论、交流,增长了见识,开阔了眼界,获益良多。感谢我的师兄邹志鹏、邓业强、王雪峰、严旭东等,你们在学习和生活上都帮助了我很多,你们踏实肯干,给我们做了好榜样。感谢实验室的师弟师妹们,是你们使得实验室像是一个温暖的大家庭,时刻充满着和谐、欢乐的学习氛围。感谢我的室友赖宏辉,肖汉波,陈伟,高逢骞,王睿,邓国贵,张松,和他们一起度过了很多快乐的时光。你们在我的生活中给了我非常多的关怀,感谢你们能在我最困难的时刻给予我鼓励。在两年多的朝夕相处中,我们结下了深厚的兄弟情谊。感谢软件学院的各位老师和工作人员,你们提供了良好的学习和科研环境,及时提供讲座和交流信息。感谢我的父母,你们的无私付出是我努力的最大动力,在此祝福你们永远幸福安康。第55页 基于云计算的海量电子病历文本分析系统研究攻读学位期间发表的学术论文目录[1]JIANGUO,RUONANRAO.“Large-scaleTextAnalysisBasedonUIMAandCloudComputing”,ICCCI2010,V2:146-150.(已发表)第56页

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。
关闭