基于DTFS的PACS存儲系統(tǒng)設(shè)計

朱彥霞，陳益洲，華南，羅劉敏

（1.河南省職工醫(yī)院，河南鄭州450002；2.河南省衛(wèi)健委統(tǒng)計信息中心，河南鄭州450000；3.中國廣電河南網(wǎng)絡(luò)有限公司，河南鄭州450000；4.洛陽職業(yè)技術(shù)學(xué)院，河南洛陽471000）

目前，醫(yī)療信息數(shù)據(jù)的存儲主要采取傳統(tǒng)的中心化SAN 存儲方式，平均每個患者醫(yī)療影像（PACS）存儲數(shù)據(jù)在500 MB 以上[1]，以三級醫(yī)院為例，根據(jù)國家衛(wèi)生統(tǒng)計中心相關(guān)數(shù)據(jù)2019年全國三級醫(yī)院平均出院人數(shù)約為3～3.5 萬人，僅單向存儲PACS 數(shù)據(jù)空間至少占約14 TB，由此面臨極大的存儲、備份、存儲擴(kuò)容壓力以及隨著數(shù)據(jù)量增加而帶來的數(shù)據(jù)庫訪問壓力；尤其當(dāng)醫(yī)院進(jìn)行存儲硬件更換、軟件系統(tǒng)升級時將面臨具大的數(shù)據(jù)遷移壓力以及數(shù)據(jù)完整性、一致性、遷移效率低下等問題。在日常的診療業(yè)務(wù)中，醫(yī)院局域網(wǎng)內(nèi)存在服務(wù)器及終端分時段存儲、網(wǎng)絡(luò)資源閑置或利用率不高的問題。如何在確保數(shù)據(jù)安全的前提下，提高醫(yī)院硬件存儲、網(wǎng)絡(luò)資源的利用率是醫(yī)院信息化管理極為關(guān)注的話題。

區(qū)塊鏈具有去中心化、可追溯、安全可靠等優(yōu)點(diǎn)[2-3]，網(wǎng)絡(luò)中各節(jié)點(diǎn)遵守特定的共識機(jī)制實(shí)現(xiàn)相互間的信息及權(quán)益的獲取。文中提出并設(shè)計了一種基于分布式傳輸文件系統(tǒng)（Distributed Transmission File System,DTFS）的PACS 存儲系統(tǒng)，充分利用現(xiàn)有各網(wǎng)絡(luò)節(jié)點(diǎn)時段性閑置資源及私有區(qū)塊鏈、加密算法等技術(shù)，實(shí)現(xiàn)分節(jié)點(diǎn)數(shù)據(jù)的存儲、傳輸與備份，在PACS 業(yè)務(wù)數(shù)據(jù)傳輸方面可有效提高文件網(wǎng)絡(luò)存取速度、降低數(shù)據(jù)坍塌式損毀風(fēng)險。

1 國內(nèi)外研究現(xiàn)狀

