施 曉 峰

(浦東新區(qū)檔案局 上海 200135)

0 引 言

隨著檔案館資源體系建設(shè)步伐不斷加快及檔案信息化建設(shè)的不斷深入，數(shù)字檔案資源的種類和容量都在快速增長，呈現(xiàn)出海量、多類型與高價值的大數(shù)據(jù)特征。新技術(shù)的發(fā)展給檔案大數(shù)據(jù)的管理帶來了新的機遇和挑戰(zhàn)。如何更好地收集、保管和利用檔案信息，是一個值得認真思考的課題[1]。

相對于傳統(tǒng)關(guān)系型數(shù)據(jù)庫，分布式NoSQL數(shù)據(jù)庫性能高、成本低、更靈活，結(jié)合分布式系統(tǒng)抗單點故障能力和 NoSQL 的天然水平伸縮性特點，能夠從容應(yīng)對海量數(shù)據(jù)的挑戰(zhàn)[2]。

本文通過分析傳統(tǒng)檔案數(shù)據(jù)管理中存在的問題，以分布式NoSQL數(shù)據(jù)庫為基礎(chǔ)，制定了可行的檔案大數(shù)據(jù)存儲與檢索方案，并采用業(yè)界當(dāng)前的主流技術(shù)，開發(fā)了原型系統(tǒng)進行驗證。

1 檔案大數(shù)據(jù)的特征

在當(dāng)前高度信息化的社會環(huán)境下，包括檔案行業(yè)在內(nèi)的各個領(lǐng)域都在業(yè)務(wù)工作中都積累了海量的電子數(shù)據(jù)。

這些數(shù)據(jù)主要分為三種：第一種是結(jié)構(gòu)化數(shù)據(jù)，可以用二維關(guān)系表結(jié)構(gòu)表示，一般存儲在關(guān)系型數(shù)據(jù)庫中；第二種是半結(jié)構(gòu)化數(shù)據(jù)，例如XML、JSON；第三種是非結(jié)構(gòu)化數(shù)據(jù)，包括各種格式的電子文件(TXT、Word、PDF)、圖片、音頻、視頻等。隨著社會信息技術(shù)的發(fā)展，檔案館接收的數(shù)據(jù)內(nèi)容也在發(fā)生著變化，半結(jié)構(gòu)和非結(jié)構(gòu)化的數(shù)據(jù)越來越多，各類電子文件、多媒體文件正在成為館藏的重要來源。

通過分析檔案館的數(shù)據(jù)資源，我們發(fā)現(xiàn)檔案大數(shù)據(jù)具有以下幾個特征：

(1) 格式多樣。既有紙質(zhì)檔案的數(shù)字化副本、接收進館的電子文件、檔案著錄信息、OCR的成果文本、聲像資料，也有用戶信息、利用記錄、架體位置等各種業(yè)務(wù)數(shù)據(jù)。

(2) 結(jié)構(gòu)復(fù)雜。檔案目錄數(shù)據(jù)同時具有結(jié)構(gòu)化和半結(jié)構(gòu)化的特征，每條記錄包含幾十個字段，有一部分是共用的字段，其他字段則隨著檔案類型的不同而變化。

(3) 規(guī)模龐大。無論是目錄數(shù)據(jù)還是電子文件的數(shù)量，都可達到千萬級以上，容量可達幾十TB。

此外，在實際業(yè)務(wù)工作中，檔案館的數(shù)據(jù)還具有以下特性：

(1) 數(shù)據(jù)大批量集中寫入多，一旦導(dǎo)入，很少發(fā)生更改操作。

(2) 數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系較少。

(3) 需要支持多種查詢方式，要有很好的查詢性能，但實時性和并發(fā)訪問要求不高。

(4) 隨著檔案類別的不斷增多，要求數(shù)據(jù)庫具有很好的可擴展性。

2 檔案數(shù)據(jù)管理現(xiàn)狀及問題

2.1 結(jié)構(gòu)化數(shù)據(jù)的存儲模式

