数据优化处理

数据优化处理（精选10篇）

数据优化处理 篇1

0 引言

近年来,一些数据密集的应用已经广为人知,这些应用中数据的到达非常快速,并且会随时间而变,甚至可能是无法预测的,数据量看起来也是无界的,这样的应用例子有:金融应用、网络监测、安全、通讯数据管理、Web应用和制造和传感网络等。这些应用中,数据源会不断地产生出大量的数据,比如股票交易中,股票的交易数据会不断涌入,这种类型的数据应该被视为易逝的数据流[1]。

在数据流模型中,不支持对部分或全部数据的随机访问,而是以持续数据流的形式到达。概括地说,与传统存储关系模型不同,数据流主要有如下几个方面的特征:

实时性数据流中的数据元素是在线到达的,并要求对它的处理也是近乎实时的;

无序性系统无法控制将要处理的新到达的数据元素的顺序,不论是对一个数据流还是在多个数据流之间;

无穷性流式数据本身就意味着数据量的无限大,而系统存储的数据相对数据流大小则是非常有限的;

瞬时性流中的数据一旦经过处理,要么被丢弃,要么被归档存储。但被丢弃的数据元素可能需要再次被访问。

时序性数据流模型中查询是相对静止不变的,而数据是时刻变化的。

对持续数据流的查询和对传统数据库的查询类似,但数据流模型下的查询具有两个一般数据库系统所没有的特点:

第一个特点是存在一次性查询和持续查询的区别。一次性查询是根据某个时间点数据集的状态计算查询结果,再把结果返回给用户。传统的数据库管理系统(DBMS)查询通常都属于一次性查询。相反,持续查询是在数据流持续到达情况下的持续计算。在数据流模型下,持续查询比一次性查询更普遍,持续查询的答案是基于时间的,它反映了到目前为止已到达的数据流的情况。当新的数据到达时,持续查询的结果可以被存储或更新。有时候查询结果本身也可表现为持续的数据流。数据流模型下一次采用一次性查询还是持续查询,得根据具体应用环境确定。例如,需要多次执行,但每次执行只产生少量的查询结果的聚集查询适合存储数据库模型下的一次性查询;而连接查询往往只需执行一次,但执行一次需要很长时间,并且产生持续的、海量的查询结果,更适合使用数据流模型下的持续查询。

第二个特点是存在预定义查询和特定查询的区别。预定义查询是指在任何相关数据到达前就已经提交给数据流管理系统的一种查询。虽然一次性查询也可以被预先定义,但预定义查询通常是持续查询。与此相反,特定查询是指在数据流已经到达后的在线查询。由于特定查询不能提前预知,因此无法找出不同查询间的公共子表达式从而对查询进行优化;计算特定查询有时需要引用数据流中历史的数据元素,而这些数据很可能已经丢弃了。

此外,传统数据库查询的数据对象是相对稳定的,至少在查询进行的过程中被认为是不变的;而数据流查询的数据对象则不断的变化,持续增长。传统查询执行的过程中可以利用索引、排序或分类等技术对数据对象进行随机存取,查询执行的次数完全取决于应用系统;而数据流查询对于持续输入的数据流只能采取线性扫描算法,在数据对象过期之前进行有限次数的查询[2]。

由于数据流在容量上可能是无限的,为了计算数据流查询的精确结果,所需的存储器容量也会无限制地增长。传统的处理数据集的算法不适合于数据流应用系统,因为它不支持持续查询。由于存储器的容量是有限的,对无限的数据流查询就不可能总是产生精确的结果,用高质量的近似结果来替代准确结果往往是可以接受的。数据流问题的近似算法在近年来已成为一个富有成效的研究领域,这其中高效查询的优化处理就成为其中的一个热点。

1 优化处理算法模块设计

当前数据流系统中存在如下几个显著的特征[3]:

(1)DS系统中存在着大量的查询,系统应该尽快地找到关心该数据的查询。

(2)对单个查询而言最优的查询计划未必对全局来说是最优的。

(3)大量查询中存在着的共同特征,查询分组技术已经在传统DBMS和一些DSMS中被证明为一种非常有效的技术。

(4)数据流系统的执行效率不仅和输入数据的速率有关,还和系统中算子的数量有关,和实际引发的查询的数量有关。如何尽量减少系统中存在的活动算子的数量也是优化需要考虑的一个问题。

基于此,设计优化模块时提出的基本目标就是:充分利用查询之间的共同特征,尽可能在查询之间实现共享;另外,调度器采用高效的调度算法使得运行时的开销最小;追求系统整体性能的提高[4]。

优化处理算法模块的组成结构如图1所示。

图1中查询优化的输入是解析后的查询树。DSMS以访问内存数据为主,且查询的数量非常庞大,因此DSMS系统的主要优化方向是减少DSMS系统中实际引发的查询的数量。连接运算代价非常大,因此DSMS将连接运算向下压,先进行连接运算,多个查询共享一个连接运算,减少了实际引发的连接操作的数量。因此,优化处理模型中的优化首先对连接进行分组,以便较大程度地在不同的连接之间共享中间结果,节约了DSMS系统中最为宝贵的主存资源。完成连接分组后,再对谓词进行分组,将相同结构的谓词组织在一个表结构中,这样实际引发的查询的数量就会大大减少[5]。

2 基于连接谓词约束的等值连接分组算法

目前为止,虽然对连接查询提出了大量的优化算法,但是针对多查询优化的连接分组优化算法却未见应用于数据流系统中,这里实现的是基于连接谓词约束的等值连接分组算法。

2.1 连接分组算法设计

连接分组的输入条件是Get Table Link中的表列和Get Where中的等值连接条件。输出结果是网络节点。如果一个节点表示一个用户查询的话,则就称该节点为终端节点,在用户明确地将查询删除以前,终端节点是不能删除的,与之相对应的是非终端节点,非终端节点没有对应的用户查询,只是保存连接的中间结果,当连接计划改变后非终端节点可能会被删除。我们的连接分组连接结果都只是增加一个基本表(流),采用类似System R优化器的结构,也特别适合流水线处理,而对于数据流来说,所需的处理方式正是流水处理方式。

基于连接谓词约束的等值连接分组算法中,连接运算的优化分为两个阶段;第一阶段为增量分组阶段;每当一个新的查询提交后,系统查找当前存在的分组,检测是否存在一个分组与新提交的查询对应,如果存在则不用创建任何分组,只需要把这个分组的引用次数加一即可;如果不存在则需要创建新的分组与这个查询对应,新的分组可以利用已经存在的分组作为自己实现的一部分。

连接运算查询优化的第二阶段为动态重分组阶段;增量分组对新加入的查询进行分组而不对存在的查询进行重分组,尽管这种查询也是有效的,可扩展的,但是它可能导致只是局部的优化,已经存在的查询没有在新查询加入时为了适应新的全局优化要求而获得重新分组的机会。

随着增量分组的进行,系统中创建了很多分组,但是对当前存在的所有查询来说,有一些分组是不必要的,或者说是冗余的,冗余分组的计算消耗了系统很多资源,因此应该动态地把这些冗余分组删除,重新创建系统的分组图,使系统尽可能地达到全局最优。

2.2 连接分组算法实现

2.2.1 基本数据结构

所有的连接节点在逻辑上是一个有向无环图,图中的每个节点都代表一个分组计划中的一个连接表达式,该节点的结构为:

2.2.2算法表示

1)增量分组Increment Group

输入:int tableids,连接约束A(目前实现的是等值连接),inttime＿t。

输出:目的节点。

示意代码实现如下所示:

该算法的过程是:

Find MaxGroup:用于找到输入的连接对应的最大连接分组,输入是表列tableids和连接约束条件,以及时间窗口。连接的中间结果都是通过索引结构记录下来,因此,Find Max只需按照哈希表的长度由大到小地遍历哈希表即可,一旦找到就停止。由于,目前为止我们规定表的最大长度为10,因此这一步的开销并不是很大。另外,目前的连接约束条件只包含等值连接,只有符合约束的连接才会被用到。

Get Constraint:得到节点B的连接约束条件,B是A的一个子集。

Get Left Table Id:得到剩余表的列表。

Ramdom Join:利用约束条件Left Constraint在node和剩下的表列随机生成连接结果(也可以按照刷新频率由小到大的次序选择基本表)。

2)动态重分组Re Group

当系统经过一段时间时,查询有的是新加入的,有的则运行一段时间后便从系统中注销,因此这时候系统的状态不一定是最优的。因此,运行一段时间后就需要对系统进行重新分组。

输入:不同长度的哈希表。

输出:重新分组优化后的查询网络。

动态重分组中,首先按照长度从大到小的规律遍历哈希表,因为终端节点是不能删除的,因此首先检查每个终端节点,如果该终端节点的父母节点的孩子节点不是此终端节点,就用子节点代替这个孩子节点,代替的过程同时检查约束条件,只有符合约束条件才能替代。检查完终端节点后,再检查非终端节点,如果发现非终端节点的引用计数等于零,就将其删除,因为已经没有父母节点引用该节点的结果了。

由于动态重分组每次都遍历哈希表,因此代价很高,可以在系统空闲的时候进行这个操作。

3 谓词分组算法

谓词分组技术在很多系统中都有应用[5],将具有相同结构的过滤条件组织在一起(通常采用索引),当数据到来时,对该分组进行过滤操作,使用高效的组织手段,因此分组过滤操作执行效率可能会比较高(相对于单独执行时)。

Argus系统中谓词分组的输入是连接分组的结果网络节点和查询解析器解析的Wheres子句的内容,它将结构相似的谓词组织在一个称为常数表的结构中,当数据到来时查找该常数表,然后找到其目的节点。

