基于云平臺Hadoop的中醫(yī)數(shù)據(jù)挖掘系統(tǒng)設計與實現(xiàn)

王 倩 石艷敏 史春暉 朱習軍

(青島科技大學信息科學技術學院 山東 青島 266061)

0 引 言

近年來云計算創(chuàng)新發(fā)展、大數(shù)據(jù)戰(zhàn)略、物聯(lián)網(wǎng)健康發(fā)展、“互聯(lián)網(wǎng)+”行動、人工智能規(guī)劃等一系列重大決策部署，開啟了我國信息化發(fā)展新征程。為順應信息化發(fā)展的歷史潮流、突破中醫(yī)藥大數(shù)據(jù)量存儲與計算的瓶頸問題，以推進中醫(yī)藥繼承創(chuàng)新為主題的中醫(yī)藥大數(shù)據(jù)應用平臺系統(tǒng)的建立迫在眉睫[1]?；诖耍疚奶岢隽艘粋€基于云計算平臺Hadoop的中醫(yī)數(shù)據(jù)挖掘系統(tǒng)，充分發(fā)揮云、大、物、移、智在中醫(yī)藥中的作用，采用并行優(yōu)化的FP-growth算法對中藥、癥狀和證型數(shù)據(jù)進行關聯(lián)關系的挖掘，發(fā)現(xiàn)其證型與癥狀間，用藥間的關系，從而達到輔助醫(yī)療診斷的效果。

1 系統(tǒng)結(jié)構與功能

1.1 系統(tǒng)架構設計

該系統(tǒng)選擇C/S結(jié)構模式，以Hadoop集群作為系統(tǒng)的服務器端，客戶端界面使用Java Swing設計，同時借助Webservice技術實現(xiàn)客戶端與服務器間的交互。系統(tǒng)總體架構如圖1所示。

圖1 系統(tǒng)總架構

1.2 系統(tǒng)功能設計

系統(tǒng)主要包括數(shù)據(jù)管理和數(shù)據(jù)挖掘兩個大模塊。具體功能描述如下：

1) 數(shù)據(jù)管理模塊 分布式文件存儲系統(tǒng)HDFS其分區(qū)塊存儲數(shù)據(jù)的思想可以有效地提高容錯能力及寫入性能：將每個區(qū)塊分為128 MB對數(shù)據(jù)順序存儲，記錄其偏移量，因此即使存儲過程某個節(jié)點發(fā)生故障，在其恢復后數(shù)據(jù)也能根據(jù)其偏移量及區(qū)塊數(shù)繼續(xù)存儲，保證整個系統(tǒng)正常運作防止數(shù)據(jù)的丟失。其特點很好地解決了中醫(yī)大量病案數(shù)據(jù)的存儲及安全問題，因此該模塊主要通過HDFS實現(xiàn)對中醫(yī)病案數(shù)據(jù)的存儲管理和數(shù)據(jù)與本地之間的上傳下載。另一方面，MapReduce在執(zhí)行任務需要將Jar包寫入到HDFS中，在讀取待處理數(shù)據(jù)和存儲結(jié)果時也需要到HDFS讀取和寫入。

2) 數(shù)據(jù)挖掘模塊 由于中醫(yī)數(shù)據(jù)較為復雜，因此在進行數(shù)據(jù)挖掘之前首先需要對病案數(shù)據(jù)進行預處理，主要包括：(1) 對原始數(shù)據(jù)進行規(guī)范整理獲得癥狀、證型、用藥三種數(shù)據(jù)類型；(2) 中醫(yī)藥數(shù)據(jù)及對證型癥狀的描述均為中文表示，其復雜性不適合作為數(shù)據(jù)挖掘中的輸入，因此需要對中文數(shù)據(jù)進行數(shù)值化處理，完成中文到數(shù)字的轉(zhuǎn)換；(3) 最后將處理好的數(shù)據(jù)存儲在HDFS上以便MapReduce任務讀取進行挖掘[1-2]。

挖掘類型包括：對用藥數(shù)據(jù)關系的單獨分析，從而獲得藥物組合規(guī)律；對癥狀與證型進行挖掘分析其關聯(lián)性；將癥狀、證型和用藥數(shù)據(jù)組合進行挖掘獲取其關聯(lián)性。

2 算法設計與實現(xiàn)

2.1 并行化設計的FP-growth算法

