分布式无线网络平台

分布式无线网络平台（精选10篇）

分布式无线网络平台 篇1

0 引言

随着互联网络规模不断扩大,大数据、云计算、工业互联网等互联网新技术不断深入日常生活的同时,各种网络攻击、敏感信息泄露等恶意信息安全事件也频繁发生。国家互联网应急中心调查显示,2015年涉及重要行业和政府部门的高危漏洞事件增多,基础应用或通用软硬件漏洞风险凸显,安全形势更加严峻。

为了不断应对新的安全挑战,各个中大型企业和组织先后部署了防火墙、UTM、IDS、IPS、漏洞扫描系统、防病毒系统、终端管理系统、WAF、DB-AUDIT以及安全监控平台等,构建起了一道道安全防线。然而,这些安全防线都仅仅抵御来自某个方面的安全威胁,形成了一个个“安全防御孤岛”,无法产生协同效应。更为严重地,这些复杂的IT资源及其安全防御设施在运行过程中不断产生大量的安全日志和事件,形成了大量“信息孤岛”。有限的安全管理人员面对这些数量巨大、彼此割裂的安全大数据,操作着各种产品自身的控制台界面和告警窗口,显得束手无策,工作效率极低,难以发现真正的安全隐患。因此,面对目前这种复杂的网络环境以及海量的安全数据,本文提出了一种基于大数据分析的分布式网络安全管理平台的设计方案。

1 关键技术概述

1.1 大数据安全分析

目前,大数据与安全分析技术的结合成了信息安全市场的热点话题,并且大数据分析在网络安全与信息安全也取得了一些成果。特别是利用大数据分析技术来发现和甄别风险和漏洞。通过大数据分析技术,我们可以分析大量的潜在安全事件,找出他们之间的关系,从而勾勒出一个完整的安全威胁。不仅如此,通过大数据分析技术,还可以将原本杂乱无章的分散数据整合起来,从而为安全人员采取更加主动的安全防御手段提供依据[1]。

1.2 Storm

Storm是一个开源的、大数据处理系统,与其他系统不同,它旨在用于分布式实时处理且与语言无关。Storm主要是为了解决来源为高度动态的实时信息的问题而提出来的。Storm与其他大数据解决方案不同之处在于它的处理方式。Hadoop在本质上是一个批处理系统。数据被引入Hadoop文件系统(HDFS)并分发到各个节点进行处理。当处理完成时,结果数据返回到HDFS供始发者使用。Storm支持创建拓扑结构来转换没有终点的数据流。不同于Hadoop作业,这些转换从不停止,它们会持续处理到达的数据[2]。

1.3 Elastic Search

Elastic Search是一个基于Lucene构建的开源分布式搜索引擎,具备高可靠性。它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful Web接口。Elastic Search是用Java开发的,并作为Apache许可条款下的开放源码发布,支持时间索引和全文检索[3]。设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便[4]。

1.4 Hbase

Hbase即Hadoop Database,是一个分布式的、面向列的开源数据库,该技术来源于Fay Chang所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样,HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式[5]。

1.5 Kafka

