大資料項目實踐：基於hadoop+spark+mongodb+mysql開發醫院臨床知識庫系統

標籤：

一、前言

     從20世紀90年代數字化醫院概念提出到至今的20多年時間，數字化醫院（Digital Hospital)在國內各大醫院飛速的普及推廣發展，並取得驕人成績。不但有數字化醫院管理資訊系統（HIS)、影像存檔和通訊系統（PACS)、電子病曆系統（EMR)和地區醫學衛生服務（GMIS)等成功實施與普及推廣，而且隨著日新月異的電腦技術和網路技術的革新，進一步為數字化醫院帶來新的互動渠道譬如：遠程醫學服務，網上挂號預約。

     隨著IT技術的飛速發展，80%以上的三級醫院都相繼建立了自己的醫院資訊系統（HIS）、電子病曆系統（EMR）、合理用藥系統（PASS）、檢驗管理系統（LIS）、醫學影像儲存與共用系統（PACS）以及移動查房、移動護理系統以及與大量的第三方介面整合應用，IT在醫學領域已經進入了一個大資料時代，隨著HIS的廣泛應用及其功能的不斷完善，HIS收集了大量的醫學資料。

     進入2012年，大資料及相關的大資料處理技術越來越多地被國人提及，人們也普遍的接受大資料的概念，大資料技術也影響著我們的日常生活，互連網行業已經得到廣泛應用，電信、銀行等行業也已經在廣泛嘗試使用大資料技術提供更穩健和優質的服務。

     在目前情況下，醫學IT系統收集了這些集其有價值的資料，但是這些大量的有價值的曆史醫學資料並沒有發揮出其應有的價值，不能為一線臨床醫生提供醫學診斷輔助，也不能為醫院管理和經營決策提供必須的支援。

     針對以上現狀，思考擬利用醫院現有的曆史就診記錄、處方、診斷、病曆資料，挖掘出有價值的基於統計學的醫學規則、知識，並基於這些規則、知識資訊構建專業的臨床知識庫，為一線醫務人員提供專業的診斷、處方、用藥推薦功能，基於強大的關聯推薦能力，極大的提高醫學服務品質，減輕一線醫學人員的工作強度。

二、Hadoop&Spark

     目前大資料處理領域的架構有很多。從計算的角度上看，主要有MapReduce架構（屬於Hadoop生態系統）和Spark架構。其中Spark是近兩年出現的新一代計算架構，基於記憶體的特性使它在計算效率上大大優於MapReduce架構；從儲存角度來看，當前主要還是在用Hadoop生態環境中的HDFS架構。HDFS的一系列特性使得它非常適合大資料環境下的儲存。

2.1 Hadoop

     Hadoop不是一個軟體，而是一個分布式系統基礎架構，是由Apache基金會主持開發的一個開源項目。Hadoop可以使使用者在不瞭解分布式底層實現的情況下，開發分布式程式，從而充分利用電腦叢集的威力，實現高速運算和大規模資料存放區。Hadoop主要有HDFS、MapReduce、Hbase等子項目組成。

     Hadoop是一個能夠對大量資料進行分散式處理的軟體架構，並且使用可靠、高效、可伸縮的方式進行資料處理。Hadoop假設資料處理和儲存會失敗，因此系統維護多個工作資料副本，確保能夠針對失敗的節點重新分配處理。Hadoop通過並行工作，提高資料處理速度。Hadoop能夠處理PB級資料，這是常規資料服務器所不能實現的。此外，Hadoop依賴於開源社區，任何問題都可以及時得到解決，這也是Hadoop的一大優勢。Hadoop建立在Linux 叢集上，因此成本低，並且任何人都可以使用。它主要具有以下優點：

     1高可靠性。Hadoop系統中資料預設有三個備份，並且Hadoop有系統的資料檢查維護機制，因而提供了高可靠性的資料存放區。

     2擴充性強。Hadoop在普通PC伺服器叢集上分配資料，通過並行運算完成計算任務，可以很方便的為叢集擴充更多的節點。

     3高效性。Hadoop能夠在叢集的不同節點之間動態轉移資料。並且保證各個節點的動態平衡，因此處理速度非常快。

     4高容錯性。Hadoop能夠儲存資料的多個副本，這樣就能夠保證失敗時，資料能夠重新分配。

     Hadoop總體架構如所示，Hadoop架構中核心的是MapReduce和HDFS兩大組件。

     Google曾發表論文《Google File System》，系統闡述了Google的Distributed File System的設計實現，Apache針對GFS，進行開源開發，發布了Hadoop的Distributed File System：Hadoop Distributed File System,縮寫為HDFS。MapReduce的核心思想也由Google的一篇論文《MapReduce:Simplified Data Processing on Large Clusters》 提出，筒單解釋MapReduce的核心思想就是：任務分解執行，執行結果匯總。

