CN102831168A

CN102831168A - 一种kpi指标的计算方法及装置

Info

Publication number: CN102831168A
Application number: CN201210258711XA
Authority: CN
Inventors: 张百全; 高利虹
Original assignee: Datang Mobile Communications Equipment Co Ltd
Current assignee: Datang Mobile Communications Equipment Co Ltd
Priority date: 2012-07-24
Filing date: 2012-07-24
Publication date: 2012-12-19
Anticipated expiration: 2032-07-24
Also published as: CN102831168B

Abstract

本发明涉及数据库技术领域，公开了一种KPI指标的计算方法及装置。该方法为：后台装置预先基于在预设的数据提取粒度内收集的原始数据预先生成的相应的基础指标和中间指标并保存至ORACLE数据库中，以及在接收用户发送的KPI指标提取请求后，直接从ORACLE数据库中获取所需的基础指标和/或中间指标生成相应的KPI指标。这样，便简化了KPI指标的提取算法，节省了大量时间和资源的，从而有效提高了KPI指标的提取效率。

Description

一种KPI指标的计算方法及装置

技术领域

本发明涉及数据库技术领域，特别涉及一种KPI指标的计算方法及装置。

背景技术

在基于ORACLE（甲骨文）的信息管理系统中，对各类KPI（KeyPerformance Indicator，关键绩效指标）进行统计是日常工作中的重要一环。KPI指示是由原始数据组成的，各类原始数据的采集通过计数器的方式实现。

通常情况下，不同类的原始数据保存在不同的数据表中，在进行KPI指标统计时，先通过各数据表中的计数器采集各类原始数据，然后再通过预设的方式对各类原始数据进行汇总，从而形成指定的KPI指标，最后，再以excel的方式展现给用户。

然而，现有技术下，在提取KPI指标的时候，往往会由于以下种种原因，造成KPI指标统计效率低下：

1、数据量过大。

每张数据表中记录的数据量均达到亿级别。

2、KPI指示形成所参考的原始数据过多。

3、KPI指示形成所需参考的原始数据通常分别保存在不同数据表中，这样，在查询时往往需要从不同的数据表里面读取不同的计数器的记录结果。

4、在ORACLE数据库中获取原始数据以后，需要调用到JAVA内存中进行计算。

从上述几点原因可以看出，现有的KPI指标提取流程主要存在以下缺点：

1、现有数据的大部分计算是在JAVA内存中进行的，这样容易在计算过程中占用大量的JAVA资源，再加上JAVA程序本身在数据处理方面的缺陷，就更容易造成大量时间和资源的浪费。

例如，在JAVA内存计算时计算缓慢，从而导致KPI指标提取缓慢或者导致计算卡死从而KPI指标无法提取的情况发生。

2、算法设计不合理。现有的算法是在提取数据表中的原始数据的时候才计算KPI指标。这样，如果用户提取的KPI指标较大较多时，就会造成在KPI指标计算缓慢，计算效率低下。

3、KPI计算流程过于复杂，致使计算量过于庞大。

发明内容

本发明实施例提供一种KPI指标的计算方法及装置，用以提高KPI指标的计算效率。

本发明实施例提供的具体技术方案如下：

一种KPI的计算方法，包括：

后台装置接收用户发送的KPI指标提取请求；

后台装置在ORACLE数据库中获取生成所述KPI指标所需的基础指标和/或中间指标，其中，所述基础指标和中间指标均是后台装置基于在预设的数据提取粒度内收集的原始数据预先生成的；

后台装置基于获得的基础指标和/或中间指标生成相应的KPI指标。

一种KPI的计算装置，包括：

配置单元，用于基于在预设的数据提取粒度内收集的原始数据预先生成的基础指标和中间指标，并保存至ORACLE数据库中；

通信单元，用于接收用户发送的KPI指标提取请求；

获取单元，用于在ORACLE数据库中获取生成所述KPI指标所需的基础指标和/或中间指标，

生成单元，用于基于获得的基础指标和/或中间指标生成相应的KPI指标。

本发明实施例中，后台装置预先基于在预设的数据提取粒度内收集的原始数据预先生成的相应的基础指标和中间指标并保存至ORACLE数据库中，以及在接收用户发送的KPI指标提取请求后，直接从ORACLE数据库中获取所需的基础指标和/或中间指标生成相应的KPI指标。这样，便简化了KPI指标的提取算法，节省了大量时间和资源的，从而有效提高了KPI指标的提取效率。

附图说明

图1A为本发明实施例中前后台装置关系示意图；

图1B为本发明实施例中后台装置功能结构示意图；