Kafka是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者规模的网站中的所有动作流数据。这种动作(网页浏览,搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop的一样的日志数据和离线分析系统,但又要求实时处理的限制,这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理,也是为了通过集群机来提供实时的消费[6]。

2 基于大数据的分布式网络安全管理平台设计

2.1 平台架构设计

如图1所示,平台设计按照数据处理的流程分为5个层次,数据源、数据收集、数据预处理及存储、数据分析以及数据展现。其中数据源为网络安全分析系统的最底层,作为整个系统的输入,原始数据源包括来自核心交换机的镜像流量、Net Flow、安全设备Syslog日志(防火墙、IPS、IDS等安全设备)以及其他安全监控系统的告警数据等,除此之外,数据源还应包括信息网络中所有资产的配置信息(如资产库)与外部情报(如漏洞库、病毒库、信誉库等)。

输入的数据按照不同种类进入到数据收集层,采用分布式数据收集组件Flume对非结构化数据进行收集,收集到的数据暂时缓存到Kafka组件中以便后续数据处理使用。结构化数据通过Webservice进行收集,并存储到My SQL中。数据预处理及存储层采用流计算组件Storm对收集到的数据进行预处理,包括数据标准化、数据去重、数据加强等。数据存储包括结构化存储和非结构化存储两部分。数据分析层主要包括大数据计算和大数据分析两部分。分析部分包括用图形化数据挖掘工具实现的可视化辅助分析、用Elastic Search和Lucense实现的数据搜索分析、用数据融合组件Candy对分散保存在各处的结构化和非结构化数据进行融合汇总分析。大数据计算部分包括Nana组件对离线历史数据的挖掘以及Storm组件对数据流的实时计算。数据展现层主要采用可配置图形分析工具提供丰富的可视化展示功能,包括当前网络安全态势以及一些预警信息展示等。

2.2 平台数据流程设计

网络设备、外部系统、原始流量分别采用syslog、webservice、sftp和netflow进行收集,收集到的数据通过flume或ftpd进行传输进入到数据处理队列kafka中,对于收集到的文件直接保存到HBase中。数据队列中所保存的为原始数据,数据队列进行本地缓存以便进行后续处理。

如图2所示,当数据进入到流计算中后,首先进行解析转换工作;之后按需要对数据进行加强,如补充资产编号、地理信息等;增强后数据创建索引保存到实时索引Elastic Search中,此时的数据量会有一定程度的增加,数据保存到HBase中进行长久保存;同时进行基于规则的告警触发,触发符合规则的告警。增强的数据按需要通过安全模型中定义的规则进行轻度汇总,轻度汇总产生的数据进入到HBase中进行保存,由于数据已经被处理过所以数据量会有一定程度降低;告警信息被触发后会产生告警数据,这些告警数据会保存到数据长久保存HBase中同时在展示层进行告警处置。另一部分增强的数据会进入到机器学习模块中进行自动化分析,通过此模块实现更为智能的安全关联分析,机器学习的结果进入到HBase中进行保存,由于数据已经被处理过所以数据量会有一定程度降低。

机器学习是目前国际较为先进的技术,通过机器学习实现人工分析难以完成的目标。常见的机器学习算法有聚类、梯度下降、K均值等,这些算法的使用能够极大的帮助分析人员找到数据中的详细点或更快捷的进行数据挖掘。

情报系统产生的数据直接保存到结构化数据My SQL中。当进行重度汇总时,通过Candy将HBase、Nana、My SQL进行融合处理,将重度汇总后的结果保存到HBase中。

可配置图形分析工具提供索引查询、汇总显示、告警处置、威胁预警等信息的展示。

3 实验测试

3.1 实验拓扑和参数

基于大数据的分布式网络安全管理平台采用B/S架构,支持集群方式的集中部署、统一管理。实验通过在隔离的实验环境中进行测试,如图3所示,Node1~Node11、模拟日志采集器和模拟流量发送器均接入一台交换机组成局域网,IP地址为192.168.1.11~192.168.1.21,其中Node1~Node11组成大数据集群和分布式存储,Node1和Node2为主备管理节点,Node3~Node9为数据存储节点,Node10为大数据集群总线调度节点,Node11作为大数据分析平台前端展示节点;模拟日志采集器利用已有的日志样本模拟生成海量的日志数据人工导入日志采集器,并使用PC模拟发送网络流量。

实验所用服务器均为高性能服务器,其中分布式网络安全管理平台由11个服务器节点组成,日志采集器使用1台syslog日志采集服务器,流量模拟器用1台PC进行模拟发送数据包。实验测试设备参数如表1所示。

3.2 实验结果

3.2.1 大数据查询检索实验结果

所示的拓扑完成大数据集群和分布式采集器的网络配置,并在大数据集群中预先导入10亿条以上的数据。

(1)等值查询

数据中精确检索一个时间点的访问记录,例如检索时间点为2014年8月24日13:31:51的DNS数据,不添加其他任何条件进行检索,查询出全部符合条件的的数据,并且查询出结果仅耗时204ms。

(2)范围查询

数据中检索一个时间范围的记录,例如设定时间范围为2014年8月24日13:31:51到2014年8月24日14:31:51,不添加其他任何条件进行检索,查询出全部符合条件的的数据,并且查询出结果仅耗时147ms。

(3)关键字查询

数据中查找对某个host的访问记录,例如设定关键字为qq.com,不添加其他任何条件,查询出符合条件的数据,并且查询出的结果仅耗时225ms。

3.2.2 大数据关联分析结果

平台中预置关联分析规则,规则为120s之内接收到5条登陆失败日志生成一个安全事件。做如下几种情况的模拟实验:

①用流量模拟器模拟发送4条登录失败的日志,等待120s之后,在管理系统中查询。在检索结果中未发现安全事件。

②先用流量模拟器模拟发送4条登录失败的日志,等待120s之后,再用模拟器发送1条登录失败日志,在关联分析结果中进行检索,并且在检索结果中未发现安全事件。

③先用流量模拟器模拟发送4条登录失败的日志,在120s之内,再用模拟器发送1条登录失败日志,在关联分析结果中进行检索,并且在检索结果中发现1条安全事件。

4 结束语

数据爆炸式的增长,海量的多源异构安全数据给传统的安全管理平台带来前所未有的挑战,主要是体现在数据采集能力、数据分析能力、安全告警精度等多方面,本文采用大数据的安全分析的手段,结合HDFS、Storm、Elastic Search、Hbase、Kafka等多种开源分布式组件,实现了基于大数据的分布式网络安全管理平台,并通过内置关联分析规则,大大提高了海量安全数据的分析能力与精度,不但解决了传统安全管理平台的数据管理和分析处理压力,而且通过采用分布式部署的方式,提高了平台的可扩展性。

参考文献

[1]zeon,大数据安全分析的6个要点[EB/OL].(2014-07-17).http:∥www.aqniu.com/industry-case-study/3625.html.

[2]Tim Jones M.使用Twitter Storm处理实时的大数据[EB/OL].(2012-12-05).http:∥www.ibm.com/developerworks/cn/opensource/os-twitterstorm.

[3]Elastic Search[EB/OL].http:∥baike.baidu.com/link?url=Iixquh AAKlh Xw0En1j KFg D99-VO4Xn23z M7Zr1ON_j ENRe Fj_nv N-73lRBns IL-Xov Mjc M-pc Dm SZvp J4aRi Kha.

[4]分布式搜索引擎Elastic Search[EB/Ol].http:∥www.oschina.net/p/elasticsearch/.

[5]Hbase.http:∥baike.baidu.com/link?url=vqg Il Bncb IHNQz QMaHi4h Hd GYGz4QFJX7W2l EWx Od CQXe_g DRF2mRMoekh7a AM8-t8Gmy XZ2kf I4A9AR7J0d USa.

[6]郭俊.Kafka剖析(一):Kafka背景及架构介绍[EB/OL].(2015-03-10).http:∥www.infoq.com/cn/articles/kafka-analysispart-1/.

分布式无线网络平台 篇2

针对工业设计实验室建设中存在的问题，探索分布式资源环境下创新实验平台建设模式，为提高工业设计实验室创新水平，以及创新人才培养进行有益的尝试。提出通过利用大量的分布式实验资源，构建共享创新实验平台，为学生提供一个开放式的创新平台，实现创新人才的培养。探索思考了分布式资源环境下的工业设计创新实验室发展建设新模式。

关键词：

分布式资源 创新 设计 实验平台

中图分类号：G622

文献标识码：A

文章编号：1003-0069（2015）07-0094-03

随着设计类人才的需求量逐年增加，社会对设计类毕业生的能力要求也越来越高。工业设计专业学生的核心专业能力.设计创新实践能力的培养需要依托完备的各类实验室资源，通过大量的设计实践来提升设计能力。但是，由于大部分高校工业设计专业办学历史较短，工业设计实验室建设滞后，实验设备不齐全，出现了实验室建设现状与专业人才创新能力培养需求的不匹配一些问题，很难完全满足实验教学需求，影响了工业设计专业学生设计创新能力的发展。如何进一步优化校内实验资源配置，提高实验室综合效益，寻求校外实验资源，拓展实验资源渠道，已成为工业设计专业实验室建设亟待解决的重要问题。

1 分布式资源理论介绍

分布式资源实际上是分布式智力资源环境的简称，在这个环境中，所有设计实体和智力单元之间交换的是信息或由信息构成的知识，知识服务的请求方发布的是信息，知识服务的提供方提供的信息或者知识。所有这些都可以在信息高速公路上传递，连同信息和知识在设计实体和智力单元内部的流动，构成了现代现代设计的基本模式。

工业设计专业的实验教学以设计实践为主，设计活动是该专业实验过程的主要呈现形式。在分布式资源环境中，设计是以已有知识为基础，以获取新知识为中心的创造性活动。在知识经济时代，基于知识的设计理论研究，尤其是基于网络环境的分布式知识资源的获取和重复利用策略的研究，已经成为创新设计的研究重点之一。

设计活动中无论是已有的或者新的理论、方法和技术，还是新的产品系统或工艺，本质上都属于知识的范畴。分布式知识资源环境中知识以资源单元的形式成分布式存在状态，能否实现对知识的获取重用是实现创新的关键。在分布式资源环境中，资源单元掌握着各自领域中领先的单元技术，而设计实体则掌握了系统或产品的集成技术，在资源单元和设计实体的合作过程中，相互之间的耦合作用将加速技术的进步，而恰当的知识如何在恰当的时间以合适的形式流向知识的需求方是设计创新的关键。

2 创新实验平台研究现状分析

2.1 国内研究现状

在国家对高校实验室管理建设研究的不断推动下，全国高校开展了实验室建设新模式的探索和研究。实验系统的建设思想明显受到计算机网络技术的影响，基于网络化、模块化、开放性等原则，实验系统也逐渐由传统的集中模式转变为分布模式，成为具有开放性、可互操作性、分散性、网络化、智能化的网上实验系统。

国防科学技术大学提出了基于Internet/lntranet的分布式实验系统设计目标和体系结构，并对系统组建的关键技术进行了研究，为未来实验室建设提供新的思路。复旦大学结合利用计算机辅助技术提出了一种分布式实验系统的设计与实现方式，这一实验模式为探讨自动化、网络化在推动产、研、学一体化发展中的应用方式打下基础。大连理工学院将仿真实验与互联网技术相结合，提出了分布式机械仿真实验室的概念。通过网上虚拟实验室，可以实现工业生产现场、科研院所实验室、最终用户现场等各方面专业技术人才的动态联盟。清华大学利用国家教育科研网（CERNET）开发了运行在CERNET环境中分布式国家重点实验室信息管理系统，为实验室日常管理的科学化规范化、公共信息资源系统的共享提供了新的模式。广东石油化工学院针对普通高校与中小企业校企合作共建受限的问题进行了分析，提出了分布式创新实验平台的建设方案。这种分布式校企共建模式为以应用型人才培养为主的普通工科院校提供了有价值的借鉴。空军工程大学提出了新型分布式网络工程实验室建设方案，采用创新的模块化设计、分块建设的规划设i+，在兼容性、可扩展性、开放性、经济性、可管理性等方面具有独特的优势，可有效克服建设经费、场地、实验室管理维护等制约条件。

2.2 国外研究现状

美国国家研究委员会提出：现代实验室是一个无墙的中心，通过计算机网络系统，研究人员或实验人员能在其中从事科学研究和工程设i+，不必顾及时间和地理位置的限制，共同协作；能共享仪器、设备、数据、计算资源以及数字图书馆等信息资源。美国illinois大学的Nmrscope系统，通过Intemet，研究人员在任何地方都能使用illinois大学的仪器。美国Johns Hopkins University的化学工程系的卡尔威教授（Professor MichaelKarweit）建立了一个工程虚拟实验室，学生可以通过电脑网络来做实验，尝试解决工程上遇到的各种问题。

2.3 实验室建设发展趋势分析

通过以上文献研究分析，实验室建设发展趋势主要体现在以下几方面：

（1）创建分布式共享实验平台成为实验室发展的趋势。在实验室建设过程中，自身实验资源与其他实验资源以分布式状态存在，针对实验任务需求，借助共享实验平台调用所需实验资源，实现各方面实验资源的“互通有无”。这样既能拓展自身实验资源，也能避免实验室的重复建设。

（2）互联网与物联网等先进技术为分布式实验室建设提供了技术支持。基于分布式实验资源的实验室建设，除了需要实验需求信息的共享之外，甚至需要实现直接对实验资源的远程共享，这需要借助互联网与物理网等先进技术来实现真正意义上的实验室共享。

（3）分布式共享实验平台没有统一标准。虽然对分布式共享实验平台建设有了很多的研究和实践，但是研究者都是根据各自的条件进行共享标准和技术参数。如何实现更大范围，更加通用的分布式共享实验平台标准需要深入研究。

nlc202309030102

3 工业设计创新设计实验平台建设模式研究

3.1 工业设计专业创新设计实验平台建设特点

工业设计专业是以培养应用型设计人才为目标，具有较强的实践性和文理交叉性。学生不仅具有坚实和宽广的基础理论知识，同时还应当经过比较系统的机械制造、美学、经济等多方面知识的学习训练。“应用型”学生的培养需要依托各类实践教学的不断训练，单独依靠工业设计实验室很难满足该专业学生综合能力的培养，创新能力的提升受到较大制约。实验室的建设更新速度往往滞后于人才需求的变化，已成为学生创新能力培养和专业发展的短板之一。

工业设计专业最大的特点就是“创新”，优秀设计本身具有很强的科学性和逻辑性，必须依靠科学的实验验证分析来支持设计过程，这需要科学分析型实验设备的支撑。随着实验对象越来越复杂，单纯依靠自身的实验资源已经很难完成，实验室建设的社会性愈发显著，借助自身之外的实验资源已成为必然趋势。在自身实验资源不完备的情况下，借助校内外的实验资源，实现分布资源的整合利用，构建创新实验平台显得很有必要。实验室建设由原来的“垂直式实验资源模式”（图1），转变成为“分布式实验资源模式”（图2）。

工业设计专业的实践教学过程由一个个设计创新活动组成，对实验资源的需求同样存在多样化，单纯依靠自身实验资源很难满足教学需求，需要借助分布式资源来丰富实验室资源。对于分布式资源的利用关键在于“资源共享机制”的建立，只有建立各个资源所有者共同认可的共享机制才能真正实现资源的有效共享，最终实现共赢。现在常用的方式主要是借助互联网技术来搭建资源的共享平台，同时制定一些列资源共享约束性制度。由于工业设计实验室建设需求的多样化，需要众多存在于校外的实验资源，与校外实验资源构建共享平台的研究还很不足，工业设计专业在这方面尤其突出，需要对分布式资源共享机制进行研究完善。

3.2 工业设计专业实验资源分布体系理论研究

分布式资源环境下的共享创新实验平台建设关键是实验资源的获取与共享，每个实验室可以看作一个资源单元，大量的资源单元以分布式状态存在，不同需求主体可以根据自身的需求来对资源单元进行选择性整合。每一个需求主体同时既可以获取其他资源单元，也可以当作一个资源单元为其他需求主体提供服务，整个需求链条依托于一个共享平台，最终构建了一个动态的资源生态链（如图3）。

分布式资源环境中高校、科研院所、企业、团体协会、政府等都可以成为资源单元，实验资源以分布方式存在于这些资源单元之中。每一个大的资源单元还可以继续细分，形成内部分布式资源单元生态链。工业设计实验室首先要明确自身资源优势和不足，通过资源分布体系的梳理整合，发现实验室实验资源上的“缺口”，同时对外提供自身的优势实验资源，进而有针对性与校内的其他实验室、校外科研机构、企业、政府团体等进行合作，获取本专业人才培养中急需的实验资源。设计活动中除了实验设备等硬件实验资源之外，教学过程中大量的设计创意方案也是无形的设计资源，这对于生产企业来说具有较大吸引力，这些资源可以作为工业设计实验室与其他机构进行合作的优势资源。

3.3 工业设计共享创新实验平台构建模式研究

随着数字化技术、社交网络和移动技术的飞速发展，人与人之间的互联互通开始成为现实。新技术和新工具必将有力地促进机构内外的各种协作，并催生和助力组织之间的共享创新。共享创新根据创新主体不同可以分为以高校为主体、以企业为主体、以科研院所为主体、以政府为主体、以协会社团为主体等不同的共享创新模式。机构内部的“垂直式共享创新”便于资源的统筹管理，但是存在资源局限性，不能与更多的资源实现共享，共享创新能力较低。多个机构之间的“水平式共享创新”理论上能获得海量的资源，共享创新活力旺盛，但同时也存在机构间合作约束机制的平衡问题，怎样找到合作机构间的利益平衡点是实现“水平式共享创新”的关键。工业设计实验室与校外机构的共享创新主要以教师为主体，依托教师高水平的科研项目或者企业技术难题，联合校外机构的软硬件设备，进行科技创新型的共享创新，最终实现“产学研共享创新”（如图4）。

4 总结

观念更新是共享创新实验平台构建的前提。实现共享创新实验平台构建的基础是合作，转变传统的个体研究和“单兵作战”的旧模式，大力倡导联合攻关和“兵团作战”的新观念。共享创新实验平台构建既需要高等学校内部的合作，更需要高等学校与科研院所和企业的合作，高等学校的科研管理部门在其中要发挥关键性的组织协调作用。机制创新是共享创新实验平台构建的关键。为了实现各个创新主体共享信息，整合资源，共享创新，需要在机制上解决五个方面的问题。一是组织管理的机制问题，二是绩效评价的机制问题，三是权益分配的机制问题，四是资源共享的机制问题，五是信息沟通的机制问题。绩效评价和权益分配又是五个问题的重中之重，因为评价系统事关价值导向，不同的绩效评价将制约着实验平台构建的方向、目标和力度；同时实验平台构建涉及多个利益实体，权益分配问题如果不能妥善解决，则会在很大程度上影响和阻碍创新的健康发展。

分布式无线网络平台 篇3

在分布式远程网络教学中, 采用多节点技术来进行教学资源的采集、存储、传输和播控是当前比较流行的方式, 其具有的高可靠性、低成本性非常方便管理员进行网络扩张, 但也给数据维护带来了一定的困难, 如同步复制、容灾备份、存储管理等等。随着网络资源的增长, 如何做到在后台文件的整合过程中让用户更透明、有条理地访问各节点的文件资源而并不中断访问进程, 这是我们在构建分布式网络教学平台中亟需解决的问题。

DFS (Distributed File System, 分布式文件系统) 是Windows 2008服务器所自带的一种多线程、多主机访问引擎技术, 它可以提供从一个单独的网络名重定向到一个跨越多个服务器的数据共享, 并支持相同的容错DFS根或子节点副本的复制, 这样, 不但能较好地解决了同一网络平台下不同课程资源的共享问题, 又兼顾了资源的维护与动态更新。本文将研究如何利用DFS技术来改善服务器端节点资源的存储结构, 进一步提升网络数据的传输质量, 以满足多学科、多功能的分布式教学需要。

1 DFS的技术特性介绍

作为微软BOIS (分公司基础结构解决方案) 体系中的一个重要基础服务, 微软在Windows 2008 R2中对DFS技术进行了重新设计, 不仅支持过往版本的分布式文件系统功能, 还将文件复制服务 (FRS) 也集成进来, 对于网络的负载平衡和容错性能也有很大的改善。

1.1 DFS的类型

分布式文件系统有以下两种不同类型的工作方式:

(1) 独立的根目录分布式文件系统。该类型提供了DFS特有的唯一命名空间, 命名空间由拥有根目标的服务器定义, 其目录配置信息也存储在本地的根服务器上, 没有根级别的容错, 因此, 当根目标不可用时, 整个DFS命名空间也都不可访问。通常, 独立的DFS系统部署在不含有活动目录域的网络环境中。

(2) 域分布式文件系统。该类型的根目标必须是活动目录 (Active Directory) 域中的一个成员, 其命名空间由创建根时所指定的域名提供, 因此, DFS的拓扑信息被存储在活动目录并可被多个域控制器使用。在域DFS类型中, 支持文件自动复制和容错功能。

1.2 DFS的命名空间

DFS命名空间能够为用户提供对所需网络资源统一和透明的安全访问, 它包括一个DFS根目录、一个或多个DFS链接以及指向一个或多个目标的引用。为了使得用户在访问一个DFS目录时就可以访问网络中各个节点的所有共享资源, 管理员需要将网络中的共享文件夹映射到DFS命名空间中, 这样才会形成一种易于理解和操作的虚拟网络资源树结构。

通过DFS的命名空间技术, 一台服务器上的某个共享点能够作为驻留在其他服务器上的共享资源的宿主, 当用户访问时看起来和普通的文件夹一致, 即无需知道具体的服务器名称或存放数据的共享文件夹即可进行浏览。DFS命名空间的路径描述与共享文件夹的通用命名约定 (UNC) 的路径相似, 其格式如下:

DfsServer DfsRoot

1.3 DFS的复制

虽然都是属于分布式文件系统中的技术, 但是从技术角度上来说, DFS复制和DFS命名空间是完全独立的, 只是通过DFS复制可以让DFS命名空间更好的工作。由于分布式网络教学平台中的资源大都存储在不同的服务器或不同的磁盘卷上, 当这些资源节点发生故障时, 就会造成无法访问或数据不同步的情况, 因此, 可以充分的利用DFS复制技术, 将分散在不同节点的数据自动同步到中心服务器。

Windows 2008 R2下所提供的DFS复制是一种基于状态的多主机复制引擎技术, 支持复制计划和带宽限制, , 由于其采用的是远程差分压缩 (RDC) 算法来检测文件中数据的更改, 因此, 其复制过程仅复制已更改的文件块而非整个文件, 复制的数据源也可以位于不同的磁盘卷, 且不必是共享文件夹或命名空间的一部分, 但若要实现DFS的自动复制流程, 则需要创建一个基于域的DFS根和复制组集合, 并将要复制的文件夹添加到该集合中。

2 构建网络教学平台的DFS引擎技术

2.1 网络教学平台的运行特点

分布式网络教学平台是公共计算机网络教学资源的重要组成部分, 其资源的体现形式除了文本信息外, 还包括大量的非文本信息, 如图形、图像、声音、视频、动画等, 呈现出多类型、多媒体、非规范、跨网段等特点。随着课程数量的增加、建设时间的推进和网络节点的扩张, 服务器端的存储需求越来越高, 管理的复杂性也越来越大, 要解决这个问题, 必须建立一个高效率的存储基础架构, 完善各个存储节点的融合和控制, 并利用统一的管理技术对全部存储设备进行监控和报告。

因此, 要构建一个能提供稳定服务的高性能网络教学平台, 不能简单的认为在一台服务器上安装好任意一套网络教学软件就可以实现, 而是需要认真分析教学平台的每一个技术要素, 比如大型文件和数据量的要求、密集型访问方式、并行文件操作、视频流的读取等, 从其工作流的角度考虑来选择合适的技术方案。对于分布式网络教学平台来说, 恰当的部署DFS技术能够为平台的运行创造高效安全的资源存储环境。

2.2 网络教学平台的DFS引擎技术设计

DFS技术的指导思想是将网络中不同计算机上的共享资源组织成一个逻辑的分级目录结构, 用户只要从该虚拟网络文件系统的根目录出发, 就能够访问全网计算机节点上所有的共享资源。从技术部署来看, 这种解决方案的出发点主要是基于软件的虚拟技术来创建存储资源的单一命名空间, 由于允许用户自由组合和添加存储节点, 而节点的访问也都使用相同的数据池, 因此, 利用DFS的网关就可以快速的重定向到不同数据的存储层。根据前述介绍, 域DFS类会比单独的DFS具有更好的扩展性和容错性, 下面主要介绍域DFS类环境的设计方案。

(1) 系统的规划部署。

Windows 2008 R2下的DFS不仅是一种网络共享资源的访问技术, 也兼具有数据复制服务的功能, 其工作方式主要有以下两点:①客户端联系命名空间服务器, 并获取参照 (Referral) ;②客户端访问由参照提供的第一台文件服务器, 而承载服务器上的实际目标则会互相之间进行复制, 以允许本地参照。

分布式网络教学平台下要部署DFS技术, 其规划设计的流程可以分解为以下2个层次8个要点, 如图1所示。

(2) 定义命名空间。

命名空间说白了就是使用者连接网络的进入点, 在部署DFS时使用命名空间可以提高数据的可用性, 如果分支服务器出现故障, 那么客户端可以将连接转移到中心服务器, 而用户不必知道存放数据的物理服务器名称或共享文件夹即可浏览逻辑命名空间。

对初始命名空间的建立可以按照Windows 2008 R2下所提供的新建命名空间向导来进行操作, 其过程主要有以下4个步骤:①选择承载命名空间的服务器;②定义命名空间的名称、设置共享文件夹的权限;③选择命名空间的类型;④向命名空间根目录添加DFS链接、设置权限。

基于域的命名空间可以由多台命名空间服务器托管, 这些服务器可以放在远程机构或分支服务器上, 这样用户不必经过成本高昂的网络连接即可通过命名空间服务器联系并接收引用。此外, 若要使基于域的命名空间可以容错, 则至少需要设置两台命名空间服务器和两个域控制器, 这样可以避免目标服务器正常运行时, 用户却无法使用命名空间对其进行访问。

(3) 建立映射关系。

为了使得用户通过访问DFS根目录就可以访问网络中所有的共享文件夹, 需要管理员将这些共享文件夹映射到DFS的命名空间中以构成树状的文件夹资源结构, 它们是DFS命名空间的重要组成部分, 可以通过指定多个文件夹目标来提高DFS文件夹的冗余性, 如果其中一个文件夹目标不可用, 客户端将根据获得的目标优先级来尝试访问其他可用目标。

图2展示了我们所建立的网络教学平台中DFS架构的命名空间和映射关系的对应关系, 由于网络课程的资源结构比较庞杂, 访问流量大, 实际规划时部署了两台命名空间服务器 (ServerA和ServerB) , 两台文件复制服务器 (ServerB和ServerC) , 其中ServerB同时担任两种角色, 而DC Server为AD域服务器, 用以账号管理, 构建模型。

(4) 定制复制拓扑。

复制拓扑是DFS成员之间的复制路径的框架, DFS技术内置的复制拓扑包括有集中星型拓扑、全网型拓扑、环形拓扑、定制拓扑4种类型。由于分布式网络教学平台具有多台服务器, 其中一台或多台位于数据中心, 其余分支机构的服务器将连接到这些中心服务器, 为便于以后的拓展和管理, 建议采用定制的集中星型拓扑结构, 如图3所示。

Windows 2008 R2下的DFS复制向导可以为每台分支服务器设置复制组, 向导将在中心服务器和分支服务器之间建立两个单向连接, 这意味着在中心服务器上所作的更改将复制到分支服务器, 反之亦然。因为中心服务器将成为多个复制组的一部分并因此托管了不同节点下的已复制文件夹, 所以, 每个已复制文件夹中将拥有自己独立的磁盘配额, 可以存储暂存文件夹及冲突和已删除文件夹的数据, 并通过复制组级别进行委派以更好地控制用户的管理权限。

为了防止用户同时访问这两种服务器所导致的文件更改冲突, 通过在命名空间中发布已复制文件夹, 可以确保分支客户端用户先访问自己站点中的已复制文件夹, 只有分支服务器不可用时, 才会将连接转移到中心服务器。

2.3 结果的评估与改进措施

(1) 结果的评估。

为了评估上述所部署方案的设计效果, 我们从以下两个方面进行了实验, 以此来判断分布式文件系统是否适用于大量分散的非结构化数据的存储应用。①同步镜像测试:同步镜像测试包括了根目录同步和子目录同步两个部分, 它们都需要将测试服务器加入到同一网域, 通过网域来进行镜像管理, 同步主机的网络拓扑则选择完整网状, 以使得所有主机能进行同步测试。无论根目录还是子目录, 经过同步设置后其测试结果都是正确的;②双机容错测试:对于多节点的服务器, 最头疼的问题是单点故障, 而DFS技术的应用能够很好的解决这个问题。在双机容错测试中, 我们模拟了当主控端发生故障时的场景, 由于外界主机访问的路径是:NetCoursePublic , 所以当进行容错切换时, 没有丝毫影响, 备份的域通过切换, 承担起原来主域的所有工作。不过, 当备份服务器变为主控端时, 如果原主控主机修复, 则原主控主机变为备份服务器, 这是AD域环境中多主机复制模式切换的特点。

(2) 带集群存储的DFS技术。

DFS技术中所采用的是命名空间聚合方案, 它将不同物理存储位置中的资源集合为单个统一的数据库管理池, 这样, 不管是分属于不同磁盘卷的数据, 还是不同服务器的文件都将会被控制在某个特定的仓库, 这样的架构虽然有吸引力, 但对于异构型的存储仓库, DFS却无法体现管理能力, 更何况现在又多了个虚拟化层来增加管理的负担。

因此, 对DFS技术的改进可以考虑引入集群技术, 使其扩展为分布式集群存储, 在集群环境下分布式文件系统保持对节点之间的文件和数据布局的控制, 并在全集范围内分配和保持一致性元数据和锁定语意, 因而可以创建一个很大的全局存储池, 单个网络驱动器或单个文件系统可以无缝扩展到数百TB。

对于这种带有DFS的集群存储技术, 由于其部署的集群管理软件驻留在存储层, 因此它完全可以控制数据在构成集群的所有存储节点中的布局, 每个节点都独立运行, 并与其它节点进行通信以传输文件, 其可用性、可靠性、可扩展性和总吞吐量等特征都具有更高的性能指标。

3 结束语

Windows 2008 R2所提供的分布式文件系统属于一种命名空间聚合技术, 其优点是能够在文件布局上控制由哪个存储仓库来接收文件, 同时呈现并聚合文件的位置资源。由于DFS将物理存储映射到一个逻辑表示中, 为网络带来的好处是数据的物理位置对用户和应用程序变得透明了。

对于分布式网络教学平台, 多节点存储结构的特性决定其处理的信息包括了大量非结构化数据, 而使用并存储这些非结构化的数据正在挑战传统存储系统的容量和性能禁区, 因此, DFS技术的应用能够在一定的程度上减轻我们管理网络共享资源的复杂性, 也为不同课程在多个节点中达到“融合、共享、互动、便利”的目标提供了坚实基础。

参考文献

[1]王淑江, 李文俊, 石长征.精通Windows Server 2008网络服务器[M].北京:中国铁道出版社, 2009.

[2]设计分布式文件系统[EB/OL].http://technet.microsoft.com/zh-cn/library/cc772778 (WS.10) .aspx.

[3]Windows Server 2008中的分布式文件系统的循序渐进指南[EB/OL].http://technet.microsoft.com/zh-cn/library/cc732863 (WS.10) .aspx.

[4]张蕊.数字图书馆实施分层存储管理初探[J].现代情报, 2007 (1) .

[5]吕会红, 李心广.基于四层架构的网络教学平台的研究与实现[J].中国教育技术装备, 2011 (3) .

分布式系统中网络负载平衡的研究 篇4

关键词:分布式系统;网络负载平衡;动态负载平衡

中图分类号:TP393 文献标识码:A文章编号:1007-9599 (2010) 06-0000-02

Research of Network Load Balancing in Distributed Systems

Pei Gang,Zeng Weidong,Deng Hairong,Su Baoxian

(95876 Troops,Shandan734100,China)

Abstract:Distributed systems can effectively reduce processing bottlenecks,which has strong fault tolerance has been quite extensive research and application.This paper introduces the definition of distributed systems and load balancing technology,which focused on the dynamic load balancing strategy.Finally,according to the characteristics of distributed applications,proposed a distributed system network load balancing solution,and gives the algorithm description and models.

Keywords:Distributed system;Network Load Balancing;Dynamic Load Balancing

网络负载平衡主要目的是降低任务平均响应时间,提高系统资源利用率。分布式系统的任务能够迅速和有效地运行,除了依赖于系统规模、各节点的运算能力和并行算法外,还包括对负载平衡的调度和管理。负载平衡是影响系统并行效果的一个非常关键的因素,因此,负载平衡问题对分布式系统的研究与发展具有十分重要的现实意义。

一、分布式系统

分布式系统在不同的文献给出的定义也不同,本文只选用其中的一种定义说法,其定义如下:一个分布式系统是一个对用户看起来像普通系统,然而运行在一系列自治处理单元(PE)上的系统,每个PE有各自的物理存储器空间并且信息传输延迟不能忽略不计。在这些PE间有紧密的合作。系统必须支持任意数量的进程和PE的动态扩展。

分布式系统要求的属性主要有以下几点:

1.任意数目的进程。每个进程也被称作一个逻辑资源。

2.任意数目的PE。每个PE也被称作一个物理资源。

3.通过消息传递的通信。这提供了比主/从方式更合适的合作式消息传递方式。

4.合作式进程。进程间以一种合作的方式交互,或者说多个进程用于解决一个共同的应用而不是几个独立的应用。

5.通信延迟。两个PE间的通信延迟不可忽略。

6.资源故障独立。没有任何单个逻辑或物理的资源故障会导致整个系统的瘫痪。

7.故障化解。系统必须提供在资源故障的情况下重新配置系统拓扑和资源分配的手段。

本文所讨论的分布式系统便是基于以上描述的。

二、负载平衡

(一)负载平衡产生原因及定义

分布式系统由于其任务到达的随机性,以及各处理结点处理能力上的差异,当系统运行一段时间后,某些结点分配的任务还很多造成超载,而另一些结点却是空闲的造成空载。如何避免这种空闲与忙等待并存的情况,从而有效地提高系统的资源利用率,减少任务的平均响应时间,这成为了负载平衡产生的原因。

负载平衡就是设法对己经提交给各结点的任务进行重新调度分配,并通过任务迁移,使各结点负载大致平衡,从而提高系统的资源利用率,减少任务的平均响应时间,达到提高分布式系统整体性能的目的。

负载平衡是一种负载分配技术,它试图平衡系统内所有结点上的负载,以使得系统内各个结点上的负载基本相等,但这种相等不是简单的任务数目相等,而是根据这些结点自身的性能综合得出的负载权值相等,因此需要根据系统内结点的负载变化进行任务的动态迁移。

(二)负载平衡的分类

负载平衡可以分为静态负载平衡和动态负载平衡两大类。

静态负载平衡就是根据过去的经验或系统本身信息收集,把外来的任务分配给各个结点,或对某些结点上的任务进行重新分配。静态负载平衡方法优点是实现简单,在一定的应用范围里具有优势,但其效率取决于对系统本身以及交互的任务是否有了解充分,如任务的执行代价和任务之间的通讯代价,处理机的性能以及硬件配置等。因为这些经验往往是不可能事先获取或不准确的,所以动态负载平衡是最常用的方法。

动态负载平衡主要用于任务不确定的情况,其决策取决于系统当前的状态,也就是说,系统可以根据当前的负载分布情况,对各个节点上的负载进行动态的调整,使超载结点上所分配的任务,通过通讯设备,迁移到轻载的结点上去,使之提高系统资源利用率,达到减少任务的平均响应时间的目的。相对于静态负载平衡,它具有更大的针对性和灵活性,可根据系统当前的负载状态有目的地进行负载平衡。

(三)动态负载平衡策略

动态负载平衡策略的就是决定超载结点如何去寻找一个空闲结点,然后将自己的新任务请求转发给空闲结点。目前常见的几种平衡策略主要有以下几个:

1.最快响应法。这样的定位策略是当一个节点超载时向系统内发布一条超载消息给所有节点,系统内的其他节点接收后立即对自己的负载状态进行查看,如果空闲就发出接受响应,平衡器记录结点本身到系统中各个结点所需的网络响应时间,将新任务分配给响应时间最短的结点。

2.最少连接法。最少连接法的平衡器记录当前所有结点的活跃连接,把新的任务请求发给当前连接数最少的结点。最少连接法是针对TCP连接的,由于不同任务对系统资源的消耗及利用差异会比较大,连接数量无法真实的反映应用负载情况,也就是说这种方法没有考虑到任务请求强度和服务器的性能。

3.最低缺失法。最低缺失法中的负载平衡器长期记录到各结点的请求情况,在进行平衡负载时,负载平衡器把新的任务请求发给记录里处理请求最少的结点。和最少连接法不同的地方是,最低缺失法记录的是过去的连接数,而不是当前的连接数,所以无法真实反映结点实时负载状况。

4.随机法。随机法给系统中各结点赋予一个由伪随机算法产生的值,具有最小或最大随机数的结点最有优先权。随机法实际上相当于无偏见的给各结点产生权值,每个结点都有可能获得最大的优先级。这也是一种机会均等的调度算法。这种算法和轮转法一样,需要在相同的结点环境中才能运行得最好。

三、负载平衡优化策略及模型设计

(一)负载平衡优化策略

负载平衡优化策略的目的是为了解决在任务迁移过程中所引起的抖动问题。抖动问题是指系统的某个结点超载时,需要定位查找一个空闲结点并转移自己的超载部分任务,查找定位结点不当就会产生抖动问题,超载的任务在转移到新结点后,发现新结点的负载能力有限而不得不将任务再次转移,多次反复转移增加了任务的执行时间,降低了系统的整体执行效率。

优化策略方法中引入了管理站结点,由管理站结点收集系统中各个结点的负载情况,并根据接收结点实时负载值,生成接收结点负载线性表,根据负载能力将接收结点进行排序,当结点超载时,由忙结点来顺序查找接收结点负载线性表,查找到第一个与自己直连的结点,然后转移超载部分任务。这样的策略方法保证了忙结点查找到的空闲结点最佳空闲结点,是当前接收结点中负载能力最强的结点,避免了转移到的新结点因为执行能力有限而再次转移任务引起的抖动现象。

(二)负载平衡策略算法实现

负载平衡策略重点是在启动策略、定位策略以及信息策略方面做以改进。负载平衡策略的目标是对系统中各结点负载能力进行更加有效地评估、及时准确的评价系统负载以及快速查找定位空闲结点以转移新任务,避免任务迁移过程中有抖动问题出现,从而减少任务平均响应时间,提高分布式系统整体执行效率。

负载平衡调度算法描述如下:

1.系统管理站周期性地启动运行动态负载值采集计算程序,根据收集到的各个结点自身的各项负载参数,计算出系统中结点的动态负载值 及实时负载值 。

则结点 转变为发送者,在管理站的结点负载信息表(LIT)中备份记录,同时由管理站将结果返回给系统中各个结点的结点负载状况表(LST)。

ELSE

则结点 转变为接收者,在管理站的结点负载信息表(LIT)由备份记录,同时由管理站将结果返回给系统中各个结点的结点负载状况表(LST)。

Endif

Endif

2.管理站根据计算后的结点的实时负载值 降序排列结点编号,生成接收结点负载线性表,并且保证管理站所保存的接收结点负载线性表永远是最新的。

3.对系统中任意一个结点 ,新任务请求到达时,

DO

查询自身结点负载状况表(LST)

If结点为接收结点

则接收任务请求

EISe

结点为发送结点,顺序查找管理站中的接收结点负载线性表

If

找到一个与自己直接相连的结点 ,将任务请求转移给结点

EISE

等待

Endif

Endif

Enddo

4.继续转1重复操作。

对系统中每一个结点,有任务到达时读取该结点自身保存的结点负载状况表(LST),如果结点为发送者结点,则由定位查询模块寻找可以接收任务的空闲结点,之后结点任务迁移模块将新到达的任务迁移到负载较轻的结点,直到所有结点都不超载,从而达到负载平衡的效果。

(三)负载平衡系统的模型设计

负载平衡系统的主要由普通结点和管理站结点组成。普通结点包含了任务迁移模块、定位查询模块、通信模块和负载信息存储模块。管理站结点中有通信模块、结点负载信息收集计算模块和接收结点负载线性表生成模块。管理站结点是系统中性能相对较高的结点它不接收执行任务,只负责定期收集并计算系统中各个结点的负载信息,根据收集来的负载信息、将接收结点的信息提取出来,并根据接收结点的实时负载值来构造接收结点负载线性表。

负载平衡系统模型如下图1所示:

图1负载平衡系统模型

结点负载信启、收集计算模块:负责周期性的收集各结点负载信息并计算各小结点的动态负载值和实时负载值。

定位查询模块:结点超载时,由定位查询模块通过通信模块与管理站通信,并顺序查找接收结点负载线性表,寻找可以转移自身任务的空闲结点。

任务迁移模块:在定位查询模块定位到可以转移任务的空闲结点后,负责任务转移工作。

负载信启、存储模块:存储结点自身负载信息。

接收结点负载线性表生成模块:管理站根据系统甲接收结点的实时负载值构造接收结点负载线性表,以供超载结点查询访问。

四、结论

网络负载平衡是分布式系统性能优化的关键,负载平衡的好坏直接影响到整个分布式系统的运行效率。本文在动态负载平衡策略的基础上,提出了一种分布式系统负载平衡优化策略,并给出了其算法描述和模型。本文所提出优化策略的是一种较为理想、相对完善的分布式系统网络负载平衡解决方案,具有一定的理论和现实意义。

参考文献:

[1]王友良,叶柏龙.分布式系统甲动态负载平衡的研究.科学技术与工程,2005,9

[2]张宇晴,佟振声,胡旦华.分布式系统中动态负载平衡算法的研究.计算机仿真,2003:20(9)

[3]陈志刚,曾志文.中间应用服务器动态负载均衡的物理模型,计算机工程,2001:1(1)

作者简介:

分布式无线网络平台 篇5

1 基于分布对象的虚拟网络平台概述

工作站向服务器的数据库发出一个查询或统计请求后, 并不是服务器将数据处理后把结果反馈到工作站, 而是把服务器中的数据通过服务器的网卡发出, 经过网络电缆传递由工作站和网卡接收, 由工作站自己处理数据得出结果, 因此网卡发送接收的能力和工作站处理数据的能力是对这一请求响应快慢的关键。

设计好适用于具体的网络管理网络结构规划系统, 可大大减少网络运行故障和网络管理人员的劳动强度及操作成本。好的网络管理系统给网络管理员提供的网络拓扑结构的是很清晰的, 过渡态数据网络的操作是非常简单的图形界面, 网络问题也可以及时反馈。本系统在NetBeans开发环境下, 使用JAVA1.6、PHP、JavaScript语言, 结合Apache2、Mysql数据库开发完成。本系统的全部开发组件如表1所示:

2 基于分布对象的虚拟网络平台数据采集

相应的处理程序可以方便地使用已有的网络连接, 通过调用其中提供的方法, 得到需要的网络数据, 并将它们交给其他部分做进一步的处理。其中, 网络管理数据由各种处理程序调用上层协议驱动, 通过SNMP, 从网络设备上取得各种性能数据。

随着语义Web的发展, 越来越多的数据提供者和互联网应用开发商将现有的数据转换成链接的数据, 使得LOD图像得到快速的发展。2011年9月展示LOD数据云发表, 它由295组数据构成, 其中包括约310亿和5.04亿的RDF链接语句。它显示了LOD数据链路之间的联系及各种项目的相关数据的数据集。其中, 某些数据集间连接作为一个数据网络的枢纽, 如DBpedia数据集等。此外, 还包含了很多著名的数据集, 如维基百科, GeoNames, 英国BBC广播公司, FOAF, SKOS, WordNet, DBLP书目等, 涉及政府、企业、学校和图书馆等其他领域。通过链接开放数据项目的详细信息, 用户可以从其他相关数据的一组数据采集环节了解到丰富数据关联, 充分发现和享用外部资源。

3 基于分布对象的虚拟网络平台的设计

以产生一个商业模式为例了解其对企业的要求和用户视图定义视图的概念的应用。概念建模技术 (例如使用案例分析、活动图、工艺设计和业务实体建模) 有助于建设关键业务和数据的描述, 可以加强业务目标和需求, 但是不包含实现技术。

逻辑视图:逻辑视图结构设计中的应用模型是建立一个商业模式, 它们决定了如何满足业务的目标和要求。模型的应用程序结构也体现在逻辑视图和建筑师的总体结构方面的应用。他们决定关系数据管理和处理步骤之间的相互作用, 根据逻辑和时序模型组件的设计确定了模型保留的数据类型和状态。

物理视图:每个元素映射应用模式的技术元素的实际要求。通过这种方法实现模型的应用。程序员将详细的业务逻辑编写为代码, 在传统开发过程中承担了部分任务, 但大多数的活动应在一个复杂的框架内来完成。框架是一种新的开发技术, 分布式应用程序和数据管理的基础设施包括帧应用逻辑框架的风格和控件结构的设计。框架完成使开发人员避免了繁琐的工作 (例如, 错综复杂的异步消息处理) , 使普通开发人员能够对项目作出更大的贡献。

能否正确定义这些模型对于组织来说也是至关重要的。结构模型的设计错误总是会导致严重的设计问题或运作问题 (例如伸缩性和可靠性问题) , 严重时甚至会导致项目无法完成以及影响业务。结构设计师正在寻找框架和指南以帮助他们创建和实现这些模型, 并把由于使用错误模型而带来的风险降到最低。

结构设计师可以使用两种结构指南和帮助来加快建模速度和降低风险。

4 基于分布对象的虚拟网络平台的实现

在用户登录上使用双重身份验证登录功能系统。用户身份认证除了使用用户的用户名和密码, 还需要使用令牌生成的同步码。同步代码生成与服务器同步一致。用户登录时需要在一定的时间内输入的代码, 所以即使用户的密码丢失也不会导致系统被攻击, 提高了系统的安全性。

网络设备日志分析方面, 主要研究通过SYSLOG服务, 将接入层交换机的日志信息捕获, 以便于对接入交换机的运行状况进行动态分析。通过分析对接入层的三大攻击行为进行定位, 为下一步操作做铺垫。日志信息同步数据量极大, 但对细节数据的准确性要求不高, 主要以大量数据宏观分析得出结果。所以, 日志信息同步功能的可靠性要比数据准确性更加重要。它要能够持续的接收分析大量数据。

接入网设备的控制功能和网络接入层设备是一个窗口交互系统, 其他业务则需要通过其主机来完成, 因此控制接入层设备需要有较强的操作能力。这种能力是通过TELNET和SNMP协议来实现的。

本文着重研究了TELNET与SNMP的开发接口以及对设备控制功能的实现。总而言之, 系统对日志分析功能得出的结果, 最后进行隔离操作是通过本功能直接完成的。日志记录和存储里, 用户的目标操作系统作为记录的目标函数在实际使用过程中主要用于事后处理和分析日志数据的存储功能, 在数据库中隔离的操作记录和其它数据存储, 因为该系统是一个大的数据库, 没有单独使用复杂的数据持久层组件, 可以实现数据库连接池功能, 重量轻且操作简单。

日志分析功能包含了SYSLOG套接字的创建, 数据读取分析两大主要功能。其中SYSLOG套接字的创建主要目的是为了接收交换机发至UDP514端口的日志信息。数据分析的主要目的有两个, 一是判断当前网络运行是否正常, 二是如果不正常, 需要确定攻击源的信息[15]。SYSLOG套接字用于将接入交换机发来的日志信息进行读取, 然后交与日志处理逻辑对日志进行分割。日志处理逻辑使用正则表达式对日志分割完成后, 数据分两部分流向, 日志信息本身交由数据库存储逻辑处理, 另一向交由攻击主机判定逻辑分析攻击主机信息。对于设备控制模块交互逻辑, 当自动隔离攻击主机

5 结论

基于分布对象的虚拟网络平台提供系统级端到端的解决方案, 这将是智能化的网络管理和工作负载分布到多个站点, 分布式网络管理信息系统的管理员可以促进用户更高效地利用系统中的资源, 网络的发展提供了可扩展性的变化。为了减少复杂性和中心网站计算的负负, 可以提供一种独立方法靠近故障点, 快速地排除故障。

基于分布对象的虚拟网络平台通过在整个网络上向多个控制台将数据采集, 监视以及管理职责分散开来而实现综合分析。

参考文献

[1]熊钰岚, 刘希民.虚拟网络实验平台设计[J].电脑知识与技术, 2010, 12 (25) :107-108.

[2]曹丽苹.基于C8051F310和CS8900A的计算机网络实验平台设计[J].电子元器件应用, 2010, 10 (02) :98-100.

分布式工业数据实时分析计算平台 篇6

中国制造业历经多年的信息化建设,国内的工业企业在各类信息系统中存储了大量数据,这些系统包括OA、HR、CRM、MES等。这些系统帮助企业优化资源配置、减化业务流程,极大地提升了企业的经营管理水平。伴随着数据的快速增长及新需求的不断涌现,原有系统越来越难以满足要求,如何将分散在各个系统中的数据整合起来,充分发挥数据对生产的指导作用,提升效率,优化生产流程,优化经营效率,己成为中国制造业的新挑战。

随着大数据技术在互联网行业中蓬勃发展,涌现了大量大数据处理框架,如Hadoop、Spark、Storm等,如何选择并整合各大数据处理框架,在其上开发、运行、维护处理海量数据的应用程序,成为制造业企业IT部门新的挑战和难题。分布式实时分析计算平台就是为了解决这一问题,帮助企业技术人员可以轻松架构,搭建适用于自身业务形态的分布式实时计算应用。

2 关键技术

本文提到的分布式实时计算平台,选择了多个优秀的开源构件作为平台的基础构件。整个技术平台自下而上主要包括:分布式文件系统层、分布式数据库、分布式数据分析、数据展示等基础功能模块。针对各个基础功能模块的功能要求及特点,筛选优秀开源构件,主要选择了以下开源构件。

2.1 Hadoop

Hadoop实现了一个分布式文件系统,为海量数据提供分布式存储。在此之上,Hadoop提供了Map Reduce分布式计算框架。该框架通过Map和Reduce两个步骤并行处理大规模的数据集。首先,Map会对由很多独立元素组成的逻辑列表中的每个元素执行指定的操作,原始表不会被更改,其会创建多个新的列表来保存Map的处理结果,这也意味着Map过程会产生大量的新数据,有大量的写磁盘操作。Map工作完成之后,会对新生成的多个列表进行shuffle和排序,之后完成Reduce操作。Map Reduce框架的最大不足在于,对于需多次迭代的复杂计算,会产生大量的中间结果,需频繁读写HDFS,无法满足实时应用的需求。

2.2 Hbase

Hbase是运行在Hadoop上的分布式、面向列的No Sql数据库,它是一个分布式可扩展的大数据仓库。它提供高可靠、高性能、列存储、可伸缩、实时读写的数据库系统,主要用来存储非结构化和半结构化的松散数据。它很好地融合了key/value存储模式带来的实时查询能力,以及通过Map Reduce进行离线处理或批处理能力。

2.3 Spark

Spark是开源的类Hadoop Map Reduce的通用并行框架,拥有Hadoop Map Reduce所具有的优点,但与Map Reduce不同的是,Job中间输出结果可以保存在内存中,从而不再需要读写HDFS,因此Spark能更好地适用于需要多次迭代Map Reduce的算法。相比Map Reduce,Spark在做重复计算时可以重复使用相关的缓存数据,无需不断地读写磁盘。

2.4 ANTLR

ANTLR是一款强大的语言识别工具,提供框架通过语法描述来构造语言识别器、编绎器和解释器。通过解析用户自定义的上下文无关描述语言,自动生成词法分析器、语法分析器和树分析器。

3 分布式工业数据实时分析计算平台

3.1 基本架构

本文中的分布式工业数据实时分析计算平台底层基于Hadoop、Hbase、Spark等构件。Hadoop为平台提供了分布式存储HDFS,在此之上是Hbase分布式No Sql数据库,由它组织和管理用户数据表。选用分布式实时计算框架Spark作为计算平台的基础计算框架。由yarn负责整个平台的系统资源调配。

计算平台主要包括Job Server、FCS(Function Compulation Service)、RESTful API等模块。Job Server负责与yarn协调申请资源,为特定应用启动单独的计算服务,管理各计算服务的计算任务。Job Server对外提供RESTful接口。FCS提供UI,供用户编排计算任务,并根据用户计划执行计算任务。平台架构如图1所示。

3.2 Job Server

Job Server主要由Context Manager、Job Manager、RDD Manager等子功能模块组成,对外提供RESTful API,用户可通过浏览器查看Job信息,如图2所示。

●Context Manager:为客户端应用管理应用上下文,每个应用可根据需求启动一个或多个Application Context,不同的Application Context均是独立的yarn应用,相互之间资源隔离。Application Context可分为长驻Context和一次执行Context。

●Job Manager:管理Application Context中的所有Job,包括创建Job、执行Job、保存Job处理结果,异步Job模式中,客户端可根据Job ID获取处理结果。

●RDD Manager:负责管理计算中生成的Spark RDD、客户端申请的有名RDD以及RDD缓存,方便客户端在Job之间共享RDD,以提升计算效率。

3.3 表达式计算引擎

分布式分析计算平台针对工业数据,抽取定义实现了适合工业计算的表达式计算引擎,主要有行计算和列计算两种模式。行计算对Hbase表中的记录行中各属性值执行表达式计算;列计算是纵向的,对表中某一列执行统计计算。两者间可嵌套执行。

海量数据计算中,同一表达式可能执行数以亿计的计算,如图3中所示,Expression parser(表达式解析器)对表达式进行词法以分析,并解析表达式,Expression compiler(表达式编绎器)将解析后的表达式编绎为可以直接执行的算子,RDD执行并行计算时,对每行数据提取算子中所需的列值,传输给表达式算子,多个算子运行结束后,由Result collector(计算结果收集器)收集、合并运算结果。RDD计算过程中无需重新解析表达式,极大地节约了计算时间,提升了计算效率。

3.4 FCS

FCS提供Web UI供客户端编排计算任务,可指定计算任务的执行模式,周期执行或符合条件的特定时间执行。可自定义计算表达式,并通过FCS提交计算任务至Job Server。

3.5 分布式工业数据实时分析计算平台与传统实时数据库对比

分布式工业数据实时分析计算平台与传统实时数据库对比如表1所示。由于传统实时数据库一般单机或多机冗余热备使用,对服务器的硬件要求高,且服务器数量有限,因此,存储容量最大为TB级。与之相比,分布式工业数据实时分析计算平台底层基于Hadoop,普通的服务器即可,群集支持数以千计的服务器,支持超大数据集,能存储PB级的数据,且在群集中维护多个工作数据副本,确保能够针对失败节点重新分布处理。从性能角度看,传统实时数据库由于架构简单,数据多缓存于共享内存,速度明显快于分布式工业数据实时分析计算平台,读写性能可达到十毫秒级。分布式工业数据实时分析计算平台因数据分布存取,存储最快可达到百毫秒级。可扩展性方面,分布式工业数据实时分析计算平台明显优于传统实时数据库,在可用的计算机集簇间分配数据并完成计算任务,可以方便地扩展到数以千计的节点中。而传统实时数据库可添加新节点,但节点数目到达一定规模后,对性能无提升。

4 结语

分布式工业数据实时分析计算平台为企业IT技术人员提供了一个支持分布式实时计算的开发平台,使得企业IT技术人员无需关心计算平台的底层架构,无需编写代码,仅通过FCS编排计算任务,即可快速完成业务计算的编写,进而对海量数据进行业务分析和处理。

参考文献

[1]朱江.基于云计算的数据挖掘平台架构及其关键技术研究[J].计算机光盘软件与应用,2015(19):53-56.

[2]梁九妹,卢忠田.一种基于云计算技术的实时业务服务模型[J].计算机与现代化,2013(07):160-163.

[3]王水萍,王方.一种基于云计算数据挖掘平台架构的设计与实现[J].信息安全与技术,2014(08):64-66.

分布式无线网络平台 篇7

随着有线数字电视整体转换工作的完成及应对三网融合提出的要求, 为提高用户粘合度和应对电信IPTV的竞争, 各地有线电视网络公司陆续开展了互动视频点播业务。

互动点播 (Video on Demand, 简称VOD) 和传统的广播式电视不同, 可以根据用户自己的意愿收看, 它打破了传统广播电视在时间、内容方面的限制, 可以在任何时间点播自己喜欢的节目, 收看过程中还可以进行快进、快退等各种操作, 提供用户完全不同于传统电视的收视体验, 其业务形态随着技术的发展和市场的需求还在逐步增加。

2 系统现状

互动点播可以划分为基于IPQAM/HFC技术和基于IPTV/LAN技术两种方式, 目前广电一般采用IPQAM/HFC方式, 而电信一般采用IPTV/LAN方式。在本文中互动点播 (VOD) 采用IPQAM/HFC方式。

基于IPQAM/HFC技术的VOD系统是建立在HFC网络架构上的根据DVB-C规范建设的系统, 是HFC网络交互电视经典的解决方案。IPQAM集“复用、加扰、调制、变频”功能于一体, 它将DVB/IP＿GBE输入的节目流重新复用在指定的MPTS中, 再进行QAM调制和频率变换, 输出RF信号。在使用IPQAM之后, STB和边缘视频服务器之间的控制信息和视频流分别通过不同的通路传输:STB的接入认证、EPG信息浏览等流程通过双向回传通道交互;边缘视频服务器收到用户的请求后将音视频流以恰当的封包形式输出至IPQAM设备, IPQAM将音视频流调制为RF信号后通过HFC网络传输给STB, STB对音视频流进行解调和解码。

在初期用户较少时, 系统采用集中模式, 将相关设备全部放置在中心机房, 与数字电视广播信号在总前端进行混频, HFC网络承载点播的视频流, 通过IPQAM调制后进行传输, 而IP城域网承载点播信令等控制信号。当点播用户规模逐步扩大后, 可以将IPQAM下移到分前端机房, VOD系统的视频流通过DWDM波分系统传送到分前端的IPQAM进行调制, 再与广播信号混合传输。随着点播用户的不断增加, 视频服务器集中于前端机房已经不能完全满足业务发展的需要, 此时采用CDN内容分发网方式, 在区域分中心机房部署边缘视频服务器, 所有的节目都在中心服务器存储, 而通过CDN网络把用户访问相对集中的内容分发到边缘服务器, 直接由边缘路由器提供用户服务。

采用IPQAM技术后, 一方面可以充分利用HFC的带宽资源以及传输特性, 向用户提供有QoS保障的视频服务, 更适合高清业务对传输网络的高下行带宽要求;另一方面降低了视频服务对IP网络的要求, 不再要求IP网络接入层提供较高的带宽, 使广电运营商可以以较低的成本实现交互视频业务。

利用IPQAM开展视频点播业务, 在美国的各大有线运营商中得到了大规模的应用, 随着国内有线网络双向业务的加快, 国内有线电视运营商也开始大量使用这种方式开展VOD业务, 比如:江苏有线按照“统一平台、统一内容”的运营模式, 建设了全省统一的互动电视点播系统, 覆盖全省的互动电视用户;后台管理系统在省中心平台, 包含视频流控制、计费信息管理、报表模块、数据库、网络管理及监控等功能;采用CDN内容分发网方式, 在苏州部署了视频服务器、页面服务器和IPQAM等设备, 热片通过苏州本地视频服务器直接播出, 冷片通过省中心的视频服务器播放。系统结构图如图1所示。

随着互动点播业务在各地的大力推广以及互动电视用户量的快速增长, 本地特色内容的业务需求不断增加, 为广大本地用户提供更加贴近本地生活的互动电视内容成为目前的重要任务。而目前互动点播系统分布式平台对本地并发流增加的支持性较好, 但是本地不能注入内容。下面以此为基础讨论几种本地内容注入的方式。

3 本地注入的几种方式

3.1 通过省中心注入本地内容

目前全省互动电视平台采用混合式部署, 用集中+分布相结合的方式实现全省内容的注入和分发, 对点播类内容的注入和分发统一在省中心进行。在省中心建立统一的点播类内容分发平台, 通过媒资系统和互动电视系统之间的标准接口, 从全省统一的内容集成平台把各类互动电视节目内容和信息集中注入互动电视平台核心存储上;然后再由核心存储根据节目的热播程度将最热播的节目内容分发到省中心以及各地分中心的视频服务器存储阵列中;各地的少量本地新闻节目由各地采集制作成媒资文件后, 通过省干线传输网以FTP或者其他方式上传到内容集成平台, 通过编目、审核后统一注入到互动电视平台。

各市县继续采用这种模式, 将需要新增加的电影、电视剧及本地戏曲等内容在本地制作、编辑后, 按照现有方式上传到内容集成平台, 由内容集成平台进行统一编目审核后统一注入, 但如果各市县都需要上传较多的节目内容量, 则内容集成平台的工作量将大大增加。

这种方式与现状完全保持一致, 系统不需要进行任何改造, 投资几乎没有, 但是需要省中心与各市县操作人员配合才能实现内容的及时发布, 各市县的自主性不够, 无法实现本地管理等功能。

3.2 建设多级分布式系统

该方案在省互动平台的现有基础上, 建设本地二级后台管理系统, 在充分利用目前互动平台的基础上, 实现本地节目的注入、本地页面的修改、本地节目的独立定价和系统的本地化管理等功能。

3.2.1 系统结构

该方式在现有互动平台基础上, 建设本地二级后台管理系统, 下移部分系统运行及管理权限, 包含页面管理、内容分发、资源调度、运行管理等功能模块。

3.2.2 系统集成

系统与目前省平台的互连如图2所示。

该方案需要在保持现有本地互动电视分布式平台正常运营的情况下, 完成新增二级后台管理系统与现省互动平台的对接, 省中心平台相应的功能模块也需要进行改造, 页面管理、内容分发、资源调度、运行管理等功能模块需要进行分级管理。相应的技术要点如下:

(1) 资源调度

本地IPQAM等资源通过本地SRM进行调度, 省中心SRM通过本地SRM对本地资源进行统一管理, 由原来一级管理调度改为二级。

(2) 内容分发

在完成本地的资产注入以后, 省网后台系统通知本地二级系统资产元数据进行发布, 本地的操作员做上片的申请操作, 根据预设的上片审核策略, 由审核人员在系统中完成本次上片的审核工作, 审核完成后, 本地二级系统自动向本地新建Portal系统进行节目的发布操作。

(3) 页面管理

需在同一页面服务器上对用户同时提供省中心提供的内容和本地注入的内容。本地新建Portal系统作为本地提供互动视频点播业务的展现, 通过与省中心平台Portal系统的对接来实现省中心平台Portal到本地新增Portal的链接跳转, 在不改变业务流程和用户体验的前提下, 保证了本地业务的顺利开展。

(4) 运行管理

需要实现省中心和本地同时对系统进行管理和维护。

这种方式在本地新增二级后台管理系统, 与现省互动平台进行对接, 可以本地管理等功能, 但是省中心平台相应的功能模块也需要进行改造, 对现有结构改动较大, 系统集成有一定工作量。

3.3 新建一套小型本地点播系统, 仅支持本地节目的用户点播

该方案新增一套小型的本地点播系统, 仅提供本地注入节目的点播和管理。系统结构与前一种方式一致, 只是规模较小, 同样需要增加视频服务器、本地存储、后台管理等系统设备 (并发流数量和存储容量规模较小) , 在充分利用目前互动平台的基础上, 实现本地付费节目的内容页面的注入和修改, 并与BOSS系统连通实现本地的认证计费, 通过本地BOSS系统与省BOSS系统连接, 实现数据报表的共享。

3.3.1 系统结构

新建系统是一个完整的点播系统, 仅提供本地注入节目的点播和管理, 系统支持的用户规模量比较小, 但是也是一个完整的点播系统, 也包含视频服务器、后台管理、互动应用、页面服务等完整的业务功能模块。

3.3.2 系统集成

系统组成及与目前省平台的互连如图3所示。

该方案需要在保持现有互动点播系统正常运营的情况下, 完成新增点播系统与现互动点播系统的对接, 新增点播系统需要和现互动点播系统共同向本地用户提供互动点播服务, 需要在两套系统之间完成页面切换、视频流切换、认证切换等, 并与本地BOSS的对接。相应的技术要点如下:

(1) Portal切换

在本地新增加Portal, 需要机顶盒在新增Portal和现有系统Portal直接自由切换。

(2) SRM切换

在本地新增加SRM系统, 这就需要机顶盒在点播本地节目和省平台节目时切换不同的SRM系统。

(3) 认证切换

将本地栏目的节目点播和定价计划由本地BOSS系统做定价策略, 省平台节目的认证和计费保持现状不变。

(4) 与BOSS对接

新增系统计费接口需要和本地BOSS进行集成, 直接访问本地AAA接口。

3.3.3 用户点播流程

(1) 用户点播某节目

用户机顶盒通过本地IP城域网访问现有互动页面, 可以通过连接切换到本地内容页面, 选择确认点播某节目。

(2) 用户认证

后台管理系统在收到用户点播请求后, 请求认证计费系统进行认证, 其中本地节目的认证由本地处理。

(3) 视频播出

用户认证通过后, 后台管理系统定位节目存储所在地。若在现有平台, 则通知现有视频服务器直接播出相应节目。若在本地新建系统, 则由本地视频服务器播出节目。

(4) 点播计费

视频播出且流控建立后, 通知计费系统对用户此次点播行为进行计费。

3.3.4 SRM对接

因为HFC网络的共享特性, 某个特定的机顶盒只能接收到来自特定的一组IPQAM端口的数据, 因此需要对服务区域有明确的规划和管理, 一般将这样的服务区域定义为Region, Region即预先定义的一组频率资源, 或者为一个IPQAM通道资源规划单元。资源管理模块 (SRM) 需要了解每个实际部署的IPQAM的资源使用情况以完成资源的分配和回收, 要求IPQAM设备提供接口供SRM完成心跳维护和状态查询, IPQAM的UDP端口和频点、节目号的映射规则应该全网统一设置, 以完成对所有资源按照统一的算法调度。

由于两套独立的互动点播系统需要共用同一组IPQAM资源, 所以本方式中SRM切换最为复杂, 可以以原有系统为主管理SRM, 向新建SRM开放接口, 两者协同进行工作, 这需要原系统开放核心接口并完成技术开发。在SRM切换没有实现前, 可以另外单独部署一套IPQAM系统, 需要另外占用频点资源, 两套系统都按最大并发流规模使用资源, 不能实现两套IPQAM、频点、骨干带宽等资源的共享, 会浪费一部分资源。

这种方式新建系统为一套小型的完整系统, 但是规模不大, 投资较小, 仅支持本地注入内容的点播并发流, 而互动点播系统规模复杂性与并发流数量并不是完全的线形关系, 并发流不大时比前一种方式大大节省投资, 可以在本地实现所有功能。但是需要进行共享IPQAM等资源, 集成比较复杂。

4 结语

分布式无线网络平台 篇8

本文的安全管理平台是基于信息安全的角度, 充分考虑到业务支撑系统不同主机、网络设备、应用、数据库等信息安全资产, 对网内的信息安全资产进行分级, 并实现对不同安全级别信息资产的安全告警监控。平台建成后, 可实现对业务支撑系统的设备安全监控、安全预警、以及整体系统安全状况评估, 极大地提升了业务支撑系统的安全性。

1 总体设计

1.1 系统的设计目标

整个系统采用J2EE的架构完成网络安全管理平台的研制和开发工作, 核心子系统采用UML进行建模, 实现模块化设计思想, 各个逻辑功能模块均能动态加载和独立运行, 满足未来扩展的需求。网络安全管理平台用于管理来自多种网络安全设备的安全事件, 基本的原理是对从网络安全设备上采集来的原始网络安全事件进行分类、关联、风险评估等分析处理, 通过该平台对运行在各种操作系统和硬件平台上的网络安全产品实施统一的配置、统一的策略、统一的日志和统一的报告, 以便用户进行相关的响应处理, 过程如图1所示:

1.2 系统的设计原则

系统采用目前业界流行的B/S结构, 分为客户层、控制层、业务处理层、数据访问层四层。系统主要基于Struts框架, 结合J2EE设计, 采用Oracle数据库存储数据。系统从可扩展性、高性能、系统的松耦合性、安全性等角度进行了充分的考虑。遵循的主要原则包括:系统采用面向对象设计思想, 系统遵循J2EE 2.0标准系统, 遵循SUN Java编程规范。

1.3 系统的部署方案

为了满足本项目的需求, 在业务支撑系统湖东机房局域网部署SOC管理平台, 其中包含HA工作模式的台SOC应用服务器与2台SOC数据库服务器、1台WEB服务器与1套2TB带库系统, 三台安全信息收集分析服务器, 分别部署在湖东、金山与乌山三地机房中, SOC应用服务器通过网络方式从三地安全信息收集分析服务器中获取数据。同时异常流量分析采集服务器部署在湖东, 通过NETFLOW与SNMP方式进行全网网络设备的智能关联分析, 将分析之后的数据统计提交到SOC应用服务器进行集中处理, 同时保存到SOC数据库服务器中。整体部署如图2所示。

2 网络架构设计

参照上述的部署方案, 我们可以看到架构设计从总体上可分为数据采集层、应用服务层、应用展现层 (终端显示) 3个逻辑层次, 如图3所示。

(1) 数据采集层:

根据要求采集各种安全信息。负责从已经汇总了福建移动业务支撑系统网络上的安全信息的网管和服务器上收集汇总后的安全信息。

(2) 数据处理层/应用服务层:

负责对采集到的原始数据进行聚并处理, 完成数据的智能关联分析, 为应用展示层提供数据支持。

(3) 应用展现层:

实现安全运维管理平台的统一界面展示。通过统一的图形化管理界面, 安全运维管理平台实现了安全监控、维护、管理、展示的全部功能。

2.1 数据采集层

数据采集层负责根据要求采集各种安全信息。针对福建移动业务支撑系统网络, 从福建移动业务支撑系统各个局域网上的网络设备、安全设备、服务器系统和主机系统收集汇总安全信息。

数据采集是整个安全管理的核心, 数据采集的关键是:首先要支持丰富的采集对象, 保证即插即用;其次是采用开放的架构, 方便体现环境和需求的特殊性。

本系统数据采集主要包括安全事件数据采集, 安全漏洞数据采集, 安全配置采集。其中实时采集安全事件和告警, 便于实时告警、分析和响应。采集安全漏洞数据用于主动防御和风险管理。收集各个安全产品、路由器的安全配置, 用于审计。必要时可以实现配置的一致性。

2.2 应用服务层

应用服务层负责对采集到的原始数据进行分析处理。将从不同来源采集到的数据进行关联分析, 为应用展示层提供数据支持。

应用服务层在应用展示层和数据采集层之间起到承上启下的作用, 完成了除收集安全信息以外剩余的所有功能。如:资产管理、安全信息监控、脆弱性管理、安全事件处理、安全知识管理、安全策略管理、安全状况评估、安全预警等。

2.3 应用展现层

应用展现层实现了安全运维管理平台的统一界面展示。通过应用展现层, 能够查看资产分布状态、关注区域的安全状况、安全事件发生的趋势、各类资产的脆弱性状况等;通过应用展现层, 完成对资产管理、安全信息监控、脆弱性管理、安全事件处理、安全知识管理、安全策略管理、安全状况评估、安全预警功能模块的配置;通过应用展现层, 完成报表的生成、输出 (保存和打印) 等。

2.4 网络架构设计的特点

数据采集采用了开放的架构设计, 将安全设备被管理的能力视为设备对外提供的一类服务——管理服务。SOC安全运维平台的主要功能就是对安全设备进行统一监管, 也就是集中使用这些服务。采用这样的架构设计系统很好的反映了现实的问题, 体现了SOC安全运维平台的实质。

通过对服务的集中管理实现对设备的统一管理, 由于安全设备的多样性和异构性是统一管理的难题, 应用服务层实现了在各种异构的安全设备和SOC安全运维平台之间搭建的一个统一的中间层——服务。服务屏蔽了各种安全设备, 在SOC安全运维平台看来, 管理活动实际上是以服务请求者的身份使用一个个的管理服务, 而无需考虑服务建立在何种硬件或操作系统上以及服务涉及的接口。

3 软件体系结构的设计

在网络架构设计的基础上, 本课题提出了如下的概念模型。整个SOC系统分为SOC界面、应用服务器、采集层和数据库服务器4个部分。此概念模型的设计理念为:鉴于网络安全管理平台在体系结构和业务功能方面都比较复杂, 本设计对系统分层, 各个层次相对独立和分离, 其中应用服务器的安全事件处理模块以及采集层的各个模块可以根据用户的需求进行平行扩展, 在采集层还可以根据业务的发展和新的要求进行功能的扩展, 并通过统一消息系统完成数据的标准化。本设计降低了应用服务器和SOC界面之间的相关性, 降低了应用服务器各个模块之间的耦合度, 便于积木式构建系统。由于这两层软件独立开发, 通过开放式接口连接, 降低了开发的难度, 提高了系统的稳定性和可维护性, 方便系统扩容、新业务开发以及为其它系统的用户提供开放式接口连接。

3.1 SOC界面

在建移动业务支撑系统安全管理平台SOC的设计中, 主要采用了面向对象的设计方法, 使用了J2EE技术, 进行基于J2EE的多层B/S结构设计。

SOC界面采用浏览器/服务器模式软件体系结构。这种三层B/S (浏览器/服务器) 体系结构是把传统的两层C/S结构的业务逻辑从客户机的任务中分离出来, 用户通过浏览器向分布在网络上的许多服务器发出请求, 服务器对浏览器的请求进行处理, 将用户所需信息返回浏览器, 而其余如数据请求、加工、结果返回以及动态网页生成、对数据库的访问和应用程序的执行等工作全部由中间层完成。B/S结构减轻了客户机的负载, 降低了客户机的性能要求, 而且使系统的管理更为集中, 成为目前业务系统采用的主流结构。

3.2 应用服务层

应用服务层主要是完成对采集来的各类资源数据的处理, 形成对风险、策略、知识等的综合管理, 同时按照安全问题的处理流程、依照相关的规则和安全风险管理模型来实现对防火墙、入侵检测、防病毒、主机、网络等构成的安全防护体系的统一监控和管理, 该层在系统实现时主要依靠基于消息通信的后台程序来支撑。应用服务器上安装了SOC界面服务器和SOC后台处理程序, 主要包括安全事件处理、安全状况评估、脆弱性收集分析、风险值计算等功能。

3.3 安全信息收集代理层

安全信息收集代理层主要是完成资产自动发现和收集日志信息生成安全信息, 主要功能是根据要求采集被管理资源 (包括各种安全设备、网络和主机设备) 的原始信息, 包含事件信息、漏洞信息、流量信息和安全和操作日志信息等, 将对所管理资源 (硬件、软件等) 中与安全相关的信息按照一定格式进行预处理 (如过滤、标准化、关联等) , 同时要求遵循标准的通信协议进行输出或被访问。例如, 安全事件的采集需要不断侦听本地主机端口, 接受安全设备发送来的安全事件, 再将其转换成标准的安全事件信息存入安全事件数据库中, 状态信息和配置规则信息主要是根据安全设备所支持的管理接口编写合适、高效的调用程序调用管理接口。

在安全信息收集代理层中, 安全事件的采集主要是运用了JAVA的一个很重要的特性, 即多线程。在客户端向服务器端发出请求时, 客户端把发来的请求放在一个消息队列中, 服务端依次从这个消息队列中取出请求来处理, 但是如果遇到单线程, 那么消息队列中的下一个请求就要等到前一个请求完全处理完后才会响应, 从而导致客户端的长时间等待;而如果采用多线程, 则服务端处理可以同时多个请求, 提高系统的性能。新线程完成的工作主要是通过调用函数readline () 读取一行的安全事件记录, 利用可重用的安全事件分析类从各式各样的安全事件格式中提取与安全统一管理有关的信息, 建立起与数据库服务器的连接, 将这些关键信息保存在数据库中。

3.4 数据库服务器

数据库服务器采用ORACLE 10g, 需要对数据资源或中间数据进行管理, 还需要具有完备的通讯、应用日志功能。按照请求命令的优先级提取用户数据 (并保证同一用户按照时间排序) , 交给通信进程处理, 并接受通信进程的应答将结果返回数据库, 属于非数据的原因造成的指令执行失败可以自动重新处理。

数据库服务器选型确定之后, 就开始数据库的设计。数据库设计分为4个步骤。

首先, 确定建立数据库的目的并收集数据, 即进行需求分析。通过详细调查要处理的对象来明确用户的各种需求, 并且通过调查、收集和分析信息, 了解数据库中需要存储哪些数据以及完成何种数据处理功能。确定了建立数据库的目的之后就需要根据目的收集相关信息。

数据库设计过程的第二阶段是建立概念模型。根据应用的需求, 画出能反映每个应用需求的E-R图, 其中包括确定实体、属性和联系的类型。然后优化初始的E-R图, 消除冗余和可能存在的矛盾。概念模型是对用户需求的客观反映, 并不涉及具体的计算机的软、硬件环境。这一阶段的工作重心是如何表达出用户对信息的需求, 暂时不考虑具体的实现问题。

数据库设计过程的第3阶段是建立数据库模型。将概念模型中得到的E-R图转换成具体的数据模型, 实际上是使用关系数据模型把实体、实体的属性和实体之间的联系转换为关系模式。

分布式无线网络平台 篇9

关键词 分布式网络；信息管理；企业信息化

中图分类号 TP311 文献标识码 A 文章编号 1673-9671-(2012)052-0100-01

随着网络计算机技术的飞速发展，企业的信息管理已经体现出越来越高的集成度和信息化，对于企业管理的智能化和数字化起到了很好的辅助支撑作用。但是，在很多企业中，信息管理系统被流于形式，其应用往往和网络割裂开来，从而无法发挥分布式网络信息管理的真正优势。尤其是在我国加入WTO之后，各行各业企业的管理由于市场竞争的加剧而面临更加复杂繁重的信息管理任务，如果再依靠过去传统的人力手工管理模式，在很大程度上将造成人力资源的浪费和企业信息管理成本的上升，因此，如何利用网络技术实现对企业信息的集成化、分布式管理，成为了摆在每一个企业家面前的难题之一。本论文主要结合分布式网络的发展，以及企业信息化管理的需求，将二者结合起来，深入分析探讨分布式网络在信息管理系统中的应用，以期从中能够找到合理有效的面向企业信息管理系统的网络应用管理模式和方法，并以此和广大同行分享。

1 分布式网络在信息管理系统中的应用概述

分布式网络的结构是由分布在不同地点且具有多个终端的节点机互连而成的。网中人一点均至少与两条线路相连，当任意一条线路发生故障时，通信可转经其他链路完成，具有较高的可靠性。同时，网络易于扩充。分布式网络又称网型网，较有代表性的网型网就是全连通网络。可以计算，一个具有n个节点的全连通网需要有n*（n-1）/2条链路，这样，当n值较大时，传输链路数很大，而传输的链路的利用率较低，因此，在实际应用中一般不选择全连通网络，而是在保证可靠性的前提下，尽量减少链路的冗余和降低造价。分布式网络与中央控制式网络对应，它没有中心，因而不会因为中心遭到破坏而造成整体的崩溃。在分布式网络上，节点之间互相连接，数据可以选择多条路径传输；但是分布式网络并不利于集中管理，安全性不好控制。针对上述分布式网络管理的分析，现在，分布式网络已经广泛的应用到信息管理系统中。所谓企业的信息管理是指为企业的经营、战略、管理、生产等服务而进行的有关信息的收集、加工、处理、传递、储存、交换、检索、利用、反馈等活动的总称。企业信息管理是企业管理者为了实现企业目标，对企业信息和企业信息活动进行管理的过程。企业信息管理是信息管理的一种形式，把信息作为待开发的资源，把信息和信息的活动作为企业的财富和核心。因此，合理利用分布式网络，构件分布式信息管理系统，实现系统的全局化集成管理，能够有效的降低企业的信息管理成本和维度，易于实现企业的信息化管理。

2 分布式网络在信息管理系统中的应用

1）企业信息管理系统的网络需求分析。企业信息管理的基本任务如下：①有效组织企业现有信息资源，围绕企业战略、经营、管理、生产等开展信息处理工作，为企业各层次提供所需的信息。②不断地收集最新的经济信息，提高信息产品和信息服务的质量，努力提高信息工作中的系统性、时效性、科学性，积极创造条件，实现信息管理的计算机化。③企业的信息化管理，具体来说，主要包括：计算机网络基础设施建设（企业计算机设备的普及、企业内部网intranet/企业外部网extranet的建立与因特网的联接等）；生产制造管理系统的信息化（计算机辅助设计cad、计算机辅助制造cam、等的运用）；企业内部管理业务的信息化（管理信息系统mis、决策支持系统dss、企业资源计划管理erp、客户关系管理crm、供应链管理scm、知识管理km等）；企业信息化资源的开发与利用（企业内外信息资源的利用、企业信息化人才队伍培训、企业信息化标准、规范及规章制度的建立）；企业信息资源建设（包括信息技术资源的开发、信息内容资源的开

发等）。

2）分布式网络的应用及其技术实现。①分布式企业信息管理网络的构建。整个分布式信息管理系统根据分布式网络所处位置可分为两层：网络监测管理层、数据采集传输层。数据采集传输层又可以分为数据采集网络和信息接收处理终端。系统总体方案阐述如下：一是网络监测管理层。监测管理层位于服务器机房，是由监测中心为核心的网络组成。监测中心由监测工控机、路由器、gprs modem等硬件和监测管理软件组成。监测中心用来接收数据采集节点采集的有关企业生产、管理等方面的数据；另一方面，监测中心接入有线传输的局域网，将数据发布到网上，供远程客户访问查询。二是数据采集和传输层。数据采集和传输层主要由各种节点构成，其主要作用是负责采集企业生产、管理等各个方面的基本数据信息。在该层中还有个信息处理接收终端，该终端主要起网关作用，对采集到的企业生产信息进行归类并向数据库传输，实现远程存储和查询访问等功能。②企业分布式信息管理的同步技术实现。在分布式网络的信息同步技术中，目前数据复制技术应用较为广泛，但是数据复制技术只是在特定的范围和领域内应用，相对而言有一定的局限性，尤其是在网络带宽较窄的时候，数据传输会变得很不稳定，传输质量可靠性不高，而且数据传输的量也很有限，如果遇上网络拥塞，长时间无法传输数据，那么有用的数据很有可能会被丢弃。因此，可以利用应用程序在监控到本地数据库上的数据更新事务后，将更新事务封装成mss消息发送。对于本地而言，消息在交付给mrb之后首先进入本地消息发送队列等待发送，若无异常，消息将送到目的客户标题所指示的远端站点的消息接收队列中。同时，一个后台服务程序一直监视着接收队列，一旦有消息到达，它将读取消息，并根据消息内容对本地数据库执行所描述的更新事务，如果更新成功，则处理结束，并返回“更新成功”，否则返回“更新失败”。此时发送端的一个后台服务程序一直监视应答队列，根据收到的消息类型进行相应的操作，若成功，则将该消息记录从数据库中删除；若失败，则周期性地重发该消息，从而实现分布式网络的数据实时更新。

3 结束语

随着企业管理方式方法的进一步发展，企业实现分布式信息化管理必然成为企业信息管理的主流趋势。在新的形势条件下，如何应对信息化浪潮给传统的企业管理带来的冲击，本文的探讨或许给出了一定的答案。首先就是要结合具体的企业特点对企业进行信息化管理的需求分析，在此基础上给出分布式网络的组建框架及其具体的技术实现，从而为进一步提高企业的信息化管理提供必要的网络基础支撑条件。本论文所探讨的方法，无论是对于理论研究还是进行应用实践，均是具有一定指导价值的，因而是值得大力推广应用的。

参考文献

[1]鲁佩云.基于intranet的企业管理信息系统[J].当代经济,2003,5:33-34.

[2]杨建青,刘海青,张朝辉.企业管理信息化技术研究，现代集成技术研究[J].中国制造业信息化,2003,32(3):144-145.

[3]林涛,陈竹君.对企业管理信息系统的认识[J].情报探索,2003,4:19-20.

[4]孙海涛.如何构件企业信息管理系统[J].管理方略,2001,6:75-76.

作者简介

分布式无线网络平台 篇10

在电网企业中,除了记录生产、业务、交易和客户信息等结构化数据外,还有如供用电合同、项目图档、邮件、可扩展标 记语言(Extensible Markup Language,XML)文件、表单、个人桌面文档等大量非结构化数据[1,2]。据统计,这些非结构化数据占比达到80% 以上,且增长率每年都在呈指数级递增, 如果说结构化数据用详实的方式记录了企业的生产经营活动,那么非结构化数据则包含了掌握企业命脉的关键内容,其重要性不言而喻。根据当前电网企业的业务管理特点,可将企业中的非结构化数据分为2类:一类是具有管理特征的个人工作文档,这类文档分散存储在个人计算机(Personal Computer, PC)中,暂称为管理类非结构化数据;另一类是具有业务特征的文档,这类文档通过主数据以附件的形式存储在各类业务信息系统数据库中,暂称为业务类非结构化数据。

对非结构化数据的管理,业内普遍面临以下困扰。

1)管理类非结构化数据存储在PC桌面,呈现游离分散状态;业务类非结构化数据由信息系统各自归档,依附主数据呈现半结构化状态。这些非结构化数据分散存储,无法体系化统一管理,难以进行深度利用。

