海量数据处理技巧（共6篇）
海量数据处理技巧 篇1
1 研究背景及意义
1.1 说明
在很多商业应用及科学研究领域, 对计算机快速处理大规模数据处理能力的要求与日俱增。绝大多数的产业在海量数据处理与高性能计算方面都有很大的需求。快速的运算能力能提供更为实时的预测结果, 能让人涉足原本无法计算和验证的领域。
当单个核心的运算频率逐渐不在跟随摩尔定律的速度提升的今天, 采用多核处理器以及构造计算机集群的方式获得更快的运算速度成为了很好的办法。构造高性能数据处理器的方法有两种。第一种是基于对称多处理器的方案。该方案已经成为多核服务器的通用方案, 有了广泛的应用。但这种方案受内存容量和总线宽度的限制使得其处理器数量遭遇了严重的瓶颈。而且当前阶段, 当处理器数目超过一定量的时候会带来性价比的严重下降。第二种方案采用构造计算机集群的思路, 具有性价比高、扩展性、容错性、便于管理、易于编程等优点。
2 集群系统概述
服务器集群, 简单的讲就是将若干台服务器集中在一起, 向用户提供一组网络资源或一种网络服务, 集群内部的单台计算机对集群来说是一个节点, 对外部用户来说, 集群做到了完全透明, 使用户感受到只有一台服务器在提供服务。集群利用内部的多台计算机对服务进行分布式的处理, 可以获得远高于单台服务器的处理能力, 且单台服务器的故障不会影响集群的整体运行。集群总体上可分为三种:科学计算集群、负载均衡集群、高可用性集群, 下面分别介绍。
2.1 科学计算集群
科学计算集群主要是解决大规模并行计算的问题, 一般情况下, 用科学计算集群科学计算集群来解决由复杂的科学问题带来的巨大的计算量, 科学计算集群就如同是一个超级计算机, 它由成千上万个服务器组成, 由控制节点统一控制, 运行相应的应用程序。
2.2 负载均衡集群
负载均衡集群可以使负载 (比如存储、计算、服务等) 尽量的平均分配到各台服务器, 这非常适合向大量用户提供同一种应用服务, 负载均衡可以使负载在各个节点之间动态的分配, 可以使每个节点都分担一部分负载, 负载均衡还可以根据各个节点的不同状况或者网络的不同状况来对负载分配作出优化, 以使整体性能达到最优。
2.3 高可用性集群
高可用性集群的作用是, 当集群中的一台或几台设备发生故障是, 高可用性集群可以迅速将分配给这些故障设备的任务转而分配给其他没有故障的设备, 从而保证了集群系统的高可用性。高可用性集群应对系统内的设备故障作出尽可能快的响应, 高可用性经常是以设备的冗余配置来实现的, 如果有节点出现故障, 则正常的设备会在非常短的时间内接替故障设备工作, 因此, 整个系统的服务是持续不断的, 也就是实现了高可用性。
3 处理业务并行化
解决一个计算量巨大的实际的数学或者物理问题, 最终目的是将该问题映射在并行机上来解决。为了完成这个映射的过程, 需要在不同的层次上对实际的数学或者物理问题做抽象。在这个抽象的过程中, 需要忽略非核心的细节问题, 从而得到并行计算模型。在并行模型的基础上, 设计符合该并行计算模型的算法, 通过算法描述需要实现的各种功能以及实现该功能的流程。然后将该算法用并行设计语言写出来, 成为能在并行机上运行的程序。
两种最重要的并行编程模型分别是基于数据并行和任务并行的。基于数据并行的模型需要将数据均衡的划分, 对不同的数据执行同样的操作。它相对于另一种编程模型而言, 实现起来更容易。只要对数据块的划分是平均的, 那么得到的每个子任务的大小也将是均匀的, 所以负载均衡的问题也很容易实现。
但是基于数据并行的编程模型适用范围较窄, 虽然这种模型可以解决科学和工程计算中的一大类问题, 但是如果用数据并行的方法来解决非数据类并行的问题, 效率会很低。因为这种形式的编程模型相对比较单一, 无法解释不同形式的并行特征。
基于任务并行的编程模型将一个复杂的任务在逻辑上进行分解, 然后将分割的子任务分别交由不同进程完成。举一个例子, 一个常见的任务并行的编程模型是基于消息传递机制来实现的。各个子任务并行执行, 子任务之间通过消息传递机制进行数据信息的交换, 执行的逻辑控制和时间上的同步。消息传递机制一般适用于分布式内存的并行计算机系统, 但也可以支持共享内存式的并行计算机系统。消息传递机制通过提供功能强大的程序调用来保证执行效率。但是另一方面, 在逻辑上评估任务的负载本身就是一件不容易的事情, 所以这种模式下的负载均衡较为困难。
4 基于Hadoop的集群系统实现
4.1 Hadoop集群
Hadoop系统平台是一个搭建在廉价PC上的分布式集群系统架构, 它具有高可用性、高容错性和高可扩展性等优点。Hadoop由Apache基金会开发, 由于它提供了一个开放式的平台, 用户可以在完全不了解底层实现细节的情形下, 开发适合自身应用的分布式程序。
Hadoop主要有两个部分组成MapReduce编程模型和HDF (Hadoop分布式文件系统) 。集群由一个主控节点负责HDFS和MapReduce执行的管理。其余节点负责数据存储和运算。Hadoop集群是一个针对大规模数据的存储和计算平台。如何处理好数据存储和计算的关系决定着集群的性能的优劣。数据存储在哪一个DataNode节点上, 就由这个节点计算机执行这部分数据的计算, 从而可以减少数据在网络上的传输, 降低对网络带宽的需求。在Hadoop这样的基于集群的分布式并行系统中, 计算结点可以很方便地扩充, 因而它所能够提供的计算能力近乎是无限的, 由于数据需要在不同的计算节点之间传输, 所以网络带宽往往容易变成瓶颈, 计算节点的数据本地性成为了最有效的一种节约网络带宽的手段, 业界把这形容为“移动计算比移动数据更经济”。调度方法就是作为Hadoop系统的核心程序负责移动计算到相应的数据上来完成计算任务。
4.2 Hadoop MapReduce并行化处理
MapReduce模型是基于任务的并行, 把一个问题分解成可以并发执行的任务集合, 然后通过底层的并行计算结构来完成计算。假设一种应用, 它的输入是n组数据, 分别对每组数据进行的操作并不一样, 比如第一组要求先做乘法后做加法, 第二组要求先做加法后做乘法, 第三组……, 这样每一组数据上的任务都不相同, 让它们并行来做可以看作是典型的按任务划分。如果用MapReduce模式来对这个问题进行描述, 可以看到在这个问题中计算步只有一个, 且不存在数据依赖。首先从数据划分方面来看, 每一个数据集合对应着不同的操作, 所以每一个数据集合作为一个单独的map输入key/value对中的value。其次, 从计算任务的分配角度来看, 由于只有一个数据无关的计算步, 所以在设计MapReduce的两个主要步骤map和reduce时, 可以将计算任务放入其中任何一个步骤。最后, 从数据结构的设计方面来看, 一方面在map的输入数据中要包含数据集合中的数据, 另一方面每个数据集合所要做的计算是不一样的, 所以要有一个标识能够表示次数据集合要做什么计算, 比如用1作为第一组数据的标识, 当发现标识为l则对每个元素做先加后乘的运算, 而且还要有加法参数a和乘法参数b的信息。由此看来在设计数据结构的时候由两部分信息要考虑, (1) 数据集合的参数和标识信息, 即数据的特征信息; (2) 数据集合本身的数据, 即原始数据。
MapReduce的并行能力主要有三个部分, 一是子任务间并行, 一个作业的各个map子任务并行执行, 见图1所示;二是map和reduce任务间并行, 一个作业的map和reduce任务同时执行, 见图2所示。三是作业间并行当然有时也是用户间的并行, 见图3所示。
MapReduce模型只是给出了问题可以用并行化的方式解决的思想, 具体的并行处理实现则需要用户通过自定义的函数去完成。而当给出了具体的用户自定义函数后, 下面的工作就需要系统去完成各个并行任务的调度和运行, 调度方法就是用来分配和调度用户自定义函数所分解出的各个子任务 (map和reduce任务) 。
5 结束语
虽然使用Hadoop平台海量数据进行处理有其先天的优势, 但是本文对其应用还是处于初级阶段, 仍有很广阔的空间等待我们去发展, 例如对于Hadoop集群的用户使用情况和作业的提交类型进行更深一步的研究, 在hadoop平台下实现更多的图论算法, 并将其应用于实际开发之中, 以及优化其并计算过程, 减少垃圾计算等等。
在今后, 会在以上问题进行更深入的研究, 了解更多的领域知识, 使Hadoop平台应用的更广阔空间里去。
参考文献
[1]Hadoop[EB/OL], http://hadoop.apache.org/[2010.9.24].
[2]HDFS[EB/OL], http://hadoop.apache.org/common/docs/r0.20.2/hdfs_user_guide.html[2010.6.10].
[3]MapReduce[EB/OL], http://hadoop.apache.org/common/docs/r0.20.2/mapred_tutorial.html[2010.8.19].
[4]孙广中, 肖锋, 熊曦, 《MapReduce模型的调度及容错机制研究》, 微电子学与计算机, 2007 (24) .
海量数据处理技巧 篇2
关键词：电子商务,数据处理,数据分析
1 电子商务数据的特点
1.1 数据量大
从TB级别跃升到PB乃至EB级别。要知道目前的数据量有多大, 我们先来看看一组公式。1024GB=1TB;1024TB=1PB;1024PB=1EB;1024EB=1ZB;1024ZB=YB。到目前为止, 人类生产的所有印刷材料的数据量是200PB, 而历史上全人类说过的所有的话的数据量大约是5EB。
1.2 类型繁多
这种类型的多样性也让数据被分为结构化数据和非结构化数据。相对于以往便于存储的以文本为主的结构化数据, 越来越多的非结构化数据的产生给所有厂商都提出了挑战。
1.3 价值密度低
价值密度的高低与数据总量的大小成反比。以视频为例, 一部1 h的视频, 在连续不间断监控过程中, 可能有用的数据仅仅只有一两秒。如何通过强大的机器算法更迅速地完成数据的价值“提纯”是目前大数据汹涌背景下亟待解决的难题。
1.4 速度快时效高
这是大数据区分于传统数据挖掘最显著的特征。根据IDC的一份名为“数字宇宙”的报告, 预计到2020年全球数据使用量将会达到35.2ZB。在如此海量的数据面前, 处理数据的效率就是企业的生命。
2 电子商务平台海量数据处理的相关技术介绍
2.1 对海量数据进行分区操作
对海量数据进行分区操作十分必要, 例如针对按年份存取的数据, 我们可以按年进行分区, 不同的数据库有不同的分区方式, 不过处理机制大体相同。例如SQL Server的数据库分区是将不同的数据存于不同的文件组下, 而不同的文件组存于不同的磁盘分区下, 这样将数据分散开, 减小磁盘I/O, 减小了系统负荷, 而且还可以将日志, 索引等放于不同的分区下。
2.2 建立广泛的索引
对海量的数据处理, 对大表建立索引是必行的, 建立索引要考虑到具体情况, 例如针对大表的分组、排序等字段, 都要建立相应索引。结构化数据具有统一的纲要, 关系表中的每个元组都有相同的属性和数据类型 (比如数值或字符串) , 关系数据库可以对它们进行统一的存储和管理。
2.3 使用文本格式进行处理
对一般的数据处理可以使用数据库, 如果对复杂的数据处理, 必须借助程序, 那么在程序操作数据库和程序操作文本之间选择, 是一定要选择程序操作文本的, 原因为:程序操作文本速度快;对文本进行处理不容易出错;文本的存储不受限制等。
2.4 使用临时表和中间表
数据量增加时, 处理中要考虑提前汇总。这样做的目的是化整为零, 大表变小表, 分块处理完成后, 再利用一定的规则进行合并, 处理过程中的临时表的使用和中间结果的保存都非常重要, 如果对于超海量的数据, 大表处理不了, 只能拆分为多个小表。如果处理过程中需要多步汇总操作, 可按汇总步骤一步步来, 不要一条语句完成, 一口气吃掉一个胖子。
2.5 优化查询SQL语句
在对海量数据进行查询处理过程中, 查询的SQL语句的性能对查询效率的影响是非常大的, 编写高效优良的SQL脚本和存储过程是数据库工作人员的职责, 也是检验数据库工作人员水平的一个标准, 在对SQL语句的编写过程中, 例如减少关联, 少用或不用游标, 设计好高效的数据库表结构等都十分必要。笔者在工作中试着对1亿行的数据使用游标, 运行3 h没有出结果, 这是一定要改用程序处理了。
2.6 定制强大的清洗规则和出错处理机制
海量数据中存在着不一致性, 极有可能出现某处的瑕疵。例如, 同样的数据中的时间字段, 有的可能为非标准的时间, 出现的原因可能为应用程序的错误, 系统的错误等, 这是在进行数据处理时, 必须制定强大的数据清洗规则和出错处理机制。
2.7 使用数据仓库和多维数据库存储
数据量加大是一定要考虑OLAP的, 传统的报表可能5、6h出来结果, 而基于Cube的查询可能只需要几分钟, 因此处理海量数据的利器是OLAP多维分析, 即建立数据仓库, 建立多维数据集, 基于多维数据集进行报表展现和数据挖掘等。
2.8 使用采样数据, 进行数据挖掘
基于海量数据的数据挖掘正在逐步兴起, 面对着超海量的数据, 一般的挖掘软件或算法往往采用数据抽样的方式进行处理, 这样的误差不会很高, 大大提高了处理效率和处理的成功率。一般采样时要注意数据的完整性和, 防止过大的偏差。
3 结语
随着电子商务平台用户数量的不断增长, 人们需求的不断提高以及商户服务种类与项目的日益增多, 电子商务平台的数据量还会不断的增大。如何针对电子商务平台海量的数据进行分析和处理是一项艰巨而复杂的任务。
参考文献
[1]亿邦动力网.零售商认为大数据有利于电子商务[EB/OL].[2012-10-18].http://www.ebrun.com/20121018/58764.shtml.
银行海量数据访问优化途径 篇3
海量数据库系统是一个可以动态调整的系统, 它的内存区域的大小、服务器进程的响应模式、后台进程的多少和种类都可以根据需要进行调整。这样一个可以动态扩展的数据库系统为不同的应用规模、软硬件平台提供了一个表现的空间, 它可以让不同的系统在不同的平台上发挥最佳的系统性能。同时, 也正是这种灵活性, 为银行海量数据访问的性能优化带来了一定的挑战。
一、数据访问优化的基本思路
银行海量数据访问优化是银行数据大集中后的一个重要研究课题。它将应用系统的数据访问任务在应用软件和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.
海量数据纹理映射技术研究 篇4
纹理映射技术是当前计算机图形学中的一个热点问题。然而由于纹理图像数据量大,特别是对于大规模的地形数据模型,如果要求具有较高的真实感,内存的需求量更是十分巨大。很多算法是采用一个单块的地形纹理来进行纹理映射,但是在越来越多的情况下纹理数据远远大于内存容量,需要将纹理分块处理后才能使用[1]。为了能在有限的资源下获得较好的实时绘制效果,研究人员从地形的几何多分辨率表示中得到启示提出多分辨率纹理映射技术[2,3,4]。该文在总结已有算法的基础上,提出了一种基于四叉树结构的海量数据纹理映射算法。有效地解决了大规模地形场景重建过程中的数据调度与海量数据的纹理映射问题。实验结果证明了该算法的有效性。
1 基于四叉树的多分辨率纹理分块
为了能有效地实现大数据量纹理的实时调度,需要将纹理进行分块管理。一般情况下,纹理图像分割得越细,纹理坐标的计算量就越小,绘制速度就越快,然而这样会大大增加内存中的数据调度次数。该文使用四叉树结构来表示大规模数字地形的多分辨率纹理数据,每个结点用相同尺寸的纹理图像表示,但不同分辨率结点的纹理精细程度不同。四叉树结构的根结点对应覆盖整个地形方形区域,它的4个子结点分别为根节点的四分之一地域,依次类推,每个子结点均按此方法产生4个子结点,直到原始纹理的最精细分辨率或满足纹理划分的要求为止。
多分辨率纹理映射的关键是如何选取与地形LOD相一致的纹理图像的分辨率。一般来说,分辨率的选择是与视点、地形块的位置大小和纹理的原始分辨率相关的。根据文献[4]中的误差计算方法可以类似计算纹理映射误差。与地形误差不同的是,纹理误差要考虑纹理结点的大小与图像的分辨率级别,因此,纹理映射的误差可表示成纹理的分辨率级别与距视点的距离的函数,可用下式表示:
式中,k为纹理图像的分辨率级别;d为纹理分块距视点的距离;w为纹理分块的大小;l为地形数据点之间的行间距和列间距的几何平均值,即
2 纹理调度算法
在大规模的实时绘制时,需要不断地从硬盘到系统内存再到纹理内存调度纹理数据,如果用图形库的函数来实时建立多分辨率纹理则效率不高。该文的方法是预先建立纹理的各个层次细节,存储在数据文件中,当需要的时候对各个层次的纹理数据进行读取,然而使用多级纹理四叉树一次调入的数据量太多时,就会造成帧间停顿时间过长,为了降低停顿时间,必须减少纹理数据的调入量。
2.1 压缩纹理存储的实现
在实际应用中发现,在硬盘到系统内存的传输这一过程可以使用算法对纹理数据进行压缩,再将其存储在硬盘文件上。在使用时,用快速的解码把纹理数据解压到系统内存中。由于纹理图像相邻的纹理象素之间具有某种连贯性,利用这种连贯性对纹理金字塔进行压缩可以有效地减少数据冗余,使得纹理的表示更为紧凑。该文使用类似文献[5]中的图像金字塔,进行多层次的压缩和存储,来对纹理进行有效地压缩、调度及纹理反走样。由于纹理数据需要在绘制时实时进行解码,对解码的时间要求比较高,而矢量量化的方法仅需要建立索引表进行数据检索,效率非常高,因此可以采用矢量量化方法压缩误差图像。用矢量量化编码图像是一种有损的压缩技术,其关键是基于区域进行码本设计。这里使用LBG矢量量化算法对误差图像进行压缩编码[6]。
在执行图像矢量量化的过程中,由于图像各局部区域之间具有相似性,取一定大小的图像子区域进行矢量量化,这些图像子区域区使用相同的编码索引。基于图像子区域进行矢量量化,可以有效地对纹理图像进行压缩。采用矢量化的压缩方法,图像解码快速有效。对于层次多分辨率的纹理,当需要导入高一层分辨率的纹理数据,可以通过使用粗糙一层的纹理数据,以及编码索引号所指向的误差图像矢量量化后的颜色值就可以计算得出。在恢复每一层时,只需要从硬盘读取码本和编码索引号的信息,数据量小,读取非常快,这样既可以节省存储空间,又可以快速地恢复精细层纹理。
2.2 基于误差控制的多分辨率纹理结构
在实际绘制过程中,可以发现在一定误差的控制下,越高分辨率的纹理图像,在离视点越近的区域使用的较多,根据这一现象,在调入纹理数据时,只调入某一分辨率的在一定范围内的纹理数据即可满足实时绘制的需要。因此,首先要根据多分辨率纹理计算的结果确定不同分辨率纹理的范围,将在范围内的多分辨率纹理调入到内存的多分辨率结构中。该文在绘制时将每一层分辨率的纹理数据与预估的结果比较,将符合要求的纹理数据调入内存结构中,此时对于不同层次的纹理映射时会有2种情况:
① 需绘制的纹理层次低于调入的纹理节点层次,此种情况可直接使用上一级纹理进行纹理映射;
② 需绘制的纹理层次高于调入的纹理节点层次,这种情况要复杂一些,因为调入的纹理不能完全覆盖满足纹理分辨率要求的一个多边形,所以不能直接进行纹理映射,解决的方法是利用己调入的纹理为绘制节点实时生成纹理图像。
2.3 纹理内存释放算法
在进行大规模的纹理调用时,当纹理的缓冲空间达到一定限制时就需要释放一部分纹理,通常的办法是采用LRU算法。
假定当前的视点位置为v1,前一帧视点位置为v0,下一帧视点位置为v2。由此可以估算出在视点v1处的运动方向是(v1-v0)/‖v1-v0‖,运动的速度为‖v1-v0‖/t,其中t是从视点v0运动到视点v1所用的时间,所以在v1处视点的运动矢量为:
式中,f表示在v1时刻的帧频率,于是下一视点v2的估计位置为:
这里假设在3个视点处有相同的帧频率,则在视点v2处的视锥体可以表示成由视点位置v2、视点方向d、视域张角w以及近截面fn和远截面ff的函数,即:
rv=rv(v2,d,w,fn,ff)。 (4)
通常情况下,在实时飞行仿真过程中后面3个变量是不变的,只有视点的位置与方向在随时间变化。在飞行仿真过程中,通常离视域范围越远的纹理被释放的可能性就越大,因此可以用纹理块与视域的距离平均距离作为影响内存释放的一个因子,可以用下式计算:
式中,(qx,qy),(rx,ry)分别为纹理分块与预测的下一视点处的视域体在平行于地面平面上投影的重心。
在进行纹理调度时,首先计算内存中纹理分块到视域体的平均距离,然后,对平均距离
p=fq×l, (6)
式中,fq为纹理四叉树结点最近一次调用的帧序号;l务纹理四叉树结点的层数,p越小且距离视域平均距离越远的纹理结点的数据最先剔除。
3 实验结果分析
该文对地形纹理的实时绘制进行性能测试,使用的实验数据是深圳地区的DEM数据,地形表面数据的大小为7 169×4 096个数据点,数据点的实际分辨率为10 m,在硬盘中的文件总大小为112 MB。对于地形纹理数据,这里使用的是该地区经校正过的卫星图片,其大小为28 672×16 384,在硬盘中的文件大小约为1.34 GB。
图1是该算法实时帧速率与传统算法的实时帧速率比较的结果图。统计了一个给定飞行路线中500帧的数据。从图中可以看出,算法的帧速率要明显高于传统方法的结果,这是因为该算法通过矢量量化图像压缩算法及根据纹理误差范围的数据调度算法,大大减少了实时仿真过程中的系统外存与内存之间的数据调度量,同时基于视域的内存释放算法可以对纹理内存进行有效的管理,减少内存中纹理数据在磁盘和缓冲区之间反复调度,提高了算法实时仿真的效率。
4 结束语
为实现实时的大规模地形的纹理映射,该文提出了一种新的基于四叉树结构的海量数据纹理映射算法。算法对多分辨率纹理数据进行了基于金字塔结构的数据压缩存储,提出了一种有效的纹理映射误差的计算方法,提高了纹理映射的精度,并利用纹理映射误差,减少了实时调度过程中纹理数据的数据量,同时优化了内存释放算法,有效减少了纹理数据在磁盘和缓冲区之间的反复调度,从而解决了大规模地形场景重建过程中的数据调度与海量数据的纹理映射问题,在实际应用中取得了比较满意的效果。
参考文献
[1]陆雁青.海量地形数据实时绘制的技术研究[D].浙江大学博士学位论文,2003.7.
[2]BLOW J.Terrain rendering at high levels of detail[C]∥Proceedings of the Game Developers Conference 2000.California,2000:119-124.
[3]TANNER C,MIGAL C,JONES M.The clipmap:a virtualmipmap[C]∥Cohen M.ed.,Proceedings of SIGGRAPH1998.Orlando,florida.1998.New York:ACM Press,1998:415-422.
[4]黄超超,凌永顺,吕相银.地形纹理映射方法研究[J].计算机仿真,2005,22(1):209-212.
[5]LINDSTROM P,PASCUCCI V.Terrain simplificationsimplified:a general framework for view-dependent out-of-core visualization[J].IEEE Transactions on Visualization andComputer Graphics,2002,8(3):239-25.
海量数据处理技巧 篇5
虚拟现实项目制作过程中，由于虚拟现实包含的内容丰富，需要载入的数据量有时会非常巨大，需要进行处理和查询的内容很多，然后还要以文字和图像的形式进行表示出来，所以经常会遇到海量数据处理的瓶颈，造成这种情况的原因是：
(1)数据量过大，数据中什么情况都可能存在。如果说有10条数据，那么大不了每条去逐一检查，人为处理，如果有上百条数据，也可以考虑，如果数据上到千万级别，甚至过亿，那不是手工能解决的了，必须通过工具或者程序进行处理，尤其海量的数据中，什么情况都可能存在，例如，数据中某处格式出了问题，尤其在程序处理时，前面还能正常处理，突然到了某个地方问题出现了，程序终止了。
(2)软硬件要求高，系统资源占用率高。对海量的数据进行处理，除了好的方法，最重要的就是合理使用工具，合理分配系统资源。一般情况，如果处理的数据过TB级，小型机是要考虑的，普通的机子如果有好的方法可以考虑，不过也必须加大CPU和内存，就象面对着千军万马，光有勇气没有一兵一卒是很难取胜的。
(3)要求很高的处理方法和技巧。这也是本文的写作目的所在，好的处理方法是一位工程师长期工作经验的积累，也是个人的经验的总结。没有通用的处理方法，但有通用的原理和规则。
在多个虚拟现实项目的基础上，尤其是通过与行内多名专家进行项目经验交流，以下的方法都可以对海量数据在虚拟现实项目中的处理进行改善。
1 选用优秀的数据库工具
现在的数据库工具厂家比较多，对海量数据的处理对所使用的数据库工具要求比较高，一般使用Oracle或者DB2，微软公司最近发布的SQL Server 2005性能也不错。另外在BI领域：数据库，数据仓库，多维数据库，数据挖掘等相关工具也要进行选择，象好的ETL工具和好的OLAP工具都十分必要，例如Informatic,Eassbase等。笔者在实际数据分析项目中，对每天6000万条的日志数据进行处理，使用SQL Server 2000需要花费6小时，而使用SQL Server 2005则只需要花费3小时。
2 编写优良的程序代码
处理数据离不开优秀的程序代码，尤其在进行复杂数据处理时，必须使用程序。好的程序代码对数据的处理至关重要，这不仅仅是数据处理准确度的问题，更是数据处理效率的问题。良好的程序代码应该包含好的算法，包含好的处理流程，包含好的效率，包含好的异常处理机制等。
3 对海量数据进行分区操作
对海量数据进行分区操作十分必要，例如针对按年份存取的数据，我们可以按年进行分区，不同的数据库有不同的分区方式，不过处理机制大体相同。例如SQL Server的数据库分区是将不同的数据存于不同的文件组下，而不同的文件组存于不同的磁盘分区下，这样将数据分散开，减小磁盘I/O，减小了系统负荷，而且还可以将日志，索引等放于不同的分区下。
4 建立广泛的索引
对海量的数据处理，对大表建立索引是必行的，建立索引要考虑到具体情况，例如针对大表的分组、排序等字段，都要建立相应索引，一般还可以建立复合索引，对经常插入的表则建立索引时要小心，笔者在处理数据时，曾经在一个ETL流程中，当插入表时，首先删除索引，然后插入完毕，建立索引，并实施聚合操作，聚合完成后，再次插入前还是删除索引，所以索引要用到好的时机，索引的填充因子和聚集、非聚集索引都要考虑。
5 建立缓存机制
当数据量增加时，一般的处理工具都要考虑到缓存问题。缓存大小设置的好差也关系到数据处理的成败，例如，笔者在处理2亿条数据聚合操作时，缓存设置为100000条/Buffer，这对于这个级别的数据量是可行的。
6 加大虚拟内存
如果系统资源有限，内存提示不足，则可以靠增加虚拟内存来解决。笔者在实际项目中曾经遇到针对18亿条的数据进行处理，内存为1GB,1个P4 2.4G的CPU，对这么大的数据量进行聚合操作是有问题的，提示内存不足，那么采用了加大虚拟内存的方法来解决，在6块磁盘分区上分别建立了6个4096M的磁盘分区，用于虚拟内存，这样虚拟的内存则增加为4096*6+1024=25600M，解决了数据处理中的内存不足问题。
7 分批处理
海量数据处理难因为数据量大，那么解决海量数据处理难的问题其中一个技巧是减少数据量。可以对海量数据分批处理，然后处理后的数据再进行合并操作，这样逐个击破，有利于小数据量的处理，不至于面对大数据量带来的问题，不过这种方法也要因时因势进行，如果不允许拆分数据，还需要另想办法。不过一般的数据按天、按月、按年等存储的，都可以采用先分后合的方法，对数据进行分开处理。
8 使用临时表和中间表
数据量增加时，处理中要考虑提前汇总。这样做的目的是化整为零，大表变小表，分块处理完成后，再利用一定的规则进行合并，处理过程中的临时表的使用和中间结果的保存都非常重要，如果对于超海量的数据，大表处理不了，只能拆分为多个小表。如果处理过程中需要多步汇总操作，可按汇总步骤一步步来，不要一条语句完成，一口气吃掉一个胖子。
9 优化查询SQL语句
在对海量数据进行查询处理过程中，查询的SQL语句的性能对查询效率的影响是非常大的，编写高效优良的SQL脚本和存储过程是数据库工作人员的职责，也是检验数据库工作人员水平的一个标准，在对SQL语句的编写过程中，例如减少关联，少用或不用游标，设计好高效的数据库表结构等都十分必要。笔者在工作中试着对1亿行的数据使用游标，运行3个小时没有出结果，这是一定要改用程序处理了。
10 使用文本格式进行处理
对一般的数据处理可以使用数据库，如果对复杂的数据处理，必须借助程序，那么在程序操作数据库和程序操作文本之间选择，是一定要选择程序操作文本的，原因为：程序操作文本速度快；对文本进行处理不容易出错；文本的存储不受限制等。例如一般的海量的网络日志都是文本格式或者csv格式（文本格式），对它进行处理牵扯到数据清洗，是要利用程序进行处理的，而不建议导入数据库再做清洗。
11 定制强大的清洗规则和出错处理机制
海量数据中存在着不一致性，极有可能出现某处的瑕疵。例如，同样的数据中的时间字段，有的可能为非标准的时间，出现的原因可能为应用程序的错误，系统的错误等，这是在进行数据处理时，必须制定强大的数据清洗规则和出错处理机制。
12 建立视图或者物化视图
视图中的数据来源于基表，对海量数据的处理，可以将数据按一定的规则分散到各个基表中，查询或处理过程中可以基于视图进行，这样分散了磁盘I/O，正如10根绳子吊着一根柱子和一根吊着一根柱子的区别。
13 避免使用32位机子
目前的计算机很多都是32位的，那么编写的程序对内存的需要便受限制，而很多的海量数据处理是必须大量消耗内存的，这便要求更好性能的机子，其中对位数的限制也十分重要。
14 考虑操作系统问题
海量数据处理过程中，除了对数据库，处理程序等要求比较高以外，对操作系统的要求也放到了重要的位置，一般是必须使用服务器的，而且对系统的安全性和稳定性等要求也比较高。尤其对操作系统自身的缓存机制，临时空间的处理等问题都需要综合考虑。
15 使用数据仓库和多维数据库存储
数据量加大是一定要考虑OLAP的，传统的报表可能5、6个小时出来结果，而基于Cube的查询可能只需要几分钟，因此处理海量数据的利器是OLAP多维分析，即建立数据仓库，建立多维数据集，基于多维数据集进行报表展现和数据挖掘等。
16使用采样数据，进行数据挖掘
基于海量数据的数据挖掘正在逐步兴起，面对着超海量的数据，一般的挖掘软件或算法往往采用数据抽样的方式进行处理，这样的误差不会很高，大大提高了处理效率和处理的成功率。一般采样时要注意数据的完整性和，防止过大的偏差。笔者曾经对1亿2千万行的表数据进行采样，抽取出400万行，经测试软件测试处理的误差为千分之五，客户可以接受。
还有一些方法，需要在不同的情况和场合下运用，例如使用代理键等操作，这样的好处是加快了聚合时间，因为对数值型的聚合比对字符型的聚合快得多。类似的情况需要针对不同的需求进行处理。
海量数据是发展趋势，对数据分析和挖掘也越来越重要，从海量数据中提取有用信息重要而紧迫，这便要求处理要准确，精度要高，而且处理时间要短，得到有价值信息要快，所以，对海量数据的研究很有前途，也很值得进行广泛深入的研究。
摘要：在虚拟现实项目制作中,由于种种原因,海量数据处理是一项艰巨而复杂的任务,本文主要论述了海量数据处理困难的原因,并提出了对海量数据进行处理的方法。
关键词：虚拟现实,海量数据
参考文献
[1]何来坤,徐渊.虚拟现实建模语言VRML及其应用[J].杭州师范学院学报,2005,(2).
[2]金杰.远程教育中虚拟实验与虚拟仪器及技术的运用与前景[J].电脑与技术,2005.
海量数据处理技巧 篇6
1 海量数据发展历史与现状
在当今的信息化时代, 信息量过大已成为我国各行各业所必须面对的问题。如何在庞大的信息中寻求对企业或者个人有用的信息来推动经济的发展, 已成为我国学者所共同关注的问题。要想让信息资源真正成为一个企业的经济推动因素, 只有通过将信息与该企业的业务发展和战略的运行相结合, 假如一味注重信息的筛选而抛开企业的实际情况来研究, 不但不能提高信息的使用效率, 还会对企业的绩效产生影响。在信息技术如此发达的今天, 企业只有通过完善信息系统的设计开发来制定项目的分析决策, 才能有效应对来自国内国外市场“数据信息量严重膨胀”的压力, 为此, 数据挖掘和知识发现技术在此背景下应运而生, 并且得以持续的发展, 在国家的经济发展中显示出重要的地位, 为企业带来了不可忽视的经济利益。由于篇幅问题, 笔者在此只介绍数据挖掘的相关内涵。
数据挖掘就是从大量的、不完全的、有噪声的、模糊的、随机的数据中, 提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程, 就是从存放在数据库、数据仓库或其他信息库中的大量数据中挖掘有趣知识的过程。在学术界上, 与数据挖掘相关表达还有几个:如从数据库中发现知识、数据分析、数据融合以及决策支持等。人们将原始数据比作形成知识的源泉, 挖掘数据就好像是在矿石中进行采矿一样。原始数据主要有两种类型:一是结构化的, 就如关系型数据库中的数据;二是半结构化的, 就像我们计算机上常见的文本、图形和图像数据, 另外, 分布在网络上的异构型数据也属于半结构化的原始数据。常见发现知识的方法有四种:数学、非数学、演绎和归纳等。通过发现挖掘的知识可以运用于信息管理、查询优化、决策支持和过程控制等方方面面。可见, 数据挖掘是一门综合性的学科, 对于开发数据库和数理统计员等相关工作人员的要求都比较高。
2 海量数据储存与访问问题研究
采用较为先进的数据库管理技术和大容量存储管理技术, 在满足数据查询需求的前提下, 把所需的数据细分为近期、中期和远期三个不同的阶段来进行相应的管理, 常见的做法是, 把访问时间较近和较频繁的数据存储在磁盘阵列中, 并向这部分数据提供相对告诉的访问响应;同理, 把访问时间较远和访问的次数较少的数据存储在保存成本较低并且容量较大的扩展光盘库设备中, 在保证其运行速度不受影响的前提下使系统的运行成本降到最低。为了更好的实现数据储存管理的高效工作, 系统提供了对磁盘、光盘数据的一致性访问接口, 对系统中的数据提供统一、透明的访问机制:计算机系统同时为内部管理机制创造了数据迁移, 确保数据能够从磁盘以较高的透明性迁移到光盘。
目前, 我国对海量数据的访问, 采用比较原始的做法, 由相关的技术工作人员将已经存放至磁带上的数据倒回数据库, 根据数据使用者的意愿来查找所需要的记录, 这种查询方式一般是通过手工来完成也就意味着其运行效率比较低, 对人工成本的依赖比较大。此外, 由于查询范围和时间上都受到其他因素的限制, 历史数据的作用就不太明显。不少用户就希望通过在生产系统外建立起一个独立的历史数据归档和查询系统, 借此系统把历史数据进行自动归档, 并从主机上分离出来, 减轻主机的负担。当时, 这种分离工作要确保历史数据能够单独使用, 被用户直接访问。
3 海量数据的数据库处理研究
如今, 关系型数据库在众多类型的数据库使用得最为广泛, 成为了当今数据库的主流。关系型数据库最初的推出是为了满足基于主机/终端方式的大型机的使用, 因此其应用范围也是相当有限的, 但是随着计算机产业的发展, 客户机/服务器方式逐渐普及开来, 关系数据库便进入了客户机/服务器时代, 并且其发展空间得到极大的提升。随后, 在Internet的普及应用, Internet上信息资源所表现出来的冗杂性和欠规范性, 导致关系型数据库在进入网络市场时表现得较为滞后, 在面对网络上更加庞大的文档型和多媒体型数据资源, 其管理模式显然已无法跟上步伐。直到一段时间后, 关系数据库开始不断完善其自身的发展, 并满足过去的需求上作出了一定的调整, 比方说增加数据库的面向对象成分以增加处理多种复杂数据类型的能力, 增加各种中间件 (主要包括CGI、ISAPI、ODBC、JDBC、ASP等技术) 以扩展基于Internet应用能力, 同时可以利用应用服务器解释执行各种HTML中嵌入脚本的技术, 可以解决Internet应用过程中数据库在显示、维护和HTML格式转换等一系列问题。关系型数据库已经发展为基于Internet应用的模式, 常见的类型有一种三层或四层的多层结构。基于这种多层结构的体系, 关系数据库的发展得到了极大的进步, 解决了Internet应用方面的问题, 将关系数据库稳定地应用于网上各种资源的开发与利用。我国的信息化程度将会越来越高, 相信在不久的将来会有更加完善的数据库来取代当前的关系型数据库, 在迎接新的数据库诞生的同时, 做好信息技术的竞争准备。
4 结语
海量数据技术对于我国经济和社会的发展都起到了促进作用, 同时, 为我国的日常工作带来了极大的方便, 然而, 科技进步无止境, 我们要解决好当前海量数据处理技术上存在问题, 进一步来完善他的发展。
参考文献
[1]赵浩然.论数据分区对海量数据处理的必要性[J].科学之友, 2011 (22) .
[2]周开乐, 丁帅, 胡小建.面向海量数据应用的物联网信息服务系统研究综述[J].计算机应用研究, 2012 (1) .
[3]王桂强.海量数据分析处理方法的研究[D].上海:上海交通大学, 2010.