海量数据过滤系统

海量数据过滤系统（精选7篇）

海量数据过滤系统 第1篇

本论文主要以遥感地面站的工程研制为研究背景,对实现地面站数据记录存档子系统的主要技术进行了深入研究,并以此为基础,提出了满足系统工程研制需求的设计方案。

1 系统总体结构设计

海量数据存储系统主要由高速数据采集卡、数据记录服务器、磁带库、RAID磁盘阵列、网络设备、数据记录存档管理软件等组成。

高速数据记录卡完成输入信号ECL到TTL电平的转换、串并转换、数据缓存、数据管理及高速PCI接口。高速数据记录卡上设置4个缓冲区数据,并由数据管理模块来保证不同通道间的数据同步。

数据回放卡采用与数据记录卡类似的PCI技术,并与数据记录卡一同插在数据记录服务器中。工作时,需要解决数据记录卡和数据回放卡的并存和工作协调。

在高速数据的记录系统设计中,高速数据在主机内部的传输受到计算机系统结构的影响,如果在高速数据传输系统的设计中忽略对现代微机系统内部数据传输通道结构的分析,会成为设计系统中的一道潜在的瓶颈。服务器作为系统架构的平台是必不可少的,它必须具有较强的处理能力和较强的I/O能力,才能够适应海量数据存储和交换的要求。

磁盘阵列作为实时数据的存储介质,与高速服务器的接口采用SCSI以保证传输速度。RAID盘具有高速度、高可靠性,支持RAID硬盘具有热插拔功能。支持多种RAID模式,这些RAID功能保证了用户数据的高可用性,保证数据的高可靠性。同时磁盘阵列容量具有扩展性,支持后续任务的增加,易于扩容。数据记录子系统中提供的LTO-2磁带驱动器,作为数据备份设备,用于事后数据的转存。

时码模块主要接收站内时频设备的时间信号,完成时间信息的转换,实现对数据记录存档系统的时间统一,用于数据记录存档数据的时间标记。

卫星数据接收过程中,在记录存档管理软件的管理和调度下,解调后的基带数据I、Q数据实时数据经过高速数据记录卡实时读入服务器,并实时记录在RAID磁盘阵列上。也就是说,在主机管理和调度下,经过解调后的高速基带数据流首先输入到高速数据记录卡,在完成接口匹配及速率调整后进行数据缓冲,然后经主机PCI总线将数据写入到RAID盘上,实时完成卫星数据的记录。卫星过境后将数据事后转存到磁带上。数据记录存档子系统具有卫星侦察数据的网络传输能力,通过千兆网络接口可以实现与外部之间的数据导入与导出。

2 系统存储结构模式

由于每颗遥感卫星设计上的独立性,无论下行数据码速率还是数据格式都没有一个统一的规范。从卫星地面站数据记录系统的发展来看,工作站的处理能力不断提高,所处理数据的码速率和数据容量不断提高,存储技术也不断更新提高。因此,如何选择相对通用的数据存储方法和存储介质,是遥感卫星地面站运行中的一个重要问题。

在存储技术中,应用比较广泛的存储模式有三种:直接连接存储(Direct Attached Storage,DAS)、网络附加存储(Network Attached Storage,NAS)及存储区域网络(Storage Area Networks,SAN)。它们都是以RAID技术为基础,一般都会提供RAID0、1、5的支持。

DAS是指将存储设备直接连接至一台服务器上。NAS是一种特殊的、可以通过网络对各种的系统平台提供文件共享服务、能完成单一或一组指定功能(文件服务、HTTP服务、EMAIL服务等)、基于网络的存储模式。SAN是一种类似于普通局域网的高速存储网络,是一个独立的、专门用于数据存取的高速专用网络。

由于本课题直接应用于遥感地面站的数据记录存档系统,对数据安全性、存储性能要求高,在系统存储方面方面需要有可扩展性和灵活性。同时,站内接收存储的数据存储时物理集中,数据管理逻辑上又彼此独立,并要求能够对物理分散的两个地面站的数据完成高速集中备份。

根据对以上存储设备和存储模式的优缺点的比较,选用DAS与SAN相结合的混合存储结构模式。选择磁盘阵列作为在线存储设备,LTO磁带库作为离线存储设备。

3 结束语

海量数据存储系统是遥感卫星地面站重要的一个组成部分,本文简要介绍了遥感地面站各部分的功能和数据存档系统的总体结构。由于卫星数据存档时,要求达到较高的速率,因此对服务器的选择尤为重要。卫星数据实时接收后存档到RAID磁盘阵列,一定天数后备份到磁带库,系统存储结构选择DAS与SAN相结合的混合存储结构模式。

参考文献

[1]葛成辉,朱正中.气象卫星遥感原理[M].北京:清华大学出版社,1992:13-15.

[2]梅安新,秦其明.遥感导论[M].北京:高等教育出版社,2001:21-23.

[3]伍尚志,杨仁忠.高速遥感卫星数据采集系统的研究与实现[J].微计算机信息,2005(21):69-70.

海量数据过滤系统 第2篇

大规模异构感知数据来源于物联网应用中由大量射频识别器、传感器节点等数据采集设备收集的感知信息, 由于数据量非常大, 一台计算机不可能满足海量数据处理的性能和可靠性等方面的要求, 因此, 研究更高效的和智能化的海量异构感知数据处理技术将给物联网系统上层应用提供更有力的决策支持和节约大量的存储资源。而云计算技术的应用能有效地增强物联网系统中的数据处理能力, 提高物联网系统的智能化程度, 通过云计算技术, 云中大规模的计算机集群提供了强大的计算能力, 通过庞大的计算机处理程序自动将任务分解成若干个较小的子任务, 快速对大规模的异构感知数据进行存储、处理、分析和挖掘, 并在保证应用时效性的基础上给用户提供决策支持。

近年来, 云计算环境下大规模异构感知数据流处理技术方面取得了一些研究成果[1,2], 主要包括文献[3]中提出的基于云计算的大规模感知数据流处理系统框架, 其利用Hadoop分布式文件系统 (Hadoop Distributed File System, HDFS) 和HBase实现感知数据的存储, 应用Map Reduce实现海量感知数据的并行处理, 文中主要研究了无线传感器网络中大规模感知数据在云计算环境下的处理方法, 而对于物联网中多模式、多属性、非结构化的高维异构感知数据处理技术没有讨论。文献[4]中主要研究了在云计算环境下通过卫星等收集的空间数据处理集群系统框架设计方法。文献[5]中结合城市车辆数据的实时采集和处理, 在理论和实践分析的基础上, 提出了一种针对高速数据流的大规模数据实时处理方法, 在云计算环境下通过优化本地阶段流水线和中间结果缓存技术有效的提高了CPU和存储器的利用率。但是对于所提出算法的负载平衡, 即异构工作节点上中间结果数据的分布和动态负载调度等关键问题还存在很大的研究空间。文献[6]中研究了如何运用Map Reduce编程框架解决海量数据的Skyline查询问题, 通过过滤部分不能成为Skyline查询结果的数据对象, 提高在Map Reduce编程框架下的查询效率、准确性和可用性, 但在Map Reduce编程框架下对于具有高维异构特性的感知数据的Skyline查询问题还有待进一步研究。国内中国科学院计算技术研究所2008年底开发完成了基于Hadoop的并行分布式数据挖掘系统PDMiner, 2009年实现了面向云计算的数据挖掘服务平台COMS, 现在已经在国家电网与国家信息安全领域实践应用, 2010年7月COMS作为无锡“感知环境, 智慧环保”环境监控物联网应用示范工程重要的一环, 通过了环保部组织的专家论证, 正进一步在试点城市实际部署应用[7]。云计算中心所具有的接入网络终端的普适性, 也解决了物联网中M2M应用的广泛性问题, 越来越多的研究机构和IT企业开展这方面的实践工作, 云计算与物联网的结合将是未来信息产业的发展趋势。

