如何在健康云上進行大數(shù)據(jù)的挖掘與分析

三、健康云上的大數(shù)據(jù)分析

由于醫(yī)療數(shù)據(jù)的一些特有的性質(zhì)，給健康云上的大數(shù)據(jù)分析帶來了特殊的挑戰(zhàn)。

1、 醫(yī)療數(shù)據(jù)是持續(xù)、大量增長的大數(shù)據(jù)。根據(jù)估算，中國一個中等城市(一千萬人口)50年所積累的醫(yī)療數(shù)據(jù)量就會達到10PB級。并且，隨著時間的推移和業(yè)務系統(tǒng)的不斷升級換代，醫(yī)療數(shù)據(jù)模式的一致性也無法保證。因此，每天都會有大量的數(shù)據(jù)持續(xù)不斷的導入?yún)^(qū)域醫(yī)療數(shù)據(jù)中心，并且每當有數(shù)據(jù)模式的更改，相關的歷史數(shù)據(jù)也需要做相應的調(diào)整。所以，區(qū)域醫(yī)療數(shù)據(jù)中心并不是簡單的傳統(tǒng)數(shù)據(jù)倉庫概念。相比之下，它的模式更靈活、寫入和更新的操作更多，而對數(shù)據(jù)存儲的水平可擴展性的要求也更高。

2、 醫(yī)療數(shù)據(jù)是關系復雜的多維數(shù)據(jù)。由于醫(yī)療數(shù)據(jù)是多種數(shù)據(jù)源數(shù)據(jù)的匯總，數(shù)據(jù)之間的關系非常復雜。比如：一個簡單的實驗室檢驗檢測值，必須同時記錄這個值對應的編碼系統(tǒng)和編碼、單位、檢測時間、檢驗項目、標本編碼，以及相關聯(lián)的患者主索引號、就診機構、申請科室、申請醫(yī)師標識號、報告醫(yī)師標識號、審核醫(yī)師標識號、正常值參考等等。一條檢測記錄就可以把患者、醫(yī)生、醫(yī)療機構多個實體在不同層次上關聯(lián)起來。而不同的醫(yī)療信息服務更需要從不同的視角來觀察這些數(shù)據(jù)，如下圖所示。比如：以患者為中心的服務需要把一個患者的全周期數(shù)據(jù)按照時間軸排列，并分析診斷、用藥和患者生命體征、檢驗檢測值之間的關聯(lián);以醫(yī)生為中心的服務又需要把與一個醫(yī)生相關的患者數(shù)據(jù)挑揀出來，并進行分類;以科室為中心的服務可能需要即從科室所屬醫(yī)生的角度，又要從在該科室就診患者的角度進行分析;針對社區(qū)的服務可能需要統(tǒng)計整個社區(qū)居民某項指標(比如血壓、血糖)的達標率?？傊?，醫(yī)療數(shù)據(jù)的多維度多粒度為各種信息服務的多角度多層次分析提供了可能，但同時也為大數(shù)據(jù)分析帶來了挑戰(zhàn)。因為我們不可能為每一種信息服務存儲一份特定的優(yōu)化模式的數(shù)據(jù)，況且我們也無法枚舉出所有可能的信息服務需求。這就需要醫(yī)療數(shù)據(jù)的存儲模型能夠適應靈活多變的多維統(tǒng)計分析需求。

