海量連續運行參考站網數據云存儲模型

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

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

1 引言

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

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

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

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

2 CORS數據量分析

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

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

圖1 SOPAC的數據量統計

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

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

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

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

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

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

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

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

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

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

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

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

3.2 CORS數據云存儲集群架構

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3 CORS數據云存儲組織架構

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

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

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

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

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

3.4 CORS數據云存儲訪問架構

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

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

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

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

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

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

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

4 實驗分析

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

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

4.1 集群可靠安全性

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

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

4.2 集群抗災容錯性

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

圖6 DataNode2節點關閉前文件存儲位置

圖7 DataNode2節點關閉后文件存儲位置

4.3 集群擴展性

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

圖8 集群擴容示意圖

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

4.4 下載速率

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

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

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

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

5 結束語

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

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

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

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

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

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

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

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

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

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

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

［11］ 劉琨，李愛菊，董龍江.基于 Hadoop的云存儲的研究及實現［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］ 唐箭.云存儲系統的分析與應用研究［J］.電腦知識與技術，2009，5（20）：13－14.

［16］ 祁芳，林鴻.Ntrip協議在 CORS系統中的應用［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的云存儲系統研究－分布式架構REPERA設計與實現［D］.上海：上海交通大學，2011：13－17.