大數據庫建設方案

前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇大數據庫建設方案范文，相信會為您的寫作帶來幫助，發現更多的寫作思路和靈感。

大數據庫建設方案范文第1篇

關鍵詞：中間庫；數據轉換；設計

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2016）26-0115-02

隨著大數據時代的來臨，數據與數據之間的聯系被進一步挖掘，并在此基礎上進行綜合分析，形成決策。將不同數據庫中的數據聯合起來，形成相關，具有多種解決方案，設計一個中間庫和一個中間件，專門負責數據的聯系和轉換，是當前主流的解決方案。

1 現狀

伴隨信息化的高速發展，我國絕大多數中小型企業和單位在信息化建設方面已經取得一定的成效，但在大數據背景下，以往建設的信息化系統出現了如下明顯問題：

1）信息化孤島。有些政府和事業單位，根據自身的業務范圍，已經建設了幾十個大小不一的信息管理系統，這些系統中，每個系統都有一個自身獨立的數據庫，系統與系統之間，數據庫與數據庫之間即使具有相同的字段，它們也沒有任何數據關聯。

2）由于數據庫沒有關聯，則存在著明顯的二次錄入現象，比如一個人員名單的增加，需要在人事系統中增加，也需要在業務數據庫中增加，工作量大而繁瑣。

3）數據不一致。由于一條信息可能會在多個業務數據庫中出現，如果這條信息沒有及時流通到相關部門中，則這個部門數據庫的數據不會更新，比如在一個高校的招生中，招生部門錄取了一名學生，但名單還未到達教務處前，教務處的系統沒有更新，導致了數據的不一致性。

4）數據沉睡。由于不同的數據庫之間沒有聯系，故不能挖掘相關數據的相關性，不同數據庫之間的數據不能聯合分析，致使數據沉睡，價值發揮不足。

基于以上的問題，將不同數據庫之間的數據有效聯系起來，成為了數據有效發揮其價值的重要環節。

2 中間件設計

1）模型設計

經過多年的信息化建設，眾多企業和單元已經具備多套信息管理系統，這些系統和系統之間具有如下特征：

① 系統之間相互孤立。在建設初期，每個系統都擁有獨立的數據庫，各數據庫之間沒有聯系，修改其中一個數據庫中的數據，其他數據庫的數據不受影響。

② 系統之間存在聯系。在操作某個業務時，修改一個數據庫中的信息，其他數據庫中的信息可能要改變。如刪除一個名單時，涉及多個系統多次刪除，形成二次錄入。

③ 新形勢下需要將多系統數據聯合分析。在大數據背景下，需要將所有的信息系統統一起來進行綜合分析，以形成精準決策和精準管理。

其具體模型如圖1：

上述問題至少有2種解決方案：

方案1：在設計統一查詢平臺時，將綜合平臺的每一項信息與各業務平臺中的數據聯立。當需要在統一查詢平臺上查詢某些信息時，在其中一個或幾個數據庫聯合查詢即可，如需進行數據轉換，則進行適當轉換。當綜合平臺中某個數據修改時，對應的若干個業務數據庫統一完成修改。

方案2：在設計統一查詢平臺時，設計一個中間庫。中間庫與各基礎庫聯立統一查詢平臺只在中間庫上進行查詢，在統一查詢平臺上進行修改操作直接修改中間數據庫。在中間數據庫和各基礎業務數據庫之間，設計一個數據轉換模型，設計中間庫與基礎庫數據之間的轉換關系和轉換規則。具體見圖2：

比較分析方案1和方案2可以發現，方案2明顯優于方案1。方案1具有兩大明顯不足，一是綜合統一平臺在查詢某個數據時，需要從業務數據庫中調取，這個數據有可能存在多個數據庫中，多個數據庫對這個數據的保存信息可能不一致，綜合查詢平臺基于不同的基礎業務數據庫時，查詢結果不一樣。二是每次在修改數據時，都需要向多個數據庫寫數據，所有的數據庫都必須全部打開等待數據寫入，非常浪費系統資源。

方案2設計了一個中間庫，統一查詢平臺的數據查詢都基于此中間庫，平臺修改的數據也僅僅是修改中間庫的數據，中間庫設計了一個觸發器，當中間庫有變化時，才向各業務數據庫寫入數據，當各基礎業務數據庫發生變化時，向中間庫寫入數據。也可以設計一個算法，定時批量同步數據。

