海量数据范文

导语：如何才能写好一篇海量数据，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。

篇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)数据整合层

通过封装关系数据存储与非关系数据存储的混合存储模型，化繁为简，用于实现数据访问与共享的隔离。

本系统的核心在于关系数据存储和非关系数据存储的有效结合。非关系型数据存储和关系数据存储主要包括如下技术实现方式：非关系存储作为镜像(可以采用代码同步模式或者同步模式)、关系与非关系数据存储的组合。鉴于电信行业数据的特点，本系统主要采用关系和非关系存储组合的方式进行实现。