下面我们讨论一下谓词的标记以及常数表的结构和基于常数表的连接算子。

3.1 谓词的标记

为了更简便,我们以下面的两个查询为例子来说明谓词的标记:

查询1:

我们比较一下这两个查询,两者的其它部分都相同,唯一不同的就是选择常数一个是pku,另外一个是nju。我们称这两个查询的标记相同。谓词的标记由下面几个部分生成:数据源,关系操作符。

3.2 常数表结构

常数表就是存放相同查询标记的查询常数值的一个结构。常数表的结构如表1所示。

常数表的第一列是常数值,第二列是引用次数,比如可能有两个查询的常数值是“云计算”,这个“云计算”的引用次数是3,第三列是目的算子的地址。

3.3 算法实现

在对数据流管理系统模型进行多查询优化时,预先对数据流进行连接,其实现如图2所示。

图2中每条数据流都有多个谓词分组,一个谓词分组对应一条或多条(有部分重复的)查询。再通过这些谓词分组生成查询计划,使整体代价较小,并且记录或删除查询不需要更改其它查询的谓词分组[6]。

算法的实现包括查询的更新和撤销两部分。算法的更新查询部分复杂度为O(n×m3),其中n为两流之间最大的不同连接因子数,m为数据流的查询连接数。而算法的撤销部分复杂度为O(m)。由于参与连接的数据流一般不会太多(少于10条),所以记录和撤消查询的算法复杂度是可接受的。

谓词分组算法的过程是:首先根据pre＿node和pre＿node的谓词找到对应的常数表,用哈希表保存常数表的地址,因此查找的速度通常会很快。如果没有对应的常数表,则创建一个常数表Create Table。然后在该表中查找是否具有取值等于过滤常数的一行,如果没有,则新生成一行,直接插入,并返回插入新行的目的网络节点的地址。如果找到对应的行,则将该行的引用计数值增1,然后返回改行对应的网络节点的地址。

3.4 常数表连接算子

由于有了常数表将所有结构相同的查询组织在一起,这样每次流A中的数据到来的时候,不用分别每次调用Filter算子,只要根据元组的相应列在常数表中查找就是了,将该查找工作用一个特定的算子Join Const实现。元组是以队列的形式存放的,和常数表的结构类似,该查找操作和连接操作很相似,我们称之为常数表连接算子Join Const。

4 实验及结果分析

查询优化的输出是查询网络,底层的调度器调度该网络上的算子节点。查询用测试用例如下所示:

4.1 实验参数说明

1)查询的总数N系统中注册的连续查询的总数量,是系统扩展性的一个重要量度。

2)算子的数量系统中存在的算子的数量。由于大量的查询可能会共享相同的算子,因此如果优化器能够实现这些计算之间的共享,算子的数量并不会和查询数量成正比。

3)数据源生成数据的速度当数据源的速度过高时可能会超出系统的处理能力,使得元组积累,内存消耗增加,从而性能急剧降低。因此采用了模拟的数据源,使数据生成速度随时可调。

4.2 优化前的算子数量对比优化后算子的数量

优化算法分别对连接和过滤操作进行分组,图3所示表示了改进前后算子数量的变化情况。

图3中由于结构相似,每个查询都会分解为数目相同的算子,因此未优化时算子的增长为直线。在采用优化方案后,由于大量的过滤算子共享同一个常数表连接算子,因此算子的数量增加很缓慢,当查询的数量足够多时(例如大于400),则算子呈直线上升,斜率约等于1,即只是增加每个查询的Map算子(投影共享),其他算子增加幅度相对减少。

另外,在很多的连接查询条件下,一条查询的优化可能会牵涉到其它许多的查询,迫使它们修正正在执行的查询计划。而查询计划的调整是非常复杂和耗资源的。这种情况在记录大量查询并频繁更新的数据流管理系统是不愿看到的[6]。如果记录查询的数量是n,本优化算法复杂度为O(lnn),而且对一条查询的优化对一条查询的优化基本不会牵涉到其它查询,性能也在可接受的范围内。

本文提出的高效查询优化处理算法的优化很简单,对一条查询的优化基本不会牵涉到其它查询。为考察该算法的性能,设计了一个实验模拟数据流的连接查询,实验结果与预期的基本吻合,有效地验证了算法的性能。本算法同样适用于硬件处理的查询计划生成,因硬件希望查询计划相对稳定。当然,它更适合应用于查询的更新频率很高的系统。

5 结语

详细讨论了用于高效查询的优化处理模型的算法。该算法的追求目标是尽量在查询之间的共享计算,优化算法采用的主要方法是分组,包括连接分组和谓词分组,分组方法是基于索引的。连接分组在大量的连接之间共享中间结果,一方面减少了内存需求,另一方面减少了连接的计算量。谓词分组将标记相同的谓词组织在一起,采用常数表将其存储起来,这样,多个过滤操作转化为数据源和常数表之间的连接操作,大大减少了系统引发的数量,并减少了系统的存储空间。

实验结果表明,本查询子系统在效率和资源节约上都取得了比较好的效果,初步可以应对网络环境中海量用户查询的挑战。

数据流产生的数据是有始无终的,而且很多环境下查询的数量是海量的,从而对硬件的资源要求很高,这就和我们有限的硬件资源产生了冲突,因此,数据化简技术也成为人们关注的焦点,数据化简技术的目标就是在查询准确性和硬件资源之间取得权衡,如果能够高效地将这些技术应用到DSMS中,会给DSMS提供更强大的效率和功能。

摘要：提出一种新颖的优化方案。方案采用了查询谓词分组和连接分组技术,在众多的查询之间实现了计算共享,较大地节约了系统中存在的算子的数量并提高了处理速度。连接分组首先检查系统当前有无可以利用的中间结果,在这个基础上进行后续连接操作。谓词分组将相同结构的谓词组织在一起,通过引入常数表的这个数据结构将这些查询组织在一起,并将多个过滤操作转化为连接操作,减少了过滤算子的数量。实验结果表明,该方法不仅节约了内存空间,而且还较好地提高了系统的运行效率。

关键词：数据流,滑动窗口,连接分组,常数表,谓词分组

参考文献

[1]左利云,马英杰.基于数据流处理模型的多查询优化算法[J].计算机工程与科学,2009,31(3):71-74

[2]陈磊松.面向高速网络的数据流处理模型研究[J].漳州师范学院学报:自然科学版,2006(2):31-33.

[3]谭博阅,刘宁.数据流中的近似查询技术[J].世界科技研究与发展,2006(4):57-60.

[4]Silberschatz A,等.数据库系统概念[M].杨冬青,唐世渭,等译.北京:机械工业出版社,2000.

[5]游凤荷,黄樟灿,李亮,等.具有物理模型数据处理的多目标优化及其算法[J].武汉大学学报:理学版,2001,47(1):57-60.

[6]左利云,马英杰.基于数据流处理模型的多查询优化算法[J].计算机工程与科学,2009,31(3):71-74.

数据库的查询优化 篇2

关键词：数据库系统；OLTP；查询优化

中图分类号: TP311文献标识码: A文章编号：1009-3044(2007)16-30938-02

Database Query Optimization

LIPeng

（Liaodong university, Dandong 118001,China）

Abstract:Database system is the key of the management information system ,Based on the database of online transaction processing (OLTP) and online analytical processing (OLAP) are the importantcomputer application of banks, enterprises, business, and government departments. While the SQL statement Submitted by the users is the basis for system optimization. How to design effective and reasonable query is very important. This paper supposes some query optimization experiences based on years of database application development.

Key words:Database system;OLAP;query optimization

1 引言

数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理(OLAP)是银行、企业、商业、政府等部门最为重要的计算机应用之一。从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。如果数据的量积累到一定的程度，比如积累到上百万甚至上千万条记录，全表扫描一次需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，可以使查询时间降为几分钟，由此可见查询优化技术的重要性。

在应用项目的实施中，许多程序员在利用一些前端数据库开发工具（如PowerBuilder、Delphi等）开发数据库应用程序时，只注重用户界面的华丽，并不重视查询语句的效率问题，大量的使用通配符，隐式转换，过分依赖算子IN、BETWEEN等。导致所开发出来的应用系统效率低下，资源浪费严重。许多程序员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是错误的。查询计划是用户所提交的SQL语句的集合，查询规划是经过优化处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。在实际的数据库产品(如Oracle、Sybase等)的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表所得到的信息来估计不同的查询规划的代价，然后选择一个较优的规划。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL语句是系统优化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效。因此，如何设计高效合理的查询语句就显得非常重要。

2 优化方法

针对以上的问题，结合在数据库应用程序开发实际经验，本文就查询优化问题,谈点实践体会。

2.1 查询优化一

在SELECT/INSERT语句中，必须记述选择表（项目名）。选择表中禁止使用通配符（*）。假如处理A改变表T，在表增加了项目X（or变更or删除）。对同一表T进行访问，与项目X无关的处理B的程序就发生错误。也就是说维护性不好。

差例：

SELECT * FROM epc_tbl1；

INSERT INTO epc_tbl1 VALUES(1，2，3)；

良例：

SELECT cd_col1，cd_col2，cd_col3 FROM tbl1；

INSERT INTO epc_tbl1(cd_col1，cd_col2，cd_col3) VALUES(1，2，3)；

用SELECT语句指定的列，限定使用在这种处理中。

2.2 查询优化二

给SELECTDE的项目名起一个表别名（Alias）。为了减轻ORACLE的解析负荷，SELECT的项目名必须做到以下两点。但在单一表中使用SELECT时除外。用table、cloumn的形式指定项目名。table名中尽量使用短的别名（Alias）。

差例：

SELECT nm_ename，nm_dname FROM epc_emp，epc_dept WHERE ～；

良例：