近年來，國內(nèi)外許多研究人員和機(jī)構(gòu)運(yùn)用區(qū)塊鏈技術(shù)在醫(yī)療領(lǐng)域積極探索并取得了一定進(jìn)展。目前，區(qū)塊鏈技術(shù)主要應(yīng)用[4-9]于電子健康病例存儲與共享、醫(yī)療欺詐與理賠、藥品溯源與防偽、DNA 錢包、比特幣支付、藥品防偽、蛋白質(zhì)折疊等方面。2015年，飛利浦與Tierion 合作，實(shí)現(xiàn)將醫(yī)療數(shù)據(jù)記錄到區(qū)塊鏈中[10]，同年，Guardtime 實(shí)現(xiàn)了基于Hash 計算的密碼學(xué)無鑰簽名基礎(chǔ)設(shè)施的區(qū)塊鏈技術(shù)[11]；2016年4月，飛利浦與區(qū)塊鏈技術(shù)公司Gem 共同推出了Gem Health[12]項目以推動醫(yī)療領(lǐng)域間的合作，同年，PokitDok 公司與因特爾公司合作，提出“Dokchain”醫(yī)療區(qū)塊鏈計劃，擬構(gòu)建醫(yī)療領(lǐng)域臨床與財務(wù)數(shù)據(jù)的分布式網(wǎng)絡(luò)解決方案[13]；2017年，Patientory 發(fā)布區(qū)塊鏈醫(yī)療應(yīng)用平臺[14]，為患者與醫(yī)護(hù)人員之間搭建安全數(shù)據(jù)存儲點(diǎn)，實(shí)現(xiàn)患者對個人醫(yī)療健康歷史數(shù)據(jù)的訪問；2018年，沃爾瑪獲得三項有關(guān)區(qū)塊鏈專利，其基于區(qū)塊鏈的醫(yī)療記錄系統(tǒng)將患者數(shù)據(jù)存儲在分布式賬本中[15]，當(dāng)病人遇到無意識的昏迷情況等緊急情況時，相關(guān)醫(yī)療記錄可被授權(quán)訪問；2019年，文獻(xiàn)[16]將區(qū)塊鏈與非對稱加密技術(shù)結(jié)合，有效利用非對稱加密安全性高、多方協(xié)作簡單等特點(diǎn)，實(shí)現(xiàn)醫(yī)療記錄跨域分享的數(shù)據(jù)追蹤、防篡改及身份驗(yàn)證的簡化。文獻(xiàn)[17]針對單管理節(jié)點(diǎn)易遭受攻擊和威脅，通過設(shè)計雙區(qū)塊鏈結(jié)構(gòu)分別實(shí)現(xiàn)醫(yī)療記錄存儲與共享。在文中，充分利用現(xiàn)有網(wǎng)絡(luò)資源時段冗余特點(diǎn)、通過軟技術(shù)實(shí)現(xiàn)基于DTFS 的PACS 存儲優(yōu)化，可節(jié)省投入成本，提升系統(tǒng)安全、運(yùn)行性能。

2 系統(tǒng)背景技術(shù)

2.1 分布式哈希表

分布式哈希表（Distributed Hash Table，DHT)是分布式存儲與傳輸?shù)年P(guān)鍵技術(shù)，廣泛應(yīng)用于P2P 網(wǎng)絡(luò)中。網(wǎng)絡(luò)中各節(jié)點(diǎn)共同維護(hù)一個形如＜key,value＞的文件索引Hash 表，通常將文件的Hash 值存入key中、將IP 地址存入value 中；這個Hash 表會按照一定的規(guī)則算法分割成若干份存儲于網(wǎng)絡(luò)的各節(jié)點(diǎn)中，每個節(jié)點(diǎn)僅維護(hù)一小部分Hash 表；當(dāng)查找時，僅需查找相應(yīng)報文路由到相應(yīng)節(jié)點(diǎn)即可[18]。

2.2 區(qū)塊鏈

2008年11月中本聰提出“比特幣”概念，2009年初實(shí)踐化區(qū)塊鏈正式誕生，全球掀起區(qū)塊鏈熱潮。目前已經(jīng)從以“比特幣”為代表的1.0 時代發(fā)展到3.0 時代。區(qū)塊鏈（blockchain)利用P2P 協(xié)議、數(shù)字加密、時間戳、分布式數(shù)據(jù)存儲等技術(shù)實(shí)現(xiàn)數(shù)據(jù)的去中心化鏈?zhǔn)酱鎯Γ鞴?jié)點(diǎn)間通過共識機(jī)制（主要包括工作量證明PoW、權(quán)益證明PoS、權(quán)威證明PoA、DPos股份授權(quán)證明機(jī)制、交易量證明機(jī)制EPos）確保鏈上數(shù)據(jù)的一致性。

3 平臺設(shè)計

3.1 PACS系統(tǒng)存儲應(yīng)用現(xiàn)狀

現(xiàn)在各醫(yī)院PACS 多采用SAN 結(jié)構(gòu)的單一存儲，存儲構(gòu)架如圖1所示。

圖1 基于SAN的單一存儲構(gòu)架

以一個省級三甲醫(yī)院為例，一年至少能產(chǎn)生15 TB的數(shù)據(jù)，如果每份數(shù)據(jù)文件以20 kB～10 MB 顆粒度計算，將至少存儲150 萬個左右小文件。在此背景下，基于SAN 存儲面臨的主要問題如下：