图2为本发明实施例中基础指标计算流程图；

图3为本发明实施例中小时指标计算流程图；

图4为本发明实施例中天指标计算流程图；

图5为本发明实施例中基础指标补采流程图；

图6为本发明实施例中小时指标补采流程图；

图7为本发明实施例中天指标补采流程图；

图8为本发明实施例中KPI指标计算流程图；

图9－11为本发明实施例中KPI指标呈现示意图。

具体实施方式

在移动网络网管系统中，为了提高数据表中原始数据的提取效率，加快KPI指标的计算速度，本发明实施例中，后台装置预先基于在预设的数据提取粒度内收集的原始数据预先生成的相应的基础指标和中间指标并保存至ORACLE数据库中，以及在接收用户发送的KPI指标提取请求后，直接从ORACLE数据库中获取生成KPI指标所需的基础指标和/或中间指标，并基于获得的基础指标和/或中间指标生成相应的KPI指标。这样，便针对网管系统中存在的由于数据量巨大而造成报表提取缓慢的问题给出了有效的解决方案，并且也提高了KPI指标的质量分析效率，填补了该领域的空白。

下面结合附图对本发明优选的实施方式进行详细。

现有技术下，由于移动网络比较大，造成数据量比较大，再加上业务逻辑比较复杂，造成生成KPI指标所定义的公式比较复杂；因而在查询生成KPI指标所需要的原始数据时需要从不同的数据表中获取，提取速度缓慢，严重影响移动网络指标分析，从而对综合分析移动网络质量造成了一定的障碍。

为了避免上述问题，本发明实施例中，重新设计系统模式：

1、移植计算容器：原有的计算基本放在JAVA内存中计算，而JAVA在大数据量的处理方面的缺陷被无限放大，造成了JAVA计算过程中严重资源不足的情况。

针对这种情况，参阅图1A所示，本发明实施例中，将所有的计算都放到ORACLE后台计算，JAVA程序只承担用户呈现的职责。即前台装置只用于接收用户的查询指令和向用户呈现KPI指标，而后台装置负责查询原始数据，以及基于原始数据生成KPI指标。

2、算法设计：采取对KPI指标做预处理的方式，在前期先基于原始数据生成基础指标，然后对基础指标进行汇总，形成各个级别的中间指标的集合，如，小时指标集合、日指标集合、月指标集合；待用户指标KPI指标的时候，按照用户的需求，从不同的指标集合里面讨取所需中间指标数据从而生成所需的KPI指标，并将其呈现给用户，从而减少在数据表提取过程中的计算量。

参阅图1B所示，本发明实施例中，后台装置包括配置单元10、通信单元11、获取单元12和生成单元13，其中，

配置单元10，用于基于在预设的数据提取粒度内收集的原始数据预先生成的基础指标和中间指标，并保存至ORACLE数据库中；

通信单元11，用于接收用户发送的KPI指标提取请求；

获取单元12，用于在ORACLE数据库中获取生成KPI指标所需的基础指标和/或中间指标，

生成单元13，用于基于获得的基础指标和/或中间指标生成相应的KPI指标。

本发明实施例中，在对原始数据进行预处理时，可以采用以下方式：

参阅图2所示，基于原始数据生成基础指标的流程如下：

步骤200：后台装置判断数据提取粒度是否已经存在，若是，则进行步骤220；否则，进行步骤230。

本实施例中。较佳的，将数据提取粒度设置为15分钟，即以15分钟为间隔收集上报的原始数据，当15分钟到达后，若确定这15分钟内需要收集的各类原始数据已由数据采集端上报完毕，则开始基于这15分钟采集的原始数据生成相应的基础指标。这样，便以15分钟为粒度连续地生成基础指标，

步骤210：后台装置将数据提取粒度的状态标识修改为已计算。

每个数据提取粒度均对应设置有相应的状态标识，在生成基础指标后，需要将对应的数据提取粒度的状态标识修改为“已计算”。

步骤220：后台装置根据在数据提取粒度中获得的原始数据计算基础指标，并保存至数据库中。

本实施例中，后台装置生成的基础指标可以有很多种类，如按照级别划分可以划分为：小区基础指标、NodeB基础指标、载波基础指标和RNC（Radio Network Controller，无线网络控制器）基础指标。

在生成基础指标后，后台装置可以根据配置信息，基于生成的基础指标进一步生成若干中间指标，中间指标有很多种类，本实施例中，以小时指标和天指标为例。

步骤230：后台装置返回继续等待。

参阅图3所示，本发明实施例中，小时指标的生成流程如下：

