大數(shù)據(jù)技術(shù)在醫(yī)療健康管理的應(yīng)用與設(shè)計

蔡全福

（廈門城市職業(yè)學(xué)院，福建 廈門 361008）

1 引言

大數(shù)據(jù)技術(shù)為醫(yī)療健康行業(yè)的發(fā)展帶來無限可能，健康數(shù)據(jù)的不斷積累，為大數(shù)據(jù)分析創(chuàng)造了條件。醫(yī)療健康信息包含大量數(shù)據(jù)，需要對這些數(shù)據(jù)進行分析處理，從而獲得有用的信息。Hadoop是分布式系統(tǒng)架構(gòu)[1]，用戶不需要了解分布式系統(tǒng)內(nèi)部細節(jié)，就能夠?qū)?shù)據(jù)進行分布式處理，其數(shù)據(jù)處理具有可靠、高效、可伸縮的特點，使得用戶可以輕松地在Hadoop上開發(fā)和運行處理海量數(shù)據(jù)。MapReduce是對大規(guī)模數(shù)據(jù)集進行并行運算的編程模型，主要包含Map階段和Reduce階段，每個階段的輸入數(shù)據(jù)和輸出數(shù)據(jù)都是以鍵值對[2]的形式出現(xiàn)，Map階段是將一個任務(wù)分解成為多個任務(wù)，每個任務(wù)并行分析處理；Reduce階段是將Map處理后的結(jié)果進行統(tǒng)計匯總，得出最終計算結(jié)果。HBase[3]是模仿BigTable的開源項目，是一種分布式的、面向列的開源數(shù)據(jù)庫，更適合于非結(jié)構(gòu)化數(shù)據(jù)存儲，是支持實時讀寫的高性能分布式數(shù)據(jù)庫系統(tǒng)。

Hadoop利用其低成本實現(xiàn)對海量數(shù)據(jù)的分布式存儲和并行計算，為醫(yī)療業(yè)務(wù)提供了全新的方法。為了應(yīng)對大規(guī)模醫(yī)療健康數(shù)據(jù)的存儲與處理需求問題，基于Hadoop搭建醫(yī)療健康數(shù)據(jù)管理平臺，選用分布式數(shù)據(jù)庫系統(tǒng)HBase作為系統(tǒng)數(shù)據(jù)庫，設(shè)計健康數(shù)據(jù)的存儲格式，并利用MapReduce對數(shù)據(jù)進行分析處理，縮短海量數(shù)據(jù)計算時間，提高醫(yī)療健康數(shù)據(jù)管理的能力。

2 醫(yī)療健康數(shù)據(jù)存儲和整體架構(gòu)

2.1 醫(yī)療健康數(shù)據(jù)存儲

醫(yī)療健康數(shù)據(jù)通過數(shù)據(jù)采集終端設(shè)備獲取，并與服務(wù)器交互，服務(wù)器進行解析處理后得到實時數(shù)據(jù)。隨著時間的推移數(shù)據(jù)往往是大數(shù)量級，使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫存儲無法快速對整體數(shù)據(jù)進行處理，擴展性能差。當(dāng)對某一時間段的數(shù)據(jù)進行查詢時，面對海量數(shù)據(jù)，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫查詢效率無法滿足系統(tǒng)的需求。HBase是非關(guān)系型數(shù)據(jù)庫[4]，以列簇式存儲，查找速度快，可擴展性強，更容易進行分布式擴展。本研究之所以選擇以HBase作為數(shù)據(jù)庫，是由于HBase是Hadoop平臺的一部分，又能支持其他平臺如Pig、Hive等，能充分利用MapReduce進行高效數(shù)據(jù)處理，而其他非關(guān)系型數(shù)據(jù)庫即便在存儲上比較有優(yōu)勢，但數(shù)據(jù)處理能力遠不如HBase強。此外，HBase支持Shell腳本和Web頁面，而其他非關(guān)系型數(shù)據(jù)庫只有API，可用性不如HBase。HBase雖然具有較強的數(shù)據(jù)處理能力，但是HBase只適用于對RowKey毫秒級別的單一查詢，對多條件的復(fù)雜查詢無法支持，為了解決該問題，本文將HBase與Solr結(jié)合進行數(shù)據(jù)存儲[5]。Solr是一個獨立的企業(yè)級搜索應(yīng)用服務(wù)器，它對外提供API接口，Solr采用Java5開發(fā)，基于Lucene的全文搜索服務(wù)器具備更為高級的全文檢索能力，對各種數(shù)據(jù)類型提供強大的匹配功能，Solr提供支持多種編程語言的編程客戶端，用戶可通過客戶端直接與Solr進行交互，是一款非常優(yōu)秀的全文搜索引擎[6]。將醫(yī)療健康信息數(shù)據(jù)加工處理后存儲到分布式文件系統(tǒng)中，并對數(shù)據(jù)做唯一標(biāo)識，利用HBase與Solr結(jié)合建立快速索引，提高數(shù)據(jù)庫的讀寫性能，使得查詢效率提高。HBase和Solr相結(jié)合的索引流程如圖1所示，將HBase表中涉及條件查詢的字段和Rowkey在Solr中建立索引，通過Solr的多條件查詢快速獲得符合過濾條件的Rowkey值，獲取Rowkey之后在HBase中通過指定Rowkey進行查詢，從而得到查詢結(jié)果。