1）一般要求SAN 主備鏡像，主備鏡像日常數(shù)據(jù)同步需消耗較大的存儲及I/O 壓力。

2）當(dāng)發(fā)生主備鏡像中的某數(shù)據(jù)存在異常錯誤，主備鏡像數(shù)據(jù)全部恢復(fù)耗時較大，同時恢復(fù)期間設(shè)備I/O 占用率為100%，有造成服務(wù)停止的風(fēng)險。

3）當(dāng)存儲的小文件達(dá)到一定量時，無論是NTFS還是EXT4 等常見分區(qū)格式，對文件的檢索和查詢性能均會降低。

4）一般采用SMBNFS 等方式與第三方系統(tǒng)進(jìn)行數(shù)據(jù)共享，如果遇到操作系統(tǒng)漏洞，可能導(dǎo)致數(shù)據(jù)被破壞或者泄露。

5）所有的數(shù)據(jù)通信都需要通過PACS 服務(wù)器，如果業(yè)務(wù)量大則壓力無法平衡。

3.2 DTFS整體解決方案

該文基于DTFS 的PACS 存儲系統(tǒng)方案如圖2所示，其整體設(shè)計思路如下：

圖2 基于DTFS的PACS存儲系統(tǒng)

1）采用HTTP、HTTPS 和WebDev 協(xié)議。

2）客戶端支持Windows/Linux 操作系統(tǒng)。

3）數(shù)據(jù)采用中心加分布式存儲并統(tǒng)一采用版本控制模式。

4）DTFS Server 服務(wù)端為全量存儲并以塊文件方式存儲物理文件，小文件打包存儲，大文件以切片形式存儲于核心數(shù)據(jù)庫。

5）DTFS Node 客戶端后臺運(yùn)行不會打擾桌面用戶，可通過Server 設(shè)置分布式存儲和內(nèi)存使用的大小，無需全量存儲數(shù)據(jù)，但需保持?jǐn)?shù)據(jù)索引與服務(wù)端數(shù)據(jù)庫版本同步；當(dāng)使用DTFS 的程序提取數(shù)據(jù)時，首先判斷是否在本地存儲，若是，則直接讀取本地區(qū)塊，若否，則通過DTFS Server 的API 直接取得網(wǎng)內(nèi)區(qū)塊；DTFS Node 需定期上報本地資源使用情況，保證某個節(jié)點(diǎn)的I/O、CPU 和剩余空間壓力不至于過大（設(shè)置臨界點(diǎn)）。

3.3 DTFS 節(jié)點(diǎn)存儲分層設(shè)計

DTFS Node 的存儲方式采用三層設(shè)計架構(gòu)，各層設(shè)計功能如下。

1）冷數(shù)據(jù)層

用于存儲長期保留的數(shù)據(jù)。在新建DTFS Node時，一般采用后臺多線程方式從同節(jié)點(diǎn)設(shè)備進(jìn)行數(shù)據(jù)塊同步，當(dāng)DTFS Node IO 或CPU 占用率較高時降低寫指令頻率。

2）溫數(shù)據(jù)層

從當(dāng)前DTFS Node 的PC 產(chǎn)生的數(shù)據(jù)，優(yōu)先寫入本地，并將結(jié)果上報中心服務(wù)器完成同步；根據(jù)主服務(wù)發(fā)布的廣播指令進(jìn)行數(shù)據(jù)同步，以類CNS 方式減少或緩解客戶端對服務(wù)器端請求壓力。

3）熱數(shù)據(jù)層

除中心服務(wù)器外，所有的DTFS Node 均有本地數(shù)據(jù)庫，只存儲DTFS Server 下發(fā)的指令和需要上報的指令和數(shù)據(jù)區(qū)塊。

3.4 算法設(shè)計

3.4.1 DTFS node 審核

