醫療大數據平臺數據高并發方案設計與關鍵技術分析

張 偉

(中國大唐集團科學技術研究院有限公司，北京 100040)

0 引言

中國人口老齡化加速、慢性病人數劇增以及社會生活水平的提高，人們對醫療服務的需求越來越高，同時醫療資源緊缺且分配不均，供需矛盾日益凸顯，利用信息化手段提高醫療行業的服務范圍和服務水平已經迫在眉睫。

醫療大數據平臺是通過使用移動通信技術(例如 IPDA、移動電話和衛星通信)來提供醫療服務和信息。隨著全球智能手機和新型創新連接設備普及率的日漸提高以及移動寬帶網絡和服務的拓展，醫療大數據平臺無疑將在未來的醫療健康行業發揮重要作用。移動互聯網、物聯網等相關技術與預防及臨床醫學相結合，可以為廣大民眾提供隨時隨地的健康關愛服務。可以說醫療大數據平臺的出現給整個醫療健康行業帶來了前所未有的新體驗，也促使著醫療健康行業面向信息化、移動化的方向發展。

醫療大數據應用是典型的面向互聯網大眾用戶應用，因此大數據量和高并發的要求比較高。集群技術和負載均衡技術作為業界通用的高并發解決技術會有廣泛的用武之地，但這些技術相對來說在開發、部署、運維等方面需要較高的人工成本和技術門檻。近年隨著互聯網技術的飛速發展，針對系統的高并發問題，涌現出越來越多的開源解決方案。這些解決方案在不同的行業應用中已經得到了生產環境的充分驗證[1]。作為醫療業務應用來說，需要結合行業領域的數據和業務特點，有針對性地對技術進行選型。本文將結合作者近幾年在移動健康業務系統開發領域的工作實踐和對現階段主流開源開發技術的應用，在對移動健康業務系統的數據和業務特點深入理解和分析的基礎上，從開源技術角度對端到端的高并發問題詳細描述技術選型和個人應用實踐經驗。

1 醫療大數據平臺高并發需求分析

1.1 醫療大數據平臺數據和業務特點

任何行業的互聯網應用都面臨著大數據和高并發的挑戰，隨著互聯網技術的發展，針對高并發問題，業界各類互聯網應用充分利用新興互聯網技術進行了非常有效的實踐[2]。這些實踐經驗和技術成果對于我們開發移動健康業務系統有很好的借鑒意義。但同時也要看到，醫療大數據平臺有自己特有的數據和業務特點，這些特點對我們解決高并發問題在技術選型上有重要的指導意義。醫療大數據平臺的數據和業務特點如下：

(1)需要采集各種體征數據的醫療業務系統需要通過各類便攜式終端采集用戶的體征數據，如血壓、血糖、心電、睡眠、運動情況等。業務系統基于這些信息提供各類業務功能給用戶使用。移動健康業務系統需要解決好這些數據的高并發傳輸問題。

(2)數據庫事務一致性需求。業務系統并不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數據庫事務管理成了數據庫高負載下一個沉重的負擔。

(3)數據庫的寫實時性和讀實時性需求。移動健康業務系統圍繞體征數據展開各類業務流程，在對數據層的查詢上一般是一次錄入多次讀取，相比其他業務系統如銀行、網購等行業應用，業務系統在數據傳輸的實時性要求上也不需要太過苛刻。對關系數據庫來說，插入一條數據之后立刻查詢，可以很快讀出來這條數據，但是對于移動健康業務系統來說，并不要求這么高的實時性。

(4)對復雜的SQL查詢，特別是多表關聯查詢的需求。任何大數據量的Web系統，都非常忌諱多個大表的關聯查詢以及復雜的數據分析類型的復雜SQL報表查詢，從需求以及產品設計角度，就避免了這種情況的產生。業務系統往往更多地只是單表的主鍵查詢以及單表的簡單條件分頁查詢，SQL的功能被極大地弱化了。

1.2 醫療大數據平臺高并發需求

本小節對醫療大數據平臺的體系架構進行簡要描述，并對分層對高并發需求進行分析。醫療大數據平臺典型體系架構如圖1所示。

圖1 移動健康業務系統架構圖

圖1中數據采集層、數據存儲層、業務處理層是高并發問題最集中的三層，其高并發需求的詳細分析如下：

(1)數據采集層：移動系統需求采集各類可穿戴設備的體征數據，這些設備包括計步器、血壓計、血糖儀、手環、心電終端、智能手機等。從數據形式上來看，采集的體征數據有二進制格式和字符串格式，相應的數據采集層需要提供TCP/UDP或者HTTP協議的接口接收數據，并根據相應的權限對外開放查詢接口供外部系統查詢，或者傳輸數據到某個具體的業務應用。