2）數據同步方案

① 數據轉換基本流程

數據同步時，有兩種情況，第一種是統一查詢平臺修改數據后，中間數據庫的數據被修改，按照一定的規程根據被修改的中間數據庫的情況修改業務數據庫，其基本流程對應于圖3。第二種情況是，在各業務平臺上修改了數據，這些數據引起了業務基礎庫的更新，更新的數據庫將引起中間庫的更新，其基本流程圖對應于圖4。

② 數據同步方案

中間數據庫與業務基礎庫中相同變量的對應關系是一對多，在中間數據中修改一個數據，可能涉及多個業務基礎庫的修改，但每個業務數據庫修改的方式又不一樣。如在中間數據庫中增加一個姓名，定義為8個字節，業務基礎數據庫1和業務基礎數據庫2都涉及了姓名列，但在業務數據庫1中，其字段長度為20，而業務基礎庫2中，其字段長度為30，故在轉換時，需要為中間數據庫每一個字段與所有的業務基礎庫的相同字段定義好轉換規則，在轉換時，必須查找對應的規則進行轉換。

大數據庫建設方案范文第2篇

【關鍵詞】 大數據 電信運營商 4V Hadoop Spark 流計算

一、引言

大數據的應用是在互聯網的高速發展中誕生的。谷歌提出了一套以分布式為特征的全新技術體系，即分布式文件系統（GFS，Google File System）、分布式并行計算（MapReduce）和分布式數據庫（BigTable）等技術。這些技術奠定了當前大數據技術的基礎，可以認為是大數據技術的源頭。

二、大數據發展現狀

近年大數據的發展呈現以下兩個特征：1）互聯網公司引領大數據發展。互聯網公司在搜索、廣告領域積極采用大數據技術優化既有業務。二是今年以來陸續推出一系列面向第三方的大數據服務。2）傳統企業大數據應用仍處在探索期，發展漸趨理性。傳統企業在大數據應用的思路上也在糾偏，更加務實。一是更加注重更干凈、結構化小的數據。二是更加注重企業自身沉淀下來的內部數據的價值挖掘。三是更加注重根業務需求把Hadoop 與傳統數據倉庫結合起來用。

三、大數據關鍵技術

1）大數據存儲管理。傳統的單機文件系統和網絡系統要求一個文件系統的數據必須存儲在一臺物理機上，在冗余性、可擴展性和容錯能力和并發能力上難以滿足大數據的需求。2）大數據計算能力。傳統的數據計算能力的提升依賴于擴容單機的CPU性能、增加內存、擴展磁盤等方式，難以支撐平滑擴容。以MapReduce為代表的分布式并行計算技術可以通過低成本的通用服務器搭建系統。通過添加服務器擴展系統的總處理能力。3）大數據分析技術。大數據分析主要在兩個方面，一是對海量的結構化和半結構化數據進行高效率的深度分析，如從文本網頁中進行自然語言分析；二是對非結構化的語音、圖片和視頻進行機器可以識別的分析提取有用的信息。

四、大數據的主流技術

1、Hadoop。Hadoop是基于Java語言開發，以分布式文件系統和Mapreduce為核心。其特點如下：1）可擴展性：Hadoop運行在基于X86結構的普通PC服務器或刀片服務器上，硬件和軟件松耦合在一起，可以很方便的增加計算節點。2）可靠性：Hadoop能夠自動保存數據的多個副本，并且能夠自動將失敗的任務重新分配，確保能夠針對失敗的節點重新分布計算。3）低成本：Hadoop架構在廉價的硬件服務器上，不需要昂貴的硬件作支撐。其軟件是開源產品，不需要授權費用。4）高效性：相比傳統并行計算結構，Hadoop的計算和存儲是一體的，實現任務之間無共享，I/O開銷小。

2、Spark。Spark擁有MapReduce的優點，但不同于MapReduce的Job中間輸出，其結果可以保存在內存中，從而不再需要讀寫HDFS。其有以下特點：1）速度快。Spark支持內存計算，對于小數據集能達到亞秒級的延遲。2）易于使用。Spark支持Sscala、Java和Python編寫程序。Spark提供了超過80個高級運算符，以便于更容易的構建并行應用程序。3）與HDFS底層兼容。Spark能夠運行在Hadoop 2.x的YARN集群管理器上，并且能夠讀取任何存在Hadoop數據。