SELECT e.nm_ename，d.nm_dname FROM epc_emp e，epc_dept d WHERE ～；

2.3 查询优化三

在WHERE语句中不要让函数和算子纠缠在INDEX项目中WHERE语句中的INDEX项目成为运算对象，放在函数中或NULL值进行比较时都不能作为索引检索的对象，而成为发生全表扫描的原因。这样性能会变得很糟，因此要十分注意。如在可能成为影响性能的地方，这些问题不可避免的话，就要重新研究处理要件与表设计的合理性。

差例：

～ WHERE nu_sal_nn * 1.1 > 950；（nu_sal_nn是INDEX项目）

～ WHERE TO_CHAR(dt_hire_nn，'YYYY/MM/DD') = :i_dt ；（dt_hire_nn是INDEX项目）良例：

～ WHERE nu_sal_nn > 950 / 1.1；

～ WHERE dt_hire_nn = TO_DATE(：dt,'YYYY/MM/DD')；

不得已必须使用时要与开发责任人商议。

2.4 查询优化四

不依赖算子IN、BETWEEN。为了减轻ORACLE的解析负荷，尽量禁止使用算子IN、BETWEEN。

差例：～ WHERE nm_ename IN ('SMITH'，'KING'，'JONES')；

～ WHERE nu_sal BETWEEN 2000 AND 3000；

良例：～ WHERE nm_ename = 'SMITH' OR nm_ename = 'KING' OR nm_ename = 'JONES'；

～ WHERE nu_sal >= 2000 AND nu_sal <= 3000；

2.5 查询优化五

避免隐式转换。在WHERE语句中对字符列项目不做单独引证就进行字符列比较的话就是隐式转换，这样有时不能进行索引检索。

差例：SELECT e.nm_ename FROM epc_emp e WHERE nm_job = sales；

良例：SELECT e.nm_ename FROM epc_emp e WHERE nm_job = 'sales'；

但在程序中应不使用有单独引证包围的字符列，而应该提前进行常数定义，再进行与该常数的比较。

2.6 查询优化六

不要无谓地反复选择同一条件的行。一旦把SELECT 的行作为UPDATE/DELETE 对象时，性能发挥作用后可利用ROWID 使ORACLE不做不必要的检索动作。

差例：SELECT nm_ename，nu_sal FROM ～ WHERE no_empno = ：i_empno AND ～；

UPDATE ～ WHERE no_empno = ：i_empno；（但如从代码的易见性、维护性出发设定了有效的索引，也可以采用这种写法）。

良例：SELECT nm_ename, nu_sal，ROWID FROM ～ WHERE nm_empno = ：i_empno AND ～；

UPDATE ～ WHERE ROWID = ：i_rowid；

2.7 查询优化七

不要根据INDEX项的NOT EQUAL进行评判

差例： ～ WHERE no_deptno <> 30；

良例：～ WHERE no_deptno > 30 OR no_deptno < 30；

不要根据INDEX项的IS NULL进行评判，不要根据INDEX项的 %LIKE% 进行评判。

2.8 查询优化八

不要使用HAVING语句。在下述的差例中可以看出处理选定的全行内容，与此前使用WHERE语句作出的良例相比，处理负荷大了。

差例：～ GROUP BY nm_regionHAVING nm_region <> 'SYDNEY' AND nm_region <> 'PERTH'；

良例：～ WHERE nm_region <> 'SYDNEY' ND nm_region <> 'PERTH'GROUP BY nm_region；

2.9 查询优化九

从NOT IN 开始也要使用NOT EXISTS。不要进行使用NOT IN 的内部分类合并。

差例：SELECT e.no_empno FROM epc_emp e WHERE e.no_deptno NOT IN(SELECT d.no_deptno FROM epc_dept d WHERE d.nm_loc = 'OSAKA')；

良例：SELECT e.no_empno FROM epc_emp e WHERE NOT EXISTS(SELECT 'X' FROM epc_dept d WHERE d.no_deptno = e.no_deptno AND d.nm_loc = 'OSAKA')；

2.10 查询优化十

从EXISTS开始也要使用JOIN。从副查询开始也要使用JOIN。

差例：SELECT e.nm_ename FROM epc_emp e WHERE EXISTS(SELECT 'X' FROM epc_dept d WHERE d.no_deptno = e.no_deptno AND d.nm_loc = 'OSAKA')；

良例：SELECT e.nm_ename FROM epc_dept d, epc_emp e WHERE e.no_deptno = d.no_deptno AND d.nm_loc = 'OSAKA'；

2.11 查询优化十一

INDEX的顺序与汇总。要对某个表，在不同的检索条件下进行高效的SELECT就必须对各个检索条件设定适当的INDEX。但是如果对一个表设定太多的INDEX，就会出现类似更新的总开销增大等的弊病（标准要设为三种）。按A，B，C项顺序排列的INDEX对下述检索要求有效。对这些检索要求没必要另外设定对应的INDEX。

只以项目A为关键字的检索。

以项目A和B为关键字的检索。

以项目A、B、C为关键字的检索。

但是，INDEX的项目排列顺序不同的话，有效的检索条件也会不同，这一点要注意。（在上述例子中INDEX的项目排列如果是B，A，C的顺序，那么在项目A的单独检索中INDEX就无效）。项目A，B使用的INDEX在以下条件时可以代用项目A，B，C使用的INDEX。

在A，B项目中的选择性高（缩小到5%以下）在A，B项目中缩小的数据绝对量少（50行以下）。

3 结论

以上着重从实现的角度讨论了查询优化,实际上要想根本解决查询优化问题,还需从设计上进行优化,如尽量使用大的内存,数据可适度冗余,库结构优化,对于频繁使用的表建立索引,面向对象的数据库设计方法等等。

参考文献：

[1]萨师煊，王珊.数据库系统概论[M]. 北京. 高等教育出版社，2004:190-215.

[2]王能斌.数据库系统原理[M]. 北京. 电子工业出版社，2000:157-190.

[3]吴胜利，王能斌.面向对象数据库的查询优化[J]. 软件学报，1997(8-2):27-29.

数据优化处理 篇3

随着移动网络的迅速发展，网络的服务质量越来越受到人们的关注。一方面移动用户数以惊人的速度发展，另一方面网络规模也在扩大，网络资源逐渐匮乏，会不同程度地出现覆盖不足、干扰严重、容量溢出等问题，从而影响网络质量的提高。如何提高网络质量，已成为网络运营商的首要任务。

无线网络优化对当前网络进行数据采集、数据分析、找出影响网络运行质量的原因，并通过调整参数和设备，使网络达到最佳运行状态，使现有网络资源获得最佳效益，同时对网络维护和规划提出合理建议[1]。由于网络优化处理的数据量大、种类繁多、指标和参数之间关系复杂，需要对有些数据做提炼、加工、汇总和规划整理这样的预处理，生成符合规范要求的数据集合。若初次预处理结果和预期结果相差甚远，还需二次预处理。

根据网络优化中的数据特点，提出一种数据预处理模型，利用SQL Server 2000中的ETL工具对数据进行预处理，提高数据利用率，为以后的网络优化工作奠定基础。

2 无线网络优化流程

目前，网络优化主要依赖设备商提供的优化思路和优化人员的经验，并主要通过手工方式进行分析，这已经成为制约网络性能快速改善的瓶颈。中的无线网络优化是对网络中的前台测试数据，基站后台数据以及系统配置数据等信息进行采集、分析，对当前网络进行评估，快速定位网络故障，及时调整网络配置参数，保证网络正常运行，提高网络性能的目的，同时总结优化经验，完善优化方案库，提高优化质量。其工作原理如图1所示。

3 源数据分析

网络优化中的数据主要包括3种：系统配置数据、基站(BS)后台数据、测试数据。

系统配置数据：主要是GSM网络优化系统运行环境的配置，即在PC平台上建立虚拟的移动通信网络，包括网络结构、无线环境、话务量(用户)分布等。网络结构及无线环境数据由网络运营商提供，话务量的数据采集内容主要是评判网络性能的主要指标：包括接通率、信道可用率、掉话率、拥塞率、话务量和切换成功率等。这些数据基本都是以数据表格的形式存储。

基站后台数据：后台数据应进行分类，可分为两类：参数类和指标类。参数类作为本系统的输入参数，指标类实际为基站后台分析软件的输出结果，导入数据是系统的输入，也可作为系统分析的结果。以上所有参数应根据需要进行分类，即按其在系统运行或者分析过程中的地位进行分类。

测试数据：测试数据要根据话务统计分析的结果进行路测。借助工具结合地理信息进行测试。需要测试的主要内容有：小区覆盖测试、呼叫通话测试、扫频测试、场强测试、干扰测试、切换测试等;需要测试的主要参数有：话音质量测试(主要以用户的主观测试为主，分为7个等级)、载波干扰比、领小区场强、掉话数，以及测试路线区域内各个基站的位置，基站间的距离等。通过路测数据可以判断无线小区的实际覆盖范围及干扰区，分析干扰源等。

通过分析可以发现网络优化中原始数据有以下特点：

(1)数据在未装载入数据仓库前，存在数据库设计不规范，数据不完整，在某些字段有空值等问题。所以对这些数据主要进行一些转换和集成工作，对空值字段要进行填充。

(2)各个小区关于小区信息在结构上基本相同，但在数据一致性和完整性上相差甚远。比如有些小区的地理经纬度在表中有表示，而有些小区却只有地理位置表示。

(3)来自不同小区的参数或指标采用不同的表示方式。如小区广播信道字段有些用“yes”和“no”来表示，有些用“1”或“0”表示。

(4)不同厂商对每一个指标的取值范围规定不同，在装入数据仓库前必须进行统一规范。

