毛亞青，王 亮，胡俊峰

(徐州醫(yī)科大學(xué) 醫(yī)學(xué)信息與工程學(xué)院，江蘇 徐州 221000)

0 引言

目前，醫(yī)學(xué)影像數(shù)據(jù)約占醫(yī)院內(nèi)部總數(shù)據(jù)的70%[1]，它們來源于不同設(shè)備、對應(yīng)不同人體組織器官和多種病癥，這些海量的醫(yī)學(xué)圖像資源為醫(yī)學(xué)圖像的存儲、檢索帶來了存儲體量大、檢索效率低等問題。如何對海量醫(yī)學(xué)圖像信息進(jìn)行高效檢索，從海量數(shù)據(jù)中快速并準(zhǔn)確地搜索出滿足要求的圖像是目前所要解決的重要問題。然而，現(xiàn)階段國內(nèi)外關(guān)于醫(yī)學(xué)圖像檢索技術(shù)的研究[2-5]依然存在三大問題：1)主要在單機(jī)環(huán)境下進(jìn)行，大規(guī)模醫(yī)學(xué)影像數(shù)據(jù)的檢索使得該串行模式的醫(yī)學(xué)圖像檢索技術(shù)已出現(xiàn)進(jìn)程瓶頸；2)當(dāng)前醫(yī)學(xué)圖像檢索中主要采用對圖像依次進(jìn)行遍歷的方式，而沒有很好的索引機(jī)制來做索引，也增大了檢索系統(tǒng)的負(fù)荷；3)傳統(tǒng)的圖像檢索模式大多基于已有的數(shù)據(jù)進(jìn)行定時離線構(gòu)建索引，對于新增的圖像檢索存在時效性差的問題。

為了解決醫(yī)學(xué)圖像檢索過程中的效率問題，本課題擬采用基于Flink的分布式技術(shù)提高這些海量醫(yī)學(xué)圖像的檢索實時性，針對海量醫(yī)學(xué)圖像檢索系統(tǒng)中圖像特征索引方式、圖像存儲以及圖像檢索的問題，建立一個高效的醫(yī)學(xué)圖像檢索平臺，實現(xiàn)醫(yī)學(xué)圖像分布式檢索，提高圖像處理的實時性以及圖像檢索準(zhǔn)確率，從而更好地輔助醫(yī)生便捷獲取和利用醫(yī)學(xué)圖像資源。

1 相關(guān)工作

1.1 Hadoop平臺簡介

從狹義上來說，Hadoop[2-6]是一個由Apache基金會所維護(hù)的分布式系統(tǒng)基礎(chǔ)架構(gòu)，旨在解決海量數(shù)據(jù)的存儲和計算問題。而從廣義上來說，Hadoop通常指的是它所構(gòu)建的Hadoop生態(tài)，包括Hadoop核心技術(shù)，以及基于Hadoop平臺所部署的大數(shù)據(jù)開源組件和產(chǎn)品，如HBase、Hive、Spark、Flink、Pig、ZooKeeper、Kafka、Flume、Phoenix、Sqoop等。這些組件藉由Hadoop平臺，實現(xiàn)大數(shù)據(jù)場景下的數(shù)據(jù)存儲、數(shù)據(jù)倉庫、分布式計算、數(shù)據(jù)分析、實時計算、數(shù)據(jù)傳輸?shù)炔煌枨螅瑥亩鴺?gòu)成Hadoop生態(tài)。

Hadoop的核心技術(shù)：HDFS、MapReduce、HBase被譽(yù)為Hadoop的三駕馬車，更為企業(yè)生產(chǎn)應(yīng)用帶來了高可靠、高容錯和高效率等特性。HDFS是分布式文件系統(tǒng)(Hadoop Distributed File System)，其底層維護(hù)著多個數(shù)據(jù)副本，即使Hadoop某個計算或存儲節(jié)點出現(xiàn)故障也不會導(dǎo)致數(shù)據(jù)的丟失，所以即使部署在成本低廉的服務(wù)器上也能同樣保障其可靠性和容錯性。MapReduce是Hadoop中并行計算編程的基本模型，能夠?qū)⑷蝿?wù)并行分配給多個節(jié)點同時工作，從而加快任務(wù)處理的速度。HBase是一個可伸縮、分布式、面向列的數(shù)據(jù)庫，和傳統(tǒng)關(guān)系數(shù)據(jù)庫不同，HBase提供了對大規(guī)模數(shù)據(jù)的隨機(jī)、實時讀寫訪問，同時，HBase中保存的數(shù)據(jù)可以使用MapReduce來處理，它將數(shù)據(jù)存儲和并行計算完美地結(jié)合在一起。