2、流計算。流式數據是指將數據看作數據流的形式來處理。數據流是在時間分布和數量上無限的一系列動態數據集合體；數據記錄是數據流的最小組成單元。流計算的技術特點如下：1）實時性。流數據是實時產生、實時計算，結果反饋往往也需要保證及時性。2）易失性。在流計算環境中，數據流往往是到達后立即被計算并使用，只有極少數的數據才會被持久化地保存下來，大多數數據往往會被直接丟棄。3）突發性。在流計算中，數據的產生完全由數據源確定，由于不同的數據源在不同時空范圍內的狀態不統一且發生動態變化，導致數據流的速率呈現出了突發性的特征。

五、主流技術方案比較

目前大數據平臺建設最常見的是基于Hadoop平臺和MPP數據庫的兩種方案。Hadoop、MPP數據庫和傳統數據庫并非是互相取代的關系。因此，在很多大數據解決方案中，單一大數據技術無法滿足所有的要求，而是要根據實際場景采用不同的技術方案或采用混搭架構進行綜合處理。

六、電信運營商大數據部署建議

大數據平臺建設目前有兩種方式，建議采用第2種方式：1）以現有分析系統BI為基礎，進行擴展，構建統一開放數據平臺。2）以統一數據管理為契機，通過數據統一采集、存儲與處理入手，新建大數據平臺。方式2可迅速匯聚數據，不影響現網各系統的運行，后期可將經分，性能管理等系統上移為數據集市，專注于專業分析。各數據源僅將數據送往大數據平臺。

大數據技術架構建議按照“松耦合、標準化、分層開放”的標準進行方案選取。而在數據層面，運營商面臨數據規模大，數據處理復雜，數據結構多樣化等多種挑戰。無論是傳統數據庫還是分布式數據庫，均難以單獨滿足數據存儲和分析的需求。大數據平臺建議采用Hadoop作為大數據的主要存儲平臺，各分析集市、應用系統可根據數據分析的深度，實時性采取Hadoop，Spark或MPP混搭架構。

參 考 文 獻

大數據庫建設方案范文第3篇

面對中國大數據市場的蓬勃發展和實際需求，IBM不斷加大對中國市場的投入，以領先的大數據與分析技術促進大數據在零售、銀行、電信、醫療、制造和互聯網等諸多行業落地，這與企業對大數據應用的熱情形成良性互動，加速了最有說服力的、實打實的“案例”的先后涌現。

實踐時代到來

“數據是競爭資源”、“細分市場越小，對數據的需求越大”，這些觀念已經逐漸深入人心，大數據在證明其對企業的重要性和必要性后，走進了“榜樣就是力量”的實戰階段——展望全球，IBM大數據與分析在全球的客戶數已經突破3萬家。

談到中國的大數據市場，IBM全球副總裁兼大中華區軟件集團總經理胡世忠表示：“IBM大數據與分析業已邁進‘中國實踐階段’。中國的人口和經濟規模決定了中國具有全球最大的大數據規模，同時也意味著中國的大數據與分析解決方案比其他國家更具創新性。另外，中國經濟發展面臨的諸多挑戰需要大數據這種創新方式提供更好的解決方案，這一巨大的需求在客觀上為中國提供了廣泛的大數據實踐機會。我們相信，對于大數據，中國面臨前所未有的機遇，有望在這一領域引領全球技術發展趨勢。”

要落地，如何降低大數據分析成本、降低部署難度、提高分析速度是大數據應用無論如何也逃避不了的難點，也是企業最頭疼的關鍵點。IBM從這三點入手，實際效果不辯自明。

青島銀行以PureData for Transactions專家集成系統支持公司數據中心建設，以整合的專家能力賦能大數據，支持公司數據中心建設，建立了高可用、高性能、簡單、易于安裝、簡化運維、能夠為青島銀行新柜面業務和其他重要交易業務提供可靠的數據平臺系統。

安聯全球救援（中國）對原有的數據分析和報告系統進行升級，利用IBM Cognos 10業務分析技術和解決方案來全面支持“安聯全球救援業務分析智能系統”，從而更好地管理和運營自身的數據庫，提高服務和運營水平，將更有價值的業務分析和預測提供給企業級汽車客戶。