步骤300：后台装置判断小时单位内的数据提取粒度为4？若是，则进行步骤310；否则，进行步骤330。

本发明实施例中，由于数据提取粒度设置为15分钟，因此，在小时单位内，需要判断是否数据提取粒度已为4。

步骤310：后台装置将小时单位的状态标识修改为已计算。

步骤320：后台装置计算小时单位对应的中间指标并存入小时单位对应的数据表。

实际应用中，每个小时单位均对应一张数据表，后台装置在计算每个小时单位对应的小时指标时，根据在每个小时内的各个数据提取粒度中收集的原始数据计算相应的小时指标。

步骤330：后台装置将小时单位对应的已存在的数据提取粒度的状态标识修改为已计算。

在这种情况下，后台装置在小时单位内没有收集到所有数据提取粒度的原始数据，因此，只将已原始数据收集完毕的数据提取粒度的状态标识修改为已计算。

步骤340：后台装置将小时单位的计算开始时间和计算结束时间插入小时单位对应的数据表的补采表中。

这样处理是因为，在小时单位内，未将所有数据提取粒度内的原始数据收集完毕，因此，需要在全部数据提取粒度的原始数据收集完毕时，再重新计算这个时间单位的小时指标，而此时，只能先基于已获得的数据提取粒度内的原始数据计算一个临时的小时指标，后续在补采表中再进行补充。

步骤350：后台装置根据已经存在的数据提取粒度对应的原始数据计算小时单位对应的中间指标并存储至小时单位对应的数据表中。

此时，在数据表中保存的只是根据部分数据提取粒度内采集的原始数据计算获得的小时指标，需要在后续流程中作进一步完善，这一点将在后续流程中进行阐述。

参阅图4所示，本发明实施例中，天指标的生成流程如下：

步骤400：后台装置判断天单位内的数据提取粒度为4×24？若是，则进行步骤410；否则，进行步骤430。

本发明实施例中，由于数据提取粒度设置为15分钟，因此，在天单位内，需要判断是否数据提取粒度已为4×24。

步骤410：后台装置将天单位的状态标识修改为已计算。

步骤420：后台装置计算天单位对应的中间指标并存入天单位对应的数据表。

实际应用中，每个天单位均对应一张数据表，后台装置在计算每个天单位对应的天指标时，根据在每一天内的各个数据提取粒度中收集的原始数据计算相应的天指标。

步骤430：后台装置将天单位对应的已存在的数据提取粒度的状态标识修改为已计算。

在这种情况下，后台装置在天单位内没有收集到所有数据提取粒度的原始数据，因此，只将已原始数据收集完毕的数据提取粒度的状态标识修改为已计算。

步骤440：后台装置将天单位的计算开始时间和计算结束时间插入天单位对应的数据表的补采表中。

这样处理是因为，在天单位内，未将所有数据提取粒度内的原始数据收集完毕，因此，需要在全部数据提取粒度的原始数据收集完毕时，再重新计算这个天单位的天指标，而此时，只能先基于已获得的数据提取粒度内的原始数据计算一个临时的天指标，后续在补采表中再进行补充。

步骤450：后台装置根据已经存在的数据提取粒度对应的原始数据计算天单位对应的中间指标并存储至天单位对应的数据表中。

此时，在数据表中保存的只是根据部分数据提取粒度内采集的原始数据计算获得的天指标，需要在后续流程中作进一步完善，这一点将在后续流程中进行阐述。

基于上述各实施例，下面对基础指标以及各中间指标的补采流程进行详细介绍。

参阅图5所示，本发明实施例中，基础指标的补采流程如下：

步骤500：后台装置判断是否存在缺失的数据提取粒度，若是，则进行步骤510；否则，进行步骤520。

步骤510：后台装置按照缺失的数据提取粒度和收集到的相应的原始数据计算基础指标并重新保存至数据库中。

步骤520：后台装置返回继续等待。

参阅图6所示，本发明实施例中，以任意一小时为例，对应的小时指标的补采流程如下：

步骤600：后台装置判断小时中是否有缺失的数据提取粒度，若是，则进行步骤610；否则，进行步骤630。

步骤610：后台装置判断小时中缺失的数据提取粒度对应的原始数据是否已经上报齐全？若是，则进行步骤620；否则，进行步骤630。

步骤620：后台装置根据已上报齐全的原始数据计算小时对应的小时指标，并替换数据库中原有的小时指标。

在执行补采流程之前，小对对应的小时指标是基于未上报齐全的原始数据生成的（可能缺失某个数据提取粒度），因而并不全面，因此，在等待原先缺失的数据提取粒度对应的原始数据上报齐全后，要重新生成小时指标。