2.2 Spark

     Spark是UC Berkeley大學AMP實驗室開源的類似MapReduce的計算架構，它是一個基於記憶體的叢集計算系統，最初的目標是解決MapReduce磁碟讀寫的開銷問題，當前最新的版本是1.5.0。Spark—經推出，就以它的高效能和易用性吸引著很多大資料研究人員，在眾多愛好者的努力下，Spark逐漸形成了自己的生態系統( Spark為基礎，上層包括Spark SQL，MLib，Spark Streaming和GraphX),並成為Apache的頂級項目。

     Spark的核心概念是彈性分布式儲存(Resilient Distributed Datasets, RDD)間，它是Spark對分布式記憶體進行的抽象，使用者可以像操作本機資料集一樣操作RDD,從而可以將精力集中於業務處理。在Spark程式中，資料的操作都是基於RDD的，例如經典的WordCount程式，其在Spark編程模型下的操作方式如所示：

     可以看到Spark先從檔案系統抽象出RDD1,然後由RDD1經過flatMap運算元轉換得到RDD2,RDD2再經過reduceByKey運算元得到RDD3,最後RDD3中的資料重新寫迴文件系統，一切操作都是基於RDD的。

三、思路和架構

     經過多方面的思考，最終決定基於Spark技術進行構建和實現醫院臨床知識庫系統，採用MongoDB/Sequoiadb構建大資料倉儲，做為大資料的儲存中心，採用Hadoop+Spark1構建巨量資料分析平台，基於AgileEAS.NET SOA中介軟體構建ETL資料幫浦轉換工具（後期部分換用了Pentaho Kettle），基於AgileEAS.NET SOA中介軟體構建知識庫的服務門戶，通過WCF/WebService與HIS系統進行業務整合整合，使用AgileEAS.NET SOA+FineUI構建基礎字典管理以後分析結構的映像化展示功能。

     最初我們選擇了SequoiaDB做為大資料存放區中心，為此我還特意的為SequoiaDB完成了C#驅動，參考本人為巨杉資料庫(開源NoSQL)寫的C#驅動，支援Linq，全部開源，已提交github一文，但是一方面熟悉SequoiaDB的技術人員太少了，維護是個問題，最後，在差不多8多個月這後我們換用了MongoDB 3.0做為大資料存放區中心。

     最初我們選擇了hadoop2.0+spark1.3.1版本之上使用scala2.10開發完成了醫院臨床知識庫系統，請參考centos+scala2.11.4+hadoop2.3+spark1.3.1環境搭建，但是在後期替換Sequoiadb為MongoDB的同時，我們把計算架構也由hadoop2.0+spark1.3.1升級到了hadoop2.6+spark1.6.2。

     考慮到spark都部署在Linux的情況，對於spark分析的結果輸出儲存在Mysql5.6資料庫之中，系統所使用的各種字典資訊也儲存在Mysql之中。

     spark資料分析部分的代碼使用IntelliJ IDEA 14.1.4工具進行編寫，其他部分的代碼使用VS2010進行編寫。

3.1 總體架構

      整個系統由資料擷取層、儲存分析層和應用邏輯層三大部分以及本系統所選所以來的外部資料源。

      本系統的外部資料源目前主要是醫院資訊系統所產生的臨床資料，目前主要集中在HIS系統之中，後期將采依賴於EMR、LIS、PACS系統。

      資料擷取層主要負責從臨床業務系統採集海量曆史臨床資料同，記錄採集方式分為批採集和即時採集，在資料擷取過程之中對未經處理資料進行格工檢查，並對未經處理資料進行清洗和轉換，並將處理後的資料存放區在大資料倉儲之中。

      儲存分析層主要負責資料存放區以及資料分析兩大部分業務，經過清洗轉換的合理有效資料被儲存在大資料集群之中，使用JSON格式，大資料存放區引用使用SequoiaDB資料庫，資料分析部分由Hadoop/Spark叢集來完成，大資料存放區經由Spark匯入並進行分析，分析結果寫入臨床知識資料庫，臨床知識資料庫使用MySql資料庫進行儲存。

      應用邏輯層主要負責人機互動以及分析結構回饋臨床系統的渠道，通過WebUI的方式向臨床醫生、業務管理員提供列表式、映像化的知識展示，也為臨床系統的業務輔助、推薦功能提供調用的整合API，目前API主要通過WebService、WebAPI兩種方式提供。