(5)不同厂商对网络规划数据和实际路测数据格式不统一，要对不同厂商的数据进行转换，转换成标准数据，否则数据有可能读出，有可能读不出。

(6)各个数据表中或多或少都含有冗余或噪声数据，装入数据仓库前要进行数据集成。

(7)每次网络优化结束后，个别小区新增加邻小区，这些都需要添加进来，供下次数据预处理使用。

4 数据预处理

通过对网络优化中源数据的分析，提出了一种数据预处理的模型，如图2所示。该模型对应了两个过程：一个是数据仓库的建设过程，另一个过程是数据预处理的过程。

由于篇幅有限，只以部分数据为例，表1为A小区的基本信息，其中存在数据不一致、数据空缺、数据冗余等问题，可见原始数据不能直接使用，必须要通过预处理，使之变成满足要求的数据。数据预处理分为4个阶段：数据抽取、数据清理、数据集成和数据转换。数据预处理后的结果如表2所示。

(1)数据抽取将网络评估和网络优化数据导入到数据仓库中。网路评估数据包括OMCR数据、网规数据、路测数据、网络评估标准;网络优化数据包括干扰分析参数、硬件故障参是数、话务均衡参数、无线信道利用率参数、拥塞分析参数、覆盖分析参数、通话质量参数、接通率参数、切换参数等。

(2)数据清理包括对缺失值的处理、噪声数据的处理。对于数据缺失值，使用默认值、中间值、平均值对缺失的数据填充，如表1中XA0303_2小区天线增益有缺失值，其所属基站的天线增益平均值为35,XA0303_2小区的天线增益可以用平均值35填充。若无平均值，可以查询表属性，用默认值代替。在噪声处理上，主要采用平滑处理，将连续数据离散化，增加粒度。如表1中人民医院基站的天线增益值存在空缺值，可以用存在值15平滑。

(3)数据集成的目的就是将这些不同数据源汇总为统一的数据实体。在数据集成中，需要考虑的问题有：

1)实体识别问题：如何确定两个表中BTS_id和btsId指示同一概念基站代码，通常的解决办法就要通过数据仓库中的元数据或同源数据的业务人员进行交流。

2)数据值冲突问题：对基站代码和小区代码编号要形成统一的原则，表1中人民医院小区和图书馆小区要使用统一编码规则，按照一定顺序进行编码，换句话说，每个小区的代码都是唯一的，不能一个代码对应两个小区。

3)冗余问题：基站代码这个字段可以从小区代码中间接获取，所以在表1中该属性就显得重复，可以选择删除此属性。

4)数据转换包括数据规范化。表1中A小区的掉话率、接通率、切换成功率、SDCCH拥塞率都以百分号形式表示，不方便查询，可适当扩大100倍，使之落入区域[0,100]，规范化数据取值。

5 结语

通过对网络优化中源数据的详细分析，根据网络优化中数据的特点，给出了数据预处理技术在网络优化中的使用方法。每种预处理技术可分开使用，也可结合使用。如果初次数据预处理结果与预期结果有一定的偏差，则要进行二次预处理，修正初次预处理的结果。做好数据预处理的工作对网络优化后期的工作也起到了事半功倍的效果。

参考文献

[1]石海军.移动网络优化的若干研究[J].电脑与电信,2006(5):48-49.

[2]胡瑶,段鹏瑞,高文昌.网络优化的数据处理平台[J].中国无线电,2004,11:43-44.

[3]罗红,张海旸.专家系统在移动网络优化分析中的应用研究[J].计算机应用研究,2005(6):98-100.

[4]彭高辉,王志良.数据挖掘中的数据预处理方法[J].华北水利水电学院学报,2008,12:61-63.

[5]沈睿芳,时希杰,吴育华.基于数据仓库的数据预处理过程模型[J].计算机与数字工程,2005(9):73-76.

[6]沈晨鸣.基于数据仓库的数据预处理模型的算法研究[J].淮阳工学院学报,2005,14(5):44-46.

[7]JiaweiHan,Micheline Kamber.Data Mining Concepts andTechniques[M].北京:高等教育出版社,2001.

[8]刘明吉,王秀峰,黄亚楼.数据挖掘中的数据预处理[J].计算机科学,2000,27(4):54-57.

优化人才管理，多让数据说话！ 篇4

在人才短缺时代，人才管理越来越精益化，不能仅靠直觉和经验做判断，需要有依据地开展人才管理实践，围绕企业战略目标，最大限度地挖掘和释放人才潜能。随着大数据时代的到来，人才管理部门更加重视人才分析了。

实际上，不仅仅如此，很多企业基于样本的数据分析，同样也起到了辅助人才管理决策的作用。如苏格兰皇家银行（Royal Bank of Scotland）、谷歌（Google）、脸谱（Facebook）等都有这样的做法。人才分析就是运用与人有关的数据，帮助企业在多个层面上实现最大的产出。但仅提供数据分析是不够的，人才管理部门还要给出行动建议，帮助业务部门解决问题。在分析的基础上，我们需要摒弃之前自认为正确的做法，积极探索有更大产出的做法。

比方说，在校园招聘时，许多公司会青睐那些具备一流学术记录的名校生，但是，AT&T和Google的量化分析发现，应聘者的主动性（take initiative）远比这些更能预测工作绩效。有了这样的数据化证据，就会从背景信息导向的评估转向基于胜任力的评估。类似的，加拿大皇家银行（Royal Bank of Canada）为了在招聘过程中找到高素质、复合型的多元化人才，在应聘者的初选中，他们要求应聘者不要提及自身的教育背景和毕业院校，从而避免招聘者对应聘者产生偏见。

人才分析可以贯穿人才从进到出的整个周期。目前，领先企业的实践中，在多个领域得到了广泛应用。

给人才“画像”

人才“画像”，就是界定在特定角色或岗位上表现优异的个人特征，这是人才管理的基础。高绩效人才的特征是什么，高潜人才的特征是什么，之前更多是靠直觉和个人经验来决定的。有了人才分析，就可以通过数据，更加精准刻画特定人才的特征。

谷歌人力运营部门专门成立了一个人力分析团队，于2009年启动了氧气项目（Project Oxygen）。该项目第一阶段，通过多变量统计分析，识别出了一名优秀管理者的八个关键行为：

是一名好的教练

授权于团队，放弃微观管理

关注并关心团队成员的成功及个人福祉

工作富有成效且以结果为导向

是一名优秀的沟通者，擅长倾听并分享信息

帮助员工进行职业规划和发展

对于团队愿景及战略有清晰的规划

具备关键的技术能力，能够给予团队建议

针对每项指标，还有相应的问题来评估。如对于第一项：“是一名好的教练”，有如下由员工来回答的三个问题来评估：

你的经理是否及时地提供了具体反馈信息？

你的经理是否定期和你做了面对面的谈话？

你的经理是否能够给你提供建设性的意见？

通过数据分析证实了管理的价值，引导管理者重视人的管理，并根据关键而具体的管理行为来指导管理者自我提升;全面地了解管理的职责，并据此设计培训项目，提升中小型团队领导者的管理能力。

衡量招聘质量

衡量人才招聘工作，有补缺时间和单位成本等指标，但最重要的指标是招聘质量：能不能胜任工作，有没有高的绩效表现，愿不愿意长期留在公司。

在招聘环节，哪类人才更容易获得用人部门的青睐？这也是人才分析的主要内容。某著名跨国公司的招聘部门通过数据分析发现，在社会招聘中，用人部门面试通过率最高的人才有三个特征：毕业于名校、硕士、工作年限在五年以内。在接下来的工作中，招聘部门重点吸引具备以上特征的人才。

在人才甄选时，越来越多的企业开始使用人才测评工具。美国领先企业中有80%的公司使用测评工具，其中，多数是用在高管人员身上，其次是高潜人才。

为了提高人才甄选的准确性，在实践中，需要选择和开发质量更高的人才测评工具。衡量测评工具的质量，最重要的指标是预测效度，即候选人测评结果和其未来工作表现的相关性，用效度系数来表示。现实中习惯使用的人才测评方法不一定是预测效度高的工具，比方说非结构化的面试。大量实证研究已经证明，非结构化面试的预测效度不理想，效度系数很难达到0.2。而结构化面试，其效度系数平均为0.4左右，甚至更高。结构化面试的预测效度是非结构化面试的两倍，但实践中非结构化面试仍然大行其道。结构化面试需要精心设计，包括测评维度、面试题目、评分参考、一致的实施程序等，这都以工作分析为基础。非结构化面试比较随意，不需要做很多前期工作，且灵活性大，用人部门往往对自己的“相马”才能过度自信，提问题不愿意受到约束，喜欢在天马行空的聊天过程中来评价人。

将多种预测效度高的测评方法整合起来应用，往往会提高选才的准确性。谷歌公司，就是将基于过往行为和假设场景的结构化面试与认知能力评估、责任心测试和领导能力测试结合在一起使用。

随着互联网的普及，大数据分析成为可能。比如：通过分析用户在社交平台上或者在公司内部通讯系统中交流时的语言习惯，来推断人的性格、价值观和需求等。

提高人才的保留率

企业对关键人才的离职动向非常关注，人才在离职之前一定会有一些信号。要根据员工调查等数据的挖掘，分析不同类别的人才看重什么，然后提示用人部门采取相应的有效行动，如恰当时机提拔人才或者采取个性化的激励措施，从而提高人才的保留率。为了提高人才敬业度，或许还需要根据数据分析，决定砍掉一些起反作用的制度。

