基于电信大数据的数据建模平台研究

2014-09-29沈雷明别志铭

电信科学 2014年6期

沈雷明，别志铭

（1.中国移动通信集团上海有限公司上海 200060；2.珠海世纪鼎利通信科技股份有限公司珠海 519085）

1 电信行业大数据的需求

伴随电信行业3G/4G等业务的增加，数据量出现爆炸式增长，数据的规模已经超过TB，达到PB级别。海量数据导致电信运营商的数据处理和存储压力急剧变大，而传统的数据库和数据仓库越来越无法满足电信行业的需求。许多电信运营商开始关注Hadoop技术，但是电信运营商自身组织结构复杂，产品和业务种类繁多，并且Hadoop技术也在快速发展。如何能统一、快速地满足不同业务的不同需求？这个难题摆在所有人的面前。

2 电信领域大数据的特点

（1）电信用户数据量大

电信行业是个垄断行业，每个国家通常只有3家或4家电信运营商，这样就导致了很多运营商拥有超过一亿的用户。

（2）用户产生的数据量大

电信用户每天都要接打电话，通过3G/4G使用互联网，即使用户只是把手机连接到电信的网络中，都会产生类似位置更新等数据。每个用户每时每刻都在产生数据，一亿用户汇聚起来，数据量非常庞大。

（3）用户产生的数据多样性

电信用户打电话、发短信、使用互联网等，还有客户的位置、在线状态等，每种数据结构都不一样，内容也不一样，其中有结构化的数据，也有非结构化的数据，非常复杂。

3 Hadoopdesigner系统设计

本文介绍了Hadoopdesigner系统，它是基于Hadoop的数据建模平台。该系统根据电信业务系统的特点，提取出类似 counter、KPI（key performance indicator，关键绩效指标）等这样的专业电信行业模型，是为电信行业的大数据建模量身打造的。Hadoopdesigner系统总体结构如图1所示。

其总体结构是由模型处理、模型对象管理、智能服务等模块构成。

3.1 模型处理

模型处理包括的功能有模型建立、模型智能评估和模型运行监控。每个功能模块的具体介绍如下。

（1）模型建立

建模人员拿到应用的需求后，把需求中的具体业务分解成系统里面的实体对象。整个建模中，一般需要经历4个过程。

·业务模型建模。它主要解决业务层面的分解和程序化。

·专业领域建模。它主要是对业务模型进行抽象处理，生成专业的领域概念模型。

·逻辑建模。它主要是将专业领域模型的概念实体以及实体之间的关系进行逻辑化。

·物理建模。它主要解决如逻辑模型对不同实体的物

理化及性能等一些具体的技术问题。

其中逻辑模型和物理模型由Hadoopdesigner系统根据业务模型和专业领域的模型自动生成。建模人员只需要对业务模型和专业领域的模型进行设计。

（2）模型智能评估

常有的数据建模有范式建模法、维度建模法、实体建模法等。对于电信的信令分析应用来说，一般采用维度建模法。针对各个维度作大量的预处理，如按照维度进行预先的统计、分类等。通过这些预处理，能够极大地提升系统的处理能力。Hadoopdesigner系统就是通过可视化的界面，辅助建模人员使用维度建模法实现应用，并且对设计的模型进行专业的智能评估和分析，给出分析报告。

（3）模型运行监控

业务和数据建模是个复杂的过程，对于复杂的应用，不可能一下子就能设计出非常合适的模型，需要对模型运行过程进行监控，及时地发现问题和解决问题，以完成对模型的持续优化。

3.2 模型对象管理

建模人员在业务模型建模和专业领域建模后，会从复杂的应用中提取出实体、事件、说明、关系等抽象的对象，再通过Hadoopdesigner系统的可视化界面，建模人员把抽象对象配置到系统中，就完成了整个应用建模过程的第一个阶段。剩下的任务就是根据模型运行的情况，调整、优化模型。目前Hadoopdesigner系统支持的常用模型有以下几个类型。

（1）数据源模型

目前数据的来源主要是通过FTP传输过来的文件。文件格式一般是csv。从应用角度出发，数据可分为CS、PS等，它们的数据字段信息等是不同的。因此需要根据不同的应用描述不同数据来源的信息，统一数据读取接口。Hadoopdesigner系统提供一些常用的数据源定义模板，在导入后，直接修改便可以使用。

（2）ETL 模型

定义好数据的来源后，数据就会源源不断地通过入云程序把数据导入Hadoop中。在数据真正入云前，需要定义数据 ETL（extract,transform and load）的规则和模型，对数据进行清洗、转换和集成以及提供数据入云的速率、数据错误率等数据质量报告等。对于常用ETL规则，Hadoopdesigner系统也提供一些模板，方便用户直接使用。

（3）counter模型