由于關聯(lián)規(guī)則經(jīng)典算法Apriori算法需要多次遍歷數(shù)據(jù)集來構造候選集、篩選候選集而獲取頻繁項集。當處理大數(shù)據(jù)量時將會造成系統(tǒng)的 IO 負載過高。另外若支持度閾值較小，那么通過自連接產(chǎn)生候選項集的計算量將非常龐大又耗時；若支持度閾值過高，雖能提升計算效率但挖據(jù)獲得的有效信息又會變少。

針對Apriori算法計算時產(chǎn)生大量候選項集的問題，Han等提出了FP-growth算法[3]，它采用前綴樹的形式來表示數(shù)據(jù)，在計算過程中只需要掃面兩次數(shù)據(jù)庫，然后遞歸地生成條件FP-tree來挖掘頻繁項。這有效地解決了傳統(tǒng)Apriori算法需要多次掃描數(shù)據(jù)庫的問題。然而在處理大數(shù)據(jù)量時，F(xiàn)P-growth算法也有一些弊端：大數(shù)據(jù)量導致其生成的FP-tree有可能非常大，以至于無法放入內(nèi)存；另外大數(shù)據(jù)量也會導致挖掘到的頻繁項數(shù)量非常巨大。

針對以上問題，本文對Fp-growth算法在中醫(yī)藥數(shù)據(jù)的處理上從兩方面來進行優(yōu)化：

1) 將待處理數(shù)據(jù)切分成多個數(shù)據(jù)片段分別存儲到Hadoop集群的多個節(jié)點中，以此來保證整個集群的讀寫性能。然后通過MapReduce任務并行的處理節(jié)點上每個job中的數(shù)據(jù)[4]。即通過劃分數(shù)據(jù)庫來突破空間復雜度的瓶頸。

2) 對于構造的項頭表中一些頻度相同的頻繁項，若在排列時順序不同將會構造出不同的fp-tree，從而有可能會導致構造出的fp-tree過大，因此在構建fp-tree時可以通過對項的順序動態(tài)調(diào)整來尋找最優(yōu)化的fp-tree，以此節(jié)省存儲空間[5]，提升計算效率。

圖2為FP-growth算法進行MapReduce優(yōu)化的流程圖。

圖2 FP-growth算法并行化實現(xiàn)流程圖

算法實現(xiàn)總體分為五個階段：

1) 數(shù)據(jù)分片：將大量數(shù)據(jù)劃分在多個Datanode節(jié)點以區(qū)塊方式存儲。

2) 并行計算獲取F-list(項頭表)：通過Map()與Reduce()任務計算支持度存入F-List，其中每個Mapper對應一個區(qū)塊。

3) 對F-list分組：每組賦予一個唯一的組ID得到G-List。

4) 并行化FP-growth：Mapper首先讀取G-List中生成的groupid，然后將第一步生成的每一個數(shù)據(jù)片作為Map()的value值。掃描value中的每一個項，若項Vn在G-List中所對應的groupid是第一次出現(xiàn)，則輸出V0～Vn的項，否則不輸出數(shù)據(jù)。將所有groupid相同的數(shù)據(jù)放到同一個Reduce中，由Redeuce()遞歸構造fp-tree挖掘頻繁模式。

5) 結(jié)果整合：Mapper對上一步中每個不同groupid的Reduce節(jié)點上的頻繁模式進行處理，由Reduce()匯總Map()的輸出獲得最終的結(jié)果。

由圖2可見，這五個階段共使用三個MapReduce的Job來完成。

2.2 FP-growth算法應用實現(xiàn)

1) 中醫(yī)藥數(shù)據(jù)關聯(lián)規(guī)則挖掘 根據(jù)上述FP-growth算法的并行化設計方案，將某醫(yī)院中醫(yī)呼吸科臨床數(shù)據(jù)分類整理與規(guī)范化，然后對數(shù)據(jù)統(tǒng)計編號完成數(shù)值化便于機器處理[6-7]。

中文數(shù)據(jù)的數(shù)值化處理主要是將三種數(shù)據(jù)類型依次按順序編號，編號之間以逗號作為分隔符，主要由Java編程中的Map()函數(shù)完成。數(shù)值化處理后的數(shù)據(jù)每如I={ 131，72，252，162，154，233，126，138，96，91，88，101，92，195，16，140，161，111，212，240，2}所示，該數(shù)據(jù)表示的是表1所示的一條事務項數(shù)據(jù)內(nèi)容。

表1 算法的一條事務項數(shù)據(jù)內(nèi)容

挖掘過程主要分為兩步：

(1) 將處理好的數(shù)據(jù)上傳至HDFS作為輸入數(shù)據(jù)。

(2) 將實現(xiàn)挖掘的Java代碼打包后通過命令行來設置數(shù)據(jù)的輸入及輸出路徑支持度等參數(shù)，然后提交至集群執(zhí)行MapReduce任務。