2)检索渠道各不相同,检索效率低下,特别是在信息系统省级大集中部署模式下,下属单位上传的业务类非结构化数据大量消耗宝贵的统一存储空间,而且会对数据库和骨干网络带来极大负担,也不利于容灾中心的数据同步。

本文从非结构化数据生命周期中选取数据获取、数据传输、数据管理、数据利用4个生命节点重点探讨分布式非结构数据管理平台的建设思路。

1数据获取

要使企业非结构化数据得以规范统一管理,必须改变数据分散存放状态,使分属不同渠道的非结构化数据归集到统一的管理平台,优化数据的存储结构,实现集约化管理。

数据归集作为各异构系统接入非结构数据管理平台的入门环节,其接口将直接影响到非结构化数据的采集及转化质量,接口定义显得尤为关键。本文的思路是利用企业信息集成平台实现数据的归集处理,其良好的互操作性、开放性、可扩展性及安全性等特点能够保证其为企业异构系统的无缝集成提供高可靠性的支持。

1.1集成框架

企业信息集成平台是一种实现信息集成的中间件产品,一种在标准化基础上为所有异构对象提供标准、统一的服务全生命周期管理、服务治理能力和信息交互的基础软件平台[3]。非结构数据管理平台集成框架如图1所示。

图1中,非结构数据管理平台与业务系统通过企业信息集成平台进行无缝集成,对业务系统的各类数据源进行封装,并以Web Service的形式发布到企业信息集成平台,企业信息集成平台对服务组装和接口解析,将已获取的数据信息转发给非结构数据管理平台接收。整个过程企业信息集成平台无需关注业务系统采用的环境、系统、编程语言和数据库等信息,只需关注业务系统推送的数据是否与平台要求的字段信息匹配,对匹配资源进行适配接入、数据映射、服务调用、服务编排、流程编排、规则配置等操作,从而实现面向服务的集成。任何应用系统之间的交互、衔接均必须通过企业信息集成平台完成,改变传统系统间点对点、直连式通道的接口建设模式。

