海量实时数据（共10篇）
海量实时数据 篇1
1 前言
随着电力信息化建设的不断推进, 大量实时和非实时系统得到建立, 大体可以分为监视系统、控制系统以及管理系统, 这些系统对电网的安全管理、安全生产以及经营起到了极其重要的作用。但已有的系统大多都是在不同时期由不同单位建设的。因此, 各系统的通信接口迥异, 无标准化的整体设计和建设规范, 系统间的数据关联较弱, 无法有效进行实时数据的共享与交互, 严重阻碍了电力信息化建设的发展。这也使得跨区多系统协作时, 系统间数据的传输容量, 传输效率得不到保证。建立标准化的实时数据服务平台显得十分必要。以下提出一种新的海量电网实时数据服务平台设计构架, 在研究各类电网系统数据即基本数据、运行数据、试验数据、在线监测数据和事故数据的基础上, 建立了标准化实时数据的数据接入格式, 统一了电网内系统间的数据通信协议, 消除了以往通信接口、数据存储接口以及服务接口相互孤立的缺陷, 形成了标准化的不同系统数据交互的海量实时数据的服务平台。
2 数据平台发展现状
由于电网实时系统应用范围的不断扩大, 以及安全分区的推进, 传统数据的传输交换结构已经无法满足现实的需求, 孤立接口模式来实现数据传输交换正逐渐被中心数据平台所代替。调度数据中心[1,2,3]向着一体化、集成化发展, 逐步形成图形、数据、模型等为一体的调度数据平台, 有效增强了电网应用系统间的数据交互与协同。实现电力生产海量实时信息交互和生产实时数据的共享的基础上, 需要更好地为电网的经济、安全运行以及经营管理服务。显然, 对于这一“企业级”的管理和生产需求, 调度数据中心却并不能完全满足, 因此, 企业级数据平台成为了研究热点。企业级数据平台的数据并非来自孤立单一的系统, 而是来源于电网中各部门相关的系统, 并且其数据平台能够为电网整体提供服务, 实现各类数据的共享与交互。
3 实时数据服务平台标准化
3.1 标准规定
国际电工委员会制定的IEC61970/61968协议标准以其先进的理念, 为电网自动化提供了指导, 给出了电网企业相关业务相适应的电网模型和接口规范, 即公共信息模型[4]CIM和组件接口规范CIS。这一协议标准彻底改变了电网中各系统信息无法有效交互, 效率较低等缺点, 使得电网中各电力信息化系统能够实现无障碍对接, 真正做到互通互联, 极大地降低了电网各系统的集成应用成本。CIM是整个IEC61970协议标准的核心部分, 是一个抽象的模型, 提供了标准化方法, 描述了电力系统中所有对象的逻辑结构和关系信息模型。这就使得能够把电网的物理设备层抽象为资源层, 不仅考虑到了主网的物理设备资源, 而且囊括了配用电等。传统的电力生产调度常常用CIM作为电网模型, 随着应用范围的不断扩大, 在其他相关电力业务的描述上使用也越来越广泛。比如电网电气、风电网、微电网[5]等都可以用CIM来建立电网模型, 获得抽象应用, 其意义不言而喻, 对电力系统中其他各类信息相关系统的集成与融合起到了指导性作用。从整体来看, 一整套CIM模型过于庞大、覆盖面广, 所建模对象之间的逻辑关系极其复杂, 因此, CIM中的对象类被对应成多个逻辑包, 某一个电力系统模型都对应着一个逻辑包。公共信息模型是由一组完整的包所组成, 这些包的集合逐渐发展成为独立的标准。
3.2 统一实时数据接入格式
3.2.1 标准体系结构
随着电力系统实时监控及决策支持系统的不断发展, 现有的电网内各系统间的数据交互性能、传输速率与安全可靠性以无法满足发展的需要, 建立能与海量数据流通相匹配的通信标准, 且能支撑电网中跨区域多系统的互通互联势在必行。应用较为广泛、技术较成熟的网络技术有ISO-OSI[6]参考模型, 这一参考模型大体上能够适应对电网中的实时动态数据的通信要求。ISO-OSI参考模型共分以下几层:应用层、传输层、网络层、数据链路层以及物理层。ISO-OSI参考模型中的传输层采用的是TCP协议, 面向链接的TCP能够提供可靠、全双工的字节流, 具有多路服用、全双工、控制流、同步和确认等功能。数据服务平台与其他各外部系统之间需要建立多通道和完成多发多收, 采用C/S模式的基于TCP的应用程序符合这些要求。各外部子系统的TCP/IP网络传输功能与数据的单元格式组成了实时数据传输的标准, 那么这个标准在基于TCP/IP的各类网络中均能使用。
3.2.2 数据单元格式
实时数据单元格式主要由4部分组成:头帧、命令帧、配置帧和数据帧。头帧规定了算法、变送器类型、模拟滤波器、数据源等说明性信息;命令帧规定了海量数据服务平台与电网各子系统通信的控制命令;配置帧主要描述了数据帧在传送实时数据时的数据类型及通信通道等信息。数据帧包含了同步相量测量值以及全球定位系统同步时间。而每个不同的帧有统一的功能字节分配, 前两个字节是帧的同步字 (SYNC) , 然后是占两个字节的帧字节数 (FRAMESIZE) , 再在后面的四个字节是世纪秒 (SOC) 。每个帧的帧头都提供了时间同步信息以及帧的类型, 帧与帧之间在传输的过程中无分界符, 每一帧都以CRC16校验字结束。
3.2.3 通信构架
海量数据服务平台与各系统之间的实时数据传输流程是通信标准的重要部分。实时通信基于面向连接的TCP通信协议, 使用C/S模式建立实时数据管道及管理管道, 图1简要说明了实时通信的建立过程。系统启动或重建通信时, 实时通信管道未建立, 服务平台与各系统的通信过程分解为若干子通信流程。
4 平台设计方案
4.1 整体架构
在建立配网模型标准、计量信息标准的基础上, 实现主配网信息的共享, 计量信息与配网设备的信息关联、主网设备与配网设备的关联以及设备功能位置与设备台帐的关联, 能够提供基于SVG图形的生产、运行综合信息的查询手段。配网系统和主站系统以适配器的方式接入海量实时数据平台, 系统的技术构架如图2。
4.2 技术路线
电网海量实时数据服务平台系统整体被设计为5个层次, 分别是用户接口、核心服务层、核心组件层、数据层以及操作系统层, 技术路线图3。用户接口层为用户提供统一的界面入口, 并根据授权的划分可以让用户能够完成不同模块应用。核心服务层提供以核心组件层为基础, 为标准协议层提供支持, 并且为各相关模块应用的调用的接口, 可使用本系统成为它们管理系统的一部分。核心组件层该层为实施实时协议标准提供支持服务, 其中核心组件层和核心服务层是基于C/S体系结构, 基于面向对象方法开发数据服务平台与相关基础组件和业务组件。数据层通过异构数据库各个组成部分的自治性, 实现数据的共享和透明访问, 同时实现不同数据库之间的数据整合, 其中每个数据库系统应保有自己的应用特性、完整性控制和安全性控制。操作系统层是基于C/S的架构, 支持各种流行的硬件平台和操作系统来为系统提供稳定安全的操作系统环境。
4.3 全网模型
分层、分区时我国电网管理与运行的典型特点, 所以电网信息的集成、交互、共享需以CIM来建立全网模型。全网模型的形成把各系统异构接口统一成标准化的接口方式, 使得可以任意获取电压等级范围内的设备参数、拓扑结构和电网模型。主要的核心设计是模型的导出以及全网模型的拼接与拆分。
4.4 数据接口
数据接口分为三大部分:配网系统适配器、计量自动化系统适配器以及生产系统接口。配网适配器连接信息集成平台与实时数据平台, 是其数据交互的接口, 依据CIM相关类对配网进行建模, 并且描述连接关系, 从信息集成平台获取按照CIM组织的配网模型和SVG图形。计量自动化系统适配器是实时数据平台接入计量主站系统的方式, 计量自动化系统相关量测数据的主要特点是多样, 因此, 量测与表计的模型需重点把握。生产数据与实时数据平台连接的接口可使用专用的接口方式, 生产系统接受展示服务器查询到的设备代码信息, 然后, 把设备缺陷信息或者设备台账反馈回去。
5 结束语
文中在提出适合电网实时数据传输的通信数据协议标准的同时, 给出了海量实时数据平台的设计方案, 通过研究各类电网系统数据即基本数据、运行数据、试验数据、在线监测数据和事故数据, 建立了标准化实时数据的数据接入格式, 统一了电网内系统间的数据通信协议, 消除了以往通信接口、数据存储接口以及服务接口相互孤立的缺陷, 形成了标准化的不同系统数据交互的海量实时数据的服务平台, 该数据平台能够提升电力系统整体的稳定性、安全性和可靠性, 为电网中各系统间海量数据的挖掘、分析、交互、共享提供途径, 极大的节约了电力生产中系统集成成本, 对于电网信息的整合起到了重要作用。
摘要：为了能够为电网中各系统间海量数据的挖掘、分析、交互、共享提供数据服务平台, 提出了对数据通信接入格式、数据存储以及相关服务接口标准化的海量实时数据服务平台。在分类分析现有控制、监视和管理系统中实时数据信息的基础上, 研究并设计了统一的实时数据接入格式, 并且详细描述分析了服务平台相关的设计方案。
关键词：实时数据,服务平台,数据接入,通信协议
参考文献
[1]丁鹏, 何云良, 陈国平, 等.金华电网基于IEC61970标准的SCADA/PAS一体化集成[J].浙江电力, 2005, 22 (1) :18-21.
[2]王晓波, 樊纪元.电力调度中心统一数据平台的设计[J].电力系统自动化, 2006, 30 (22) :89-92.
[3]孙宏斌, 李鹏, 李矛, 等.中国南方电网在线分布式建模系统研究与设计[J].电力系统自动化, 2007, 31 (10) :1-6.
[4]潘毅, 周京阳, 吴杏平, 等.基于电力系统公共信息模型的互操作试验[J].电网技术, 2003, 27 (10) :25-28.
[5]丁银, 丁明, 毕锐, 等.微电网系统CIM/XML模型研究[J].电力系统保护与控制, 2010, 38 (9) :37-41.
[6]李丹, 韩福坤, 郭子明, 等.华北电网广域实时动态监测系统[J].电网技术, 2004, 28 (23) :52-56.
海量实时数据 篇2
海量的数据处理问题，对其进行处理是一项艰巨而复杂的任务。原因有以下几个方面：
一、数据量过大，数据中什么情况都可能存在。如果说有10条数据，那么大不了每条去逐一检查，人为处理，如果有上百条数据，也可以考虑，如果数据上到千万级别，甚至过亿，那不是手工能解决的了，必须通过工具或者程序进行处理，尤其海量的数据中，什么情况都可能存在，例如，数据中某处格式出了问题，尤其在程序处理时，前面还能正常处理，突然到了某个地方问题出现了，程序终止了。
二、软硬件要求高，系统资源占用率高。对海量的数据进行处理，除了好的方法，最重要的就是合理使用工具，合理分配系统资源。一般情况，如果处理的数据过TB级，小型机是要考虑的，普通的机子如果有好的方法可以考虑，不过也必须加大CPU和内存，就象面对着千军万马，光有勇气没有一兵一卒是很难取胜的。
三、要求很高的处理方法和技巧。这也是本文的写作目的所在，好的处理方法是一位工程师长期工作经验的积累，也是个人的经验的总结。没有通用的处理方法，但有通用的原理和规则。那么处理海量数据有哪些经验和技巧呢，我把我所知道的罗列一下，以供大家参考：
一、选用优秀的数据库工具现在的数据库工具厂家比较多，对海量数据的处理对所使用的数据库工具要求比较高，一般使用Oracle或者DB2，微软公司最近发布的SQL Server 2005性能也不错。另外在BI领域：数据库，数据仓库，多维数据库，数据挖掘等相关工具也要进行选择，象好的ETL工具和好的OLAP工具都十分必要，例如Informatic，Eassbase等。笔者在实际数据分析项目中，对每天6000万条的日志数据进行处理，使用SQL Server 2000需要花费6小时，而使用SQL Server 2005则只需要花费3小时。
二、编写优良的程序代码处理数据离不开优秀的程序代码，尤其在进行复杂数据处理时，必须使用程序。好的程序代码对数据的处理至关重要，这不仅仅是数据处理准确度的问题，更是数据处理效率的问题。良好的程序代码应该包含好的算法，包含好的处理流程，包含好的效率，包含好的异常处理机制等。
三、对海量数据进行分区操作对海量数据进行分区操作十分必要，例如针对按年份存取的数据，我们可以按年进行分区，不同的数据库有不同的分区方式，不过处理机制大体相同。例如SQL Server的数据库分区是将不同的数据存于不同的文件组下，而不同的文件组存于不同的磁盘分区下，这样将数据分散开，减小磁盘I/O，减小了系统负荷，而且还可以将日志，索引等放于不同的分区下。
四、建立广泛的索引对海量的数据处理，对大表建立索引是必行的，建立索引要考虑到具体情况，例如针对大表的分组、排序等字段，都要建立相应索引，一般还可以建立复合索引，对经常插入的表则建立索引时要小心，笔者在处理数据时，曾经在一个ETL流程中，当插入表时，首先删除索引，然后插入完毕，建立索引，并实施聚合操作，聚合完成后，再次插入前还是删除索引，所以索引要用到好的时机，索引的填充因子和聚集、非聚集索引都要考虑。
五、建立缓存机制当数据量增加时，一般的处理工具都要考虑到缓存问题。缓存大小设置的好差也关系到数据处理的成败，例如，笔者在处理2亿条数据聚合操作时，缓存设置为100000条/Buffer，这对于这个级别的数据量是可行的。
六、加大虚拟内存如果系统资源有限，内存提示不足，则可以靠增加虚拟内存来解决。笔者在实际项目中曾经遇到针对18亿条的数据进行处理，内存为1GB，1个P4 2.4G的CPU，对这么大的数据量进行聚合操作是有问题的，提示内存不足，那么采用了加大虚拟内存的方法来解决，在6块磁盘分区上分别建立了6个4096M的磁盘分区，用于虚拟内存，这样虚拟的内存则增加为 4096*6 + 1024 = 25600 M，解决了数据处理中的内存不足问题。
七、分批处理 海量数据处理难因为数据量大，那么解决海量数据处理难的问题其中一个技巧是减少数据量。可以对海量数据分批处理，然后处理后的数据再进行合并操作，这样逐个击破，有利于小数据量的处理，不至于面对大数据量带来的问题，不过这种方法也要因时因势进行，如果不允许拆分数据，还需要另想办法。不过一般的数据按天、按月、按年等存储的，都可以采用先分后合的方法，对数据进行分开处理。
八、使用临时表和中间表数据量增加时，处理中要考虑提前汇总。这样做的目的是化整为零，大表变小表，分块处理完成后，再利用一定的规则进行合并，处理过程中的临时表的使用和中间结果的保存都非常重要，如果对于超海量的数据，大表处理不了，只能拆分为多个小表。如果处理过程中需要多步汇总操作，可按
火龙果整理 uml.org.cn
汇总步骤一步步来，不要一条语句完成，一口气吃掉一个胖子。
九、优化查询SQL语句在对海量数据进行查询处理过程中，查询的SQL语句的性能对查询效率的影响是非常大的，编写高效优良的SQL脚本和存储过程是数据库工作人员的职责，也是检验数据库工作人员水平的一个标准，在对SQL语句的编写过程中，例如减少关联，少用或不用游标，设计好高效的数据库表结构等都十分必要。笔者在工作中试着对1亿行的数据使用游标，运行3个小时没有出结果，这是一定要改用程序处理了。
十、使用文本格式进行处理对一般的数据处理可以使用数据库，如果对复杂的数据处理，必须借助程序，那么在程序操作数据库和程序操作文本之间选择，是一定要选择程序操作文本的，原因为：程序操作文本速度快；对文本进行处理不容易出错；文本的存储不受限制等。例如一般的海量的网络日志都是文本格式或者csv格式（文本格式），对它进行处理牵扯到数据清洗，是要利用程序进行处理的，而不建议导入数据库再做清洗。
十一、定制强大的清洗规则和出错处理机制海量数据中存在着不一致性，极有可能出现某处的瑕疵。例如，同样的数据中的时间字段，有的可能为非标准的时间，出现的原因可能为应用程序的错误，系统的错误等，这是在进行数据处理时，必须制定强大的数据清洗规则和出错处理机制。
十二、建立视图或者物化视图视图中的数据来源于基表，对海量数据的处理，可以将数据按一定的规则分散到各个基表中，查询或处理过程中可以基于视图进行，这样分散了磁盘I/O，正如10根绳子吊着一根柱子和一根吊着一根柱子的区别。
十三、避免使用32位机子（极端情况）目前的计算机很多都是32位的，那么编写的程序对内存的需要便受限制，而很多的海量数据处理是必须大量消耗内存的，这便要求更好性能的机子，其中对位数的限制也十分重要。
十四、考虑操作系统问题海量数据处理过程中，除了对数据库，处理程序等要求比较高以外，对操作系统的要求也放到了重要的位置，一般是必须使用服务器的，而且对系统的安全性和稳定性等要求也比较高。尤其对操作系统自身的缓存机制，临时空间的处理等问题都需要综合考虑。
十五、使用数据仓库和多维数据库存储数据量加大是一定要考虑OLAP的，传统的报表可能5、6个小时出来结果，而基于Cube的查询可能只需要几分钟，因此处理海量数据的利器是OLAP多维分析，即建立数据仓库，建立多维数据集，基于多维数据集进行报表展现和数据挖掘等。
十六、使用采样数据，进行数据挖掘基于海量数据的数据挖掘正在逐步兴起，面对着超海量的数据，一般的挖掘软件或算法往往采用数据抽样的方式进行处理，这样的误差不会很高，大大提高了处理效率和处理的成功率。一般采样时要注意数据的完整性和，防止过大的偏差。笔者曾经对1亿2千万行的表数据进行采样，抽取出400万行，经测试软件测试处理的误差为千分之五，客户可以接受。还有一些方法，需要在不同的情况和场合下运用，例如使用代理键等操作，这样的好处是加快了聚合时间，因为对数值型的聚合比对字符型的聚合快得多。类似的情况需要针对不同的需求进行处理。海量数据是发展趋势，对数据分析和挖掘也越来越重要，从海量数据中提取有用信息重要而紧迫，这便要求处理要准确，精度要高，而且处理时间要短，得到有价值信息要快，所以，对海量数据的研究很有前途，也很值得进行广泛深入的研究。
一般来说第7种方案是最常用的，有的主要就是使用第7种方案，选择的余地也非常的大，不只是俺月，日，年，也可以按周等等划分，灵活性较高
而面对大量数据的处理一般都是分批次处理，之前我做一个文本分类器，面对1g多的索引（索引1g多，但是分类时需要的数据就大得多了），40-50分钟就可以跑完所有分类：
一是分批操作。
二是给jvm回收内存的时间，比如每次20w的数据进行分类，完成之后睡眠一段时间，每睡眠一端时间就手动gc一次。
火龙果整理 uml.org.cn
通过这些方式取得了很明显得见效。
海量数据处理专题
（一）大数据量的问题是很多面试笔试中经常出现的问题，比如baidu google 腾讯 这样的一些涉及到海量数据的公司经常会问到。
下面的方法是我对海量数据的处理方法进行了一个一般性的总结，当然这些方法可能并不能完全覆盖所有的问题，但是这样的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目，方法不一定最优，如果你有更好的处理方法，欢迎与我讨论。
本贴从解决这类问题的方法入手，开辟一系列专题来解决海量数据问题。拟包含 以下几个方面。
1.Bloom Filter 2.Hash 3.Bit-Map 4.堆(Heap)5.双层桶划分 6.数据库索引
7.倒排索引（Inverted Index）8.外排序 9.Trie树 10.MapReduce
在这些解决方案之上，再借助一定的例子来剖析海量数据处理问题的解决方案。欢迎大家关注。
海量数据处理专题
（二）【什么是Bloom Filter】
Bloom Filter是一种空间效率很高的随机数据结构，它利用位数组很简洁地表示一个集合，并能判断一个元素是否属于这个集合。Bloom Filter的这种高效是有一定代价的：在判断一个元素是否属于某个集合时，有可能会把不属于这个集合的元素误认为属于这个集合（false positive）。因此，Bloom Filter不适合那些“零错误”的应用场合。而在能容忍低错误率的应用场合下，Bloom Filter通过极少的错误换取了存储空间的极大节省。这里有一篇关于Bloom Filter的详细介绍，不太懂的博友可以看看。
【适用范围】
可以用来实现数据字典，进行数据的判重，或者集合求交集
【基本原理及要点】
火龙果整理 uml.org.cn
对于原理来说很简单，位数组+k个独立hash函数。将hash函数对应的值的位数组置1，查找时如果发现所有hash函数对应位都是1说明存在，很明显这 个过程并不保证查找的结果是100%正确的。同时也不支持删除一个已经插入的关键字，因为该关键字对应的位会牵动到其他的关键字。所以一个简单的改进就是 counting Bloom filter，用一个counter数组代替位数组，就可以支持删除了。
还有一个比较重要的问题，如 何根据输入元素个数n，确定位数组m的大小及hash函数个数。当hash函数个数k=(ln2)*(m/n)时错误率最小。在错误率不大于E的情况 下，m至少要等于n*lg(1/E)才能表示任意n个元素的集合。但m还应该更大些，因为还要保证bit数组里至少一半为0，则m应 该>=nlg(1/E)*lge 大概就是nlg(1/E)1.44倍(lg表示以2为底的对数)。
举个例子我们假设错误率为0.01，则此时m应大概是n的13倍。这样k大概是8个。
注意这里m与n的单位不同，m是bit为单位，而n则是以元素个数为单位(准确的说是不同元素的个数)。通常单个元素的长度都是有很多bit的。所以使用bloom filter内存上通常都是节省的。
【扩展】
Bloom filter将集合中的元素映射到位数组中，用k（k为哈希函数个数）个映射位是否全1表示元素在不在这个集合中。Counting bloom filter（CBF）将位数组中的每一位扩展为一个counter，从而支持了元素的删除操作。Spectral Bloom Filter（SBF）将其与集合元素的出现次数关联。SBF采用counter中的最小值来近似表示元素的出现频率。
【问题实例】
给你A,B两个文件，各存放50亿条URL，每条URL占用64字节，内存限制是4G，让你找出A,B文件共同的URL。如果是三个乃至n个文件呢？
根据这个问题我们来计算下内存的占用，4G=2^32大概是40亿*8大概是340亿，n=50亿，如果按出错率0.01算需要的大概是650亿个 bit。现在可用的是340亿，相差并不多，这样可能会使出错率上升些。另外如果这些urlip是一一对应的，就可以转换成ip，则大大简单了。
海量数据处理专题
（三）什么是Hash
Hash，一般翻译做“散列”，也有直接音译为“哈希”的，就是把任意长度的输入（又叫做预映射，pre-image），通过散列算法，变换成固定长度的输出，该输出就是散列值。这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，而不可能从散列值来唯一的确定输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。
火龙果整理 uml.org.cn
HASH主要用于信息安全领域中加密算法，它把一些不同长度的信息转化成杂乱的128位的编码,这些编码值叫做HASH值.也可以说，hash就是找到一种数据内容和数据存放地址之间的映射关系。数组的特点是：寻址容易，插入和删除困难；而链表的特点是：寻址困难，插入和删除容易。那么我们能不能综合两者的特性，做出一种寻址容易，插入删除也容易的数据结构？答案是肯定的，这就是我们要提起的哈希表，哈希表有多种不同的实现方法，我接下来解释的是最常用的一种方法——拉链法，我们可以理解为“链表的数组”，如图：
左边很明显是个数组，数组的每个成员包括一个指针，指向一个链表的头，当然这个链表可能为空，也可能元素很多。我们根据元素的一些特征把元素分配到不同的链表中去，也是根据这些特征，找到正确的链表，再从链表中找出这个元素。
元素特征转变为数组下标的方法就是散列法。散列法当然不止一种，下面列出三种比较常用的。1，除法散列法
最直观的一种，上图使用的就是这种散列法，公式：
index = value % 16
学过汇编的都知道，求模数其实是通过一个除法运算得到的，所以叫“除法散列法”。
2，平方散列法
求index是非常频繁的操作，而乘法的运算要比除法来得省时（对现在的CPU来说，估计我们感觉不出
火龙果整理 uml.org.cn
来），所以我们考虑把除法换成乘法和一个位移操作。公式：
index =(value * value)>> 28
如果数值分配比较均匀的话这种方法能得到不错的结果，但我上面画的那个图的各个元素的值算出来的index都是0——非常失败。也许你还有个问题，value如果很大，value * value不会溢出吗？答案是会的，但我们这个乘法不关心溢出，因为我们根本不是为了获取相乘结果，而是为了获取index。
3，斐波那契（Fibonacci）散列法
平方散列法的缺点是显而易见的，所以我们能不能找出一个理想的乘数，而不是拿value本身当作乘数呢？答案是肯定的。
1，对于16位整数而言，这个乘数是40503 2，对于32位整数而言，这个乘数是2654435769
3，对于64位整数而言，这个乘数是***98485
这几个“理想乘数”是如何得出来的呢？这跟一个法则有关，叫黄金分割法则，而描述黄金分割法则的最经典表达式无疑就是著名的斐波那契数列，如果你还有兴趣，就到网上查找一下“斐波那契数列”等关键字，我数学水平有限，不知道怎么描述清楚为什么，另外斐波那契数列的值居然和太阳系八大行星的轨道半径的比例出奇吻合，很神奇，对么？
对我们常见的32位整数而言，公式：
i ndex =(value * 2654435769)>> 28
如果用这种斐波那契散列法的话，那我上面的图就变成这样了：
很明显，用斐波那契散列法调整之后要比原来的取摸散列法好很多。
火龙果整理 uml.org.cn
【适用范围】
快速查找，删除的基本数据结构，通常需要总数据量可以放入内存。【基本原理及要点】
hash函数选择，针对字符串，整数，排列，具体相应的hash方法。
碰撞处理，一种是open hashing，也称为拉链法；另一种就是closed hashing，也称开地址法，opened addressing。
【扩展】
d-left hashing中的d是多个的意思，我们先简化这个问题，看一看2-left hashing。2-left hashing指的是将一个哈希表分成长度相等的两半，分别叫做T1和T2，给T1和T2分别配备一个哈希函数，h1和h2。在存储一个新的key时，同 时用两个哈希函数进行计算，得出两个地址h1[key]和h2[key]。这时需要检查T1中的h1[key]位置和T2中的h2[key]位置，哪一个 位置已经存储的（有碰撞的）key比较多，然后将新key存储在负载少的位置。如果两边一样多，比如两个位置都为空或者都存储了一个key，就把新key 存储在左边的T1子表中，2-left也由此而来。在查找一个key时，必须进行两次hash，同时查找两个位置。
【问题实例】
1).海量日志数据，提取出某日访问百度次数最多的那个IP。
IP的数目还是有限的，最多2^32个，所以可以考虑使用hash将ip直接存入内存，然后进行统计。
海量数据处理专题
（四）【什么是Bit-map】
所谓的Bit-map就是用一个bit位来标记某个元素对应的Value，而Key即是该元素。由于采用了Bit为单位来存储数据，因此在存储空间方面，可以大大节省。
如果说了这么多还没明白什么是Bit-map，那么我们来看一个具体的例子，假设我们要对0-7内的5个元素(4,7,2,5,3)排序（这里假设这些元素没有重复）。那么我们就可以采用Bit-map的方法来达到排序的目的。要表示8个数，我们就只需要8个Bit（1Bytes），首先我们开辟1Byte 的空间，将这些空间的所有Bit位都置为0(如下图：)
火龙果整理 uml.org.cn
然后遍历这5个元素，首先第一个元素是4，那么就把4对应的位置为1（可以这样操作 p+(i/8)|(0x01<<(i%8))当然了这里的操作涉及到Big-ending和Little-ending的情况，这里默认为Big-ending）,因为是从零开始的，所以要把第五位置为一（如下图）：
然后再处理第二个元素7，将第八位置为1,，接着再处理第三个元素，一直到最后处理完所有的元素，将相应的位置为1，这时候的内存的Bit位的状态如下：
然后我们现在遍历一遍Bit区域，将该位是一的位的编号输出（2，3，4，5，7），这样就达到了排序的目的。下面的代码给出了一个BitMap的用法：排序。//定义每个Byte中有8个Bit位 #include ＜memory.h＞ #define BYTESIZE 8 void SetBit(char *p, int posi){
}
void BitMapSortDemo(){
//BufferLen这个值是根据待排序的数据中最大值确定的 //待排序中的最大值是14，因此只需要2个Bytes(16个Bit)//为了简单起见，我们不考虑负数 int num[] = {3,5,2,10,6,12,8,14,9};*p = *p|(0x01＜＜(posi%BYTESIZE));//将该Bit位赋值1 return;for(int i=0;i ＜(posi/BYTESIZE);i++){ } p++;
火龙果整理 uml.org.cn
} //就可以了。
const int BufferLen = 2;char *pBuffer = new char[BufferLen];//要将所有的Bit位置为0，否则结果不可预知。memset(pBuffer,0,BufferLen);for(int i=0;i＜9;i++){
} //首先将相应Bit位上置为1 SetBit(pBuffer,num[i]);//输出排序结果
for(int i=0;i＜BufferLen;i++)//每次处理一个字节(Byte){
} for(int j=0;j＜BYTESIZE;j++)//处理该字节中的每个Bit位 {
} pBuffer++;
//判断该位上是否是1，进行输出，这里的判断比较笨。//首先得到该第j位的掩码（0x01＜＜j），将内存区中的 //位和此掩码作与操作。最后判断掩码是否和处理后的 //结果相同
if((*pBuffer&(0x01＜＜j))==(0x01＜＜j)){ }
printf(“%d ”,i*BYTESIZE + j);int _tmain(int argc, _TCHAR* argv[]){
} 【适用范围】 BitMapSortDemo();return 0;
火龙果整理 uml.org.cn
可进行数据的快速查找，判重，删除，一般来说数据范围是int的10倍以下 【基本原理及要点】
使用bit数组来表示某些元素是否存在，比如8位电话号码 【扩展】
Bloom filter可以看做是对bit-map的扩展 【问题实例】
1)已知某个文件内包含一些电话号码，每个号码为8位数字，统计不同号码的个数。
8位最多99 999 999，大概需要99m个bit，大概10几m字节的内存即可。（可以理解为从0-99 999 999的数字，每个数字对应一个Bit位，所以只需要99M个Bit==1.2MBytes，这样，就用了小小的1.2M左右的内存表示了所有的8位数的电话）
2)2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数。
将bit-map扩展一下，用2bit表示一个数即可，0表示未出现，1表示出现一次，2表示出现2次及以上，在遍历这些数的时候，如果对应位置的值是0，则将其置为1；如果是1，将其置为2；如果是2，则保持不变。或者我们不用2bit来进行表示，我们用两个bit-map即可模拟实现这个 2bit-map，都是一样的道理。
海量数据处理专题
（五）【什么是堆】
概念：堆是一种特殊的二叉树，具备以下两种性质
1）每个节点的值都大于（或者都小于，称为最小堆）其子节点的值
2）树是完全平衡的，并且最后一层的树叶都在最左边
这样就定义了一个最大堆。如下图用一个数组来表示堆：
火龙果整理 uml.org.cn
那么下面介绍二叉堆：二叉堆是一种完全二叉树，其任意子树的左右节点（如果有的话）的键值一定比根节点大，上图其实就是一个二叉堆。
你一定发觉了，最小的一个元素就是数组第一个元素，那么二叉堆这种有序队列如何入队呢？看图：
火龙果整理 uml.org.cn
假设要在这个二叉堆里入队一个单元，键值为2，那只需在数组末尾加入这个元素，然后尽可能把这个元素往上挪，直到挪不动，经过了这种复杂度为Ο(logn)的操作，二叉堆还是二叉堆。
那如何出队呢？也不难，看图：
火龙果整理 uml.org.cn
出队一定是出数组的第一个元素，这么来第一个元素以前的位置就成了空位，我们需要把这个空位挪至叶子节点，然后把数组最后一个元素插入这个空位，把这个“空位”尽量往上挪。这种操作的复杂度也是Ο(logn)。
【适用范围】
海量数据前n大，并且n比较小，堆可以放入内存
【基本原理及要点】
最大堆求前n小，最小堆求前n大。方法，比如求前n小，我们比较当前元素与最大堆里的最大元素，如果它小于最大元素，则应该替换那个最大元 素。这样最后得到的n个元素就是最小的n个。适合大数据量，求前n小，n的大小比较小的情况，这样可以扫描一遍即可得到所有的前n元素，效率很高。
【扩展】
双堆，一个最大堆与一个最小堆结合，可以用来维护中位数。
【问题实例】
1)100w个数中找最大的前100个数。
用一个100个元素大小的最小堆即可。
海量数据处理专题
（六）火龙果整理 uml.org.cn
【什么是双层桶】
事实上，与其说双层桶划分是一种数据结构，不如说它是一种算法设计思想。面对一堆大量的数据我们无法处理的时候，我们可以将其分成一个个小的单元，然后根据一定的策略来处理这些小单元，从而达到目的。
【适用范围】
第k大，中位数，不重复或重复的数字
【基本原理及要点】
因为元素范围很大，不能利用直接寻址表，所以通过多次划分，逐步确定范围，然后最后在一个可以接受的范围内进行。可以通过多次缩小，双层只是一个例子，分治才是其根本（只是“只分不治”）。
【扩展】
当有时候需要用一个小范围的数据来构造一个大数据，也是可以利用这种思想，相比之下不同的，只是其中的逆过程。
【问题实例】
1).2.5亿个整数中找出不重复的整数的个数，内存空间不足以容纳这2.5亿个整数。
有点像鸽巢原理，整数个数为2^32,也就是，我们可以将这2^32个数，划分为2^8个区域(比如用单个文件代表一个区域)，然后将数据分离到不同的区域，然后不同的区域在利用bitmap就可以直接解决了。也就是说只要有足够的磁盘空间，就可以很方便的解决。当然这个题也可以用我们前面讲过的BitMap方法解决，正所谓条条大道通罗马~~~ 2).5亿个int找它们的中位数。
这个例子比上面那个更明显。首先我们将int划分为2^16个区域，然后读取数据统计落到各个区域里的数的个数，之后我们根据统计结果就可以判断中位数落到那个区域，同时知道这个区域中的第几大数刚好是中位数。然后第二次扫描我们只统计落在这个区域中的那些数就可以了。
实际上，如果不是int是int64，我们可以经过3次这样的划分即可降低到可以接受的程度。即可以先将int64分成2^24个区域，然后确定区域的第几 大数，在将该区域分成2^20个子区域，然后确定是子区域的第几大数，然后子区域里的数的个数只有2^20，就可以直接利用direct addr table进行统计了。
3).现在有一个0-30000的随机数生成器。请根据这个随机数生成器，设计一个抽奖范围是0-350000彩票中奖号码列表，其中要包含20000个中奖号码。
中国面临海量数据爆发 篇3
John R. Talburt教授是国际信息与质量协会技术顾问委员会成员。该组织是信息与数据研究领域唯一专业国际组织。Talburt教授认为，中国正面临海量数据爆发，信息与数据质量优化将成企业竞争力。
在西安交大与安客诚的IQ/DQ最佳实践论坛中，Talburt教授不但与安客诚大中华区业务发展副总裁孔宇先生一起深度剖析如何管理与优化信息、提高数据质量以及减少运营风险的实践经验。论坛特邀中国邮政集团数据管理处处长赵岫枫女士介绍了中国邮政邮编地址的数据质量提升服务，并针对数据管理与优化的主题与参会者做深度分享。
Gomez中国门户 2.0版
Compuware总裁兼首席运营官（CEO）Bob Paul在发布会上做主题演讲.jpg
日前，专注于从事技术性能服务,全球领先的应用性能管理(APM)供应商Compuware公司(Compuware Corporation,NASDAQ:CPWR)宣布推出针对中国市场的统一应用性能管理解决方案——Compuware Gomez中国门户 2.0版。该新版本由经验丰富的中国研发团队开发，使中国用户能够用本地语言访问业界独一无二的“First Mile”（数据中心）到 “Last Mile”（终端用户）APM 解决方案，为中国用户提供全面的终端用户性能的全球化视图。
近年来，随着中国APM市场的不断增长，中国已经成为Compuware全球APM市场重要地区之一，Compuware也对中国市场寄予了很高重视。Compuware总裁兼首席运营官（CEO）Bob Paul先生、Compuware 亚洲与印度区副总裁Nick Evered先生、Compuware APM业务部首席技术官Steve Tack先生、Compuware APM 中国区研发和运营副总裁李启蓉女士、Compuware大中华区解决方案销售总监李翔以及网宿科技股份有限公司（ChinaNetCenter）行政副总裁刘洪涛先生等公司高层共同出席了此次发布会，向与会者们介绍了Compuware Gomez产品业界领先的技术亮点，分享了Compuware Gomez产品带给中国企业的核心价值，并与现场用户和媒体展开深入交流。
云客户端计算革新梦想 迎接IT消费化时代到来
迎接IT消费化时代到来
Gartner于2005年提出的“IT消费化”预测已变成现实。所谓“IT消费化”，即是信息技术的消费化，它的产生来源于个人科技消费商用化而产生的对科技产品及服务的新一代需求；是消费技术浪潮深入企业的产物。在商业世界中，企业要求随时获得速度、质量、安全及灵活的技术支持，而云、虚拟化和移动设备正在使这种需求成为可能。最新IDC调查也显示，IT消费化是信息技术改变人类工作与生活方式的最新体现。现如今，在后PC时代，IT消费者化概念变得愈加的火热。每个人都会感受到它的影响力，而IT界更是必须找到支持IT消费者化的方式，来留住雇员并保持企业的生产力。
作为全球云客户端计算解决方案的领先供应商，美国Wyse Technology公司坚信，在IT界中，存在可支持IT消费化的强大方式，同时可保证安全、降低成本，并为生产提供更多额外的选择。我们也看到，虚拟化已经超越过去的部门和业务组，在整个企业的范围内实现IT消费化。此次，我们邀请到Wyse首席市场策略官兼首席客户律师Jeff McNaught先生为我们详尽讲解IT消费化的趋势及其提供给我们的选择。而Wyse Technology公司的云客户端计算解决方案为业界提供了一种理想的选择，可以在易用性、安全性以及管理性等多个方面进行提升。
与此同时，Wyse Technology不断评估不同地域市场的客户需求，并寻求新合作伙伴。在此次的活动中，Wyse Technology也宣布与神州数码公司展开合作，选定该公司作为中国区总代理。这也是Wyse Technology兑现其通过新的产品、解决方案和服务推动中国IT行业向前发展的承诺。
海量实时数据 篇4
随着社会的信息化发展，很多部门逐渐建立起各自的业务信息系统，但由于各业务系统建立时间和提供商不同，也导致各种数据的存在形式、来源和记录格式也各不相同，这对各部门、各系统之间实现数据共享带来不便。同时，随着社会高速发展，各企业部门对数据的“实时性”需求也越来越高，因为数据实时性越高，便更有利于企业部门高层作出更及时、更准确的决策。特别对于那些目前仍然主要采用以“文件形式”记录数据的部门来说，将具有多种来源途径和记录格式的文件型数据实时处理、集成，并最终建立统一、透明的“综合数据实时共享平台”，为企业或部门的高端决策提供实时数据支持，已是迫在眉睫。
以“文件形式”记录的数据在存储、提取、使用效率以及统计查询等方面仍存在较多不便。首先各类数据的“多源”存储，给数据文件的获取带来不便，同时也较不稳定;其次，各类数据的“记录格式”不统一，也不利于数据信息的提取;再者，数据的“文件型”记录，造成数据的“多次使用必须多次提取”，特别是对于部分数据在抽取完成后需要进一步处理加工过程时，就很大地影响了数据的使用效率，也加重了系统的负荷;最后，随着各类数据文件的日积月累，一方面容易造成文件的丢失，另一方面也不方便数据的管理和历史信息的查询统计。
针对目前数据文件在这些方面的不足，本文设计并实现了“多源异构海量数据实时处理平台”，该平台能实时从多种数据路径获取并处理多种数据文件，并按照各数据记录格式实时提取并将处理完的数据保存到数据库，不仅克服了文件型数据在保存、使用效率和统计查询等方面的不足，而且实现了各业务系统之间“多源异构数据”的实时共享。同时，将各类数据都统一保存到数据库后，对其他基于数据库开发的信息系统的开发与发展具有很大的意义[1]。
1 系统分析
1.1 系统数据源分析
目前各企业部门业务系统的数据来源途径主要有四种:远程FTP服务器、局域网数据服务器、局域网数据库服务器和本地数据服务器[2]。
(1)远程FTP服务器:系统平台通过互联网连接一台或多台FTP服务器，文件更新频率可能各不一样，对服务器存储的文件有下载权限。
(2)局域网远程数据服务器:在局域网内部，但物理距离较远，建立多台远程数据服务器实现数据共享，主要用作存储各种类型的文件型数据，各文件更新频率不定。
(3)局域网数据库服务器:在局域网内部，有部分数据经过其他系统处理，将处理完的产品数据保存到局域网的数据库服务器，通过权限设置为其他主机提供数据共享。
(4)本地服务器:本地服务器主要存放一些本地的数据文件。
系统数据源总体架构如图1所示。
1.2 系统设计目标
建立“多源异构海量数据实时处理平台”在功能上主要包括以下目标:
(1)系统具有基本的参数设置功能。主要是对各种数据存放位置的设置，比如:设置数据路径、FTP站点、必要信息的增删改查等。
(2)系统能够实时监测各类数据，对于最新更新的数据文件，能够实时获取并处理，并且最终保存到数据库中，同时能够通知其他系统实时使用最新数据。
(3)系统能够完成必要的数据保存、备份以及其他的各种维护功能。
(4)该系统能够24小时不间断运行于服务器端，必须保证数据的实时性、准确性以及系统的稳定性。
(5)基于软件设计的基本宗旨，该系统应具有良好的可扩展性。
2 系统设计
2.1 系统框架
根据本系统大的设计要求和目标，系统总体框架主要分为实时监测模块、实时处理模块和实时保存模块。
实时监测模块主要功能是对所有数据源上的数据文件进行实时监测，当有新增文件或者有文件内容发生变动时，能够实时获取该文件，然后交予实时处理模块处理。
实时处理模块主要功能是实时处理由实时监测模块监测到的新增或者内容发生变动的文件。该模块主要包括文件判断和文件处理两个功能，文件判断主要是用于判断实时监测到的文件是否为需要处理的文件，而文件处理主要包括数据抽取和数据加工。具体处理细节按照各种数据文件的要求不同。
实时保存模块主要是将实时处理完成后的数据保存到数据库中，并且在数据库中形成相应记录以通知其他系统的实时使用最新数据[3,4]。
此外，系统还包括了数据备份、数据清理等一系列必要的数据库维护功能。为了数据的安全，数据备份是必不能少的。本系统处理的数据种类较多，而且各种数据的使用情况各不相同，其中，有些数据需要永久保存，而有些数据只是用作最近时段的实时展示，有效时限较短但占用资源又较大，所以不需要永久保存，对这些数据则需要系统定时清理。同时对于一些存放临时数据的中间表，也需要系统定时清理。
2.2 系统功能设计
系统主要功能包括实时监测、实时处理和实时保存等三大模块。
1)实时监测
系统的实时监测模块主要分为两种方式:“定时扫描”和“实时监测”。主要是根据数据的存储位置和数据文件的特征采用不同方式。
对于远程FTP数据文件实时监测主要是采用“定时扫描”的方式，即指每隔指定时间后对所有文件进行一次扫描，以发现这段时间内是否有新增文件或文件发生变化。对于远程FTP服务器无法使用实时监测路径方法，系统主要结合FTP文件更新频率设置系统定时扫描频率。对于具有固定文件更新频率(即每隔固定时间更新一次文件)的FTP服务器，系统主要按照文件的更新频率设置系统扫描频率。而对于没有固定文件更新频率的FTP服务器，系统扫描频率主要根据实时性要求和系统与FTP服务器负荷而定。系统扫描频率越高，对系统与FTP服务器负荷就越大，所以在保证系统和FTP服务器正常运行的前提下，实时性要求越高，扫描频率就越高，反之相反[5]。
对于局域网远程数据服务器，可以在本系统平台建立映射盘，类似访问本地磁盘一般访问该远程数据服务器中的数据，所以对于该种存储方式的数据可以像监测本地文件一样使用“实时路径监测”，.NET已经提供了该类方法的实现，即当某路径有新增文件或者有文件发生修改时都能得到该文件的具体信息。同时，该方法的实时性较高。
对于本地服务器，也可采用“实时路径监测”方法对文件路径进行实时监测。
对于局域网数据库服务器，主要有两种方法:“定时扫描”和“使用触发器”。“定时扫描”主要和前文相似，每隔指定时间检查目标数据库是否有数据更新。“使用触发器”主要是结合数据库的触发器技术，对目标数据库设置触发器，当目标数据发生更新时，实时通知本系统数据库，对更新的目标数据进行处理。
2)实时处理
实时处理模块作为本系统一个核心模块，主要是处理实时监测模块监测到的最新实时文件。该模块主要包括文件判断和文件处理两个功能。
(1)文件判断:采用实时监测方法监测的是某一个路径下的所有内容，但是并非该路径下的所有文件都是所需要处理的文件，所以根据实际需求，对监测到的文件还需要判断该文件是否为所需文件，判断依据主要依数据实际需求而定。
(2)文件处理:当文件判断确定为所需数据文件后，就将对该文件进行处理。其中，文件处理主要包括数据抽取、数据加工等过程[6,7]。
a)数据抽取:按照各自的文件格式将所需的信息抽取出来。系统处理的大部分文件主要是文本数据格式，对该类数据文件只要进行简单的数据读取就可以[8]。但同时还有一些数据文件可能还使用了加密技术，所以在数据抽取之前还需要按其加密格式对其进行解码，再处理为所需的数据[9]。
b)数据处理:根据各种数据需求不同，处理的需求也不同，目前主要分为以下几种处理方式:数据提取、数值计算和数据统计等，而对于具有时空特性的一些数据，除以上几种方式外，可能还有:插值、生成等值线/等值面、平滑和图层叠加等，最终生成具有时空特性的空间GIS数据[10]。总之，对于各种数据，各自的读取格式、数据计算要求以及最终生成的产品数据形式也各不相同[11]。
3)实时存储
实时存储模块主要是将实时处理模块处理完成后的数据保存到数据库中，同时在数据库中形成相应记录以方便其他系统的实时使用最新数据[12]。其中，因处理完后的数据形式不同，数据存放形式也有所不同，在本平台中，数据库分为关系型数据库和空间数据库[4]，对于一些简单的数据主要存储在关系型数据库的表中;而对一些具有时空特性的空间GIS数据主要存放在空间数据库中[13]，比如各种色斑图和等值线/等值面数据等。
3 关键技术
3.1 数据实时处理模型
本系统根据目前数据存在的特点:存储在不同位置或者多种路径、数据格式各不相同、数据文件量增长更新速度较快等，针对因此带来的较多不便，比如因数据文件增长更新速度较快而导致数据文件越来越多，不便于保存，也不利于历史数据的统计与查询，更重要的是，很多数据文件还不能被实时处理和利用。
为此，本系统提出了一种“多源异构海量数据的实时处理模型”，主要包括三层架构:实时监测层、实时处理层和实时存储层。其中，“实时监测层”利用多种监测方法完成对多源数据的实时监测;“实时处理层”完成对“异构”且“海量”数据的实时处理;“实时存储层”完成对产品数据的保存和数据的实时被利用，同时也方便以后历史数据的计算和统计等。由此得出，本模型能够较好解决目前多源异构海量数据在保存和实时处理方面存在的诸多不便，有效提高数据的实时利用效率[5]。
系统三层模型架构图如图2所示。
3.2 数据并行处理
分析系统数据处理需求如下:
1)系统实时监测多种路径的“海量”数据，经常会出现同时有多个文件已经更新。
2)系统处理数据的“实时”需求，需要对每一个实时更新的数据进行实时处理。
再结合各种文件处理复杂度各不一样，有的文件处理较为复杂，耗时较长，所以会出现前一批数据还没处理完，后一批实时数据已经到达，导致系统来不及处理，因此不能满足系统的“实时”要求。
因此，系统采用“多线程”技术，为每一个实时更新的数据创建一个线程进行处理，最终实现并行实时处理海量数据文件[14]。但根据实际监测情况，会出现“很短的时间内有大量文件更新”的情况，且数据处理较为复杂，占用系统资源较大，一段时间内给系统带来较大负荷，因此系统制定如下“并行处理策略”:
1)设置系统最多同时并行处理指定数量的数据文件。具体数量由系统能承担的负荷和实际文件更新频率而定。
2)制定文件“处理优先级”。其中，根据客户对各数据的实时需求，实时需求较高的“处理优先级”较高，反之，实时需求较低的“处理优先级”也较低。
3)对于同一“处理优先级”的多个数据文件，根据文件的更新时间，优先处理较早更新的数据文件。
按照此策略，既能够有效缓解系统在文件更新高峰期时的负荷，同时又能够满足数据处理的“实时”需求。
4 应用实例
4.1 气象应用实例
通过以上对多源异构海量数据实时处理平台的设计，最终实现了基于Super Map的“多源异构海量气象数据实时处理平台”系统，并且已经实际应用在上海市嘉定区气象局日常业务中。
系统能够24小时实时监测多个路径，包括:一台远程FTP服务器、多台局域网远程数据服务器和多台本地数据服务器，对于实时监测的海量气象数据文件实时处理，对每一种格式的数据，按照各自的记录格式进行解码或者数据提取，再按照实际数据需求进行处理，并最终实时保存到各自数据库中。
系统框架图如图3所示。
该系统主要工作在于后台实时监测数据和处理数据，前台展示较少，图4为系统实时处理数据的记录首页。
同时，该系统主要处理的数据文件基本是以文本格式记录，用数值记录各格点的气象要素信息，不能直观地看出总体数值的空间分布和变化。该系统主要结合各样点数据空间分布和待创建表面的类型等特征，对每种特征的数据应用适当的插值方法进行处理，将文本型数据转换为具有时空特性的空间GIS数据[15]。本系统实现的插值方法主要有:距离反比权重插值、普通克吕金插值和样条插值。对于空间呈均匀分布且密集程度能够反映局部差异的样点数据集，比如Micaps的第四类格点数据，主要采用“距离反比权重插值方法”;对于插值字段值的期望(平均值)未知且恒定，数据变化成正态分布的数据，比如系统中的自动站各气象要素数据，主要采用“普通克吕金插值”[16];而对数据呈不均匀分布但输入点较多且较为密集的气象数据，如No Caws的自动站数据和Micaps的第一类地面全要素填图数据和第二类高空全要素填图数据，主要采用“样条插值方法”[17]。通过多种插值算法，最终生成等值线或者等值面等空间数据集[18]。
如图5所示，图的上部为自动站分钟数据，其中包括温度、风、雨量的各种气象要素信息数据，图的下部为将其中的“温度”要素经过“数值提取插值平滑”后生成的等值面数据集。
4.2 运行环境
目前，系统正在以下运行环境上运行:
硬件设备如表1所示。
支持软件如表2所示。
系统在长时间的试运行过程中较为稳定，且能够很好解决目前上海市嘉定区气象局业务所需的气象数据文件处理。
5 结语
本文针对目前各业务系统数据文件的“多源、异构、海量”等特点，结合对“实时性”的需求，设计了一种对“多源异构海量数据实时处理模型”，能够实时监测以多种形式存放在多种路径的海量数据，对所需数据文件能够及时响应，实时并行处理具有多种结构的海量数据文件，最后将处理完的数据实时保存到各自数据库中，确保数据能够实时被使用。同时，系统在数据处理过程中，结合各种数据的空间分布等特征，采用各种适当的插值算法，将文本记录的数据转换成更加直观的具有时空特性的空间数据，使数据得到更好的展示。
海量数据来袭 CIO无须紧张 篇5
围绕数据分析工作，市面上出现了众多相关技术，帮助企业管理和分析多种多样的庞大数据集。在这个高级分析技术的领域，由于IT服务产品的价格持续下降，用户可以用更少的IT预算来获取完善的服务、进行更多的信息分析，解决更复杂的问题。
随着分析技术的飞速发展和商业智能手段的日益高明，CIO现在完全可以做到大规模、低成本地分析业务数据。这也意味着，企业可以充分利用一切可利用的机会，获取更高的商业价值。
勇于接受海量数据
大数据是指庞大的数据集，尤其是那些未经组织、管理以适合传统数据仓库的数据集。虽然不是每一家公司都需要掌握处理庞大非结构化数据集的手段，但Verisk Analytics公司的CIO Perry Rotella认为，所有CIO都应该关注大数据分析工具。Verisk公司帮助金融公司评估风险，也帮助保险公司从理赔数据中识破欺诈，它在2010年的营收超过了10亿美元。Verisk公司的业务是“从你事先未知的数据中找到一定的模式和关联。”Rotella表示，企业的IT负责人应持数据越多越好的态度，并勇于接受海量数据。
HMS公司专门帮助客户实施医疗保险和医疗补助计划，同时也为企业控制医疗保健成本，其业务覆盖美国40多个州的卫生和福利计划以及130多个医疗补助管理型医疗保健计划。在2010年，通过避免错误支付，HMS帮助客户追回了18亿美元的成本，省下了数十亿美元的开销。该公司的CIO Cynthia Nustad认为，大数据呈“爆炸式发展”的趋势，“我们在努力获取、跟踪、分析大量资料，包括结构化数据和非结构化数据，尽管有时你可能都不知道自己在数据中到底要寻找什么。”
Hadoop是被谈论最多的大数据技术之一，作为一个开源的分布式数据处理平台，Hadoop最初被用来处理海量网页搜索之类的任务。最近它与另外几种所谓的“NoSQL”技术（包括CouchDB和mONGOdb）大行其道，正以新颖的方式管理大数据。
Hadoop能够处理PB级数据，具体步骤是把海量数据的子集分配给上千台服务器，然后由主调度器核对和整理每一台服务器返回的处理结果。Hadoop既可以用来准备好数据以便分析，本身也可以作为一款分析工具来使用。如果企业没有成千上万台备用服务器，可以向亚马逊等云服务提供商购买服务，根据具体需要访问Hadoop。
Nustad认为Hadoop有助于企业通过分析数据来识破欺诈和浪费现象，或许还可以用于分析多种格式的病人门诊记录。她表示，HMS确实在探究NoSQL技术的用途，但并非用于其庞大的医疗保险和医疗补助理赔数据库，因为这些数据库含有结构化数据，可以用传统的数据仓库技术来处理，而且为了大数据而弃用传统的关系数据库管理方法也不明智。
作为一家比较购物网站，Shopzilla每天积累的数据多达数TB。其CIO Mulkey说：“我们用Hadoop来处理过去用数据仓库来处理的任务，更重要的是，它能让我们做一些以前无法实现的、真正能满足需求的分析工作。”以前，Shopzilla要为数据取样和分类——处理这么多数据，工作量非常大。现在借助Hadoop，Shopzilla就能分析原始数据，跳过中间步骤。
像Rotella和Mulkey这种有Hadoop实践经验的CIO，他们所在的公司甚至会将数据分析服务当做一项业务来出售。
提速
从IT架构改革开始
“分析速度提升将是一个更大的趋势，而大数据技术只是这个趋势当中的一部分。”肯塔基大学的CIO Vince Kellen认为，“我们需要用更高级的技术来分析海量数据，因为我们希望迅速地获得分析结果。所以数据多少不重要，重要的是分析数据的效率。”
虽然几十年来，数据库一直通过缓存那些频繁访问的数据来提高性能，由于从磁盘获取数据在一定程度上是个机械过程，所以速度要比在内存中处理慢很多。现在看来，把庞杂数据全部装入到一台服务器或者多台服务器的内存中要更切实可行，磁盘只用来作备份。
Rotella表示：“现在我可在几秒钟内执行分析任务，而五年前我们需要花整整一个晚上。”他们对庞大数据集进行预测性分析，通常需要经历启动查询、寻找模式、进行调整等环节，然后再启动下一个查询，查询的执行时间对于分析速度影响很大。“原来，我们运行模型比建立模型费时间，而现在建立模型比运行模型更费时间。”
列式数据库服务器把数据库传统的组织方式颠倒过来。查询只访问相关的列，因而为评估几个关键列的应用程序提升了性能。为了提高分析性能，硬件同样很重要。保险和金融服务巨头John Hancock的CIO Allan Hackney已经开始尝试GPU加速的系统。他说：“可视化方面的运算与统计分析方面的运算非常相似，而GPU执行的运算速度比传统的PC和服务器处理器快几百倍。”
开源技术压低成本
从某种程度上说，计算能力的增加得益于内存和存储设备价格的不断下跌，此外有了付费产品之外的选择以及开源软件也迫使厂商降低价格。
Ternent在加入Island One之前是Pentaho开源商业智能公司的技术副总裁，他积极倡导开源技术，“在我看来，开源为公平竞争创造了条件。”
Ternent表示，开源工具一度只适用于基本的报告，而现在，它们提供了最先进的预测分析功能。“现在几乎所有领域都有开源厂商，这意味着谁有胆量用，谁就可以随意使用开源工具。”
HMS的Nustad发现，不断变化的经济因素也在改变着IT架构方面的一些基本选择。比如说，构建数据仓库的一个传统原因是在拥有计算功能的服务器上把数据整合起来。以前计算功能比较稀缺时，CIO会把分析任务从操作系统卸载下来，以免拖累日常任务的性能，现在就没必要这么做了。由于省略了移动数据、格式化以及把数据装入数据仓库的步骤，CIO直接在操作应用上进行分析能更快地获得结果。
不过Hackney表示，虽然现在的趋势正朝着有利于降低管理成本的方向发展，但节省的成本经常被增加的存储容量需求抵消。“这就像在原地跑步。虽然2011年John Hancock的存储成本下降了2%到3%，但存储使用量却增长了20%。”
为员工设计终端界面
对Nustad而言，移动商务是必须的。因为即使出门在外也要查看各种报告，了解公司是否履行了服务级别协议。她还希望让公司的客户可以通过移动设备访问自己数据，帮助他们监控和管理医疗保健开支。“这是一项客户非常喜欢的功能。五年前，客户不会要求提供这项功能，但现在他们对此非常关注。”
对于CIO来说，应对这个趋势的关键不是提供复杂的分析功能，而在于为智能手机、平板电脑和触摸屏设计用户界面。Kellen觉得这问题很容易解决。
但Rotella并不这么认为。“移动计算影响着每个人。使用iPad和其他移动设备办公的人越来越多，这个趋势会让员工使用企业计算资源的方式加速改变。”Rotella说，例如，Verisk开发了一种产品，可以让理赔员在现场访问分析结果，如此一来他们就能估算重置成本。这种方式可以充分利用分析结果，满足那些有需要的人。
技术在迅速变化，这是让CIO最感头疼的事情。Rotella认为，“两年前，我们没有iPad；现在，大家出去都带着iPad。由于移动设备操作系统有很多种，我们要努力了解如何才能最有效地利用自己的开发资源，避免进行重复的开发工作。”
Island One的Ternent表示，由于手机和平板电脑中浏览器的功能越来越强大，为每个移动平台开发原生应用程序的呼声也随之减弱，“如果我只需针对移动设备为基于Web的应用程序更换皮肤，就不一定非要开发定制的应用程序了”。
分析混合型的
社交媒体
随着Facebook、推特等社交媒体遍地开花，越来越多的公司想要分析这些网站的数据。现在，市场上已经出现了新的分析应用软件，包含语言处理、情感分析和网络分析等统计方法，它们已不再属于典型的智能商务“工具包”。
许多社交媒体的分析工具很新颖，常以服务的形式出售。一个突出例子是Radian6，该软件最近被Salesforce.com收入囊中。Radian6提供了一个仪表板，根据推特消息、Facebook公共帖子以及博客和讨论板会话上的帖子和留言，可以列出了提到品牌的各种评价。营销部门和客户服务部门买来这类工具后，基本上不需要麻烦IT部门。
不过，肯塔基州大学的Kellen表示，对于这类工具，他还在观望。他说：“我的任务是，确定这些技术中哪一种适合自己，然后再对相应的人员进行培训。”
与企业一样，肯塔基州大学也对监控其品牌评价很有兴趣。Kellen表示，他也有兴趣开发特定的应用程序，解决学校关注的具体问题，如学生流失等。例如，监控学生在社交媒体上发布的帖子可以帮助教职员工及早了解学生是否在学习上遇到了麻烦。戴尔公司的支持部门也会经常关注推特，以便及早发现是否有消费者发消息称自己的戴尔笔记本电脑坏掉的情况。Kellen表示，IT开发人员应想方设法，把社交媒体分析工具生成的报警机制融入到企业系统中，以便迅速应对那些事件。
Hackney说：“我们缺少挖掘分析社交媒体上大量帖子的工具。一旦你拥有数据，就需要获得相关事件的足够信息，那样才能把它们关联起来。” Hancock已经在这方面刚开始迈出步伐，把社交分析服务提供的数据与企业数据关联起来。例如，如果数据显示中西部用户对公司的评论以负面为主，他就要看看公司是不是改变了在该地区的价格或政策，从而导致这个状况发生。
海量实时数据 篇6
关键词：海量历史/准实时数据管理平台,实时数据,深化应用,一发两收
0 引言
国家电网公司海量历史/准实时数据管理平台是对电力生产运行过程中各业务应用生成的历史/准实时数据进行按需存储、整合、 共享和分析的场所。 2010 年, 国家电网公司启动了 “海量历史/准实时数据管理平台”项目, 接入大部分业务应用准实时数据[1]。 截止2014 年6月, 该平台已接入96个系统的2 807万测点, 同时为54个系统提供数据访问服务。
深化应用建设全面继承海量历史/准实时数据管理平台已有建设成果, 并开展海量历史/准实时数据管理平台完善提升工作。其重点包括完成海量历史/准实时数据管理平台设备模型构建、多通道数据访问、平台数据综合展示、应用开发数据质量检测和审计等业务组件的研发工作, 完成计算服务模块的完善提升工作, 同步开展相关前沿关键技术的研究。
1 深化应用建设内容
1.1 新增基于电网设备的海量历史/准实时数据管理平台设备模型
结合江苏海量历史/准实时数据管理平台对平台设备模型的试点实用化建设成果, 对运行、检修和营销设备进行整合, 以构建基于电网设备的海量历史/准实时数据管理平台设备模型 (如图1 所示) , 形成海量历史/准实时数据管理平台数据字典, 提升业务系统数据访问的便捷性, 满足运检部PMS2.0等业务系统通过设备方式访问及二次加工历史/准实时数据的需求 (如图2 所示) 。 其主要内容包括:
(1) 研究电网设备存储模型、数据源自动同步方式。
(2) 基于设备命名的测点命名方式。
(3) 设备树与测点的自动挂接技术。
(4) 基于设备树的访问方法和计算加工功能。
(5) 基于设备树的测点管理与维护。
(6) 设备信息相关集成接口的开发。
(7) 新增历史/准实时数据多通道访问模式。
1.2 新增历史/准实时数据多通道访问模式
为了满足PMS2.0通过设备全路径名访问, 适应一体化电量与线损管理系统通过设备台账信息访问, 同时支撑其它不同业务系统对历史/准实时数据的多形式数据访问需求, 完成数据混合模式访问模块开发, 提升海量历史/准实时数据管理平台数据访问的便捷性。 其主要内容包括:
(1) 提供基于设备的海量历史/准实时数据管理平台数据访问服务。
(2) 提供基于相关台账信息 (如区域代码、用户号、表计号和功能编码访问用电信息采集数据) 的数据访问服务。
(3) 提供设备全路径名数据访问服务。
(4) 提供基于设备模型的数据访问服务。
(5) 提供其它类型数据访问服务。
1.3提升海量历史/准实时数据管理平台计算能力, 新增平台数据可视化综合展示和应用开发业务组件
基于运监中心 “量价费损”等业务应用对数据二次加工的需求, 提升海量历史/准实时数据管理平台计算能力;新增海量历史/准实时数据管理平台数据可视化综合展示业务组件, 支撑不同层次人员对数据综合展示的需求;基于基层班组个性化创作需求, 新增基于海量历史/准实时数据管理平台的应用开发业务组件, 完成基层班组信息化工作推进。
(1) 提升海量历史/准实时数据管理平台计算能力, 支撑运监中心 “量价费损”等复杂业务应用对历史/准实时数据的电量与负荷计算、区域的电量与负荷计算等二次加工需求, 为构建复杂分析类应用提供工具保障。其主要内容包括:研究基于海量历史/准实时数据管理平台的分布式并行计算框架;开发分布式多节点并行计算模块;开发计算过程统一调度控制模块;开发计算资源池管理模块;开发支持复杂计算的计算过程模块;开发支持二次开发的IDE。
(2) 完成海量历史/准实时数据管理平台数据可视化综合展示业务组件开发, 实现海量历史/准实时数据管理平台海量数据多维度、多形式综合展示, 解决运维中心对平台可视化监控的需求, 适应管理人员对数据可视化综合分析的需求, 满足不同层次人员对数据展示的需求。其主要功能包括:提供数据不同属性 (如区域属性、 设备类型、测点类型、数据源等) 的多维度展示;提供数据多形式 (如表格、饼图、柱状图等) 展示; 提供数据不同属性的数据健康状况 (中断、漏点等) 综合展示;提供数据审计情况综合展示;提供平台运行指标 (数据访问率、测点活跃率等) 综合展示。
1.4 实现海量历史/准实时数据管理平台对用电信息采集系统准实时类数据的直接采集接入
用电信息采集系统数据量大, 数据提供及时性不高, 对 “量价费损”等业务应用中用户表计电量偏差、用户表计断流等复杂计算的及时性有较大影响。结合需求, 采用用电信息采集系统前置机 “一发两收”机制 (如图3 所示) , 在传输数据解析后写入用电信息采集系统数据库的同时向海量历史/准实时数据管理平台推送相同的原始时标数据, 以保证用电信息采集数据的及时性, 减轻用电信息采集系统的接口压力, 并为其提供数据备份。
1.5 新增平台数据质量监测和审计组件
研发海量历史/准实时数据管理平台数据质量监测和审计模块, 通过数据质量检测、数据质量审计、数据质量反馈及解决, 形成数据质量问题跟踪解决闭环, 提升海量历史/准实时数据管理平台数据的有效性、 适用性和及时性, 以满足省公司营销部需求侧分层分区决策管理系统、调控中心大屏展示系统等业务系统对历史/准实时数据数据质量的需求。其主要功能包括:
(1) 数据质量监测 (重点是FTP中断, 漏点, 数据为空, 数据为0, 网络中断等) 。
(2) 基于数据质量监测, 结合现场实际情况, 综合评价分析数据质量。
(3) 将评价结果反馈给数据管控部门, 协助解决数据质量问题, 形成数据质量跟踪解决闭环。
(4) 提供数据质量咨询服务。
1.6 部署分布式实时计算组件
平台分布式实时计算组件[3,4]研究, 实现了对历史/准实时数据的分布式并行内存计算[5], 提升了数据加工计算的效率;流计算和内存计算, 可提升加工数据的实效性;开发集成IDE, 可使数据加工计算变得更便捷; 支撑了“电网规划深化应用”、运监中心 “量价费损”和 “一体化电量与线损管理” (如图4 所示) 等复杂业务应用对历史/准实时数据的电量与负荷计算、 区域的电量与负荷计算、运行数据分析等二次加工需求, 提升了海量历史/准实时数据管理平台分布式实时计算能力, 为构建复杂分析类应用提供了工具保障。总之, 平台分布式实时计算组件研究, 为后续基于平台二次加工计算类应用开发提供了便捷。其具体研发内容如下:
(1) 研发分布式多节点并行计算引擎。 基于上述研究内容研发海量历史/准实时数据管理平台分布式多节点并行计算引擎, 计算引擎通过时间、优先级等配置策略, 调用脚本引擎执行对应的计算算法, 生成计算结果, 并作为测点的结果值和状态转存到数据库中。公式解析采用脚本引擎提供的方式。
(2) 研发分布式多节点并行计算的统一调度控制模块。该模块通过统一配置时间、优先级等策略, 实现控制调度各分布式节点计算任务的执行。
(3) 研发计算资源池管理模块。 该模块用于管理所有分布式节点的计算任务。
2 主要应用成效
通过海量历史/准实时数据管理平台提供的设备模型和对混合数据访问方式的研发, 提升了数据访问的便捷性, 提高了集成的工作效率, 减少了集成工作时间;通过对海量历史/准实时数据管理平台关键技术的研究, 提升了平台的容错性、可靠性和可用性;通过对数据质量检测和审计功能的开发, 可提供数据质量检测、 数据质量确认、数据质量反馈及协助解决机制, 形成数据质量解决闭环, 从而有效提升平台数据质量, 减少数据质量跟踪解决成本。海量历史/准实时数据管理平台的建设响应了国家电网公司坚强智能电网的建设目标, 为国家电网公司智能电网建设在历史/准实时数据存储、 加工、 交换等方面提供了有力支撑。
3 非功能需求
3.1 性能与可靠性
(1) 海量历史/准实时数据管理平台支持100TB级规模的历史/准实时数据管理以及10 个以上的历史/准实时数据库构建统一访问群集。
(2) 在带宽允许情况下, 时间序列数据的事务吞吐率不低于10万事务/s。
(3) 日常平均CPU占用率小于40%, 忙时小于75%;内存占用率小于50%, 最大并发时小于75%。
3.2 信息安全
为了保证系统安全[5], 海量历史/准实时数据管理平台的安全级别为信息系统等级保护二级。其在应用和数据方面需符合以下要求:
(1) 提供身份鉴别机制。 使用平台服务需进行基于用户密码的身份鉴别, 密码登录失败3次结束会话。
(2) 提供访问控制。平台业务用户无法直接访问文件和数据库, 默认只有最小权限, 超级管理员外的用户资源权限有限。
(3) 具备安全审计功能。 平台提供覆盖每个用户的安全审计功能, 审计记录无法被删除, 记录信息包括时间、用户、类型、级别、结果等。
(4) 提供资源控制机制。 在通信双方中的一方未作响应时, 另一方能自动结束会话;能限制系统与单个用户的最大连接数。
(5) 通信保密。 在通信双方建立连接前, 利用密码技术进行会话初始化验证。
4 结束语
海量历史/准实时数据管理平台深化应用建设结合“量价费损”等业务应用对准实时数据的需求, 完成海量历史/准实时数据管理平台计算加工能力提升, 支撑复杂分布式并行计算业务需求;完成平台设备模型业务组件、可视化综合数据展示业务组件、多通道数据访问服务、关系数据处理模块、应用开发业务组件与数据质量检测和审计服务的开发, 提升了平台数据质量, 满足了多形式的数据访问需求, 支持关系数据的储存和处理, 为不同层次人员提供多样化综合展示平台;实现平台对用电信息采集系统准实时类数据的 “一发双收”直接采集数据接入, 提升了平台历史/准实时数据实时性, 满足了 “量价费损”等业务应用对用电信息采集数据的实时性要求;开展海量历史/准实时数据管理平台接口和应用服务的故障转移技术、平台内部关系型数据存储与处理技术、时序型数据和关系型数据的统一查询机制技术等研究, 提高了平台的容错性, 保障了平台的高可用性。
参考文献
[1]曹强, 黄建忠, 万继光, 等.海量网络存储系统原理与设计[M].武汉:华中科技大学出版社, 2010
[2]张云勇.中间件技术原理与应用[M].北京:清华大学出版社, 2004
[3]蔡瑞端, 程浩忠.基于中间件技术的电力市场辅助服务实时数据库设计[J].继电器, 2007 (12) :12~15
[4]何江, 吴杏平, 李立新, 等.基于组件技术的电力系统实时数据库平台[J].电网技术, 2002 (3) :64~67
银行海量数据访问优化途径 篇7
海量数据库系统是一个可以动态调整的系统, 它的内存区域的大小、服务器进程的响应模式、后台进程的多少和种类都可以根据需要进行调整。这样一个可以动态扩展的数据库系统为不同的应用规模、软硬件平台提供了一个表现的空间, 它可以让不同的系统在不同的平台上发挥最佳的系统性能。同时, 也正是这种灵活性, 为银行海量数据访问的性能优化带来了一定的挑战。
一、数据访问优化的基本思路
银行海量数据访问优化是银行数据大集中后的一个重要研究课题。它将应用系统的数据访问任务在应用软件和DBMS之间作最优分解, 采用一定技术对大型数据库的数据结构设计、参数调整和数据访问方式等3方面优化进行有机结合, 从而有效减少搜索空间, 同时提高数据访问的效率, 完成数据访问优化工作。同时在数据库管理层次, 可以根据不同交易对数据访问的特点, 进行数据库的配置和优化设计, 充分发挥数据库管理数据的优势。如果两类数据库存放在不同的物理主机上, 可以发挥多主机并行处理的最大优势。在应用程序层次, 进行联机交易处理时, 严格控制每笔交易的处理时间, 杜绝其它业务处理进程 (如大数据量查询交易和长事务交易等) 对联机交易处理的影响, 使联机交易类数据库保持最小的数据集合, 提高交易响应速度, 便于对数据进行快速的联机备份。应该最大可能地实现7×24小时不间断业务, 日终、季末、月末、年末的批量处理尽量不要影响联机交易业务持续进行。数据访问优化的基本思路如下所述。
(一) 减少无关和重复的计算
采用适当的数据访问语句, 减少无关的数据运算和操作运算。针对影响重复计算的原因, 如用户在所提供的规则中对数据的重复计算或在迭代计算中同一事实多次计算等, 改进应用程序逻辑或数据访问算法。
(二) 参数调整
根据软、硬件的资源情况和数据库的实际运行状况, 调整数据库SGA内存区的大小和PGA区的大小, 调整操作系统数据缓冲区的大小、每个进程所能使用的内存大小等参数, 同时可以调整数据库存储过程, 提高系统的整体性能。
(三) 数据分布调整
可以将组成同一个表空间的数据文件放在不同的物理存储上, 即采用数据的分区技术, 调整数据库系统的I/O性能。例如, 银行的户主账表原来设计成一张表, 虽然可以方便程序的设计与维护, 但经过分析发现, 由于数据量太大, 会影响数据的迅速定位。如果将户主账表分别设计为活期户主账、定期户主账及对公户主账等, 并放在不同的分区上, 则可以大大提高查询效率。
(四) SQL语句计算优化
SQL语句运行的时间越长, 占用系统资源的时间也越长。因此, 尽量使用优化过的SQL语句以减少执行时间。比如, 不在查询语句中包含子查询语句, 充分利用索引, 合理进行分组、合并及汇总等。
(五) 连接优化
指数据库中存在的临时关系的优化和长连接优化。前者指数据库系统查询中, 会产生大量仅含少量元组的临时关系, 要尽量减少这种临时关系;后者指逻辑数据模型中常出现一条规则含有多个子目标时, 该规则的计算中所包含的较多数目的连接操作。连接操作是一种十分费时的操作, 在数据库的连接操作中, 尤其是长连接查询中连接操作数目多、搜索空间大, 对长连接最好进行优化。
(六) 并行优化算法
指将并行算法引入逻辑数据模型, 以提高系统的处理效率。对含有递归规则的逻辑数据语言来说, 采用并行策略, 由于存在规则的迭代计算, 上一次计算的结果要作为下一次计算的输入, 这就需要将计算结果在系统间进行多次传递, 即并行计算将带来高额的传递代价, 因此, 需要采取查询并行优化算法减少这种计算结果的传递。
二、数据访问优化主要技术
通常一个基于海量数据的应用优化应在3个阶段有针对性地进行:应用程序开发阶段、应用程序部署阶段、应用程序调整阶段。不同的阶段优化的内容也不一样, 只有做好3个阶段的优化工作, 才能最大限度地使整个应用系统 (软件、硬件、网络) 高性能地运行。
(一) 数据索引技术
使用数据索引可以极大地提高数据操作效率, 特别在联机交易处理时, 尤其应该注重充分发挥数据库管理器利用索引进行数据操作的效率。数据表索引在建表时创建, 但在应用时的使用情况由应用自身决定。通过使用索引定位取代顺序扫描, 能够提高查询速度, 提高数据排序速度, 同时保证被索引字段的唯一性, 当仅仅查询索引字段时, 避免读取记录全部字段内容。但是建立索引后, 插入、修改、删除记录时增加系统的开销, 索引将占用额外的系统存储空间。因此应用开发时, 应该认真设计数据表的索引。
索引的建立原则为:对连接 (join) 字段建立索引, 对于连接操作, 至少对连接表达式的一个字段建立索引, 否则数据管理器要么在连接之前自动建立临时索引进行“sort merge join”或者“nested loop join”, 要么顺序扫描数据表进行“hash join”;对选择性过滤 (selective filter) 字段建立索引;对排序 (order) 字段建立索引;避免对高重复率 (highly duplicate) 的字段建立索引;利用组合索引 (composite indexs) 降低索引重复率;建立组合索引时, 应该将重复率低的字段放在前面, 重复率高的字段放在后面;控制索引字段对比数据表字段不能过长;运用聚集索引 (clustered index) 提高查询速度, 聚集索引的建立将使被索引的表记录在物理存储上严格按聚集索引的顺序存放, 也就是聚集索引记录与数据记录的存储顺序一致, 查询时扫描的数据量较普通索引减少了, 所以对于经常查询, 很少增删的表可以充分利用聚集索引的优点提高查询速度;数字字段的索引查找速度较其他类型字段 (如字符串字段等) 的索引快;一个数据表的索引不应该过多, 索引过多, 数据插入、数据删除、数据修改速度一定程度上会受影响;利用“部分键查找” (partial key search) 提高索引利用率, 例如, 建立在表tab上的一个索引idx (f1, f2, f3, f4) , 当对tab按照 (f1, f2, f3, f4) 或者按照 (f1, f2, f3) 或者按照 (f1, f2) 或者按照 (f1) 条件查询时, 索引idx (f1, f2, f3, f4) 都可以被利用;为了提高索引查询的效率, 索引应该与数据存放在不同的表空间。
(二) 数据分区技术
当创建一个数据库时, 把数据库分成称为表空间 (tablespace) 的多个逻辑区段。为了使大型数据库的管理更方便, 减少数据查询时引起的I/O冲突, 提高查询效率, 可对数据量比较大 (50 000条记录以上) 、访问频繁的数据表进行分区存放, 分区分为以下方式。
1. 范围分区
如果要在某个数据表中存储大量记录, 可能希望将该数据表的行分到多个表空间中。若要按范围划分表的记录, 可使用creat table命令的partition by rang子句, 这些范围确定存储在每个分区的值。例如:
该数据表实现了将数据按季存放在不同的物理表空间。
2. 散列分区
散列分区通过对分区键值执行一个散列函数来确定数据的物理位置。在范围分区中, 分区键的连续值通常存储在同一分区。在散列分区中, 分区键的连续值不必存放在同一分区。散列分区在比范围分区更大的分区集上分配一个记录集, 从而减少了I/O冲突的可能性。创建一个散列分区, 使用partition by hash子句, 例如:
3. 列表分区
列表分区是基于值列表划分行而不是使用值范围划分行。当基于值列表划分表时, 只能在partition by list子句中指定一个分区键值, 不能指定maxvalue作为列表分区值。例如:
将各个省分行的数据按照业务量的大小进行搭配, 均匀地分配到多个物理空间。
4. 混合分区
混合分区是指把散列分区和范围分区结合起来使用, 从而创建范围分区的散列分区。对于非常大的表, 这种组合分区可能是把数据分成可管理和可调整部分的有效方法。例如:
将历史数据根据交易日期按季进行范围分区, 在范围分区内以账号为键值建立散列分区。
(三) 数据库设计和查询优化技术
1. 表的设计
当在表中添加字段时, 应该选择长度最小的数据类型, 这样表在内存中每页可以存储更多的记录。如“姓名”字段一般设置为TEXT类型, 一般长度为10就够用, 则比默认值255要好得多。整型Integer的长度是2, 在使用整型Integer可以解决问题时不要使用Single, Long, Double, Currency, 因为它们的长度分别为4, 4, 8, 8 (都比2大) 。在建立表后一定要建立索引, 可以大大提高查询速度。
2. 压缩数据库
数据库的查询优化是有代价的, 随着数据库的不断扩大, 优化将不再起作用。压缩数据库会改变数据库的状态, 并重新优化所有查询。同时, 随着数据库的增大, 会产生很多碎片。而压缩数据库可以把一个表中的数据写到硬盘中连续的页里, 提高了顺序搜索的速度。
3. 避免多余计算
当查询的结果作为另外一个查询的数据源时, 可能引起查询优化问题。在这个时候第一查询尽量避免大量的计算。如果在查询输出中实在无法避免计算式的话, 尽量把计算式放在最外层, 不要放在最内层。在建立查询时, 仅返回需要的字段, 这样可以节省不必要的开支。如果某个字段不需要的, 在查询语句中不要出现。用SELECT INTO建立工作表, 尤其是结果集用于几个查询时, 尽量使用中间结果表。在查询前做的准备工作越多, 查询速度越快。
4. 分组、合并及汇总
这里要说明的主要是合并, 当你需要把2个表合并, 就是说, 要根据“Customer Name”对2个表进行合并, 要肯定GROUP BY field (Customer Name) 和汇总 (Sum, Count, and等) 的字段是来自同一张表。在合并表时, 尽量使两边的字段都设置索引。这在执行查询时, 查询优化器可以更多地使用sophisticated内部合并策略。如果要在合并中使用表达式约束一个字段的数值, 需要测试表达式放在合并的一侧还是其他地方的速度。在一些查询中, 表达式放在合并关键词join一侧反而比较快。
SQL语句中分组 (GROUP BY) 的字段越多, 执行查询的时间越长。在GROUP BY子句中尽量用aggregate函数来减少字段的数量。在合并之前嵌套GROUP BY子句。如果要合并2张表, 而且只在一张表中分组, 以查询分为2个SELECT语句要快得多。例如:
可改为:
查询1
查询2
5. 使用可优化的表达式
重新构造查询语句, 以便于Rushmore技术可以对其进行优化。Rushmore是一种数据访问技术, 使用可以提高记录集的查询速度。使用Rushmore时, 若在查询条件中使用具体类型的表达式, 查询速度将非常快。Rushmore不会自动加快速度, 必须按照具体的方法修改查询语句, 以便于Rushmore可以优化它们。
使用COUNT (*) 代替COUNT (Column Name) , 因为Count (*) 计算所有的行, Count (Column Name) 计算所有Column Name非空的行。在变量中避免使用LIKE, 由于在查询完成的时候变量的值不确定, 所以无法使用索引, 这样建立的索引就失去了意义, 而且严重制约查询速度。避免LIKE和通配符同时使用, 如果要把LIKE运算符同通配符一起使用, 为了使用索引, 必须把通配符放在后面。避免SELECT子语句和NOT IN同时使用, SELECT子语句和NOT IN同时使用很难优化, 取反嵌套的查询或OUTER JOINs影响很大。
(四) 并行查询技术
随着功能强大的计算机的问世, 可以利用多个处理器来执行事务处理和查询。一个数据库的查询工作可以通过多个相互配合的处理器来完成。在多处理器间分配工作量可以提高事务处理及查询操作的性能。Oracle等大型数据库的并行查询选项 (PQO) 结构允许将几乎所有的数据库操作并行化。可以利用PQO优势的操作包括create table as select, create index, insert, update, delete和全表扫描、索引扫描、排序、大多数查询。数据库所使用的并行程度由这些命令中使用的paraller关键字degree和instances参数决定。并行查询最适合以下的情况。
●通过搜索非常大表 (通常1 000 000行) 来处理访问大量数据的查询。
●处理连接非常大的表查询, 当数以百万行计的表一起进行访问并汇集查询结果时, 使用并行处理所得的效果特别明显。
●处理建立大索引、大容量数据装载、汇总计算以及对Oracle对象间大量数据拷贝等作业。
●处理在SMP (对称多处理器) 或MPP (大规模并行处理) 群和聚合 (多个机器一起工作, 访问同一组盘和主数据库) 的机器上的查询。
●处理存放在多个数据文件且在不同盘驱上的数据查询。
●对于CPU工作明显不足或间断使用CPU的机器处理。一般是按平均利用率不低于40%来检测CPU的使用效率。
●处理需要大量辅助内存的工作, 比如分类的查询。
●应用系统开发人员应与数据库管理员协同工作, 合理利用资源, 以保证并行处理的进行。
三、海量数据访问优化技术发展及展望
计算机技术发展日新月异, 数据访问优化技术也层出不穷, 当前的优化技术必须具有一定前瞻性, 不但要满足当前的应用要求, 还要考虑未来的业务发展, 同时必须有利于扩展或增加应用系统的处理功能, 同时对数据访问优化技术发展方向, 也要作必要的了解和有益的探讨, 为数据大集中时代数据的更好利用不断拓展途径。目前, 数据访问优化最新技术有以下几个方面。
(一) 逻辑数据语言
采用逻辑数据语言、逻辑数学模型和递归查询计算模式, 在扩大数据库的查询功能和提高数据库的推理能力方面发挥重要作用。如逻辑数据语言可以表达递归查询, 这是关系数据语言所不具备的。它通过构造函数符号的引入来表达复杂对象, 突破了关系数据语言1NF的限制, 同时克服了关系数据库中存在的阻抗不匹配问题。逻辑数据语言及模型具有说明性语义和较强的语义表达能力, 而且采用基于规则的表达方式, 十分符合人的思维方式, 尤其是近年来通过对逻辑数据模型及其计算语义、演绎数据库的各种递归查询算法及计算模式进行大量研究, 数据库的理论和实践方面已取得较大的进展, 并越来越适合用来开发各类基于决策的应用系统。然而, 作为智能数据库初级阶段的演绎数据库迄今尚停留在试验和原型化阶段, 随着进一步的技术进展, 商品化的演绎数据库和知识库系统将问世。
(二) 数据感知的调度
任务负载调度器是网络应用系统中数据访问的一个重要组件, 它通常在把作业分发到分布式数据库上, 进行执行时并不考虑数据的位置。只有在提供最好的数据访问性能的资源上执行作业才更有意义, 因此当前发展的一种趋势是, 调度器正在开始考虑所需要的数据的位置。这需要采用一些方法来将所需要的数据 (输入或输出) 及其位置关联到给定的可执行文件或作业上。网络感知应用程序有望成为一种新的概念, 其中应用程序能够了解网络的状态, 从而可以适应不同的环境来达到可接受且可预测的性能。由于分布式数据库的网络会不断变化, 在应用程序中应用网络感知方面的智能就变得有意义。这种方法的问题是采用什么编程模型以及能够实现何种程度的简化, 从而让应用程序开发人员可以简单地在自己的应用程序中集成网络智能。
(三) 智能检索
智能检索指用AI技术解决大存储容量数据库的优先存取问题, 它通常由AI和数据库2种技术的有效结合来实现, 亦即根据智能数据库或知识库中的事实和知识演绎出正确的答案, 进而推理, 以实现对数据库的智能检索。同时将含有函数项的一阶谓词逻辑用关系演算来表达, 并使其具有较高的计算效率。目前, 引入简单的函数项已不能满足新应用领域的需求, 如现已提出将集合引入逻辑数据语言以及将面向对象数据库和演绎数据库相结合等优化算法与途径。通常, 实现智能检索, 数据库系统应具有以下功能。
●能理解自然语言, 允许用户直接用自然语言提出各种询问。这通常需要引入AI中的自然语言理解技术, 通过建立基于自然语言或类自然语言的人机接口来实现。
●具有推理能力, 能根据存储的事实和知识来推理、演绎出所需的答案。
●系统拥有一定的常识性知识, 以补充学科范围的专业知识, 并能根据这些常识, 演绎出基于一般询问的某些答案来。智能检索涉及自然语言用户界面接口、逻辑演绎算法和语义数据模型等方面的研究, 近年来在这方面已有所突破。
参考文献
[1]唐汉明, 翟振兴, 兰丽华.深入浅出MySQL:数据库开发优化与管理维护[M].北京:人民邮电出版社, 2007.
[2]牛新庄.DB2数据库性能调整和优化[M].北京:清华大学出版社, 2009.
海量数据存储模型的研究 篇8
随着全球信息技术的迅猛发展, 计算机网络技术越来越成熟, 网络上信息的规模正在以指数趋势上升。整个互联网每天都会产生海量的网页数据, 所以怎样高效地对海量网页数据进行存储已经成为人们越来越关注的问题。
传统的网页数据存储模型, 基于单机的或者集中式的存储方式已经不再适合于大规模网页数据存储[4]。最近几年, 云计算的概念越来越流行。云计算作为一种新的商业模式, 是由分布式处理, 并行处理和网格计算发展形成的。目前, 谷歌, 亚马逊, IBM, 微软, Sun等IT巨头都在寻求开发云计算的技术和产品[5]。例如, 谷歌一直 致力于推 动基于GFS[1]、MapReduce[2]和Bigtable[3]等的应用。
传统的集中式的存储方法由于每个存储节点的缺陷, 在存储和管理海量网页数据 ( TB级甚至是PB级) 的时候会出现很多的限制。比如用户会经常发现, 网页数据请求是很耗时的, 网页数据存储能力是有限的, 网页数据读取过程是低效率的。
为此, 本文设计并实现了一种基于云计算的存储模型, 该存储模型主要采用的技术有: Zookeeper[8]开源的同步协同系统确保文件数据写入的一致性、基于hadoop的HDFS文件系统以及基于HDFS文件系统的HBase等技术[8~10]确保实时、高效、稳定、可靠地读写和访问网页数据, 此外由于本文设计的存储模型是利用大量廉价的计算机组成的, 所以存储模型的成本较低。
2 相关的研究工作
文献[4]对海量视频网页数据的存储问题进行了研究, 提出了基于HDFS的HBase的存储框架, 也介绍了HDFS、hbase等技术的基本工作原理和工作特点; 文献[5]提出了一个基于开源的分布式网页数据库服务系统的云存储解决方案 , 它遵循一个阶层设计, 包括Web服务前端, 变换处理层和网页数据存储层; 文献[6]介绍了云计算和云存储的概念以及云存储的架构。然后, 分析了云网页数据存储技术 - GFS ( 谷歌文件系统) / HDFS ( Hadoop分布式文件系统) 应用于具体企业的例子; 文献[7]提出了一种高效的云存储模式, 用于异构云基础设施的存储; 文献[14]介绍了一个基于开源数据库的云存储系统, 阐述了相关技术和原理, 最终页实现了原型系统的架构; 文献[15]针对海量电网数据进行分析和设计出了基于hadoop的云存储模型架构; 文献[11]对Hadoop的基本原理和工作过程做了研究, 使用Hadoop分布式集群技术对分布式海量网页数据存储系统进行了相关的研究与设计, 作了一些有益的尝试和探索; 文献[12]也分析了海量网页数据存储问题, 怎样在电子商务环境下存储海量网页数据, 他们的想法是使用开源的基于Hadoop的分布式存储系统, 并在此基础上提出一种网页数据存储模型, 实现了电子商务海量网页数据的存储; 文献[13]研究并设计了海洋数据存储的一个管理系统, 使用了Hadoop技术, 同时也引入了HBase分布式网页数据库对海洋数据进行存储。
以上的这些研究者研究和分析了怎么存储海量网页数据, 并提出了一些适合各自领域的存储方法, 也对海量数据的计算问题进行了研究, 通过研究对比, 发现他们的研究中存在着一些不足:
( 1) 很多的研究者没有使用Hbase数据库, 读写效率低, 在扩展性、稳定性和可靠性方面都有所不足。
HBase是一个在HDFS文件系统之上运行的开源网页数据库, 它的优势就是能够支持海量网页数据实时高效地对其进行访问与存储, 此外它还是一个面向列的网页数据库, 具有很好的可扩展性、稳定性与可靠性。
( 2) 缺少Zookeeper同步协调工作系统, 不能保持存储节点中的数据写入的一致性。
Zookeeper是Google的Chubby一个开源的实现, 是高有效和可靠的协同工作系统, Zookeeper能够用来leader选举, 配置信息维护等, 在一个分布式的环境中, 需要一个Master实例或存储一些配置信息, 确保文件写入的一致性等。
( 3) 没有针对特定领域的海量数据进行存储的模型。
一般的存储模型都不是通用的, 设计应用到特定领域的模型才更加具有专业性和实用性。
为此, 本文在设计海量网页的云存储模型时, 引入基于HDFS的HBase数据库实现底层的存储架构, 达到高效实时有效的读写海量网页数据, 最后本文实现了一种基于云计算技术的海量网页数据存储模型。
3 存储模型的设计
海量网页数据有很多种形式, 有结构化的网页数据, 比如海量的文本数据, 还有非结构化的网页数据, 比如图片、视频、超媒体数据等等。由于HBase数据库存储的网页数据在默认的情况下都是字符串类型的, 所以对于海量结构化的文本数据, 我们就可以直接存储其对应的字符串, 以文件形式直接存储在HDFS中, 然后在Hbase中建立相应的元数据信息表和地址信息表, 这样做也是因为这样做更有利于表述内容信息和便于查询。
在此基础上, 针对不同类型的网页数据信息, 还可以对他们进行划分不同的次服务器进行存储, 例如建立专门的图片和视频次服务器、文本次服务器等。本文设计的存储模型如图1所示。
本文设计的存储模型最主要的组成部分是HDFS和HBase。
本文设计的针对海量网页数据的存储模型有一张网页数据表需要存储: 它所存储的内容包括crawldb: Nutch爬行的网页数据库, 用来存储爬虫需要爬行的URL地址、linkdb: URL超链接网页数据库, 它是用来存储每个URL超链接的链接地址, 包括初始的源地址和链接地址、segments: 被Nutch爬虫爬取的URL地址被称为一个独立的单元, 而一个segment就是一个独立的单元、indexs: 采用Lucene建立的索引、index: 建立的索引片段。
在如图2的存储模型的实现过程中, 关键的问题是如何对Nutch爬取到的网页数据进行存储、读写以及最后用户的查询。因为HDFS是擅长存储大型文件的, 所以对大量的小文件进行处理、索引和存储的效率是不高的。造成这一现象的原因是HDFS将文件系统全部存入Namenode结点的内存中, 因为每个集群中的Namenode结点只有一个, 它的内存容量是有限的, 所以如果存入的文件数目过多的话, HDFS很难及时的处理和存储。另一个问题是HDFS不允许修改文件的内容, 只能在文件中添加新的内容。
我们知道基于HDFS的HBase数据库是基于列的, 其中存储的网页数据表是由一个KEY/VALUE键值对和无限数量的列族组成的。这样的话, 在Nutch搜索引擎使用的过程中我们可以随时添加新的列, 这样就避免了修改表的结构。
综上所述, 如果我们将Nutch爬虫爬取回来的海量网页数据存入到HBase数据库中, 这样就能够有效地解决这个问题。
4 存储模型的实现
在实验室搭建了由三台相同配置的普通计算机服务器组成的Hadoop分布式集群, 经过多次实验比较了一台服务器节点组成的单机环境下运行和由三台服务器组成的三个节点hadoop分布式运行环境下写入网页数据和读取网页数据所用的时间关系。
图3显示了分别在单机运行的环境下和在三台服务器组成的hadoop集群环境下运行与不同线程个数的写入网页数据的时间关系。从图中可以看出, 集群中同时运行的线程越多, 写入网页数据所需要的时间明显低于单机情况下写入网页数据所需要的时间, 由此可见该存储模型具有高效的写入性。
图4显示了分别在单机和集群环境下同时运行的线程个数不同的情况下读取网页数据的时间关系。从图中可以看出, 随着集群中同时运行的线程数的增加, 集群的读取网页数据时间明显低于单机情况下读取网页数据的时间。由此可以发现本文设计的存储模型具有高效的读取性。
如图5所示, 读取网页数据所花的时间与集群中的节点数成反比, 计算机节点数增加, 读取网页数据的耗时减少, 由此验证了集群的扩展性比较好。
5 结束语与展望
本文设计的海量网页数据存储模型是建立在大量廉价的计算机之上的, 所以只要花很小的成本可以有效地存储海量的网页数据, 同时本文设计的存储模型有较强的扩展性, 通过增加机器节点, 可以在更大网页数据量的环境下运行。
研究称钻石可能存储海量数据 篇9
“我们率先发现可以把钻石作为超密存储的平台。”该研究的主要作者、纽约城市学院物理学家希德哈斯·多姆卡尔 (Siddharth Dhomkar) 说道。
有一部分钻石的晶体结构中缺失了一些碳原子, 从而构成了一些空穴。由于空穴周围聚集了一些氮原子, 因此这种缺陷被称作氮空穴色心 (nitrogen vacancy centers) 。研究人员用这样的钻石进行了一系列实验。
这些空穴中通常储存着电子, 因此使钻石带上了负电荷。不过, 研究人员可以通过向钻石发送激光, 将其转化为中性。在吸收了激光之后, 空穴的特性便会发生改变:它们在光线照射下不会再闪烁, 而是会始终保持黯淡的色泽。这一变化是可逆的, 持续时间很长, 并且弱光照射不会对其造成干扰。
这一研究发现说明, 钻石可以以负电荷和中性电荷的形式存储数据, 然后由激光完成读取、写入、抹除和重新写入等任务。
多姆卡尔指出, 每字节数据在钻石上仅需占据几纳米的空间, 比现有的任何数据存储设备都小得多, 因此有助于我们研发超密计算机存储技术。
不过, 研究人员目前还无法从如此微小的结构中读取或写入数据。但他们确实证明了自己可以解码3D形式的数据 (由2D图像堆叠而成) 。
“如果引入第三维度, 数据存储能力将大大提高。”多姆卡尔指出。利用研究人员所研发的3D数据存储技术, 我们或许能创造出一种新型数据存储光盘, 存储空间可达普通DVD光盘的100倍。
海量数据库的设计与优化 篇10
1 数据库设计
在软件系统处于开发阶段, 往往对系统功能的实现关心较多, 而对系统的性能关心较少, 等系统上线运行后发现系统的性能在不断降低, 这时候再去考虑系统的完善, 则需要花费更多的时间和财力。因此我们在分析复杂的软件系统需求时, 需要确保即使发生高并发的存取情况, 系统也不能瘫痪, 而要能够保持平稳的运行。
在设计数据库的时候, 必须确保数据库的一致性和完整性, 确认数据表之间的相互关系, 存储空间毕竟是有限的, 还要尽可能地降低数据的冗余。数据的冗余度越低、, 系统的完整性越容易得到保证, 反过来, 数据的完整性越好, 也更能清楚地表达数据元素之间的相互关系。在大型系统中, 经常需要对于多个数据表进行的连接查询, 关联的数据表越多, 其查询的效率必然会降低, 同时应用程序的编程复杂度也相应增加, 因此, 数据库设计需要均衡考虑。根据系统业务逻辑, 确定关联数据表的数据量大小、字段被访问频率, 如果某些字段被访问的频率非常高, 可以对这些常用的数据表适当提高冗余设计, 虽然提高冗余度可能会增加软件系统编程的复杂性, 但可以极大提高系统的响应时间, 用户体验会变得更好, 所以合理的数据冗余也是很有必要的。
数据表在设计时应注意以下问题:
1) 通过分区视图可以把一个数据库中的一个大表按照一定的规则分布到不同的数据库中, 这样可以减少服务器的压力。但这种分区视图在网络状况不好时, 效率比较差。
2) 数据表中字段的数据类型能够用数字类型也能用字符型时, 则尽量选择数字类型, 因为数据库管理系统在执行查询时会依次比较字符串中所有字符, 所花时间比较长, 而对于数字型的字段, 只需要一次比较就可以了, 效率高。
3) 对于定长字符型和变字符型, 定长字符型类型查询效率高, 速度快, 但是所占存储空间比较大, 而变长字符型在查询时速度可能会慢一点, 但是可以节省存储空间。因此需要灵活选择字段的数据类型, 对于存储的数据长度有特定规则的, 每次存储数据量变化不大的字段可以选择定长字符型, 长度变化大的字段可以选择变长字符型。
4) 字段的长度在在满足条件的情况下, 最好短一些, 这样可以提高查询的效率, 同时在此字段上建立索引的时候也可以减少资源的消耗。
2 数据库优化
1) 有时候为了逐行处理数据, 需要定义游标, 但在使用游标时要慎重, 因为游标的执行效率比较差, 如果游标操作的数据非常多, 比如超过万行, 那么最好考虑其他方式。游标虽然提供了对特定数据集合进行逐行扫描的手段, 但基于多个表和大数据表定义的游标, 往往会使系统程序进入一个较长的等特过程, 用户体验不是很好, 这个时候可将符合条件的数据行存入到临时表中, 然后再对临时表定义游标, 进行相关操作, 这样可使系统的性能得到较大的提高。
2) 索引是数据库中非常重要的一个对象, 使用索引可以提高数据表中数据的访问速度, 另外没有索引的数据表是按堆结构存储数据的, 后续增加的数据都将添加到数据表的后面, 建立索引的数据表, 表中数据在物理上会按照索引键的顺序存储, 大大提高数据的读取速度。
3) 数据随着时间持续增长, 然而有时候只有近期的数据才是最常用的。定期清除较早数据到历史表中, 将业务数据分级存储, 一个较小规模的近期表是一种很好的提高查询效率的方法。
3 结束语
随着信息技术的快速发展, 越来越多的软件系统需要应对海量的数据, 系统性能受到严重影响, 在现有条件下, 充分优化数据库的设计, 可以更好地发掘系统的潜力, 提升软件系统的性能。
参考文献
[1]毛杰, 佘名高.海量数据库查询优化研究[J].软件导刊, 2010 (5) .