基于云平臺Hadoop的中醫數據挖掘系統設計與實現

王 倩 石艷敏 史春暉 朱習軍

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

0 引 言

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

1 系統結構與功能

1.1 系統架構設計

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

圖1 系統總架構

1.2 系統功能設計

系統主要包括數據管理和數據挖掘兩個大模塊。具體功能描述如下：

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

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

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

2 算法設計與實現

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

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

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

針對以上問題，本文對Fp-growth算法在中醫藥數據的處理上從兩方面來進行優化：

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

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

圖2為FP-growth算法進行MapReduce優化的流程圖。

圖2 FP-growth算法并行化實現流程圖

算法實現總體分為五個階段：

1) 數據分片：將大量數據劃分在多個Datanode節點以區塊方式存儲。

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

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

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

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

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

2.2 FP-growth算法應用實現

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

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

表1 算法的一條事務項數據內容

挖掘過程主要分為兩步：

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

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

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

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

表2 部分挖掘結果示例

通過分析表2發現：

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

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

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

3 系統環境搭建及實現

3.1 Hadoop體系結構

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

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

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

3.2 集群規劃說明

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

表3 集群規劃部署表

3.3 系統實現

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

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

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

圖4 關聯模式的挖掘

如圖5所示，若監控任務顯示挖掘任務運行成功，選擇結果顯示中的加載結果文件，選擇數據轉換將結果轉換成中文，或將結果導出再進行分析。

圖5 挖掘結果展示

4 結 語

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