企业在人才发展方面投入了巨大的费用，但是，哪种发展方式最有效？哪种方式和组织目标的达成几乎没有什么关联？人才分析在这些方面也会发挥作用。我们在2014年的调查发现，尽管大家都不认为课堂培训是有效的领导力发展方式，但是，在实际中运用的发展方式中，课堂培训还是被排在了第一位。如果有充分的数据证明存在更有效的方式，我想，企业决策者一定会作出新的选择，比如会选择群策群力研讨实践问题的方式、复盘的方式等。

通过数据分析，研究高绩效者的行为模式，然后，在人才发展中，指导培养对象采取新的行为方式，比传统课堂培训的实际效果明显要高。我们在为一家银行培养客户经理时，就专门分析了绩优客户经理和普通客户经理的行为差异。比如：绩优的个人业务客户经理，主动和客户进行非工作交流的比例明显高于普通客户经理。接下来，在培训和辅导中，就强化客户经理的这种行为。再比如：我们也研究过银行网点行长这个岗位，那些业绩持续好的网点行长，往往会平衡内部管理和外部营销，而不是那些仅仅注重外部营销的人。在网点行长培养项目中，要强化提升带团队、抓管理的能力。

提前做好人力资本投资

人力资本投资分析，其作用是帮助企业搞清：做些什么对业务表现会产生最大影响。比如：很多服务型企业的数据分析发现，员工满意度高的业务单元往往会有更高的营业收入、更低的成本、更高的员工保留率和优质客户的忠诚度。因此，在提高员工满意度方面的投资，对业务会产生非常显著的推动作用。另外，杰出人才的绩效往往高于平均绩效的若干倍。这就提示管理者要花大价钱招募优秀人才，激励、培养并留住这类人才，这才是最值得做的人力投资！

那么，开发定制的建模工具，提前预测各业务单元何时该增员，何时该减员，建模时会考虑离职、内部晋升与转岗、业务发展机会等信息。从中国企业的现实情况来看，一把手最关注的还是组织内中高级管理职位的继任者，一旦出现这类人才的断层，对业务的影响立竿见影。因此，如果人力部门做不到整体的人力预测，至少要根据数据分析，做到关键岗位的预测和规划，并通过外招和内培，以及人才保留政策，及早做好关键岗位的人才储备。在中国，国有企业往往出现某个较长时段不进人的情况，若干年后，结果就会导致关键人才严重断档的现象。如果能够提前预警，就会有时间做好补救工作。人力规划要实现的目标就是在合适的位置和时间，以合适的成本，获得合适的人才。

当然，要推行基于证据/数据/事实的人才管理，还需要分析文化为支撑。如果一家企业高层不认为数据会说话，更相信自己的经验和直觉，那么实现人才分析的价值，还需要耐心等待。

数据优化处理 篇5

根据《国家电网公司“十二五”信息化规划》的工作要求, 借助于移动作业终端实现现场办公, 一方面通过移动终端方便现场人员及时采集信息, 减少了联合查勘带来的人力资源浪费;另一方面及时将现场作业产生的数据及时登录到系统, 提高数据的正确性和及时性, 为其他业务工作的开展提供了便利。

二、系统数据通信

(一) 系统部署图。如图1所示, 系统的数据在传输过程中需要通过无线网络、防火墙、安全接入网关。同时与各类其他业务系统相连, 包括营销系统、生产系统、电力ERP、一体化平台等各类系统, 数据来源广, 传输路径复杂。

(二) 数据通信中出现的问题。系统需要在不同的业务场景、运行状况下, 即时地展现数据, 现有移动终端中的数据大部分是通过在线请求业务系统获取所需的数据信息, 虽然实时性比较高, 但是相对耗时较长, 并且对业务系统依赖较大, 系统未根据特定的功能需要进行数据分类和分级传输。

由于当前的通信转发环节比较多, 无线网络信号相对不稳定, 易造成网络请求超时现象;并且终端的数据主要来源于业务系统, 当业务系统出现异常时, 移动终端中所对应的功能也就无法正常使用;目前系统的通信通道只有一个, 并且受限于VPN安全客户端, 而VPN安全客户端很不稳定, 经常造成移动终端通信通道的关闭。

(三) 数据分级管理与处理。结合系统对数据进行分类、分级, 将数据类型划分为常量数据、缓存数据和实时数据;对不容易变化的数据常量, 可以通过文件系统直接发布;缓存数据是将实时性较低的数据保存到本地, 并通过空闲时段进行同步传输;召测数据是通过召测系统将用户、变压器等设备的电流电压, 可视化显示出来, 并定时将数据更新同步。

同时已上传的各类数据也进行分类, 分为即时上传数据和空闲上传数据, 即时上传数据是需要即时上传的数据, 这类数据可能影响下一步作业的流程, 如到达现场、位置上报等信息。空闲上传数据是指不需要实时上传的数据, 只在系统空闲时或者网络情况比较好的情况下上传, 这类数据不影响系统的业务流程。

三、数据处理

(一) 常量数据和实时数据的处理。常量数据是指基本不会发生变化的数据, 如组织机构、电压等级、地市编码等这类数据, 写在随终端发布的文件中, 系统可以直接从文件中读取数据, 不需要访问网络或者其它系统;实时数据是指需要实时从后台业务系统中读取的数据, 仍然按照系统原有的方法, 调取相关接口实时处理。

(二) 缓存数据的处理。

1.缓存数据处理总体方案。缓存数据包括静态数据和动态数据;静态数据在服务器启动时自动生成, 以后不再自动检查更新, 由终端手动来检查更新;动态数据包括基础数据和增量数据。基础数据在服务器启动时自动生成;增量数据则定时获取;定期清理垃圾数据。

2.缓存数据分类。如表1所示。

3.缓存方案逻辑结构图。如图2所示, 终端启动应用后, 通过用的部门ID和班组ID获取缓存的数据文件。如果应用牌打开状态, 则每天早晨8点获取增量文件, 如果终端关闭, 则每天第一次启动应用时获取缓存数据文件。

4.静态数据缓存方案。接口服务器启动时, 首先检查是否存在静态数据文件, 如果不存在, 则生成静态数据文件。

5.动态数据缓存方案。服务器启动时或触发定时器时, 将结束时间设置为当前时间。判断上次更新线路数据时间是否存在。

如果上次更新线路数据时间不存在, 设置开始时间为空值, 不作为检索条件。

根据开始时间获取线路的台账数据。如果获取的线路台账数据为空, 处理结束;如果获取的线路台账数据不为空, 以线路ID为单位, 做成线路基础数据文件, 文件名为base.db, 存入serverpath/cache线路ID/目录下。

根据开始时间和结束时间获取线路下的设备台账数据。如果获取的数据为空, 处理结束;如果获取的设备台账数据不为空, 以线路为单位分组, 将数据加入线路ID对应的基础数据文件base.db。

遍历serverpath/cache目录, 根据开始时间、结束时间和线路ID获取间隔下的设备台账数据。如果获取的设备台账数据不为空, 以线路为单位分组, 将数据加入线路ID对应的基础数据文件base.db文件中。

开始时间设置为结束时间-30天 (生产环境-365天) 。根据开始时间和结束时间, 获取运行记录数据。

如果获取到的运行记录数据不为空, 以线路ID为单位分组, 生成运行记录基础数据文件。文件名为runningB ase.db, 放入线路基础数据所在的目录。

如果上次更新线路数据时间存在, 设置开始时间为上次更新时间。

根据开始时间获取线路台账的增量数据。如果获取的线路台账数据不为空, 遍历线路台账的增量数据。如果线路状态不等于0、1、4且存在线路ID对应的基础数据文件, 删除线路ID对应的基础数据文件;如果线路状态不等于0、1、4且不存在线路ID对应的基础数据文件, 继续下一个线路;如果线路状态等于0、1、4且存在线路ID对应的基础数据文件, 更新线路ID对应的基础数据文件;如果线路状态等于0、1、4且不存在线路ID对应的基础数据文件, 新建一个线路ID对应的基础数据文件。

根据开始时间和结束时间获取线路下的间隔台账增量数据。如果获取的间隔台账数据不为空, 遍历获取到的间隔台账增量数据。如果间隔状态不等于0、1、4且存在间隔ID对应的基础数据, 删除间隔ID对应的基础数据;如果间隔状态不等于0、1、4且不存在间隔ID对应的基础数据, 继续下一个间隔;如果间隔状态等于0、1、4且存在间隔ID对应的基础数据, 更新间隔ID对应的基础数据;如果间隔状态等于0、1、4且不存在间隔ID对应的基础数据, 在基础数据文件中增加一条间隔台账基础数据。

遍历serverpath/ache目录, 根据开始时间、结束时间和线路ID获取间隔下的设备台账增量数据。如果获取的设备台账增量数据不为空, 遍历设备台账增量数据。如果设备状态不等于0、1、4且存在设备ID对应的基础数据, 删除设备ID对应的基础数据;如果设备状态不等于0、1、4且不存在设备ID对应的基础数据, 继续下一个设备;如果设备状态等于0、1、4且存在设备ID对应的基础数据, 更新设备ID对应的基础数据;如果设备状态等于0、1、4且不存在设备ID对应的基础数据, 在基础数据文件中增加一条设备台账基础数据。

获取开始时间和结束时间, 获取运行记录增量数据。如果获取的数据不为空, 遍历运行记录增量数据。如果数据在基础数据中存在, 则更新基础数据文件;如果数据在基础数据中不存在;则在基础数据文件中新增数据。将增量数据以线路ID为单位分组, 做成增量数据文件。

将上次更新时间设置为结束时间。

6.数据清理方案。和获取缓存数据采用同一个定时器, 在获取缓存数据完成以后, 做数据清理;数据清理内容:最近30天 (生产环境365天) 以外的运行记录基础数据和增量文件, 还有被删除的运行记录数据。

