4G移动用户端到端业务清单关联算法研究及实现

［宫云平 郑博 许群路］

4G移动用户端到端业务清单关联算法研究及实现

［宫云平 郑博 许群路］

随着4G网络的全面部署和4G用户的爆发增长，4G用户感知提升成为电信运营商最主要的网络优化工作，尤其是室内4G用户感知评估和提升，由于室内无线环境复杂、干扰因素多等，更是一直困扰运营商网优部门的难题。传统的室内用户质量提升主要从无线侧入手，侧重于提高无线侧的网络质量，而对于用户的业务行为特点关注较少，往往会造成网络的KPI指标和用户的业务感知脱节的情况。本文则从用户端到端的业务感知出发，运用大数据处理技术，形成从终端到云端，贯穿无线、承载、核心网、SP的，端到端的，用户级的业务清单，为全网用户端到端网络质量评估分析和室内深层覆盖质差优化提供基础和前提。

4G 端到端 关联算法

宫云平

中国电信股份有限公司广州研究院，毕业于重庆邮电学院，本科，就职于中国电信股份有限公司广州研究院，高级工程师，从事运营商大数据技术研究及数据应用产品开发工作。

郑博

中国电信股份有限公司广东分公司，毕业于华南理工大学，硕士研究生，就职于中国电信股份有限公司广东分公司网络运营部，主要研究方向为网络运营支撑系统建设。

许群路

中国电信股份有限公司广东分公司，就职于中国电信股份有限公司广东分公司网络运营部，主要研究方向为网络运营支撑系统建设。

1 背景及目的

在当前4G网络大规模部署中，4G移动网络质量提升越来越强调面向用户感知，基于端到端的业务流程来分析网络质量对用户感知的影响，并根据不同的业务特征来优化网络、配置相应的网络资源，因此，需要在传统的网络运行KPI指标分析的基础上，转向基于端到端的用户业务清单来分析4G移动用户的感知和网络质量。而4G网络下全量用户端到端清单数据的关联分析存在以下难点：

（1）种类多、体量大：涉及从终端、无线、承载网、核心网、SP等维度的多种数据，百亿条记录的大表关联

（2）不等值关联：MR、CDR与CHR的关联、DPI与MR的关联都不是简单的等值关联，需要提供一些特殊算法来提升关联程序的的性能和效率

（3）实时性要求高：准实时数据流处理，时延要求高

因此，4G移动用户端到端业务清单关联算法研究及实现作为一项前提性的基础工作需要首先解决。

2 算法实现的关键技术点

2.1 根据数据业务特点划小数据块

4G用户端到端清单关联最大的难点在于数据量大，而且是不等值关联，其中最主要的一个数据是DPI、CHR、MR三者的不等值关联。MR数据作为无线侧用户级的主要数据，需要与核心网侧用户级的清单数据DPI关联，这两个数据是我们端到端的清单数据的核心。但是有MR数据中没有用户的MDN/IMSI信息，而DPI数据则是以用户的MDN/IMSI作为主要索引的，所有如果想把无线侧的MR数据与核心网的DPI数据关联起来，得到用户级的清单数据，必须借助CHR数据为桥梁。目前广东电信DPI数据一天约200亿条记录，MR数据约60亿条记录，CHR数据约50亿条记录。如此大量的三个数据做不等值关联，即使使用hadoop集群处理技术，仍然是一个非常大的难题。

解决这个问题的基本思路是化小，并且根据数据关联的化小。首先是MR和CHR的关联，其关联规则是：两个数据的eNodeB_ID相等、MmeUeS1apId相等、且记录中的时间戳前后相差不超过60秒，选择符合上述要求的时间戳最接近的两条做关联。根据关联规则，首先按照小时化小数据块，这样CHR和MR的数据忙时一小时大概是5亿条数据的级别，再按照eNodeB_ID分成50个数据块（用eNodeB_ID模50的方法），这样切分下来，每个数据块就百万—千万级别，然后再按照时间戳取前后60秒的数据去关联MR和CHR，最后得到时间最接近的两条数据，将CHR中的IMSI/MDN赋值给MR，这样就让MR数据有了用户的MDN/IMSI信息。

