CN101141754B

CN101141754B - 一种增值业务分析系统及其方法

Info

Publication number: CN101141754B
Application number: CN200610126817A
Authority: CN
Inventors: 田珂; 唐文彬; 魏国强; 赵化冰; 文秀林; 姜磊
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2006-09-05
Filing date: 2006-09-05
Publication date: 2010-05-12
Anticipated expiration: 2026-09-05
Also published as: CN101141754A

Abstract

本发明涉及一种增值业务分析系统及其方法，其中系统包括数据采集子系统、数据预处理器(26)和业务分析子系统(2)；其中方法包括通过数据采集子系统获取与其一一对应的网络中各短信处理设备(1)的原始业务数据；通过数据预处理器(26)将各所述原始业务数据转换成统一格式的业务数据；在业务分析子系统服务器(3)端将所述统一格式的业务数据汇总成一个或一个以上数据库，并可根据所述数据库按用户自定义或者系统预先设定的需求生成报表。这种系统及其方法通过数据预处理器将各种不同短信处理设备原始业务数据统一，进一步在汇总数据库的基础上提供标准报表和自定义报表生成方法，实现了对增值业务的统一监视和管理。

Description

一种增值业务分析系统及其方法

技术领域

本发明涉及通信网络管理，具体涉及一种增值业务分析系统及其方法，更具体地说，涉及包含多种短信处理设备的业务分析系统及其方法。

背景技术

目前增值业务已成为中国各大运营商的一个主营业务和重要收入来源，建立在短信基础上的各种增值业务更是层出不穷，并且发展十分迅猛。目前短信平台基本上是按省进行建设的，每个省的短信平台包括：短信中心、梦网/在信网关、互通网关、SP管理台、彩铃、彩信、WAP等短信处理设备，这些短信处理设备由多个生产厂家提供，基本上是分厂家和分系统的管理，而由于各厂家设备的原始增值业务话单在格式内容上差异很大，因此无法直接汇总进一步对增值业务进行统一监控和生成报表，而只能就不同设备分开进行监视和管理。

另一方面上，运营商需要增值业务汇总报表帮助其①进行经营决策分析、②提升在增值业务方面的监视、管理能力，特别有利于维护人员快速地发现、定位网络和业务故障点和故障面，快速恢复在线业务，提高系统运行质量，为市场经营工作提供有力的后台支撑。这些汇总报表一般可以划分为标准报表、OLAP报表以及自定义报表三种类型。标准报表是指根据行业规范要求必须提供的报表；OLAP报表是指客户通过手工钻取多维数据集(CUBE)产生的报表；自定义报表则是客户根据自身特点要求定制的报表。

发明内容

本发明需要解决的技术问题是针对目前增值业务平台网络现状，提供一种增值业务分析系统，帮助运营商实现对增值业务平台的集中管理和监控。

本发明上述第一个技术问题这样解决，提供一种增值业务分析系统，包括若干数据采集子系统、若干数据预处理器和业务分析子系统，其中：

(一)数据采集子系统：采集网络中各短信处理设备的原始业务数据；

(二)数据预处理器：与所述数据采集子系统一一对应，将所述原始业务数据转换成统一格式的业务数据；

(三)业务分析子系统：由客户端和服务器构成，其中服务器端将所述统一格式的业务数据汇总存储在一个或一个以上数据库中，并可根据所述数据库按用户自定义或者系统预先设定的需求生成报表。

按照本发明提供的增值业务分析系统，所述数据预处理器是独立存在的设备。

按照本发明提供的增值业务分析系统，所述数据预处理器内置在所述数据采集子系统或所述业务分析子系统中。

按照本发明提供的增值业务分析系统，所述业务分析子系统包括多维数据查询模块、日报回存处理模块、报表处理模块、调度模块，其中：

(一)多维数据查询模块：按用户自定义需求生成报表；

(二)日报回存处理模块：将日报导入所述数据库中相应的日表中；

(三)报表处理模块：按系统预先设定的需求生成报表；

(四)调度模块：按时间调度策略自动控制执行所述报表处理模块任务。

本发明另一个技术问题这样解决，提供一种增值业务分析方法，包括以下步骤：

5.1)通过数据采集子系统获取与其一一对应的网络中各短信处理设备的原始业务数据；

5.2)通过数据预处理器将各所述原始业务数据转换成统一格式的业务数据；

5.3)在业务分析子系统服务器端上将所述统一格式的业务数据汇总成一个或一个以上数据库储存，并可根据所述数据集按用户自定义或者系统预先设定的需求生成报表。

