CN102377582A

CN102377582A - 数据上传方法和设备

Info

Publication number: CN102377582A
Application number: CN2010102486800A
Authority: CN
Inventors: 余再跃
Original assignee: Datang Mobile Communications Equipment Co Ltd
Current assignee: Datang Mobile Communications Equipment Co Ltd
Priority date: 2010-08-09
Filing date: 2010-08-09
Publication date: 2012-03-14

Abstract

本发明实施例公开了一种数据上传方法和设备，通过应用本发明实施例的技术方案，一方面，网元设备通过文件方式向网管系统进行数据传输，保证了数据传输的高效，另一方面，网管系统将接收到的文件存储在内存中，在对文件中的数据完成解析处理之后才将相应的数据存储到数据库中，避免了对硬盘的多次读写操作，从而，进一步提高了网元设备向网管系统上传数据的传输效率和处理速度，在简化处理流程的情况下，保证上传的数据能够得到及时处理，保证了网络管理的效果和效率。

Description

数据上传方法和设备

技术领域

本发明涉及通信技术领域，特别涉及一种数据上传方法和设备。

背景技术

近年来，随着通信技术的发展，通信网络也在不断的发展壮大，无论是无线通信网络还是有线通信网络，其覆盖范围和复杂程度都有很大程度的扩大和提高。因此，对网络管理系统的要求也随之越来越高，仅仅依靠各个网络设备自身的管理工具进行分别管理已经不能满足网络发展的需要。现代化的移动网络需要一个覆盖面广、自动化程度高并可以灵活配置和扩展的标准的网络管理系统或可以对系统中的网络设备实现管理的网络管理设备。

从管理功能上，网络管理设备主要包括配置管理、故障管理、性能管理、安全管理和计费管理等方面的网络管理功能。每个功能都侧重于某一方面的网络管理，但它们并不是各自独立的，在一定条件下这五个功能可以相互转化。其中，性能管理在实际应用中对系统运行状态和效率影响最大，所以，所得到的关注也是最多的。

性能管理主要是对移动网络的性能进行管理。具体来讲，就是通过对网络运行状况的监测，保证网络能够有效、平稳、安全地运行。并通过对网络设备数据的采集和分析，给网络管理人员提供充足、完整的运行数据，供管理人员根据网络运行状况制定合适的运行策略，使网络运行在最高效的状态下。

性能管理包括监视和分析被管网络及其所提供服务的性能机制。性能分析的结果可能会触发某个诊断测试过程或重新配置网络以维持网络的性能。性能管理收集分析有关被管网络当前状况的数据信息，并维持和分析性能日志。一些典型的功能包括：

(1)性能监控

由用户定义被管对象及其属性。被管对象类型包括线路和路由器；被管对象属性包括流量、延迟、丢包率、CPU利用率、温度、内存余量。对于每个被管对象，定时采集性能数据，自动生成性能报告。

(2)阈值控制

可对每一个被管对象的每一条属性设置阈值，对于特定被管对象的特定属性，可以针对不同的时间段和性能指标进行阈值设置。可通过设置阈值检查开关控制阂值检查和告警，提供相应的阈值管理和溢出告警机制。

(3)性能分析

对历史数据进行分析，统计和整理，计算性能指标，对性能状况作出判断，为网络规划提供参考。

(4)可视化的性能报告

对数据进行扫描和处理，生成性能趋势曲线，以直观的图形反映性能分析的结果。

(5)实时性能监控

提供了一系列实时数据采集；分析和可视化工具，用以对流量、负载、丢包、温度、内存、延迟等网络设备和线路的性能指标进行实时检测，可任意设置数据采集间隔。

(6)网络对象性能查询

可通过列表或按关键字检索被管网络对象及其属性的性能记录。

相应的，为了实现上述的各项功能，网关设备需要从各个网元设备中获取大量的性能数据，以便进行性能分析。

网管系统中，性能数据由网元设备上传到网管系统中，常用上传方式包括以下两种方式：

方式一、文件方式

网管系统中，各网元设备将性能数据以文件方式向网关设备上传，网管系统收到该文件后，对其中的性能数据进行解析，然后，将完成解析的性能数据存入数据库。

如图1所示，具体的处理流程包括以下步骤：

步骤S101、网管系统的FTP(File Transfer Protocol，文件传输协议)服务器接收到从网元设备上传的性能文件，并保存在本地。

在本步骤中，性能文件是网元设备上传的文件形式的性能数据，而本步骤的网管系统将性能文件保存在本地的操作需要对硬盘进行一次写操作。

步骤S102、网管系统中的应用程序读取性能文件，并解析其中的性能数据，得到性能解析结果。