本層的高并發主要在于數據量比較大。以計步器為例，不考慮重復上傳和用戶手動上傳的情況，每個計步器每天需要自動定時上傳5～6條簡要包數據和24條分小時的詳細包數據。這樣算來，僅僅1萬用戶每天就需要上傳近30萬條計步數據，用戶量大的時候，高并發需求凸顯。

(2)數據存儲層：數據存儲層存儲采集層接收到的各類體征數據以及業務處理層生成的各類業務數據，這些數據提供了數據挖掘和業務處理的支撐。數據量巨大是本層的主要特點。如果用戶量比較大，在海量數據的基礎上進行查詢，數據存儲層的查詢效率將是一個很大的挑戰，處理不好就會成為系統的性能瓶頸。

(3)業務處理層：業務處理層需要基于產品設計開發各類業務應用的訪問接口，實現用戶的各類業務需求。首先是海量用戶的并發訪問給業務處理層提出了挑戰，需要充分利用良好的技術架構和緩存技術進行解決[3]。其次，業務處理層會有許多統計分析類功能，它們要在海量數據查詢的基礎之上進行大量耗時比較長的復雜運算，這些功能需要充分利用分布式并行技術提高運算效率。

2 醫療大數據平臺高并發解決方案

2.1 數據采集層

2.1.1二進制數據接收

二進制數據需要通過TCP/UDP協議傳輸，通常的做法是利用socket編程來實現。然而不管采用TCP還是UDP協議的socket編程，可穿戴健康設備和數據采集層接口之間都是同步阻塞式 IO 的，每個傳輸由單獨的線程實現。雖然可以通過多線程實現同時接收多個客戶端數據，但隨著并發量的增大，服務器開啟的線程數目會增多，將會消耗過多的服務器內存資源，導致服務器變慢甚至崩潰。因此在大量可穿戴健康設備連接數據采集層接口的時候，高并發問題會凸顯出來，導致大量的傳輸連接請求被拒絕。

分析可穿戴健康設備上傳的數據不難發現，單個客戶端每次傳輸的數據并不大，需要的鏈接時間很小，但并發量比較大，非阻塞式IO傳輸正適合此類型的數據傳輸。作為TCP/UDP 協議級別的非阻塞式IO傳輸，目前比較流行的開源框架有Netty和Mina框架。這兩個框架都是由同一個人開創的，在設計理念等方面比較類似，并發性能上都可以滿足實際需求。

下面以 Mina 為例簡述一下此開源技術是如何解決高并發問題的。Apache Mina 是一個網絡通信應用框架，它主要是針對基于TCP/ UDP協議棧的通信框架，Mina可以幫助我們快速開發高性能、高擴展性的網絡通信應用，提供了事件驅動、異步操作的編程模型。Mina是介于用戶業務和底層的socket之間的中間層,它簡單易用，幫助實現下層的NIO處理細節，讓開發者把關注點放在具體的業務實現上。

2.1.2字符串數據接收

作為字符串形式的數據接收，一般需要高層通信協議，比如SOAP、HTTP等，通常的架構設計是采用RPC方式，如圖2所示。

圖2 RPC方式交互數據圖

如果使用RPC方式建立可穿戴設備和服務器的連接，由于可穿戴設備必須阻塞式的等待服務器返回數據處理結果，在高并發情況下將會嚴重影響執行效率和資源使用率，給服務器造成很大壓力。

分析此類數據不難發現，可穿戴設備要把數據傳輸給服務器，只需要把相關信息封裝到數據中，不需要關心服務器對數據的接收處理細節，因此為了提高并發能力，需要采用圖3所示松耦合的技術架構。

圖3 消息隊列方式交互數據圖

客戶端A向消息中介(Queue)發送一條消息，很可能一段時間之后，客戶端B調用Queue來收取消息。任何一個應用程序都不知道對方是否存在，也不需要阻塞等待。這種通信方式大大縮減了維護開銷，而且對于一個應用程序的修改對其他應用程序影響極小。基于這種松耦合的消息方式的開源技術有很多，比如ActiveMQ、RabbitMQ、ZeroMQ等。

以ActiveMQ為例，它是一種開源的實現了JMS1.1規范的面向消息的中間件，為應用程序提供高效、可擴展、穩定和安全的企業級消息通信。它支持兩種截然不同的消息傳送模型：PTP(即點對點模型)和Pub/Sub(即發布/訂閱模型，并且可以持久化數據，保障數據的安全性)。

2.2 數據存儲層

移動健康業務系統作為一個基于大數據高并發的互聯網產品，數據存儲層的選擇非常關鍵，如何保障對業務處理層的高并發的數據支持是核心問題。目前數據存儲層主要有關系型數據庫和 NOSQL 數據庫。下面將對兩種數據庫技術的優缺點以及使用注意事項等進行分析并給出實踐經驗。