按照本发明提供的增值业务分析方法，所述汇总是增量汇总。

按照本发明提供的增值业务分析方法，所述增量汇总以可变时间段为采集粒度，节假日对应的所述时间段小于平时对应的所述时间段。

按照本发明提供的增值业务分析方法，该方法这样按用户自定义需求生成自定义报表，包括以下步骤：

8.1)用户通过客户终端人机界面根据自身实际需求提出报表需求；

8.2)将报表指标对应到所述数据库中的多个表中相应的字段；

8.3)通过多维数据集模块将涉及的数据库记录构建为多维数据集；

8.4)多维数据查询模块按照所述报表需求对应的查询定义，读取多维数据集生成用户需要的报表；或者，通过多维数据查询模块生成数据视图保存到中间数据库中，然后利用报表处理模块对表中字段加工计算后最终生成用户自定义报表。

按照本发明提供的增值业务分析方法，该方法这样按系统预先设定的需求生成标准报表，包括以下步骤：

9.1)用户根据行业规范提出报表需求并预设在系统中；

9.2)将报表指标对应到所述数据库中的多个表中相应的字段；

9.3)对涉及的数据库记录按应用场景需要的最小时间粒度进行汇总计算，并生成相应的汇总表；所述汇总表包括日报表、月报表和季报表，由调度模块按时间调度策略调度对应的报表任务。

按照本发明提供的增值业务分析方法，该方法还包括将所述日报导入所述数据库相应日表中，所述方法进一步在调度模块调度下以所述数据库中日表记录按系统预先设定的需求生成月或季度报表。

本发明提供的一种增值业务分析系统及其方法，使用数据预处理器汇总数据，在此基础上自动生成标准和自定义报表帮助用户快速发现业务性能瓶颈，从而有针对性地提出扩容和改进方案；进一步提高运营商对增值业务的管理监控能力。另外，①本系统通过多维数据查询模块，使系统具有钻取最大范围涵盖具体业务关键数据的多维业务数据集生成自定义报表的能力，从而使系统能够快速应对自定义报表的需求，极大地减少了用户开发自定义报表的工作量；②由于采用了日报表回存数据库的技术，使得在生成月报、季报、年报的时候，大大减少了需要处理的数据；③系统采用增量方式更新数据库，有效避免了系统在重负荷情况下出现宕机、数据处理失败等故障，增强了系统的鲁棒性。

附图说明

图1是本发明增值业务分析系统整体结构图。

图2是本发明增值业务分析系统业务分析子系统软件架构图。

图3是本发明业务分析子系统标准报表处理示意图。

图4是本发明业务分析子系统自定义报表处理示意图。

具体实施方式

首先，说明本发明增值业务分析系统的一种具体结构，如图1所示，包括分布在网络各处的若干短信处理设备1(包括短信中心SMSC、USSD中心、业务/互通网关、SP管理台等)、业务分析子系统服务器3和若干业务分析子系统客户终端4。

其次，说明本发明的关键技术：

(一)增量构建多维数据集：

由于短消息数量巨大，所以多维业务数据集的构建必须要采取增量的方式进行构建，也就是说，每天将新增的业务数据插入到数据集中，而不是每一次都重建数据集。增量更新必须要保证构建数据集的数据也是增量的，否则数据有可能多次进入多维数据集。本发明系统采取的具体的处理方法可以是首先建立该表的一个视图，利用WHERE的条件限制要处理的某一个时段，该时段根据应用场景的不同，可以是一天或者是几个小时。例如：在正常情况下，自动采集以一天为一个采集时段；在节假日模式下，自动采集以4个/2个小时为一个采集时段。通过为不同表定义不同的视图模版，结合下面第(三)条所述的节假日模式，就可以实现不同场景下的数据自适应采集。

(二)日报数据回存：

根据中国移动SMSC数据需求规范V2.0.0，短信处理设备/短信中心SMSC需要向局方用户提供短信处理设备/短信中心系统性能指标、短信信令负荷指标、国际短信业务指标等几十张报表。对于每一张报表局方除了需要日报外，还需要月报、季报、年报等。、报表中每一个指标都来自于短信中心提供的中间库中的原始数据表中的一个或者多个字段，这些表中的记录一般为一分钟一条记录、一天为1440条记录，一个月为43200条记录，一年约为518400条记录。

就日报处理而言，每天需要处理的数据记录约为15万条左右，这个数量并不算大。但是在作月报的时候，需要处理的数据记录就是450万条左右；作季报的时候，需要处理的数据记录就是1350完条；作年报的时候，需要面对的记录将会高达1.6亿条左右，因为系统每天还有大量的日常工作需要完成，这无疑将大大影响系统的处理能力。