3.2 總體流程

     整個系統經由資料來源資料擷取，寫入大資料存放區SequoiaDB叢集，然後由Spark進行分析計算，分析產生的臨床知識寫入MySQL知識庫，經由WebUI以及標準的API交由臨床使用。

3.3 資料匯入流程

     曆史資料的採集匯入使用初期使用AgileEAS.NET SOA 的計劃任務配何C#指令碼進行實現，由計劃任務進行協調定時執行，具體的資料匯入代碼根據不同的臨床業務系統不同進行指令碼代碼的調整，也可以使用Pentaho Kettle進行實現，通過Pentaho Kettle可配置的實現資料的匯入。

3.4 物理結構設計

     臨床資料來源為本系統進行分析的資料來源，源自於臨床HIS、EMR，目前醫院的HIS使用SQL Server 2008 R2資料庫，EMR使用ORACLE 11G資料庫，運行於Windows2008作業系統之上。

     SequoiaDB叢集為大資料存放區數制庫叢集，目前使用SequoiaDB v2.0，運行於Centos6.5作業系統之上，根據業務來規模使用2-16節點叢集，其用於儲存經過清洗轉換處理的海量曆史臨床資料，供Spark叢集進行分析，以及供應SOA伺服器進行曆史資料查詢和曆史相關推薦使用。

     Hadoop/Spark叢集為本系統的分析計算核心節點，用於對SequoiaDB叢集之中的曆史資料進行分析，產生輔助臨床醫生使用的醫學知識，本叢集根據業務來規模使用2-16節點叢集，使用Centos6.5作業系統，安裝JAVA1.7.79運行環境、scala2.11.4語言，使用Hadoop2.3，spark1.3.1分析架構。

     MySql知識庫為本系統的知識庫儲存資料庫，Hadoop/Spark叢集所生產的分析結構寫入本資料庫，經由SOA伺服器和Web服務處理供臨床系統整合使用和WebGUI展現，目前使用MySQL5.6版本，安裝於Windows2008/Centos6作業系統之上。

     SOA Server為本系統的對外介面應用伺服器，向臨床業務系統和Web Server提供業務運算邏輯，以及向臨床業務系統提供服務API，目前運行於Windows2008作業系統，部署有.NET Framework 4.0環境，運行AgileEAS.NET SOA 中介軟體的SOA服務，由AgileEAS.NET SOA 中介軟體SOA服務向外部系統提供標準的WebService以及WebAPI。

     Web Server為系統提供基於標準的B/S瀏覽器使用者介面，供業務人員通過B/S網頁對系統進行管理，查詢使用知識庫之中的醫學知識，目前運行於Windows2008作業系統，部署有.NET Framework 4.0環境，運行於IIS7.0之中。

     臨床工作站系統運行HIS、EMR系統，兩系統均使用C#語言SOA架構思路進行開發，與本系統整合改造後，使用標準WebService介面本系統，使用本系統所提供的API為臨床提供診療輔助。