每個DTFS Node 安裝后會產(chǎn)生一個GUID 并提示用戶選擇服務(wù)器或輸入服務(wù)器IP；鏈接成功后并對本地資源進(jìn)行上報，上報后DTFS Server 會審核此Node；DTFS Node 通過審核后，服務(wù)端根據(jù)DTFS Node 的硬件水平設(shè)置磁盤和內(nèi)存的策略，然后DTFS Node 轉(zhuǎn)入后臺運(yùn)行；在使用DTFS 的APP 或者WebAPP 通過認(rèn)證機(jī)制訪問DTFS API 接口操作數(shù)據(jù)時，在設(shè)備硬件性能不足時可設(shè)置禁用本地緩存直接從服務(wù)器推薦的DTFS 節(jié)點(diǎn)讀取數(shù)據(jù)。

3.4.2 新建文件過程

新建文件過程也即導(dǎo)入DTFS 系統(tǒng)的過程，具體流程如下：

1）首先根據(jù)用戶ID(UID) 獲取用戶角色(UserRole)，同時調(diào)用本地DTFS API 接口對文件進(jìn)行二進(jìn)制流化處理并根據(jù)設(shè)定切片包大小(Buffer_len)進(jìn)行數(shù)據(jù)流切片；與服務(wù)器進(jìn)行握手，用＜Public key, Private key＞進(jìn)行數(shù)據(jù)加密并獲取Hash、Did、Gid、Version 等相關(guān)信息后打包上報；上報后數(shù)據(jù)分別存儲于DTFS Server 及當(dāng)前DTFS Node。

2）服務(wù)器獲取并簽入數(shù)據(jù)后，廣播指令給1/5 的在網(wǎng)資源較富余的Node 并分批下發(fā)同步指令，Node按DTFS-Tree 結(jié)構(gòu)根據(jù)資源狀態(tài)進(jìn)行同步，服務(wù)端可在后臺查看目前Node 節(jié)點(diǎn)和數(shù)據(jù)的運(yùn)行狀態(tài)。

3）Node 節(jié)點(diǎn)的策略分為Full 模式及Auto 模式。通常可選取服務(wù)器集群中業(yè)務(wù)原資源消耗率較低的節(jié)點(diǎn)標(biāo)識為Full Node，用于DTFS 數(shù)據(jù)優(yōu)先資源同步；其他終端節(jié)點(diǎn)標(biāo)識為Auto Node,并根據(jù)日常監(jiān)控資源使用情況進(jìn)行Auto 分發(fā)同步；Auto 模式設(shè)置兩種狀態(tài)，即CDN 狀態(tài)和鏡像狀態(tài)（鏡像狀態(tài)包含CDN功能），如果所有節(jié)點(diǎn)達(dá)不到DTFS鏡像模式的最低標(biāo)準(zhǔn)，則僅啟動CDN功能，DTFS將失去災(zāi)備恢復(fù)能力。

3.4.3 讀取文件過程

文件讀取過程中主要采用NO-SQL 技術(shù)完成內(nèi)存數(shù)據(jù)操作等，具體流程如下：

1）調(diào)用請求DTFS API 接口并傳送＜Gid, Did,Hash＞,接口可選擇獲取對應(yīng)的Version信息及與之相關(guān)的存儲路徑信息等，并根據(jù)路徑信息自動從本地或路徑導(dǎo)航指示Node 數(shù)據(jù)塊中獲取相應(yīng)文件數(shù)據(jù)。

2）獲取文件數(shù)據(jù)后，DTFS API 調(diào)用Server 上存儲的對應(yīng)密鑰對數(shù)據(jù)進(jìn)行解密；解密后的文件數(shù)據(jù)存儲于Node 節(jié)點(diǎn)上的內(nèi)存數(shù)據(jù)庫中。

3）讀取文件過程結(jié)束后，DTFS API 對內(nèi)存數(shù)據(jù)進(jìn)行釋放。

3.4.4 修改文件過程

文件修改過程支持版本控制功能，主要分為版本覆蓋、版本升級兩種模式，具體流程如下：

1）版本覆蓋模式

Gid 不變Version+1；Did 和Hash 會被刷新與修改后的切片一同上傳，同時服務(wù)端下發(fā)指令，將Gid下原有版本的數(shù)據(jù)在所有節(jié)點(diǎn)上聲明清除已節(jié)省空間；此時所有Node 節(jié)點(diǎn)獲取數(shù)據(jù)時只能請求Server端或已經(jīng)同步過的Node 節(jié)點(diǎn)來獲取數(shù)據(jù)。