2. 基于云计算的海量数据处理需解决的关键问题

构建基于云计算平台的面向物联网大规模异构感知数据流的处理体系需要实现具有高速流数据特征的海量感知数据在云计算环境下的分布式存储技术, 以及能有效降低数据处理延迟的实时响应算法和在云计算环境下实现低复杂度的、高效的海量异构感知数据分布式知识发现和并行化数据挖掘算法。需要解决的关键问题有:

(1) 多态异构的感知数据流在云计算环境下的存储问题。物联网感知层的传感器节点、视频监控终端和RFID标签种类繁多、性能各异, 采集的数据结构各不相同, 有静态数据, 也有动态数据。因此需要结合物联网系统应用的特点设计适合于多态异构的感知数据流云存储方案。

(2) 云计算环境下对海量感知数据流处理的时效性问题。物联网中被感知的事物状态可能是瞬息万变的, 不管是WSN还是RFID系统, 数据采集工作随时进行, 数据更新很快, 数据量大, 无限制的备份历史数据不仅消耗大量存储空间, 而且影响数据处理和查询的效率, 因此需要解决在不影响感知数据流特征的基础上, 增强系统对新数据更新的处理效率, 减少数据处理的延迟, 提高系统的可靠性和实用性。

(3) 云计算环境下非结构化感知数据流的分析挖掘问题。大多数物联网系统中采集的原始数据是非结构化的, 例如:图结构、序列、读入连续测量值等。对于不能用特征向量表示的感知数据流, 传统的数据挖掘算法不能直接应用。因此, 需要研究怎样自动抽取非结构化感知数据流有用的特征信息, 适用于典型的数据挖掘策略。为进一步提高数据挖掘算法的执行效率和解决信息丢失问题, 需要更深入的研究非结构化感知数据表示方法, 实现能在时空非向量空间中直接执行分析挖掘操作的算法。

(4) 云计算环境下大规模异构感知数据流的质量问题。物联网系统应用中, 由于传输错误、传感器失效、停电等原因, 在数据采集过程中会发生数据成批成片或部分丢失和错误情况。另一方面在面向大规模异构感知数据流处理的云计算环境下, 数据产生不一致性、不正确性、错误性、冗余性和过期的概率进一步增大, 因此, 在感知数据挖掘建模分析时需要解决丢失或错误数据的识别和算法鲁棒性问题。

3. 基于云计算的海量数据处理系统框架的实现

在Linux操作系统下安装Hadoop分布式开源计算框架实现云计算平台的搭建, 利用虚拟化技术实现Hadoop的集群配置, 安装Java虚拟机, 完成SSH、HBase、hive、sqoop、zookeeper等配置工作。对于Hadoop的集群来说, 分为Master和Slave两大类角色, 前者主要配置Name Node和Job Tracker的角色, 负责总管分布式数据和分解任务的执行, 后者配置Data Node和Task Tracker的角色, 负责分布式数据存储以及任务的执行。由于Map Reduce计算模型适合于结构一致的海量数据, 而且要求计算简单, 但对于大量的非结构化的感知数据密集型应用, 往往涉及到数据降维, 程序迭代、近似求解等复杂的算法, 计算非常困难, 本文在深入研究Map Reduce并行计算框架的基础上, 通过预处理、分布缓存和复用中间结果等方法增强Map Reduce的数据流处理能力, 减少数据处理开销。实验测试数据分别采用大规模高维合成数据集和通过美国Crossbow公司含有IRIS处理器/射频板和光、温度、湿度、气压和震动传感器节点构建的无线传感器网络采集的海量感知数据流及用于安防监控的摄像头收集的视频数据流作为待分析处理的大规模异构感知源数据流。

3.1 系统的云存储方案

在云计算环境下, 针对物联网应用中采集的海量感知数据所具有的异构性、不确定性、高数据流等特点, 以提高存储的可扩展性、容错性以及降低存储的能耗等为研究目标, 从数据中心网络的设计、数据的存储组织方式等方面对当前分布式存储关键技术进行研究, 系统的云存储方案采用三层数据存储结构。如图1所示, 其中运行支撑数据层负责存储和动态更新感知数据流和计算的中间结果;运行结果数据层负责存储和动态更新最终处理结果;历史数据层负责存储和追加更新历史感知数据, 每次数据计算处理后, 运行结果数据层中剥取出需要演变为历史资料的数据追加到历史数据层。中央存储调度模块根据相关指令分别调度三层中的数据集合, 并保持调度过程中运行支撑数据层和运行结果数据层的数据一致性。基础管理层主要以集群分布式文件系统的方式提供管理和数据获取和更新服务。

3.2 海量数据流的实时处理流程

针对现有云计算环境下, Hadoop框架下Map Reduce方法以持久化数据的批处理方式对海量感知数据流处理的实时性差问题, 通过预处理、分布缓存和复用中间结果的方法降低每次数据流到达时的历史数据重复处理开销, 并使得数据流处理本地化, 减少节点间的数据传输开销。本系统框架将预处理的历史数据中间结果分布缓存于各个节点, 每个节点冗余地接收数据流, 通过Map阶段过滤出本节点负责处理的数据并在本地缓存上进行Reduce计算, 当已有节点的本地计算和存储资源不能满足实时性需求时, 可以在新增节点上通过重新划分和移动缓存数据进行扩展, 最后通过数据同步将本地计算结果同步到分布式存储区, 工作过程如图2所示。

3.3 海量数据流挖掘分析的并行处理方案

深入分析物联网应用中产生的海量感知数据具有的快速更新、数据维数高、非结构化等特点, 实现基于Map Reduce的大规模异构感知数据流并行规约和特征提取算法, 从而给物联网系统终端用户提供更可靠的决策支持。利用虚拟化技术, 实现海量感知数据挖掘云服务的计算资源自主动态分配和调度。传统的并行属性数据挖掘算法是假设将所有数据一次性装入内存中, 不适合处理海量异构感知数据集, 在云计算环境下对高维海量感知数据流处理时, 可采用如图3所示的并行操作策略。