步骤630：后台装置返回继续等待。

参阅图7所示，本发明实施例中，以任意一小时为例，对应的小时指标的补采流程如下：

步骤700：后台装置判断小时中是否有缺失的数据提取粒度，若是，则进行步骤710；否则，进行步骤730。

步骤710：后台装置判断小时中缺失的数据提取粒度对应的原始数据是否已经上报齐全？若是，则进行步骤720；否则，进行步骤730。

步骤720：后台装置修改天指标的状态标识为已计算。

步骤730：后台装置根据已上报齐全的原始数据计算天对应的天指标，并替换数据库中原有的天指标。

在执行补采流程之前，天对应的天指标是基于未上报齐全的原始数据生成的（可能缺失某个数据提取粒度），因而并不全面，因此，在等待原先缺失的数据提取粒度对应的原始数据上报齐全后，要重新生成天指标。

步骤740：后台装置返回继续等待。

基于上述各实施例，参阅图8所示，本发明实施例中，后台设置生成KPI指标的详细流程如下：

步骤800：后台设置接收用户发送的KPI指标提取请求。

具体为：后台装置接收前台装置转发的用户输入的KPI指标提取请求，这是因为，本发明实施例中，KPI指标的计算位置由JAVA内存转入后台，这样，不会给前台装置带来运行负荷。

后台装置可以根据KPI指标提取请求中携带的KPI指标的标识确定用户需要哪种类型的KPI指标。

步骤810：后台装置在ORACLE数据库中获取生成上述KPI指标所需的基础指标和/或中间指标，其中，基础指标和中间指标均是后台装置基于在预设的数据提取粒度内收集的原始数据预先生成的。

本实施例中，后台装置确定用户需要提取的KPI指标后，确定生成KIP指标所需的基础指标和/或中间指标，由于在预处理过程中，已按照预设的数据提取粒度预先生成了各个基础指标及中间指标，因此，在执行步骤810时，后台装置直接读取所需的基础指标和/或中间指标即可，节省了大量的操作时间。

其中，步骤810的具体操作流程已在之前的实施例中进行了介绍：

例如，后台装置分别基于在每一个数据提取粒度内收集的原始数据，生成相应的基础指标，并保存至ORACLE数据库中，以及在判定存在缺失的数据提取粒度时，待缺失的数据提取粒度对应的原始数据收集完毕后，再基于获得的原始数据生成相应的基础指标，并保存至ORACLE数据库中。

又例如：后台装置分别基于在每一个预设的数据提取粒度集合内收集的原始数据，生成相应的中间指标，并保存至ORACLE数据库中，以及在判定任意一数据提取粒度集合内存在缺失的数据提取粒度时，先基于当前在该数据提取粒度集合内已收集完毕的原始数据生成相应的第一中间指标，并保存至ORACLE数据库中，待缺失的数据提取粒度内的原始数据收集完毕后，再基于在该数据提取粒度集合内获得的全部原始数据生成相应的第二中间指标，并对ORACLE数据库中保存的第一中间指标进行更新。

在此不再作进一步赘述。

步骤820：后台装置基于获得的基础指标和/或中间指标生成相应的KPI指标。

例如，假设所需获得的KPI指标为：电路域系统间切换出成功率〔由TD（Time Division，时分）制式切换至GPRS（General Packet Radio Service，通用分组无线业务）〕，则需要先计算电路域系统间切换出成功次数和电路域系统间切换出成功请求次数，再根据这两个基础指标计算出电路域系统间切换出成功率。如，电路域系统间切换出成功率（TD->GPRS）＝100*(((R008_289)-(R008_290))/(R008_289))

又例如，假设所需获得的KPI指标为：RNC（Radio Network Controller，无线网络控制器）间CS（Circuit Switched，电路开关）硬切换出成功率，则RNC间CS硬切换出成功率＝100*(R020_023)/(R020_001)。

另一方面，本发明实施例中，后台装置在ORACLE数据库生成KPI指标后，可以采用拆线图、柱状图或者饼状图的形式将该KPI指标呈现给用户。

具体为：后台装置在ORACLE数据库中增加对现有KPI指标的多维报表分析系统功能，从而形成一个KPI指标的多维分析系统，以直观的方式给用户展现KPI指标。

例如，参阅图9所示，后台装置可以提取KPI指标的最近7天的统计数据，按天进行汇总，在前台装置界面上以折线图或柱状图的方式呈现出来。