圖1 HBase與Solr相結(jié)合的索引流程圖

2.2 醫(yī)療健康數(shù)據(jù)管理模型整體架構(gòu)

本文提出基于Hadoop的醫(yī)療健康數(shù)據(jù)管理模型，以Hadoop構(gòu)建一個集群數(shù)據(jù)中心。醫(yī)療健康數(shù)據(jù)管理模型包含數(shù)據(jù)實時上傳、數(shù)據(jù)存儲管理、數(shù)據(jù)查詢分析功能。模型總體框架圖如圖2所示。

圖2 模型總體框架圖

醫(yī)療健康數(shù)據(jù)管理模型的數(shù)據(jù)上傳功能主要包括各種終端設(shè)備，采集的數(shù)據(jù)包括姓名、性別、身高、體重、心率等信息，終端設(shè)備通過GPRS、WIFI網(wǎng)絡(luò)傳輸用戶健康信息到服務(wù)器實現(xiàn)交互。集群中心由分布式文件系統(tǒng)HDFS、分布式數(shù)據(jù)庫HBase、并行計算MapReduce組成和數(shù)據(jù)庫管理組件構(gòu)成。HDFS存儲非結(jié)構(gòu)化數(shù)據(jù)文件，HBase存儲健康數(shù)據(jù)和運行數(shù)據(jù)，并行計算MapReduce提供高效和高性能的計算方法，數(shù)據(jù)庫管理組件維護數(shù)據(jù)的一致性以及為數(shù)據(jù)查詢、存儲提供服務(wù)。通過集群中心分析計算獲得對用戶有用的信息，從而為醫(yī)療健康作出決策參考。

3 基于Hadoop醫(yī)療健康數(shù)據(jù)管理模型設(shè)計與實現(xiàn)

3.1 醫(yī)療健康數(shù)據(jù)HBase數(shù)據(jù)庫的設(shè)計

醫(yī)療健康數(shù)據(jù)需要多次頻繁寫入并實時讀取，Hadoop中的HDFS主要適用于一次寫入多次讀出的數(shù)據(jù)，直接利用HDFS存儲延遲性高，不能高效對數(shù)據(jù)進行管理。選用實時讀寫能力強、低延遲的分布式數(shù)據(jù)庫系統(tǒng)HBase，結(jié)合Hadoop強大的數(shù)據(jù)并行處理編程模型MapReduce對醫(yī)療健康數(shù)據(jù)進行分析處理，并能對醫(yī)療健康數(shù)據(jù)進行更高效的管理。傳統(tǒng)數(shù)據(jù)庫是以數(shù)據(jù)塊來存儲數(shù)據(jù)，當(dāng)表字段越多時，占用的空間將增加，使得查詢速度變慢，而且數(shù)據(jù)可伸縮性差，傳統(tǒng)數(shù)據(jù)庫需要添加中間層才能實現(xiàn)硬件的擴充。而HBase是基于列存儲，按照列存儲的每個字段數(shù)據(jù)聚集存儲，對同列中的數(shù)據(jù)查詢效率較高，可以動態(tài)添加，當(dāng)列為空時不存儲數(shù)據(jù)，能節(jié)省空間，HBase對存儲的數(shù)據(jù)自動切分，能實現(xiàn)高并發(fā)讀寫的操作，使得其可擴充性強，適合用于海量數(shù)據(jù)存儲。HBase是基于列存儲的數(shù)據(jù)庫，由列簇將數(shù)據(jù)表屬性列分割[7]。Rowkey用于查詢記錄的主鍵，在HBase數(shù)據(jù)存儲中，數(shù)據(jù)是按Rowkey順序排列。HBase中每一列都屬于Column Family，列名以ColumnFamily作為前綴，修飾符作為后綴的格式組成。HBase通過Rowkey和列確定的存儲單元稱為Cell，每個Cell中存儲多份數(shù)據(jù)版本，每個數(shù)據(jù)版本的查詢是通過時間戳TimeStamp，每個數(shù)據(jù)具有唯一的時間戳，按照倒序的順序，使最新數(shù)據(jù)排在最前面。醫(yī)療健康數(shù)據(jù)管理模型HBase數(shù)據(jù)庫設(shè)計的如表1所示。醫(yī)療健康數(shù)據(jù)包含很多屬性特征，如姓名、性別、身高，體重等，根據(jù)數(shù)據(jù)特征，HBase表設(shè)計為多行多列的模型，即每個RowKey中有多個ColumnFamily，每個ColumnFamily又包含多個 Column Qualifier，Column Qualifier是不同時間所對應(yīng)的值。