四、環境、安裝、坑

    目前系統跑在虛擬化環境之中，其中三台Centos6組成大資料存放區、計算叢集，每台分配16CPU（核）16G記憶體2T硬碟，3台共48核48G，這三台機器每台都安裝了java1.8.25+scala2.10+hadoop2.6,spark1.62,mongodb3.0組合3節點的叢集，spark採用Standalone Cluster模式，單一master節點，為每台機器分配其中12核12G用於Worker，其餘CPU記憶體留給mongodb叢集使用，運行如下：

     一台Win2008做為SOA|應用伺服器，分配32核64G記憶體，部署了Mysql5.6,IIS，AgileEAS.NET SOA 服務，整個系統的SOA服務和Web管理介面由本伺服器進行承載，一方面提供Web方式的管理和查詢，另一方面以webservice、webAPI為臨床系統提供服務。

     具體環境的安裝過程由於篇幅的原因在此就不在一一細說，我將會單獨寫一篇文章為大家進行詳細的介紹。

     第一次使用Spark，又沒有多少資料可參考，所以在開發過程之中遇到不少的坑，特別是初期的時間，搭建環境就費了一周，寫代碼過程之中坑也是一直發現一直填坑，有點坑也填不了，直好換思路繞了，記得在spark sql的udf自訂函數上，並不是所有函數都有坑，偶爾自己寫的udf函數怎麼都是過不去，找不到原因，看spark的原始碼也沒看出個所以然，最後不得改寫代碼，換思路搞。

     感覺特別有愛的就是scala語言了，我覺得使用.net 4.0(C#)的朋友們，特別是用熟Linq的兄弟們，scala語言太方便了，我感覺他基本上就是和linq一樣方便，更沒有節操的是，在函數之中可以定義類，不過，真的是很方便，我不是很喜歡java，但是我喜歡scala。

五、效果展示5.1 門診診斷排名

     門診診斷排名是門診診斷知識的圖形化介面展示顯示，用於展示全院或者指定專科的TopN位常用診斷，也為每一個診斷與性別、年齡等人群相關性以及與節氣相關性圖表展示。

5.2 門診伴生診斷查詢

     門診伴生診斷排名是門診診斷併發症的知識展示介面，用於展示得某一種疾病另其他疾病的可能性。

5.3 門診自動組方查詢

     門診自動組方查詢，用於展示臨床最常用的用藥、治療自動組方知識，即比如最常用的0.9%氯化鈉注射液 100 ml配注射用頭孢硫咪 1g，常適用於扁桃體發炎、喘息性之氣管炎、上呼吸道感染等疾病，給以靜脈點滴方式每日一次使用。

5.4 門診診斷組方推斷

     門診診斷組方推斷，用於展示臨床疾病診斷與常用藥品、治療給合方案的相關性關聯，即如展示上呼吸道感染常使用氨酚麻美幹混懸劑1包、四季抗病毒合劑、0.9%氯化鈉注射液100ml+注射用頭孢硫咪1g、滅菌注射用水2ml+注射用重組人幹擾素a1b 10ug等這樣的組合治療方案。

5.5 醫學臨床系統整合

     為了實現來源於臨床系統，並且服務於臨床系統的總體系統，我們聯動了本院的HIS系統之中的門診醫生站，與本系統進行基於WebService的整合，如所示的整合介面：

     臨床醫生在完成基本的門診病曆之後，系統會自動為其體檢待選的門診疾病診斷，80%-90%的情況可以直接選擇，在少數情況下沒有推薦合適的時候大夫才會錄入，省去大夫錄入診斷的麻煩，也減少因大夫錄入的不規範而導致的資料的混亂。

     在臨床醫生寫完門診病曆，進行開立檢驗、檢查、用藥、治療的時間，系統會根據當有的診斷資訊進行推薦合適的治療方案選擇，臨床醫生只需求在右邊的推薦組方上雙擊即可實現快速的處方開方，大大的方便的臨床醫生的工作。

     針對中醫院，系統整合了3W多個經典成方，根據曆史資料與成方字典的組合分析對比，極大的方便中醫大夫日常工作：

六、實現細節、後續文章

     對於大資料技術，以及大資料技術在醫學化資訊行業的實踐，以及實現之中的思路和細節，不是短短的這麼一點篇幅就能介紹完成的，此文也是在我們實現需求，實踐之後所寫，所以總覺得東西都比較簡單，我只期望本文能達到拋轉引用的作用，能對同行做相關工作的朋友們有所參考，思路可以得到借鑒，然本文也實在沒有講清楚所有的細節。

     在接下來，我們專門寫一篇與本文使用的技術環境相匹配的一篇環境搭建、配置細節的文章，還請期待。

     有做相關業務的朋友可以聯絡我，進行相關的探討。

QQ:47920381

郵件:[email protected],

電話：18629261335。

大資料項目實踐：基於hadoop+spark+mongodb+mysql開發醫院臨床知識庫系統