1.2 Flink平臺簡介

Apache Flink是一個框架和分布式處理引擎，用于對無界和有界數(shù)據(jù)流進(jìn)行有狀態(tài)計算。Flink被設(shè)計在所有常見的集群環(huán)境中運(yùn)行，以內(nèi)存執(zhí)行速度和任意規(guī)模來執(zhí)行計算。Flink基于Flink流式執(zhí)行模型(Streaming execution model)，能夠支持流處理和批處理兩種應(yīng)用類型。流處理和批處理所提供的服務(wù)等級協(xié)議完全不相同，流處理一般需要支持低延遲、Exactly-once保證，而批處理需要支持高吞吐、高效處理，所以在實現(xiàn)的時候通常是分別給出兩套實現(xiàn)方法，或者通過一個獨立的開源框架來實現(xiàn)其中每一種處理方案。如：實現(xiàn)批處理的開源方案MapReduce、Spark；實現(xiàn)流處理的開源方案Storm；微批處理方案Spark Streaming。

與傳統(tǒng)方案不同，F(xiàn)link在實現(xiàn)流處理和批處理時，將二者統(tǒng)一起來：Flink是完全支持流處理，也就是說作為流處理看待時輸入數(shù)據(jù)流是無界的；批處理被作為一種特殊的流處理，即有界的數(shù)據(jù)流。這種批、流一體的架構(gòu)使得Flink在執(zhí)行計算時具有極低的延遲。

2 系統(tǒng)架構(gòu)設(shè)計

2.1 系統(tǒng)總體架構(gòu)設(shè)計

為了實現(xiàn)海量醫(yī)學(xué)圖像的實時檢索和高效存儲，設(shè)計基于Flink的海量醫(yī)學(xué)圖像并行檢索系統(tǒng)總體架構(gòu)共包括：數(shù)據(jù)采集層、數(shù)據(jù)存儲層、資源管理層、數(shù)據(jù)計算層和應(yīng)用層。

如圖1所示為醫(yī)學(xué)圖像檢索系統(tǒng)架構(gòu)圖，具體如下。

圖1 系統(tǒng)總體架構(gòu)圖

1)數(shù)據(jù)采集層：

系統(tǒng)的數(shù)據(jù)源主要包括：用戶通過Web界面上傳醫(yī)學(xué)圖像、通過API批量導(dǎo)入的醫(yī)學(xué)圖像和系統(tǒng)操作日志流。對于實時產(chǎn)生的數(shù)據(jù)首先放入Kafka消息隊列進(jìn)行緩沖中以供后續(xù)計算，通過Zookeeper組件對Kafka服務(wù)器消費(fèi)生產(chǎn)速度進(jìn)行同步。此外，還可以通過ETL導(dǎo)入數(shù)據(jù)作為系統(tǒng)的數(shù)據(jù)源。

2)數(shù)據(jù)存儲層：

系統(tǒng)的數(shù)據(jù)存儲根據(jù)數(shù)據(jù)類型和應(yīng)用場景分為基礎(chǔ)業(yè)務(wù)庫、醫(yī)學(xué)圖像存儲庫、圖像特征索引庫和內(nèi)存數(shù)據(jù)庫。其中，基礎(chǔ)業(yè)務(wù)庫通過MySQL存放系統(tǒng)的結(jié)構(gòu)化信息，如：人員列表、組織架構(gòu)、圖像基礎(chǔ)信息等。醫(yī)學(xué)圖像存儲庫通過Hadoop平臺的HDFS進(jìn)行存儲，圖像ID對應(yīng)MySQL中的圖像基礎(chǔ)信息表的記錄。同時，該ID圖像的特征索引存儲在HBase數(shù)據(jù)庫中。此外，服務(wù)器將經(jīng)常訪問的數(shù)據(jù)緩存在內(nèi)存數(shù)據(jù)庫Redis中，從而提高訪問速度和計算效率。