安聯全球救援（中國）首席運營官金卡羅（Giancarlo Scupino）表示：“IBM大數據分析將我們的業務分析能力提升到了一個新的高度，使我們不再局限于過去簡單的人工數據統計，而是對數據進行了更高層次的總結和分析。”

技術的力量

支持這諸多應用成功落地的正是IBM在大數據和分析領域的不斷努力和層出不窮的新產品。正如IBM全球副總裁兼IBM中國開發中心總經理王陽所描述的：“如果你想要走進大數據時代，IBM會給你帶來強有力的武器，以產品和解決方案幫助你來實現大數據時代的勝利。”

“IBM創新的大數據技術和解決方案，能夠實現數據的快速挖掘與分析，幫助企業更加高效地獲取大數據價值，從而深化客戶關系，規避風險和詐騙，快速尋找新的業務機遇，提升業務表現。” IBM大中華區系統與科技事業部技術總監李永輝了IBM大數據與分析新產品及實現路線圖。

大數據庫建設方案范文第4篇

關鍵詞： 大數據；電信網絡；精簡架構；數據即服務

Abstract： In this paper， we discuss a number of domestic and international big-data telecommunications architectures and propose our own lean big-data architecture. This new architecture combines the practical application scenarios of operators， and the universal large platform is abandoned. There are two directions in big-data development： improving business efficiency and providing data as a service （DaaS）. Capturing， managing， and mining core data of a telecom operator is the basis for service implementation. Rapid deployment and application of big data is the final target. A balance also needs to be struck between in efficiency， cost and time when deploying a big-data architecture.

Key words： big data； telecommunications network； lean architecture； data as a service

中圖分類號：TN915.03； TP393.03 文獻標志碼：A 文章編號：1009-6868 （2013） 04-0039-003

1 電信運營商建設大數據

思路及關鍵技術

運營商的網絡和用戶是運營商的核心資產，而其中流動的數據（包括用戶配置基礎數據、網絡信令數據、網管/日志數據、用戶位置數據、終端信息）是運營商的核心數據資產。對于運營商來說，最有價值的數據來自基礎電信網絡本身，對于基礎管道數據的挖掘和分析是運營商大數據挖掘的最重要方向。抓取、管理和挖掘這些數據是運營商的當務之急[1-2]。運營商基于核心數據的大數據應用可從兩個方面入手：

（1）通過大數據應用提升自身運營效率。比較典型的應用包括：信令多維分析、網絡綜合管理及分析、業務和運營支撐系統（BOSS）經營綜合分析、精準營銷等。

（2）通過數據即服務（DAAS）拓展新的服務內容，提供對外服務。包括個體及群體的位置信息以及用戶行為分析等，對于第三方公司（比如零售業或者咨詢公司、政府等）都是非常有價值的信息。運營商可以基于這些數據提供對外DAAS服務，拓展市場空間。

為了構建電信運營的大數據應用，從技術能力的角度可以分為數據收集與存儲、信息檢索匯聚、知識發現以及智慧4個層面。電信大數據技術層面如圖1所示。自下而上數據挖掘深度增加，難度加大，對于系統的智能需求提升。其中關鍵的技術包括抽取轉換裝載（ETL）、并行計算框架、分布式數據庫、分布式文件系統和數據挖掘、機器學習等。

面對海量的大數據，如何有效進行數據處理是需要解決的迫切問題，分布式并行處理是有效手段。傳統關系型數據庫多采用共享磁盤（Sharing-disk）架構，當數據量達到一定程度，將面臨處理的“瓶頸”以及擴展的困難，同時成本也偏高。當前有效的做法是采用分布式文件系統/分布式數據庫結合做分布并行處理。目前基于開源的Hadoop平臺是業界采用較廣泛的一個實現方案。Hadoop[3]的核心思想是基于Hadoop分布式文件系統（HDFS）存儲文件或者基于HBase數據庫（也是基于HDFS），使用分布式并行計算框架MapReduce來并行執行分發Map操作以及Reduce歸約操作。在Hadoop的計算模型中，計算節點與存儲節點合一。存儲數據的普通PC服務器可以執行MapReduce的任務。而在Sharing-disk模型中，存儲節點與計算節點是分離的，存儲的數據需要傳送到計算節點做計算。Hadoop計算模型適合離線批處理的場景，比如Log日志分析、文檔統計分析等。它是關系型數據庫管理系統（RDBMS）的有益補充。