2）版本升級模式

Gid 不變Version+1；Did 和Hash 產(chǎn)生新的與修改后的切片一同上傳，同時服務(wù)端下發(fā)指令，將Gid下原有版本的數(shù)據(jù)在所有節(jié)點(diǎn)上聲明Version 升級。

3.4.5 刪除文件過程

文件刪除過程也采用了版本控制機(jī)制，分為徹底刪除和當(dāng)前版本刪除兩種模式，具體流程如下：

1）徹底刪除模式

根據(jù)Gid 直接刪除所有歷史版本，所有Server和Node 節(jié)點(diǎn)啟動就會執(zhí)行，服務(wù)端只會保留刪除歷史。

2）版本刪除模式

根據(jù)Gid 的獲取版本號并將相應(yīng)版本標(biāo)記刪除；刪除后客戶端將不再獲取該版本數(shù)據(jù)，但其他數(shù)據(jù)節(jié)點(diǎn)會暫存該節(jié)點(diǎn)信息直至同步數(shù)據(jù)資源不足時釋放。

3.4.6 核心過程實(shí)現(xiàn)

基于DTFS 平臺的PCAS 文件存儲核心過程實(shí)現(xiàn)詳見算法1,算法涉及文件導(dǎo)入、權(quán)限判斷、加密、DTFS Node 間數(shù)據(jù)傳送、異步處理等過程。算法1 展示如下：

3.5 系統(tǒng)安全機(jī)制

3.5.1 DTFS 標(biāo)記約束

每個軟件應(yīng)用DTFS 的時候，需通過平臺申請賬號并獲取系統(tǒng)為軟件應(yīng)用分配唯一標(biāo)識及會話認(rèn)證key；軟件應(yīng)用調(diào)用DTFS API 時，會根據(jù)機(jī)制獲取會話令牌用于文件操作流程。

3.5.2 文件命名約束

文件命名根據(jù)路徑軌跡以冒號分隔，以軟件應(yīng)用APP1 創(chuàng)建及查詢PACS 文件過程為例：創(chuàng)建過程，創(chuàng)建形如App1：眼科：張某：2020-04-22：眼部掃描.zip的文件；查詢過程根據(jù)命名約束進(jìn)行路徑拆解掃描，并根據(jù)接口調(diào)用及傳參情況獲取相應(yīng)資源。

3.5.3 數(shù)據(jù)訪問原理

本地軟件由DTFS API 調(diào)用平臺會串行化一個http/https 地址用于數(shù)據(jù)本地軟件的獲取；DTFS API還支持WebDev 模式，可實(shí)現(xiàn)類Windows 操作文件方式，但不支持徹底刪除和選擇版本讀取。

3.5.4 數(shù)據(jù)同步鏡像原則

鏡像服務(wù)需要通過節(jié)點(diǎn)實(shí)時備份且至少保證在線設(shè)備空間與主服務(wù)器可用空間比例為1∶1，以下對理想狀態(tài)與非理想狀態(tài)下存儲網(wǎng)絡(luò)狀態(tài)進(jìn)行了分析，分析假設(shè)：服務(wù)器端需同步數(shù)據(jù)大小為20 TB，客戶端數(shù)量為100 臺。

1）理想狀態(tài)

理想狀態(tài)下所有節(jié)點(diǎn)設(shè)備的可存儲空間在全量數(shù)據(jù)的5 倍左右，此基礎(chǔ)配置下可以保證極端情況下至少有33%的設(shè)備在線以支撐系統(tǒng)正常運(yùn)行要求；按照每臺PC 終端可劃出1 TB 的存儲空間用于DTFS 存儲，根據(jù)員工晝夜輪休情況，全院2/3 的電腦在非工作時間處于關(guān)機(jī)狀態(tài)，則剩余的1/3 的電腦已可滿足服務(wù)器端的鏡像同步需求。

2）非理想狀態(tài)

節(jié)點(diǎn)不滿足DTFS 的基礎(chǔ)需求，則DTFS 工作采用熱CDN 模式。該模式下，對近期有訪問的數(shù)據(jù)進(jìn)行緩存，容量超限之后，自動刪除訪問率較低的數(shù)據(jù)，當(dāng)核心服務(wù)器數(shù)據(jù)丟失后，不可全量恢復(fù)、僅可支持恢復(fù)所有節(jié)點(diǎn)當(dāng)前版本數(shù)據(jù)。