3)資源管理層：

系統(tǒng)通過由Yarn進(jìn)行資源管理，負(fù)責(zé)在有數(shù)據(jù)計算請求時根據(jù)集群狀況分配計算資源和計算節(jié)點，從而提供MapReduce、Spark、Flink等組件的計算環(huán)境。

4)數(shù)據(jù)計算層：

系統(tǒng)首先對于用戶輸入的醫(yī)學(xué)圖像通過Flink進(jìn)行特征提取，根據(jù)圖像上傳形式分為實時計算和離線批量計算兩種；進(jìn)而對圖像進(jìn)行特征量化編碼便于檢索，特征編碼存儲在HBase中，并由Phoenix進(jìn)行HBase中數(shù)據(jù)的查詢計算；在用戶需要檢索時通過醫(yī)學(xué)圖像并行檢索比對特征相似度計算返回檢索結(jié)果。

5)應(yīng)用層：

系統(tǒng)通過Web的形式提供用戶交互界面，實現(xiàn)對醫(yī)學(xué)圖像的存儲管理、醫(yī)學(xué)圖像檢索操作、用戶管理、系統(tǒng)管理和日志管理等。

2.2 系統(tǒng)功能結(jié)構(gòu)設(shè)計

醫(yī)學(xué)圖像檢索系統(tǒng)主要設(shè)計包括系統(tǒng)管理模塊、用戶管理模塊和圖像管理模塊三部分。其中，系統(tǒng)管理模塊包括系統(tǒng)管理、日志管理、異常報警；用戶管理模塊包括用戶注冊、用戶登錄、個人信息管理；圖像管理模塊包括圖像上傳、圖像批量導(dǎo)入、圖像查看和圖像檢索檢索。具體功能如圖2所示。

圖2 系統(tǒng)功能結(jié)構(gòu)圖

2.3 系統(tǒng)集群網(wǎng)絡(luò)架構(gòu)

系統(tǒng)集群網(wǎng)絡(luò)架構(gòu)共包括前端集群、后端業(yè)務(wù)集群和數(shù)據(jù)計算集群，醫(yī)學(xué)圖像并行檢索系統(tǒng)網(wǎng)絡(luò)架構(gòu)如圖3所示。

圖3 系統(tǒng)集群網(wǎng)絡(luò)架構(gòu)圖

系統(tǒng)主要采用前端界面和后端業(yè)務(wù)分離的思想，在提高各個模塊的內(nèi)聚性的同時降低各模塊之間的耦合性。在前端集群中，由Nginx負(fù)責(zé)請求的反向代理和負(fù)載均衡，根據(jù)用戶操作分別指向靜態(tài)文件服務(wù)器或Web服務(wù)器，實現(xiàn)網(wǎng)頁相關(guān)界面的顯示與交互。前端集群通過遠(yuǎn)程調(diào)用的方式與后端業(yè)務(wù)集群進(jìn)行通信，實現(xiàn)相關(guān)業(yè)務(wù)操作、MySQL數(shù)據(jù)庫交互操作、數(shù)據(jù)計算與結(jié)果緩存到Redis等操作。對于后端業(yè)務(wù)操作中的數(shù)據(jù)計算環(huán)節(jié)則由數(shù)據(jù)計算集群負(fù)責(zé)，如：實時圖像上傳、批量圖像導(dǎo)入、特征提取模型計算、特征編碼模型計算等。

在數(shù)據(jù)計算集群中部署了Hadoop平臺(HDFS、HBase、Yarn)以及Flink、Kafka、Zookeeper等組件。其中HDFS負(fù)責(zé)進(jìn)行底層數(shù)據(jù)的存儲，具體由HDFS的DataNode進(jìn)行文件分片多備份存放，由NameNode進(jìn)行元數(shù)據(jù)管理和文件操作管理，同時通過Zookeeper注冊兩個NameNode并實時監(jiān)控狀態(tài)，防止一方故障立即切換到另一個，從而保證NameNode的高可用性。HBase負(fù)責(zé)對醫(yī)學(xué)圖像和特征編碼進(jìn)行存儲，由HMaster管理多個RegionServer進(jìn)行數(shù)據(jù)維護(hù)和查詢，底層由HDFS進(jìn)行存儲。對于實時計算部分通過Kafka Broker接受Kafka生產(chǎn)者生產(chǎn)的實時消息，再通過Kafka消費(fèi)者Flink進(jìn)行處理計算，其中Kafka的生產(chǎn)、消費(fèi)進(jìn)度由Zookeeper進(jìn)行記錄。Flink不僅提供實時計算，同時提供離線批量計算，其計算過程通過Yarn申請計算資源，具體由ResourceManager管理資源并分配到NodeManager上進(jìn)行計算。