本步骤涉及对硬盘的一次读操作。

步骤S103、网管系统将完成上述解析操作的性能数据存入数据库中。

实际上，本步骤同样需要对硬盘进行一次写操作。

方式二、消息方式

即网元设备将性能数据以消息方式上传给网管系统。在这样的处理中，网管系统对硬盘只进行了一次写操作。

在实现本发明实施例的过程中，申请人发现现有技术至少存在以下问题：

对于上述的方式一，在整个处理过程中，至少需要进行两次硬盘写操作，一次硬盘读操作，以及一次非常消耗资源的性能数据解析过程，效率很低。

对于上述的方式二，虽然减少了硬盘读写次数，但实际的处理效率却比方式一的处理效率还低，具体原因如下：

1、性能数据数据量大，涉及的性能指标非常多，往往若干组性能指标作为一条消息上传，使得网管和网元之间产生频繁的消息交互，这是最核心的一个原因。

2、应用层复杂的协议，例如，消息发送，确认，无论是停等协议，还是窗口协议，这些协议都会使得传输过程变得复杂，降低效率。

基于以上的原因，使得消息方式上传往往比文件方式上传更慢了。

因此，上述两种方式都不能解决网元设备向网管系统上传性能数据的效率问题。

发明内容

本发明实施例提供一种数据上传方法和设备，解决网元设备向网管系统进行数据传输效率低，影响网络管理效果的问题。

为达到上述目的，本发明实施例一方面提供了一种数据上传方法，包括：

网管系统将接收到的网元设备所上传的文件直接存储到内存中，所述文件包含所述网元设备所获取的待解析数据；

所述网管系统对存储在内存中的所述文件进行解析处理，并将完成所述解析处理的文件存储到硬盘中。

另一方面，本发明实施例还提供了一种终端设备，包括：

接收模块，用于接收网元设备上传的文件，所述文件包含所述网元设备所获取的待解析数据；

存储模块，用于将所述接收模块所接收到的网元设备所上传的文件直接存储到内存中；

处理模块，用于对所述存储模块存储在内存中的所述文件进行解析处理，并将完成所述解析处理的文件存储到硬盘中。

与现有技术相比，本发明实施例具有以下优点：

通过应用本发明实施例的技术方案，一方面，网元设备通过文件方式向网管系统进行数据传输，保证了数据传输的高效，另一方面，网管系统将接收到的文件存储在内存中，在对文件中的数据完成解析处理之后才将相应的数据存储到数据库中，避免了对硬盘的多次读写操作，从而，进一步提高了网元设备向网管系统上传数据的传输效率和处理速度，在简化处理流程的情况下，保证上传的数据能够得到及时处理，保证了网络管理的效果和效率。

附图说明

图1为现有技术中各网元设备将性能数据以文件方式向网关设备上传的流程示意图；

图2为本发明实施例所提出的一种数据上传方法的流程示意图；

图3为本发明实施例所提出的一种数据上传的网络管理系统的示意图；

图4为本发明实施例提出的一种网管系统的结构示意图。

具体实施方式

如背景技术所述，网元设备需要向网管系统上传待解析的数据信息(包括性能数据等)，以使网管系统能够通过解析这些数据了解当前的网络状态，并进行相应的网络管理。

但是，由于网元设备不间断产生大量待解析数据，包括性能数据、告警数据、故障数据等，均需要上传给网管系统，而网管系统对这些待解析数据的处理速度必须大于网元设备产生这些待解析数据的速度，否则，就会形成待解析数据的积压，最终导致网管系统的崩溃。

目前，虽然正常情况下，网管系统对这些待解析数据的处理速度大于网元产生的速度，但随着通信技术的发展，由于性能指标等监测项目的不断增加，待解析数据的总量也有进一步增加的趋势，同时，在系统比较繁忙，资源比较紧张的情况下，则会出现网管系统对这些待解析数据的处理速度低于网元设备产生的速度的情况。

为了避免这种情况的出现，需要进一步提高网元设备向网管系统进行数据传输的效率，本发明实施例就是基于此目的，提出了一种效率更高的数据上传方法。

如图2所示，为本发明实施例所提出的一种数据上传方法的流程示意图，该方法具体包括以下步骤：

步骤S201、网管系统将接收到的网元设备所上传的文件直接存储到内存中。

其中，上述的网元设备所上传的文件中包含该网元设备所获取的待解析数据，如性能数据、告警数据、故障数据等。

需要指出的是，在本步骤之前，还包括网管系统在内存中建立用于存储接收到的文件的资源池的过程。

