李林陽，呂志平，陳正生，樊黎暉

（1.信息工程大學 地理空間信息學院，鄭州 450052；2.成都測繪信息中心，成都 610000）

1 引言

20世紀80年代，加拿大首先提出 “主動控制系統(tǒng)”概念，并于1995年建成了第一個全球定位系統(tǒng)（global positioning system，GPS）連續(xù)運行參考站網（continuous operating reference station system，CORS）。隨著差分技術、網絡實時動態(tài)差分法（real－time kinematic，RTK）技術的出現(xiàn)與逐步普及以及計算機技術、網絡通信技術的飛速發(fā)展，CORS得到了不斷發(fā)展和壯大，世界上很多國家紛紛建成了國家級、區(qū)域級、城市級的CORS［1－4］。面對規(guī)模龐大的 CORS站網及其連續(xù)觀測，如何對CORS數據進行高效地存儲、組織、管理與發(fā)布，提高處理和分發(fā)的效率，緩解海量數據與有限的計算、存儲能力的矛盾 成為一個迫切需要解決的問題。

目前已建成的CORS數據管理系統(tǒng)大部分基于FTP文件格式存儲原始數據，如國際全球衛(wèi)星導航系統(tǒng)國際服務協(xié)會（international global navigation satellite system service，IGS）和中國大陸構造環(huán)境監(jiān)測網絡簡稱陸態(tài)網（crustal movement observation network of China，CMONOC），用戶通過FTP下載數據產品。這種管理模式技術成熟，但存在如下缺點：結構簡單，缺乏統(tǒng)一管理機制；信息安全性、完整性低，不具備并發(fā)控制與故障恢復的功能；實時性差，用戶不能實時地獲取數據。

2006年投入使用的北京全球定位綜合應用服務系統(tǒng)（BGIAS）采用基于關系數據庫技術的實時數據存儲與應用服務方案［6］。文獻 ［7］在關系數據庫的基礎上，提出適用于實時服務的數據預處理結合Huffman編碼的壓縮方法和事后數據服務的Huffman和LZ77編碼結合的壓縮方法，實現(xiàn)了CORS數據的無損壓縮。該方式組織靈活，檢索管理方便；但其對服務器性能要求高，隨數據量的增加檢索速度降低，并發(fā)共享和抗災容錯能力較差。

綜上所述，以上三種存儲模型均采用集中式存儲，隨著CORS數據的幾何倍數增長［1］以及單個節(jié)點硬件設備的限制［8］，這些方式在管理海量數據（Tbit甚至Pbit級）方面存在諸多限制［9］，集中存儲策略已不能滿足大規(guī)模存儲應用的需要。大型CORS網具有基站數量多、觀測數據多、數據共享關系復雜的特點，基站與各數據中心相連，各數據中心又可互相通信，其本身就是一個天然的分布式系統(tǒng)［10］。本文對CORS站網的數據量進行了分析，指出了集中式數據存儲管理海量CORS數據的問題；研究了CORS數據云存儲模型，提出了CORS數據云存儲集群、組織和訪問架構；基于分布式數據處理平臺Hadoop，采用多臺存儲節(jié)點分擔存儲負荷，突破了CORS數據集中存儲方式不易擴展、可靠性差等缺點，具有管理方便、組織靈活、高抗災容錯性、高擴展性、高數據讀取性能，支持大吞吐量數據的并發(fā)訪問，適于海量CORS數據的高性能應用。

2 CORS數據量分析

CORS站每天主要采集的數據類型有三種：觀測數據文件、導航星歷文件和氣象文件。觀測數據文件主要包括低采樣率（15s30s 和高采樣率（1s）的數據。1s采樣率的數據量較大，受限于數據中心的存儲空間，一般存儲時間短，目前只存儲1a或2a，15s或30s采樣率數據永久存儲；星歷文件一般為幾十kbit，個別包含了格洛納斯衛(wèi)星導航系統(tǒng)（global navigation satellite system，GLONASS）星歷的文件較大，達到幾百kbit；氣象文件一般也為幾十kbit。CORS數據量估算如表1。

