基于DTFS的PACS存儲系統設計

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

（1.河南省職工醫院，河南鄭州450002；2.河南省衛健委統計信息中心，河南鄭州450000；3.中國廣電河南網絡有限公司，河南鄭州450000；4.洛陽職業技術學院，河南洛陽471000）

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

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

1 國內外研究現狀

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

2 系統背景技術

2.1 分布式哈希表

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

2.2 區塊鏈

2008年11月中本聰提出“比特幣”概念，2009年初實踐化區塊鏈正式誕生，全球掀起區塊鏈熱潮。目前已經從以“比特幣”為代表的1.0 時代發展到3.0 時代。區塊鏈（blockchain)利用P2P 協議、數字加密、時間戳、分布式數據存儲等技術實現數據的去中心化鏈式存儲，各節點間通過共識機制（主要包括工作量證明PoW、權益證明PoS、權威證明PoA、DPos股份授權證明機制、交易量證明機制EPos）確保鏈上數據的一致性。

3 平臺設計

3.1 PACS系統存儲應用現狀

現在各醫院PACS 多采用SAN 結構的單一存儲，存儲構架如圖1所示。

圖1 基于SAN的單一存儲構架

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

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

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

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

4）一般采用SMBNFS 等方式與第三方系統進行數據共享，如果遇到操作系統漏洞，可能導致數據被破壞或者泄露。

5）所有的數據通信都需要通過PACS 服務器，如果業務量大則壓力無法平衡。

3.2 DTFS整體解決方案

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

圖2 基于DTFS的PACS存儲系統

1）采用HTTP、HTTPS 和WebDev 協議。

2）客戶端支持Windows/Linux 操作系統。

3）數據采用中心加分布式存儲并統一采用版本控制模式。

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

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

3.3 DTFS 節點存儲分層設計

DTFS Node 的存儲方式采用三層設計架構，各層設計功能如下。

1）冷數據層

用于存儲長期保留的數據。在新建DTFS Node時，一般采用后臺多線程方式從同節點設備進行數據塊同步，當DTFS Node IO 或CPU 占用率較高時降低寫指令頻率。

2）溫數據層

從當前DTFS Node 的PC 產生的數據，優先寫入本地，并將結果上報中心服務器完成同步；根據主服務發布的廣播指令進行數據同步，以類CNS 方式減少或緩解客戶端對服務器端請求壓力。

3）熱數據層

除中心服務器外，所有的DTFS Node 均有本地數據庫，只存儲DTFS Server 下發的指令和需要上報的指令和數據區塊。

3.4 算法設計

3.4.1 DTFS node 審核

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

3.4.2 新建文件過程

新建文件過程也即導入DTFS 系統的過程，具體流程如下：

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

2）服務器獲取并簽入數據后，廣播指令給1/5 的在網資源較富余的Node 并分批下發同步指令，Node按DTFS-Tree 結構根據資源狀態進行同步，服務端可在后臺查看目前Node 節點和數據的運行狀態。

3）Node 節點的策略分為Full 模式及Auto 模式。通常可選取服務器集群中業務原資源消耗率較低的節點標識為Full Node，用于DTFS 數據優先資源同步；其他終端節點標識為Auto Node,并根據日常監控資源使用情況進行Auto 分發同步；Auto 模式設置兩種狀態，即CDN 狀態和鏡像狀態（鏡像狀態包含CDN功能），如果所有節點達不到DTFS鏡像模式的最低標準，則僅啟動CDN功能，DTFS將失去災備恢復能力。

3.4.3 讀取文件過程

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

1）調用請求DTFS API 接口并傳送＜Gid, Did,Hash＞,接口可選擇獲取對應的Version信息及與之相關的存儲路徑信息等，并根據路徑信息自動從本地或路徑導航指示Node 數據塊中獲取相應文件數據。

2）獲取文件數據后，DTFS API 調用Server 上存儲的對應密鑰對數據進行解密；解密后的文件數據存儲于Node 節點上的內存數據庫中。

3）讀取文件過程結束后，DTFS API 對內存數據進行釋放。

3.4.4 修改文件過程

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

1）版本覆蓋模式

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

2）版本升級模式

Gid 不變Version+1；Did 和Hash 產生新的與修改后的切片一同上傳，同時服務端下發指令，將Gid下原有版本的數據在所有節點上聲明Version 升級。

3.4.5 刪除文件過程

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

1）徹底刪除模式

根據Gid 直接刪除所有歷史版本，所有Server和Node 節點啟動就會執行，服務端只會保留刪除歷史。

2）版本刪除模式

根據Gid 的獲取版本號并將相應版本標記刪除；刪除后客戶端將不再獲取該版本數據，但其他數據節點會暫存該節點信息直至同步數據資源不足時釋放。

3.4.6 核心過程實現

基于DTFS 平臺的PCAS 文件存儲核心過程實現詳見算法1,算法涉及文件導入、權限判斷、加密、DTFS Node 間數據傳送、異步處理等過程。算法1 展示如下：

3.5 系統安全機制

3.5.1 DTFS 標記約束

每個軟件應用DTFS 的時候，需通過平臺申請賬號并獲取系統為軟件應用分配唯一標識及會話認證key；軟件應用調用DTFS API 時，會根據機制獲取會話令牌用于文件操作流程。

3.5.2 文件命名約束

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

3.5.3 數據訪問原理

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

3.5.4 數據同步鏡像原則

鏡像服務需要通過節點實時備份且至少保證在線設備空間與主服務器可用空間比例為1∶1，以下對理想狀態與非理想狀態下存儲網絡狀態進行了分析，分析假設：服務器端需同步數據大小為20 TB，客戶端數量為100 臺。

1）理想狀態

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

2）非理想狀態

節點不滿足DTFS 的基礎需求，則DTFS 工作采用熱CDN 模式。該模式下，對近期有訪問的數據進行緩存，容量超限之后，自動刪除訪問率較低的數據，當核心服務器數據丟失后，不可全量恢復、僅可支持恢復所有節點當前版本數據。

3）成本對比分析

以下將PACS 存儲分別在SAN 模式及DTFS 模式下的存儲服務器硬件成本及運營恢復成本進行了分析對比，分析結果表明：基于DTFS的存儲模式無論在硬件成本及運營恢復成本上均優于傳統PACS模式。

①存儲、服務器等硬件成本分析

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

②運營成本分析

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

3.5.5 數據災難恢復

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

4 結 論

數據儲存備份壓力、數據并發傳輸效率、數據遷移風險是PACS 信息化平臺中面臨的重要問題。文中在醫院PACS 平臺之上設計了一個基于DTFS 的存儲分發容災平臺，可有效延緩系統升級時間以實現資源高效利用并降低成本投入，同時通過存儲及安全機制策略設計可有效提高系統的數據傳輸速度、提升系統安全性能并降低災難性數據丟失風險。