此过程即为网管系统为了接收上传的数据而申请内存空间的过程，网管系统在内存中请求建立资源池，该资源池中包括多个文件组内存块；

其中，资源池中所包括的文件组内存块的数量等于网管系统所对应的网元设备的数量，每个文件组内存块用于存储一个网元设备所上传的的文件，而每个文件组内存块的大小都应大于一个网元设备能够上传的最大压缩文件组的大小，以保证该网元设备所上传的文件能够有足够的空间进行存储。

在实际的应用场景中，因为一个作为网络中关键网元设备的RNC(RadioNetwork Controller，无线网络控制器)，会在15分钟内上传一个性能文件，并且一个网管系统管理的RNC的总数量并不多，因此，为了最大程度避免竞争，资源池中的文件组内存块个数可以直接设定为RNC个数，这样，不同的RNC所上传的文件将分别存储在不同的文件组内存块中，而该文件组内存块的大小又大于一个RNC所可能上传的最大压缩文件组的大小，所以，可以保证RNC所上传的文件具有足够的存储空间。

在实际的应用场景中，本步骤的实现过程具体可以为：

首先，网管系统接收网元设备根据FTP协议上传的文件，通过稳定而高效率的FTP协议以文件的形式对待解析的数据进行传输，保证了数据传输的效率和稳定性。

然后，网管系统将接收到的文件存储到上述申请到的资源池的文件组内存块中，实现内存写操作。

为了使FTP服务器既能够将文件保存在内存，同时能够有将文件保存在磁盘的功能，需要FTP服务器能够区分哪些文件是写入内存的，哪些文件是写入磁盘的。例如，将性能文件写入内存，告警文件等其他文件则写入磁盘，可以根据文件路径或者文件名称等进行区分，例如，性能文件的文件路径或者文件名中都含有某个特殊的字符串。通过这种方式，FTP服务器能够轻易地进行区分。

需要进一步指出的是，在资源池中的资源管理过程中，还包括新资源的申请以及闲置资源的释放处理过程，具体说明如下：

(1)新资源的申请过程

当网管系统判断资源池中的资源量不足时，网管系统判断当前资源池中的文件组内存块的数量是否达到预设的最大的文件组内存块数量(资源池允许运行的最大的文件组内存块数量可在配置文件中进行配置)。

如果达到，网管系统拒绝接收网元设备上传的文件，如果没有达到，网管设备请求建立新的文件组内存块，并将新建立的文件组内存块加入资源池。

(2)闲置资源的释放过程

网管系统在内存中建立资源池之后，网管系统按照预设的检测周期检测资源池中各文件组内存块的文件存储状态；

如果资源池中所包括的文件组内存块的数量大于当前网管系统所对应的网元设备的数量，并且存在空闲的文件组内存块，网管系统释放空闲的文件组内存块。

一般情况下，一个RNC只会在同一时刻上传一个压缩文件组，而资源池所包括的文件子内存块的数量和网管系统所管理的RNC个数相同，因此一般情况下，资源池的资源是足够的，但是，也不排除网络拥塞的极端情况，在这种情况下，一个RNC可能正在传上一个周期的性能数据，但是传得很慢，而新的周期的性能数据又形成，同时开始传新周期的性能数据，如果很多RNC都出现这种情况，则可能出现资源池不够，需要网管系统申请新的资源的情况。

另外一种情况是，网管系统和网元设备之间断链一段时间后，网元设备积累了很多性能文件，开始同时上传若干性能文件。

这种以上两种情况下，网管系统会申请在资源池中增加新的资源，这在一定程度上缓解了资源竞争，并且通过上述的闲置资源的释放过程，网管系统可以在适当的时候回收闲置的资源，以免长期闲置造成的内存资源浪费。

通过以上方式，实现了内存资源的动态调整。

基于性能文件是网元设备和网管系统之间每15分钟都会进行一次传输的数据，使用资源池的内存管理方案可以很好地避免了内存的反复申请和释放，也避免了内存碎块，因此资源池和文件传输方案相结合，很好地提高了网元设备和网管系统之间数据的传输效率。

步骤S202、网管系统对存储在内存中的文件进行解析处理，并将解析得到的数据存储到数据库中。

在实际的操作中，本步骤的处理具体包括：

网管系统根据前述确定的存储文件的内存的地址信息，对存储的文件中所包含的待解析数据进行解析处理，在此过程中需要进行内存的读操作。

网管系统将完成解析处理的文件中数据存储到数据库中，此时，实现了一次硬盘的写操作。