表1 一個CORS站的數據量估算（僅觀測GPS衛(wèi)星）

圖1 SOPAC的數據量統(tǒng)計

以IGS站為例，截止至2014年4月，全球共有495個IGS站，假定每個站點采集了高采樣率的數據，每站每年共接收7～14Gbit的衛(wèi)星數據，全網每年共產生3.4～6.8Tbit的數據量，再加上數據分析中心發(fā)布及提供的各項產品和服務，數據存儲服務器需要管理海量的數據和產品。斯克里普斯軌道和常駐陣列中心（scripps orbit and permanent array center，SOPAC）作為IGS數據操作中心之一，自1996年以來其存儲和管理的數據量如圖1所示。已建成的陸態(tài)網由260個連續(xù)觀測和2 000個不定期觀測站點構成，單站單天30s采樣率的數據文件（d文件）大約為600kbit，2013全年30s采樣率的數據達到48Gbit。BGIAS每天觀測產生的數據量約為600Mbit，全年約為214Gbit。

隨著GPS現(xiàn)代化進程加快、GLONASS系統(tǒng)恢復使用、伽利略衛(wèi)星導航系統(tǒng)（Galileo navigation satellite system，Galileo）和我國北斗衛(wèi)星導航系統(tǒng)（BeiDou navigation satellite systemBDS的投入使用，各個衛(wèi)星系統(tǒng)之間穩(wěn)步實現(xiàn)的兼容互操作為用戶提供了大量可用衛(wèi)星數，CORS站觀測數據量的大小將成倍增加。目前部分IGS站和全部陸態(tài)網參考站采集了GLONASS數據，每天接收的數據量至少增加了一倍。

面對海量CORS數據及發(fā)布的產品，集中式CORS數據存儲策略采用 “存儲服務器＋獨立磁盤冗余陣列（redundant array of independent disk，RAID）”的方式管理CORS數據和產品，受單節(jié)點服務器性能和網絡帶寬的限制，中心節(jié)點成為系統(tǒng)的瓶頸，系統(tǒng)的擴展性、可靠性和抗災容錯性能不足，存在用戶訪問延遲大、數據下載速率慢等問題。

3 CORS數據云存儲模型架構設計

3.1 CORS數據云存儲的定義及平臺架構

CORS數據云存儲是指通過集群應用、網格技術或分布式文件系統(tǒng)等功能，將CORS系統(tǒng)中大量不同類型的存儲設備通過應用軟件集合起來協(xié)同工作，共同對外提供CORS數據存儲、產品服務和用戶訪問的系統(tǒng)。

CORS數據云儲存平臺架構可以劃分為：CORS數據存儲層、系統(tǒng)基礎管理層、CORS應用接口層、CORS用戶訪問層，如圖2所示。

圖2 CORS數據云存儲平臺架構

CORS數據存儲層是云存儲最基礎的部分。存儲設備為每個數據中心的硬件設備，每個數據中心構成獨立的云存儲集群，分布在不同的地域，集群之間通過互聯(lián)網連接，進行數據交換。統(tǒng)一的存儲設備管理層通過存儲虛擬化和集群管理技術，對存儲硬件資源進行抽象化表現(xiàn)，實現(xiàn)數據和存儲設備的統(tǒng)一管理［［11－13］。

系統(tǒng)基礎管理層是云存儲最核心、最難實現(xiàn)的部分。通過集群系統(tǒng)、分布式文件系統(tǒng)和網格計算等技術，實現(xiàn)云存儲設備之間的協(xié)同工作，提供同一種服務和更強的數據訪問性能［14］；內容分發(fā)系統(tǒng)保證CORS數據不會被未授權的用戶所訪問［15］；通過數據備份、加密、容災技術可以提高CORS數據的可靠性。

CORS應用接口層是云存儲最靈活多變的部分，它面向用戶的各種需求。根據CORS的建設、維護和升級及各類用戶的需求，開發(fā)不同的應用服務類型，提供不同的應用程序編程接口（application programming interface，API）及應用軟件，采用不同的CORS數據傳輸協(xié)議。例如在差分數據傳輸中，可采用國際海運事業(yè)無線電技術委員會（radio technical commission for maritime services，RTCM）數據傳輸協(xié)議［16］（networked transport of RTCM via internet protocol，NTRIP）。