先将大规模感知数据划分为多个数据片, 然后对每个数据片并行计算不同的候选属性集导出等价类, 产生大规模不可辨识或者可辨识的对象对后, 再以数据并行方式计算候选属性集的可辨识或不可辨识对象对总个数, 最终确定最佳候选属性。

4. 结束语

云计算的超大规模、虚拟化、多用户、高可靠性、高可扩展性等特点正是物联网规模化、智能化发展所需的技术。之所以在物联网系统后端采用云计算模式而不是其他的分布式计算模式, 原因在于云计算的分布式并行计算模式具有低成本、扩展性好、大规模数据处理的计算能力强和良好的容错能力等特点。本文针对异构感知数据流的数据量不断增长而引发的存储、管理以及性能问题, 在深入研究基于Map Reduce并行编程模型的数据流处理技术基础上, 通过分布式缓存和弹性缓存技术, 考虑将业务逻辑代码转移到数据所在节点执行, 提出了云计算环境下面向海量高速感知数据流处理的系统框架, 为构建智能化的物联网应用系统应用支撑层, 完成可靠地服务决策和协调控制任务奠定基础。

摘要：为了有效地解决物联网系统中海量实时感知数据流的存储和处理问题, 本文在深入分析和研究现有国内外相关先进技术和研究成果的基础上, 提出了基于云计算的海量数据处理系统框架, 在构建的虚拟数据中心拓扑结构上, 实现了面向大规模异构感知数据存储的分布式数据库集群系统架构, 在此基础上结合MapReduce编程模型设计了适合大规模异构感知数据流并行计算的优化策略。

关键词：海量数据处理,云计算,物联网,并行计算

参考文献

[1]Hausenblas Michael, Grossman Robert, Harth Andreas, Cudré-Mauroux Philippe.Large-scale linked data processing:Cloud computing to the rescue?[C].Proceedings of the 2nd International Conference on Cloud Computing and Services Science, 2012, pp:246-251.

[2]Anjomshoaa Amin, Tjoa A.Min.How the cloud computing paradigm could shape the future of enterprise information processing[C].13th ACM International Conference on Information Integration and Web-Based Applications and Services, 2011, pp:7-10.

[3]Tang Bing, Wang Yu.Design of large-scale sensory data processing system based on cloud computing[J].Research Journal of Applied Sciences, Engineering and Technology, 2012, 4 (8) :1004-1009

[4]Siládi Vladimir, Huraj Ladislav, Vesel Eduard, Polcák Norbert.A parallel processing of spatial data interpolation on computing cloud[C].ACM International Conference Proceeding Series of 5th Balkan Conference in Informatics, 2012, pp:193-198.

[5]亓开元, 赵卓峰, 房俊, 马强.针对高速数据流的大规模数据实时处理方法[J].计算机学报, 2012, 35 (3) :477-490.

[6]丁琳琳, 信俊昌, 王国仁, 黄山.基于Map_Reduce的海量数据高效Skyline查询处理[J].2012, 34 (10) :1785-1796.

海量数据过滤系统 第3篇

城市管理部门为了加强对供水管网的信息化管理, 决定建立供水管网管理信息系统, 该系统将利用数据库技术、GIS技术、计算机技术、网络技术, 把城区全部供水管网及设施以数字的形式获取和存储, 对其进行查询统计、编辑、输出、更新等管理, 为城市建设与发展提供准确设施基础资料。为供水管网及设施的日常规划、设计施工、统计分析、发展预测提供可靠的科学依据, 从而彻底改变传统的供水管线及设施管理模式。

本系统采用业界具有行业领先水平的海量空间数据库管理技术Oracle11g和最先进的图形处理优化技术, 在实际应用中注重系统操作的高效性, 实现查询检索及数据处理优化。系统采用先进的优化算法, 确保软件系统与现有的硬件环境的良好兼容性和性能的高效性, 从而推动数字城市的建设工程。

1 数据来源

本系统涉及的数据包括基础信息数据和管网数据。

(1) 基础信息数据 (即地形数据) 是城市最基本的地理信息, 包括各种平面、高程测量控制点、建筑物、道路、桥梁、水系、境界、地形、植被、地名以及某些属性信息等, 用于表示城市的基本面貌并作为各种专题信息空间定位的载体。

城市供水管网数据量庞大, 管网与供电、邮电等其它管网交错在一起, 错综复杂, 所以都需要勘察记录入库。

(2) 管网数据是指供水管网及相关设施信息。管网数据通过管网探测及调查得到。

2 数据分层

各类数据库或数据子库, 根据具体情况和用户需求, 采用分层的办法存放。分层有利于数据管理和对数据的多途径快速检索与分析。

数据分层的原则为:

(1) 同一类数据放在同层; (2) 相互关系密切的数据尽可能放在同层; (3) 用户使用频率高的放在主要层, 否则放在次要层; (4) 某些为显示绘图或控制地名注记位置的辅助点、线、面的数据, 应放在辅助层。对于地形信息, 通常按管理要求将地物提出, 如河道、主要建筑物、道路、桥梁等。

3 数据编码

供水管网信息管理系统, 重点是对管网以及相关的设施物进行管理, 因此可对各类管网制定相应的分类编码方案。

编码原则: (1) 一致性:各类管网编码方法一致或接近一致; (2) 简易性:编码方便, 易于理解和操作; (3) 兼容性:与国标码方案类似, 可互相转换。本系统以《基础地理信息要素分类与代码》GB_T_13923-2006和《城市地下管线探测规程》为依据, 制定标准的编码管理体系和图库, 用户可以在本系统编码体系的基础上进行扩展, 使之满足日后扩展的要求。

4 数据库设计和管理原则

在系统数据库的设计和日常管理过程中, 坚持以下原则:

4.1 数据安全性原则

做到定期按时备份, 防止系统故障带来的损失。数据的查询、修改必须按相关规定执行。

4.2 数据保密性原则

系统及数据属于档案资产, 其中的空间坐标信息受国家相关法律法规的约束。系统的运行必须遵守国家相关制度的规定。

4.3 标准性原则

系统运行维护必须依据相关国家标准和系统本身数据要求进行, 包括已经约定的管径、材质、节点性质名称、符号类型等, 必须沿用, 对于新出现的情况, 应加以说明。

4.4 准确性原则

为了保证数据的一致性、连贯性, 要求必须为同一坐标系、高程系的数据, 且精度误差在允许范围之内。

4.5 完整性原则

为了充分发挥系统的管理功能, 必须完整输入相关数据, 如:高程、埋深、材质、管径、日期等资料。

5 数据库设计要求

分专业对管网数据进行处理, 生成点属性表和线属性表两个相关联的表, 并提供相对应的线注记CAD (DXF) 格式数据。对点属性表编码、线属性表编码按唯一性原则进行编码。