在私有技術上實現分布式存儲和并行處理，在調用接口上與Hadoop兼容，這是一個可行的技術方案。這種方案可以避免上述Hadoop的缺點，同時在性能上做更多的優化。有效的手段包括增加數據本地性（Data Locality）特性，在多次迭代的計算過程減少數據在不同節點之間的傳送；使用索引和緩存加快數據的處理速度。結合存儲和計算硬件進行調優也是有效的手段，可以使用數據的分層存儲，將數據分布在內存、固態硬盤（SSD）、硬盤等不同介質上[4]，使得與計算資源達到很好的平衡。

面對海量數據實時性的要求，比較有效的方式是采用復雜事件處理（CEP）[5]。實時流處理采用事件觸發機制，對于輸入的事件在內存中及時處理。同時對于多個事件能合成一個事件[6]。實時流處理需要支持規則以滿足靈活的事件處理要求。實時流處理可以使用分布式內存數據庫、消息總線等機制來實現快速實時響應。目前商用的CEP產品有不少，但是在功能、性能以及適用范圍上有較大差異，選擇成熟度高以及合適的產品是關鍵。

針對大數據中大量的半結構化或者非結構數據，NoSQL數據庫應運而生。NoSQL數據庫放棄關系模型，弱化事務，支持海量存儲、高可擴展性、高可用及高并發需求。NoSQL數據庫在特定應用場景下有很高的優勢，是傳統數據庫的有效補充。按照數據模型，NoSQL主要有四大類：鍵-值（Key-Value）型、列存儲型、文檔型、圖型，它們對應不同的應用場景。比如Key-Value型適合簡單鍵-值對的高效查詢，而圖型適合社交關系的存儲和高效查詢。

針對大數據挖掘分析、搜索以及機器自適應學習等技術在企業系統中逐步應用。相關的算法種類很多，當前需求較多的是分布式挖掘和分布式搜索。

由于數據類型以及數據處理方式的改變，傳統ETL已經不適用。運營商需要根據應用場景做不同的規劃。目前來說，由于運營商應用系統差別較大，尚未有一種統一的處理模式。比較可行的一種方法是依據數據的功用以及特性做分層處理，比如大量的數據源首先做初篩，初篩完之后有部分數據進入數據倉庫或者RDBMS或者其他應用。初篩可以使用Hadoop或者CEP或者定制的方式來完成。

針對運營商的不同應用場景，需要采用不同的技術或者技術組合。比如用戶實時詳單查詢，數據量巨大，但是它的數據類型簡單，數據以讀為主，不需要復雜的Join操作，數據的分布性好。相比傳統的RDBMS，使用Hadoop可以大大提升查詢性能，降低處理成本。更多的應用可能需要多種技術的組合。比如信令采集及多維分析，信令數據特別是分組域（PS）信令數據量大且實時性要求高，有效解決海量數據處理與實時性要求是它的關鍵，需要CEP與Hadoop的組合。在當前階段，不同的技術成熟度不一，由于業界大數據應用進展較快，我們認為當前針對不同應用的精簡方案是最合適的，也就是依據應用場景，挑選最合適的組件做組合，摒棄通用化的大平臺。

2 中興通訊大數據實踐

中興通訊依托在云計算等領域的長期積累，針對大數據形成了一套完整的技術體系架構。ZTE大數據技術體系架構如圖2所示。架構依據運營商的不同的應用需求，注重采用組件搭建的方式，形成端到端的精簡方案。下面以兩個具體的案例進行說明。

（1）用戶實時位置信息服務系統

該系統實時采集蜂窩網絡用戶的動態位置信息，并通過規范接口提供DAAS服務。實際工程中，當期接入的用戶數達兩千多萬，每天用戶位置更新數據可達40多億條，高峰期更新達到每秒幾十萬次。除了采集的位置，還可以結合其他數據源比如用戶年齡等屬性做分析，以應用編程接口（API）開放給上層應用。此外該系統需要有良好的可擴展性，后續可以接入其他區域的數據源。另外這套系統需要有良好的性價比，成本可控，時間可控。依據這些需求，我們在成熟的組件K-V NoSQL 數據庫的基礎上搭建了系統。用戶實時位置信息服務系統如圖3所示。

