王利琴，高衛(wèi)香，蘭軍，翟艷東

（河北工業(yè)大學(xué)計算機科學(xué)與軟件學(xué)院，天津 300401）

0 引言

根據(jù)《中國心血管報告2016》[1]的統(tǒng)計結(jié)果，心血管疾病的死亡高居我國城鄉(xiāng)居民死亡原因首位。隨著心臟病、高血壓、糖尿病等慢性疾病的死亡率不斷飆升，越來越多的人面臨健康的威脅。同時隨著通信網(wǎng)絡(luò)技術(shù)和傳感器技術(shù)的發(fā)展，來自醫(yī)院的傳統(tǒng)心電檢查數(shù)據(jù)以及來自移動終端等設(shè)備的心電數(shù)據(jù)（ECG，Electro?cardiogram）呈指數(shù)級增長、復(fù)雜程度增大，逐步構(gòu)成了心電大數(shù)據(jù)。如果能對這些數(shù)據(jù)進行分析挖掘，發(fā)現(xiàn)潛在的心臟疾病，并在發(fā)作前提供預(yù)警，則將大大降低病人的致死率及醫(yī)療成本，同時為醫(yī)護人員的臨床實踐提供參考。因此構(gòu)建心電數(shù)據(jù)的存儲平臺，實現(xiàn)心電數(shù)據(jù)的共享，為心臟疾病的診斷提供支撐具有重要的現(xiàn)實意義。

Hadoop作為分布式的存儲平臺，已有不少文獻將其應(yīng)用到了心電信號的存儲領(lǐng)域。文獻[2]提出了一種基于HBase的心電信號存儲架構(gòu)，并利用MapReduce編程框架實現(xiàn)對信號處理的方案，該方案在存儲系統(tǒng)滿足數(shù)據(jù)輸入和輸出響應(yīng)需求的同時很容易地將計算并行化，從而解決了當(dāng)前各類由于傳感器和其他監(jiān)測終端產(chǎn)生的結(jié)果數(shù)據(jù)越來越多，存儲計算需求越來越高的需求。文獻[3]基于Hadoop和HBase技術(shù)構(gòu)建心電數(shù)據(jù)庫,并對數(shù)據(jù)庫的存儲時間、訪問時間做了測試，實驗表明基于Hadoop和HBase構(gòu)建的心電信號存儲系統(tǒng)具有較高的可靠性，可以滿足心電數(shù)據(jù)的存儲要求。但文獻中只分析了數(shù)據(jù)的存儲時間、查詢時間，并沒有給出具體的存儲系統(tǒng)架構(gòu)。本文將從分布式存儲系統(tǒng)設(shè)計的角度，詳細給出存儲系統(tǒng)設(shè)計的系統(tǒng)結(jié)構(gòu)，數(shù)據(jù)存儲流程以及HBase表結(jié)構(gòu)設(shè)計及主鍵設(shè)計。

1 相關(guān)技術(shù)

1.1 Hadoop

Hadoop[4]由Hadoop分布式文件系統(tǒng)（Hadoop Dis?tributed File System,HDFS）和MapReduce編程框架組成，是一個提供分布式存儲和計算能力的主從架構(gòu)平臺。HDFS與傳統(tǒng)的分布式系統(tǒng)不同，傳統(tǒng)的分布式系統(tǒng)需要在客戶端和服務(wù)器之間重復(fù)傳輸數(shù)據(jù)，這對計算密集型的工作很適用，但對大數(shù)據(jù)處理，由于數(shù)據(jù)變得太大，對其進行移動已變得不可實現(xiàn)。Hadoop實現(xiàn)了移動計算而非移動數(shù)據(jù)，主節(jié)點（NameNode）只發(fā)送要執(zhí)行的MapReduce程序到從節(jié)點（DataNode）上，而且這些程序通常很?。ㄍǔＪ乔ё止?jié)），集群的帶寬完全可以滿足。同時，集群中的數(shù)據(jù)被分解并分布在集群中的所有數(shù)據(jù)節(jié)點上，并且計算盡可能多地在同一臺機器上的數(shù)據(jù)塊進行。

1.2 MapReduce

MapReduce[5]是一種編程模型，廣泛應(yīng)用于大數(shù)據(jù)的并行處理。MapReduce由Map函數(shù)和Reduce函數(shù)具體執(zhí)行，Map函數(shù)對輸入的數(shù)據(jù)進行切分，并輸出鍵值對形式的中間結(jié)果，Reduce函數(shù)合并具有相同鍵的多個不同的值，形成一個鍵值對的集合。它只專注于計算，而不必關(guān)心數(shù)據(jù)，使得基于MapReduce的編程更易實現(xiàn)。此外，由于大多數(shù)計算都是在存儲數(shù)據(jù)副本的從節(jié)點上完成的，這使得在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量較小，從而提高了整體計算效率。