2.2.1關系型數據庫

關系型數據庫已經在信息系統開發領域被使用多年，它基于標準SQL語句實現了靈活的數據增、刪、查、改、統計等操作，并提供了良好的事務處理機制[4]。用的比較多的關系型數據庫有Oracle、SQL Server、MySQL等。在數據量比較大的時候，雖然數據庫提供了分區、索引等技術提高查詢效率，但性能上還是很難滿足互聯網業務系統的高并發要求。

在關系型數據庫支撐高并發方面，需要充分使用好分區、索引、集群等技術。阿里巴巴公司對MySQL的使用非常成功，他們充分利用MySQL的集群技術形成了大型關系數據庫集群，并開發了數據庫和應用層之間的中間層，為應用層屏蔽了數據庫層的復雜性。相對來說，關系型數據庫的性能優化對技術的要求比較高，要做到大型關系型數據庫集群是比較難的。在移動健康業務系統建設初期，用戶量還不多，并發要求還不太高，為了快速開發上線系統，這時候可以優先采用關系型數據庫。另外需要處理對于事務性要求比較高的業務時需要采用關系型數據庫。

2.2.2非關系型數據庫

隨著互聯網Web2.0網站的興起，非關系型的數據庫現在成了一個極其熱門的新領域，非關系數據庫產品的發展非常迅速，而傳統的關系型數據庫在應付Web2.0網站，特別是超大規模和高并發的Web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題。作為移動健康業務系統也是如此。

(1)對數據庫高并發讀寫的需求

因需要根據用戶個性化信息來實時生成動態頁面和提供動態信息，所以基本上無法使用動態頁面靜態化技術，因此數據庫并發負載非常高，往往要達到每秒上萬次讀寫請求。關系型數據庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫數據請求，硬盤 IO 就已經無法承受了。

(2)對海量數據的高效率存儲和訪問的需求

對于大型網站，每天用戶產生海量的用戶動態信息，以國外的Friend Feed為例，一個月就達到了2.5億條用戶動態數據，對于關系數據庫來說，在一張具有2.5 億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型Web網站的用戶登錄系統，例如騰訊、盛大，動輒數以億計的賬號，關系數據庫也很難應付。

(3)對數據庫的高可擴展性和高可用性的需求

在基于Web的架構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，數據庫卻沒有辦法像Web server和app server那樣簡單地通過添加更多的硬件和服務節點來擴展性能和負載能力。對于很多需要提供 24 小時不間斷服務的網站，它們對數據庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移，使得公司業務中斷，造成經濟損失。

以上提到的“三高”需求是關系數據庫難以克服的障礙，對于移動健康業務系統，關系數據庫很難滿足這些應用需求。而NOSQL數據庫是近些年隨著大數據技術的廣泛應用發展起來的，因其易于擴展、大數據量高并發、高可用性等優勢，目前已被知名的互聯網公司廣泛使用。例如，列存儲數據庫HBase、文檔型數據庫MongoDB、CouchDB，key-value數據庫MemcacheDB、Redis等。

文檔型數據庫MongoDB可以說是最像關系型數據庫的 NOSQL 數據庫，甚至可以從搜索網站上搜索到MongoDB和常用標準SQL的對應關系。因此本文重點推薦存儲層用MongoDB 數據庫。

MongoDB是一個介于關系數據庫和非關系數據庫之間的產品，是非關系數據庫當中功能最豐富、最像關系數據庫的。它支持的數據結構非常松散，類似JSON的BJSON格式，因此可以存儲比較復雜的數據類型。MongoDB最大的特點是支持的查詢語言非常強大，其語法有點類似于面向對象的查詢語言，幾乎可以實現類似關系數據庫單表查詢的所有功能，而且還支持對數據建立索引。它是一個面向集合的模式自由的文檔型數據庫。MongoDB 主要功能如下：

(1)完整的索引支持：包括文檔內嵌對象及數組。MongoDB 的查詢優化器會分析查詢表達式，并生成一個高效的查詢計劃。

(2)復制及自動故障轉移：MongoDB 數據庫支持服務器之間的數據復制，支持主-從模式及服務器之間的相互復制。復制的主要目標是提供冗余及自動故障轉移。

(3)高效的傳統存儲方式：支持二進制數據及大型對象(如照片或圖片) 。

(4)自動分片和副本集技術支持云級別的伸縮性：自動分片功能支持水平的數據庫集群，可動態添加額外的機器。

2.3 業務處理層

2.3.1數據緩存的使用

數據緩存技術是解決 Web 應用程序可擴展性、數據響應及時性以及減輕服務器負載、降低網絡擁塞的主要手段之一。最常用的場景如下：