基于企业信息集成平台的数据获取方式,能够满足企业内部各业务系统的及时归集、存储和管理, 通过接口标准或接口协议,完成非结构化数的准入识别与约束处理。

1.2基于SOA的集成思路

企业信息集成平台基于面向服务的体系结构 (Service-Oriented Architecture,SOA)的设计理念, 具有灵活多样的接口服务,将应用程序的不同功能单元通过这些服务之间定义良好的接口和协议联系起来,并且独立于硬件平台、操作系统和实现服务的程序语言,具有灵活性、重用性、集成性等架构特点。

Web服务是实现SOA架构模式的技术规范, 具有如下 特点:1基于XML、超文本传 送协议 (Hypertext Transfer Protocol,HTTP)等协议技术, 能够较好地实现系统的开放互连;2与同类技术相比,它可以同任何技术的组件相连,具有很好的互操作性;3不仅可以基于HTTP协议实现,也可以使用简单邮件传输协议(Simple Mail Transfer Protocol, SMTP)、文件传输 协议(File Transfer Protocol, FTP)等传输数据,如在本文研究课题中,可以对现有业务系统中基于其他中间件技术实现的部分集成功能进行封装,以Web Service的形式展现;4 Web服务可以通过多种可靠有效的安全技术保证传输信息和 简单对象 访问协议(Simple Object Access Protocol,SOAP)信息安全性问题。