CORS用戶訪問層包括各類通過授權的用戶，通過標準的公用接口接入CORS數據云存儲系統(tǒng)，進行實時差分定位，下載數據和產品等，享受云存儲提供的服務。

3.2 CORS數據云存儲集群架構

在云存儲和計算方面，Hadoop是一個可以對海量數據進行分布式處理的軟件框架［17－18］，具有可靠、高效、可擴展這三大特性，加上Hadoop開源免費的特性，Hadoop技術迅猛發(fā)展。Hadoop采用主／從（Master／Slave）架構，其重要組成部分是分布式文件系統(tǒng)（hadoop distributed file system，HDFS），一個HDFS由一個NameNode、一個Secondary NameNode和若干個DataNode這三個守護進程組成。

基于HDFS的運行體系，設計了CORS云存儲集群體系架構，將一個CORS數據中心定義為一個集群，若有多個數據中心則建設多個集群。體系架構如圖3所示。

1）數據中心的NameNode節(jié)點負責管理該數據中心的DataNode節(jié)點，并以 “文件路徑／CORS數據塊集合”的形式記錄集群內CORS數據的存儲位置；

2）Secondary NameNode節(jié)點是輔助Name－Node節(jié)點，運行在數據中心的一臺計算機上，與NameNode節(jié)點保持通信，按照一定時間間隔保持CORS云存儲集群元數據的快照，以備NameNode節(jié)點發(fā)生故障時進行CORS數據恢復。

3）數據中心的其它硬件設備為DataNode節(jié)點，在本地文件系統(tǒng)中以數據塊的形式存儲CORS數據產品，響應用戶對CORS數據塊和元數據的請求，周期性地向NameNode報告所存儲的CORS數據塊信息。

相比傳統(tǒng)的集中式CORS數據存儲，圖3所示的CORS數據云存儲架構具有以下技術特點：

1）數據存儲在各數據中心的硬件設備中，各數據中心之間相互通信、獨立運行、互相兼容，任何存儲單元均可作為存儲節(jié)點加入到CORS集群，大大提高了集群存儲和計算容量的擴展性。

2）CORS數據流入、流出DataNode節(jié)點，對數據中心的服務器要求較低，不會成為系統(tǒng)的瓶頸。

3）采用機架感知［19］（rack awareness）的策略，NameNode節(jié)點可以確定每個DataNode節(jié)點所屬的機架ID，改進了數據的可用性、可靠性和網絡帶寬的利用率；

4）集群啟動時，自動進入安全模式，計算CORS數據塊數量、集群內的可用節(jié)點數、可用存儲空間等，保證了CORS數據的完整性和可靠性。

5）集群運行時，通過DataNode節(jié)點的塊報告（block report）和心跳檢測（heartbeat）機制，數據中心NameNode節(jié)點監(jiān)控各DataNode節(jié)點的運行狀態(tài)、磁盤利用率、網絡帶寬等，均衡集群中各個計算機的存儲負載，優(yōu)化集群的運行。

圖3 數據中心CORS數據云存儲邏輯框架

6）Secondary NameNode保持對CORS數據系統(tǒng)元數據的快照，在NameNode節(jié)點發(fā)生故障時進行數據恢復，提高了系統(tǒng)的健壯性。

3.3 CORS數據云存儲組織架構

數據中心發(fā)布的產品，建立products存儲目錄，再依據產品種類，如軌道和鐘差（預報、快速、精密）、對流層天頂延遲、電離層格網圖、地球自轉參數、參考站坐標及速率等，分別建立子目錄。由于發(fā)布的產品種類較多、類型各異，各產品大小不一，最小的只有幾kbit，最大的達到數Gbit。Hadoop在存儲大文件方面，采取數據塊存儲的方式，將每個大文件分成若干個數據塊，存儲在不同的DataNode節(jié)點，數據塊的尺寸可以調整為默認值128Mbit（Hadoop 2.0的默認值）的整數倍；在小文件存儲方面，可以使用Archive工具、CombineFileInputFormat類、SequenceFile格式，分別將許多小文件歸為一個HAR文件、將多個文件打包到一個分片、利用key－value合并文件，降低了集群的存儲容量開銷和總數據中心的內存開銷。