月报/季报/年报中的统计指标和日报是一致的，唯一的区别在于：日报中的时间粒度较细，比方说，小时或者15分钟为一个统计粒度，而月报/季报/年报中，基本上以天为统计粒度。针对这种情况，在每天日报生成完成之后，自动调用日报回存处理模块将日报导入数据库中相应的日表中。在每月结束的时候，以日表中的记录为基础，来生成月报表。在这种情况下，即便是生成年报，需要处理的记录数也不过为几万条，在这种情况下，月报\季报\年报的定时生成对系统的处理能力基本上不会有冲击。

(三)节假日模式

短消息运维系统中面临的一个特殊情况就是：在节假日(包括春节、五一、十一、元旦、圣诞节、愚人节、以及平时周六、周日)的时候，短信流量往往比平时大很多，比方说：春节期间的前面几天，短信流量是平时的六倍。在这种场景下，平时以天为采集粒度来构建多维数据集市就显得太大，不仅会导致数据库性能下降，而且数据入库也会经常失败。而如果每一次都由值班人员手工调整采集粒度，则大大增加了维护人员的工作量和工作难度。为此，本系统提出了节假日模式来处理这种情况，在节假日模式中，用户可以指定采集粒度的大小(4小时、2小时、1小时、15分钟等)；。根据以往对流量的统计，维护人员可以定义出需要归入节假日模式进行处理的日期范围，并且本系统还细分了1～6(种类数量不限)种子模式。下面就是通过节假日工具产生的某省节假日定义文件：

<Feast>

<！--元旦-->

<！--春节-->

<！--五一劳动节-->

<！--十一国庆节-->

<！--肉孜节-->

…………

</Feast>

</Holiday>

</BusinessCalendar>

</project>

在该文件中，用户不但可以定义法定节日，还可以根据实际情况定义地方性节日(例如：肉孜节)。

最后，说明业务分析子系统的报表生成方法：

业务分析子系统2，架构如图2所示，包括多维数据集模块、调度模块22、报表处理模块23、多维数据查询模块24、日报回存处理模块25和数据预处理器26。其中，多维数据集模块将数据库记录构建为多维数据集21；调度模块22按照时间调度策略调度对应标准报表任务；报表处理模块23完成各种标准报表任务；多维数据查询模块24按照查询定义，读取多维数据集生成用户需要的报表；日报回存处理模块25将日报表中的数据导入数据库内相应的日表中；数据预处理器26统一原始业务数据的格式。具体报表生成方法包括标准报表和自定义报表生成方法，其中：

①标准报表生成，如图3所示，在这种处理方式下，中间数据库汇总表中字段组成的合集涵盖所有标准报表指标。由调度模块22每日调度触发报表处理模块23在中间数据库基础上自动生成日报，再由日报回存处理模块25将日报表中的数据导入数据库内相应的日表中；由调度模块22每月/季度调度触发报表处理模块23在日表的基础上自动生成月报/季报。

②自定义报表生成，如图4所示，在这种方式中，只要业务数据存在于多维数据业务集21中，用户5就可以通过多维数据查询模块24中的多维查询表达式钻取多维数据业务集21生成自定义报表6；多维数据业务集21设计为最大范围地涵盖关键业务数据，因此在多维数据业务集21中基本上可找到相关业务数据，而这些业务数据并没有全部存在于中间汇总表中。在图4中，对于通过多维数据查询定义无法直接满足用户报表需求的情况，可以先将查询定义得到的数据视图保存到中间数据库的相应表中，再通过报表处理模块23提供的报表工具对表中字段加工计算后最终生成用户自定义报表6，这种处理过程如图4中的虚线所示。

多维数据查询模块24中的多维数据查询定义文件定义了从多维数据业务集21中钻取报表所需要的全部信息，包括：源多维数据集所在的目录、名字、查询的方式，查询定义(包括查询的字符串、匹配方式、维度名称等)，以及查询结果插入报表中的位置等信息，举例说明如下：

<？xml version＝″1.0″encoding＝″GB2312″？>

<job name＝″cubeToReport″cubeName＝″梦网短信分析″

cubePath＝″$run.cube.dir″>

<ReportQueries add＝″3″>//代表高级查询模式

<objFind Name＝″SP流量分析″searchText＝″903″pattern＝″2″

dimension＝″SP代码″searchShortName＝″False″/>

<AddToReport insertItem＝″1″insertPoint＝″1″

levelAction＝″3″/>