基于以上特性分析,非结构数据管理平台与各应用系统之间的集成将依托SOA架构[4],基于标准的Web服务进行信息交互,实现各业务接口组件在企业内横向业务协作、纵向集成重用,解决数据向非结构数据管理平台归集的问题。

2数据管理

非结构化数据管理平台不仅是企业非结构数据的归集地和存储中心,同时也制定了非结构数据的管理方法。下面分别从混合式二维分布存储、面向文档的数据管理2个方面梳理并提出非结构化数据的管理方法。

2.1二维分布存储架构

混合式的二维分布存储,即将非结构化数据的条目数据与内容数据进行分布式存储,条目数据统一存放在企业总部侧的非结构化数据管理平台中, 总部平台具有对条目数据的统一管控权限;内容数据则分别存放在数据所属单位的非结构数据管理平台中,各单位将业务办理时需上传的文档附件存放在本地服务器,实现分布式存储。通过建立目信息与内容信息的索引关联,使得企业各单位间的数据能够顺利访问与调用,实现“在集中下有序分离”。 非结构数据管理平台存储拓朴如图2所示。

条目的存储结构[5]由文档标识码、文档业务属性、附件位置属性等构成。数据访问时通过文档标识码寻址附件位置信息,通过附件位置信息访问附件内容。这种“统一调配、分流访问”的构建方式,在企业信息系统大集中部署模式下,充分利用各单位数据中心资源存储附件内容,减少非结构数据对大集中系统统一存储空间的资源消耗,附件仅在各单位内部网络上传输,不需占用城域网骨干带宽,大大缓解骨干网络带宽受限的问题。