对于MR和DPI数据的关联，思路也是同样的化小。MR和DPI的关联规则是：两个数据的MDN相等，且记录中的时间戳相差不超过5秒，选择符合上述要求的时间戳最接近的两条做关联。按照同样的思路，我们把MR和DPI数据首先按照小时化小数据块，然后再按照MDN划分成50个数据块（用MDN模50的方法），经过这样切分，每个数据块化小到千万级别，再进行两者的关联后，就可以将MR和DPI数据串接起来，形成用户端到端业务清单数据的核心。

2.2 预判下一个环节数据处理要求

数据处理是采集-入库-分析-处理-输出这样一个一环扣一环的流水线似的作业，每一个环节都应该考虑下一个环节怎么使用这个数据，因此在输出给下一个环节是，不但要考虑本环节生成的性能要求，还要提前考虑下一个环节的数据要求。

例如上面的DPI、CHR、MR关联时，首先做的是MR和CHR的关联，这两个数据的关联规则是按照“小时+eNodeB_ID（模50分区）”的，所以在MR和CHR数据入库后就直接采用这种分块方式存储。而MR和CHR关联后，接下来跟DPI关联时，需要采用“小时+MDN（模50分区）”，所以MR和CHR的关联结果文件以及DPI入库后的文件都应该按照“小时+MDN（模50分区）”的数据块存储。这样对下一个环节数据处理要求的预判以及提前做的准备工作，可以大大提升数据的处理效率，减少I/O读取次数。

2.3 数据处理由MapReduce改成Spark处理。

MR、CHR、DPI大表不等值关联数据的处理，由传统的调用hadoop的MapReduc程序处理，改用Spark内存式分布处理架构，一小时的MR/CHR/DPI数据（约15亿*5亿条）进行关联时间由原来的8小时提升到10分钟以内，效率显著提升。

3 算法关键实现过程概述

端到端用户清单关联的关键实现过程包括数据采集、数据入库、数据分析三个层面，如图1所示。

3.1 数据采集

端到端业务清单数据关联涉及到不同专业、不同网元、不同系统产生的数据，关联的第一步首先通过FTP方式把各类数据采集到集中的网络数据运营平台的采集机上，然后再送上hadoop集群，如图2所示。

图1 端到端用户清单关联数据处理整体架构示意图

图2 数据采集处理架构示意图

在采集过程中，有几个关键点需要注意：

（1）从网管服务器传到采集机上的文件，如何判断文件已经传完？

方案1 ：执行lsof命令判断是否有进程在写文件。特点：

① Windows平台不支持

② 调用一次要10毫秒以上

③ 多个进程在很短的间隔内依次写同一个文件时，lsof在这个间隔中间执行会误判文件已经写完

方案2.依据时间间隔判断

① 给一个时间间隔，比如两分钟： 如果文件的修改时间跟当前时间相比超过两分钟了； 说明在这段时间内都没有修改，就认为它写完了。

② 缺点: 文件传到hadoop集群会有延迟，如果在那段时间间隔后再写怎么办？

方案3.制定规范

① 传到采集机上的文件，如果正在传，还没有写完，先以”.tmp”（或其他）后缀命名，写完后再去掉”.tmp”后缀。

② 只有非”.tmp”结尾的文件才能从采集机上传到hadoop集群。

通过对比，最终选择相对较优的方案3实现。

（2）如何判断采集机上的文件已经传到hadoop集群，避免重传，同时支持发生错误时补传？

① 方案1: 加”.copied”后缀，缺点: 需要rename权限、只支持一个应用对文件进行rename，不支持多个应用