檔案的結(jié)構(gòu)化與半結(jié)構(gòu)化數(shù)據(jù)一般是指檔案的元數(shù)據(jù)。檔案元數(shù)據(jù)是一組用來描述數(shù)字檔案內(nèi)容與其他特性的元素集，包括傳統(tǒng)的檔案著錄要素，例如檔號、題名、責(zé)任者等，也包括文件的產(chǎn)生背景、形成過程、結(jié)構(gòu)格式等，是組織與管理數(shù)字檔案資源的基礎(chǔ)數(shù)據(jù)。

關(guān)系型數(shù)據(jù)庫具有很強的安全性、良好的數(shù)學(xué)基礎(chǔ)支撐，在許多需要保證事務(wù)一致性的行業(yè)，如電信、銀行等的關(guān)鍵業(yè)務(wù)系統(tǒng)中應(yīng)用廣泛。當(dāng)前，采用成熟的關(guān)系型數(shù)據(jù)庫，集中存儲和管理檔案元數(shù)據(jù)是業(yè)界的主流模式。

但是隨著社會的發(fā)展，檔案的門類不斷擴展，各門類檔案既有統(tǒng)一的管理要求，又有各自個性化的需求，檔案元數(shù)據(jù)也在不斷地更新與變化，半結(jié)構(gòu)化的趨勢愈加明顯。

關(guān)系數(shù)據(jù)庫的模型不靈活、橫向擴展能力較差，使用傳統(tǒng)關(guān)系型數(shù)據(jù)庫進行檔案檢索正面臨越來越嚴(yán)峻的挑戰(zhàn)，檢索速度慢、結(jié)果質(zhì)量低[3]，已經(jīng)難以滿足數(shù)據(jù)快速增長帶來的更新和查詢需求了。

2.2 非結(jié)構(gòu)化數(shù)據(jù)的存儲模式

檔案的非結(jié)構(gòu)化數(shù)據(jù)主要包括紙質(zhì)檔案的數(shù)字化副本、電子文件歸檔形成的電子檔案、照片、音視頻等。目前，檔案的非結(jié)構(gòu)化數(shù)據(jù)主要采取以下兩種存儲方式：

(1) 直接將非結(jié)構(gòu)化數(shù)據(jù)以二進制大對象(BLOB)的形式存儲在關(guān)系型數(shù)據(jù)庫中。采用這種方式的優(yōu)勢在于可以依靠數(shù)據(jù)庫自身來保障數(shù)據(jù)的安全性、事務(wù)的一致性等。但其劣勢在于，用關(guān)系型數(shù)據(jù)庫存儲非結(jié)構(gòu)化數(shù)據(jù)時，不斷增加的文件數(shù)量會導(dǎo)致數(shù)據(jù)庫的體積不斷增大，讀寫性能持續(xù)下降。在進行數(shù)據(jù)庫備份和還原時，速度也會變得非常緩慢。

(2) 將非結(jié)構(gòu)化數(shù)據(jù)通過文件系統(tǒng)直接存儲在文件服務(wù)器中。數(shù)據(jù)文件按一定規(guī)則存放于服務(wù)器的指定目錄下，需要訪問數(shù)據(jù)時，應(yīng)用系統(tǒng)通過保存在關(guān)系型數(shù)據(jù)庫中的存儲路徑讀取服務(wù)器上的文件。這種模式的可擴展性較差，不支持數(shù)據(jù)復(fù)制，不具備負載均衡等特性，文件高并發(fā)訪問性能不理想[4]，容易出現(xiàn)系統(tǒng)瓶頸。隨著檔案數(shù)字資源量劇增、業(yè)務(wù)需求激增，傳統(tǒng)文件系統(tǒng)提供的數(shù)據(jù)存儲能力和性能已經(jīng)不能滿足應(yīng)用的需要，也無法更好地解決海量小文件的索引、查找、統(tǒng)計、備份等一系列問題。

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

3.1 MongoDB