7.工单记录异步提交。在原有的填写工单记录直接提交, 返回失败或成功消息的业务处理逻辑基础上, 增加功能菜单显示提交排队任务信息, 信息包括提交记录类型、记录内容 (标题) 、提交时间、提交进度条、操作按钮。对提交工单记录采取异步操作, 将编辑提交的记录进行本地化保存并生成提交队列进行排队提交, 而界面仍可以做其它操作, 不需要用户长时间等待网络处理响应, 在提交任务信息栏中对提交失败的任务进行提示, 用户可以进行干预 (对其进行重新提交或者删除操作) 。

四、结语

互联网应用的不断发展, 给电力的生产也带来了深远的影响, 为了充分利用新兴的技术, 提高工作效率, 我们开发了配网移动抢修作业系统;与开发传统的信息系统不同, 在开发的过程中要充分考虑无线网络的不确定性, 对业务数据分类处理是一个很好的选择;通过这一手段, 可以提升用户体验, 让系统运行得更加流畅。

摘要：配电抢修移动作业系统可以实现抢修作业人员现场接收任务, 对任务详情、现场故障、抢修进度以及单线图、设备台账等信息的现场查询和回单操作, 实现现场无纸化办公, 提高了故障抢修及时性, 提高了工作效率。

数据优化处理 篇6

在GPS定位数据处理工作中,占用处理时间最长,工作量最大的是GPS基线解算。基线解算质量的好坏直接影响到GPS网的定位精度和工作效率。因此正确评价基线解算的质量,及时对不理想基线进行优化处理就显得很重要。本文以Gpsadj软件为例,对GPS静态基线解算的质量评价及优化处理方法进行了探讨,以供同行参考。

1 基线解算质量评价要素

Gpsadj软件中,基线解算结果有4项质量指标,即基线解的类型,基线解的方差比值,同步环、异步环闭合差和重复基线长度检核。我们根据这些质量要素对基线解算进行评价。

1.1 基线解的类型

基线向量的解算质量与整周未知数的确定有直接关系。在软件数据处理中,整周未知数是被当作平差计算中的待定参数来加以估计和确定的。解算整周模糊度的能力与基线的长度有关,获得全部模糊度参数整数解的结果称为双差固定解,只获得双差模糊度参数整数解的结果称为双差浮点解,对于较长的基线(30km以上的基线),固定解和浮点解都不能得到较好的结果,可以用三差解。

1.2 方差比值(Ratio)

方差比值是整周未知数固定时次最优固定解的方差与最优固定解的方差的比值;它反映了整周未知数可靠性的高低。方差比值越大,说明整周未知数可靠性越高;方差比值越小,说明整周未知数可靠性越差。

1.3 同步环、异步环闭合差

同步环、异步环闭合差是反映GPS网内符合精度的一项最重要的指标,也是评价组成环路的所有基线是否含有粗差的重要依据。

1.4 重复基线长度检核

重复基线是指同一条基线边观测了多个时段得到的多个基线边。对重复基线边的长度检核也是评价某条基线是否含有粗差的重要依据。

2 基线解算的质量评价

2.1 利用解类型评价

根据相应的《全球定位系统城市测量技术规范》中规定:同一级别的GPS网,在8公里以内的基线必须采用双差固定解;30公里以内的基线,可在双差固定解和双差浮点解中选择最优结果;30公里以上的基线,可以采用三差解作为基线解算的最终成果。如果达不到规范要求,应对基线进行优化处理。

2.2 根据方差比值(Ratio)评价

方差比值是评价基线解算质量的重要指标,比值越高,说明整周未知数确定的可靠性越大。

2.3 根据同步环、异步环闭合差评价

在Gpsadj软件中,每个同步环和异步环都有三个方向的闭合差及边长闭合差和相对误差。GPS测量技术规程对同步环坐标分量及环线全长相对闭合差进行了规定,如果达不到规范要求,应对基线进行优化处理。

2.4 依据重复基线长度检核评价

在Gpsadj软件中,可以查看控制网中所有的重复基线。GPS测量技术规程对不同观测时段的基线边的互差进行规定,差值不应小于相应级别规定精度。如果超限应对含有粗差的基线进行优化处理。

3 基线解算优化处理方法

在基线解算之前,设置好该项目采用的坐标系、控制网等级等属性参数。首先按照Gpsadj软件中的缺省参数对基线进行自动处理,然后打开基线解算结果,查看基线解算情况,对基线质量进行分析评价。当有不理想基线时,应做优化处理,处理方法如下。

3.1确定合适的卫星高度截止角

Gpsadj软件中高度截止角的选择范围在5°至35°之间,步长值为5°。如果解算基线失败,先核实连续观测时间长短、观测卫星数多少和图形强度因子PDOP值大小。如果同步观测卫星数较多(6颗以上)、同步观测时间较长(45分钟以上),可适当增加高度截止角,剔除容易被外界干扰的低空历元数据,采用不易被干扰的且接收稳定的高空历元数据重新进行解算;反之亦然。

3.2 选择合适的历元间隔

历元间隔的大小,决定参与解算的数据量的多少。合适的历元间隔原则为:对基线同步观测时间较短,采集的数据量较少时,可缩短历元间隔,让更多的历元数据参与解算。同步观测时间较长,采集的数据量大,要增加历元间隔,能有效的跳过因为外界干扰而失锁的区域。

3.3 剔除无效历元

通过一个例子来说明这个问题,在相位跟踪图中右键单击鼠标,在弹出的快捷菜单中选择"数据编辑G0013021"。弹出数据编辑框。跟踪卫星的序号在图左端显示。连续线中断处表示当时卫星信号失锁。在数据编辑图中选择工具按钮,然后按住鼠标左键拖拉框圈住图中有数据中断的地方即可剔除无效历元,以灰颜色显示(如图3)。退出数据编辑框,重新解算剔除无效历元后的基线。

3.4选择合适的模糊度分解方法

整周模糊度的解算一般采用整数最小二乘法原理进行解算。常见的方法有:模糊函数法、快速模糊求解方法、最小二乘模糊搜索法、最小二乘模糊去耦调节法(LAMBDA)、整型模糊度求解法等;LAMBDA是其中快速且有效的方法。一般情况下,对于短基线,观测数据量较小时,采用LAMBDA法解算效果会比较好。

4 结束语

4.1 对基线解算质量的评价应全面综合考虑。

4.2 通过基线解算的优化处理,基线精度可进一步提高,但要决定每条基线最终解算是否成功,还必须通过残差分析和同步环、异步环环闭合差分析。

4.3 基线优化处理的前提是要有足够数量的野外健康数据,因此必须保证野外作业的观测时间和观测质量。

参考文献

[1]GPS数据处理软件操作手册.广州:南方测绘仪器有限公司,2006.2

[2]徐绍铨等.GPS测量原理及应用.武汉:武汉大学出版社,2002.10

数据优化处理 篇7

关键词：大规模数据出来,集群,监控,优化

一、需求分析

1.1大规模数据处理需求

大规模数据处理具有一定的优势,并可以实现以下功能:集群部署、数据导入、数据过滤处理。集群部署:即将Hadoop、Spark、和HBase集群分别部署在不同的服务器上。利用其中一台服务器作为主节点,可以对管理文件进行命名并对客户端文件进行相关的访问,同时起到总调度的任务。集群一般是由一台服务器的主节点和多台子节点服务器组成,但是收到实验室的限制,因此只能选择两样服务器进行操作,但是操作原理依然符合上述操作流程,两台服务器起到的作用也不同。在集群配置中,首先需要准备的工作就是对网络环境进行设置和对运行环境进行设置。

1.2集群监控需求

集群监控技术可以更好的满足对各个节点数据的收集,利用集群监控技术可以将CPU的利用率及系统负载情况进行及时的显示。最主要的是可以实现数据的实时更新,在更新的过程中主要涉及以下内容:数据获取的方法、数据传送给客户端、将数据转化为更直观的曲线数据。

二、设计优化

1、数据处理设计。

在原始数据中每一行都包含呼叫用户和被呼叫用户,并现实相关的通话时间和呼叫时间。本文数据设计中所需要的数据是指前三项。主要计算根据是用户的通话时间和次数。1)先对所需要的数据进行初始化设置,并对用户的通话时间进行统计,将统计后的时间放人Page Rank模型中。然后对原始数据进行分析,并对各个号码建立相关的联系。通过Map对原始数据进行分析,输入<call_number,<called_number,call Length>>,其中call_number可以被看做为KEY。时间计量则是value。通过Reduce进行操作,并将上阶段操作中输出的键值和一样的KEY进行合并,将相同的号码的数据进行统计,多时长进行合并。

2、性能监控。

监控的主要原理是通过Hadoop对相关守护进程进行开启,并注册相关的Metrics到本地MBean Server上。在该监控系统中所用到的监控端口包含Name Node的50070端口和Data Node50075端口。而Hadoop本身就自带监控体系,所以访问监控端口时不能直接跳回监控数据中,而是跳到相关的jsp页面。所以,在访问时可以利用JMX体系,并获得集群监控中的所有数据,利用这一体系就建立数据进行获取,不仅可以及时掌握各种信息,同时数据格式也更利于用户进行处理。监控方法有很多种,本文介绍的方法是通过REST形式对数据进行获取。利用这种方式,可以对所需数据进行筛选,只选择自身需要的数据进行了解。

三、实现

1、数据处理。

数据处理的过程中,首先要对数据进行过滤,数据过滤中,输入和输出文件分别为/cdr/raw和/cdr/clear。并利用Spark和Mapreduce对数据进行过滤。最后将过滤后数据结果分别存到HDFS和HBase中。在HDFS中,数据经过过滤并进行储蓄时,其目录名和字段分割格式和导入时的一样。通过相关实验对过滤后的数据进行迭代计算,可以对用户进行分析,并提取有价值的用户。