② 方案2: 把读过的文件名记录到一个HDFS文件或本地文件中，传失败的文件不记录。同时，这种方案还可以方便核查比对，帮助寻找代码中的bug。

通过对比，最终选择方案2。

（3）当发生日期切换时，如何采到23点的文件？

采集机上的文件有些是按日期分目录的，例如2016-08-28号23点的一小部分文件，可能会意外的放到2016-08-29号的目录中，这时不能以2016-08-29号为日期，而是提取文件名中的日期时间，然后传到Hadoop集群相应的HDFS目录下。

（4）如何优雅地关闭采集程序？

使用shutdown hook，kill pid （不加-9）。 直到正在传送的文件传完到hadoop集群时才退出

（5）如何用简单的办法及时通知入库程序有新文件了？

① 在HDFS中为CHR、CDR、MR、DPI创建特殊的NEW_FILES_子目录，例如CHR是: /DATA/ PUBLIC/NOCE/SRC/SRC_CHR_L_MM/_NEW_FILES_

② 采集程序每次传了一批文件到Hadoop集群后，在NEW_FILES_目录中生成一个文件名包含日期时间的临时文件

③ 入库程序检查_NEW_FILES_目录的修改时间，如果比上一次要新，把该目录中的文件名列出来，抽取出日期时间，然后去对应的SRC目录中找新文件，入库后删除临时文件

3.2 数据入库

数据入库就是把送上HDFS的文件进行清洗、加密、分区，生成ETL表。入库程序自动识别采集程序传到Hadoop集群的各种文件类型，然后将文件分批处理，集群每个节点一次处理一批文件，各类数据文件并行处理，提高入库效率。同时对于压缩文件不解压到硬盘，边读边解析边分区入库。对于大文件，在单个节点上，用一个读线程加多个解析线程的方式，充分利用CPU，减少大文件的入库时间，如图3所示。

图3 数据入库处理架构示意图

数据入库阶段要充分考虑该数据的业务特征，为下一个环节的数据处理做好准备，例如对于MR和CHR数据，这里就应按照小时、eNodeB_ID模50的方法，每小时分成50个数据块。而对于DPI数据，则是按照小时和MDN模50的方法划分数据块。

在数据入库过程中，有几个关键点需要注意：

（1）异常记录保留得处理

对于eNodeB_ID和MDN为0的记录，单独放到一个分区，例如第51个分区，用eNodeB_ID或MDN做关联分析时忽略异常记录

（2）避免多个节点同时写同一个分区文件的方法：由于某一批文件只会在一个节点中处理，为每一批文件分配一个id（可循环使用），从而避免发生写冲突

3.3 数据关联

有前面数据入库时做的数据块化小的准备工作，数据关联主要实现对应的两个化小数据块之间的关联，同时为了避免内存溢出，边读边计算边输出，及时将关联后的结果输出到结果表，如图4所示。

数据关联过程中的关键实现步骤：

图4 数据关联架构示意图

（1）CHR与MR关联

① 启动25个Spark executor，分别读取某个小时的CHR数据中的前25个数据块，并将其加载到内存，同时按照eNodeB_ID、MmeUeS1apId、Start_Time这3个字段排序

② 读取MR对应的分区文件，不用一次全加载到内存

③ 使用折半查找算法，从CHR中找出该条MR对应的MDN/IMSI

④ 重复上面步骤，把后25个数据块关联完，这样就完成了CHR和MR一小时内的数据关联

⑤ 结果输出到CHR_MR关联表中，同时将该表按照MDN划分成50个数据块（用MDN模50的方法），为接下来的和DPI的再次关联做准备。

（2）DPI与MR关联

① 启动25个Spark executor，分别读取CHR_MR关联表对应的编号从0～24的25个分区文件

② 加载到内存后，将MDN 相同的分成一组，同组内的记录按timeStamp字段升序排序

③ 读取DPI对应的分区文件，不用一次全加载到内存