CORS站實時采集高采樣率數據文件，實時傳輸到數據中心，進行質量檢核并轉換為RINEX格式，數據中心的DataNode節(jié)點執(zhí)行數據寫入集群操作，即可實現(xiàn)數據的實時共享；CORS數據寫入的過程是即時、動態(tài)的，滿足網絡RTK等實時定位技術的需求，同時實現(xiàn)了CORS數據的完全備份。CORS觀測數據的存儲目錄按年積日進行排列，建立與觀測日期對應的文件夾，存放觀測當天所有CORS站的觀測數據。

當數據副本數（dfs.replication）為3h（可設置為更大參數），部署策略是將第一個副本存放在本節(jié)點，第二個副本放在同一機架的另一個Data－Node節(jié)點，最后一個副本放在另一個機架的DataNode節(jié)點。數據文件1的3個副本的存放位置如上圖3所示。通過副本存放策略，集群具備了抗災性和容錯性；機架的錯誤遠比DataNode節(jié)點的錯誤少，這個策略可以防止數據中心內的整個機架因故障失效時，不會影響到CORS數據和產品的可靠、可用性。

利用Hadoop的分布式數據處理模塊MapReduce，可生成采樣率是1s整數倍的觀測數據文件。因此在年積日的目錄下，可建立1s、15s、30s采樣率的文件夾，授權用戶可以下載指定采樣率和指定時間段的觀測數據文件。生成30s采樣率數據文件的流程如下圖4，分為輸入分片（input splitmapreduce和輸出（output 四個步驟。分片是將RINEX觀測文件按照測站名和觀測日期劃分為數據塊；map函數對每一分片的數據逐行進行過濾，轉換為由文件頭信息和觀測歷元的數據組成的鍵／值對；reduce函數根據指定的采樣率和采樣時間，變更文件頭信息，提取觀測歷元，排序后生成新的觀測數據文件。多個節(jié)點的map和reduce共同完成整個CORS網觀測數據的處理。

圖4 30s采樣率文件生成流程

3.4 CORS數據云存儲訪問架構

基于Hadoop的CORS數據云存儲技術為用戶提供了便捷的共享機制，通過訪問NameNode節(jié)點的50070端口進入分布式文件系統(tǒng)，可以查看集群的存儲容量、集群內可用和失效節(jié)點數、集群運行日志、集群配置和部署情況、CORS數據和產品總量、CORS數據文件位置等，在被授權之后，用戶可以下載CORS數據和產品，下載時通過檢驗文件創(chuàng)建時的校驗和提高了數據傳輸的完整性和可靠性。

由于CORS數據分布地存儲在各個DataNode節(jié)點，Hadoop實現(xiàn)了樹形的網絡拓撲結構［20］，通過網絡節(jié)點的規(guī)劃機制，NameNode節(jié)點會根據存儲節(jié)點與用戶之間的 “距離”和網絡帶寬對多個DataNode進行排序后返回給用戶，以便從最快的存儲節(jié)點讀取數據，減少CORS數據的傳輸時間。

為了支持在線用戶同時進行的大吞吐量數據的并發(fā)訪問（滿足較多網絡RTK用戶實時需求和支持大量用戶的并發(fā)數據下載），采用了支持并發(fā)常用的多服務隊列機制，包括：

1）NameNode服務隊列。用戶接受差分定位服務和下載CORS數據產品時，需要從NameNode節(jié)點獲取文件的元數據，根據系統(tǒng)訪問量合理設置dfs.namenode.handler.count參數控制的線程數量，來響應大量用戶的并發(fā)訪問請求。

2）DataNode服務隊列。用戶在線服務以及數據的讀取均發(fā)生在各數據中心的DataNode節(jié)點，可以啟動dfs.datanode.handler.count參數控制的線程數量，應對CORS數據塊讀取操作。