<publish outputDir＝″$run.report.dir″interactive＝″flase″

allLayers＝″true″format＝″xls″/>

</job>

searchText＝″903″，代表查询包含903的SP代码；pattern＝″2″表示是字符串开头包含方式；dimension＝″SP代码″表示查询的维度名称；cubeName＝″梦网短信分析″表示分析主题的名字；outputDir＝″$run.report.dir″表示报表输出的路径.

Claims

1.一种增值业务分析系统，其特征在于，包括若干数据采集子系统、若干数据预处理器和业务分析子系统(2)，其中：

(一)数据采集子系统：采集网络中各短信处理设备(1)的原始业务数据；

(二)数据预处理器(26)：与所述数据采集子系统一一对应，将所述原始业务数据转换成统一格式的业务数据；

(三)业务分析子系统(2)：由客户端(4)和服务器(3)构成，其中服务器(3)端将所述统一格式的业务数据汇总存储在一个或一个以上数据库中，并根据所述数据库按用户自定义或者系统预先设定的需求生成报表。

2.根据权利要求1所述增值业务分析系统，其特征在于，所述数据预处理器(26)是独立存在的设备。

3.根据权利要求1所述增值业务分析系统，其特征在于，所述数据预处理器(26)内置在所述数据采集子系统中。

4.根据权利要求1所述增值业务分析系统，其特征在于，所述数据预处理器(26)内置在所述业务分析子系统中。

5.根据权利要求4所述增值业务分析系统，其特征在于，所述业务分析子系统(2)还包括多维数据集模块、多维数据查询模块(24)、日报回存处理模块(25)、报表处理模块(23)、调度模块(22)，其中：多维数据集模块将数据库记录构建为多维数据集；

(一)多维数据查询模块(24)：按用户自定义需求对应的查询定义，读取多维数据集(21)生成用户自定义报表(6)；或者，多维数据查询模块(24)生成数据视图保存到所述数据库中，然后利用报表处理模块(23)对表中字段加工计算后最终生成用户自定义报表(6)；

(二)日报回存处理模块(25)：将日报导入所述数据库中相应的日表中；

(三)报表处理模块(23)：按系统预先设定的需求生成报表；

(四)调度模块(22)：按时间调度策略自动控制执行所述报表处理模块任务。

6.一种增值业务分析方法，其特征在于，包括以下步骤：

6.1)通过数据采集子系统获取与其一一对应的网络中各短信处理设备(1)的原始业务数据；

6.2)通过数据预处理器(26)将各所述原始业务数据转换成统一格式的业务数据；

6.3)在业务分析子系统服务器(3)端上将所述统一格式的业务数据汇总成一个或一个以上数据库储存，并根据所述数据库按用户自定义或者系统预先设定的需求生成报表。

7.根据权利要求6所述增值业务分析方法，其特征在于，所述汇总是增量汇总。

8.根据权利要求7所述增值业务分析方法，其特征在于，所述增量汇总以可变时间段为采集粒度，节假日对应的所述时间段小于平时对应的所述时间段。

9.根据权利要求6所述增值业务分析方法，其特征在于，该增值业务分析方法这样按用户(5)自定义需求生成自定义报表(6)，包括以下步骤：

9.1)用户(5)通过客户终端人机界面根据自身实际需求提出报表需求；

9.2)将报表需求对应到所述数据库中的多个表中相应的字段；

9.3)通过多维数据集模块将涉及的数据库记录构建为多维数据集(21)；

9.4)多维数据查询模块(24)按照所述报表需求对应的查询定义，读取多维数据集(21)生成用户自定义报表(6)；或者，通过多维数据查询模块(24)生成数据视图保存到所述数据库中，然后利用报表处理模块(23)对表中字段加工计算后最终生成用户自定义报表(6).

10.根据权利要求6所述增值业务分析方法，其特征在于，该增值业务分析方法这样按系统预先设定的需求生成标准报表，包括以下步骤：

10.1)用户根据行业规范提出报表需求并预设在系统中；

10.2)将报表需求对应到所述数据库中的多个表中相应的字段；

10.3)对涉及的数据库记录按应用场景需要的最小时间粒度进行汇总计算，并生成相应的标准报表；所述标准报表包括日报表、月报表和季报表，由调度模块(22)按时间调度策略调度完成对应的报表任务。

11.根据权利要求10所述增值业务分析方法，其特征在于，该增值业务分析方法还包括将所述日报导入所述数据库相应日表中，所述方法进一步包括在调度模块(22)调度下以所述数据库中日表记录按系统预先设定的需求生成月或季度报表。