2) 挖掘結(jié)果分析 并行化算法運行結(jié)束后，首先獲得第一次構建FP-Tree樹產(chǎn)生的后綴模式的條件模式基，如圖3所示，輸出結(jié)果為key-value形式。然后對結(jié)果進行關聯(lián)規(guī)則計算，輸出結(jié)果形如[233,140,16]=>2:supp=0.250,conf=0.729，其中supp代表支持度，表示[233,140,16]與2同時出現(xiàn)的概率為0.250；conf代表置信度，表示[233,140,16]出現(xiàn)的情況下2出現(xiàn)的概率為0.729。而數(shù)字16、2、233、140則是對中文中醫(yī)數(shù)據(jù)的編碼。因此為了更直觀清晰地分析出數(shù)據(jù)之間的關聯(lián)規(guī)則，需要將挖掘結(jié)果轉(zhuǎn)換為中文表示，同樣主要由Java編程中的Map()函數(shù)實現(xiàn)。將部分挖掘結(jié)果匯總?cè)绫?所示，該表包含了證型與癥狀、藥物與癥狀、藥物與藥物之間的規(guī)律。

圖3 部分后綴模式的條件模式基

表2 部分挖掘結(jié)果示例

通過分析表2發(fā)現(xiàn)：

1) 半夏，陳皮，茯苓該組藥物同時出現(xiàn)的頻率很高，經(jīng)查閱相關資料得知，半夏主治燥濕化痰，降逆止嘔，痰多咳喘，痰飲眩悸，風痰眩暈等癥狀；陳皮主要用于脘腹脹滿，食少吐瀉，咳嗽痰多；茯苓則用于脾虛食少，痰飲眩悸，驚悸失眠等癥狀。分析發(fā)現(xiàn)半夏，陳皮和茯苓均用于痰多咳嗽癥狀且有化痰的功效，這也與表2中挖掘出的：[半夏，陳皮]==>痰多泡沫這項結(jié)果相符合。證明本次實驗挖掘得到的中醫(yī)用藥與癥狀之間的關系符合實際與實踐。

2) 發(fā)現(xiàn)了一些證型中的核心癥狀表現(xiàn)，如表2中的氣陰兩虛證：此證型同時與胸悶氣短,動則加重,干咳無痰,少痰,氣聲低,神疲,乏力,汗多,惡風,腰膝酸軟等癥狀頻繁出現(xiàn)，其支持度較高；反之，若當患者出現(xiàn)如上幾個癥狀，可以考慮患者有可能患氣陰兩虛證。

3) 表2中最后一項痰蒙神竅證與其癥狀間關系的置信度高達百分之八十九，表示神志恍惚,肢體抽搐，苔白膩，舌質(zhì)紅這些癥狀出現(xiàn)的情況下，患者所患的病癥為痰蒙神竅證的概率達89%。而查閱相關資料發(fā)現(xiàn)痰蒙神竅證的主要癥狀為神志恍惚，抽搐，苔白膩或黃膩，舌質(zhì)暗紅，脈細。證明挖掘結(jié)果有效可靠有效，符合實際情況。

3 系統(tǒng)環(huán)境搭建及實現(xiàn)

3.1 Hadoop體系結(jié)構

Hadoop被公認是一套行業(yè)大數(shù)據(jù)標準開源軟件，在分布式環(huán)境下提供了海量數(shù)據(jù)的處理能力。它主要解決了三大問題：通過HDFS實現(xiàn)海量數(shù)據(jù)的存儲、MapReduce實現(xiàn)海量數(shù)據(jù)的計算與分析、YARN實現(xiàn)資源的管理調(diào)度。

數(shù)據(jù)量越來越多，在一個操作系統(tǒng)管轄的范圍存放不了，因此迫切需要一種系統(tǒng)來管理多臺機器上的文件，這就是分布式文件系統(tǒng)HDFS。其中NameNode是整個文件系統(tǒng)的管理節(jié)點，它維護著整個文件系統(tǒng)的文件目錄樹，同時接收用戶的操作請求。而Data-Node則提供真實文件數(shù)據(jù)的存儲服務。

MapReduce是一種分布式計算模型，主要用于解決海量數(shù)據(jù)的計算問題。MR由兩個階段組成：Map和Reduce，每個Map處理一個塊的內(nèi)容，當所有Map都處理完之后再通過Reducer進行合并。用戶只需要實現(xiàn)map()和reduce()兩個函數(shù)，即可實現(xiàn)分布式計算。MapReduce運行在YARN之上，Yarn中的ResourceManagger用來管理資源的分配調(diào)度，NodeManager負責具體任務。