3）成本對比分析

以下將PACS 存儲分別在SAN 模式及DTFS 模式下的存儲服務(wù)器硬件成本及運(yùn)營恢復(fù)成本進(jìn)行了分析對比，分析結(jié)果表明：基于DTFS的存儲模式無論在硬件成本及運(yùn)營恢復(fù)成本上均優(yōu)于傳統(tǒng)PACS模式。

①存儲、服務(wù)器等硬件成本分析

傳統(tǒng)SAN 模式服務(wù)器采用Raid5，有效存儲20 TB，服務(wù)器、硬盤及配套硬件總成本約6 萬；采用DTFS 模式，以100 臺PC 客戶端構(gòu)建DTFS 子節(jié)點(diǎn)同時考慮服務(wù)器冗余資源利用。根據(jù)市場調(diào)查目前PC 客戶端硬盤存儲不小于2 TB，空閑存儲不小于1 TB 可用于DTFS，平臺整體硬件成本將小于3 萬元，當(dāng)客戶端在線率及冗余率增高時，其DTFS 擴(kuò)容成本隨之降低。

②運(yùn)營成本分析

客戶端請求服務(wù)器讀取數(shù)據(jù)時服務(wù)器端會產(chǎn)生大量網(wǎng)絡(luò)和I/O 壓力，對服務(wù)器及網(wǎng)絡(luò)擴(kuò)容需求增高帶來相應(yīng)運(yùn)營成本不斷增高；采用DTFS 按照局域網(wǎng)是1 000 M 計算，通過瀑布式傳輸可分步實(shí)現(xiàn)數(shù)據(jù)同步傳輸，常規(guī)數(shù)據(jù)的讀寫不直接再請求核心服務(wù)器，充分緩解了核心服務(wù)器和核心交換機(jī)的壓力，延緩了IT 擴(kuò)容的周期，相應(yīng)運(yùn)營成本增幅較慢。

3.5.5 數(shù)據(jù)災(zāi)難恢復(fù)

系統(tǒng)設(shè)計充分考慮數(shù)據(jù)災(zāi)難恢復(fù)方案：當(dāng)遭遇中心服務(wù)器宕機(jī)數(shù)據(jù)徹底丟失時，首先重新部署服務(wù)器；部署完成后，各Node 端自動鏈接Server（如果服務(wù)端IP 域名變更則需Node 端相應(yīng)重新配置），Server 端審核后，審核通過的Node 會自動上傳本地版本庫的數(shù)據(jù)和版本日志，只要本地分節(jié)點(diǎn)的數(shù)據(jù)覆蓋能達(dá)到100%則數(shù)據(jù)可以完美恢復(fù)；在恢復(fù)過程中，Node 的數(shù)據(jù)可能會發(fā)生篡改或損壞，則Node 節(jié)點(diǎn)之間需要進(jìn)行批量數(shù)據(jù)塊校驗(yàn)比對，通過服務(wù)端仲裁策略決定服務(wù)端的最終恢復(fù)相應(yīng)版本數(shù)據(jù)；當(dāng)冗余備份不足時，僅恢復(fù)當(dāng)前節(jié)點(diǎn)版本數(shù)據(jù)。

4 結(jié) 論

數(shù)據(jù)儲存?zhèn)浞輭毫Α?shù)據(jù)并發(fā)傳輸效率、數(shù)據(jù)遷移風(fēng)險是PACS 信息化平臺中面臨的重要問題。文中在醫(yī)院PACS 平臺之上設(shè)計了一個基于DTFS 的存儲分發(fā)容災(zāi)平臺，可有效延緩系統(tǒng)升級時間以實(shí)現(xiàn)資源高效利用并降低成本投入，同時通過存儲及安全機(jī)制策略設(shè)計可有效提高系統(tǒng)的數(shù)據(jù)傳輸速度、提升系統(tǒng)安全性能并降低災(zāi)難性數(shù)據(jù)丟失風(fēng)險。