3 主要模塊設(shè)計

3.1 醫(yī)學(xué)圖像存儲模塊

系統(tǒng)在接收到Web端的醫(yī)學(xué)圖像上傳請求后，首先在MySQL業(yè)務(wù)庫中創(chuàng)建圖像記錄，然后服務(wù)器后臺將圖像文件的字節(jié)碼對應(yīng)業(yè)務(wù)庫中的圖像ID存儲到HBase中，實現(xiàn)海量醫(yī)學(xué)圖像數(shù)據(jù)的存儲。在圖像經(jīng)過特征提取和編碼后，將編碼后的圖像特征對應(yīng)圖像ID存儲到HBase中，在圖像檢索的過程中通過Phoenix進(jìn)行查詢。

對于海量文件的存儲，通常的方案是通過HDFS進(jìn)行分布式存儲。HDFS系統(tǒng)在存儲過程中將文件切分成多個block多副本存儲在多個節(jié)點上，從而保障文件的可用性和拓展性，默認(rèn)每個block的大小為128 MB。然而，HDFS通過NameNode加載每個文件的元數(shù)據(jù)信息，一般上傳圖像文件的尺寸都較小，在大量這種小文件的存儲情況下，其每個小文件都會占用一個block，造成HDFS產(chǎn)生大量的文件元數(shù)據(jù)信息。這些元數(shù)據(jù)信息會給NameNode的內(nèi)存和計算帶來很重的負(fù)擔(dān)，從而降低系統(tǒng)的存儲效率。為了解決HDFS在小文件存儲方面的問題，通常的做法是先將很多小文件合并成一個大文件再保存到HDFS，同時為這些小文件建立索引，以便進(jìn)行快速存取，如Hadoop自帶的HAR文件和SequenceFile方案。但是這兩種方案均需要用戶編寫程序定時進(jìn)行小文件的統(tǒng)一合并，且不支持文件追加和修改，并不適合醫(yī)學(xué)圖像實時上傳、頻繁更新業(yè)務(wù)庫的場景。因此，系統(tǒng)將圖像文件通過字節(jié)碼的形式直接存儲在HBase中，從而避免HDFS存儲過多的小文件、影響效率的情況。

系統(tǒng)利用HBase存儲醫(yī)學(xué)圖像文件數(shù)據(jù)和特征編碼等數(shù)據(jù)，進(jìn)而通過Phoenix進(jìn)行結(jié)構(gòu)化查詢。HBase作為分布式數(shù)據(jù)庫，通過多個Region對數(shù)據(jù)進(jìn)行存儲，在實時查詢方面具有很強(qiáng)的優(yōu)勢。然而默認(rèn)情況下HBase的表結(jié)構(gòu)分區(qū)只有一個，在寫入讀取時會增大單節(jié)點的負(fù)擔(dān)，沒有發(fā)揮集群的優(yōu)勢。此外，一條記錄由它的RowKey唯一標(biāo)志，并決定該條記錄存儲于哪個分區(qū)。因此，在設(shè)置多個分區(qū)后也需要考慮分區(qū)的分配策略，即進(jìn)行合理的RowKey設(shè)計，從而對數(shù)據(jù)進(jìn)行均勻分布，防止出現(xiàn)數(shù)據(jù)熱點問題。

在本系統(tǒng)的HBase存儲設(shè)計部分共包括創(chuàng)建表、預(yù)分區(qū)、RowKey設(shè)計等環(huán)節(jié)，包括：

1)創(chuàng)建圖像存儲表，設(shè)計兩個列族MD(image data)、MI(image info)分別存放圖像的字節(jié)碼和圖像信息(圖像id、圖像特征碼等)，在創(chuàng)建表的同時進(jìn)行預(yù)分區(qū)操作，設(shè)計共9個分區(qū)，指定每個分區(qū)的RowKey范圍，建表語句如下：

