醫(yī)療大數(shù)據(jù)分析應(yīng)用平臺建設(shè)項目關(guān)鍵核心技術(shù)和算法眾多海量醫(yī)藥醫(yī)療數(shù)據(jù)為大數(shù)據(jù)管理與處理平臺提出了諸多技術(shù)挑戰(zhàn)。第一，由于數(shù)據(jù)是不斷累積的，平臺需具備高可擴展性；第二，存儲層應(yīng)適應(yīng)不同的存取訪問需求.實時應(yīng)用如醫(yī)院的掛號和收費系統(tǒng)等，主要涉及小量數(shù)據(jù)的讀取與寫入，要求后端存儲能夠快速讀寫;復(fù)雜應(yīng)用如醫(yī)療歷史數(shù)據(jù)挖掘等，涉及大量數(shù)據(jù)的讀取，要求后端存儲實現(xiàn)高吞吐量讀取；第三，由于醫(yī)療數(shù)據(jù)關(guān)乎人的生命，需要保證平臺的高容錯與高可用性，能夠應(yīng)對常態(tài)化的出錯問題。1.1大數(shù)據(jù)分析能力大數(shù)據(jù)分析能力體現(xiàn)在五個基本方面：大數(shù)據(jù)可視化分析能力大數(shù)據(jù)分析的使用者有大數(shù)據(jù)分析專家，同時還有普通用戶，二者對于大數(shù)據(jù)分析最基本的要求就是可視化分析。大數(shù)據(jù)挖掘發(fā)現(xiàn)能力大數(shù)據(jù)分析的理論核心就是數(shù)據(jù)挖掘算法，被全世界統(tǒng)計學(xué)家所公認(rèn)的各種統(tǒng)計方法才能深入數(shù)據(jù)內(nèi)部，更快速的處理大數(shù)據(jù)，挖掘出公認(rèn)的價值；如果一個算法得花上好幾年才能得出結(jié)論，那大數(shù)據(jù)的價值就減弱了。大數(shù)據(jù)預(yù)測趨勢能力大數(shù)據(jù)分析最重要的應(yīng)用領(lǐng)域之一就是預(yù)測性分析，從大數(shù)據(jù)中挖掘出特點，通過科學(xué)的建立模型，之后便可以通過模型帶入新的數(shù)據(jù)，從而預(yù)測未來的數(shù)據(jù)。 大數(shù)據(jù)語義引擎能力大數(shù)據(jù)分析廣泛應(yīng)用于網(wǎng)絡(luò)數(shù)據(jù)挖掘，可從用戶的搜索關(guān)鍵詞、標(biāo)簽關(guān)鍵詞、或其他輸入語義，分析，判斷用戶需求。大數(shù)據(jù)質(zhì)量和管理能力大數(shù)據(jù)分析離不開數(shù)據(jù)質(zhì)量和數(shù)據(jù)管理，高質(zhì)量的數(shù)據(jù)和有效的數(shù)據(jù)管理，無論是在學(xué)術(shù)研究還是在商業(yè)應(yīng)用領(lǐng)域，都能夠保證分析結(jié)果的真實和有價值。1.2大數(shù)據(jù)分析技術(shù)數(shù)據(jù)采集：ETL工具負責(zé)將分布的、異構(gòu)數(shù)據(jù)源中的數(shù)據(jù)如關(guān)系數(shù)據(jù)、平面數(shù)據(jù)文件等抽取到臨時中間層后進行清洗、轉(zhuǎn)換、集成，最后加載到數(shù)據(jù)倉庫或數(shù)據(jù)集市中，成為聯(lián)機分析處理、數(shù)據(jù)挖掘的基礎(chǔ)。數(shù)據(jù)存取：關(guān)系數(shù)據(jù)庫、NOSQL、SQL等。基礎(chǔ)架構(gòu)：云存儲、分布式文件存儲等。數(shù)據(jù)處理：自然語言處理技術(shù)、人工智能等統(tǒng)計分析：假設(shè)檢驗、顯著性檢驗、差異分析、相關(guān)分析、T檢驗、方差分析、卡方分析、偏相關(guān)分析、距離分析、回歸分析、簡單回歸分析、多元回歸分析、逐步回歸、回歸預(yù)測與殘差分析、logistic回歸分析、曲線估計、因子分析、聚類分析、主成分分析、因子分析、快速聚類法與聚類法、判別分析、對應(yīng)分析、多元對應(yīng)分析（最優(yōu)尺度分析）、bootstrap技術(shù)等。數(shù)據(jù)挖掘：分類、估計、預(yù)測、相關(guān)性分組或關(guān)聯(lián)規(guī)則、聚類、描述和可視化、復(fù)雜數(shù)據(jù)類型(Text，Web，圖形圖像，視頻，音頻等)挖掘。模型預(yù)測：預(yù)測模型、機器學(xué)習(xí)、建模仿真。結(jié)果呈現(xiàn)：云計算、標(biāo)簽云、關(guān)系圖等。1.3大數(shù)據(jù)存儲技術(shù)和系統(tǒng)在數(shù)據(jù)存儲系統(tǒng)體系結(jié)構(gòu)方面，以大量廉價服務(wù)器組成無共享(shared-nothing)集群的方式逐漸成為主流。這種體系結(jié)構(gòu)易于實現(xiàn)高可用、高性能、漸進可擴展的存儲系統(tǒng)，并且由于存儲資源與計算資源緊密耦合，在擴充存儲容量的同時，計算能力也能夠同步增強，能夠避免\存得下，算不出"的問題。在軟件方面，文件存儲是最基本的數(shù)據(jù)存儲方式。文件存儲的優(yōu)點是訪問接口簡單，文件格式可以由使用者靈活定義，因此文件存儲往往作為更高級的數(shù)據(jù)管理系統(tǒng)的底層存儲服務(wù)。目前能夠存儲超大規(guī)模數(shù)據(jù)的文件存儲系統(tǒng)包括Lustre、Googlefilesystem(GFS)、Hadoopdistributedfilesystem(HDFS)以及AmazonS3等。它們的共同特點是基于無共享架構(gòu)、能夠管理數(shù)百乃至數(shù)千存儲節(jié)點、自動維護數(shù)據(jù)冗余或副本、高并發(fā)順序訪問吞吐率等。1.4大數(shù)據(jù)業(yè)務(wù)模型建模在更高級的數(shù)據(jù)管理方面，最重要的數(shù)據(jù)管理系統(tǒng)是以關(guān)系數(shù)據(jù)模型為基礎(chǔ)的關(guān)系數(shù)據(jù)庫系統(tǒng)(RDBMS)。關(guān)系數(shù)據(jù)模型最主要的優(yōu)點之一是具有與一階邏輯體系同等強大的知識表達能力，這意味著現(xiàn)實中的許多查詢都可以用關(guān)系代數(shù)描述。此外，使用關(guān)系數(shù)據(jù)模型，用戶能夠方便地為各種對象以及對象之間的聯(lián)系設(shè)計邏輯模型而無需了解數(shù)據(jù)庫的實現(xiàn)細節(jié)。因此，在21世紀(jì)之前，關(guān)系數(shù)據(jù)庫被廣泛應(yīng)用于各類信息系統(tǒng)，如醫(yī)院常用的電子病歷系統(tǒng)、臨床信息系統(tǒng)、用藥管理系統(tǒng)、ICU監(jiān)護系統(tǒng)等。關(guān)系數(shù)據(jù)模型雖然具有諸多優(yōu)點，但要實現(xiàn)一個高效率的關(guān)系數(shù)據(jù)庫系統(tǒng)卻并不容易。這主要是因為:(1)為保證關(guān)系數(shù)據(jù)模型功能的完整性，很多數(shù)據(jù)操作難以進行專門優(yōu)化;(2)為保證事務(wù)處理的原子性、一致性、分離性和持久性，帶來了大量的額外開銷。因此在管理大數(shù)據(jù)時，以O(shè)racledatabase、SQLserver、MySQL為代表的傳統(tǒng)關(guān)系數(shù)據(jù)庫常常成為性能瓶頸。這些系統(tǒng)的低效不僅表現(xiàn)為查詢速度慢，而且數(shù)據(jù)加載與建立索引的過程也十分漫長。由于原始數(shù)據(jù)和數(shù)據(jù)處理的中間結(jié)果大部分是非結(jié)構(gòu)化(unstructured)數(shù)據(jù)或半結(jié)構(gòu)化(semi-structured)數(shù)據(jù)，如網(wǎng)頁、日志、文檔、圖片、視頻等，傳統(tǒng)關(guān)系數(shù)據(jù)庫被認(rèn)為不適用于存儲這類數(shù)據(jù)，因此需要使用其他類型的數(shù)據(jù)管理系統(tǒng)。現(xiàn)有的針對此類數(shù)據(jù)的管理系統(tǒng)被籠統(tǒng)地稱為NoSQL數(shù)據(jù)庫，按照數(shù)據(jù)模型分類，可以分為以下3種(按照數(shù)據(jù)模型由簡單至復(fù)雜的順序排列)。鍵-值存儲系統(tǒng):鍵-值(key-value)數(shù)據(jù)模型將數(shù)據(jù)表示為鍵與值的映射關(guān)系。所有的鍵|值存儲系統(tǒng)都支持的基本操作是給定一個鍵，查找其對應(yīng)的值。當(dāng)鍵上可以定義比較關(guān)系時，有些系統(tǒng)也支持鍵上的范圍查詢(rangequery)。鍵-值模型功能簡單和易于實現(xiàn)，鍵-值存儲系統(tǒng)一般具有極佳的可擴展能力和訪問性能，因此多用于支持高并發(fā)的Web服務(wù)查詢或作為其他存儲系統(tǒng)的高性能緩存。目前主流的分布式鍵|值存儲系統(tǒng)包括Amazondynamo、Redis、MemcacheDB等。列族存儲系統(tǒng):列族(column-family)數(shù)據(jù)模型是在鍵-值模型基礎(chǔ)上，將值定義為列族的集合，每個列族可以包含多個相關(guān)屬性列。與鍵-值存儲系統(tǒng)相比，列族存儲系統(tǒng)支持的基本操作也是按值查找和范圍查詢，但允許用戶指定返回的結(jié)果中所需包含的屬性列，因此更加靈活易用，并且在僅用到小部分屬性列的情況下查詢性能更好。近10年來，最具代表性的大規(guī)模列族存儲系統(tǒng)是Googlebigtable，類似的系統(tǒng)包括HBase和Hypertable等。文檔存儲系統(tǒng):文檔(document-oriented)數(shù)據(jù)模型也可視為鍵-值模型的擴展，與列族模型不同的是它將值定義為類似廣義表的數(shù)據(jù)結(jié)構(gòu)。從抽象的角度看，列族模型是一種特殊的文檔模型。文檔存儲系統(tǒng)除了支持基于鍵的查詢，一般還允許用戶指定值上的過濾條件(取決于具體系統(tǒng)實現(xiàn))，但更為靈活的數(shù)據(jù)結(jié)構(gòu)需要更多空間存儲以及更長時間解析，其查詢速度通常比列族存儲系統(tǒng)慢。目前主流的文檔存儲系統(tǒng)包括MongoDB、CouchDB、ApacheCassandra等。相比關(guān)系數(shù)據(jù)庫，NoSQL數(shù)據(jù)庫采用了較為簡單的數(shù)據(jù)模型。這樣做的好處是能夠為特定的查詢(如按鍵檢索)進行優(yōu)化，極大地提高查詢性能，從而具備非常好的可擴展性，能夠應(yīng)用于超大規(guī)模的數(shù)據(jù)。另一方面，NoSQL數(shù)據(jù)庫僅能支持關(guān)系數(shù)據(jù)庫能夠支持的數(shù)據(jù)操作的一個很小的子集，例如大多數(shù)NoSQL數(shù)據(jù)庫不支持關(guān)聯(lián)查詢(join)。當(dāng)進行NoSQL數(shù)據(jù)庫不支持的查詢時，用戶只能自行編寫代碼以滿足需要。在醫(yī)療服務(wù)中產(chǎn)生的數(shù)據(jù)類型多樣，既有適合關(guān)系數(shù)據(jù)模型描述的結(jié)構(gòu)化數(shù)據(jù)，也有圖片和文本等多種非結(jié)構(gòu)化數(shù)據(jù)。這種異構(gòu)性為醫(yī)療大數(shù)據(jù)的管理帶來了很大的挑戰(zhàn)。許多關(guān)鍵業(yè)務(wù)數(shù)據(jù)要求數(shù)據(jù)管理系統(tǒng)支持原子性(atomicity)、一致性(consistency)、完整性(isolation)和隔離性(durability)，而支持ACID的關(guān)系數(shù)據(jù)庫系統(tǒng)不適合存儲非結(jié)構(gòu)化數(shù)據(jù)。一種解決方案是采用兩套系統(tǒng)分別存儲結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)，但這為兩種數(shù)據(jù)之間進行聯(lián)接查詢(join)帶來了困難。例如，當(dāng)要尋找某科室患者的所有CT影像圖片時，需要首先在業(yè)務(wù)數(shù)據(jù)庫中查詢到該科室所有患者的ID，然后再到非結(jié)構(gòu)化數(shù)據(jù)庫中查找圖片。這種跨數(shù)據(jù)庫的聯(lián)接查詢的執(zhí)行效率不高。因此，就醫(yī)療大數(shù)據(jù)而言，需要研究一種基于混合數(shù)據(jù)模型的數(shù)據(jù)管理系統(tǒng)，能夠高效管理結(jié)構(gòu)化數(shù)據(jù)與非結(jié)構(gòu)化數(shù)據(jù)，并支持異構(gòu)數(shù)據(jù)之間的高效混合查詢。1.5大數(shù)據(jù)的實時查詢醫(yī)療服務(wù)對時效性的要求很高，很多查詢都要求得到實時響應(yīng)。智慧醫(yī)療中涉及實時查詢的可大致分為:(1)與時間有關(guān)的查詢，如檢索監(jiān)護對象某一時間段內(nèi)的全部信息;(2)與空間有關(guān)的查詢，例如檢索監(jiān)護對象在某個區(qū)域(如某個醫(yī)院)內(nèi)的全部信息;(3)與特定屬性有關(guān)的查詢，例如檢索監(jiān)護對象的血壓變化歷史和用藥記錄等;(4)綜合查詢，例如檢索監(jiān)護對象在某段時間和某個區(qū)域內(nèi)的某項生命體征數(shù)據(jù)。高效實時查詢的關(guān)鍵是必須預(yù)先了解查詢類型并建立所需的索引。當(dāng)數(shù)據(jù)規(guī)模非常大時，現(xiàn)有數(shù)據(jù)庫采用的索引技術(shù)基本能夠滿足數(shù)據(jù)檢索的實時性需要，但在索引的創(chuàng)建與更新的性能方面有較大不足。例如，我們的測試結(jié)果表明，用一臺運行PostgreSQL的服務(wù)器為200萬條數(shù)據(jù)(約1GB)在一個空間屬性上創(chuàng)建R-tree索引，用時約為20分鐘;在此基礎(chǔ)上再次插入40萬條數(shù)據(jù)(約0.2GB)，用時約為60分鐘。根據(jù)這個結(jié)果，當(dāng)數(shù)據(jù)產(chǎn)生的速度大于960萬條/天時，即使服務(wù)器的全部計算資源都用于維護索引，索引的更新速度仍將落后于數(shù)據(jù)產(chǎn)生的速度。而如果1個醫(yī)療傳感器每15秒產(chǎn)生1條測量數(shù)據(jù)，1萬個這樣的傳感器每天將產(chǎn)生超過5000萬條數(shù)據(jù)。這意味著現(xiàn)有的索引更新方法無法勝任醫(yī)療大數(shù)據(jù)處理的需求。此外，是一種常用的避免更新索引的方法是在插入新數(shù)據(jù)之前刪除索引并在之后重新創(chuàng)建索引，但這種方法不能從根本上解決問題，因為隨著數(shù)據(jù)不斷累積，重新創(chuàng)建索引所用的時間越來越長，最終會比更新索引的速度更慢。為滿足大數(shù)據(jù)實時查詢的需要，必須對現(xiàn)有的索引技術(shù)必須加以改進，將索引的創(chuàng)建與更新速度提高至少一個數(shù)量級。索引更新速度慢的一個重要原因是數(shù)據(jù)逐條添加時引發(fā)了多次隨機小量寫操作，因此首先需要重新設(shè)計索引結(jié)構(gòu)，使其能夠批量添加數(shù)據(jù)(bulk-insertion)，盡量用順序?qū)懭氪髩K數(shù)據(jù)取代隨機寫入小塊數(shù)據(jù)。另外，需要設(shè)計索引的并行創(chuàng)建與更新算法，使索引的創(chuàng)建與更新能夠在無共享架構(gòu)中水平擴展。1.6大數(shù)據(jù)的復(fù)雜分析在智慧醫(yī)療中，有很多復(fù)雜的數(shù)據(jù)分析查詢，以下僅舉幾例:(1)醫(yī)療數(shù)據(jù)統(tǒng)計，如統(tǒng)計歷年慢性病比例變化和各地區(qū)心腦血管疾病分布等;(2)相似聯(lián)接查詢(similarityjoin)，如根據(jù)CT成像圖片，尋找相似的病例與診斷，尋找骨髓移植匹配等;(3)醫(yī)療數(shù)據(jù)挖掘與預(yù)測，如尋找亞健康狀況與職業(yè)、性別、年齡等因素的聯(lián)系和預(yù)測下一個月各類藥品的需求等。這些復(fù)雜分析查詢的主要特點有:需要讀取大量數(shù)據(jù)，所需計算時間長;查詢靈活多變，難以預(yù)測;涉及多學(xué)科交叉，需要醫(yī)療、統(tǒng)計、計算機等各領(lǐng)域的專業(yè)人士協(xié)作完成。傳統(tǒng)關(guān)系數(shù)據(jù)庫與NoSQL數(shù)據(jù)庫難以勝任復(fù)雜的數(shù)據(jù)分析，其原因主要有兩個。首先，它們在維護數(shù)據(jù)庫的原子性、一致性、分離性和持久性方面花費了巨大的開銷，而在進行復(fù)雜的數(shù)據(jù)分析時，數(shù)據(jù)往往是靜態(tài)的，因此這些開銷是不必要的。第二，它們的存儲與索引結(jié)構(gòu)是為數(shù)據(jù)的隨機讀寫與頻繁更新而設(shè)計，沒有為大量數(shù)據(jù)的讀取進行專門優(yōu)化。目前，對大數(shù)據(jù)進行復(fù)雜分析的工具主要有兩大類。一類是并行分析型數(shù)據(jù)庫，另一類是基于MapReduce的數(shù)據(jù)分析工具。分析型數(shù)據(jù)庫基于關(guān)系數(shù)據(jù)模型，與傳統(tǒng)關(guān)系數(shù)據(jù)庫相比，其存儲結(jié)構(gòu)與查詢算法為數(shù)據(jù)讀取進行了專門優(yōu)化，如用列式存儲(column-store)替代行式存儲(row-store)。目前主流的并行分析型數(shù)據(jù)庫的有Vertica和Greenplum等。這些數(shù)據(jù)庫提供的用戶接口是與傳統(tǒng)關(guān)系數(shù)據(jù)庫相同的結(jié)構(gòu)化查詢語言(SQL)。這種實現(xiàn)方式降低了用戶的學(xué)習(xí)成本，但也帶來了兩個問題。首先，雖然關(guān)系數(shù)據(jù)模型能夠進行擴展以表示非結(jié)構(gòu)化數(shù)據(jù)，但由于數(shù)據(jù)種類繁多，目前缺少足夠有效的理論與工具將非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)化為結(jié)構(gòu)化數(shù)據(jù);第二，一些復(fù)雜的數(shù)據(jù)分析難以直接用SQL描述，即使能夠用SQL描述，其執(zhí)行效率也比專門編寫的過程化分析程序要低得多。MapReduce是Google于2003年提出的一種新的基于無共享架構(gòu)的并行計算范式。與傳統(tǒng)并行計算范式(如MPI)相比，MapReduce簡化了并行數(shù)據(jù)處理算法的設(shè)計與實現(xiàn)，使用者僅需根據(jù)查詢需要定義map和reduce兩個函數(shù)，無需關(guān)心并行執(zhí)行過程中的任務(wù)調(diào)度、資源管理以及出錯處理等問題。MapReduce最初是為處理Google的海量文本數(shù)據(jù)的簡單分析算法而設(shè)計。隨著ApacheHadoop項目提供的MapReduce開源實現(xiàn)在學(xué)術(shù)界與工業(yè)界廣泛使用，MapReduce編程模型被證明十分靈活。我們不僅可以在其上構(gòu)建分析型數(shù)據(jù)庫(如HadoopHive)，而且能夠?qū)崿F(xiàn)常用的數(shù)據(jù)挖掘與機器學(xué)習(xí)算法程序庫(如ApacheMahout)。從大數(shù)據(jù)分析性能的角度看，數(shù)據(jù)庫專家們對并行分析型數(shù)據(jù)庫與MapReduce的優(yōu)劣曾經(jīng)有過長達數(shù)年的爭論。隨著對兩者研究的深入，目前已取得的主要共識有:對于簡單的結(jié)構(gòu)化查詢，當(dāng)計算節(jié)點較少時(100臺或以下)，并行分析型數(shù)據(jù)庫由于采取了更優(yōu)化的存儲結(jié)構(gòu)與查詢算法，性能明顯優(yōu)于MapReduce;當(dāng)計算節(jié)點較多時，此時計算節(jié)點出錯的概率很高，并行分析型數(shù)據(jù)庫在出錯時往往需要重新執(zhí)行整個查詢，性能會受到較大影響，而MapReduce的設(shè)計從一開始就將常態(tài)化的出錯問題納入考慮，因此能夠輕松擴展到數(shù)千臺節(jié)點;并行分析型數(shù)據(jù)庫必須預(yù)先加載數(shù)據(jù)，而數(shù)據(jù)加載的時間通常十分漫長，因此對于日志分析等僅需讀取一次數(shù)據(jù)的任務(wù)并不合適;MapReduce比并行分析型數(shù)據(jù)庫的應(yīng)用更廣