3.2 集群規(guī)劃說明

系統(tǒng)基于Linux環(huán)境，通過6臺PC機組成6個節(jié)點搭建Hadoop 2.7.2 集群作為服務器。集群部署規(guī)劃如表3所示：考慮到NameNode和ResourceManager要占用大量資源，因此將二者分別配置在兩個節(jié)點中，從而減輕資源使用的壓力。將DataNode和Node-Manager分別配置在三個節(jié)點中，由于NodeManager有多個，因此它通過心跳機制與ResourceManager保持聯(lián)系同時主動領取MapReduce任務，以此減輕Resource-Manager作為管理者的壓力。另外考慮到集群的負載均衡與HA問題，采用QJM解決方案使得主備NameNode之間通過一組JournalNode同步元數(shù)據(jù)信息，共配置三個JournalNode。同時將分布式協(xié)調(diào)服務Zookeeper配置到集群中用于DFSZKFailoverController的故障轉(zhuǎn)移，當Active NameNode產(chǎn)生故障時會自動切換Standby NameNode為Active狀態(tài)，保證了整個集群的正常運作[8]。表3中QuorumPeerMain為Zookeeper的進程。

表3 集群規(guī)劃部署表

3.3 系統(tǒng)實現(xiàn)

系統(tǒng)通過Webservice技術實現(xiàn)集群連接，文件上傳/下載，Job任務提交等，最終完成服務器之間的交互。

向集群提交MapReduce任務時，后臺遠程調(diào)用Webservice提交任務，將請求任務加工成soap包后提交至YARN，各節(jié)點任務結(jié)束后將結(jié)果匯總存儲到HDFS上。這時可以在系統(tǒng)界面對結(jié)果進行、下載，或者將結(jié)果加載展示在系統(tǒng)界面[9]。

系統(tǒng)在進行挖掘時，需要設置的參數(shù)包括：待處理的數(shù)據(jù)源，關聯(lián)規(guī)則算法，支持度與置信度，HDFS的結(jié)果存放路徑。如圖4所示，設置好相關參數(shù)后選擇要執(zhí)行的算法jar包提交任務，點擊執(zhí)行后系統(tǒng)立即執(zhí)行挖掘。如章節(jié)一中系統(tǒng)集群配置模塊中所述，挖掘過程中可在集群監(jiān)控中查看任務進度與狀態(tài)，以便于及時發(fā)現(xiàn)問題，保證挖掘任務的順利進行。

圖4 關聯(lián)模式的挖掘

如圖5所示，若監(jiān)控任務顯示挖掘任務運行成功，選擇結(jié)果顯示中的加載結(jié)果文件，選擇數(shù)據(jù)轉(zhuǎn)換將結(jié)果轉(zhuǎn)換成中文，或?qū)⒔Y(jié)果導出再進行分析。

圖5 挖掘結(jié)果展示

4 結(jié) 語

本文在Hadoop平臺上設計實現(xiàn)了一個集中醫(yī)藥數(shù)據(jù)管理和數(shù)據(jù)挖掘功能于一體的中醫(yī)數(shù)據(jù)挖掘系統(tǒng)，并對系統(tǒng)所提供的功能進行了比較詳細的分析與設計。相比于中醫(yī)數(shù)據(jù)挖掘的已有研究，本文具有以下創(chuàng)新點：1) 為避免Apriori算法產(chǎn)生大量候選集導致的大計算量問題，對FP-growth算法并行化設計：將數(shù)據(jù)存儲在多個節(jié)點中并行計算，提高存儲與計算效率；2) 系統(tǒng)在具備傳統(tǒng)中醫(yī)數(shù)據(jù)挖掘系統(tǒng)的基本功能的前提下，通過引入Hadoop體系結(jié)構，實現(xiàn)了對中醫(yī)大數(shù)據(jù)量更完善、更安全的存儲和更高效、更準確地挖掘計算，從而完成了一個比傳統(tǒng)專家系統(tǒng)計算效率更高的中醫(yī)數(shù)據(jù)挖掘系統(tǒng)。結(jié)果證明在Hadoop平臺上將FP-growth算法并行化并應用于中醫(yī)大數(shù)據(jù)量的進行挖掘具有一定的可行性，其效率更高、結(jié)果更準確。這為中醫(yī)藥健康大數(shù)據(jù)的應用奠定了基礎，也推動了互聯(lián)網(wǎng)與中醫(yī)藥健康服務深度融合發(fā)展。