create2′'image_info′, {NAME => ′MD′}, {NAME => ’MI’}, SPLITS => [′0000|′, ′0001|′, ′0002|′, ′0003|′, ′0004|′, ′0005|′, ′0006|′, ′0007|′, ′0008|′]

2)根據(jù)預(yù)分區(qū)設(shè)計，在向HBase中插入數(shù)據(jù)時需要對RowKey進(jìn)行相應(yīng)的格式約束，即在保證RowKey唯一性的同時確保其前綴格式為“000x|”。本系統(tǒng)首先根據(jù)醫(yī)學(xué)圖像在業(yè)務(wù)庫的唯一ID通過MD5加密生成Hash值；然后獲取RowKey前綴：將得到的Hash值轉(zhuǎn)成Long型，并根據(jù)預(yù)分區(qū)數(shù)對9取余，其中字符’a’～’f’替換為’10’～’15’；再取Hash值的后八位作為RowKey的后綴，拼接前綴作為最終的Row Key。

3.2 圖像特征提取與編碼模塊

傳統(tǒng)樹結(jié)構(gòu)索引方法存儲空間占用過大，且隨著維度的增長空間代價成倍變大，因此需要通過對原始數(shù)據(jù)進(jìn)行哈希編碼壓縮以節(jié)省空間。目前對哈希編碼的研究主要包括數(shù)據(jù)無關(guān)哈希和數(shù)據(jù)驅(qū)動哈希：數(shù)據(jù)無關(guān)哈希方法以局部敏感哈希[7]為代表，在不考慮數(shù)據(jù)分布的情況下將原始空間中的數(shù)據(jù)投影到超平面獲取相應(yīng)編碼。數(shù)據(jù)驅(qū)動哈希方法主要通過判別數(shù)據(jù)結(jié)構(gòu)及分布信息來自動學(xué)習(xí)哈希函數(shù)，代表方法有譜哈希[8]、迭代量化[9]、乘積量化[10]、笛卡爾K均值[11]及組合量化[12]等。與其他編碼方法相比，乘積量化模型能夠有效解決聚類中心數(shù)量膨脹問題，進(jìn)而提升大規(guī)模圖像檢索過程中的數(shù)據(jù)存儲效率。

系統(tǒng)根據(jù)應(yīng)用場景分為批量導(dǎo)入圖像時的特征量化以及用戶在實時上傳圖像時的特征量化。

1)批量導(dǎo)入圖像特征量化：

系統(tǒng)實現(xiàn)醫(yī)學(xué)圖像的批量導(dǎo)入功能，用于歷史或外部圖像的離線導(dǎo)入場景。其過程如下：

(1)將圖像信息記錄到業(yè)務(wù)庫并將圖像字節(jié)碼和圖像id存儲在HBase中；

(2)通過DeepLearning4J調(diào)用預(yù)訓(xùn)練的深度卷積神經(jīng)網(wǎng)絡(luò)VGG-16模型提取圖像特征；

(3)使用乘積量化編碼模型對提取的圖像特征進(jìn)行量化編碼；

(4)將圖像特征編碼存儲到HBase中。

2)實時圖像特征量化：

在多用戶同時在線的場景中，為保證用戶在上傳圖像后能被其他用戶同步到以供檢索，設(shè)計實時圖像檢索模塊，對增量上傳的圖像進(jìn)行實時特征提取和特征量化編碼，從而實現(xiàn)系統(tǒng)的時效性。其實現(xiàn)過程包括：

(1)通過命令行創(chuàng)建Kafka消息訂閱的topic，表示一條圖像上傳的實時記錄，設(shè)計topic名為imageupload，定義副本數(shù)2個，分區(qū)數(shù)9個。

bin/kafka-topics.sh --zookeeper node01:2181 --create --replication-factor 3 --partitions 9 --topic imageupload

(2)Web服務(wù)響應(yīng)用戶的上傳請求，首先將圖像基本信息存入MySQL庫中；接著創(chuàng)建Kafka的生產(chǎn)者，由Kafka生產(chǎn)者將圖像上傳消息類進(jìn)行序列化，包括圖像的基本信息及圖像文件字節(jié)碼；然后，通過KafkaProducer類發(fā)送到imageupload的topic中；同時，利用回調(diào)函數(shù)監(jiān)測是否發(fā)送成功，異常則觸發(fā)報警。因為系統(tǒng)對圖像上傳順序的要求不高，因此Kafka的消息按照輪詢的方式進(jìn)行存放在每個分區(qū)中。