通过以上描述，可以发现，在整个的流程中，包括了一次内存的写操作，一次内存的读操作，以及一次硬盘的写操作，与现有技术中的处理过程相比，对硬盘的读写操作减少了两次，而代之以内存的读写操作，由于内存的读写速度和便捷度要远高于硬盘的读写速度和便捷度。因此，这样的处理过程可以有效的提高数据传输的效率，而且，降低对硬盘的损耗和资源占用。

需要进一步指出的是，在实际的应用场景中，上述网元设备向网管系统传输的文件具体可以为包含性能数据的文件，以及告警文件，或者其他任何涉及网管系统和网元设备之间文件传输的文件类型，甚至推广到网管系统内部的操作维护终端和服务器之间的文件传输，这样的变化并不影响本发明的保护范围。

与现有技术相比，本发明实施例具有以下优点：

下面，结合具体的应用场景，对本发明实施例所提出的技术方案进行说明。

如图3所示，为本发明实施例所提出的一种数据上传的网络管理系统的示意图。

网管系统中建立一个FTP服务器，FTP协议是一个高效率的传输协议，因此，本发明实施例需要充分利用其高效率的特点，应用FTP协议进行文件传输，但本发明实施例中对这个FTP服务器进行了针对特定应用场景的改进，一方面，设定该网管系统中的FTP设备和位于网元设备中的FTP客户端之间遵循FTP协议进行文件交互，从而对待解析数据实现文件传输，但FTP服务器收到文件后，并不向硬盘中进行数据写入，而是将接收到的文件保存在内存中，然后，将存储了上述文件的内存地址传递给性能数据解析入库程序，由性能数据解析入库程序进行文件中的待解析数据的解析和入库操作。

显然，上述的处理过程实际上是对现有技术中以文件方式进行数据传输的方式一中的处理方式所进行的进一步改动，现有技术的方式一中，FTP服务器是打开一个本地文件进行硬盘的写操作，而在本发明实施例所提出的技术方案中，则是预先申请一块内存资源，将接收到的文件进行内存写操作。而后续的解析过程的文件读取对象也由硬盘变为了内存，这样的改变使得文件读写的效率进一步提高了，而鉴于开源的FTP服务器的技术已经非常成熟，所以，对其进行修改将是十分便捷的，因此，本发明实施例所提出的技术方案的应用过程中也将是非常方便的，降低了为应用本发明实施例所提出的技术方案而对现有网络架构的改造复杂度。

在本发明实施例所提出的技术方案中，只是对网管系统进行了调整，而对网元设备并没有进行改造，进一步提高了本发明实施例所提出的技术方案的应用便捷度。

本发明实施例所提出的技术方案对硬盘的读写操作次数非常少，只有数据入库(写入数据库)时进行一次硬盘的写操作。这样的处理，一方面提高了数据处理的速度，另一方面，也避免了硬盘的频繁读写所带来的硬盘损耗和资源占用。

与现有技术相比，本发明实施例具有以下优点：

为了实现本发明实施例的技术方案，本发明实施例还提供了一种网管系统，其结构示意图如图4所示，具体包括：

接收模块41，用于接收网元设备上传的文件，文件包含网元设备所获取的待解析数据。

在具体的应用场景中，接收模块41用于接收网元设备根据FTP协议上传的文件

存储模块42，用于将接收模块41所接收到的网元设备所上传的文件存储到内存中。

处理模块43，用于对存储模块42存储在内存中的文件进行解析处理，并将完成解析处理的数据存储到数据库(硬盘)中，具体包括：

解析子模块431，用于根据存储文件的内存的地址信息，对存储的文件中所包含的待解析数据进行解析处理；

持久化子模块432，用于将解析子模块431完成解析处理的文件中的数据存储到数据库(硬盘)中。

在具体的应用场景中，上述的网管系统还包括：

资源管理模块44，用于在内存中建立资源池，资源池中包括多个文件组内存块，其中，资源池中所包括的文件组内存块的数量等于网管系统所对应的网元设备的数量，每个文件组内存块用于存储一个网元设备所上传的的文件，文件组内存块的大小大于一个网元设备能够上传的最大压缩文件组的大小。

存储模块42，具体用于将接收模块41所接收到的网元设备所上传的文件直接存储到资源管理模块44所建立的资源池中相对应的文件组内存块中。

进一步的，该网管系统还包括：

判断模块45，用于判断资源管理模块44所建立的资源池中的资源量是否不足，如果判断结果为不足，进一步判断当前资源管理模块44所建立的资源池中的文件组内存块的数量是否达到预设的最大的文件组内存块数量；

如果达到，接收模块41拒绝接收网元设备上传的文件，如果没有达到，资源管理模块44请求建立新的文件组内存块，并将新建立的文件组内存块加入资源池。