为了便于数据集成, 对提交的数据要求如下: (1) 数据表命名约定:表名以管网性质为基础, 按数据类型增加后缀和扩展名。线属性表增加后缀“LINE”;点属性表增加后缀“POINT”。 (2) 提交的数据文件种类包括:点线表、线属性注记文件、图幅信息表、管沟点线表、井边框点线表。 (3) 对线属性注记文件的要求:提交各专业管网注记。以上文件均以大片数据组织。例如:给水专业管网性质为给水 (JS) , 则点属性表:JSPOINT, 线属性表:JSLINE。 (4) 隐蔽管线点精度要求, 隐蔽管线点精度执行CJJ61-2003《城市地下管线探测技术规程》中的精度, 具体标准如下:水平位置限差 (cm) :±0.10h埋深限差 (cm) :±0.15h, h为地下管线的中心埋深, 以厘米计, 当h<100㎝时则以h=100㎝代入计算。分别计算隐蔽管线点的定位中误差和定深中误差。定位中误差和定深中误差均不得超过规定限差的0.5倍。 (5) 明显管线点精度, 执行CJJ8-99《城市测量规范》中的规定, 平面位置测量中误差不得大于±5cm (相对于邻近解析控制点) , 高程中误差不得大于±3cm (相对于邻近高程控制点) 。埋深精度中误差不得大于±2.5cm。

6 数据库建设内容

基础地形空间数据库建设内容, 在城市基础地理空间数据的标准和规范《1∶500、1∶1000、1∶2000地形图建库技术规程》的基础上建立本项目需要的基础地形空间数据库。基础地形空间数据建设内容如下: (1) 建立1∶1000/1∶2000地形图GIS数据库, 包括整个城市范围。 (2) 建立规划与现状路网GIS数据库, 整个城市相应范围。 (3) 建立行政区域 (市区街道镇/村) GIS数据库, 整个城市相应范围。 (4) 建立地名地址GIS数据库, 整个城市相应范围, 大约5万个POI。 (5) 提供1米分辨率卫星影像图数据并建立GIS数据库, 范围:市区300平方公里。 (6) 建立市区门牌号码和公共设施数据库。 (7) 建立市区企事业和机关单位信息资料库。

供水管网空间数据库由于供水管网的历史资料比较混乱, 本项数据库建设的内容包括管网数据的普查 (执行行业标准《城市地下管线探测技术规程》[CJJ61-2003]、建设部《城市测量规范》 (CJJ8-99) ) 。 (1) 供水管网数据普查与建库 (到用户计费水表管网) 。 (2) 供水管网规划空间数据建库。 (3) 供水管网设施参数数据整理建库与管网空间数据关联。 (4) 水表普查编号与收费系统水表对应。

7 结束语

本系统的设计与开发, 突出以海量数据为基础, 面向工作流程、面向单位业务管理的特征要求。

数据的处理纷杂、繁琐, 数据库的设计遵循以上原则能够较好的处理供水管网的海量数据。系统最终实现统一的信息化管理, 提高供水管理工作效率、增加工作透明度, 使信息达到最大程度的利用和共享, 将供水管网数据作为整个信息系统的核心, 建立了一套现代化的综合管网管理信息系统。

参考文献

[1]张杰.蚌埠市供水管网科学管理方法初探.价值工程, 2013 (5) .

[2]俞良协, 刘波, 罗俊.基于GIS的供水管网资产管理系统开发与应用.城镇供水, 2012 (5) .

[3]李开源.住宅小区供水管网管理的地理信息系统研究与开发中国学位论文数据库.

[4]申艳芬 (陕西) .基于Arc GIS Server的给水管网系统研究与设计.中国学位论文数据库.

[5]郭成林.基于GIS的给水管网优化调度研究.中国学位论文数据库.

海量数据过滤系统 第4篇

云计算是一种以服务形式出现、基于互联网的计算模式, 其涵盖了计算能力、存储能力和交互能力, 具有动态性、可伸缩性和虚拟化特征。目前, 云计算这一平台的提出, 还包含大量开源的云计算平台。在云计算平台在数据挖掘过程中, 可供服务主要包括四个层面的内容:第一个层面是数据挖掘算法的主要步骤;第二个层面是指关联规则、聚类等数据挖掘服务, 具有独立性;第三个层面是并行分类、聚合式机器学习等数据挖掘模式;第四个层面是将前三个层面的元素进行整合, 形成完整的数据挖掘应用模式。与此同时, 相关人员提出了基于云计算数据挖掘服务的开放性框架, 一系列数据挖掘服务系统逐渐显现出来, 譬如Weka4 WS、Mobile Data Mining Services、Knowledge Grid等, 该类系统有效结合图形界面, 使广大用户可自主定义数据挖掘流程, 并直接在云计算平台上操作。

二、关键技术

(一) 数据存储方式。

在设计的数据存储系统中, 通常会采用关系型数据库来实现用户所需数据的存储。但由于云计算平台的特殊性, 其还存在两方面的问题:一方面是云计算涵盖的数据总量十分庞大且复杂, 数据关系库也无法完全存储, 因此, 对关系型数据库的扩展势在必行, 其也是计算平台正面临的巨大挑战;另一方面, 针对云计算的数据存储功能, 部分应用要求非结构化或者半结构化的数据存储, 并非完整的结构化存储方式。由此可以看出, 在云计算平台中, 对于非结构化或半结构化的数据存储, 应提供数据存储方式。对于云计算而言, 数据存储技术主要包含开源的HDFS与非开源的CFS, 其中HDFS数据存储技术的应用较为广泛, 如因特尔、雅虎等。

(二) 数据预处理方式。

在预处理数据过程中, 为了实现更具适用性的并行处理方式, 云计算平台提供了大量的数据并行加载方式和概念分层组织。并在此基础上, 利用数据稀疏化技术、高纬度约减技术进行更加充分化、质量化的数据预处理, 有效提高了数据管理与数据挖掘的效率。

(三) 海量数据挖掘并行算法。

数据挖掘算法并行化作为大量数据挖掘的重中之重, Map Reduc等先进计算模型的使用, 无法实现数据挖掘测量和并行化策略的直接应用, 与之对应的是海量数据挖掘也无法完成。因此, 需深入对更具适用性的海量数据挖掘并行算法进行分析和研究, 以带动云计算并行海量挖掘算法的高效化发展。同时, 还应不断分析和改造已有的云计算模型, 锲而不舍地扩充和改善海量数据挖掘算法, 确保云计算模型完全适用于海量数据挖掘。

三、海量数据挖掘系统

(一) 系统架构。

基于微软平台构建海量数据挖掘系统, 便于使其为数据挖掘系统的开放接口提供强有力的支持。针对互联网用户, 可通过系统直接访问, 也可充分利用其它应用程序实现开放接口的调用, 为其提供各项服务。无论是何种情况, 用户无需深入了解系统内部, 也无需担心系统存储能力或计算能力不足。通常情况下, 用户可结合自身需要, 选择不同的数据算法来处理不同数据, 还可将任务请求布置给系统, 由系统为用户解决问题。该系统中的任务模块可自主选择使用算法, 将经过不同算法得出的挖掘结果通过可视化输出服务完整地呈现给用户。在海量数据挖掘系统中, 可通过系统输出模块、输入模块、开放接口为用户提供便捷、有效的服务。其中, 一切外部可见服务都属于开放接口所提供的服务, 且系统输入模块可直接调用系统开放接口, 实现外部可调用服务。