(3)創(chuàng)建Flink on Yarn任務(wù)實現(xiàn)Kafka的消費(fèi)者進(jìn)行實時處理。Flink任務(wù)實現(xiàn)記錄圖像信息到業(yè)務(wù)庫、提取圖像特征、存儲圖像字節(jié)碼和圖像特征編碼到HBase中。

3.3 圖像并行檢索模塊

在醫(yī)學(xué)圖像并行檢索的Flink任務(wù)執(zhí)行過程中，對于輸入查詢的醫(yī)學(xué)圖像，本文首先利用CNN模型進(jìn)行深度特征提取，然后對哈希編碼后的特征向量采用非對稱距離度量進(jìn)行距離計算，最終輸出距離最近的相似醫(yī)學(xué)圖像。利用非對稱距離度量的優(yōu)勢在于能夠避免直接計算查詢醫(yī)學(xué)圖像深度特征向量與數(shù)據(jù)庫中每個向量的歐式距離，從而減少查詢時間、提高檢索效率。

圖4是醫(yī)學(xué)圖像并行檢索過程的示意圖。通過事先計算深度特征哈希數(shù)據(jù)庫中每個聚類中心與其子向量的距離建立檢索查找表；對于需要查詢的醫(yī)學(xué)圖像深度特征向量q，計算其與數(shù)據(jù)庫中聚類中心xi′的距離，即為該向量與其他圖像向量之間的非對稱距離；通過比較q與聚類中心的距離找出最近的聚類c，設(shè)距離為l；最后，遍歷查找表將c聚類中每個向量與聚類中心的距離與l相加，即獲得q與該聚類中所有向量的距離，篩選距離排序獲得最近似的特征向量并返回對應(yīng)的醫(yī)學(xué)圖像。

圖4 醫(yī)學(xué)圖像并行檢索過程

4 實驗結(jié)果與分析

4.1 實驗環(huán)境

為了實現(xiàn)醫(yī)學(xué)圖像特征提取模型的高效訓(xùn)練和并行檢索模型的分布式執(zhí)行，本文將模型訓(xùn)練和集群應(yīng)用兩部分實驗分在不同的環(huán)境中執(zhí)行。其中，模型訓(xùn)練過程環(huán)境選用GPU型號為Tesla K80、12 GB內(nèi)存的Google云服務(wù)器，并采用Python 3.6和Tensorflow 1.7的深度學(xué)習(xí)框架。集群應(yīng)用環(huán)境選用1個主節(jié)點和3個計算節(jié)點，各節(jié)點配置情況如表1所示。

表1 分布式節(jié)點配置情況

服務(wù)器集群采用4個節(jié)點(node00～node03)并采用CDH進(jìn)行部署管理，包括HDFS、Yarn、Zookeeper、Kafka、HBase等組件的部署、監(jiān)控管理。此外，還部署了Flink計算組件、MySQL主備節(jié)點、Redis內(nèi)存數(shù)據(jù)庫等，具體組件子服務(wù)的分配狀況如表2所示。

表2 服務(wù)器集群組件分配情況

實驗數(shù)據(jù)集選用由美國國立衛(wèi)生研究院臨床中心(NIHCC)的團(tuán)隊開發(fā)的醫(yī)學(xué)圖像數(shù)據(jù)集DeepLesion[13]，是來自4 427個患者的多類別、病灶級別標(biāo)注臨床醫(yī)療CT圖像開放數(shù)據(jù)集。該數(shù)據(jù)庫中目前已有32 735張CT圖像及病變信息，去除重復(fù)記錄后共有已標(biāo)記的病變圖像9 624個，包括：肺(2 370)、腹部(2 119)、縱隔(1 640)、肝臟(1 257)、骨盆(843)、軟組織(660)、腎(488)和骨(247)共8種損傷類型。