NoSQL(Not Only SQL)是對非傳統(tǒng)關(guān)系型數(shù)據(jù)庫的統(tǒng)稱，具有快速讀寫、動態(tài)伸縮、模式靈活、高可靠低成本等特點。主要可以分為以下5類：(1) 鍵值(Key-value)數(shù)據(jù)庫，例如Dynamo、Redis；(2) 面向文檔(Document)數(shù)據(jù)庫，例如MongoDB、CouchDB；(3) 面向列(Column)數(shù)據(jù)庫，例如BigTabe、HBase；(4) 圖形(Graph)數(shù)據(jù)庫，例如AllegroGraph、Neo4j；(5) 多模型(Multi-model)數(shù)據(jù)庫，例如ArangoDB、OrientDB。

MongoDB是一款面向文檔的分布式NoSQL數(shù)據(jù)庫，功能十分豐富，易部署、易使用，并且保留了很多關(guān)系型數(shù)據(jù)庫的特性。MongoDB使用BSON作為數(shù)據(jù)存儲和傳輸?shù)母袷?，支持?nèi)嵌的文檔對象和數(shù)組對象，僅用一條記錄就能表示復(fù)雜的層次關(guān)系，十分靈活[5]。MongoDB支持集群部署、數(shù)據(jù)分片，具有高性能、可擴展的特點。

3.2 FastDFS

FastDFS是一款開源的分布式文件系統(tǒng)，用C語言編寫，支持Linux、FreeBSD、AIX等UNIX系統(tǒng)[6]，提供文件的存儲、同步、訪問等管理功能，已在包括淘寶、京東、迅雷等眾多國內(nèi)互聯(lián)網(wǎng)公司中得到廣泛應(yīng)用。主要包括以下特性：

(1) 能夠在不中斷服務(wù)的情況下實現(xiàn)存儲的線性擴展。

(2) 提供負載均衡，對文件的訪問可以分散到多個服務(wù)節(jié)點上。

(3) 避免單點故障，系統(tǒng)中的所有角色都可以采用集群部署，實現(xiàn)冗余。

(4) 文件不分塊，直接存儲在文件系統(tǒng)中，不會加重服務(wù)器的工作量，適合小文件存儲。

FastDFS較好地解決了海量數(shù)據(jù)冗余備份、負載均衡、線性擴容等問題，部署硬件成本低，非常適合用于管理4 KB至500 MB之間的中小型文件，與檔案館需要存儲海量電子文件的使用場景十分吻合。

3.3 Elasticsearch

檢索服務(wù)是檔案數(shù)據(jù)管理與利用的核心。傳統(tǒng)集中式的檢索方式資源覆蓋面較窄， 資源更新和維護比較困難，檢索速度也比較緩慢[7]。

Elasticsearch(以下簡稱ES)是一個開源的、分布式搜索分析引擎，基于Java開發(fā)并使用Lucene作為其核心來實現(xiàn)索引和搜索的功能，具有近實時、高性能、高可用和易擴展等優(yōu)點。

ES能夠在很短的時間內(nèi)完成數(shù)據(jù)索引，提供近乎實時的搜索體驗；同時，ES可以把一個完整的索引進行分片(Shards)存儲，均勻分配到各個服務(wù)節(jié)點上，并對索引和搜索做負載均衡； ES還可以設(shè)置多個索引副本(Replicas)，防止硬件故障造成的數(shù)據(jù)丟失；此外，ES很容易進行橫向擴展，新增的服務(wù)節(jié)點能夠自動地加入集群而無需人工干預(yù)。

目前，很多互聯(lián)網(wǎng)公司都使用ES來搭建自己的搜索系統(tǒng)。比如Github(代碼管理網(wǎng)站)使用 ES對1 300億行代碼進行查詢；Wikipedia(維基百科)使用 ES提供帶有高亮片段的全文搜索[8]；百度目前也廣泛使用ES作為文本數(shù)據(jù)分析，采集服務(wù)器上的各類指標(biāo)數(shù)據(jù)及用戶自定義數(shù)據(jù)，并進行多維分析展示，給業(yè)務(wù)工作提供輔助決策。

4 方案設(shè)計與實現(xiàn)

4.1 總體框架