(二) 功能框架设计。

目标系统的功能框架主要设计为五层, 从下至上分别为海量数据集层、算法层、任务层、用户层、用户界面与开放接口层, 每一层都为其上层服务。系统开放接口与用户界面都位于最顶层, 用户可由这一层系统共享数据集、布置任务或选择数据挖掘算法, 且将所得结果通过可视化输出, 便于用户将计算结果集成到自己的应用中, 进而体现出微软云计算平台的开放性;在系统任务层中, 用户可根据系统任务关联算法结合自动选择算法进行数据挖掘, 而由一系列算法得出的结果经过详细的比对后进行任务综合, 并向用户输出;其中, 用户界面与开放接口在最顶层, 用户可以通过这一层向系统布置任务、共享数据集或选择数据挖掘算法等, 且其结果通过可视化输出, 在算法层中, 共包含四种服务, 即可视化输出、数据挖掘算法调用、数据清洗算法调用与算法注册与注销。其中, 可视化输出服务主要是指以表格或图形的方式将数据挖掘结果准确地呈现给用户;挖掘数据算法调用服务主要是按照数据层中已接受预处理的数据集, 采用既定算法, 实现接口的统一调用, 并进行数据挖掘;数据清洗算法调用服务主要是指清洗有噪声数据的数据集, 并通过数据层存储到云计算平台的存储空间;注销服务与算法注册主要是针对各类算法模块进行插件式管理。

结束语

综上所述, 云计算平台服务具有较高的适用性和开放性, 且其具有虚拟化特征, 在为数据挖掘带来新机遇的同时, 也为这一领域的研究和发展指明了方向。微软云计算平台能快速的部署应用程序, 具备微软大型数据中心, 不仅能确保云服务基础平台的规模, 还拥有强大的计算能力。

摘要：随着科学技术的发展, 人们对数据挖掘服务提出了较高的要求。在网络环境下, 云计算能为海量数据挖掘提供基础设施, 基于云计算平台的数据挖掘研究为数据挖掘服务带来了较大的发展空间。本文针对基于云计算的海量数据挖掘进行分析, 提出基于微软云计算平台的海量数据挖掘系统架构设计。

关键词：云计算,微软云计算平台,数据挖掘

参考文献

[1]李金凤, 姜利群.基于微软云计算平台的海量数据挖掘系统[J].电脑知识与技术, 2011, 34:8766-8768.

[2]贺瑶, 王文庆, 薛飞.基于云计算的海量数据挖掘研究[J].计算机技术与发展, 2013, 02:69-72.

海量数据过滤系统 第5篇

在海量URL的数据处理中, 利用WEB爬虫是一种较为高效的处理模式。因为爬虫的运行过程和爬虫低海量URL的存储操作进行详细的分析是设计海量URL数据存取的快速文件系统的重要依据, 即通过对其运行的规律与方式来设计支撑高速且稳定的web爬虫运行环境, 以此完成对海量URL数据的高速存取, 所以在设计快速文件系统时应先对web爬虫技术的相关定义进行了解。其中基本定义包括以下几种:

种子:是一种人为设置的批量文件, 即一批RL, 在系统中作为爬虫访问网络的进口, web爬虫工作时就是利用种子界面来解析网页的内容并获得任务的。

URL下载器:在系统中下载器对指定的URL进行下载, 并获得对应的web页面内容。

URL抽取器:在系统工作中对下载器获得的页面进行分析, 提取其中包含的URL连接, 如绝对或者相对的URL链接。

URL过滤器:过滤的功能就是在用户准则下对相应的网络页面进行筛选, 提出不能满足客户需求的URL, 以提高针对性。

爬行策略:这个策略是一种爬虫工作的模式界定, 其中所涉及的有广度与深度优先爬行策略, 即在爬虫工作时按照什么样的方式进行优先操作。具体看, 广度优先的策略是先分析一个页面中包含的所有的链接, 其分散性明显, 然后在对连接进行爬行操作, 最后获得这些链接中保护的所有的URL, 操作为逐层递进模式。广度优先的模式保证了一个站点中浅层的爬行, 且可以获得最短路径, 提高了访问的效率。如没有设定站点的爬行规律, 则广度优先会同时访问对个站点, 优化了访问站点的过程, 避免了频繁访问一个站点而导致其对web爬虫进行限制或者禁止的问题。广度优先策略实际上就是一种简化思路且方法容易实现, 往往用于对通用爬虫的控制。但是如果需要进行一个深度嵌套的站点对于深层次的页面进行访问往往会消耗大量的时间。

深度优先策略则是利用爬虫先抓取一个页面, 并完全解析其中的包括的全部的URL, 在选择其中的某个URL进行继续下载与解析, 逐个递进, 直至爬行到当前界面中不在存在新的URL的时候即返回, 到上一层中没有被解析的URL在此进行下载与解析。这就是深度优先, 这个策略帮助爬虫对一个深度嵌套的站点进行快速的深入解析。但是是因为大型的站点往往深度较大, 此时一旦利用深度优先, web爬虫将陷入其中不会返回。因此在实际的应用中必须对某些策略进行改进, 如采用深度优先的时候, 应将深度与广度策略结合起来, 这个策略可以向广度优先策略一样同时进行多个站点爬行, 防止某个时间段内对一个站点进行频繁而大量的访问而导致被限制;而对于一个站点的访问则采用深度策略, 能保证被访问站点的内容被充分解析。同时需要设置对站点爬行的层次和站点的访问深度, 即防止爬行陷入大型的嵌套中。

URL存储管理:就是对所有的URL的存入与读取进行管理, 包括了对URL的预存取和更新, web爬虫在爬行的时候会出现URL入库和当前下载的URL进行更新的过程, 并使其匹配存入到数据库的某个位置。

2 基于海量URL的快速文件系统设计

2.1 海量URL快速文件系统构建目的

海量的URL数据管理其本质就是爬虫高效率运行的基本保证, 为了web爬虫在运行的过程中保持长久的有效性, 高效率的URL数据管理服务是必不可少的。所以需要建立快速文件系统来辅助爬虫进行高效运行。这就是海量URL快速文件系统构建的目标, 细分其目标可以总结为:

(1) 在存在大规模的URL的情况下, 可以在短时间内完成对数据的更新与存取操作。

(2) 提高对web爬虫爬行过程中产生的重复数据的处理能力, 即高效过滤防止系统出现重复数据或者重复访问的情况降低系统效率。

(3) 对海量的URL数据进行优化管理, 尽量降低其对系统资源的占用, 试图消除海量URL数据在web爬行调用系统接口的时候有效地调度控制其出现的性能瓶颈缺陷, 使得接口具备良好的拓展性能。