本文實現(xiàn)的醫(yī)學(xué)圖像檢索方法在DeepLesion數(shù)據(jù)集上進(jìn)行醫(yī)學(xué)圖像特征提取和分布式并行檢索。根據(jù)給定醫(yī)學(xué)圖像實現(xiàn)數(shù)據(jù)集中相同病灶、相似損傷的其他醫(yī)學(xué)圖像的檢索，從而有效地輔助醫(yī)療診斷過程。

4.2 圖像檢索效率分析

為了驗證基于Flink的醫(yī)學(xué)圖像檢索系統(tǒng)的圖像檢索效率，本文分別使用MapReduce、Spark和Flink三種分布式計算組件實現(xiàn)并行檢索環(huán)節(jié)，并對比不同組件在不同圖像數(shù)據(jù)量下進(jìn)行醫(yī)學(xué)圖像檢索的時間。

各組件檢索時間對比如圖5所示。在使用3種組件時，并行檢索的時間均隨著數(shù)據(jù)量的增大而增加。其中MapReduce效果相對更差，且使用時間增長也較快。Spark和Flink使用時間相差不多，總體來說Flink的處理效果更好，且隨著處理數(shù)據(jù)量的增加，F(xiàn)link的計算效率明顯更優(yōu)于Spark。因此，使用Flink進(jìn)行分布式圖像檢索的計算更具優(yōu)勢。

圖5 各組件檢索時間對比圖

4.3 系統(tǒng)功能效果

進(jìn)入醫(yī)學(xué)圖像檢索系統(tǒng)，用戶首先通過用戶名、密碼、驗證碼的方式進(jìn)行登陸。如果忘記密碼可以通過郵箱找回密碼。具體操作如圖6所示。

圖6 系統(tǒng)用戶登陸界面

同時，新用戶進(jìn)入系統(tǒng)可以通過注冊賬號，填寫用戶名、姓名、郵箱、設(shè)置密碼等表單信息進(jìn)行新用戶的申請。具體操作如圖7所示。

圖7 新用戶賬號注冊界面

進(jìn)入桌面化的系統(tǒng)界面后選擇打開桌面上的應(yīng)用進(jìn)行操作，系統(tǒng)根據(jù)權(quán)限不同提供醫(yī)學(xué)圖像管理、用戶信息管理、日志管理、系統(tǒng)狀態(tài)管理、多媒體應(yīng)用等應(yīng)用。

在醫(yī)學(xué)圖像管理模塊，用戶通過醫(yī)學(xué)圖像上傳應(yīng)用對圖像信息、圖像描述、圖像文件進(jìn)行填寫，圖像上傳后存儲在HBase平臺中。具體操作如圖8所示。

圖8 醫(yī)學(xué)圖像上傳應(yīng)用操作界面

用戶可以通過醫(yī)學(xué)圖像列表應(yīng)用查看醫(yī)學(xué)圖像記錄，可以根據(jù)圖像類型、開始時間和結(jié)束時間進(jìn)行簡單篩選。具體操作如圖9所示。

圖9 醫(yī)學(xué)圖像列表應(yīng)用操作界面

在醫(yī)學(xué)圖像檢索應(yīng)用中，用戶可以通過以圖搜圖的方式對醫(yī)學(xué)圖像庫中已有的圖像進(jìn)行檢索，檢索結(jié)果按相似度從小到大進(jìn)行排序。具體操作如圖10所示。

圖10 醫(yī)學(xué)圖像檢索應(yīng)用操作界面

5 結(jié)束語

針對海量醫(yī)學(xué)圖像存儲、檢索的效率問題，本文設(shè)計并實現(xiàn)一種基于Flink的醫(yī)學(xué)圖像檢索系統(tǒng)。系統(tǒng)利用Flink批流一體的架構(gòu)提高并行檢索效率，實現(xiàn)實時圖像編碼、批量圖像上傳編碼和圖像并行檢索。圖像檢索過程使用深度卷積神經(jīng)網(wǎng)絡(luò)模型提取圖像特征并利用乘積量化編碼模型進(jìn)行特征編碼。同時，通過Web應(yīng)用作為用戶操作入口，系統(tǒng)通過HBase存儲醫(yī)學(xué)圖像數(shù)據(jù)和圖像特征編碼數(shù)據(jù)。實驗結(jié)果表明，本系統(tǒng)具有更好的檢索效率表現(xiàn)，滿足實際應(yīng)用需求。