本方案總體框架底層采用了虛擬化資源池，以提高資源利用效率，實現(xiàn)硬件資源的動態(tài)分配、靈活調(diào)度，特別適合分布式系統(tǒng)的部署與應(yīng)用。數(shù)據(jù)服務(wù)層采用MongoDB保存結(jié)構(gòu)化與半結(jié)構(gòu)化的檔案數(shù)據(jù)，用FastDFS存儲電子文件，用ES實現(xiàn)內(nèi)容索引與檢索，所有服務(wù)均采用集群模式部署，實現(xiàn)整體功能的負載均衡與故障轉(zhuǎn)移。在通用接口層，通過構(gòu)建對外統(tǒng)一的數(shù)據(jù)訪問與查詢接口，簡化上層應(yīng)用與數(shù)據(jù)服務(wù)層之間的交互流程，如圖1所示。

圖1 總體框架設(shè)計

4.2 集群構(gòu)架

4.2.1MongoDB集群

MongoDB的集群一般有主從，副本集和分片三種模式，本文采用了分片集群(Sharded Cluster)的方式，如圖2所示。MongoDB可以通過自動將數(shù)據(jù)分散存儲到不同機器上來實現(xiàn)數(shù)據(jù)庫的水平擴展，這樣只需要增加普通服務(wù)器就可以提高數(shù)據(jù)庫的存儲空間與負載性能。

圖2 MongoDB 集群構(gòu)架

這種方式主要包括三種角色：Shard、Mongos與Config Server。

Shard：數(shù)據(jù)分片，每個分片根據(jù)規(guī)則保存完整數(shù)據(jù)中的一部分，通常采用副本集(Replica Set)的方式部署以保證安全。本研究采用三成員副本集，每個分片包含一個主數(shù)據(jù)節(jié)點(Primary)和兩個備份節(jié)點(Secondary)。主節(jié)點負責(zé)數(shù)據(jù)寫入，兩個備份節(jié)點與主節(jié)點保持數(shù)據(jù)同步，當(dāng)主節(jié)點發(fā)生故障時，其中一個備份節(jié)點會升級成主節(jié)點。

Mongos：路由服務(wù)，只負責(zé)把客戶端的數(shù)據(jù)請求轉(zhuǎn)發(fā)到對應(yīng)的數(shù)據(jù)分片上，然后把結(jié)果返回到客戶端，本身不存儲數(shù)據(jù)。Mongos可以配置多個節(jié)點以實現(xiàn)冗余。

Config Server：配置服務(wù)器，存儲分片集群的元數(shù)據(jù)與配置信息，通常也采用兩副本部署。

Mongos啟動時從Config Server上獲取基本信息，在接受到客戶端的請求時，路由到分片(Shard)服務(wù)器上，然后將返回的數(shù)據(jù)結(jié)果發(fā)回給客戶端。

4.2.2FastDFS集群

與其他分布式文件系統(tǒng)相比，F(xiàn)astDFS的構(gòu)架更加簡潔，只有Tracker Server和Storage Server兩種角色。Tracker Server主要負責(zé)負載均衡和任務(wù)調(diào)度，Storage Server則負責(zé)文件數(shù)據(jù)的存儲。

本方案中，存儲服務(wù)集群采用了兩個組(Group1和Group2)，每個組配置了三臺Storage Server，每個Server上的數(shù)據(jù)完全一致，互為冗余。集群可以通過添加組來實現(xiàn)存儲空間的線性擴展，如圖3所示。

圖3 FastDFS集群構(gòu)架

跟蹤服務(wù)集群配置了三臺Tracker Server同時提供服務(wù)，Server之間的關(guān)系相互平等，負載均衡，不存在單點故障。

客戶端在需要時向Tracker Server發(fā)出請求，獲取到可用的Storage Server地址后，直接與之通信，完成文件的上傳和下載。

此外，在每個Storage Server上還部署了Nginx，解決組內(nèi)Storage Server同步延遲導(dǎo)致文件暫時無法訪問的問題，同時提供HTTP訪問服務(wù)。

4.2.3Elasticsearch集群