又例如，参阅图10所示，后台装置可以提取KPI指标最近1天的统计数据，按小时进行汇总，在前台装置界面上以折线图或柱状图的方式呈现出来。

又例如，参阅图11所示，后台装置还可以在前台装置界面上将KPI指标以饼状图的方式呈现出来。

综上所述，本发明实施例中，后台装置预先基于在预设的数据提取粒度内收集的原始数据预先生成的相应的基础指标和中间指标并保存至ORACLE数据库中，以及在接收用户发送的KPI指标提取请求后，直接从ORACLE数据库中获取所需的基础指标和/或中间指标生成相应的KPI指标。这样，便简化了KPI指标的提取算法，节省了大量时间和资源的，从而有效提高了KPI指标的提取效率。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种关键绩效指标KPI的计算方法，其特征在于，包括：

后台装置接收用户发送的KPI指标提取请求；

后台装置在甲骨文ORACLE数据库中获取生成所述KPI指标所需的基础指标和/或中间指标，其中，所述基础指标和中间指标均是后台装置基于在预设的数据提取粒度内收集的原始数据预先生成的；

2.如权利要求1所述的方法，其特征在于，所述后台装置基于在预设的数据提取粒度内收集的原始数据生成基础指标，包括：

后台装置分别基于在每一个数据提取粒度内收集的原始数据，生成相应的基础指标，并保存至ORACLE数据库中。

3.如权利要求2所述的方法，其特征在于，后台装置判定存在缺失的数据提取粒度时，待缺失的数据提取粒度对应的原始数据收集完毕后，再基于获得的原始数据生成相应的基础指标，并保存至ORACLE数据库中。

4.如权利要求1所述的方法，其特征在于，后台装置基于在预设的数据提取粒度内收集的原始数据生成中间指标，包括：

后台装置分别基于在每一个预设的数据提取粒度集合内收集的原始数据，生成相应的中间指标，并保存至ORACLE数据库中。

5.如权利要求4所述的方法，其特征在于，后台装置判定任意一数据提取粒度集合内存在缺失的数据提取粒度时，先基于当前在所述数据提取粒度集合内已收集完毕的原始数据生成相应的第一中间指标，并保存至ORACLE数据库中，待所述缺失的数据提取粒度内的原始数据收集完毕后，再基于在所述数据提取粒度集合内获得的全部原始数据生成相应的第二中间指标，并对ORACLE数据库中保存的第一中间指标进行更新。

6.如权利要求2-5任一项所述的方法，其特征在于，后台装置基于在ORACLE数据库中获得的基础指标和/或中间指标生成相应的KPI指标后，通过前台装置采用拆线图、柱状图或者饼状图的形式将所述KPI指标呈现给用户。

7.一种关键绩效指标KPI的计算装置，其特征在于，包括：

配置单元，用于基于在预设的数据提取粒度内收集的原始数据预先生成的基础指标和中间指标，并保存至甲骨文ORACLE数据库中；

通信单元，用于接收用户发送的KPI指标提取请求；

8.如权利要求7所述的装置，其特征在于，所述配置单元基于在预设的数据提取粒度内收集的原始数据生成基础指标时，分别基于在每一个数据提取粒度内收集的原始数据，生成相应的基础指标，并保存至ORACLE数据库中。

9.如权利要求8所述的装置，其特征在于，所述配置单元判定存在缺失的数据提取粒度时，待缺失的数据提取粒度对应的原始数据收集完毕后，再基于获得的原始数据生成相应的基础指标，并保存至ORACLE数据库中。

10.如权利要求7所述的装置，其特征在于，所述配置单元基于在预设的数据提取粒度内收集的原始数据生成中间指标时，分别基于在每一个预设的数据提取粒度集合内收集的原始数据，生成相应的中间指标，并保存至ORACLE数据库中。

11.如权利要求10所述的装置，其特征在于，所述配置单元判定任意一数据提取粒度集合内存在缺失的数据提取粒度时，先基于当前在所述数据提取粒度集合内已收集完毕的原始数据生成相应的第一中间指标，并保存至ORACLE数据库中，待所述缺失的数据提取粒度内的原始数据收集完毕后，再基于在所述数据提取粒度集合内获得的全部原始数据生成相应的第二中间指标，并对ORACLE数据库中保存的第一中间指标进行更新。

12.如权利要求8-11任一项所述的装置，其特征在于，所述生成单元基于在ORACLE数据库中获得的基础指标和/或中间指标生成相应的KPI指标后，所述通信单元通过前台装置采用拆线图、柱状图或者饼状图的形式将所述KPI指标呈现给用户。