counter模型是系统定义单一维度的统计汇总模型。它是系统里面非常重要的模型，是维度建模法的基础。系统可以通过定义的counter模型，对需要统计分类的维度进行预处理和优化。counter模型根据数据所处的位置分类，可以分为两类：一是云外counter模型，主要定义在数据入云的同时，对单个维度的汇总统计；二是云内counter模型，主要是定义在Hadoop里面，对单个维度的汇总统计。通过两种类型的counter模型，可以充分利用系统的基础和存储能力，大大提高以后应用汇总统计的速度和能力。比如定义通话中的主叫成功次数、主叫失败次数等，都可以定义为counter模型。不同的行业可以定义不同的counter库。针对电信的信令分析行业，笔者建立了counter模型库，提供了常用的几百个counter对象。

（4）KPI模型

counter模型相当于单个实体，KPI模型就是通过各种运算符等关系，连接多个不同实体，组成一个新的KPI模型。比如计算通话总次数这个KPI，就可以通过定义的通话成功counter模型加上定义的通话失败counter模型，构成通话总次数的KPI模型。在实际的应用中，KPI模型会经常被引用，并且不同的KPI可以直接相互地引用。例如需要定义通话成功率的KPI模型，就可以通过定义的通话成功counter模型加上定义的通话总次数的KPI对象，构成通话成功率的KPI模型。针对电信的信令分析行业的常用KPI模型，Hadoopdesigner系统也定义了上百个KPI模型，方便用户组建模的时候调用。

（5）数据聚合模型

在对数据进行汇总统计的时候，需要指定对某个维度进行聚合。通过数据聚合的模型，可以很简单地从上面定义的数据源模型的维度里，任意挑选一个维度进行处理，然后再从下拉框中选择一个对这个维度聚合的算法。

聚合的算法常有两类：一是对时间的聚合算法，对某个时间维度进行不同时间段的聚合，如15 min、30 min、1 h等聚合；二是通过特定的算法，把维度从细粒度变成粗粒度，如从信令中基站控制器的维度汇总到移动交换中心的维度。数据聚合模型需要根据具体的行业需求，开发出不同聚合算法的组件。

（6）数据分组模型

上述模型定义完成后，通常需要对数据进行分组和分类统计汇总等。数据分组模型就是用来实现数据分组和分类的模型。系统会根据数据源的模型，取出相关的分组维度，提供单选和多选、排序等方式方便用户选择需要的维度。

（7）静态数据模型

在实际应用中，静态数据的使用是不可避免的。因此对静态数据的管理和建模也是很重要的。在信令分析应用中，如手机终端的静态信息会经常被使用。但是静态数据不一定就是固定不变的数据，只是该数据变化和更新较少，实际上还是需要对静态数据进行增删改等操作。静态数据模型按关联的位置可以分为两种：一是在数据的分析阶段关联的静态数据，对于Hadoop来说，就是在MapReduce的map阶段关联的静态数据，如分析某个特定型号的手机的通话次数，需要通过TAC号来关联终端型号的静态数据；二是在汇总阶段的关联静态表，对于Hadoop来说，即是MapReduce的redcue阶段关联的静态数据，如分析所有不同型号的手机的通话次数，需要按TAC汇总后，再通过TAC号关联终端型号的静态数据，当然这个例子也可以在map阶段汇总，但是考虑到性能内存等问题，最好是在汇总后进行关联。

（8）对象集合模型

Hadoopdesigner系统支持按星型模式或雪花模式来设计。上述模型都是周围的“小星星”或“小雪花”，那么结构的中心实体就是对象集合模型，是用户最关心的基本实体和查询活动的中心，为Hadoop的活动提供定量数据。它用来集合和引用上面各种模型和对象，组成一个实际的应用。为了方便用户的建模，Hadoopdesigner系统扩展对象集合模型面向对象的设计，主要表现在以下两个方面。

·支持多个对象的继承关系。如A对象集合模型使用了通话成功次数的counter模型，B对象集合模型使用了通话失败次数的counter模型，当C对象集合模型同时需要使用通话成功和失败次数的counter模型时，就可以定义C从A和B继承过来。

·重载的功能。如A对象集合模型使用了通话成功次数的counter模型，定义数据源模型是来自BSSAP对象，B对象集合模型也是使用了通话成功次数的counter模型，但是数据源来自RANAP对象。只需要定义B对象集合模型从A对象集合模型继承，同时把数据源重新定义覆盖即可。

（9）调度模型

在海量数据的分析中，做一次汇总统计是一个漫长的过程，快则半小时，慢则需要几个小时。因此在很多的实际应用中，都需要定时来调度运行应用。Hadoopdesigner系统调度的最大特点在于能实现智能调度。它根据批量处理的多个模型的优先级别运行模型。若系统不忙时，优先等级比较低的模型可以运行；若系统忙时，根据系统的负荷选择运行等级高的模型。