1.3 HBase

HBase[6]是運行在HDFS之上的分布式列存儲數(shù)據(jù)庫，它基于Google BigTable并支持MapReduce編程模型，提供了方便的、隨機訪問數(shù)據(jù)的方法。作為一種NoSQL數(shù)據(jù)庫，HBase對表、行和列的定義與傳統(tǒng)的關(guān)系數(shù)據(jù)庫不同，它的數(shù)據(jù)模型主要包含如下幾個部分：

表：Hbase用表存儲數(shù)據(jù)。

行：行由一個可排序的行鍵（rowkey）唯一標(biāo)識。

列族：列族需事先定義，每行的數(shù)據(jù)按照列族分組存儲。

列修飾符：列修飾符也就是列，列族里的數(shù)據(jù)通過列定位。每行有相同的列簇，但是在行之間，相同的列簇不需要有相同的列。

單元：行鍵、列族和列修飾符一起確定一個單元。

HBase在數(shù)據(jù)存儲和操作方面比傳統(tǒng)的關(guān)系數(shù)據(jù)庫管理系統(tǒng)具有巨大的優(yōu)勢。因此，采用HBase設(shè)計數(shù)據(jù)存儲模型，使其能夠滿足高并發(fā)性、海量存儲和高擴展性等需求[7]。

2 基于大數(shù)據(jù)分布式平臺的心電信號存儲系統(tǒng)設(shè)計

2.1 基于Hadoop的存儲平臺設(shè)計

基于Hadoop平臺的分布式特性，本文構(gòu)建的心電大數(shù)據(jù)處理存儲平臺如圖1所示，由Hadoop、Zookeep?er和HBase構(gòu)建。在這個平臺中，Hadoop提供基本的分布式存儲和處理功能，Zookeeper協(xié)調(diào)應(yīng)用程序并管理相關(guān)配置，HBase存儲ECG信號數(shù)據(jù)。

圖1 心電大數(shù)據(jù)存儲平臺設(shè)計

2.2 數(shù)據(jù)存儲流程

心電大數(shù)據(jù)存儲系統(tǒng)不僅存儲由各類傳感器和醫(yī)療設(shè)備采集的實時心電數(shù)據(jù)，而且也要存儲已有的數(shù)據(jù)，用于數(shù)據(jù)和疾病預(yù)測的相關(guān)分析等場合。因此，對大數(shù)據(jù)存儲系統(tǒng)來說，要分離線存儲和在線存儲兩個過程，如圖2所示。

圖2 心電大數(shù)據(jù)存儲流程

2.3 表結(jié)構(gòu)設(shè)計

考慮到HBase在存儲數(shù)據(jù)時，不同的列族存儲在不同的文件中。同時當(dāng)某個列族在flush的時候，與它鄰近的列族也會因關(guān)聯(lián)效應(yīng)被觸發(fā)flush，最終導(dǎo)致系統(tǒng)產(chǎn)生更多的I/O。因此，本文在設(shè)計存儲數(shù)據(jù)表時，只設(shè)計一個列族，以心電數(shù)據(jù)存儲表為例，只包含一個列族ECG，包含如下列：

文件名：心電數(shù)據(jù)作為時間序列數(shù)據(jù)，為更好的對其實施管理，需將其按照固定時間進行截取，存為一個文件。

文件存儲路徑：數(shù)據(jù)實際在HDFS上的存儲位置。

信號特征：在分析心電圖時，需要用到ECG數(shù)據(jù)的特征參數(shù)，如QRS持續(xù)時間、R波振幅、ST段振幅、ST段斜率、ST段位移、PR間期、QT間期以及由特征提取算法提取到的其他特征值。通過分析這些特征參數(shù)，應(yīng)用程序可以找到各種參數(shù)與疾病之間的相關(guān)關(guān)系。

疾病類別：在心電數(shù)據(jù)存入數(shù)據(jù)庫之前，基于提取到的信號特征采用某種分類方法將其大致進行分類。

用戶屬性：心電數(shù)據(jù)對應(yīng)的患者相關(guān)的一些數(shù)據(jù)，如患者的病史、生活方式、性別、年齡、服藥歷史等屬性，這些屬性往往也與疾病存在著相關(guān)關(guān)系。

2.4 行主鍵設(shè)計

HBase只提供了行級索引，因此為實現(xiàn)多條件查詢，需要設(shè)計合適的行主鍵。本文選擇用戶id和疾病id聯(lián)合作為行主鍵。同時為避免region的熱點問題，充分利用集群分布式的特性，將用戶id倒序。

3 實驗及結(jié)果