表1 醫(yī)療健康HBase數(shù)據(jù)庫表

3.2 醫(yī)療健康數(shù)據(jù)寫入HBase

將現(xiàn)有文件中的數(shù)據(jù)寫入到HBase中，一般有三種方法實現(xiàn)：使用HBase的Java API中的put方法、使用HBase的bulk load工具以及使用MapReduce Job方法。Put方法是最直接方法，但是對海量數(shù)據(jù)寫入到HBase時，效率較低。bulk load工具支持海量文本數(shù)據(jù)高效地載入HBase中，但是對于非固定格式的數(shù)據(jù)載入支持較差，不利于擴展。MapReduce是處理海量數(shù)據(jù)最有效的方式。這也是HBase中加載海量數(shù)據(jù)可行的方法。根據(jù)醫(yī)療健康數(shù)據(jù)的特性，這里選用MapReduce Job方法將數(shù)據(jù)寫入HBase中。HBase提供TableOutputFormat用于在MapReduce Job中向HBase的表中寫入數(shù)據(jù)，寫入過程如圖3所示。要運行MapReduce Job，首先在createSubmittableJob()方法中創(chuàng)建一個Job實例，對其設(shè)置了輸入路徑、輸入格式以及mapper類。調(diào)用TableMapReduceUtil.initTableReducerJob()對 Job 實例進行配置，設(shè)置HBase和TableOutputFormat以及添加運行需要的jar依賴包。調(diào)用job.waitForCompletion()將Job提交到MapReduce框架中，運行的Job實例將會讀取輸入路徑下的所有文件，并且將每行都傳入到mapper類。在mapper類中，轉(zhuǎn)換行數(shù)據(jù)并生成RowKey，建立Put對象，通過 Put.add()方法將轉(zhuǎn)換后的數(shù)據(jù)添加到對應(yīng)的列中。最終調(diào)用context.write()方法將數(shù)據(jù)寫入HBase表中。

圖3 數(shù)據(jù)寫入HBase過程圖

3.3 醫(yī)療健康數(shù)據(jù)MapReduce查詢分析設(shè)計

設(shè)計醫(yī)療健康數(shù)據(jù)管理系統(tǒng)的目的是能夠?qū)】禂?shù)據(jù)進行管理，從數(shù)據(jù)庫中獲得有用的數(shù)據(jù)。利用MapReduce強大的運算處理能力來處理海量大數(shù)據(jù)能很好滿足要求。首先對每個用戶的醫(yī)療健康數(shù)據(jù)總條數(shù)進行查詢分析。MapReduce設(shè)計思路如下：

Map過程就是將HBase中的數(shù)據(jù)導(dǎo)入到集群環(huán)境中。以每個用戶個體作為一個分塊，并分配一個Map任務(wù)，這些分塊會運行在不同的機器上。Map任務(wù)會針對每個個體數(shù)據(jù)進行查詢計算，Map函數(shù)處理后輸出一個鍵值對。以用戶身高為例，Key=Height，Value=1。Map函數(shù)產(chǎn)生的鍵值對會被分配到不同的Reduce函數(shù)中，系統(tǒng)將Key值相同的所有數(shù)據(jù)的Value進行合并，就查詢到每個用戶個體在數(shù)據(jù)庫中的醫(yī)療健康的總條數(shù)。再以醫(yī)療健康數(shù)據(jù)中的體重（Weight）特征進行分析，分析體重超過80kg的醫(yī)療健康數(shù)據(jù)在總數(shù)據(jù)的比率。在Map函數(shù)中以體重是否超過80kg對體重進行分組，如果Weight大于80就產(chǎn)生鍵值對為，如果Weigh小于80就產(chǎn)生鍵值對為，之后傳到Reduce函數(shù)，根據(jù)Key值合并Value的值，得出結(jié)果，完成MapReduce計算過程。查詢分析流程圖如圖4所示。