2.2 系统总体构建的思路

总结以往的研究经验, 认为快速文件系的原型系统在功能上应具备以下几个功能模块。URL访问操作线程:即为快速文件系统提供逻辑储存模型和快速文件的物理存储模型, 使之按照一定的逻辑性运行;在这里快速文件系统的逻辑存储模型是指负责URL逻辑层面的访问功能控制, 对URL访问线程提供功能上的支持, 根据技术需求, 快速文件系统的逻辑存储模型包括了URL去重复模块、索引模块、URL记录模块。而快速文件系统的物理存储模型则是指描述URL数级在磁盘上存储的形式, 以及为逻辑模块提供对存储磁盘上的数据进行访问的功能, 主要模块包括了缓存模块、页面调度模块、磁盘读写管理模块等。URL访问线程:这个部分负责的是提供URL的访问效率, 如URL预取、预取更新插入、下载更新等等。

2.3 系统主要模块的设计

2.3.1 数据过滤模块

系统过滤模块主要的功能就是去掉重复的数据, 即对重复的URL进行过滤防止重复的数据进入到数据库中或者被重复下载而占用系统资源。URL的域名首先进行哈希计算获得32位的整数, 在对URL本身进行哈希计算仍然获得32为整数, 此时将二者进行合并哈希计算, 由此获得64位的整数值, 以此为标准进行去重复的哈希计算。

2.3.2 索引的管理

在系统中对数据的索引进行管理也是十分必要的, 其面向的是海量URL数据, 是快速文件件系统的核心组件。这个组件可以有效的提高URL数据存储的速度, 是URL的快速查询、动态化更新的重要基础。URL索引的管理主要就是对B+Tree的索引进行维护, 包括对数据的查询、插入数据时引起的B+Tree的索引结构的改变以及对叶子页上的URL记录数据进行动态化更新。对于B+Tree的索引算法可以利用优化的B+Tree的方式进行操作以保证空间的合理利用。

2.3.3 URL数据记录管理

在URL记录中包括了URL与其附属信息, 大多数的字段是用来描述URL记录的, 在研究中发现, URL记录的往往是固定长度的字符进行储存的, 在存储空间上每一个URL记录都会占用560个字节。同时记录URL记录数据只能够在逻辑层上才能有意义, 在物理层面上URL的记录仅仅是二进制的方式进行保存。所以需要利用对其进行管理, 所以系统中必须有记录管理模块来对其进行管理, 对其进行物理存储上导逻辑存储之间的转换和对其记录进行维护。因为缓存中只保存有二进制的数据, 可以节约内存的有限资源, 同时只有查询的时候才会检查URL记录的整体, 并转换获得信息。因为URL的数据记录是等长度的, 更新操作仅仅更新的是URL记录的状态信息, 所以只需对相应的字节进行更新就可以完成更新, 不是每次换页都需要进行URL数据转换。

2.3.4 对系统的缓存管理

缓存是保证快速文件系统高速性能的重要基础, 所有的并发控制都在缓存上进行, 而缓存的技术改进也可提高I/O性能。所以高效缓存管理是快速文件提取的重要基础。在系统设计与实现时URL记录的所有操作都被限定在缓存中完成, 因为web爬虫操作的数量巨大, 所以需要缓存的容量也就相对大。所以在缓存数据中也没是按照树形的结构组织进行构建的, 并按照树形运算与缓存方式进行工作, 这样可以加快判断速度。

2.3.5 页面调用

页面调用是系统中最底层的一个工作模块, 也关系到整个快速文件系统的工作效率, 其直接负责与存储在硬盘的数据进行交换, 完成文件的读取与写入。其在运行中操作的一个最小的基本单元就是数据页, 此时每个数据页面都会被分配得到一个固定的页面ID, 每个数据页面都是固定长度的字符, 所以对数据也的地址而言只能通过一个固定的ID和页面的长度都可通过计算获得。页面调度模块维护的是两个队列的关系, 一个LRU队列和另一个修改队列。当缓存溢满的时候, LRU算法就负责进行替换分析与处理。如果替换出的页面数据被更改, 修改队列中就会需要写入硬盘的数据页, 按照ID进行排序, 以此完成对磁盘的顺序读写。

3 结语

如前文分析, 海量URL的管理技术的目标就是设计稳定而高效的管理系统, 对URL和附属信息进行快速的访问与查询、存储等。而借助web爬虫技术是当前实现快速查询URL数据库的重要措施。为了到达这个目标, 在对web爬虫的爬行过程进行分析后, 研究提出了基于海量URL的快速文件系统。在实现快速文件系统的过程中借助了B+Tree索引、URL去重, 内存和缓存交换算法、I/O优化等方面的技术, 最终完成对快速系统的实现。

摘要：海量的URL快速文件系统建立的目标就是提供高速的处理机制, 此时以高性能的web爬虫为基础的系统可以帮助实现这个目标。为了实现这个快速目标, URL往往将被保存在一个专业数据库中, 但数据量的增加会给爬虫技术带来巨大的压力, 关系数据库往往不能满足爬虫对海量URL的存储需求。本文所研究的是数据规模增加是如何打破web爬虫的技术瓶颈, 从而使得系统获得更加优化的利用效果与速度的。

关键词：海量URL,web爬虫,爬行策略,系统构建,系统模块

参考文献

[1]李永喜, 陈小平, 杨兴良.一种基于内容的Web服务器集群调度算法[J].计算机应用与软件, 2008 (3)

[2]吕勇.基于URL索引划分的Web内容自适应算法[J].计算机应用与软件, 2008 (9)

[3]燕彩蓉, 彭勤科, 沈钧毅, 武红江.基于两阶段散列的Web集群服务器内容分配研究[J].西安交通大学学报, 2005 (8)

[4]邱振华, 苏光诚.浅析WEB集群架构解决方案[J].福建电脑, 2010 (10)

[5]吴德军, 孙建伶, 何志均.高可用性负载均衡信息发布平台的设计[J].计算机工程, 2006 (4)

[6]刘利强.基于集群系统的数字资源库的研究与设计[J].湖南理工学院学报 (自然科学版) , 2009 (2)

[7]曾庆江.负载均衡系统设计方案[J].计算机工程与设计, 2009 (19)

海量数据过滤系统 第6篇

随着互联网的发展, 网络数据的总量迅速增加, 并且数据形式也趋于多样化。海量的网络数据需要一个功能强大的管理系统对其进行组织和存储, 以满足用户的频繁访问和检索。

Zvents公司开发的Hypertable是一个大规模的结构化数据分布式存储系统, 用于存储和管理海量的网络数据。它采用Bigtable系统的数据模型, 提供了对数据布局和格式的动态控制和管理。虽然Hypertable系统参考Bigtable系统, 但是两系统仍存在一些差异。

1 数据模型