④ 使用DPI的MDN字段找到对应的那组CHR_MR关联表记录，然后再顺序比较timeStamp是否在DPI的ts_start和ts_end之间

⑤ 重复1～5，把分区25到49关联完

（3）处理DPI MDN为0的记录

DPI数据中有大量MDN为0的记录，这部分记录在用户端到端关联上是垃圾数据，但是在进行其他模型分析时，该部分数据是有用的，所以这部分数据需要保留。但是该部分数据与正常记录产生的分区大小相比会有一个数量级的差距，造成数据不均衡，不能跟正常分区一起跑数据分析。解决方案是启动第51个分区来分散存储MDN为0的记录额外启动多个Spark Task来并行分析这些文件。

3.4 数据输出

经过上述关联后，形成了4G用户端到端的业务清单数据，该清单数据反映了全网任何一个用户，在任何时间，用什么类型的终端，在什么位置，访问了什么业务，当时端到端的网络质量/指标（包括无线网、承载网、核心网等）是怎样的，用户的业务体验（网页打开时延、视频下载速率等）如何等。为了更好地支持这些端到端的清单数据的快速查询和输出，将清单数据存储在HBASE数据库中，并且以“MDN+时间”作为查询主键，实现了百亿条清单数据秒级的查询返回速度。

4 系统现网部署验证

端到端的业务清单关联数据采用新算法后，与原来直接按照时间粒度划分后采用MR程序进行大表关联相比，性能提升为原来的48倍，极大地算短了数据结果输出时延。端到端业务清单关联数据完全采用自主研发团队，基于hadoop开源软件架构，自主设计开发实现，与购买外部商用软件比，响应快、工期短、部署快。整个工作从设计到开发一个月内完成。

4G用户端到端的业务清单关联在2015年10月已经在广东电信网络数据运营平台上线应用，运行一年以来，该套关联算法运行稳定，实时性好，处理效率高，其采用的设计理念计算法已经成为该平台核心数据处理程序，在多个海量数据关联场景中得到应用。

5 结束语

用户端到端的业务清单数据真正实现了全网任何用户（Anyone）任何时间（Anytime）、任何位置（Anywhere）、任何业务行为（Anything），以及用户当时的业务质量感知（时延、速率）等情况、无线网质量（覆盖、干扰）与核心网的运行情况等。目前该清单数据被广泛应用用客服投诉查询、楼群感知评估、人群流动分析等应用中。

4G用户端到端业务清单数据关联的思路及实现方法可以广泛应用于海量数据的大表关联的数据处理实践中，为海量网络运营数据的处理和价值挖掘提供基础。

1孟小峰，慈祥.大数据管理:概念、技术与挑战［J］.计算机研究与发展，2013，01:146-169

2李建中，刘显敏.大数据的一个重要方面:数据可用性［J］.计算机研究与发展，2013，06:1147-1162

3王元卓，靳小龙，程学旗.网络大数据:现状与展望［J］.计算机学报，2013，06:1125-1138

4韩晶.大数据服务若干关键技术研究［D］.北京邮电大学，2013

5李学龙，龚海刚.大数据系统综述［J］.中国科学:信息科学，2015，01:1-44

6李文莲，夏健明.基于“大数据”的商业模式创新［J］.中国工业经济，2013，05:83-95

7冯登国，张敏，李昊.大数据安全与隐私保护［J］.计算机学报，2014，01:246-258

8孙大为，张广艳，郑纬民.大数据流式计算:关键技术及系统实例［J］.软件学报，2014，04:839-862

9张引，陈敏，廖小飞.大数据应用的现状与展望［J］.计算机研究与发展，2013，S2:216-233

10卢辉，数据挖掘与数据化运营实战：思路、方法、技巧、应用，大数据技术丛书，机械工业出版社，2012.6

11中国电信客户感知项目组，中国电信移动网业务感知分析系统功能规范，技术规范，中国电信集团 2015.1

10.3969/j.issn.1006-6403.2016.10.007

（2016-10-12）