| 编辑推荐: |
本文主要介绍了大数据在医疗行业的发展趋势、大数据在医疗行业的应用场景、医疗行业建设大数据项目取得的收益、医疗行业建设大数据项目面临的风险与应对措施及疗行业建设大数据项目技术路线的选择等，希望对您的学习有所帮助。
本文来自于微信公众号twt企业IT社区，由Linda编辑、推荐。 |
|
1 大数据在医疗行业的发展趋势
据有关机构统计数据，最近几年全球数据产生量迅猛增长。到2020年全球数据产生量达到50.5ZB，同比增长23%。在数据储量不断增长的推动下，大数据产业也将构建出多层多样的市场格局，具有广阔发展空间。未来两年里，大数据市场将呈现稳步发展的态势，增速保持在14%左右。
近年来，随着云计算、大数据、物联网、移动互联网、人工智能等新兴技术不断涌现和成熟，加速了传统医疗行业与这些新兴技术的融合，其中以健康医疗大数据为代表的医疗新业态，不断的激发着医疗行业的发展。在过去几年，健康医疗大数据应用市场规模快速增长，从2014年的6.06亿元猛增到2018年的56.3亿元，年复合增长率达到74.6%。其中，数据整合管理市场规模为29.7亿元，占比为52.8%。下图是医疗行业大数据应用的领域：
医疗大数据的潜在价值巨大，其应用有助于提高医疗服务质量、减少资源浪费、优化资源配置、控制骗保行为、改善自我健康管理等。
2 大数据在医疗行业的应用场景
目前，医疗大数据的应用场景主要包括临床决策支持、健康及慢病管理、支付和定价、医药研发、医疗管理等，服务对象涵盖居民、医疗服务机构、科研机构、医疗保险机构、公共健康管理部门等。
由于大数据在医疗管理、医疗研究等领域具有独特优势，越来越多医疗相关单位与大数据企业、医疗信息化公司合作，同时高等医学类院校也纷纷成立大数据研究院，尤其是2018年4月，某大学健康医疗大数据国家研究院在京成立，标志着医疗大数据在高校和医院联合研究方面走上了新的高度。
医疗行业在大数据世界中占比达30%以上，每年以48%的速度增长，是增速最快的行业之一，从2009年到2020年医疗数据增长了44倍，医疗行业数据呈PB级增长，一个三甲医院每年的医疗影像数据将增加数十TB,根据估算，一个中等城市50年累计的医疗数据量将达到10PB级。
3 医疗行业建设大数据项目取得的收益
医院数据，包括门诊收费、电子病历、检验检查数据和医学影像数据等，医疗机构健康医疗数据的互联互通和标准化入库，未来将逐步接入医疗保险数据、基因测序数据、健康智能设备数据和第三方健康管理机构数据等。医院建设大数据项目可提供众多人群的精准医疗数据服务，为临床决策与科研、基因测序、新药研发和健康管理等提供海量存储及大数据分析能力。
大数据极大提高了临床决策的科学性
大数据将极大提高医疗决策，特别是临床决策的科学性，主要包括用药分析、药品不良反应、疾病并发症、治疗疗效相关性分析、制定个性化治疗方案等，大数据分析技术将使临床决策支持系统更智能，通过挖掘医疗文献数据建立医疗专家数据库，从而给医生提出诊疗建议，提醒医生防止潜在的错误，减少和降低医疗事故率。
大数据能更好的服务于患者
大数据通过全面分析病人特征数据和疗效数据，然后比较多种干预措施的有效性，可以找到针对特定病人的最佳治疗途径。研究表明，对同一病人来说，医疗服务提供方不同，医疗护理方法和效果不同，成本上也存在很大差异。将有可能减少过度治疗，以及治疗不足。
大数据创新医疗行业需求开发
随着微博、微信、电商平台等媒介在PC端和移动端的创新和发展，公众分享信息变得更加便捷自由，而公众分享信息的主动性促使了网络评论这一形式的发展。微博、微信评论版上成千上亿的网络评论形成了交互性大数据，其中蕴藏了巨大的医疗行业需求开发价值，值得管理者重视。
作为医疗行业，如果能对网上医疗行业的评论数据进行收集，建立网评大数据库，然后再利用分词、聚类、情感分析了解消费者的消费行为、价值取向、评论中体现的新消费需求，以此来改进和创新产品，制订合理的价格及提高服务质量，从中获取更大的收益，只要医疗行业企业平时善于积累和运用自动化工具收集、挖掘、统计和分析这些数据，为我所用，都会有效地帮助自己提高市场竞争力和收益能力，赢得良好的效益。
4 医疗行业建设大数据项目面临的风险与应对措施
医疗数据安全关系到患者隐私、技术研发等重要、敏感领域，一旦发生数据泄露将对患者群体、社会稳定乃至国家安全造成严重影响。因此，做好医疗数据的安全防护与治理至关重要。
1、 临床研究数据安全风险。临床研究数据一般是指由医院、学术研究机构和医疗企业发起的，主要用于药物、医疗器械、医疗诊断的科学研究，所涉及的基本人口学资料、诊断信息、病例及患者报告等数据信息。参与临床研究的医患及有关信息，在通过专线、互联网线路等途径进行传输时，或是在医疗机构进行存储和使用等过程中，都面临着诸多数据安全风险。另外还存在远程医疗数据安全和医疗中心数据安全问题，针对这些问题需要从多方面进行管控：
1) 包括医疗健康大数据在使用的过程中，涉及到个人隐私数据的分析利用、流通等都应受到严格管控，无论从个人角度还是使用者角度，都需要获得授权许可。
2) 构建以患者为中心的医疗数据安全防护体系。现有的隐私安全防护，大多只是注重脱敏和匿名保护，不是全方位体系。需要加强构建以患者为中心的个人医疗信息风险评估和防护体系，覆盖信息录入、个人隐私管理、加密存储、访问控制等多个环节。
3) 加强个人信息保护立法。一方面，公民要有充分认知，应当学会对自身隐私的保护。另一方面，对违法行为要有足够的惩治，打击个人信息的不当泄露和非法利用。
2、医疗数据标准化建设是医疗大数据建设的基础工作，为了使大数据建设更好的满足临床业务和为患者服务的需求，实现数据统一的标准化和规范化。医疗数据标准化建设过程中遇到以下风险和难点内容，分享给大家：1)数据标准化涉及多个应用系统，协调接口改造进度和接口质量把控难度大，需要协调好院方确认改造的接口双方签字后执行。2)数据标准化以消息方系统为建设起点，收集各消息方系统对数据标准化需求，先建立数据基本集和预留部分扩充字段，避免接口改造反复修改，提高接口稳定性；3)数据标准化确认业务流程，通知相关科室维护数据要求，给出必填字段及业务流程，以免维护数据错误或空缺而影响消息系统数据问题。
5 医疗行业建设大数据项目技术路线的选择
大数据系统最基本的组件是处理框架，处理框架和处理引擎负责对数据系统中的数据进行计算，依据所要处理的数据类型和数据状态分类，一些系统可以用批处理方式处理数据，一些系统可以用流方式处理连续不断流入系统的数据，另外还有一些系统可以同时处理这两类数据。下面是流处理与批处理的对比图：
Apache Hadoop是一种专用于批处理的处理框架。Apache Hadoop及其MapReduce处理引擎最适合处理对时间要求不高的非常大规模数据集。通过非常低成本的组件即可搭建完整功能的Hadoop集群，使得这一廉价且高效的处理技术可以灵活应用在很多案例中。
Apache Storm是一种侧重于极低延迟的流处理框架，也许是要求近实时处理的工作负载的最佳选择。该技术可处理非常大量的数据，通过比其他解决方案更低的延迟提供结果。
Apache Samza是一种与Apache Kafka消息系统紧密绑定的流处理框架。虽然Kafka可用于很多流处理系统，但按照设计，Samza可以更好地发挥Kafka独特的架构优势和保障。该技术可通过Kafka提供容错、缓冲，以及状态存储。
Apache Flink是一种可以处理批处理任务的流处理框架。该技术可将批处理数据视作具备有限边界的数据流，借此将批处理任务作为流处理的子集加以处理。Flink是一个新兴的项目存在一定的局限性。
Apache Spark是一种包含流处理能力的下一代批处理框架。与Hadoop的MapReduce引擎基于各种相同原则开发而来的Spark主要侧重于通过完善的内存计算和处理优化机制加快批处理工作负载的运行速度。Spark是多样化工作负载处理任务的最佳选择。Spark批处理能力以更高内存占用为代价提供了无与伦比的速度优势。对于重视吞吐率而非延迟的工作负载，则比较适合使用Spark
Streaming作为流处理解决方案。
经过对几种大数据处理框架和处理引擎的比较，结合医院现有应用系统的建设情况和数据量的规模以及数据类型的复杂度（医疗数据包括结构化和非结构化还有半结构化数据，数据类型多种多样，有的数据适合批处理，而有的数据适合流处理），所以选用开源大数据架构的Apache
Spark建设医院大数据分析平台。
上面是Hadoop和Spark的处理性能对比图，从图中可以看出排序100TB的数据（1万亿条数据），Spark只用了Hadoop所用1/10的计算资源，耗时只有Hadoop的1/3。
Hadoop的处理引擎MapReduce只提供两个操作Map和Reduce，表达力欠缺；一个Job只有Map和Reduce两个阶段无法满足复杂的计算需要，Job之间的依赖关系是由开发者自己管理的；ReduceTask需要等待所有MapTask都完成后才可以开始，时延高只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够。因此MapReduce效率相对较低，所以我们选择更有效率，速度更快的内存级计算的Spark来构建医疗大数据分析平台。
Spark的优势不仅体现在性能提升上的，Spark框架为批处理，交互式，流式，机器学习，图计算提供了统一的数据处理平台，这相对于使用Hadoop有很大优势。
提到Spark不得说一下RDD，RDD（Resilient Distributed Dataset），RDD就是一个不可变的带分区的记录集合，RDD也是Spark中的编程模型。Spark提供了RDD上的两类操作，转换和动作。转换是用来定义一个新的RDD包括map,
flatMap, filter等，动作是返回一个结果包括collect, reduce等。
Spark基于RDD的抽象，实现数据处理逻辑的代码非常简短；提供很多转换和动作，很多基本操作如Join，GroupBy已经在RDD转换和动作中实现；一个Job可以包含RDD的多个转换操作，在调度时可以生成多个阶段（Stage），而且如果多个map操作的RDD的分区不变，是可以放在同一个Task中进行；中间结果放在内存中，内存放不下了会写入本地磁盘；通过将流拆成小的batch提供Discretized
Stream处理流数据。
医疗行业数据量非常大，每日增量数据也很大，数据类型复杂，选择通用性更强、运算效率更高的Spark架构来构建医疗大数据分析平台，可以更好的服务于医疗行业、服务于患者。
6 医疗行业建设大数据项目的技术难点与解决办法
本项目以卫健委给出的医院信息化建设的要求和相关数据模型为基础，结合医院的业务流程对现有业务进行梳理，确定业务中的问题形成总体设计；制定数据标准、接口标准、消息标准、文档标准和服务标准；根据总体设计和标准规范同步进行大数据平台实施。
本项目基于患者就诊过程建立模型，该模型是从患者入院到出院过程中所产生的相关数据，主要包括患者的检查信息，图像序列表的生成，系统图像记录，患者特征数据、病种数据、治疗方案与费用数据、治疗状态数据及在该过程中产生的管理类数据。
1) 患者特征数据：患者特征数据主要有现病史、检查检验类数据。涵盖了疾病的主要症状、体征、发病过程、检查、诊断、治疗及既往疾病信息、不良嗜好甚至职业。
2) 病种数据：即患者疾病的诊断结果，一般有第一诊断、第二诊断、第三诊断等。目前使用ICD-10进行疾病的分类与编码
。
3) 治疗方案与费用数据:根据诊断结果为患者提供的治疗方案与费用数据主要包括药品、检查、检验、手术、护理、治疗6大类，此外费用数据还有材料费、床位费、护理费、换药费用等。
4) 治疗状态数据:治疗状态数据即患者出院时的治疗结论，一般分为治愈、好转、未愈、死亡4类。
5) 管理类数据:除患者就医过程产生的服务于医院管理的数据外，还包括医院运营和管理系统中的数据，如物资系统、财务系统、绩效考核系统等产生的数据。
医疗大数据分析平台由数据获取、数据整合，数据加工和数据展现四个模块组成。医疗大数据处理模型如下图：
1) 数据获取：在这个阶段要回答以下几个问题，包括要收集哪些数据，哪些数据是对于战略性的决策或细节决策有帮助的，哪些数据分析出来的结果是有价值的，哪些数据得出的信息对于一个临床诊疗是有帮助，哪些数据能更好的实现辅助诊疗目标等。
2) 数据整合：为了得到更加精确的结果，在大数据分析的过程当中，数据整合是关键的环节，数据整合是将从医院信息平台抽取的业务数据按照统一的存储和定义进行集成。医院信息化经过多年的发展，积累了很多基础性和零散的业务数据。但是数据分散在临床、辅助、管理等不同部门，致使数据查询访问困难，医院管理层人员无法直接查阅数据和对数据进行分析利用，数据整合需要综合不同格式、不同业务系统的数据。
3) 数据加工：医院原有的业务数据必须经过标准化处理后才能够迁入大数据平台。由于医院的大数据来自各个不同的业务系统，数据格式和标准不统一，很难对数据进行统一的管理和利用。一般大数据平台的建设都会针对结构化和非结构化数据建立不同的主索引数据，然后对源数据进行清洗后导入数据集。拥有或创造一个干净、结构良好的数据集是必须的。使用数据清洗软件工具可以帮助细化数据并将其重塑为可用的数据集。
4) 数据展现：数据展现即数据可视化，为方便医护人员、患者和管理人员理解和阅读数据，而采用相关技术按业务规则进行的数据转换。这就要求医院相关的业务规则都是已经确定好的，这些业务规则可以帮助数据分析员评估他们的工作，将数据进行分析得出有价值的结果。
医疗大数据项目建设过程中的技术难点：
数据标准化是数据采集和数据分析的基础，医院在信息化建设过程中缺乏通用的数据标准、技术标准、管理标准和业务标准，未形成标准化的底层信息架构。在进行数据采集之前首先要对医院现有数据按以下标准进行归类、抽取、整合、为第二阶段的数据加工提供标准化的数据。
医疗大数据标准化与整合。将不同科室，不同业务系统的非结构化、零乱的数据整合成有利用价值的数据；对大数据进行过滤，设计脏数据过滤规则；数据一致性检查，无效值和缺失值处理。在医疗大数据的应用的同时，还存在数据的抽取、存储、清洗、整合、挖掘、分析、展现等问题需要解决。
下图是进行数据分析的步骤：
第一步从整体上对所要进行数据分析的对像进行设计，第二次从技术实现细节上对数据分析对像进行实现。
将原始数据转化为中间数据，因为海量的原始数据是没有清洗的非结构化数据，因此需要用HDFS进行存储，使用Spark进行清洗压缩编码，得到结构化的中间数据，中间数据是进行数据分析的目标数据，中间数据在量上比原始数据要小，但单机仍然难以处理，因此要用HDFS存储，用Spark/Hive进行进一步处理，得到小数据后在进行建模、分析，并将分析结果可视化。
要确保医疗大数据利用过程中，不被外界窃取和修改，要建立相应的数据加密技术和数据访问授权机制等。数据加密采用ssl
vpn技术加密，保障数据的传输安全和内容安全，数据的访问要实现双因子认证，帐号密码加专用密钥的方式。
7 大数据平台的系统与功能测试
测试验收的目的和挑战：
系统测试验收是一个项目实施结束的标志，系统测试验收完成后项目从实施阶段进入维保阶段，测试建设完工的医疗大数据平台在建设目标和功能上是否满足要求，测试验收的内容包括：功能项测试、业务流程测试、容错测试、安全性测试、性能测试、易用性测试、适应性测试和文档测试，测试验收按国家标准要求和规范进行，对测试没有通过的内容需按国家标准要求进行整改，整改后再测试直到完全通过测试验收为止。
测试验收参考方案：
验收标准包括 《GB/T 16260-1996 信息技术/软件产品评价/质量特性及其使用指南》，《GB/T
17544-1998软件包质量要求和测试》，《GB/T 15532-2008 计算机软件测试规范》。
验收项目：
A）系统功能项测试： 对软件需求规格说明书中的所有功能项进行测试。
B）系统业务流程测试： 对软件项目的典型业务流程进行测试。
C）系统容错测试的检测内容包括：
1） 软件对用户常见的误操作是否能进行提示；
2） 软件对用户的操作错误和软件错误，是否有准确、清晰的提示；
3） 软件对重要数据的删除是否有警告和确认提示；
4） 软件是否能判断数据的有效性，屏蔽用户的错误输入，识别非法值，并有相应的错误提示。
D）系统安全性测试的检测内容包括：
1）软件中的密钥是否以密文方式存储；
2）软件是否有留痕功能，即是否保存有用户的操作日志；
3）软件中各种用户的权限分配是否合理；
E）系统性能测试： 对软件需求规格说明书中明确的软件性能进行测试，测试的准则是要满足规格说明书中的各项性能指标。
F）系统易用性测试内容包括：
1）软件的用户界面是否友好，是否出现中英文混杂的界面；
2）软件中的提示信息是否清楚，易理解，是否存在原始的英文提示；
3）软件中各个模块的界面风格是否一致；
4）软件中的查询结果的输出方式是否比较直观，合理，并且能支持多种输出保存格式。
G）系统适应性测试： 参照用户的软、硬件使用环境和需求规格说明书中的规定，列出开发的软件需要满足的软、硬件环境，对每个环境进行测试。
H）系统文档测试：
用户文档包括：安装手册、操作手册和维护手册，对用户文档测试的内容包括：
1) 操作、维护文档是否齐全、是否包含产品使用的信息和所有的功能模块；
2) 用户文档是否容易理解，是否使用适当的术语，图形表示，详细解释来表达
3) 用户文档描述的信息是否正确，是否没有歧义和错误的表达；
4) 用户文档对主要功能和关键操作是否提供应用实例；
5) 用户文档是否有详细的目录表和索引表；
到此，以上系统测试验收要求全部满足，系统测试验收完成。
8 医疗行业实施大数据项目日常运维方案
医疗大数据项目经过系统试运行和最终验收后就进入运维阶段了， 项目所涉及到的硬件设备按厂商的规定进行保修（一般是三年）、软件产品按合同约定进行保修。
场景描述： 此次大数据项目的实施包括基于spark开发的医疗大数据分析系统，以及为大数据分析系统做支撑的服务器、存储、网络及安全设备等已经从实施进入运维阶段。
运维工作需求分析： 一流的运维服务体验来自于以用户服务为核心的策略，如何保障医疗大数据分析系统稳定的运行是运维工作的重点，经过与用户的沟通确定了如下的用户需求：
1． 提高运维工作效率，运维的及时性，准确性。
2． 运维人员绩效考核，有利于提高运维工作效率，有利于运维工作的创新，有利于提高工作的积极性和主动性。
3． 巡检是运维工作的日常内容。确认设备的巡检周期，建立并执行应用系统巡检制度，制定巡检工作流程单，按流程按时按要求对设备进行巡检。
运维方案的制定： 运维方案包括组织架构，运维要求，运维方式，管理制度共四个方面。
组织架构： 以总经理牵头，下设运营部、市场部和技术部；在运营部下设人事、行政、商务、采购、财务等部门；在市场部下设销售部、市场部、产品部和客服部；在技术部下设系统集成部、运维管理部、售前方案部等部门。
运维要求： 根据出现问题的紧急程度，确定非常严重、严重和一般三个等级。根据问题的紧急程度确认响应时间，2个小时以内、4小时以内、8小时以内，
运维支持的方式包括现场支持、电话邮件支持和远程协助支持。
运维方式： 根据运维工作的需求和运维响应时间要求决定建设完整的运维计划并确定服务的标准，以现场软硬件巡检为主，增强运维计划的执行力，下面是运维工作流程：
建设完整的运维计划：在整个运维过程中，计划是整个工作流程的核心，按照计划先行的原则，依据本年度工作计划制定分项工作计划和时间维度计划，并按流程、按计划进行实施和保障。
现场巡检的重要性：现场巡检计划是运维工作计划的重点，通过现场巡检能够发现系统薄弱环节、关键业务节点、存在的隐患，尤其是对制定应急预案及备品备件计划至关重要。
执行力的重要性：运维计划的执行是运维工作的重点，在运维计划执行过程中，应严格按照流程规范开展运维，并注重控制以降低运维风险。针对运维执行情况，应定期向用户进行反馈。
服务标准：签订售后服务承诺函与用户约定服务级别，对于所承诺的服务级别包括提供的资源（备品和备件等）、提供的方案应严格按约定执行；
管理制度： 包括运维工作流程管理，机房环境巡检制度，服务器、存储、网络及安全设备等巡检制度，应用系统巡检制度等相关内容。
9 医疗行业实施大数据项目易踩到的坑以及处理办法
在医院大数据系统实施的过程中出现了以下错误及处理办法在此处做一个总结仅供大家参考。
1、spark thriftserver报以下错误，其他诸如hive/sparksql等方式均正常
ERROR ActorSystemImpl: Uncaught fatal error from
thread [sparkDriverActorSystem-akka.actor.default-dispatcher-379]
shutting down ActorSystem [sparkDriverActorSystem]
java.lang.OutOfMemoryError: Java heap space
原因：thriftserver的堆内存不足
解决办法：重启thriftserver，并调大executor-memory内存（不能超过spark总剩余内存，如超过，可调大spark-env.sh中的SPARK_WORKER_MEMORY参数，并重启spark集群。
start-thriftserver.sh --master spark://masterip:7077
--executor-memory 2g --total-executor-cores 4 --executor-cores
1 --hiveconf hive.server2.thrift.port=10050 --conf
spark.dynamicAllocation.enabled=false
如果调大了executor的内存,依旧报此错误,仔细分析发现应该不是executor内存不足,而是driver内存不足,在standalone模式下默认给driver
1G内存,当我们提交应用启动driver时,如果读取数据太大,driver就可能报内存不足。在spark-defaults.conf中调大driver参数
spark.driver.memory 2g 同时在spark-env.sh中同样设置 export
SPARK_DRIVER_MEMORY=2g
2、Caused by: java.lang.OutOfMemoryError: GC overhead
limit exceeded**** JDK6新增错误类型。当GC为释放很小空间占用大量时间时抛出。在JVM中增加该选项
-XX:-UseGCOverheadLimit 关闭限制GC的运行时间（默认启用 ） 在spark-defaults.conf中增加以下参数
spark.executor.extraJavaOptions -XX:-UseGCOverheadLimit
spark.driver.extraJavaOptions -XX:-UseGCOverheadLimit
3、spark 错误描述：org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.ipc.StandbyException):
Operation category READ is not supported in state
standby 原因：NN主从切换时,spark报上述错误,经分析spark-defaults.conf配置参数spark.eventLog.dir写死了其中一个NN的IP,导致主从切换时，无法读日志。另外，跟应用程序使用的checkpoint也有关系,首次启动应用程序时,创建了一个新的sparkcontext,而该sparkcontext绑定了具体的NN
ip, 往后每次程序重启,由于应用代码【StreamingContext.getOrCreate(checkpointDirectory,
functionToCreateContext _)】将从已有checkpoint目录导入checkpoint
数据来重新创建 StreamingContext 实例。如果 checkpointDirectory
存在，那么 context 将导入 checkpoint 数据。如果目录不存在，函数 functionToCreateContext
将被调用并创建新的 context。故出现上述异常。解决办法：
1、将某个NN固定IP改成nameservice对应的值
2、清空应用程序的checkpoint日志 3、重启应用后,切换NN,spark应用正常
4、获取每次内存GC信息
spark-defaults.conf中增加：
spark.executor.extraJavaOptions -XX:+PrintGC -XX:+PrintGCDetails
-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime
-XX:+PrintHeapAtGC -XX:+PrintGCApplicationConcurrentTime
-Xloggc:gc.log
5、timeout,报错：
17/10/18 17:33:46 WARN TaskSetManager: Lost task
1393.0 in stage 382.0 (TID 223626, test-ssps-s-04):
ExecutorLostFailure (executor 0 exited caused by one
of the running tasks)
Reason:Executor heartbeat timed out after 173568
ms
17/10/18 17:34:02 WARN NettyRpcEndpointRef: Error
sending message [message = KillExecutors(app-20171017115441-0012,List(8))]
in 2 attempts
org.apache.spark.rpc.RpcTimeoutException: Futures
timed out after [120 seconds]. This timeout is controlled
by spark.rpc.askTimeout
at org.apache.spark.rpc.RpcTimeout.org$apache$spark$rpc$RpcTimeout$$createRpcTimeoutException(RpcTimeout.scala:48)
网络或gc引起,worker或executor没接收到executor或task的心跳反馈。
提高 spark.network.timeout 的值，根据情况改成300(5min)或更高。
默认为 120(120s),配置所有网络传输的延时
spark.network.timeout 300000
6、通过sparkthriftserver读取lzo文件报错：
ClassNotFoundException: Class com.hadoop.compression.lzo.LzoCodec
not found
在spark-env.sh中增加如下配置：
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/hadoop/hadoop-2.2.0/lib/native
export SPARK_LIBRARY_PATH=$SPARK_LIBRARY_PATH:/home/hadoop/hadoop-2.2.0/lib/native
export SPARK_CLASSPATH=$SPARK_CLASSPATH:/home/hadoop/hadoop-2.2.0/share/hadoop/yarn/:/home/hadoop/hadoop-2.2.0/share/hadoop/yarn/lib/:/home/hadoop/hadoop-2.2.0/share/hadoop/common/:/home/hadoop/hadoop-2.2.0/share/hadoop/common/lib/:/home/hadoop/hadoop-2.2.0/share/hadoop/hdfs/:/home/hadoop/hadoop-2.2.0/share/hadoop/hdfs/lib/:/home/hadoop/hadoop-2.2.0/share/hadoop/mapreduce/:/home/hadoop/hadoop-2.2.0/share/hadoop/mapreduce/lib/:/home/hadoop/hadoop-2.2.0/share/hadoop/tools/lib/:/home/hadoop/spark-1.6.1-bin-2.2.0/lib/
并分发到各节点，重启spark thrift server执行正常
7、spark worker中发布executor频繁报错,陷入死循环（新建->失败->新建->失败.....）
work日志：
Asked to launch executor app-20171024225907-0018/77347
for org.apache.spark.sql.hive.thriftserver.HiveThriftServer2
worker.ExecutorRunner (Logging.scala:logInfo(58))
- Launch command: "/home/hadoop/jdk1.7.0_09/bin/java"
......
Executor app-20171024225907-0018/77345 finished with
state EXITED message Command exited with code 53 exitStatus
53
executor日志：
ERROR [main] storage.DiskBlockManager (Logging.scala:logError(95))
- Failed to create local dir in . Ignoring this directory.
java.io.IOException: Failed to create a temp directory
(under ) after 10 attempts!
再看配置文件spark-env.sh：
export SPARK_LOCAL_DIRS=/data/spark/data
设置了spark本地目录，但机器上并没有创建该目录，所以引发错误。
./drun "mkdir -p /data/spark/data"
./drun "chown -R hadoop:hadoop /data/spark"
创建后，重启worker未再出现错误。
8、spark worker异常退出：
worker中日志：
17/10/25 11:59:58 INFO worker.Worker: Master with
url spark://10.10.10.82:7077 requested this worker
to reconnect.
17/10/25 11:59:58 INFO worker.Worker: Not spawning
another attempt to register with the master, since
there is an attempt scheduled already.
17/10/25 11:59:59 INFO worker.Worker: Successfully
registered with master spark://10.10.10.82:7077
17/10/25 12:00:05 INFO worker.ExecutorRunner: Killing
process!
17/10/25 12:00:05 INFO util.ShutdownHookManager:
Shutdown hook called
17/10/25 12:00:06 INFO util.ShutdownHookManager:
Deleting directory /data/spark/data/spark-ab442bb5-62e6-4567-bc7c-8d00534ba1a3
近期，频繁出现worker异常退出情况，从worker日志看到，master要求重新连接并注册，注册后，worker继续连接master,并反馈了一个错误信息：
ERROR worker.Worker: Worker registration failed:
Duplicate worker ID之后就突然杀掉所有Executor然后退出worker。
出现该问题的机器内存都是16g(其他32g节点,没有出现worker退出问题)。再查看该类节点yarn的
配置，发现分配yarn的资源是15g,怀疑问题节点yarn和spark同处高峰期，导致spark分配不到资源退出。
为查看问题时间点，节点中yarn资源使用情况，只能到active rm中查看rm日志，最后看到节点中在11:46:22到11:59:18，问题节点yarn占用资源一直在。如此，确实是该问题所致，将yarn资源调整至12g/10g,后续再继续观察没有发现此问题了。
总结
医疗行业通过实施大数据项目，可提供众多人群的精准医疗数据服务，为临床决策与科研、基因测序、新药研发和健康管理等提供海量存储及大数据分析能力。大数据分析技术使临床决策支持系统更智能，通过挖掘医疗文献数据建立医疗专家数据库，从而给医生提出诊疗建议，提醒医生防止潜在的错误，减少和降低医疗事故率。大数据通过全面分析病人特征数据和疗效数据，然后比较多种干预措施的有效性，减少过度治疗，以及治疗不足，找到针对特定病人的最佳治疗途径。
|