(1)緩存數據庫的查詢結果，減少數據的壓力。

(2)緩存磁盤文件的數據。常用的數據可以放到內存，不用每次都去讀取磁盤，特別是密集計算的程序，比如中文分詞的詞庫。

(3)緩存某個耗時的計算操作，比如數據統計。

目前流行的應用層緩存技術有Squid、Varnish、nginx等，本文重點推薦內存數據庫 Redis。Redis數據庫中的所有數據都存儲在內存中。由于內存的讀寫速度遠快于硬盤，因此 Redis在性能上對比其他基于硬盤存儲的數據庫有非常明顯的優勢，在一臺普通的筆記本電腦上，Redis可以在一秒內讀寫超過十萬個鍵值。不過，將數據存儲在內存中也有問題，例如，程序退出后內存中的數據會丟失。為解決這個問題，Redis將可以內存中的數據異步寫入到硬盤中，同時不影響繼續提供服務。

Redis可以為每個鍵設置生存時間，生存時間到期后鍵會自動被刪除。這一功能配合出色的性能讓Redis可以作為緩存系統來使用，而且由于Redis支持持久化和豐富的數據類型，使其成為了另一個非常流行的緩存系統Memcached的有力競爭者。

作為緩存系統，Redis 還可以限定數據占用的最大內存空間，在數據達到空間限制后可以按照一定的規則自動淘汰不需要的鍵。

此外，Redis的列表類型鍵可以用來實現隊列，并且支持阻塞式讀取，可以很容易地實現一個高性能的優先級隊列。同時在更高層面上，Redis 還支持“發布/訂閱”的消息模式。

Redis 提供了幾十種不同編程語言的客戶端庫，這些庫都很好地封裝了Redis的命令，使得在程序中與Redis進行交互變得更容易。有些庫還提供了可以將編程語言中的數據類型直接以相應的形式存儲到Redis中(如將數組直接以列表類型存入 Redis)的簡單方法，使用起來非常方便。

Redis支持五種的數據類型，針對移動健康業務系統來分析這五種類型的應用場景如下：

(1)字符串類型：每一行對應一個key，value值存可以統一存取的序列號的對象值(鏈表或散列存更方便)，如文章閱讀量等數據。

(2)散列類型：每行對應一個key，value值類似一個map，適合緩存多種數據列的實體數據。

(3)鏈表類型：適合緩存實現鏈表和堆棧效果的數據，比如實現分頁、限制某個IP的訪問頻率等功能比較方便。

(4)集合類型：適合緩存無順序要求，并需要執行并、交、差等集合操作的數據，如頁面的標簽類型等信息。

(5)有序集合類型：適合緩存有順序要求，而且需要執行集合操作的數據。

2.3.2并行計算技術的使用

在移動健康業務系統中難免有需要處理耗時較長的各類統計分析操作，為提高此類功能的運行效率，可以采用并行計算技術，如MapReduce。

MapReduce是一種編程模型，用于大規模數據集(大于1 TB)的并行運算。概念“Map(映射)”和“Reduce(歸約)”是它的主要思想。它極大地方便了編程人員在不會分布式并行編程的情況下，將自己的程序運行在分布式系統上[5]。當前的軟件實現是指定一個Map(映射)函數，用來把一組鍵值對映射成一組新的鍵值對，指定并發的Reduce(歸約)函數，用來保證所有映射的鍵值對中的每一個共享相同的鍵組。

3 結論

醫療健康大數據和個人密切相關，其安全和隱私保護問題從保障技術和管理制度兩方面都顯得尤為重要。未來醫療大數據處理可以基于云計算平臺實現，作為云計算平臺的一種服務。基于云計算平臺的開發和應用使得很多數據被存儲在云端進行處理、查詢和搜索[6]。因此，除了要解決醫療大數據搜索的可擴展性、可靠性和效率外,必須考慮數據搜索和使用的安全和隱私問題。

參考文獻

[1] 劉智慧,張泉靈.大數據技術研究綜述[J].浙江大學學報(工學版),2014,48(6):957-972.

[2] 王藝,任淑霞.醫療大數據可視化研究綜述[J].計算機科學與探索,2017,11(5):681-699.

[3] 馬燦.國內外醫療大數據資源共享比較研究[J].情報資料工作,2016,37(3):63-67.

[4] 宋波,楊艷利,馮云霞.醫療大數據研究進展[J].轉化醫學雜志,2016,5(5):298-300.

[5] 魏建兵.基于云計算的醫療大數據系統架構研究[J].電腦知識與技術,2016,12(7):21-23.

[6] 孫艷秋,王甜宇,曹文聰. 基于云計算的醫療大數據的挖掘研究[J].計算機光盤軟件與應用,2015 (2):11-11.