Hypertable是一个稀疏的、分布式的、多维的、排序的映射表。它用于管理海量结构化或半结构化数据, 实现对表数据高速存储与查找。这个映射表使用行关键字、列关键字和时间戳对表数据进行索引。

以crawldb Table为例讲述这个模型 (图1) , crawldb Table用来存储从互联网抓取到的网页信息, 每个网页包括URL地址、标题、网页内容、引用链接和抓取时间等。在Hypertable系统中, 网页数据按照URL地址进行有序存储, 每个URL索引的网页信息被当作表的一行数据, 而URL地址作为行关键字。除行关键字外, 网页的其它数据按照对应的列关键字和存储时间戳进行索引和存储。在表中, 行数据不具有完整性约束, 部分列数据可以没有, 而且不同行的列之间没有约束关系。

在Hypertable系统中, 行关键字是表的主关键字, 它是任意字符串, 此字符串是以’�’为结束符的。行关键字的长度不受限制。而在Bigtable系统中, 行关键字是任意字节数串, 它的长度一般是10-100B, 上限为64KB。

列关键字是对表数据的第二级索引。系统将所有列划分成不同的集合, 数据类型相近的列在同一个集合中, 每一个集合叫做一个列家族 (ColumnFamily) 。系统限制列家族的数目最大为256个, 每个列家族可以包含任意多个列, 由列限定词 (Qualifier) 区分不同的列。

Hypertable系统保存了同一表数据的不同版本, 它使用时间戳标识数据的不同版本。时间戳是一个64位的整型数据, 它精确到微秒级。

2 系统结构

2.1 体系结构

Hypertable系统包括三个主要组件 (如图2) :主服务器 (Master) 、数据服务器 (Range Server) 、客户端库 (Client Lib) 。同时, Hypertable运行在两个辅助组件上, 它们是提供锁服务的Hyperspace和底层中间件DfsBroker。

Hypertable系统和Bigtable系统的体系结构相似, 并且每个组件的功能也基本相同。两系统存在部分差异。首先, Hypertable的设计方案将设置一个备份主服务器, 用来接替故障的主服务器。其次, Hyperspace组件为系统提供分布式的锁服务, 但它只有一个服务器提供锁服务, 没有多服务器的选举机制和较高的可靠性, 同时它自身没有可靠的文件存储功能, 使用底层分布式存储系统。最后, Hypertable系统使用Dfs Broker中间件访问不同文件系统。在hypertable-0.9.0.4-alpha版本的系统中, Dfsbroker已经实现了对HDFS、KFS和本地文件系统 (local) 的接口。

2.2 表的结构组成

Hypetable系统的表结构和Bigtable系统相似, 由表结构信息 (Shema) 和多个数据块 (Range) 组成。下面着重介绍Hypertable系统的不同之处。

两系统的表结构信息都是由列家族信息和其它属性组成。但是Hypertable系统将功能相似的列家族划分成单独的访问组 (AccessGroup) , 如图3。如访问组可以包含多个使用频率较高的列家族, 系统通过设置此访问组为常驻内存, 提高列家族数据的读写效率。

Hypertable系统以Range为单位管理表数据, 同时以访问组为单位进行表数据读写。如图4, 每个Range包括多个访问组对象 (AGObject) , 实现面向列 (column-oriented) 的读写操作。访问组对象和表结构信息的访问组相对应, 都是列家族组成的集合, 但是访问组只是表结构信息的单元, 而访问组对象实现了一组列家族的数据读写功能。

每个访问组对象管理一个单元缓存 (Cell Cache) 和多个单元库文件 (CellStore) , 分别相当于Bigtable系统的Memtable和SSTable。单元缓存是位于内存中的空间, 负责保存客户端近期提交的数据。单元库文件是用于在磁盘上永久存储表数据。单元缓存和单元库保存了访问组内的表数据。当访问组对象接收到客户端提交的数据后, 它首先将数据保存在单元缓存中。当单元缓存满后, 系统将数据写回到单元库文件中。

2.3 对比分析

综上所述, Hypertable系统和Bigtable系统的差异包括体系结构和表结构组成两部分。Hypertable系统的增加备份主服务器的功能, 提高了系统的可靠性, 同时两个主服务器的同步和数据一致性增加了系统的复杂性。由于Hyperspace锁服务器是单机版的, 它的可靠性和稳定性要低于Chubby锁服务。Hypertable系统提供了DFSBroker中间件, 它可以访问不同的文件系统, 增加了系统应用范围, 但降低了数据的读写效率。

Hypertable系统的表结构增加了访问组。它可以向用户提供面向列的读写机制, 增加了数据的管理功能。由于系统在进行数据访问时, 需要经过访问组对象这一层, 导致了数据的读写效率有所降低。

3 工作原理

Hypertable系统借鉴了Bigtable系统的工作原理, 但在表结构数据管理和读写流程两方面仍然存在不同之处。下面着重对这两方面进行介绍。

3.1 表结构数据的管理

用户对表操作的第一步是创建表。用户向客户端提供表名称和表结构信息, 其中表结构信息是以XML形式存储的。客户端向主服务器发出表创建请求, 主服务器对请求进行响应, 启动表创建操作。在表创建过程中, 主服务器首先加载表结构信息, 创建Schema对象;之后, 主服务器在Hyperspace上创建表文件, 这个文件以表名称进行命名, 然后将表的ID号和结构信息写入到表文件中;从而表结构信息存储在可靠的表文件中, 保证其不会在系统故障时丢失。

在对表进行读写操作之前, 用户需要创建Table对象, 加载表的结构信息。在此版本中, 主服务器没有保存表结构信息, 因此, 客户端需要向Hyperspace发出请求, 读取表文件, 加载表结构信息。

由于主服务器没有缓存表结构信息, 用户在每次进行读写操作时都需要从底层文件中读取, 这样将会降低读写效率。在当前版本中, 系统没有提供对表结构信息的修改接口和表的权限控制功能。

3.2 表数据的读写

在客户端查找到所需Range的位置后, 用户开始进行读写操作。系统对读写操作的处理从客户端开始, 客户端收集用户的读写请求, 将其分组提交给数据服务器;由数据服务器进行再次分类, 分配给不同的Range对象;Range对象包含着所有的访问组对象, 对表数据的读写任务最后由访问组对象来完成。如上所述, 每个访问组对象包含一个单元缓存 (Cell Cache) 和多个单元库 (Cell Store) 。访问组对象将数据写入到单元缓存中, 并最终写入到单元库文件中;同样, 访问组对象读取单元缓存和单元库中的数据, 将其合并后返回给用户。

在Hypertable系统中, 表数据的写入操作包括四个阶段: (1) 客户端收集更新数据并分组提交; (2) 数据服务器接收更新数据, 解析并分配给所在的Range对象; (3) Range对象将数据添加到对应的访问组对象中, 由访问组对象完成数据的写入; (4) 访问组对象执行数据整理操作, 将缓存的更新数据写回到单元库文件中。