3）用戶請求隊列等待。從1）和2）看，NameNode和DataNode都采用了服務隊列機制處理并發(fā)請求，當用戶并發(fā)請求數超過總線程數時，請求會在隊列中等待。

通過合理配置以上3個服務隊列的數量，會有效提高CORS數據云存儲集群的服務效率。

4 實驗分析

實驗環(huán)境：虛擬機選擇VMware Workstation10.0.1build－1379776，操作系統(tǒng)選擇Ubuntu 13.10。實驗搭建了Hadoop完全分布式集群，由一臺NameNode（同時作為Secondary NameNode）和三臺DataNode節(jié)點組成，IP地址設置如下：NameNode：192.168.100.129，DataNode1： 192.168.100.130，DataNode2： 192.168.100.131，DataNode3：192.168.100.141。以陸態(tài)網2013年的觀測數據為例，通過HDFS API建立了存儲目錄，將全年的觀測數據寫入到集群中。集群搭建情況如圖5所示。

圖5 實驗搭建的云存儲集群

4.1 集群可靠安全性

在啟動集群，首先啟動NameNode節(jié)點，不啟動任何DataNode節(jié)點，通過http訪問192.168.100.129的50070端口，看到live node數為0，集群一開始會自動進入安全模式。

隨著DataNode節(jié)點的啟動，當NameNode監(jiān)測到足夠數量的數據塊，集群才會退出安全模式；本實驗中三臺DataNode節(jié)點啟動后，才退出安全模式。集群運行過程中，每隔1h，DataNode都會向NameNode發(fā)送一個心跳報告和塊報告（對應日志文件），包含了全部DataNode磁盤中所有CORS數據塊的信息，NameNode可以跟蹤監(jiān)測數據塊的變化。

4.2 集群抗災容錯性

為了測試在存儲節(jié)點失效的時，CORS數據的完整性，在設置副本數為2的前提下，關閉某一存儲節(jié)點。如圖6的最下端所示，中國周邊IGS站.txt存儲在DataNode1和DataNode2節(jié)點。將DataNode2節(jié)點關閉，如圖7所示，中國周邊IGS站.txt存儲在DataNode1和DataNode3節(jié)點中。在關閉DataNode2節(jié)點的整個過程中，集群正常運行，并未受到DataNode2節(jié)點失效的影響。

圖6 DataNode2節(jié)點關閉前文件存儲位置

圖7 DataNode2節(jié)點關閉后文件存儲位置

4.3 集群擴展性

隨CORS數據量的增長，需要對集群的存儲容量和計算能力進行擴充，如圖8所示，只需四個步驟即可實現(xiàn)集群擴容。

圖8 集群擴容示意圖

同時，Ambari作為Hadoop的集群部署與監(jiān)控集成工具，最多可在1h內安裝1 000個節(jié)點的存儲集群，全部操作采用界面呈現(xiàn)的形式，易于操作，可迅速實現(xiàn)展集群的擴展。

4.4 下載速率

將陸態(tài)網2013年前8d的觀測數據文件（d文件）合并，壓縮后大小約為1Gbit，前16d約為2Gbit，前32d約為4Gbit。分別測試了云存儲集群的下載時間和VSFTP（Ubuntu系統(tǒng)下的FTP軟件）的下載時間，下載時間取五次下載的平均值，如下圖9所示，橫軸為數據文件大小，縱軸為下載時間。

圖9 FTP和HDFS的下載時間比對

從上圖可以看出，較FTP下載方式，采用支持并發(fā)常用的多服務隊列機制的云存儲下載機制更快，更節(jié)約時間。

隨CORS數據集群規(guī)模的擴大，當存在大量用戶進行并發(fā)訪問請求時，由于云存儲突破了單節(jié)點訪問下載的限制，可以實現(xiàn)網絡帶寬的最優(yōu)化利用，從而用戶的訪問延遲更小，可從最快的存儲節(jié)點獲取CORS數據和產品。

5 結束語