用戶實時位置信息服務系統是一個典型的精簡方案，它基于分布式Key-Value NoSQL數據庫的分布式緩存（DCache），組裝了對位置流事件實時處理的系統。DCache既是消息總線，也是內存數據庫，能很好地滿足實時性的要求。同時DCache基于x86刀片服務器，采用分布式架構，系統的擴展性很好，成本較低。該系統性能優越，穩定可靠，取得良好的效果。

（2）信令監測多維分析系統

隨著運營商數據業務快速增長，運營商對于網絡質量提升、網絡運營效率有著更大的壓力。通過采集網絡Gn接口、Mc接口信令并加以處理分析，可以獲得網絡運行的完整視圖，基于信令的相關專題分析，比如網絡質量分析、流量效率分析、多網協同分析、客戶投訴及服務分析等對于運營商網絡運營有極大的價值。

信令監測多維分析的難點在于信令流量大且數據量大，比如某運營商省公司Gn接口峰值流量可以達到4 Gb/s，每天信令數據可達1 TB。需要采集信令并做多種分析以服務于不同的部門。

信令監測多維分析系統采用分層的架構，便于數據共享及和應用的擴展。信令監測多維分析系統如圖4所示。使用實時流處理滿足實時性高的數據分析要求，對于會話或事務詳單（XDR）初步處理完的數據采用傳統RDBMS存儲供后續分析查詢使用。對于數據量龐大的XDR采用Hadoop HBase存儲并查詢，原始信令采用分布式文件系統存放在本地。

在這個方案中，數據根據它的使用特性采用不同的方式存儲和處理，突破RDBMS處理“瓶頸”和擴展性的“瓶頸”，達到了很好的效果。在測試中，4節點PC服務器可以全部承擔某運營商省公司PS域XDR的存儲，入庫性能可達50 Mb/s，針對上百億條記錄查詢，可以在10 s內返回。取得了很好的實踐效果。

3 結束語

電信運營商面臨大數據發展的機遇，都在積極推動大數據的試點和商用。在當前大數據技術快速發展的形勢下，根據需求和應用場景搭建精簡方案，可以幫助運營商在當前激烈競爭環境中快速獲得競爭優勢，在效率、成本和時間上取得最佳平衡。

參考文獻

[1] Cisco Systems. Cisco visual networking index global mobile data traffic forecast update， 2011 - 2016 [EB/OL]. [2013-03-25]. http：//.

[2] MANYIKA J， CHUI M， BROWN B， et al. Big data： The next frontier for innovation， competition， and productivity [R]. McKinsey Global Institute， 2011.

[3] WHITE T. Hadoop權威指南 [M]. 2版. 周敏奇， 王曉玲， 金澈清， 譯. 北京：清華大學出版社， 2011.

[4] SNIA. 2012 SNIA Sprint Tutorials-NextGen Infrastructure for Big Data [EB/OL]. [2013-02-15]. http：//

[5] NEUMEYER L， ROBBINS B， NAIR A， et al. S4： Distributed stream computing platform [C]//Proceedings of the IEEE International Conference on Data Mining Workshops （ICDMW’10）， Dec 14-17，2010， Sydney， Australia .Los Alamitos， CA， USA： IEEE Computer Society， 2010：170-177.

[6] SHARON G， ETZION O. Event-processing network model and implementation [J]. IBM Systems Journal， 2008，47（2）：321-334.

作者簡介

大數據庫建設方案范文第5篇

[關鍵詞]地質大數據；數據中心；建設

中圖分類號：P621 文獻標識碼：A 文章編號：1009-914X（2017）17-0098-02

地質礦產勘查部門經營幾十年沉淀下海量的各類地學數據，由于缺乏有效的管理和綜合開發利用，大部分依然埋存在數據墳墓中，以至無法創造附加價值。如何盤活這些數據資源，將沉淀的數據資源價值最大化，是一個面臨的重大考驗。引入云計算、大數據等新一代信息技術，建設地質大數據中心，從而實現地質數據智慧化服務和管理的新模式，為地質數據資源綜合開發利用提供基礎保障。

1 地質大數據中心發展趨勢

隨著地質調查信息化水平的提高，地質大數據時代到來的步伐不斷加快，在大數據時代背景下，地質資料的管理、開發利用以及社會服務也將發生變化，與傳統的資料存儲相比，大數據時代下的地質資料數據具有載體形式多、數據格式多、信息量龐大的特點，給數據資料管理存儲與應用服務帶來了新的挑戰，如何有效保存、快速發現和獲取成為重要課題，建立具有高性能、容災備份能力的數據中心成為了當今地質大數據時代信息化和數字化的必然要求[1]。