进一步的，资源管理模块44在内存中建立资源池之后，还用于按照预设的检测周期检测资源池中各文件组内存块的文件存储状态，如果资源池中所包括的文件组内存块的数量大于当前网管系统所对应的网元设备的数量，并且存在空闲的文件组内存块，资源管理模块44释放空闲的文件组内存块。

与现有技术相比，本发明实施例具有以下优点：

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本发明实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明实施例各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本发明实施例所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本发明实施例序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本发明实施例的几个具体实施场景，但是，本发明实施例并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明实施例的业务限制范围。

Claims

1.一种数据上传方法，其特征在于，包括：

所述网管系统对存储在内存中的所述文件进行解析处理，并将解析得到的数据存储到数据库中。

2.如权利要求1所述的方法，其特征在于，所述网管系统将接收到的网元设备所上传的文件直接存储到内存中，具体包括：

所述网管系统接收所述网元设备根据文件传输协议FTP上传的文件；

所述网管系统直接将所述文件存储到内存中。

3.如权利要求2所述的方法，其特征在于，所述网管系统直接将所述文件存储到内存中之前，还包括：

所述网管系统在所述内存中建立资源池，所述资源池中包括多个文件组内存块；

其中，所述资源池中所包括的文件组内存块的数量等于所述网管系统所对应的网元设备的数量，每个所述文件组内存块用于存储一个网元设备所上传的的文件。

4.如权利要求3所述的方法，其特征在于，所述文件组内存块的大小大于一个网元设备能够上传的最大压缩文件组的大小。

5.如权利要求3所述的方法，其特征在于，所述网管系统直接将所述文件存储到内存中，具体为：

所述网管系统直接将所述文件存储到资源池中相对应的文件组内存块中。

6.如权利要求5所述的方法，其特征在于，当所述网管系统判断所述资源池中的资源量不足时，还包括：

所述网管系统判断当前所述资源池中的文件组内存块的数量是否达到预设的最大的文件组内存块数量；

如果达到，所述网管系统拒绝接收网元设备上传的文件，如果没有达到，所述网管设备请求建立新的文件组内存块，并将新建立的文件组内存块加入所述资源池。

7.如权利要求3所述的方法，其特征在于，所述网管系统在所述内存中建立资源池之后，还包括：

所述网管系统按照预设的检测周期检测所述资源池中各文件组内存块的文件存储状态；

如果所述资源池中所包括的文件组内存块的数量大于当前所述网管系统所对应的网元设备的数量，并且存在空闲的文件组内存块，所述网管系统释放所述空闲的文件组内存块。

8.一种网管系统，其特征在于，包括：

处理模块，用于对所述存储模块存储在内存中的文件进行解析，并将解析得到的数据存储到数据库中。

9.如权利要求8所述的网管系统，所述接收模块，具体用于接收所述网元设备根据FTP协议上传的文件。

10.如权利要求8所述的网管系统，其特征在于，所述处理模块，具体包括：

解析子模块，对内存中存储的所述文件进行解析；

持久化子模块，用于将所述解析子模块解析得到的的数据存储到数据库中。

11.如权利要求8所述的网管系统，其特征在于，还包括：

资源管理模块，用于在所述内存中建立资源池，所述资源池中包括多个文件组内存块，其中，所述资源池中所包括的文件组内存块的数量等于所述网管系统所对应的网元设备的数量，每个所述文件组内存块用于存储一个网元设备所上传的的文件，所述文件组内存块的大小大于一个网元设备能够上传的最大压缩文件组的大小。

12.如权利要求11所述的网管系统，其特征在于，所述存储模块，具体用于将所述接收模块所接收到的网元设备所上传的文件直接存储到所述资源管理模块所建立的资源池中相对应的文件组内存块中。

13.如权利要求12所述的网管系统，其特征在于，还包括：

判断模块，用于判断所述资源管理模块所建立的资源池中的资源量是否不足，如果判断结果为不足，进一步判断当前所述资源管理模块所建立的资源池中的文件组内存块的数量是否达到预设的最大的文件组内存块数量；

如果达到，所述接收模块拒绝接收网元设备上传的文件，如果没有达到，所述资源管理模块请求建立新的文件组内存块，并将新建立的文件组内存块加入所述资源池。

14.如权利要求11所述的网管系统，其特征在于，所述资源管理模块在所述内存中建立资源池之后，还用于按照预设的检测周期检测所述资源池中各文件组内存块的文件存储状态，如果所述资源池中所包括的文件组内存块的数量大于当前所述网管系统所对应的网元设备的数量，并且存在空闲的文件组内存块，所述资源管理模块释放所述空闲的文件组内存块。