隨著國家、區(qū)域、行業(yè)型CORS的建成及連續(xù)觀測，CORS數據規(guī)模迅速增長，本文對CORS站網的數據量進行了分析，針對當前CORS數據管理系統(tǒng)普遍采用的集中管理策略，指出了其存在的問題；提出了CORS數據云存儲，設計了CORS數據云存儲集群、組織和訪問架構；可將已建成的各個參考站、數據中心納入到云存儲集群中。在虛擬機環(huán)境下搭建了Hadoop集群，分析了CORS數據云存儲的可靠性、抗災容錯性、擴展性和下載速率。CORS數據云存儲突破了傳統(tǒng)集中式數據存儲技術的局限，可提高CORS數據產品組織、管理和發(fā)布的效率和可靠性。云存儲為CORS數據分布式計算提供了源數據基礎和保障，為用戶在線解算提供了基礎平臺。

［1］ 黃俊華，陳文森.連續(xù)運行衛(wèi)星定位綜合服務系統(tǒng)建設與應用［M］.北京：科學出版社，2009：51－85.

［2］ 劉經南，劉暉.建立我國衛(wèi)星定位連續(xù)運行參考站網的若干思考［J］.武漢大學學報：信息科學版，2003，28（特刊）：27－31.

［3］ 陳俊勇.構建全球導航衛(wèi)星中國國家級連續(xù)運行站網［J］.測繪通報，2009（9）：6－8.

［4］ 陳俊勇，張鵬，武軍酈，等.關于在中國構建全球導航衛(wèi)星國家級連續(xù)運行站系統(tǒng)的思考［J］.測繪學報，2007，36（4）：16－19.

［5］ 崔陽，呂志平，陳正生.Web Services分布式計算在大規(guī)模網平差中的應用［J］.大地測量與地球動力學，2013，33（2）：136－139.

［6］ 譚志彬，戴連君，過靜珺，等.GPS連續(xù)運行參考站網數據存儲［J］.測繪通報，2003（11）：8－10.

［7］ 徐冬晨.基于CORS系統(tǒng)的數據存儲的研究［D］.南京：東南大學，2010：5－6.

［8］ 崔陽，呂志平，陳正生，等.多核環(huán)境下的 GNSS網平差數據并行處理研究［J］.測繪學報，2013，42（5）：661－667.

［9］ 岳利群.基于分布式存儲的虛擬地理環(huán)境關鍵技術研究［D］.鄭州：解放軍信息工程大學，2011：106－112.

［10］ 呂志平，陳正生，崔陽.大型CORS網基線向量的分布式處理［J］.測繪科學技術學報，2013，30（4）：109－114.

［11］ 劉琨，李愛菊，董龍江.基于 Hadoop的云存儲的研究及實現(xiàn)［J］.微計算機信息，2011，27（7）：228－229.

［12］ 張龍立.云存儲技術探討［J］.電信科學，2010（增刊）：77－80.

［13］ 周可，王樺，李春花.云存儲技術及其應用［J］.中興通訊技術，2010，16（4）：29－32.

［14］ 晏強，張曉峰，丁蕊.云存儲技術研究［J］.計算機信息技術，2011（12）：26－28.

［15］ 唐箭.云存儲系統(tǒng)的分析與應用研究［J］.電腦知識與技術，2009，5（20）：13－14.

［16］ 祁芳，林鴻.Ntrip協(xié)議在 CORS系統(tǒng)中的應用［J］.城市測繪，2008（1）：85－88.

［17］ DEAN J，GHEMAWAT S.Mapreduce：Simplified Data Processing on Large Clusters［EB／OL］.［2014－02－18］.http：／／static.googleusercontent.com／media／research.google.com／zh－CN／／archive／mapreduce－osdi04.pdf.

［18］ GHEMAWAT S，GOBIOFF H，LEUNG S T.The Google File System［EB／OL］.［2014－02－18］.http：／／static.googleusercontent.com／media／research.google.com／zh－CN／／archive／mapreduce－osdi04.pdf.

［19］ 劉敏，麥耀峰，李冀蕾.Hadoop技術內幕［M］.北京：人民郵電出版社，2013：19－28.

［20］ 徐文強.基于HDFS的云存儲系統(tǒng)研究－分布式架構REPERA設計與實現(xiàn)［D］.上海：上海交通大學，2011：13－17.