2 地質數據化管理現狀

地質數據化管理化建設已經開展多年，但目前依然局限于解決某個部門某個項目的訴求上，處于比較落后階段。沒有統一的信息化管理平臺，沒有集中管理的數據存儲中心。各類地學數據無法統一存儲管理、數據安全管理缺失、信息安全管控能力薄弱、系統容災性極差的尷尬局面。據公開數據顯示，當前已經建設完成涵蓋基礎地質數據、地質礦產數據、物化遙數據、水工環數據等多專業的地學數據庫。但這些數據庫的建設方式大多數是簡單地利GIS系統和數據庫系統來裝載數據，很少做數據層面的資源整合和以需求為主導的二次開發。不同專業屬性的數據不能互相構建互通，造成信息資源分散，共享和統一的程度不高。

3 地質大數據中心建設現實需求分析

以存儲、管理、開發利用地質數據為主題的大數據中心，是地質行業信息化建設的大放向，以數據為核心，連接各類地質業務平臺，可以促進地質數據共享，有效地提高數據資源的利用率，這將成為地質數據資源轉換為地質數據資產必備條件。

解決海量地學數據的存儲和各類應用系統的整合部署，是目前地質大數據中心建設的迫切需求。海量數據的存儲需求主要以各類項目和應用系統的需求為主導，項目包括已經完成、正在實施、計劃開展的項目。以對基礎地質、礦產地質、農業地質、礦山環境、地質災害、旅游地質等的專業數據評估，都以矢量數據、柵格數據、文本數據、表格等為主，所產生的數據都屬于PB級的數據量。為有效對這些海量數據進行采集、存儲、管理和深度挖掘，以充分利用數據資源，地質大數據中心建設成為了未來發展的必然趨勢。

4 地質大數據中心建設目標和原則

以地質數據生產、存儲、管理、開發、利用為主線，采取統一、分步、集中、共享的建設方針，逐步構建地質大數據中心為目標。

統一：對數據中心化建設進行統一標準、統一規劃、統一籌備、統一部署、統一管理。避免各個業務部門、地勘單位各自為營的建設。

分步：設備會貶值，技術會過時，數據中心建設是一個長期工程，不可能一步建設到位，必須根據規劃，依據實際需求進行分步建設，逐步向目標推進。

集中：數據中心的硬件資源、軟件資源、網絡資源進行集中采購、集中部署、集中管理。避免重屯度胄緯傻淖試蠢朔眩便于軟硬件資源的維護，同時強化信息安全的管理。

共享：地勘單位共享硬件資源、軟件資源、網絡資源，各類資源由管理部門統一調度，各個地勘單位原則上不再投入建設相關的設施。

數據中心的建設必須理清現狀，明確需求，以資源整合、充分利舊、合理升級為建設原則。

資源整合：對硬件資源、軟件資源、網絡資源進行分析、評估、整合，各類資源能用就用，統籌部署、合理共享，提高資源利用率。

充分利舊：充分利用現有基礎設施資源，可以改建為同城災備中心和數據機房。

合理升級：運營多年的業務系統，設施可能已經落后，并且多年沉淀下來的數據，已屬于海量數據。原則上在利舊的前提下，新數據中心機房的建設，在不影響現有數據存儲、業務系統運營的情況下，合理升級數據的存儲方案和業務系統的運營策略等。

5 地質大數據中心總體方案描述

數據中心建設的指導思想是：堅持整體規劃、分布實施、統一標準、整體協調、整合發展、資源共享的原則，以網絡為基礎、應用為重點、信息資源開發利用為核心，建立一個高可靠、大容量、安全的數據中心。依據建設目標，以業務應用為驅動，切合實際數據存儲規模需求作為建設切入點打造全新的地質模塊化數據中心。數據中心的建設涉及到硬件資源的整合、軟件資源的整合、網絡資源的整合、業務應用系統功能整合、各類數據庫的整合，每個環節都需從管理、應用、服務等諸多方面多角度全方位的考慮，并擬出技術方案方可實施。

1）地質大數據中心應用架構