Hypertable系统设置了多种扫描器 (Scanner) 完成数据的读取, 不同层次具有不同的扫描器, 包括:表扫描器 (Table Scanner) , 合并扫描器 (Merge Scanner) , 单元缓存扫描器 (Cell Cache Scanner) , 单元库扫描器 (Cell Store Scanner V0) 。由这些扫描器在不同层次进行数据的查找和读取。实现扫描器的基础是查找条件的指定, 在此系统中, 查找条件的指定是通过ScanContext对象来实现的, 读取到的扫描数据以扫描块 (ScanBlock) 的形式返回。

单元缓存扫描器和单元库扫描器分别在单元缓存和库文件中查找所需数据, 按照存储顺序返回数据记录。每个访问组对象具有一个合并扫描器, 它统一收集单元缓存扫描器和单元库扫描器的查找数据, 返回给Range对象。最终所有满足条件的数据返回给客户端的表扫描器, 由它逐条输出给用户。

4 总结

Hypertable系统通过借鉴Bigtable系统的数据模型和实现原理, 采用多维巨型表的形式对海量数据进行管理, 基本实现了数据表的管理功能, 但是两种系统存在着部分差异。首先Hypertable系统采用了不同的体系结构, 提高了系统可靠性和应用范围, 但在一定程度上降低了数据的读写效率。其次, Hypertable的表结构增加访问组的设置, 增加管理功能。

参考文献

[1]Google Wiki.Overview of Hypertable Architecture[EB/OL].2008.http://code.google.c om/p/hypertable/wiki/ArchitecturalOverview.

[2]Google’s BigTable[EB/OL].2005.http://andrewhitchcock.org/?post=214.

[3]Doug Judd.hypertable-0.9.0.4-alpha[CP/OL].2008.http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd.

[4]Chang F.Dean J.Ghemawat S.Hsieh W.C.Wallach D.A.Burrows M.Chandra T.Fikes A.Gruber R Bigtable:A distributed structured data storage system[C].In7th OSDI.2006.

海量数据过滤系统 第7篇

一、任务分配的基本概念

操作系统中“任务”和“进程”是同一概念的不同说法。任务分配与调度中的“分配”和“调度”也属于同一概念。在操作系统的客户/服务器模型中, 分配是从服务器考虑的, 而调度是从客户方所看到的。按通常的习惯, 我们分别成为静态分配和动态调度。

任务分配是指在多处理机系统中, 针对某一目标, 按照一定的策略将规模为N的任务划分并映射到P个处理机上。任务分配的主要目标是寻找一种合适的分配算法, 使T降低到最低程度。

二、任务配置模型

主机任务由任务定制生成, 每项主机任务定义一次数据发送内容的完整信息。按执行方式任务分为轮循任务、间隔任务和触发任务。每项任务以任务编号为标识, 包括任务名称、任务类型、执行时间、数据源信息、传输数据配置信息等。

三、任务描述模型

任务调度模型描述如下:1.系统有一组处理器 (Pi) 和一组实时任务 (Ti) 组成, 并有一个处理器作为专门的中心调度器;

系统中每个传输节点有一台主机用于任务定制和子机调度, 因此它作为中心调度器, n (n>=1) 个处理子机完成数据解析、数据发送和数据接收任务, 子机集合P={P1, P2..Pn}。每个子机Pi (i=1, 2, ..n) 拥有子机IP, 传输速度等属性[1]。

2. 任务队列T={T0, T1, Tm}表示m (m>=0) 个不同的任务, Ti包含子任务Ti1, Ti2, Tin.。每个实时任务Ti都是周期性任务。有任务定制随机产生。每个任务Ti (i=1, 2, m) 拥有任务ID、任务f类别、开始时间 (Bi) 、执行周期 (pi) 、执行时间 (Ri) 、数据源信息、目标节点等属性。

3. ei, j为Ti, j的最大执行时间, 即子任务Ti, j的每个作业的执行时间不会超过ei, j。

4. di为实时任务Ti的截止期 (结束时间) , 由于pi是执行周期, di=pi, 如第一个子任务的作业释放被的时刻为t, 则最后子任务Ti, n相应作业必须在 (t+di) 时刻完成。

5. 每个子机有自己的调度队列。这样, 在它执行完当前任务以后, 就从其调度队列中取出一个新的任务来执行。

6. 主机调度器与各处理器之间的通信通过调度队列来实现。

四、并行任务分配与调度策略

并行传输过程由主机完成任务分配及子机调度, 子机进行数据解析和传输。由任务定义程序在完成一项传输任务的定制后, 保存相应传输信息, 并将在主机任务队列生成一条任务记录。任务代理[2]负责监控任务队列, 发现匹配的任务向子机分配任务。

(1) 竞争调度策略

竞争调度方式不需考虑各子机的数据传输能力, 采用让子机竞争方式完成任务。主机任务代理检测到主机任务队列中有需立即执行的任务, 向每个空闲子机的任务队列发出传输数据任务, 子机接到任务后开始执行。

(2) 平衡调度策略

平衡调度方式将解析和传输处理同时进行, 主机动态调节解析子机和传输子机的负载平衡。

(1) 主机任务代理检测到主机任务队列中有需立即执行的任务, 向每个空闲子机的任务队列发出解析数据任务, 子机接到任务后开始执行。

(2) 子机解析数据时每次从业务数据库中读取2000 (参考数据) 条记录直接解析到主缓冲池。

(3) 子机检查子机任务队列:1) 无任务, 等待;2) 有解析任务, 重复解析2000条记录直接解析到主缓冲池, 重复2;3) 有发送任务, 从主缓冲池读取2000条记录到子缓冲池, 同步发送到接收端, 重复3。

(4) 主机按设定时间间隔监控主缓冲池动态, 当未发送记录数大于L1时, 将一台解析子机任务转为发送;当未发送记录数小于L2时, 将一台发送子机任务转为解析。任务调整后, 子机在完成上次任务后再次检查子机任务队列时领取新任务。设定值L1、L2在系统运行时根据实际情况调节设定。

(5) 当所有子机任务均已完成时, 主机认为本次发送任务完成。

平衡调度策略适用于子任务分配 (在子任务中再细分, 任务号_表名) , 没有足够的时间进行整体任务分配, 需要按子任务细分。

摘要：本文对并行传输任务分配与调度机制的环境与策略进行了较为详细的介绍。对任务分配的基本概念、任务配置模型、任务描述模型、任务调度的种类和并行任务分配与调度策略等都做了较为详尽说明, 尤其对任务分配与调度算法的可行性进行了严密的论证。

关键词：并行,任务,调度,策略

参考文献

[1]沈卓炜, 汪芸.基于EDF调度策略的端到端实时系统可调度性分析算法, ISSN1000-1239/CN11-1777/TP, 43 (5) :813～820, 2006

[2]Jesus M.Milian_Franco.Adaptive Middleware for Data Replication[A].H.-A.Jacobsen.Middleware2004[C].LNCS3231:IFIP International Federation for Information Processing, 2004:pp.175-194.