在ES 5中，集群的節(jié)點(Node)一般有三種角色:Master、Data和Ingest。

Master：主節(jié)點，主要用于維護集群狀態(tài)和配置集群，比如索引的創(chuàng)建與刪除、分片的分配等。

Data：數(shù)據(jù)節(jié)點，保存包含索引的數(shù)據(jù)分片，負責(zé)與數(shù)據(jù)、搜索與聚合相關(guān)的操作，這些操作對CPU、內(nèi)存和 I/O 資源的消耗較大。

Ingest：轉(zhuǎn)換節(jié)點，執(zhí)行常見的數(shù)據(jù)轉(zhuǎn)換和預(yù)處理，如果不需要則無需配置。

默認情況下，一個節(jié)點可以同時擔(dān)任Master和Data兩種角色，但為了保證集群的可伸縮性，建議不同的類型節(jié)點分開部署。本文采用的集群配置如圖4所示。

圖4 Elasticsearch集群構(gòu)架

設(shè)置三個主節(jié)點(Master-only)，負責(zé)統(tǒng)籌集群層面的事務(wù)，維護數(shù)據(jù)節(jié)點的索引和分片。另外規(guī)劃三節(jié)點的數(shù)據(jù)集群(Data-only)，專注于索引數(shù)據(jù)的存儲和面向客戶端的檢索服務(wù)。同時，將索引數(shù)據(jù)分為3個片，每個分片各有2個副本分片作為備份。整個集群實現(xiàn)了負載均衡以及數(shù)據(jù)冗余，避免了單點故障。

4.3 數(shù)據(jù)模型設(shè)計

在MongoDB中，設(shè)計數(shù)據(jù)模型的關(guān)鍵應(yīng)圍繞文檔的結(jié)構(gòu)和應(yīng)用程序如何表示數(shù)據(jù)之間的關(guān)聯(lián)關(guān)系。MongoDB中有兩種方式來表示這些關(guān)系：嵌入式文檔和引用。

以檔案中最常見的數(shù)據(jù)對象——案卷目錄與卷內(nèi)目錄(按件歸檔時則為歸檔文件目錄與件內(nèi)文件目錄)為例，兩者為“1”對“N”的關(guān)系。案卷目錄和卷內(nèi)目錄都可以單獨進行查詢、更新等操作。綜合考慮，這里采用了父引用方式建模。

將案卷目錄存放在集合Archives中, 每一條案卷目錄作為一個MongoDB文檔。一條案卷目錄的文檔如下：

{

″_id″:ObjectId(″59f470a3e95db40408000029″),

″acode″:″6.D4.7.2004-006331″,

″archivesname″:″XXX房地產(chǎn)檔案(產(chǎn)權(quán))″,

″gatherunit″:″上海市房屋土地資源管理局(浦東新區(qū))″,

″gatherdate″:″2004/11/11″,

″savetimeout″:″永久″,

″papernumber″:″17″,

″drawnumber″:″6″,

″receiveno″:″200425138XXXX″,

″certificationno″:″浦2004122XXX″,

″owner″:″鄧XX″,

″idno″:″35010254080XXXX″,

″houseplace″:″德平路24弄2X號6XX室″,

″buildarea″:″49.21″

}

將卷內(nèi)目錄存放在集合Archives_File中，每一條卷內(nèi)目錄作為一個MongoDB文檔。卷內(nèi)目錄文檔中保存案卷目錄文檔的acode引用，便于關(guān)聯(lián)查詢。一條卷內(nèi)目錄文檔如下：

{

″_id″:ObjectId(″59f3de27e95db46408000029″),

″acode″:″6.D4.7.2004-006331″,//案卷級文檔的引用

″sequenceid″:″2″,

″filecode″:″″,

″person″:″″,

″title″:″封面目錄備考表″,

″datevalue″:″2003/11/5″,

″pageno″:″4″,

″pagecount″:″3″,

″remark″:″″,

″filename″:″6.D4.7.2004-006331_4.tif″,

″filepath″:″group2/M00/00/89/eQ6h3FKfPRl8p4AUz4wO8tqaA688.tif″ //對應(yīng)電子文件在FastDFS中的索引(FID)

}