圖4 MapReduce醫(yī)療健康查詢分析流程圖

4 醫(yī)療健康數(shù)據(jù)管理模型的測試分析

4.1 測試環(huán)境搭建

測試使用3臺機器構(gòu)建Hadoop集群，其中1臺作為主節(jié)點，2臺作為從節(jié)點，3臺機器的配置和IP配置如表2所示。操作系統(tǒng)為Centos7.0，Hadoop版本為hadoop-2.5.2，HBase數(shù)據(jù)庫版本為HBase-0.98.9。

表2 Hadoop集群機器配置信息表

4.2 HBase性能測試

由于醫(yī)療健康數(shù)據(jù)種類特征較多，需要進行數(shù)據(jù)加工處理。本次實驗數(shù)據(jù)來自香港婦幼健康中心（MCHC）和多所中小學(xué)學(xué)校統(tǒng)計25000個孩子從0歲到18歲身高體重數(shù)據(jù)。數(shù)據(jù)存儲從傳統(tǒng)數(shù)據(jù)庫MySql轉(zhuǎn)變?yōu)榉顷P(guān)系型數(shù)據(jù)庫HBase，為了驗證HBase更加適合于海量數(shù)據(jù)的存儲，分別對HBase和MySql數(shù)據(jù)量查詢時間做對比，結(jié)果如表3所示。從表中可以看出，對于數(shù)據(jù)量較小的查詢，MySql表現(xiàn)比HBase較好，但差距不大。隨著數(shù)據(jù)量的增大，HBase的優(yōu)勢顯著提高，這正是由于HBase的分布式處理，使得HBase查詢時間優(yōu)于傳統(tǒng)數(shù)據(jù)庫。

表3 MySql和HBase數(shù)據(jù)量查詢時間表

4.3 MapReduce性能測試

測試醫(yī)療健康數(shù)據(jù)集群MapReduce的性能，此處用Hadoop自帶的wordcount進行測試，wordcount用于對文本中單詞個數(shù)進行統(tǒng)計。通過測試節(jié)點數(shù)為1個、2個和3個條件下對文件大小分別為1MB、10MB、100MB、500MB和800MB的文件進行集群性能測試，結(jié)果如表4所示。從對比結(jié)果可以看出，當(dāng)集群節(jié)點數(shù)為1個時，小文件處理時間比大文件快，而當(dāng)節(jié)點數(shù)為3個時，處理大文件的時間大大減少，體現(xiàn)MapReduce并行計算的優(yōu)勢，證實醫(yī)療健康數(shù)據(jù)集群MapReduce部署無誤，可用于海量醫(yī)療健康數(shù)據(jù)分析和挖掘。

表4 MapReduce性能測試對比

5 結(jié)語

隨著移動端設(shè)備和可穿戴式技術(shù)的逐漸成熟，醫(yī)療健康數(shù)據(jù)越來越龐大，存儲和處理如此大量的數(shù)據(jù)正面臨許多挑戰(zhàn)。本文提出基于Hadoop的醫(yī)療健康數(shù)據(jù)管理模型的研究，并進行測試分析。通過對HDFS、HBase和MapReduce特性進行分析，設(shè)計了利用HBase存儲醫(yī)療健康數(shù)據(jù)并使用MapReduce對數(shù)據(jù)查詢分析，在數(shù)據(jù)存儲和計算性能方面均有較大提升。通過測試分析，HBase比傳統(tǒng)數(shù)據(jù)庫在大量數(shù)據(jù)存儲上更具有優(yōu)勢，MapReduce在數(shù)據(jù)分析方面可以提高整體運行計算能力。在今后工作中，研究的重點是對HBase醫(yī)療數(shù)據(jù)存儲索引的更新和維護，深入挖掘醫(yī)療數(shù)據(jù)中有用的信息，為醫(yī)療健康提供更為合理的決策建議。