2.2面向文档的数据管理

通常情况下,企业业务变化会导致非结构化数据条目信息的变更,必须考虑条目信息数据的灵活扩展。传统的关系型数据库在结构和关系方面的限制过于严格和单一,难以适应条目信息数据的变化,而面向文档的数据库,不受既定规格和空间的约束,可以视具体条目数据自动进行扩展存储,无需从底层数据架构作二次开发,即可轻松完成自适应存储。

文档是文档数据库的核心概念,由一系列有序的键值对构成,是数据的基本单元,类似于关系数据库中的行。而集合则可以看成是没有模式的表,由一组文档组成。面向文档的数据库关系模型是:文库数据库的一个数据库实例由多个“关系表”组成, “表”的模式在宏观上可变,但在微观上是确定的;在某一个时刻,其模式由该对应集合中所有文档的键构成,每个字段的域与该字段对应文档的键的取值范围相同;集合中的文档是该“表”的一条“元组”, “元组”在形式上除了对应文档所有的值,还包含 “表”中其他文档的值(为空值)。数据存储实现过程如图3所示。

1)业务变更前:在时间点T1时,文档条目信息各属性的取值分别作为文档的键值对进行存储。

2)业务变更后:在时间点T2时,系统接收新文档,自动按其属性信息(如存在新增属性),新增键值对的存储空间,同时,历史文档也自动增加新增键值对的存储空间。如图中的“num”属性及对应存储的 “num”键值对。