2、监控实现。

集群监控中的页面主要显示的是集群中的整体情况,并对整体进行分析。其主要内容是对DFS的容量和使用情侣进行分析,并通过反应集群对数据的改变进行实时监控。而节点信息所反映的则是集群中所有的节点基本情况,并通过节点名称进行相应的点击,可以对其信息进行查看。而节点中的主要内容则是上述提起的CPU使用情况,在对数据进行绘制时,以折线图为主,并以每一秒为数据间隔。除此之外,对CUP的使用情况进行评估,在评估的过程其使用变化发生改变时背景色也会发生相应的变化。而在监控中,也可以对集群的整体情况进行相关监控,并对所有CPU数据进行分析和评测,对整体的CPU负载情况进行准确的评估。

四、总结

随着计算机技术的发展,集群性能体系需要不断的优化和建立。本文通过对集群性能的监控情况进行分析,并提出了相应的优化办法,同时也对其监控方向进行阐述。但是收到本文专业和知识的限制,在对其优化的过程中还存在一定的局限性,因此在今后的学习中,会对其优化办法进行不断的改善。

参考文献

[1]王馨曼.大规模数据处理及集群性能监控与优化[D].大连理工大学,2015.

[2]林文辉.基于Hadoop的海量网络数据处理平台的关键技术研究[D].北京邮电大学,2014.

数据优化处理 篇8

随着新型飞机型号研制任务的快速发展和课题需要的变化, 飞行控制系统 (简称飞控系统) 作为新型飞机设计定型试飞中一个必不可少的测试系统, 面临着试飞测试参数的数量和种类不断增加 (以前试飞参数数量至多上百个, 现在已经增加到几千个) 、新型飞控系统采集、记录总线数据的模式由1 流增加到5 流, 试飞模式由单表号试飞变化为一次飞行多个表号试飞。用原飞控系统总线数据处理软件 (原数据处理软件只针对单流数据进行处理、一次处理单个表号试飞数据、数据处理效率较低) 已无法满足新型飞机试飞高效的数据处理需求。因此, 急需优化设计新型飞控系统总线数据处理软件。

1 软件设计

该软件采用结构化、模块化设计思路, 适应性强。软件主要包括配置文件模块、参数校线解析模块、数据处理模块、源码分析模块、批处理模块和故障检查六个模块。

1.1 基本框图

软件结构框图如图1 所示。

软件的基本流程图如图2 所示。

1.2 设计说明

飞控系统采集器一旦确定, 采集的数据块结构就是固定的, 定义如图3 所示。其中数据字0 表示飞控系统的表号。

飞控系统一次飞行可以保存4 张控制表, 在飞行过程中, 通过切换表号, 会采用不同的控制指令工作, 按照飞控系统采集数据块结构特点, 一个起落中的表号可以任意切换, 不影响飞控采集器正常采集数据, 但是对于数据处理来说, 就需要根据表号进行数据提取和分析。

表号的格式定义如图4所示。需要解决的问题如下:

(1) 解决多个表号带来的参数信息正确对应关系, 带头信息中4 个表号的参数信息完整, 根据读入的飞控数据解析出表号, 并选用正确的参数表进行参数的解算, 由于不同表号参数名称、解算方式不同, 因此需要独立的文件输出不同表号的结果参数列, 否则数据难以判读;

(2) 飞控块数据扫描模块优化:飞控块数据不均分布在PCM格栅中, 剔除PCM勤务字后, 才能根据飞控块间隔特征找出飞控块数据, 并对飞控块数据的正确、完整性进行判读, 获取完整的飞控块后, 才可以使用参数校线对飞控数据进行解算, 高效、合理的飞控块扫描和判读直接影响飞控数据处理的效率;

(3) 飞控带头信息管理:飞控参数校准信息的定义、编辑、修改, 原来飞控系统的带头信息只有一路, 目前飞控一个架次有5 流数据需要处理, 除了提高飞控单流数据处理效率外, 多流数据的带头维护需要程序支持, 方便用户一次维护多个带头信息, 支持带头中参数信息的增删改;

(4) 故障原始数据快速定位:支持故障块数据在原始数据中的故障位置, 方便用户进行飞控原始数据的分析, 帮助飞控采集系统进行故障分析;

(5) 多流数据的后期融合:提供数据融合手段, 可以将同流和不同流的多组同一时间段的参数物理量结果信息进行融合, 方便课题进行数据分析。

2 关键技术

2.1 参数文件、校线文件的优化设计

不同的数据流采集的是不同的试飞参数, 不同的表号采集的是不同的试飞科目参数, 每个参数有顺序、字号、名称、类型、校准信息等, 将这么多参数信息写进一个校线文件, 按照软件设计的思路, 采用的存放规则是先按照流数进行存放, 每一流再按照表号进行存放。用三维字符数组来存放不同数据流不同表号的参数, 采用结构体存放每个参数的信息内容。

对参数文件的优化:单机版处理程序采用在参数文件首行加入数据流数来区分每个流的参数文件, 由于每流数据都可能存在多表号, 采用@TAB+表号数+流数@和“@TAB+表号数+流数END@”作为某一流某个表号参数的开始和结束标志。

网络化处理由于所有的处理参数都存放在一个数据库, 不同的表号之间可能会存在相同的参数, 采用“参数名+通道号+表号+流数”进行区分参数名, 读入参数名后, 然后进行拆解流数、表号、通道号并按顺序记录每个参数的信息和对应位置。

2.2 内存映射技术

随着试飞工作的开展, 表号的切换, 一个起落数据量剧增, 原软件对数据文件采用传统的读写文件方式, 由于不断的在内存和磁盘之间进行切换, 频繁地执行IO操作, 因此处理效率不是很高。针对这种情况, 引入内存映射技术, 实现读、写数据都在内存中进行, 避免了上述情况的发生, 从根本上实现了数据处理的高效运行。

按照飞控采集器的数据发送协议, 正常情况下, 飞控采集器在每一时刻发送完所有通道数据后, 才会开始下一时刻数据发送。但是在实际使用中, 经常会遇到同一时刻多通道时间不同步问题。用原处理软件进行处理, 经常会存在漏时刻输出。针对这种情况, 先进行单通道输出数据, 然后再进行多流合并数据, 由于每架次数据量大、数据流数多, 为了实现快速输出, 运用内存映射技术中的内存共享, 将单通道输出数据设置为内存视图文件, 减少输出文件在磁盘和内存之间反复操作, 实现数据块的快速输出。

3 软件验证

首先对软件的功能、效率、正确性、处理异常问题的能力进行了测试, 经过测试改进, 该软件运行正常, 并能够正确的解析飞控系统多流、多表号总线数据。目前该软件已应用到实际的飞控系统数据处理中, 得到课题的一致认可。其软件的运行界面图如图5, 图6 所示。

选取100 个参数, 数据量1.3 GB, 用原软件处理和现有软件处理进行比对, 结果见表1。

4 结语

本软件针对多流、多表号飞控系统总线数据进行分析处理, 同时对原始数据的读取、结果文件的输出进行优化, 极大的提高了数据处理效率;软件提供的配置文件模块可以满足多种数据格式的数据处理任务, 同时在软件设计中提供的源码、计数字、故障检查等模块, 更好地为试飞工程师分析飞控系统工作状态, 为测试工程师排除系统故障提供了重要依据, 目前该款软件已经投入使用, 反应良好。

参考文献

[1]西安远方航空测控技术研究所.飞控数字FTI采集器[M].西安:西安远方航空测控技术研究所, 2012.

[2]王建军, 党怀义.基于Web的分布式试飞数据处理系统结构设计[J].计算机测量与控制, 2010, 18 (6) :1452-1454.

[3]RICHTER Jeffrey.Windows核心编程[M].北京:清华大学出版社, 1998.

[4]国家标准局.GB/T 8567-1988计算机软件产品开发文件编制指南[S].北京:国家标准局, 1988.

[5][美]John Miano, Tom Cabaski.Borland C++builder编程指南[M].郝杰, 译.北京:电子工业出版社, 1998.

数据优化处理 篇9

关键词自动气象站;月报表;异常数据;预审;处理

中图分类号P4文献标识码A文章编号1673-9671-(2010)081-0124-01

随着自动气象站和地面测报业务系统软件的使用,地面气象数据文件审核方法发生了重大变化。南乐县气象局从2005年1日1日自动气象站投入业务运行以来,对全局测报质量的提高起到了一定的作用,我根据近几年在地面资料审核工作中积累的经验,对本台站出现的、疑误数据处理问题进行了归纳总结,并提出了相应的处理方法。

1异常数据与处理

1.1降水量上下连接值的输入

《地面气象观测数据文件和记录薄表格式》规定,降水量上下连接值由3段组成:即下月1日20—8时降水量和跨月连续降水(或无降水)开始日期和上跨连续降水量。有些站往往没有将下跨的降水量输入或是输错。如有微量降水0.0应输为“,,,,”,误为“0000”。月末最后一日,应该人工录入、校对降水量上下连接值,确保B文件数据正确。

1.2分钟降水量与天气现象矛盾的处理

由于OSSMO 2004软件没有把J文件降水量及降水起止时间与A文件天气现象的降水起止时间对比,所以J文件经常出现降水量与天气现象矛盾的现象,值班员和预审人员必须人工校对分钟降水量与降水的起止时间是否一致。

操作说明:J文件分钟降水量取自B文件,因此要求每日20时值班员要按照《地面测报业务软件操作手册》和系统“帮助”文件,对“小时、分钟降水量”进行校对,方能确保小时降水量合计值和分钟降水量累积值相一致,分钟降水量记录和降水起止时间相一致。

1.3日照时数全天缺测

