海量數據范文
時間：2023-03-15 00:18:36
導語：如何才能寫好一篇海量數據，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。
篇1
關鍵詞：數據；處理；存儲
中圖分類號：TP311.52 文獻標識碼：A 文章編號：1007-9599 （2012） 16-0000-02
1 引言
在企業競爭日益激烈的今天，第一時間了解公司線上業務運行情況并及時進行調整直接決定了項目能否第一時間占據市場高地。對業務數據的處理涉及到收集，存儲，加工三個關鍵步驟，而根據不同的業務類型，對數據的一致性，準確性，實時性都有不同的要求。能否制定出適合業務類型的數據處理解決方案將決定數據處理系統的成敗，從而影響了項目的命運。本文將從介紹數據收集開始，結合不同的業務類型提出相應的解決方案，并權衡各種方案的利弊。
2 數據收集
本文的討論重點是關系型數據庫解決方案及NoSQL解決方案的比較，但在此之前對數據收集進行簡要介紹對于理解后續的模型是有必要的。由于企業的業務往往分散在各地的服務器上，要對業務數據進行收集可采取兩種方案，服務端主動發送，服務端記錄日志并由數據收集系統的客戶端進行收集并發送。為減少業務之間的耦合，我們將采取第二種方案，即業務相關服務記錄特定格式日志，并由客戶端進行收集，在業務相關服務中僅需添加根據特定格式寫日志接口。
3 數據存儲
對于海量數據的處理，數據存儲在后續應用及維護中占據了核心地位。設計良好的存儲模型與設計不合理的模型在對資源的消耗上有著天壤之別，而一個針對具體問題設計合理的方案能夠在工作中事半功倍。
3.1 關系型數據庫模型
當業務規模相對較小并且業務種類單一時（比如一些剛起步的游戲公司）其主要需關注的數據是一些游戲的在線、登入、登出、付費人數等數據，在下文中將稱其為關鍵運營數據。這些數據表現了一個項目的生命特征（當這些特征表現很低靡時，如果不是服務器出問題了，公司管理者就應該為項目的前途擔心了）。對于這些數據要求有極高的一致性、準確性以及實時性。當然最好能記錄明細（明細往往由相關的提供業務支持的系統進行維護）。對于這種類型的數據，需要為每個業務邏輯制定一個標識，當收集到該數據時，（數據處理）服務端根據該標識對數據進行區分，從而存儲于數據庫中。對這類數據須保證實時性，但不需要保持時序關系。
3.2 NOSQL思想
“NoSQL這一術語常用于描述網頁開發者對非關系型數據庫與日俱增的使用”。[3]
隨著公司業務種類的多樣化，以及業務的深入，越來越多的項目浮出水面，尤其是對于無線項目，由于這類項目往往由用戶下載客戶端后客戶端直接提供服務，限制于發行商對產品的限制，不便因數據收集的需求對產品進行頻繁修改。而業務的深入也必定帶來更多更細致的數據需求。在這樣的背景下，類似于關鍵運營數據那樣為每個業務邏輯制定標識的方法維護性將變得很低（試想對某個游戲的所有道具、所有任務、所有NPC或是一個行為產生的結果進行數據收集，將需要為所有的這些對象制定標識，系統的開發者以及維護者將不堪重負）。此時地數據將成幾何級數倍的速度增長，正如[1]中所說，“對于這些數據的讀寫操作大多基于主鍵，而并不需要基于RDBMS的復雜功能，而為了維護這些過量的功能企業不得不投入大量的硬件和人力資源，使基于RDBMS的解決方案變得很低效。”，“盡管在RDBMS上近幾年取得了許多進步，但要擴展一個數據庫仍然不是一件輕松的工作。”所以除了本來就應考慮的一致性準確性等問題外，存儲模型的延伸性也應該進行考量。
如[2]中提到的Brewer的CAP理論中陳述的，“在任何一個系統（常為分布式系統）中，一致性，可用性，以及分區容忍性只能三選其二”，對于CAP三者的解釋如下，Consistency（一致性）：對所有數據庫的查詢操作都將獲取同樣的結果，即使在并發更新的情況下。Availability（可用性）：所有的數據庫客戶端總能存取數據。Partition Tolerance（分區容忍性）：數據庫能被分割開到多臺機器上，即使發生網絡中斷也能繼續提供服務。在現有的需求下，較好的實現能夠根據配置在這三者間進行調解，如Cassandra[2]。
本文討論的存儲模型的存儲策略借鑒了Dynamo，而數據結構類似于Google的Big-table，目前開源社區對該類存儲模型較好的實現可以參考Cassandra。同時這類系統一般用于公司內部運營支持，暫不考慮安全性相關問題。
3.3 NOSQL模型
在新項目上線之前，可以根據策劃案對可能需要設計的數據需求進行統籌，并制定需求，在與數據處理系統開發人員，產品開發人員溝通后，最終修改需求并不再進行更改。在產品開發之前，為這些需求制定標識字串，這些字串往往是自說明的。在一切都準備好之后，在產品的業務代碼中加入相應的數據收集代碼。
當用戶在產品中產生一個動作時，與該行為相對應的結果將通過數據收集代碼寫到磁盤中，數據收集客戶端將分析磁盤上的文件，將對應的字串發送至服務端。服務端可以通過在框架上使用共享庫的方式，加在不同模塊以針對不同的數據類型。比如可以專門有一個共享庫用來處理放入NoSQL存儲的數據。根據Big-table中提出的數據模型思想，可以通過主鍵定位到具體的數據，故存放之前需要對整個字串進行拆解，根據事先制定的數據模型來組成不同的數據包并寫入存儲。
由于到達數據處理服務端的字串是自說明的，其中包含了用來定位一個數據所有必要的信息，所以若在最初制定的數據需求是全面的，游戲中所有用戶相關行為產生的數值信息都可以使用相同的格式寫至磁盤，很大程度上節省了產品開發人員以及，數據處理系統開發及維護人員以及在雙方溝通中消耗的溝通成本。
基于Dynamo思想的分布式存儲采用了P2P結構，使用該節點的好處在于所有的節點都是對等的，即使其中一個出現問題，如斷電、網絡中斷等，只要采用合理的備份策略，整個集群是可用的。另外采用這樣的方法便于維護人員向集群中添加或減少機器，因為所有節點是對等的。
由此可見，妥善使用NoSQL并設計良好的話，可以極大地降低開發及維護人員的人力成本。
4 總結
無論是關系型數據庫還是NoSQL都不可能成為最終的解決方案，正如多年前被的認為關系型數據庫可以成為終極的解決方案的思想一樣，NoSQL也不可能坐上這一寶座。
所幸的是，現在的工程師們在經歷了關系型數據庫時代后對這一點已經有了深刻的認識，并以此為動力開發出了多樣化的NoSQL產品，每一款都解決了某些特定的問題。對于即將使用NoSQL思想設計自己系統的工程師，應當仔細分析自己的需求，使用最適合自己的NoSQL產品，或者對現有的NoSQL產品進行定制（很多產品如Cassandra都提供了可自定義的接口）。甚至可以根據需求設計并開發自己的數據庫系統。
在思考解決方案時，也務必需要考慮是否在該項目中是否真的有必要使用NoSQL產品，因為往往對一家相對成熟的公司（有自己的數據庫管理員）在使用關系型數據庫進行開發時的效率是最高風險最低的。
參考文獻：
[1]Dynamo：Amazon’s Highly Available Key-value Store
[2]Oreilly Cassandra The Definitive Guide
篇2
關鍵詞:RFID;海量數據;數據挖掘
中圖分類號:TP311文獻標識碼:A 文章編號:1009-3044(2010)19-5359-02
Research on Mass Data Mining for RFID
LIN Zhong-da YAN Xin-zhe
(College of Information Engineering, Nanchang University, Nanchang 330031, China)
Abstract: The technology of RFID has been applied in many kind of domain since 1990s.In recent years,the application scope of RFID has expanded rapidly because of its convenient and long service life,the statement of "Internet of Things" made the development of RFID more fast,RFID has become one of the most important technology in the 20th century.Facing the mass data produced by RFID,the traditional way of data mining cannot satisfy the need of information acquisition.This article introduces the RFID system simply,and makes some discussion to the mass data mining for RFID by analyzes the characteristic of RFID data.
Key words: RFID; mass data; data mining
RFID(Radio Frequency Identification),即無線射頻識別技術,是一種新型的非接觸式自動識別技術。RFID于20世紀90年代開始興起,與其它自動識別技術相比,RFID具有信息量大、抗干擾能力強、保密性高、使用壽命長等優點,因此,近年來廣泛應用于多種商業領域,尤其是物流和供應鏈管理。
數據挖掘是一門從大量數據中提取有用信息的學科,在各種商業領域中有著廣泛應用。數據挖掘通過聚類、關聯分析等多種方式從大型數據倉庫中查找并提取決策者感興趣的信息,以便決策者對未來商業活動進行預測與計劃。自20世紀80年代以來,數據挖掘技術得到了迅猛的發展,出現了許多成熟的挖掘算法和數據挖掘工具。
RFID技術的發展,向傳統的數據挖掘提出了挑戰。RFID數據有著與傳統數據不同的特點,因此,必須針對RFID數據設計新的數據挖掘系統,以滿足RFID海量數據的挖掘要求。
1 RFID數據分析
1.1 RFID系統簡介
RFID是一種新興的自動識別技術,它利用射頻信號傳遞信息,達到無接觸識別的目的。一個完整的RFID系統由標簽、閱讀器和應用軟件三部分組成:
標簽(Tag):標簽是一個小型芯片,它帶有全球唯一的標識碼,附著在目標物體上,用來標識物體。按照有無電源,標簽可以分為有源標簽和無源標簽。有源標簽可以主動向閱讀器發送信息,但需要電源支持,并且價格更高。無源標簽只能被動等待閱讀器讀取信息,但結構簡單,無須電源支持,價格便宜。按照是否可寫,標簽可以分為只讀標簽和可讀寫標簽。只讀標簽內的信息在出廠時固化,之后不能更改。可讀寫標簽則可以在其中自由讀取和寫入信息,更加方便靈活。
閱讀器(Reader):閱讀器是一個可以發送和接收某個特定頻率信號的設備,它可以向標簽發送射頻信號,并接收返回的信號,讀取其中的信息,解碼后將數據傳送給應用軟件處理。如果標簽是可讀寫的,閱讀器還可以發送信號改變標簽內的數據。閱讀器抗干擾能力強,并且具有防沖撞功能,即使有數個標簽同時出現在閱讀器工作范圍內,也可以分別識別出每個標簽的信息而不會混淆。
應用軟件:應用軟件負責處理閱讀器返回的數據,如果標簽是可讀寫的,應用軟件還負責向閱讀器傳送需要改寫的標簽數據。
RFID系統的數據采集過程如下:閱讀器向周圍發送某一頻率的射頻信號,處于閱讀器工作范圍內且擁有相同頻率的標簽接收信號后,將標簽芯片中儲存的信息發送出去,閱讀器接收信號并讀取其中的信息,解碼后將信息傳遞給應用軟件處理。
1.2 RFID數據特點
作為一種新型的數據采集技術,RFID在實際應用中采集到的數據有著自身的特點。概括起來,有以下幾種:
海量:在商業領域中,貨物流動非常頻繁,每樣貨物附著的標簽都將自己的信息傳遞給流通路徑上遇到的所有閱讀器,這樣產生的數據量是非常驚人的。如果采用傳統數據挖掘方法直接挖掘,將很難取得良好的效果。
冗余:閱讀器不間斷的向周圍發送射頻信號,而不同閱讀器的工作范圍可能發生重疊,因此,RFID數據會出現兩種冗余情況,時間冗余和空間冗余。時間冗余是指標簽長期處于某一閱讀器工作范圍內時,會多次向閱讀器發送自己的信息。空間冗余是指標簽處于多個閱讀器工作范圍內時,會向每一個閱讀器都發送自己的信息。由于閱讀器的閱讀周期相對于標簽的停留時間非常短,而一個大型貨物中轉站安放的閱讀器數量又很多,工作范圍重疊不可避免,因此數據冗余造成的影響是巨大的。
連續:閱讀器的閱讀周期固定,并且相對于標簽的停留時間非常短,因此,RFID數據將按照時間序列保持連續性。這種連續性在數據挖掘中可能有一定的利用價值。
分散:在現實世界中,貨物的流通范圍非常廣,中國生產的皮鞋可以銷往歐洲,南非出產的鉆石可以賣到北美,因此,RFID數據在地理上是非常分散的。如何高效的從這些分散的數據中挖掘有用的信息,是RFID數據挖掘需要面對的一個問題。
RFID數據的以上特點,使得我們必須尋找合適的數據挖掘方式,以便更好的管理和利用RFID數據,滿足RFID數據挖掘的需求。
2 RFID數據處理
RFID采集的原始數據是一個三元組(EPC,Location,Time),其中EPC是標簽的標識碼,Location是閱讀器讀取標簽的地點,Time是閱讀器讀取標簽的時間。企業需要從RFID數據中了解的信息是產品流通的路徑和時間,由于原始數據的規模過于龐大,因此,在將原始數據存入數據倉庫之前,應當先對原始數據進行處理,以便提高挖掘效率。對RFID數據來說,處理的步驟主要是數據清理和數據歸約。
篇3
一、海量數據挖掘關鍵技術隨時代而變化
所謂海量數據挖掘，是指應用一定的算法，從海量的數據中發現有用的信息和知識。海量數據挖掘關鍵技術主要包括海量數據存儲、云計算、并行數據挖掘技術、面向數據挖掘的隱私保護技術和數據挖掘集成技術。
1.海量數據存儲
海量存儲系統的關鍵技術包括并行存儲體系架構、高性能對象存儲技術、并行I/O訪問技術、海量存儲系統高可用技術、嵌入式64位存儲操作系統、數據保護與安全體系、綠色存儲等。
海量數據存儲系統為云計算、物聯網等新一代高新技術產業提供核心的存儲基礎設施；為我國的一系列重大工程如平安工程等起到了核心支撐和保障作用；海量存儲系統已經使用到石油、氣象、金融、電信等國家重要行業與部門。發展具有自主知識產權、達到國際先進水平的海量數據存儲系統不僅能夠填補國內在高端數據存儲系統領域的空白，而且可以滿足國內許多重大行業快速增長的海量數據存儲需要，并創造巨大的經濟效益。
2.云計算
目前云計算的相關應用主要有云物聯、云安全、云存儲。云存儲是在云計算(cloud computing)概念上延伸和發展出來的新概念，是指通過集群應用、網格技術或分布式文件系統等功能，將網絡中大量各種不同類型的存儲設備通過應用軟件集合起來協同工作，共同對外提供數據存儲和業務訪問功能的一個系統。
當云計算系統運算和處理的核心是大量數據的存儲和管理時，云計算系統中就需要配置大量的存儲設備，那么云計算系統就轉變成為一個云存儲系統，所以云存儲是一個以數據存儲和管理為核心的云計算系統。
3.并行數據挖掘技術
高效率的數據挖掘是人們所期望的，但當數據挖掘的對象是一個龐大的數據集或是許多廣泛分布的數據源時，效率就成為數據挖掘的瓶頸。隨著并行處理技術的快速發展，用并行處理的方法來提高數據挖掘效率的需求越來越大。
并行數據挖掘涉及到了一系列體系結構和算法方面的技術，如硬件平臺的選擇(共享內存的或者分布式的)、并行的策略(任務并行、數據并行或者任務并行與數據并行結合)、負載平衡的策略(靜態負載平衡或者動態負載平衡)、數據劃分的方式(橫向的或者縱向的)等。處理并行數據挖掘的策略主要涉及三種算法：并行關聯規則挖掘算法、并行聚類算法和并行分類算法。
4.面向數據挖掘的隱私保護技術
數據挖掘在產生財富的同時也隨之出現了隱私泄露的問題。如何在防止隱私泄露的前提下進行數據挖掘，是信息化時代各行業現實迫切的需求。
基于隱私保護的數據挖掘是指采用數據擾亂、數據重構、密碼學等技術手段，能夠在保證足夠精度和準確度的前提下，使數據挖掘者在不觸及實際隱私數據的同時，仍能進行有效的挖掘工作。
受數據挖掘技術多樣性的影響，隱私保護的數據挖掘方法呈現多樣性。基于隱私保護的數據挖掘技術可從4個層面進行分類：從數據的分布情況，可以分為原始數據集中式和分布式兩大類隱私保護技術；從原始數據的隱藏情況，可以分為對原始數據進行擾動、替換和匿名隱藏等隱私保護技術；從數據挖掘技術層面，可以分為針對分類挖掘、聚類挖掘、關聯規則挖掘等隱私保護技術；從隱藏內容層面，可以分為原始數據隱藏、模式隱藏。
5.數據挖掘集成技術
數據挖掘體系框架由三部分組成：數據準備體系、建模與挖掘體系、結果解釋與評價體系。其中最為核心的部分是建模與挖掘體系，它主要是根據挖掘主題和目標，通過挖掘算法和相關技術(如統計學、人工智能、數據庫、相關軟件技術等)，對數據進行分析，挖掘出數據之間內在的聯系和潛在的規律。大體上，數據挖掘應用集成可分為幾類：數據挖掘算法的集成、數據挖掘與數據庫的集成、數據挖掘與數據倉庫的集成、數據挖掘與相關軟件技術的集成、數據挖掘與人工智能技術的集成等。
二、海量數據挖掘應用廣泛但深度不足
2011年中國數據挖掘軟件市場規模達接近2億元，2012-2014年還將快速增長。從數據挖掘應用行業上看，國內大多數的用戶都來自電信、銀行、保險、稅務、政府等領域。應用主題主要包含：消費者行為分析、信用評分與風險管理、欺詐行為偵測、購物籃分析等方面。目前，國內數據挖掘應用仍停留在初級階段，行業企業大規模的運用數據挖掘技術尚需時日。
1.國內數據挖掘應用可分為3個層次
從數據挖掘應用層次上看，大體可以分為三個層次：第一層次是把挖掘工具當作單獨的工具來用，不用專門建設系統；第二層次則是把數據挖掘模塊嵌入到系統中，成為部門級應用；第三層次是企業級應用，相當于把挖掘系統作為整個企業運營的中央處理器。目前，國內的數據挖掘應用的企業基本處于第一層次，偶爾某些企業用戶能夠做到第二層次。
2.國內有代表性的數據挖掘行業應用情況簡評
(1)通信業：國內應用數據挖掘的企業還是以通信企業(移動、聯通、電信)為首，應用的深度和廣度都處于領先地位。
(2)互聯網企業：隨著電子商務的普及，各大商務網站已經大規模使用數據挖掘技術，并且迅速從中取得商業價值。例如，國內很多網上商城已經開始使用數據挖掘技術進行客戶聚類或者商品關聯推廣。另外，搜索引擎企業使用數據挖掘技術的需求也非常迫切。
(3)政府部門：我國政府部門中使用數據挖掘技術比較領先的是稅務系統。數據挖掘在電子政務中的應用，更多的涉及到報表填制、數據統計。
(4)國內金融行業：操作型數據挖掘應用在國內金融行業應用廣泛，尤其是信貸評審領域。中小型銀行數據挖掘需求將是未來金融行業數據挖掘市場的主要增長點。未來5年時間里，數據挖掘應用在金融行業仍將高速發展。
篇4
[關鍵詞]智能MCC 海上油田 海量數據 分級分層管理
中圖分類號：T456 文獻標識碼：A 文章編號：1009-914X（2015）10-0380-01
引言
海上MCC為石油天然氣的開采及平臺人員的生活提供生產、配電、管理保障，它的回路類型各異，回路個數及二次設備眾多，節點狀態及電氣、統計參數通過硬接線或現場總線的方式進行數據傳輸。
智能MCC系統[1]對海上MCC所有回路節點及二次設備進行電氣數據采集、統計數據分析、文件數據及維護信息更新，實現海上MCC的實時監控、故障預警、快速定位、設備信息及全生命周期管理。該系統采集和存儲的相關數據量很大（對于單個海洋石油中心平臺來說，總的信息采集點數高達10000個左右），而實際的智能馬達保護器、多功能表等二次設備本身的通訊接口一般為現場總線，如DEVICENET[2]，PROFIBUS，MODBUS等[3]，都基于工業現場總線技術，有一定的帶寬限制和節點數要求。同時，智能MCC系統需要進行存儲、統計分析和趨勢跟蹤。如此大量的數據如全部進行統一處理，容易造成信息通道阻塞。
并且由于智能MCC系統不僅運行在海上油田的局域網中，更運行在陸地公網上，而海上油田網絡與陸地公網是通過微波傳輸，受寬帶限制，網絡實時容量低，這對于智能MCC系統的海量數據管理，也提出了苛刻要求。
本文介紹一種數據分級分層的管理機制，保證智能MCC系統對于基礎海量數據的穩定采集、傳輸、分析、調用，避免系統信息通道的阻塞，實現了海上智能MCC系統的穩定、可靠運行。
正文
一 海上智能MCC系統海量基礎數據
為滿足海上油氣生產設施正常生產和運維需求，智能MCC系統應能通過上位機或者維護終端遠程調節各從站設定值、特性曲線參數等。通過智能MCC系統完成的數據傳遞應包括回路電氣實時參數，如電流電壓功率等；相關設備的報警與預警信息，如過電流報警等；通過智能馬達保護器完成的設備診斷信息，如缺相和堵轉等；用于實時控制的模擬量數字化傳輸，如調速設備速度（頻率）給定；以及用于控制和保護的非實時參數整定值下發，如對回路框架斷路器、智能馬達保護繼電器報警值設定、死區值設定[4]等。具體如下：
（1） 通過上位機遠程測量各回路、各設備的電量參數如下：
主進線電路：三相電流、三相電壓（相電壓/線電壓）、有功功率、無功功率、有功電度、功率因數；
配電電路：三相電流、三相電壓（相電壓/線電壓）
動力照明：三相電流
電動機回路：三相/一相電流、三相電壓（相電壓/線電壓）、功率因數、有功功率；
補償回路；三相電壓（相電壓/線電壓）、功率因數（實際值/設定值）；
其他：電網頻率、變壓器檔位，剩余電流。
（2）通過上位機或生產DCS（PCS）對各從站實現以下控制功能：
動力中心電路：控制開關的儲能、合閘、分閘；
配電回路：控制開關的合閘、分閘；
電動機控制電路：電動機的啟動、停車等操作；
補償電路：能選擇自動/手動補償。手動方式下，遠程可控制電容器、電抗器、APF的投切等；
有載調壓變壓器分接頭位置遠程控制。
（3）通過上位機提供系統的各種信息資源，包括：
動力中心電路：控制開關的儲能、合閘、分閘；
配電回路：控制開關的合閘、分閘；
電能管理、成本分析和負荷分析等；
變壓器分接頭位置。
另外，智能MCC系統還需要完成與生產工藝直接相關的如調速裝置頻率、電動機負荷（電流、功率）等信號到DCS或生產控制系統的上傳；以及對特定的設備進行自動控制，并滿足控制的可靠性和足夠響應時間要求。
為了完成設備的設備預警、智能診斷和快速故障定位，智能馬達保護器本身提供的回路熱過載、缺相、相間不平衡、過電流、堵轉、起動超時、接地故障、頻繁起動、電機PTC熱保護、接地故障、欠載、相序顛倒、過電壓、欠電壓、功率、功率因素、平均電流、相間電流不平衡率、熱容量、電機溫升等[5]保護和測量的信息也需要按照實際設備情況采集并歸納到智能MCC系統中。
同時為實現對所有電氣設備的全面管理，設備本身的電子化圖紙、規格參數、設計參數、額定參數、操作記錄、維修策略、檢維修記錄、運轉時間和啟動次數等信息也需要通過網絡或信息化系統進行采集和管理。
二 海量數據分層分級管理機制設計
本系統制定如下數據分級分層管理原則：必要的實時數據和信息，稱為實時數據，采用毫秒級進行采集和管控；需要動態更新但工藝決定不會發生瞬變的數據或只用來監視不參與控制的數據，稱為類實時數據，按照秒級進行數據傳輸；平常不需要進行實時更新但需要和現場設備交互的數據，稱為參數管理類數據，在需要時才進行傳輸和存儲；統計分析類數據按照客戶實際需要可進行調整。
通過分級分層管理可以大大提高網絡利用效率和關鍵數據傳輸的可靠性，具體分類如下：
（1）實時數據
設備狀態、脫扣狀態、有功功率、無功功率、報警信息；
實時數據采樣周期為ms級別。
（2）類實時數據
三相電流、平均電流、接地電流、過載電流、平均過載電流、三相電壓、平均電壓、頻率、功率因素、電度；
脫扣數據記錄、報警數據記錄、熱容量；
類實時數據更新時間為秒級。
（3）參數管理類數據
過載報警值、接地報警值、堵轉報警值、欠載報警值、電流不平衡報警值、高/低電壓報警值、高/低電流報警值；
過載復位時間、過載脫扣時間、接地脫扣值、堵轉脫扣值、欠載脫扣值、電流不平衡脫扣值、高/低電壓報警使能、高/低電流報警使能；
參數管理類數據在需要時候才進行傳送。
（4）統計分析類數據
起停次數統計、能耗統計、脫扣統計、報警統計、有功/無功統計。
另外通用的管理數據或通過信息系統下發的管理信息統稱管理類數據，如設備規格參數、操作記錄、維修計劃、電子資料文件等，通過信息層網絡進行傳輸管理，不再經由現場數據總線。海量數據分層分級管理機制框圖見圖一所示。
三 海量數據分層分級管理機制應用
（1）實時數據采集及網絡負荷率
本系統通過第三方機構賽寶對實時數據的采集時間和網絡負荷率進行測試，以馬達保護器的故障報警響應時間為例：
報警響應時間第一次測量結果：250ms；
報警響應時間第一次測量結果：250ms；
報警響應時間第一次測量結果：312ms；
報警響應時間第一次測量結果：63ms；
報警響應時間第一次測量結果：31ms；
報警響應時間第一次測量結果：31ms；
報警響應時間第一次測量結果：46ms；
報警響應時間第一次測量結果：46ms；
報警響應時間第一次測量結果：47ms；
報警響應時間第一次測量結果：74ms。
智能MCC系統網絡負荷率為17.12KB/s～21.38KB/s。
（2）參數管理類數據的按用戶需求進行交互
圖二為海上MCC回路斷路器電流整定值、散熱時間及保護類型的交互界面，這些參數是參數管理類數據，按照用戶需求進行交互。用戶可以查看或更改該設備此類型參數。
（3） 其他管理類數據的傳輸、存儲
海上油田智能MCC系統對于底層設備進行了臺帳、設備檢維修管理及電子資料管理等，這些設備的臺帳、檢維修信息通過數據庫協議等進行信息的傳輸、存儲，并且為了不影響數據庫檢索響應速度，智能MCC系統電子資料管理中的文件數據通過FTP協議進行傳輸、存儲[6]。
圖三為智能MCC系統軟件設備電子資料模塊的交互界面。
4 總結
海上油田智能MCC系統的海量數據管理機制的設計，梳理了智能MCC系統不同類型數據的采集、傳輸、存儲機制及存儲途徑，并通過了現場應用與測試。該方法能夠保證智能MCC系統在海上、陸地運行時的穩定、可靠性。
參考文獻
[1]魏澈，王國朝. 海上IMCC系統設計綜述[J]. 電子技術與軟件工程，2014（15）：95-97.
[2] 佟為明，陳向陽，李風閣，吳S.DeviceNet現場總線技術[J].微處理機，2002（6）：1-3.
[3] 劉建昌，左云，錢曉龍，陳智鋒，馮立. 現場總線概述[J].基礎自動化，2000，7（6）：1-5.
[4]郭宏，于凱平. 電機控制中心綜述[J].電氣傳動，2006（3）：8-10.
[5] Cleaveland Peter. Smart Motor Control Center has Built-in DeviceNet Communications， Software for Monitoring and Control[J]. I&CS Instrumentation & Control Systems，2000，73（3）：58-60.
篇5
知道淘寶每天產生的交易數據量有多少嗎?知道電信運營商們的業務數據量已經達到什么數量級了嗎?知道熱盼的智能電網落地后會新增多少數據嗎?
數據爆炸催熟分析型數據庫
在這個數據不斷膨脹的時代,企業數據量從過去的MB到GB再到TB,增長到現在的PB級數據規模。過去多年來,中國企業非常重視基礎和應用建設,其結果是產生了大量的數據。如果這些數據不能體現價值,IT從業人員會遭受到巨大的壓力。
而大多數數據庫的性能隨著所管理的數據量的增加,性能會急劇下降,傳統的OLTP數據庫在處理海量數據時遭遇瓶頸,于是分析型數據庫登臺亮相。
分析型數據庫是在海量數據中心、企業級數據倉庫、企業數據云的背景下分化出來的一個細分市場,這個市場從被明確出來的那一刻起,就發展得異常迅速。
都說分析型數據庫時代來臨,那到底什么是分析型數據庫,和傳統的數據庫有什么區別呢?分析型數據庫廠商Greenplum業務總監陳昌騰向記者介紹說,傳統數據庫側重交易處理,關注的是多用戶的同時讀寫操作,在保障即時性的前提下,處理數據的分配、讀寫等操作,存在I/O瓶頸。而分析型數據庫是以實時多維分析技術作為基礎,對數據進行多個角度的模擬和歸納,從而得出數據里面包含的信息和知識,當面對海量數據時,數據庫首先要克服I/O瓶頸。
企業采用分析型數據庫技術有無數的理由。TDWI Research的高級經理Philip Russom認為,其中一個很重要的原因,就是數據分析的使用越來越頻繁,而其復雜度卻越來越高。一種被Russom和其他專家稱為“高級分析”的技術目前十分火熱,它描述了特別復雜的――通常是SQL驅動的查詢或者預測分析技術的使用。毫無例外,分析型數據庫專家都將MPP(Massively Parallel Processing,平臺海量并行處理服務器)作為高級分析的一個必要條件。
Russom認為傳統的數據倉庫系統是無法完成針對海量數據的分析任務的,他引用TDWI的一份調查來說明:調查顯示有40%的受訪者對他們現有數據倉庫平臺的分析能力表示擔心,有51%的受訪者表示計劃在接下來的5年時間里,啟動分析型數據庫平臺。
讓用戶在幾秒內得到查詢結果
高性能的大規模數據處理能力是DBA對數據庫夢寐以求的能力之一。從字面上不難看出,“高性能的大規模數據處理能力”,一方面是針對“大規模的數據”,另一方面就是“數據的處理”。前者需要的是數據吞吐能力,就是所謂的I/O;后者需要的是并行計算能力,即充分利用軟硬件資源最大化運行任務及進程,這也就是像Greenplum這樣的高性能數據倉庫引擎追求高效的兩個途徑。
Russom認為,高級分析技術轉為主要依靠復雜或對等的SQL語句實現,這讓傳統數據倉庫平臺查詢性能差的缺點更加突出。很多企業都認為“查詢響應慢”是影響他們部署數據倉庫平臺產品的決定性因素。
在這方面,分析型數據庫專家特別喜歡用傳統的數據倉庫平臺做對比,例如主流的Oracle、SQL Server或者DB2。分析型數據庫廠商紛紛宣稱自己的產品可以讓用戶在幾秒鐘內,甚至幾百毫秒內就得到想要的查詢結果。人們通常關注一些類型的查詢,這些查詢也許是需要頻繁交互的,或者有非常多的用戶,反正需要使用非常復雜的查詢語句,并且需要在幾秒鐘內就得到結果,人們無法容忍幾十分鐘甚至數個小時的等待。
“Greenplum的海量數據查詢速度可以比傳統的數據庫快20倍。”Greenplum大中華區總裁周金輝說,“其實20倍是一個保守數字,因為大多數的實際測試結果都顯示,查詢速度之比都在20至50倍之間。”周金輝在IT行業從業25年以上,曾在Oracle公司工作16年,擔任亞太區副總裁。周金輝表示考慮到客戶環境的差異、應用場景的復雜性,Greenplum認為20倍是完全可以保障的。但他同時表示,這一結果目前僅僅是在一些既有的數據倉庫應用案例中比較得出的。
陳昌盛向記者解釋說,之所以能做到如此,有三個原因:一是Greenplum的并行處理技術,創造出了前所未有的高性能,初接觸的客戶會感受到完全不同的震撼;二是Greenplum的分布式架構設計,使得用戶可以無限線性擴展所管理的數據,完全消除海量數據的壓力;三是 Greenplum的開放平臺設計,確保在低端的PC服務器實現高性能,這顯著降低了用戶的使用門檻,與市場正在形成的需求形成良性互動。
Greenplum試進入中國大約一年的時間,已經簽約了16家客戶,平均每個月都能夠簽約一家多,這樣的簽約速度在企業級軟件市場是非常快的,因為客戶從了解、熟悉到做決定一般都至少需要3個月的時間。Greenplum的簽約時間短,也說明了客戶對Greenplum的信心比較足。陳昌盛補充說,Greenlpum所管理的數據是無限擴充的;而且更為重要的是,目前所有的系統擴容都需要停機,但是Greenplum卻可以擴容不損失任何業務時間。
工作量管理是否有必要
有意思的是,Greenplum和其他分析型數據庫廠商,都特別熱衷于把Teradata作為對比對象。與一些傳統的數據庫管理系統廠商相比,Teradata的工作量管理(WLM)能力是非常出色的。
當然,也有一些分析型數據庫廠商宣稱能夠改善工作量管理特性,例如Aster Data Systems公司,他們表示其產品可以與Teradata的Active Systems Management(TASM)相媲美。Vertica公司負責市場的副總裁Dave Menninger也表示,Vertica在其最新產品Vertica 3.5版本中,引入了加強的WLM功能。大部分的分析型數據庫廠商,都會主要強調MPP速度和并行處理能力的優勢。
Teradata公司負責產品與服務市場的副總裁Randy Lea表示:“工作量管理是相當復雜的,我們依然在持續改進其功能,為客戶提供大量個性化的服務。”他認為,他們的目標是戰略層次上的,而大部分的分析型數據庫平臺的實現只是停留在戰術層面上。Lea說,在戰術層面上,工作量管理也許并沒有那么重要,最多你可以對使用系統的用戶做一些限制,而對于企業級的數據倉庫,情況則要復雜得多。
“即使是非常簡單的數據需求,我依然會制定一些業務規則,并予以實現。例如,CEO的請求應該具有最高優先級。這可能是一種好的策略。”他解釋說,“我們完全可以根據時間、查詢結果、用戶或者應用,來實現我們的業務規則,從而最好地實現數據倉庫的效用。”
“如果你遵從統一的平臺模型,并且需要為一部分數據倉庫任務提供良好的實時SLA保障,那么工作量管理是很有用的。”咨詢公司Third Nature的資深數據倉庫體系架構專家Mark Madsen說。他認為,現在需要建設數據倉庫的公司,需要在無所不包、自頂向下和松散耦合、自底向上兩種方法之間作出選擇。
篇6
關鍵詞：云計算 航空影像 數據處理 構架
中圖分類號：P23 文獻標識碼：A 文章編號：1672-3791（2014）03（c）-0005-02
隨著攝影測量手段和信息獲取技術的發展，航空影像數據的獲取周期越來越短，航空影像數據的更新頻率越來越快。對于海量遙感數據快速處理以達到實現快速響應機制，傳統的攝影測量數據處理平臺已經不能滿足當前的生產需求。因此，如何快速、高效地處理這些影像數據，以及如何迅速的從影像數據中獲取用戶所需的基本信息（如概貌、土地的分類、土地利用情況、植被分布、水系的分布和變化，災害區的范圍等）是一個值得研究并且急需解決的問題，也是建立遙感快速響應機制領域的一個重要的應用和發展方向。
本文將云計算模型處理的技術引入影像數據處理中，設計了基于云計算的海量影像數據的云處理模型。
1 云計算模型構架
云計算的關鍵是如何實現大規模地連接到更加廣泛的服務器甚至個人計算機，使這些計算機并行運行，各自的資源結合起來形成足可比擬超級計算機的計算能力。我們可以通過個人電腦或便攜設備，經由因特網連接到云中。對用戶端來說，云是一個獨立的應用、設備或文件，云中的硬件是不可見的，如圖1所示。
它的過程是這樣的：首先，用戶的請求被發送給系統管理，系統管理找出正確的資源并調用合適的系統服務。這些服務從云中劃分必要的資源，加載相應的Web應用程序，創建或打開所要求的文件。Web應用啟動后，系統的監測和計量功能會跟蹤云資源的使用，確保資源分配和歸屬于合適的用戶。
2 云計算處理模型的運行機制
基于云計算模型的影像數據處理模型是在傳統的影像數據處理流程的基礎上，突破了傳統的計算模式，使用了云計算強大的計算資源來完成整個數據處理中的大量的數字運算。其中包括任務的分發、云端處理以及處理完數據的集中和影像的鑲嵌等操作。
2.1 云處理模型的體系結構
圖2為基于云計算模型的影像數據處理系統的體系結構。云工作站負責管理和分發任務，云端處理服務器依據分發的任務，從云存儲中取出影像進行相應的處理，通過TCP/IP通信協議與服務器建立通訊。當對應的云端處理服務器（可以是大型的計算機業可以使微型的個人機）接收到任務時，通過調用系統的計算資源進行相應的處理服務，同時通過云端系統之間的相互通信可以實現一些軟件資源的共享等。
2.2 云處理模型的工作流程
圖3為基于云計算模型的影像數據處理系統的一般的工作流程，主要包括任務表的創建與分發，云端系統的具體的處理過程以及數據成品的集中和影像的鑲嵌。 利用云計算強大的計算資源來完成其中涉及到的巨大的運算要求。
3 基于云計算的航空影像處理模型
在這個模型系統中，主要包括數據的預處理和專題信息的提取。在后期的制圖過程中主要包括地圖信息的符號化和綜合。
3.1 預處理
遙感圖像的預處理主要包括幾何校正和輻射校正，還包括其他的預處理手段，如圖4所示。遙感圖像成圖時，由于各種因素的影響，圖像本身的幾何形狀與其對應的地物形狀往往是不一致的。遙感圖像的幾何變形是指圖像上各地物的幾何位置、形狀、尺寸、方位等特征與在參考系統中的表達要求不一致時產生的變形。遙感圖像的變形誤差可以分為靜態誤差和動態誤差兩大類。靜態誤差是在成像的過程中，傳感器相對于地球表面呈精致狀態時所產生的各種變形誤差。動態誤差主要是成像過程中由于地球的旋轉等因素所造成的圖像變形誤差。遙感圖像的幾何處理主要包括圖像的粗加工、精糾正，還包括重采樣以及共線方程的糾正的。
由于航空影像成像過程的復雜性，傳感器接收到的電磁波能量與目標本身輻射的能量是不一致的。傳感器輸出的能量包含了太陽位置和角度條件、大氣條件、地形影響和傳感器本身的性能所引起的各種失真，這些失真不是地面目標本身的輻射，因此，對圖像的使用和理解會造成影響，必須加以校正或消除。輻射校正就是指消除或改正遙感圖像成像過程中附加在傳感器輸出的輻射能量中的各種噪聲的過程。
在影像數據制圖中，數據的收集一般包括遙感影像數據的收集和其他非空間數據的收集，在充分收集歷史和當前數據的基礎上要對于資料進行初步的整理。數據的預處理主要包括影像數據的幾何處理和輻射校正。預處理的云處理模型已經在之前介紹過了。
3.2 中期操作
在傳統的遙感影像專題信息提取中，主要包括影像數據的格式轉化，圖像的增強和均衡化、波段的融合、糾正等，文本資料的分類，地圖信息的分析，同時在信息的提取中有監督法分類和非監督法分類，以及分類后處理等操作。在基于云計算模型的遙感影像處理系統中，上述的操作方法不變，變化的是計算的模式。傳統的處理模式是串行的處理，基于云計算的遙感影像處理模式主要是利用云端系統強大的計算資源實現影像的實時處理。
在完成任務的分發后，相應的云端通過直接的相互通信，能夠下載相應的處理模塊所需的軟件和模塊，同時按照當前服務器的計算資源狀況完成相應的處理和任務的分發等。
3.3 后期操作
后期的專題地圖的制作中主要包括地圖信息的綜合，按照專題的信息決定地圖信息的取舍，突出重點的專題，省略其他無關的要素，符號化的過程主要依據可視化和視覺美學等知識進行取舍，其中涉及到大量的計算任務仍然放到云端來完成。影像數據的處理一般包括格式轉換、圖像的增強、均衡化、波段的融合等，在影像數據的應用上主要有信息的提取、分類、專題圖的制作等。
4 結論
云計算是一種顛覆性的技術具有深刻意義，不僅對互聯網服務，而且對這個IT 業都是一次革命。將它應用在航空影像數據處理領域更是一種大膽的嘗試，作為航空影像數據處理專業領域，如何進行海量數據存儲與處理、系統的擴展與開放等是該領域長期的瓶頸，云計算的出現給解決這些問題帶來了希望。本文詳細探討了遙感云計算的系統構成和實現方法，并以一個具體的原型系統展現了航空影像云計算模式的用戶界面、技術手段和運行流程。
參考文獻
篇7
傳統大數據保護方案海量難題
IT系統運維的有效性將直接關系到企業能否正常運行。數據量暴增、應用的愈加復雜卻使大型用戶的數據中心、共享災備中心等環境成為了大數據問題的重災區。
首先，海量數據卷導致備份時間延長，企業往往被迫采用復雜的快照和腳本方法，因此恢復操作極其復雜、耗時。
其次，大多數企業在其所分配的備份時間中無法完成完全或者增量備份；而主要應用程序的磁帶備份連續寫入方式需要更高的網絡和處理器能力以及更多的時間；另外，傳統的保護模式制約服務器虛擬化項目和云技術的啟動及實施；邊緣數據無法得到系統保護；耗費時間“堆砌”在一起的大量單點產品導致管理備份活動極其困難；數據恢復既緩慢又不細化，缺乏確定性；無法實現完全的分層存儲。
再次，傳統的備份方法不能全局性地解決冗余數據激增的問題，這一問題會導致對網絡、存儲和管理資源的過度消耗。這限制了企業恢復和使用受保護數據的能力，增加了數據恢復和查找所需的時間。
全新IaaS架構創新TxCloud突破大數據保護容量瓶頸
所幸，愛數推出了TxCloud云柜，這款為大中型數據中心提供一體化備份容災云計算解決方案的大機柜，將有效解決這個難題，并結合法規遵從管理理念，將IT管理目標與企業管理目標有效結合，提升數據的業務價值，輕松構建私有云。然而，TxCloud云柜為何能在大數據時代立足？
云概念的興起使IaaS架構廣為人知，而云柜便是基于IaaS的底層架構來建設，在IaaS架構之上搭建應用的。正是基于此，TxCloud云柜才可在大數據中乘風破浪。
首先，IaaS的底層架構實現了對底層物力資源的抽象，使其成為一個個可以被靈活生成、調度、管理的基礎資源單位。這樣便可以以服務化的方式向上層提供資源。
其次，TxCloud云柜的IaaS底層架構將會做分布式存儲，使未來存儲擴展更方便。云柜定位于大數據時代的備份容災，而誰都無法預測到大數據時代的備份容量要求，因此存儲的擴展性對云柜的意義非凡。
再次，IaaS的服務化使得添加新應用更方便，同樣為TxCloud云柜應對大數據提供支持。
正是由于引入了IaaS架構，TxCloud云柜才會具有更良好的擴展性以及更大的備份存儲容量。現在TxCloud云柜最多支持18個備份容災節點，共可提供432TB的物理容量。但IaaS架構的功能并不僅限于此，TxCloud云柜將更具可持續發展性和可持續擴展性。
重復數據刪除技術完美嵌入
大數據保護無懼海量難題
重復數據刪除技術不再新鮮。然而，愛數一體化容災技術體系中的源端重復數據刪除技術，其重刪比最高可達99%，能夠有效控制因備份而產生的重復數據的快速增長。
愛數將源端重復刪除技術完美嵌入TxCloud云柜后，用戶備份的次數越多，其實際數據與邏輯數據間的比例就越小。如：用戶第一次備份10TB數據，而第二次備份時只變化了其中的2TB，從用戶角度而言，兩次完全備份服務端就需保存20TB的數據，但基于愛數源端重復刪除技術,服務端實際只會存放12TB的數據。因此，基于云柜本身的屬性，最多可提供432TB的物理容量，再除以重刪率(約1/9),即可以使最終的邏輯容量達到3.5PB之多。
篇8
關鍵詞：海量數據存儲;分布式數據庫;MPP架構;并行處理
目前海量數據處理還是一個比較新的研究方向，大多數都是各公司或者是組織各自研究自己的處理方法，國際上沒有通用的標準，研究的方式和結果也都是各有千秋。針對項目中帶有復雜業務邏輯的海量數據存儲，主要從容量擴展和并行處理兩個方面考慮。前文己論述過NoSQL分布式數據庫由于其數據結構簡單、不善于做JOIN連接等復雜操作，存在數據遷移問題，并不適用于本項目，所以本解決方案依舊從關系型數據庫入手。其次為了支持多樣的切分策略，本論文將實現range、list、consis
tent-hash模式。最后系統借鑒MPP并行處理架構，使得整個項目能部署在便宜的PC集群上，不僅能保證穩定性，還節省項目成本。
物理設施包含數據庫服務器的基礎架構、web服務器的選擇，以及資源分配管理服務器的選擇。這三者分別負責數據的存取、數據的分析處理以及資源工作的均衡分配，它們協同合作，共同搭建一個高效的協同的后端服務管理，使存儲系統均衡工作、高效運行。
作為解決海量數據的存儲方案，首要必須考慮是存放海量數據的需求。根據前文可知，分布式數據庫的出現其根本原因是解決存放不下數據的問題，故而將數據依照策略存放在不同的數據庫服務器上，存放數據的策略以及數據之間的并行查詢處理是研究的重點。第二個問題是分布式處理方案，現有技術從各個方面進行過嘗試，有的基于關系型數據庫提出了多種shard
ing方案。將關系型數據庫遷移到非關系型數據庫上代價太大，所以本解決方案基于關系型數據庫的系統。
根據以上的設計思路與實現目標，設計出分布式海量數據存儲解決方案。該系統主要包含以下四個模塊：
SQL解析模塊。SQL語句復雜、格式多樣、形式多變，解析結果作為數據切分的依據。解析SQL語句的方法是編譯成字節碼，生成語法樹，這種方式的優點是準確率高、數據層次清晰、結構正確，但設計到相關語法樹知識，比解析字符串更難以理解。
數據分發模塊。如果集群系統中沒有進行數據切分，則多臺數據庫服務器存儲的是完全一樣的數據，這實際上是對硬件資源的浪費，也在同步數據保持一致上浪費了更多的時間和效能。而且一旦數據再上升一個等級，很可能一臺服務器就無法存儲下大量數據。所以合適的數據切分策略是遲早的，本解決方案將結合現有的數據切分策略，結合業務邏輯，提供多樣的切分策略，并且預留切分接口使用戶靈活地自定義自實現，系統的可用性更高。
并行處理模塊。由分發服務器和多臺數據庫服務器構成。相對于集中式數據庫來說，分布式詢代價需要考慮以下因素：
CPU處理時間，I/O消耗時間，還有數據在網絡上的傳輸時間。在設計系統的時候，應該根據分布式數據庫中各個數據庫的地理位置的不同情況來設計。在局域網且傳輸率高的系統中，通信代價和局部處理的開銷差別不大，在優化中則應平等對待;在數據傳輸率較低和通信網速度較慢的系統中，網絡傳輸可能會比花費在查詢中的CPU及I/O的開銷更大，則應首要考慮優化網絡通信。
匯總處理塊。結果匯總大致分為兩種情況：單機單庫情況下，直接返回結果;多機多庫的情況則需要在轉發節點處進行一個匯總。
基于架構的工作流程大致如下：首先，轉發節點收到客戶端發來的SQL語句，將依據各個解析節點當前工作量、預計完成解析工作的時間、本條查詢語句預估需要時間、歷史響應需求時間等因素，將SQL語句轉發給各個解析節點，對其進行語法解析。當所有的工作量都經過這個轉發節點的時候，必然會產生高并發的問題。在存在多個分發節點的情形下，為了消除單個轉發節點的性能瓶頸，本文設計多個分發節點，每個節點都可以將任務轉發到不同的解析節點。采用RoundRobin策略將任務依次分發給每個解析節點，讓工作量保持均衡。其次，解析節點解析本次查詢的SQL語句，生成便于理解的SQL對象，通過調用相應的接口方法可以實現對SQL語句的操作。最后，各個數據庫服務器執行了 SQL語句，便對查詢結果進行一個匯總并返回，劃分倘若是單機查詢，那么處理的結果可直接返回給客戶端。
SQL解析、數據切分以及轉發歸并的工作都由以上四個模塊協同完成。
基于MPP架構的設計了關系型數據庫的海量數據分布式存儲解決方案。本章采用解析SQL語句、分發SQL語句，并行處理、歸并匯總處理結果的方式完成整個框架。與MySQL
Cluster的區別在于采用的存儲引擎就是MySQL，適應于本身就用MySQL進行存儲的集中式數據庫的改造，或是業務邏輯復雜的報表展示等，無論是業務的擴展，遷移都十分方便。
參考文獻：
篇9
關鍵詞：海量遙感影像 縮減存儲 瓦片地圖 高并發訪問
中圖分類號：P282 文獻標識碼：A 文章編號：1672-3791（2014）05（b）-0031-02
隨著遙感技術的發展，影像地圖應用的日益增多，在全國級的海量影像地圖應用中，數據的存儲、管理和更新是業界一直比較關注的熱點問題。當前很多應用會采用分塊分層結構對影像地圖數據進行切割處理，然后分塊調用[1]，可以明顯加快顯示速度，下文稱此技術產生的地圖為瓦片地圖。在這種瓦片地圖應用過程中，本文提出了一種基于特征點數據分布的海量影像地圖縮減存儲方法，并以瓦片影像地圖的應用為實例進行驗證，該方法可以有效縮減90%以上的地圖存儲量，在此基礎上，本文還分析了數據快速更新機制、適用于高并發的多級數據存儲策略等海量地圖應用關鍵技術的可行性。
1 影像數據組織方式
本文以瓦片式影像地圖的應用作為實例，來驗證該縮減壓縮方法的有效性，故此先簡述瓦片地圖的組織結構以及數據存儲量的計算方法。
1.1 金字塔式瓦片存儲組織結構
瓦片式電子地圖是當前比較流行的地圖服務形式，其采用金字塔結構，對影像地圖進行分層和分塊的劃分。按照既定的多層比例尺，把每一個比例尺的整幅影像地圖切割為256×256像素或者512×512像素的小幅圖片（通常稱為瓦片），地圖引擎再采用相應的算法，把這些小幅圖片組織起來，顯示到客戶端界面。瓦片的結構圖如圖1所示[2]。
1.2 影像地圖數據總量計算
假設切圖方式采用現在流行的WEB墨卡托投影切片方式，即橫向和豎向的瓦片數量一致，則可知每個地圖級別n的瓦片數量為2n×2n，0～18級瓦片地圖的總數據量及存儲空間見表1所示[3]（通常情況下，影像瓦片地圖平均大小為10 KB）。
以上為全球的瓦片地圖總數據量，如果按中國大陸的區域進行計算，0～18級的數據總量大約為1994965244×10/1024/1024/1024=18.58T。
2 影像地圖智能縮減存儲方法
下面以全國特征點數據為基礎，詳述如何從中挖掘出重要區域信息，然后采用合適的高效算法，判斷某個位置的瓦片地圖是否是重要地圖，繼而選擇性的存儲，保證存儲的瓦片地圖都位于比較重要的位置。并且根據某個位置區域的特征點數據的密度，自動判斷某個比例尺下的某個瓦片是否為重要地圖，可針對每個比例尺進行地圖重要性判斷，從而大大縮減了重要地圖的數量，達到地圖智能縮減存儲的目的。
2.1 挖掘重要區域信息
首先對全國特征點數據進行網格劃分，劃分依據為14級瓦片地圖的切割方法，統計每個網格內的數據量，并根據數據量的多少，計算當前網格的重要程度，基于此重要程度，判斷當前網格所處的區域是否為重要區域，并且根據重要程度的高低，判斷后續的15～18級地圖是否為重要地圖。
選擇14級作為基準參考級別也是有所考慮的，14級網格數量約為596.7萬，若按15級或更大級別劃分，就容易因網格數量過大，降低后期數據判斷的運算速度。并且因為本重要程度數據本身只是參考數據，并不一定代表實際情況，所以，過于要求數據的精準度，并不一定達到更好的實際使用效果。
該分析方法具有通用性，當特征點數據更新時，可快速的更新此重要區域信息，為后續的判斷提供新的依據。
2.2 基于重要區域信息的縮減存儲方法
按照上一步挖掘出的重要區域信息，判斷任意瓦片地圖是否為重要地圖，簡單的判斷依據為：
（1）小于14級，認為全部是重要地圖。
（2）14級，當網格內數量大于0，則認為是重要地圖。
（3）14級以上時，假設當前級別為level，先找到當前瓦片在14級所在的瓦片網格的位置，獲取此網格的數據量n，判斷當n>=4level-14時，認為此瓦片為重要地圖。
（4）循環所有瓦片地圖，即可知道那些為重要地圖。
在地圖存儲時，就可以僅存儲重要地圖，達到縮減存儲的目的。
考慮到特征點數據可能出現缺失，以及盡可能為重要地圖區域顯示更多的緩沖區域，并且重要地圖周邊一定范圍的地圖訪問量也會是比較高的，所以可對上述判斷依據做進一步的優化，以便更好的適用實際情況，可能包含以下優化方法：
（1）重要地圖周邊N塊網格的地圖都認為是重要地圖，N>=1，具體數值可根據實際情況設置。
（2）每個網格的權重不簡單的按照其中的特征點數量，而是參考周邊網格的權重進行綜合計算，可有效的建立重要地圖的周邊緩沖帶，達到更好的顯示效果。
優化后可達到更好的顯示效果，但也會帶來存儲量的增加，需根據實際情況選用。
3 應用實例
本文以中國大陸的影像地圖為例，使用本文的數據縮減方法對海量瓦片影像數據進行縮減存儲處理。
首先，對全國2000余萬條特征點數據進行挖掘分析，計算出重要區域，然后通過此重要區域以及相關算法，判斷每個瓦片是否為重要地圖，計算結果如表2所示。
全部級別數據量之和為17176348張瓦片，總存儲空間約為163.8G，相比沒有縮減之前的18.58T的數據存儲空間，縮減比例達99.14%。
因影像瓦片地圖色彩都比較豐富，重要和非重要區域的地圖圖片大小差別并不是很大，由實際的存儲容量就可以看得出來，所以使用理論上的瓦片數據的比例作為存儲空間的縮減比例，是具有一定的參考價值的。
從部署和更新時間上考慮，163.8GB的瓦片地圖數據進行切片、壓縮、打包、上傳、解壓等完整步驟，在單臺普通計算機上只需要20天左右的時間，如果使用多臺機器進行任務分解操作，基本上可滿足快速更新部署的需求。
4 基于重要區域信息的擴展應用
4.1 地圖快速更新
如果有新的影像地圖數據產生，可優先對重要區域內的地圖數據進行處理，達到數據快速更新的目的。
4.2 提升并發性能
眾所周知，對于大多數系統來說，最頭疼的就是大規模的小文件存儲與讀取，因為磁頭需要頻繁的尋道和換道，因此，在讀取上容易帶來較長的延時。在大量高并發訪問量的情況下，簡直就是系統的噩夢[4]。海量瓦片地圖就是這樣的情況，圖片數據可達數十億張以上，如果沒有比較好的存儲策略，在高并發訪問時，文件IO勢必成為系統瓶頸。當前比較簡單且有效的方法是將訪問頻率較高或者隨機讀寫比例較高的數據文件放在固態硬盤SSD上，而將訪問頻率較低或者順序讀寫比例較高的數據文件存放在機械硬盤上[5]。
根據本文提出的數據縮減方法，就可以把重要地圖放置在SSD硬盤上，把剩余的地圖放置在機械硬盤上，可大大提升高并發時的地圖訪問速度。并且根據當前主流的存儲器價格數據，SSD存儲的價格大約是SATA盤的10～20倍，昂貴的高速存儲器只有比較小的存儲空間，把訪問量高的數據放在高速存儲上，訪問量低的數據放在低速存儲上，也可以達到節約成本的目的。總之，使用本文的數據縮減存儲方法，可達到節約成本、提高并發訪問性能的目的。
4.3 原理通用性
本縮減方法，還可適用于平面地圖、地形圖等各種瓦片地圖或者其他地圖數據的存儲策略，便于對訪問需求量比較高的“重要地圖”進行優先考慮。
5 結語
本文提出的海量影像地圖數據縮減存儲方法，可有效的降低數據存儲量，特別是當數據有多機備份時，具有非常明顯的效果；進一步，基于此方法產生的重要區域信息數據，本文還提出了其可能的一些擴展應用，例如解決數據多級存儲、高并發訪問、成本控制以及快速更新部署的問題。
參考文獻
[1] 王華斌，唐新明，李黔湘.海量遙感影像數據存儲管理技術研究與實現[J].測繪科學，2008，33（6）：156-157.
[2] 宋江洪，趙忠明.圖像分塊分層結構在海量數據處理中的應用[J].計算機工程與應用，2004（33）.
[3] 許輝，馬曉鵬.基于WEB墨卡托投影地理信息系統設計與實現[J].電腦編程技巧與維護，2011（8）.
篇10
關鍵詞 分布式計算 非關系型數據庫 海量數據處理 云計算
1 引言
目前網絡服務正從傳統的“高集中、高成本、低通用”的服務配置向“高分布、低成本、高通用”轉變。為了構建出動態的、易擴展的、高性價比的計算和存儲平臺，目前涌現出了云計算(Cloud computing)等新型網絡計算技術及其應用系統，目的都是將客戶數據和計算請求部署在大量集中或分布管理的廉價計算與存儲設備(如PC)上，利用高效的并行和分布式計算技術，支持應用的快速部署和任務調度，提供數據冗余機制，穩定、快捷地滿足用戶的各種應用。其中，數據的存儲方式是構建云計算平臺時需要重點考慮的關鍵因素。
1970年，Edgar Frank Codd首次提出了數據庫的關系模型的概念，奠定了關系模型的理論基礎。后來Codd又陸續發表多篇文章，論述了范式理論和衡量關系系統的12條標準，用數學理論奠定了關系數據庫的基礎。IBM的Ray Boyce和Don Chamberlin將Codd關系數據庫的12條準則的數學定義以簡單的關鍵字語法表現出來，里程碑式地提出了SQL語言。由于關系模型簡單明了、具有堅實的數學理論基礎，所以一經推出就受到了學術界和產業界的高度重視和廣泛響應，并很快成為數據庫市場的主流。當前的大多數數據主要以關系型數據庫的方式進行存儲。
隨著Web2.0的快速發展，非關系型、分布式數據庫存儲得到了快速的發展，它們不保證關系數據的ACID特性。非關系型數據庫(NosQL)概念在2009年被提出來，其主要特點如下：
(1)松耦合類型：使用松耦合類型、可擴展的數據模式來對數據進行邏輯建模(Map、列、文檔、圖標等)。
(2)彈性計算能力：以遵循于CAP定理的跨多節點數據分布模型而設計，支持水平伸縮。也即對于多數據中心和動態供應的必要支持，即彈性計算能力。
(3)靈活存儲：擁有在磁盤或者內存中，或者在這兩者中都有，對數據持久化的能力，有時候還可以使用可熱插拔的定制存儲。
(4)多數據接口：支持多種的“Non-SQL”接口進行數據訪問。
(5)易擴展：NoSQL種類繁多，但是共同的特點是沒有關系數據庫的關系型特征。數據中間無關系，因此擴展比較容易，同時在架構的層面也帶來了可擴展的能力。
(6)大數據量，高性能：NoSQL由于無關系型，數據存儲的結構簡單；且NoSQL的Cache是記錄級別的，因此性能要高很多。
(7)靈活的數據模型：NoSQL無需事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式；而關系數據庫，則基本不可能。
(8)高可用：NoSQL由于采用CAP原則設計，在不影響性能的情況下，可以實現高可用的架構。
目前普遍受到關注的基于大規模廉價計算平臺的系統包括Google的云計算平臺和Yahoo資助的開源項目Hadoop系統等。這兩種系統采用了非常近似的Map／Reduce計算模式和大規模分布式非關系數據存儲NoSQL機制(Google的Bigtable和Hadoop的HBase)。
本文的貢獻在于：探索在混搭平臺上，既利用NoSQL的高并發、高擴展、低成本的特性，又保持了傳統數據庫成熟的解決方案，從而展示了混搭平臺對于海量數據存儲及分析處理能力，以源自電信部門的大規模業務數據為分析對象，構建了一個具有良好參考價值的應用示范。
2 技術思路
隨著電信行業的發展和用戶規模的不斷擴大，每天都產生著海量的業務數據、上網數據、信令數據、用戶話單數據等。運營商普遍希望利用數據挖掘技術對這些數據進行分析處理，從而提供決策支持和為用戶提供增值服務。然而由于數據量過于龐大，利用關系型數據庫和復雜SQL語言對數據進行處理的傳統方法將占用大量處理與存儲資源，造成承載的服務器負載過高，執行效率低下，不得不提升服務器性能及存儲規模，導致投資成本增加，已經越來越不可取。
“非關系型數據庫”能夠以兩種基本的方式實現業務處理的靈活性。模式自由的邏輯數據模型有助于為任何業務進行調整帶來更快的周轉時間，把對現有應用和功能造成的影響減到最少，在大多數情況下因變更而帶來的遷移工作幾乎為零；水平伸縮性能夠在用戶增加造成負載周期性變化，或者應用突然變更的使用模式時，提供堅固的保障。面向水平伸縮型的架構也是邁向基于SLA構建的第一步，這樣才能保證在應用不斷變化的情形下業務處理保持連續。
分布式數據的核心問題是保證磁盤I／O不能成為應用性能的瓶頸，在此之上，絕大部分解決方案支持各種新一代并行計算的范式，例如MapReduce、排序列、Bloom Filter、B樹、Memtable等。分布式計算模式將大型任務分成很多細粒度的子任務，這些子任務分布式地在多個計算節點上進行調度和計算，從而在云平臺上獲得對海量數據的處理能力，可以有效地解決電信行業海量數據挖掘處理中所存在的問題。
以關系型數據庫存儲和非關系型數據NoSQL存儲為基礎，結合云計算下的分布式計算理念，以下提出對電信數據的海量數據處理方法。
3 方案設計
結合關系數據庫存儲敏感數據及實時訪問的優點，以及非關系數據庫模式自由與低成本高性能高可擴展的優點，本文提出了關系數據庫與非關系數據庫NoSQL相結合的海量數據方案。系統架構如圖1所示。
(1)數據整合層
通過封裝關系數據存儲與非關系數據存儲的混合存儲模型，化繁為簡，用于實現數據訪問與共享的隔離。
本系統的核心在于關系數據存儲和非關系數據存儲的有效結合。非關系型數據存儲和關系數據存儲主要包括如下技術實現方式：非關系存儲作為鏡像(可以采用代碼同步模式或者同步模式)、關系與非關系數據存儲的組合。鑒于電信行業數據的特點，本系統主要采用關系和非關系存儲組合的方式進行實現。