卷內(nèi)目錄對應(yīng)的電子文件保存在FastDFS文件系統(tǒng)中，文件索引(FID)由組名、虛擬磁盤路徑、數(shù)據(jù)兩級目錄和文件名組成。

4.4 存儲與檢索流程的實現(xiàn)

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

結(jié)構(gòu)化與半結(jié)構(gòu)化的數(shù)據(jù)按照預(yù)先定義的數(shù)據(jù)模型，通過程序接口保存到MongoDB中。

文件對象通過程序接口直接上傳到FastDFS，服務(wù)器會將文件的索引(FID)返回給客戶端，客戶端再將FID寫入MongoDB對應(yīng)的記錄中，用于以后該文件的訪問。

最后，通過mongo-connector將MongoDB中的數(shù)據(jù)自動同步到ES中，同步過程中elastic2_doc_manager負責(zé)將數(shù)據(jù)寫入到ES，如圖5所示。

圖5 數(shù)據(jù)存儲流程

4.4.2數(shù)據(jù)檢索流程

用戶通過客戶端向ES發(fā)起查詢請求，ES返回摘要結(jié)果，需要查看詳細結(jié)果時，通過摘要記錄的ID查找MongoDB數(shù)據(jù)庫，返回詳細記錄。

需要訪問對應(yīng)的文件時，根據(jù)記錄中保存的文件索引(FID)向FastDFS發(fā)起請求，F(xiàn)astDFS通過解析FID，定位到文件所在的存儲服務(wù)器組與磁盤目錄，并根據(jù)文件名找到相應(yīng)的文件，最后將文件下載到客戶端，如圖6所示。

圖6 數(shù)據(jù)檢索流程

4.5 原型系統(tǒng)搭建

原型系統(tǒng)采用虛擬化平臺進行搭建，由于實驗條件限制，使用了2臺PC服務(wù)器機，采用簡化設(shè)置，共7個節(jié)點，配置情況如表1所示。

表1 服務(wù)器角色配置表

系統(tǒng)采用PHP進行開發(fā)。MongoDB對PHP支持良好，尤其是高并發(fā)和schema-free(自由結(jié)構(gòu))特性，使PHP開發(fā)變得更加靈活和高效。

系統(tǒng)主要包括三個功能，如圖7所示。

圖7 系統(tǒng)主界面

(1) 數(shù)據(jù)導(dǎo)入。支持Access數(shù)據(jù)文件與TIFF圖像的導(dǎo)入，一次可以導(dǎo)入幾萬或者十幾萬條，容量達到幾GB甚至幾十GB。

(2) 數(shù)據(jù)查詢。可以針對需要的字段進行模糊檢索并顯示結(jié)果列表，如圖8所示。

圖8 數(shù)據(jù)查詢功能

(3) 數(shù)據(jù)管理。可以查看已導(dǎo)入的數(shù)據(jù)情況并進行簡單管理。

通過一段時間的測試，原型系統(tǒng)運行穩(wěn)定，大批量數(shù)據(jù)的寫入與檢索性能優(yōu)良，達到了文本的研究目的。

5 結(jié) 語

本文首先分析了檔案大數(shù)據(jù)的特征與存儲現(xiàn)狀，然后通過對相關(guān)技術(shù)的比較和研究，設(shè)計了一套基于分布式NoSQL數(shù)據(jù)庫的檔案大數(shù)據(jù)存儲方案，并開發(fā)了原型系統(tǒng)進行驗證。

此方案的系統(tǒng)構(gòu)建成本低、性能強，同時具有良好的可靠性和可擴展性，適合作為智慧檔案館大數(shù)據(jù)管理的基礎(chǔ)平臺，為各類檔案信息化應(yīng)用提供通用、開放的數(shù)據(jù)存儲與檢索服務(wù)，也為今后模式識別、自然語言理解、應(yīng)用知識庫、可視化展示等大數(shù)據(jù)技術(shù)在智慧檔案中的應(yīng)用提供有力保障。