對各類地質數據進行全面梳理、分析，整合現有的數據資源，構建完整、規范、統一的數據存儲中心，集中存儲，打破部門邊界，實現資源的有效共享，為今后業務系統建設奠定基礎（圖1）。

2）地質大數據中心網絡架構

數據中心的網絡構架必須統籌局域網內部署，同時協調已有的各業務系統之間的運營需求，使這些已有的系統運行、真正投入使用，實現這些業務系統與下屬地勘單位互聯互通，進行項目實時動態管理。而這些系統運轉的前提是數據中心機房的建設，需要大力的設備、人力、物力、財力的支撐，時間持續也很長久（圖2）。

3）確立數據中心平臺

構建一套基于軟件定義的云存儲平臺，在標準硬件上構建一套系統滿足文件存儲及對象存儲資源的訴求，并能實現存儲資源的按需自動化發放。不同類型存儲分別為不同業務按需提供存儲資源。

文件存儲服務：提供NFS、CIFS、FTP和HDFS等標準接口，以卓越性能、大規模橫向擴展能力和超大單一文件系統為用戶提供非結構化數據共享存儲資源，應用于視頻/音頻海量存儲、大數據應用等場景。

對象存儲服務：兼容Amazon S3與OpenStack Swift，支持融入主流云計算生態，滿足云備份、云歸檔、IoT及云存儲服務運營場景需求。

通過存儲系統軟件將標準硬件的本地存儲資源組織起來，構建全分布式存儲池，實現一套存儲系統向上層應用提供塊、文件和對象三種存儲資源服務，滿足結構化、非結構化和半結構化等多類型數據存取對IOPS、帶寬及海量擴展需求；提供快照、精簡配置、遠程復制、多租戶等豐富的企I級數據服務特性，幫助企業輕松應對業務快速變化時的數據靈活、可靠存取需求。同時，提供基于標準接口協議的開放API，天然融入OpenStack云基礎架構及Hadoop大數據生態[2]。

4）容量規劃

根據實際數據存儲的容量需求，總體配置1540TB裸容量，滿足1PB可用容量需求，分布式存儲系統最大可達到4096節點，200PB容量，本期配備11個節點，兼容未來5年內數據增長對存儲容量的冗余需求。

5）存儲網絡拓撲

存儲的組網架構包括管理網絡、前端業務網絡和后端存儲網絡。管理網絡用于云存儲系統與用戶維護網絡對接，為系統管理員提供管理UI，完成系統配置、租戶管理、資源管理、服務發放等業務操作，以及告警/性能/拓撲等維護操作。同時可以匯聚所有物理節點的Mgmt接口，提供遠程設備維護能力，如遠程登錄設備虛擬KVM、查看溫度、電壓等硬件運行數據等。前端業務網絡用于云存儲系統與用戶網絡對接，為租戶用戶提供租戶UI，完成資源申請、使用情況查詢等操作，并處理租戶客戶端或API發送的業務請求。

后端存儲網絡用于云存儲節點間內部互聯，提供HA（High Availability）組件如DSS（Data Service SubSystem）的心跳通信，以及各組件之間的內部通信和數據交互（圖3）。

6）地質大數據中心建設階段規劃

數據中心建設是一個中長期建設的過程，可按數據存儲中心、數據處理中心、數據應用中心、數據運營服務中心五個階段逐步實施（圖4）。

6 地質大數據中心建設模式

地質大數據中心工程可以考慮參其它單位的模塊化數據機房建設模式：系統運營商投資建設，應用單位購買服務。

由于項目建設初期資金投入大、運營周期長、維護難度大，為了降低項目建設初期資金籌措風險以及后期運行維護壓力，可借鑒目前硬件商推薦的“系統運營商投資建設，政府購買服務”。

該方案的優點在于：在系統運營服務期內，政府只需要按年向中標的系統運營商支付系統建設運營服務費即可，大大降低財政資金壓力；同時，不需要再成立專門的平臺維護機構，專注于業務處理，提高行政效率。

7 結束語

在國家大數據互聯網建設的背景，針對目前地質數據存儲、管理存在的問題和安全隱患提出，為了保障數據安全，建立地質大數據中心，挖掘深層數據信息，提高辦公效率，解決存在的隱患問題。通過對數據中心構建的可行性分析認為是可行的，地質大數據中心的構建推動地質大數據挖掘、綜合利用，促進地質數據資源服務全行業的積極作用。

參考文獻：