大医疗数据背景下基于云架构的家庭诊断服务毕业论文(编辑修改稿)

大医疗数据背景下基于云架构的家庭诊断服务毕业论文(编辑修改稿)内容摘要：

提交 从形式上看，在我们的家庭诊断服务中，一次用户查询可以形式化为定义 3。 定义 3（用户查询）一次用户查询可以定义为一个三元组（基本信息，疾病症状）。 简化时，它可以被 Q=(BI, DS)替代。 在定义 3 中，基本信息是指病人的性别和年龄（即 {女性或男性 }， {儿童、成年人或老年人 }）。 疾病症状是指病人的症状名称。 示例（用户查询）用户查询可以是 =({性别 =女 ,年龄 =成人 },{症状 = {发烧、大医疗数据背景下基于云架构的家庭诊断服务 15 咳嗽 } })。 在收到用户查询时 ,负载平衡器根据其选择规则将查询转发到一个调度程序。 然后被选择的调度程序会利用算法 2，将用户查询转发到分布式搜索集群的N 个搜索节点。 医疗记录检索 给定一个包含一组症状的用户查询，每个搜索节点都会运行布隆签名过滤去检索同时出现“发烧”和“咳嗽”的医疗记录。 同时基本信息过滤也会运行以过滤一些男性的或非成年病人的记录。 （ 1） BF 签名过滤 如在第三节所讨论的 ,BF 签名采用加速症状匹配。 （ 1）用户查询中的每个症状是散列的 k 个值 是由 k 个散列函数 ,„ ,所确定的。 （ 2）把 m维向量中与那些离散值 相应的位置 1。 （ 3）通过个人数据签名，用户查询的布隆签名可以通过“ OR”操作计算出来。 （ 4）通过 iS ，在反向检索文件中的每个布隆签名 BFcR 会被扫描，并与 iS 比较。 如果 BFcR ∧ iS = iS ，那么在 jcRe 中记录的具体的症状会与 iQ 中记录的症状相比较以确保 jcRe 包含 iQ 中所有的症状。 （ 2）基本信息过滤 对于经过 BF 签名过滤的医疗记录，它的性别和年龄会与用户的性别年龄相比较，以过滤掉男性、老年人以及儿童患者。 从形式上看，算法 3 说明了医疗记录检索的执行过程。 算法 3 医疗数据检索算法 大医疗数据背景下基于云架构的家庭诊断服务 16 数据分析 通常，用户由于缺乏医疗知识，只能提供他 /她的一部分症状。 与 节的检索的医疗记录相联系，可能不止一种疾病满足用户的查询。 数据分析通过利用一种被称为形式概念分析（ FCA）的数学理论帮助用户分析这些可能的疾病分类的相似和不同点。 (Belohlavek and Vychodil, 20xx。 Wu et al., 20xx。 Crampes et al., 20xx).FCA 会被采用以显示具有相同症状的不同疾病分类之间的潜在关系。 更具体地说 ,疾病名称以及症状会从 节中获得的医疗记录中被提取。 然后 ,三个步骤会进行以分析具有相同症状的疾病之间的关系 ,即形式内容构建、形式概念 计算以及疾病症状点阵计算。 形式内容构建 定义 4（形式内容） 在家庭诊断服务中，形式内容是指疾病集合 E 和症状集合 F 之间的一个二进制的关系 R。 R⊂EF， R 表示 E 和 F 之间的关系。 (e, f) ∈ R (e∈ E, and f∈ F)表明疾病 e 有症状 f。 当集合是有限的，内容就可以通过一个交叉表来指定。 下面给了形式内容的一个例子。 示例（形式内容）表 3 中展示了一个简单的例子。 假设与 节搜索到的医疗记录相联系，疾病集合 E= {胸膜炎、结核、流感、肺炎 },而症状集合F= {发热、咳嗽、呼吸困难、胸痛、胸闷 ,盗汗 ,身体疼痛 }。 交叉表的行代表疾病，列代表症状，符号√代表的是一个症状是否适用于一种疾病的一种二进制关系。 表 3 家庭诊断服务形式概念的例子 形式概念计算 给定一个形式内容，形式概念就可以通过共同特征和公共实体的定义被计算。 定义 5（共同特征）给定一个疾病集合 EE39。 ,则集合 39。 E 的共同症状特征 CF可以被定义为： }),(,|f{)( 39。 39。 RfeEeFECF  大医疗数据背景下基于云架构的家庭诊断服务 17 定义 6（共同实体）类似的，给定一个症状集合 FF39。 ,则集合 39。 F 的共同疾病 CE 可以被定义为： }),(,|e{)( 39。 39。 RfeFfEFCF  例子（共同特征和共同实体）：在表 3 中，比如， CF({胸膜炎、肺炎 })= {发热、咳嗽、呼吸困难、胸痛 },和 CE({发烧、咳嗽 })= {胸膜炎、结核、流感、肺炎 }。 根据定义 5 和定义 6，疾病和相关的症状可以被归入有意义的集合。 这些集群被称为形式概念。 定义 7（形式概念）内容（ E,F,R）的形式概念可用一对 ),)(,( 39。 39。 39。 39。 FFEEFE 代替，其中 39。 39。 )( FECF  , 39。 39。 )( EFCE 。 而且，在 ),( 39。 39。 FE 概念中， 39。 E 被称为概念的范围， 39。 F 被称为概念的目的。 换句话说，在 ),( 39。 39。 FE 概念中， 39。 F 症状集所共有的疾病集合是 39。 E ，而 39。 E 疾病集所共有的症状集合是 39。 F。 示例（形式概念）比如，表 3 中的 ({胸膜炎、结核、流感、肺炎 },{咳嗽、发烧 })是一个形式概念。 因为 {咳嗽、发烧 }是 {胸膜炎、结核、流感、肺炎 }的共同症状。 并且 {发烧、咳嗽 }在 {胸膜炎、结核、流感、肺炎 } 中都会出现。 此外 ,{胸膜炎、结核、流感、肺炎 }是程度的集合。 {发烧、咳嗽 }是唯一的现象。 另外 ,({肺炎、胸膜炎 },{咳嗽、发热、胸痛、呼吸困难 })是这种情况下的另一个概念。 疾病症状点阵计算 为了使得 节中计算得到的形式概念的层次关系可视化，一个偏序的关系揭示了具有相同症状的疾病之间的关 系和其底层结构。 定义 8（不等式关系）对于所有的形式内容（ E,F,R）中的概念，一个不等式关系“  ” 可 以 被 定 义 在 形 式 内 容 的 概 念 上。 特 别 的 ，jijjii FEFEFE  ),(),(。 示例（不等关系）在表 3 中的形式概念中， ({胸膜炎 },{咳嗽、发热、胸痛、呼吸困难、胸闷 }) ({肺炎、胸膜炎 },{咳嗽、发热、胸痛、呼吸困难 })。 根据定义 8,{胸膜炎 }是 {肺炎、胸膜炎 }的一个子集 ,而 {咳嗽、发热、胸痛、呼吸困难 }也是 {咳嗽、发热、胸痛、呼吸困难、胸闷 }的一个子集。 此外，部分排序可以被认为是 subsuper 关系。 根据这个 subsuper 关系排序 ,大医疗数据背景下基于云架构的家庭诊断服务 18 它通过在上下文的概念定义了一个完整的点阵。 而这个在本文中被称为疾病症状点阵。 它可以被哈斯图所代替。 图 8（ a）是一张哈斯表展示了表 3 中的内容的疾病症状点阵。 疾病症状点阵的节点代表了形式概念的潜在内容。 图 8 表 3 中的疾病症状点阵 有了疾病症状点阵，用户可以通过自上而下浏览点阵的每一个诊断路径获得自我诊断。 诊断路径示例是用红色突出显示在图 8(b)。 同时，与每个路径相联系的是相关的症状和诊断结果，已用红色标出。 通过这个，用户可以区分可能的疾病并且判断他 /她可能感染了哪一种疾病。 在用户查询的例子中 ,用户查询症状“发烧”和“咳嗽” ,有 4 个匹配这些症状 (如疾病、胸膜炎、结核、流感和肺炎 )。 然后他 /她就可以检查每一个标识了“发烧”和“咳嗽”的诊断路径以查看是否有其他有用的症状来区分这些可能的疾病。 例如 ,流感和肺炎都有“发烧”和“咳嗽”症状。 而“胸痛” ,“呼吸困难”和“身体疼痛”症状 ,可以用来区分两种疾病。 作为总结，家庭诊断服务的数据分析可以用算法 4 来描述。 大医疗数据背景下基于云架构的家庭诊断服务 19 算法 4 家庭诊断服务的数据分析算法 返回结果中的隐私信息过滤 为了帮助用户对他 /她的疾病有更详细的信息 ,我们认为 ,每个疾病关联的医疗记录也应该呈现给目标用户。 然而 ,医疗记录是隐私数据 ,这是受法律保护的。 因此 ,类似的医疗记录返回到目标用户之前，超出了目标用户的访问权限的隐私敏感信息应该被过滤 ,避免曝光病人的隐私。 根据节点选择算法和 节中讨论的访问控制策略 ,隐私信息过滤过程包括三个主要步骤。 (1)具有最小的服务错误率值得访问控制节点被选中并通过利用节点选择算法来进行隐私信息的过滤。 （ 2）从 调度程序收到查询以后，访问控制节点会访问本地索引文件。 通过目标用户的 ID，在用户访问权限内用户域和相联系的动态域就可以获得。 根据访问控制策略，细节索引文件的与用户相关的用户域中的静态域是不可访问的。 因此，在用户访问权限内的动态域的会被返回给调度程序。 （ 3）最后，调度程序会把细节索引文件中的动态域的信息返回给目标用户。 通过这些，隐私敏感信息就不会曝光给目标用户。 大医疗数据背景下基于云架构的家庭诊断服务 20 5 评价 在这个部分，一个原型系统会被设计而且一个运行示例会演示我们的提案的可扩展性和效率。 具体来说，基于 Lucene 的分布式搜索集群是通过一系列实验尝试来评价的。 此外，为了更好地证明家庭诊断服务为目标用户提供了诊断的依据，我们将讨论一个运行示例。 原型系统设计 目前，我们实现了一个基于云计算框架的家庭诊断服务。 原型系统的配置已经列在表 4 中。 表 4 基于云架构原型系统的配置 对于基于云计算的框架，一个私有的 Hadoop 集群被用于离线数据存储（即Lucene 文件和索引文件）和索引构建。 一个基于 Lucene 的分布式搜索集群是由21 台 PC 部署在一起实现在线用户查询处理的功能。 此外，我们用从连云港一家医院的呼吸医学部门 的 100 个医疗记录作为我们原型实现的数据集。 医疗记录被存储为 XML 文档。 图 9 描述了原型框架。 图 9 原型系统设计的框架 大医疗数据背景下基于云架构的家庭诊断服务 21 在图 9 中 ,Hadoop 集群由 18 节点 (一个主节点和 17 个从节点 )。 每个节点配置了两个英特尔 (R)四核 E5620 工作在 GHz 的至强处理器 (R)和 24 GB RAM。 主节点 ,装有 2TB 的磁盘。 而对于每个从节点 ,都配有两个 2TB 的磁盘。 集群是在红帽企业的 linux 服务器 ， java 和 (Apache Hadoop, 20xx)的环境 下运行的。 而对于搜索集群 ,21 台个人电脑是在 Ubuntu ,Java 和 环境下部署的以运行在线用户查询处理。 此外 ,搜索节点集群由18 个人电脑组成一个 3 * 6 搜索矩阵形式。 其他 3 个人电脑是用来实现一个调度集群、数据分析集群以及集群访问控制的功能。 每个电脑配置了 2 个英特尔 E5400 GHz的处理器，有 2 GB内存。 所有的方法都是在 Java 中实现。 标准的 Hadoop MapReduce API 以及 Lucene API 相应地在索引构建和在线用户查询处理中被采用。 性能分析 在本节中，我们设计了 2 个测试用例对我们的提案进行性能测试。 不失一般性，相对于搜索节点集群的大小，我们研究了基于云计算框架的可扩展性。 我们对 节提到的 100 个医疗记录做了 1000 万个副本。 每个医疗记录的大小是 ，总的大小是 14GB。 把医疗记录转换为 Lucene 文档后， Lucene文档的大小也是 14GB。 Lucene 文档作为块文件被存储在 Hadoop 集群的 HDFS中。 索引构建阶段以后，就可以获得三种索引文件。 此外 ,新的 PFD 压缩机 (Yan et al .,20xx。 Ao et al .,20xx)被用于反向索引压缩。 而概要索引文件和详细的索引文件被谷歌的 snappy 压缩机压缩 (Arroyuelo et al .,20xx)。 压缩后 ,索引文件的总大小是 GB。 对于在线病历检索 ,每个索引文件被分为 N 个碎片 (N 是搜索节点集群每一行的搜索节点的数量 )。 每一行的第 i个 (1≤ i≤ N)搜索节点包含第 i个 (1≤ i≤ N)索引碎片。 （ 1）相对于 N 值的性能 表 5 性能关于 N 的测 大医疗数据背景下基于云架构的家庭诊断服务 22 在第一个测试用例中， M 为定值 1。 我们进行 5 次试验来评价搜索节点集群相对于不同 N 值时候的性能。 （相应地， N 为 1,2,3,4,5）每次试验中，我们模拟最初在客户端有两个并发的进程持续发送 50000 次查询给调度程序。 此外，第 i次试验中，第 i个搜索节点会被初始化来进行医疗记录检索。 平均延时， CPU 的利用率和 I/O 口的等待时间会被记录。 在表 5 中，我们可以发现 ,当 N≤3,平均延迟和 I/O 等待会随着 n 的增加显著。