3、 醫(yī)療數(shù)據(jù)是具有語義的數(shù)據(jù)。大家可能聽說過語義網(wǎng)(Semantic Web)，它是為讓數(shù)據(jù)能跨應用進行共享和重用所設計的框架體系。我們可以把語義網(wǎng)簡單地理解為：一個讓機器(machines)讀懂的維基百科(Wikipedia)，主要包括了各種條目的定義以及各個條目之間的關系。如果數(shù)據(jù)也采用這些條目和關系組織內(nèi)容，那么機器就可以自動理解數(shù)據(jù)的語義，并推理出各種知識。所以建立語義網(wǎng)的關鍵就是如何制作一本百科全書(有個專有名詞叫Ontology)。由于醫(yī)學是一門非常嚴謹?shù)目茖W，其在全球的標準化水平很高，對疾病名稱、藥物成分、臨床特征、儀器設備等都有嚴格的定義以及關聯(lián)描述。所以，語義網(wǎng)在醫(yī)學領域得到了廣泛應用。進而，醫(yī)療數(shù)據(jù)也越來越多的采用基于語義網(wǎng)的臨床文檔框架(CDA)格式的XML文檔來保存。這些XML文檔通過Ontology的解釋，就變成了一個無比巨大的概念+事實+關系的網(wǎng)絡。雖然機器能夠讀懂這個網(wǎng)絡，并能夠在上面進行邏輯推理，從而發(fā)現(xiàn)知識，但是其計算代價也是相當高的。當前的醫(yī)療系統(tǒng)通常會把復雜的臨床文檔解析成簡單的屬性值，并存入自定義的關系表中。這樣做雖然會有大量的語義及關系的丟失，但卻能夠滿足日常業(yè)務系統(tǒng)對數(shù)據(jù)處理性能的要求。但是對于未來的區(qū)域醫(yī)療信息系統(tǒng)來說，為了能夠提供豐富全面的信息服務，我們必須盡可能的保留臨床文檔中的語義信息。這樣，醫(yī)療數(shù)據(jù)分析的過程中就不可避免的需要對大量XML文檔進行解析、對各種關系進行推理。這樣的數(shù)據(jù)分析處理過程比我們之前提到的互聯(lián)網(wǎng)數(shù)據(jù)處理要復雜得多。

通過上述的分析可見，簡單地將現(xiàn)有的大數(shù)據(jù)分析技術套用在健康云服務上是行不通的。我們需要充分考慮健康云服務的特點和充分利用現(xiàn)有技術框架的靈活性，已達到最好的大數(shù)據(jù)分析性能。初步解決方案：

1. 基于Hadoop生態(tài)系統(tǒng)構建健康云數(shù)據(jù)中心，用以解決數(shù)據(jù)存儲水平擴展的挑戰(zhàn)。利用MapReduce并行處理批量事務的能力，從多個數(shù)據(jù)源(主要是醫(yī)療機構的各個業(yè)務系統(tǒng))抽取數(shù)據(jù)、轉換格式、并導入基于HBase的數(shù)據(jù)存儲模型。

2. 在數(shù)據(jù)存儲模型的設計上，借鑒已有的數(shù)據(jù)倉庫中多維數(shù)據(jù)模型的設計思想，比如：星型模式和數(shù)據(jù)立方體的概念。在考慮應用需求的基礎上，利用HBase中行鍵、列鍵、列族設計的靈活性，將多維醫(yī)療數(shù)據(jù)有效地組織在一起。而在索引技術上，結合RDBMS領域的成熟技術，用以進一步提高HBase的查詢性能。對于數(shù)據(jù)模式的更新，HBase特有的多版本共存的特性正好成了解決問題的關鍵。

3. 為了保留醫(yī)療數(shù)據(jù)中大量的語義關系，采用結構化數(shù)據(jù)+XML文檔混合存儲的方式。在數(shù)據(jù)導入的同時，提取XML文檔中特定的元數(shù)據(jù)，(比如：患者主索引、就診科室、主治醫(yī)師等)，并將XML文檔根據(jù)不同粒度打散成大小不一的子文檔。根據(jù)不同粒度的查詢條件，系統(tǒng)將自動選擇相應的子文檔進行進一步信息的解析，從而避免為提取少量信息而不得不解析大量XML文檔的問題。

4. 數(shù)據(jù)模型的接口將采用Hive提供的類SQL查詢的方式。這樣更有利于數(shù)據(jù)分析人員設計分析算法。同時，系統(tǒng)中將嵌入多種數(shù)據(jù)挖掘算法供數(shù)據(jù)分析師使用。

綜上所述，為解決健康云上的大數(shù)據(jù)分析問題，必須同時利用RDBMS和NoSQL的優(yōu)勢，并且采用結構化和非結構化數(shù)據(jù)混合存儲的形式，相互彌補缺陷，已達到最靈活和最高效的設計。而這套基于健康云的大數(shù)據(jù)分析平臺，也將有希望擴展到其他類似行業(yè)，比如：電信、能源、物聯(lián)網(wǎng)和公共事業(yè)等。