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

王 倩 石艷敏 史春暉 朱習(xí)軍

(青島科技大學(xué)信息科學(xué)技術(shù)學(xué)院 山東 青島 266061)

0 引 言

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

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

1.1 系統(tǒng)架構(gòu)設(shè)計(jì)

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

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

1.2 系統(tǒng)功能設(shè)計(jì)

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

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

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

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

2 算法設(shè)計(jì)與實(shí)現(xiàn)

2.1 并行化設(shè)計(jì)的FP-growth算法

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

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

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

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

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

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

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

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

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

2) 并行計(jì)算獲取F-list(項(xiàng)頭表)：通過Map()與Reduce()任務(wù)計(jì)算支持度存入F-List，其中每個(gè)Mapper對(duì)應(yīng)一個(gè)區(qū)塊。

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

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

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

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

2.2 FP-growth算法應(yīng)用實(shí)現(xiàn)

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

中文數(shù)據(jù)的數(shù)值化處理主要是將三種數(shù)據(jù)類型依次按順序編號(hào)，編號(hào)之間以逗號(hào)作為分隔符，主要由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所示的一條事務(wù)項(xiàng)數(shù)據(jù)內(nèi)容。

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

挖掘過程主要分為兩步：

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

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

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

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

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

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

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

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

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

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

3.1 Hadoop體系結(jié)構(gòu)

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

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

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

3.2 集群規(guī)劃說明

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

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

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

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

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

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

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

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

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

4 結(jié) 語

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