应该在日出到日落的各小时都应该录入“—”,不能自己认为从有日照的小时开始输“—”。日出、日落时的日照时数如果大于日出、日落时计算的最大值,OSSM0 2004审核提示为错误,应该利用软件提供的计算功能,算出本站该年每日日出日落时间,并查找引起矛盾的原因,确保观测未记录的准确性。

1.4对自动气象站大风记录的开始与结束时间应该认真校对

1)大风数据文件为FJ.TXT,由于FJ文件中的数据是自动气象站采集监控软件(SAWSS)从每分钟采集的数据中判断写入的,若SAWSS因故关闭或采集不正常,都会造成FJ.txt记录不正常,所以FJ.txt文件不能作为大风天气现象的唯一依据。

2)若自动站日极大风速≥17.0m/s,FJ.txt中无大风记录,可从Z文件中的时极大风速尽可能的判断记录,或通过随OSSMO 2004一并下发的自动气象站数据质量控制软件中的“大风现象查询”功能获取。

3)部分厂家的自动站,有时会出现从采集器读取的每分钟数据中的出现时间与实际时间有偏差,若写入FJ.txt文件中的时间与正点写入Z文件中的出现时间有时相差1分钟,则以Z文件的极大风速时间为大风的开始时间。

2对机审疑误信息要认真判断分析

分别使用地面气象测报业务软件和自动气象站数据质量控制软件对A文件、J文件和Z文件进行审核。对软件提示的疑误信息要逐条进行排查处理。提示为“错误”的信息必须维护正确,提示为“可疑”的信息要根据气象要素进行人工确认。如海平面气压、水汽压、露点温度与反查计算值相差>0.3℃,有错误,就应该利用地面气象测报业务软件的工具菜单进行查算;连续变化的要素,相邻时次变化异常。如地温、草温传感器安装不当,就会造成变化异常。一般认为,深层地温(80、160、320cm)相邻时次变化超过0.3℃属于异常。值班人员要按照有关业务文件的要求,加强自动站数据监控和人工与自动对比观测,及时发现问题,解决问题。

3自动站定时记录缺测的处理方法

按照《地面观测规范》和技术问题综合解答(第一号)的规定,自动站记录缺测的处理方法具体有:

1)自动气象站定时观测记录缺测。要优先使用正点前后接近正点的10分钟记录代替。监控软件从3.0.8版本增加了全要素分钟数据文件即RTD文件的备份。可以使用“质量控制软件”查找正点前后接近正点的分钟数据,并用来代替自动站缺测的正点值。

2)人工观测和自动观测记录的同类观测记录可相互代替。

3)在没有任何数据可代替的情况下,采取内插法或缺测处理。内插法是级别最低的。内插法不适用于风向风速、降水量缺测记录的处理。

4)缺测和不完整记录的处理方法要进行备注。

5)分钟数据缺测寻找方法。为了最大限度地减少缺测记录,用自动气象站数据质量控制软件的“数据导入”功能,从RTD文件中恢复。具体方法是:利用质量控制软件中的文件菜单—打开—文件类型—逐分钟地面数据文件—找到相应时间的数据。

4文件的审核

4.1J文件的审核

J文件处理方法。根据有关技术文件,J文件的分钟记录缺测或异常,不再按内插处理。J文件的分钟数据必须是自动站原始采集数据,因此,60分记录用A文件记录代替时,不能用A文件中内插或人工站代替的正点记录代替。需注意:J文件风速是一分钟风速,不能用A文件定时风速代替。

4.2Y文件的审核

制作年报表的A文件月份选择。制作年报表必须在Y文件维护中同时加载当年1-12月的A、J文件和上年度7-12月的A文件,这样才能制作正确的Y文件。

5结束语

自动站报表数据文件内容多、数据量大,要求审核员必须熟练掌握《地面气象观测规范》中各项技术规定及数据文件格式规定,对机审提出的疑误信息进行判断和推敲,不断总结经验,提高自动站报表数据文件的审核质量。台站的报表预审宜采取初审-复审-终审的流程。通过上述流程的上报报表可最大限度地减少错情;要尽量为每个班次排主班、副班并明确责任。当主班在观测、操作、发报时副班应负责校对和配合,发现不正常记录要及时处理,

参考文献

[1]中国气象局监测网络司,地面气象测报业务系统软件操作手册[M].北京:气象出版社,2005,1(37).

[2]地面气象观测规范[M].北京:气象出版社,2003,11(107).

作者简介

数据优化处理 篇10

关键词：数据流管理系统,连续查询,查询优化

数据流的特点是:数据具有实时性,需要即时响应;数据量大,而且无界;它还具有不可预知性,不可预期、无法控制数据流中元素的到达次序。以上这些特点都决定了,对数据流的查询只能近似实时。而且,目前大多数基于软件实现的数据流管理系统的处理速度都是有一定限制的。当数据流的流速达到一定的速度之后,就会出现瓶颈,利用软件就难以实现了。目前看来,比较可行的方法是来设计专门的硬件进行预处理来解决这个问题,即将数据流处理的某些操作利用硬件来实现。

提高对数据流连接操作的处理效率,是解决数据流管理系统中,如何提高处理速度的关键问题。利用多条数据流并发执行连接理论上可以提高处理效率,但是如何处理连接顺序又在很大程度上影响了系统的速度。因此,如何优化数据流并发连接查询算法则成为了研究数据流管理系统的关键技术之一。

1 基于硬件预处理的数据流管理系统

目前基于硬件预处理的数据流管理系统主要由两部分组成,包括:位于前端的预处理器和位于后端的数据引擎部分。位于前端的预处理器主要功能是完成对数据流的预处理操作。可以对后端传输过来的一些控制命令进行初始化处理,还可以对数据流中的数据进行滤波、压缩和加标记等处理工作。这种位于前端的预处理器,采用的是软、硬件协同的方式进行工作的,可以大大提高数据的处理速度。经过前端预处理之后的数据通过网络被传输到后端的数据引擎部分。

系统后端的数据引擎主要的功能是进行连续查询的语法分析、生成要进行并行查询的计划、将经过预处理的元组分到相应的数据缓存中,将通过并行处理后得到的查询结果再进行组装分发,后端数据引擎还负责负载的均衡、服务质量的监控等功能。用户提交的查询要经过词法及语义的分析、要进行查询优化才能得到所需的查询抽象语法树,在后端要对生成的抽象语法树用相应的算法进行处理,得到所需控制信息,再将这些控制信息,经过查询输出控制器交给前端的硬件查询处理模块进行相应的处理。

2 基于硬件预处理的数据流连续查询语言X-SQL

在传统的关系数据库中,常用的查询语言是SQL,它不能用于数据流查询中,不支持数据流中的连续查询语义。为了处理数据流中的数据,就需要使用专门处理数据流查询的语言。目前,用于数据流研究的查询语言主要有:基于关系的、基于对象的和基于过程的这三种语言[1]。

在研究过程中,我们数据流管理系统使用的是基于硬件预处理的数据流连续流查询语言X-SQL。它是一种基于关系查询语言,具有类SQL的句法规则,它还可以提供对窗口以及对排序的支持。通过基于关系的流语言,用户即可指定查询的语义,也定义数据流的采样率。

X-SQL是用滑动窗口来实现连续查询中的抽象语义的。我们可在系统后端进行X-SQL连续查询的输入,再进行交叉编译得出相应的一些查询指令和信息,再通过网络传输,将这些指令和数据输送到硬件的预处理器中,即可进行对数据流的各种查询。

X-SQL由数据流定义语言和数据流查询语言两种语言构成。其中,数据流定义语言是用来给数据流管理系统输入元数据信息的,而数据流查询语言则是实现对数据流进行查询的。

在X-SQL语言中,也是用SELECT语句来实现查询功能的。只不过除了像传统SQL语言一样给出要返回的属性选择列表、要检索数据的流的流列表和条件外,还有窗口声明部分。窗口声明部分是用来声明相应的滑动窗口大小的。语法如下所示:

X-SQL查询语句通过WINDOW子句就可以实现对滑动窗口查询,也就可以实现对数据流的连续查询操作。

3 并发连接查询的优化算法

在基于硬件预处理的数据流管理系统中,当用户提交了查询,该查询首先要经过编译器的词法分析、语法分析和语义分析。在进行了这些分析之后,才能得一棵语义正确的查询语法树。然后再依据这棵语意正确的语法树生成相应的目标代码。但是,只是可以生成目标代码,用这种方法生成的代码执行效率并不高,我们为了提高查询系统的工作效率,就需要对一些查询进行优化。

3.1 对谓词进行化简的优化算法

对谓词进行化简就是利用应用逻辑运算的相应规则,将用到的谓词表达式,等价地置换成更简单的式子。谓词化简的逻辑运算规则如下表1所示:

根据规则,我们设计出谓词化简算法,如下所示:

3.2 对谓词进行规范化优化算法

除了可以对谓词进行化简,我们还可以在X-SQL查询中对谓词的规则进行规范化优化,规谓词范化优化算法如下所示:

4 结论

目前来看,大多数的数据流管理系统基本还是基于软件系统来实现管理的。那么,当数据流速过快时,处理速度就出现问题。为了能提高数据流的处理速度,我们采用了基于硬件预处理的数据流管理系统。并对数据流查询语言X-SQL进行了优化。通过查询优化,可得到查询语法树,再对相应的语法树进行处理,即可生成基于硬件预处理的数据流管理系统所需的优化的控制信息。

参考文献

[1]Qian Jiang-bo,Xu Hong-bing,Dong Yi-sheng,et al.FPGAAcceleration window Joins over Multiple Data Stream,Jour-nal of Circuits,Systems,and Computers,2012,14(4):813-830.