基于这种存储方式,不仅能够更好地保证非结构数据管理平台中条目信息的统一管控,也能够大幅降低数据库的维护工作量和维护难度。

3数据传输

通过企业信息集成平台为非结构数据管理平台提供了统一的数据归集通道,数据二维分布存储方式为非结构数据管理平台的分布式访问提供了可能性。基于这2方面的基础,针对数据的归集传输与访问传输,从经济成本、时间成本、部署难易程度和实现效果等方面综合考虑,本文提出“回调”方案,将业务类非结构数据从业务系统中“剥离”,实现本地存储和访问,减少骨干网络带宽占用。

3.1回调方案

回调方案的主要思路是将业务系统非结构化数据统一归集到非结构数据管理平台,业务系统本身不保存数据,数据访问通过企业集成平台调用接口实现,其中,数据归集接口的接入标准和接入规范由非结构数据管理平台制定,各业务系统需遵循标准接口规范进行接口调用。

3.2回调方案的上传附件过程

回调方案的上传附件过程如图4所示。

回调方案的上传附件过程如下。

1)本地用户在业务系统中完成业务办理后,点击“附件上传”按钮,通过HTTP协议发出服务请求。

2)业务系统调用“保存条目服务”接口,向企业信息集成平台代理发送SOA报文。