3.1 實驗環(huán)境及數(shù)據(jù)集

測試硬件環(huán)境為在1臺服務(wù)器構(gòu)建分布式Hadoop集群，集群包含1個主節(jié)點，4個從節(jié)點，用到的各軟件版本分別為 Hadoop2.6.2、Zookeeper3.4.6、HBase1.2.6，操作系統(tǒng)均為64位CentOS 6.5。服務(wù)器的硬件配置如下：

處理器：英特爾·至強·E5-2600V4處理器；

磁盤：600GB；

內(nèi)存：32GB；

本文采用的心電數(shù)據(jù)庫如表1所示，共包含來自三個數(shù)據(jù)集的263個心電信號文件，共約10.2G的數(shù)據(jù)。其中European ST-T數(shù)據(jù)集包含90個30分鐘的心電記錄文件，Long-Term AF包含84個21小時的心電記錄文件，Long-Term ST包含89個24小時的心電記錄文件。

3.2 數(shù)據(jù)寫入性能

因ECG數(shù)據(jù)是從5KB到100MB的不等的文件，為考察心電存儲平臺數(shù)據(jù)的導(dǎo)入性能，需事先對ECG文件進行預(yù)處理，根據(jù)采樣頻率按照每分鐘的時長將原始文件切分成同樣的長度，各數(shù)據(jù)集含有的記錄條數(shù)如表1所示，共236700條記錄。將數(shù)據(jù)分別寫入到本文構(gòu)建的存儲平臺和MySQL數(shù)據(jù)庫中，每秒記錄一次寫入的記錄條數(shù)，實驗進行10次，取平均值，實驗結(jié)果如圖3所示。實驗結(jié)果表明：HBase數(shù)據(jù)的寫入性能總體優(yōu)于MySQL寫入性能。HBase隨著寫入記錄數(shù)的增加，數(shù)據(jù)寫入性能總體平穩(wěn)，最快寫入速度19813條/秒。

表1 實驗數(shù)據(jù)集

圖3 HBase與MySQL數(shù)據(jù)寫入性能比較

圖4 HBase與MySQL數(shù)據(jù)查詢性能比較

3.3 數(shù)據(jù)查詢性能

按照行鍵的設(shè)計，設(shè)計三種查詢測試用例，包含只按照用戶id查詢、只按照疾病id查詢和用戶id和疾病id組合查詢,每個用例一共執(zhí)行10次后取均值，結(jié)果如圖4所示。實驗結(jié)果表明，HBase的查詢性能總體優(yōu)于MySQL，最快查詢速度15805條/秒,數(shù)據(jù)檢索結(jié)果返回時效達到毫秒級，能夠滿足業(yè)務(wù)應(yīng)用中對心電信號存儲和檢索時效的要求。

4 結(jié)語

針對關(guān)系型數(shù)據(jù)庫對心電數(shù)據(jù)的存儲及檢索效率低的問題，通過對HBase中相關(guān)表的結(jié)構(gòu)及行鍵設(shè)計，建立了基于HBase的分布式存儲與處理系統(tǒng)，使實時采集和監(jiān)控心電數(shù)據(jù)成為可能。系統(tǒng)中關(guān)鍵技術(shù)是基于MapReduce的并行數(shù)據(jù)導(dǎo)入。實驗驗證了該方案相對于MySQL具有較高的存儲效率和查詢速度，能夠滿足業(yè)務(wù)中的時效性要求。

[1]http://news.medlive.cn/heart/info-progress/show-129366_129.html

[2]Nguyen AV,Wynden R,Sun Y:HBase,MapReduce,and Integrated Data Visualization for Processing Clinical Signal Data.In AAAI Spring Symposium:Computational Physiology:2011.

[3]熊艷,陳宇,蔣文濤等.基于Hadoop的心電數(shù)據(jù)庫存儲研究[J].生物醫(yī)學(xué)工程研究,2016,35（3）:175-177.

[4]Shvachko K,Kuang H,Radia S,Chansler R:The Hadoop Distributed File System.In Mass Storage Systems and Technologies（MSST）,2010 IEEE 26th Symposium on:2010,IEEE;2010:1-10.

[5]K.C.Wee and M.S.M.Zahid.Auto-tuned Hadoop MapReduce for ECG Analysis.2015 IEEE Student Conference on Research and Development（SCOReD）,Kuala Lumpur,2015：329-334.

[6]張智,龔宇.分布式存儲系統(tǒng)HBase關(guān)鍵技術(shù)研究[J].現(xiàn)代計算機，2014（11）:33-37.

[7]R.C.Taylor.An overview of the Hadoop/MapReduce/HBase Framework and Its Current Applications in Bioinformatics.J.BMC Bioinformatics,2010.