3)企业信息集成平台将数据转发到总部侧的非结构数据管理平台。

4)总部侧非结构数据管理平台将上传表单地址通过SOA协议发送到企业信息集成平台。

5)企业信息集成平台将接收到的返回数据转发到业务系统,业务系统从总部侧非结构数据管理平台获取指向本地非结构数据管理平台上传地址生成上传附件表单。至此,完成条目数据在总部侧非结构数据管理平台的存储过程。

6)业务系统输出指向本地非结构数据管理平台的上传表单,用户上传附件到本地非结构数据管理平台,本地非结构数据管理平台接收并保存附件,生成附件存储标识信息(包括附件标识码、附件地址等信息),并将附件存储标识信息发送至同步模块并返回浏览器。

7)同步模块接收本地非结构数据管理平台的附件存储标识信息后,通过SOA协议向企业信息集成平台发送信息,由企业信息集成平台转发到总部侧非结构数据管理平台。

8)浏览器接收本地非结构数据管理平台的附件存储标识信息后,将信息发送给业务系统进行存储。 至此,完成内容数据在本地非结构数据管理平台的存储过程;完成条目信息与内容信息的关联过程。

4数据利用

非结构数据管理平台存储的是经过处理的资源数据,前面章节呈现的解决方案为非结构化数据的便捷利用提供了技术支撑,本文提出“存储与利用并重”的理念,改变非结构化数据“重保存、轻利用”的管理格局,实现非结构化数据利用的“四大”转变,使非结构化数据的资源价值得以充分利用。

4.1在利用维度上的转变

从“在各业务系统中单维数据利用”到“基于平台的多维综合数据利用”的转变。传统的非结构化数据分散到各业务系统中,数据利用仅限于当前业务系统范围内,而归集到非结构数据管理平台的数据经过平台的汇总梳理、文本分析、数据整合、信息抽取后,可通过维度归集(如按部门维度、时间维度、 业务维度、项目维度等)、关联数据、相关资源检索、组织推荐等手段实现数据信息的综合推送与展现, 提高非结构化数据的信息价值含量。

4.2在利用渠道上的转变

从“分散不一的利用渠道”到“基于Web端和客户端双轨并行的利用渠道”的转变。传统模式下, 因各业务系统的建设水平差参不齐,对非结构数据利用并不十分重视,使得系统提供的利用渠道比较单一,有的是基于线下的查找,有的是基于线上的查找,并且查找工具各异、查找标准不一。非结构数据管理平台可提供基于Web端与客户端双轨并行的利用渠道,分别满足于业务类和管理类两类数据的并行分线应用和应用需要。

4.3在利用范围上的转变

从“偏重于相关业务人员的利用”到“覆盖公司决策层、管理层、基层员工的分级服务”的转变。一般情况下,业务系统只处理并存储相关专业的数据, 数据受众方一般是业务人员,并且数据一般为原始数据,数据的服务性体现不强。非结构数据管理平台可利用大数据分析方法,对归集数据通过数据挖掘、统计分析、权限控制等技术,实现面向企业内部决策层、管理层、基层用户的对应数据推送,并以报表、图表等形式呈现,满足数据辅助决策支持的目的,扩大数据的受众面,提升数据的服务性。

4.4在利用手段上的转变

从“单一查询检索方式”到“多向互动利用方式” 的转变。非结构数据管理平台作为企业各种非结构化数据的归集中心,在数据处理问题上具备更开阔的处理空间,提供文档检索、浏览、共享、收藏、订阅、 借阅等功能,实现个人与平台的信息互动、个人与组织之间的信息互动。

5结语