中国移动架构师大数据分析模型实践:解决渠道猫和老鼠的游戏

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介:


目录

  • 猫池介绍

  • 终端识别模型

  • 日间隔预警模型

关于数据挖掘,我给大家分享的案例是猫池终端识别模型和日间隔预警模型。当然作为运营商一般是自己很少全程参与的,但这两个模型基本上从需求定义、指标选取、指标确认、挖掘算法、模型结果确认和优化是我参与和把控的。


猫池介绍


猫池(外文名:ModemPOOL)就是将相当数量的Modem使用特殊的拨号请求接入设备连接在一起,可以同时接受多个用户拨号连接的设备。

猫池分不同用途,可以单独认为它是仅仅基于电话的一种扩充装备,而不去区分它的上网或者手机讯号收发效应。 它使用电话的中继功能,即一个号码多条线路。

猫池广泛应用于大量具有多用户远程联网需求的单位或需要向从多用户提供电话拨号联网服务的单位。如邮电局、税务局、海关、银行、证券商、各类交易所、期货经纪公司、工商局、各类信息呼叫中心等。


简单说来就是一台设备,这个设备是为了方便人们的批量使用的。


终端识别模型



如果只是简单的设备和应用,没必要大惊小怪的。问题出在哪里呢,运营商是以KPI为导向的,用户数、终端数,为了KPI,运营商的分公司会造假、渠道会造假、甚至部分分公司配合渠道造假。但是移动发放SIM/USIM卡双为了发展新用户、发展市场占有率,同时也发放正常的佣金给渠道。移动卖终端也是为了维系老用户,巩固市场占有率,总的目标是为了“用户”。但渠道不同,他的本质在于逐利。除了正常的佣金/酬金,还想赚取倒卡的利润,低价批量获取移动资源,高价卖给用户。终端也是,争取赚取更多的差价,创造更多利润。


当然运营商也会对渠道进行考核,希望用户用起来卡和终端,而不是虚耗资源。但渠道的对策是采用机卡分离,制造两者使用的假象这就是我们本次挖掘的目标,把渠道制造的假象和行为识别出来。


前面啰里啰唆说了这么多,就是为了找到数据挖掘出发点。渠道套机是为了获利,因此机终端在收入、流量、通话行为、终端行为等指标上会存在相似的特征,且显著有别于正常的终端,因此识别猫池终端存在可行性。基于对猫池终端的以上理解,选择从终端的收入、计费时长、流量、通话时长、通话次数、通话基站数、激活终端数、主用终端数、交往圈终端数、主被叫通话占比、通话行为集中次数等指标。渠道制造使用的假象本质也是为了利润,所以他投入的成本要小于运营商的佣金,这样才有盈利的空间。世面上猫池设备提供这种便利可能性,当然机器终归是机器,其行为必定与正常用户有所区别。



这是我们经过认真分析后得到的指标。主要是终端的消费行为,终端自身的行为、终端与渠道的关系、终端与号码的关系。经分系统的数据表有1万+以上,报表5000+,指标数千,并不是所有的指标都可以直接拿来挖掘的。挖掘的误区是,给我现有的几百个指标,我可以得到任何想要的用户模型,而且成本都是一样的。通话行为集中次数-该终端在一个月中有几次出现这样的情况:在同一天,同一基站下,向同一人通话,且通话时间在30s以内,且通话次数大于2次,光看这个指标就很绕口。实现是从通话清单出的,现有的DB2数据仓库,每天只能跑4、5天的数据。激活终端数,激活该终端的号码激活了另外多少部终端。主用终端数,该终端的主用号码还有多少部主用终端。是从终端找号码,再从号码找终端。


这20个指标的开发用了大约3个月时间。运行2个月数据花了半个月,所以数据准备期是最长的。


接下来是数据探索


探索是对数据进行初步研究,以便更好地理解它的特殊性质。数据探索有助于选择合适的数据预处理和数据分析技术。它甚至可以处理一些通常由数据挖掘解决的问题,例如,有时可以通过对数据进行直观检查来发现模式。

数据探索的一种常用方法是“可视化”。数据可视化是指以图形或表格的形式显示信息。成功的可视化需要将数据(信息)转换成可视的形式,以便能够借此分析或报告数据的特征和数据项或属性之间的关系。在数据分析中,可视化技术(如图和表等)常常是优先选择的方法。尽管数据挖掘强调算法和数学方法,但是可视化技术也能在数据分析中起关键性作用。


就是类似简单的可视化,通过2维可视化来评估各指标的适配度



直方图是一种可视化技术。在统计学中,直方图是一种对数据分布情况的图形表示,是一种二维统计图表,它的两个坐标分别是统计样本和该样本对应的某个属性的度量。



我们完成每个指标的直方图,对其进行解释。分析各指标的数据分布规律性是否符合正态分布,不满足正态分布的指标一般属于重点监测对象,激活终端数、其他主用终端、其他终端这三个指标值的分布很不均匀,值为0的占绝大多数,表明正常终端绝大部分只被一个号码激活,如果激活该终端的号码同时激活了其他一部或多部终端,则套机的可能性增大。另外,主叫占比大致服从正态分布,但是当主叫占比值为100时,明显与右侧的长尾冲突。因此主叫占比100的终端有套机嫌疑。对猫池终端的识别采用的是聚类算法,对聚类出来的结果需要进行进一步业务分析和解读,以确定是否有疑似猫池终端的聚类,确定后,即生成相应的指标规则。


通常指标是满足正态分布的。但是也有长尾的,这很正常,比如收入、时长、流量,这是由于大多数人的消费行为和运营商对用户的认定导致的。激活终端数、其他主用终端、其他终端这三个指标值的分布很不均匀,值为0的占绝大多数,表明正常终端绝大部分只被一个号码激活,如果激活该终端的号码同时激活了其他一部或多部终端,则套机的可能性增大。


这个是可以预想的,正常用户的行为是如何的,极端客户是如何的。


算法的选择


市场部并未给出疑似猫池终端用户的样本,因此无法选用决策树之类的模型。模型的目标是要挖掘出套机终端,由于没有套机样本,因此分类算法无法解决,必须借助于聚类算法。聚类算法的核心思想是“物以类聚,人以群分”,即具有相似特征的个体聚集成一个簇。猫池套机终端存在诸多相似特征,例如终端收入较低、计费时长较短、流量较小和主叫占比较高等特征,而这些特征又显著区别于正常终端,因此聚类算法有效。

聚类是一个不断探索寻优的过程,本次使用k-means算法将数据划分成不同的类,观察聚类结果,选择平方误差和(SSE)最小的分类策略。K-means算法把簇的形心定义为簇内点的均值。首先,在数据集D中随机地选择k个对象,每个对象代表一个簇的初始均值或中心。对剩下的每个对象,根据其与各个簇中心的欧氏距离,将它分配到最相似的簇。然后,使用更新后的均值作为新的簇中心,重新分配所有对象。迭代继续,直到分配稳定,即本轮形成的簇与前一轮形成的簇相同。


k-means聚类过程
第1步:确定要划分的类别数k;
第2步:根据欧氏距离把所有的终端划分到这k个类中;
第3步:重新计算k个类的中心;
第4步:重复第2~3步,直至分类趋于稳定。



我们先是选择了聚类算法,再次选择k-mean聚类。k-mean聚类比较成熟,也容易理解。聚类既不是越多越好,也不是越少越好。聚类越多,干扰项越多,解读也越困难;聚类少了,用户的特征体现不出来,所以一般是10个以内。聚类是一个不断探索寻优的过程,本次使用k-means算法将数据划分成不同的类,观察聚类结果,选择平方误差和(SSE)最小的分类策略。

随着分类个数的增加,分类误差(SSE)越来越小,同时分类耗时(迭代次数)也急剧上升。当聚类个数低于8时,聚类误差下降很快,超过30时则趋于平缓,但迭代次数上升迅速。


聚类个数越多,误差平方和越小,但是个数过多会干扰决策判断,导致业务上的偏差。原则上聚类个数不宜过多,因此模型选择聚类个数10类。

观察结果发现,第10个类的终端收入、基站数和通话交往圈等指标值较其他类低,而激活终端数、主叫占比等指标值较高,根据猫池套机业务分析,此类应该判断为猫池终端。


并把聚类的结果生成指标规则,以便为后续数据提供进一步挖掘依据。


聚类出来的结果要通过业务语言进行解读,为了保证kmeans聚类能力的适用性,模型建立在以下数据集上(样例为随机数)


数据集:2015年5月、6月销售的已激活终端在6月、7月的行为数据;

样本总数:xxxx
观察结果:第10个类的终端收入、基站数和通话交往圈等指标值较其他类低,而激活终端数、主叫占比等指标值较高,根据猫池套机业务分析,此类应该判断为猫池终端。


就是这么一张聚类结果表,要能解析出业务含义,要评估出那些敏感指标的敏感特征数据,不是靠机器,而是靠业务积累。


数据挖掘的应用和输出


数据挖掘的目的不是为了挖掘而挖掘,而是为了让规则持续得到应用,并不断去污求精的完善过程。因此该过程描述的是把规则库应用到新月份的新售终端,且次月已经激活的情况下,通过猫池终端规则库校验,判断是否为疑似猫池终端用户,并通过对预设条件的筛选,最终获取更为精确的结果。

通过以上步骤,完成了终端聚类任务,接下来需要将模型部署到生产环境中。
通过计算欧氏距离,把终端划分到相应的类中,把划分到第10个类的终端套机标签标记为1,划分到其他类的终端标记为0。



我判断出之前数据的疑似猫池用户,要把该模型结果应用到下个月或之后的用户上,才能得到持续应用,产生价值,是吧。



同时我还要给用户去看相关数据,如果用户对相关数据不满意,我还要能设定再次筛选吧。


所以在最终结果中,还引入了一些用户的基本行为作为筛选项和判断依据。比如疑似猫池用户约为每月5000,用户经过再次筛选后得到2000,然后业务部门再把这2000用户提交给渠道或者做私下调查,以避免模型误判。这是第一个模型。


日间预警模型


第二个模型,日间隔预警模型稍微简单点,是我12年进公司的时候,当时引入的一个模型。


客户生命周期理论,告诉我们要发展新用户,刺激用户消费、维系存量用户,预警和挽留老用户。本模型适用于最后一个目标维系存量用户、预警和挽留老用户的投入是发展新用户成本的十分之一。




RFM模型是基于上述三个要素建立的数据模型,是衡量客户价值和客户创利能力的重要工具和手段。该模型通过一个客户的近期购买行为、购买的总体频率以及花了多少钱三项指标来描述该客户的价值状况。


RFM模型之前我是知道的,但想明白跟日间隔预警模型的关系,却是最近的事儿。



为什么能使用这个模型?是基于假设的,假设正常用户的通话行为是不变的,通话频率、最近一次通话时间间隔等等;假设用户要离网,该行为必定有所改变,你可以设想一下转网或互转或换卡等等。再一个是运营商一般对欠费、离网用户会保留三个月的正常状态,只有持续不通话几个月才会做销号处理。所以我们可以向前推,假如用户8月离网,5月开始通话不正常,则可以观察3、4、5月的通话行为。



当前沉默时间:用户最后一次通话时间距当日23点59分59秒的时间间隔;
期 望 值:用户常态下通话时间间隔的平均值;
标 准 差:用户常态下通话时间间隔稳定度,标准差值越小,说明用户通话间隔越稳定;
T 值 :T =(I-μ)/δ。当T很大时,说明用户的通话时间间隔明显超过用户常态下的使用习惯,用户离网倾向较高。

同RFM模型相比少了个M



基于用户3个月的历史通话详单和5个月的用户资料进行研究。分别运行M月份日通话清单,对比用户M-1、M-2月份(用户通话模式正常期)的通话模型,预测在M+1、M+2月发生离网的概率。以M+1、M+2月真实发生离网的用户评估模型的命中率和覆盖率。这个在2012年时每天也只能处理3天的数据,时间都被耗在模型计算上了。在4+1的MPP上,能计算10天数据。


模型的输入输出



输入的是正常用户的日间隔期望、标准差、最后一次通话日期和时间,以及当前沉默时间,输出的是T值



再一个是查全率和查准率问题,这两个是相互矛盾的,所以必须不停调整T值以求得最佳结果。



模型的调优,因数据量原因,把日调成周了,同时也要解决实际操作问题,预警排重。



最后是模型应用。这个模型也可以调整成中高端用户预警、存量预警等等,再

细化人群


企业的数据挖掘和书本的数据挖掘差别在于对于业务模型的解读、持续的优化。


讲师介绍:

  • 16年IT工作经验;关注领域包括证券、航空、制造、电信等。

  • 在数据库开发和优化、数据仓库、系统架构、大中型项目管理、数据分析、Office、大数据方面有一定研究。

  • 《剑破冰山--Oracle开发艺术》一书合著者,《IT项目管理那些事儿》一书主编。


本文来自云栖社区合作伙伴"DBAplus",原文发布时间:2015-12-26

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
目录
相关文章
|
19天前
|
运维 持续交付 云计算
深入解析云计算中的微服务架构:原理、优势与实践
深入解析云计算中的微服务架构:原理、优势与实践
52 1
|
6天前
|
机器学习/深度学习 测试技术 定位技术
新扩散模型OmniGen一统图像生成,架构还高度简化、易用
近期,一篇题为“OmniGen: Unified Image Generation”的论文介绍了一种新型扩散模型OmniGen,旨在统一图像生成任务。OmniGen架构简洁,无需额外模块即可处理多种任务,如文本到图像生成、图像编辑等。该模型通过修正流优化,展现出与现有模型相当或更优的性能,尤其在图像编辑和视觉条件生成方面表现突出。OmniGen仅含3.8亿参数,却能有效处理复杂任务,简化工作流程。尽管如此,OmniGen仍存在对文本提示敏感、文本渲染能力有限等问题,未来研究将继续优化其架构与功能。
35 16
|
6天前
|
DataWorks 数据挖掘 大数据
方案实践测评 | DataWorks集成Hologres构建一站式高性能的OLAP数据分析
DataWorks在任务开发便捷性、任务运行速度、产品使用门槛等方面都表现出色。在数据处理场景方面仍有改进和扩展的空间,通过引入更多的智能技术、扩展数据源支持、优化任务调度和可视化功能以及提升团队协作效率,DataWorks将能够为企业提供更全面、更高效的数据处理解决方案。
|
18天前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
14天前
|
运维 监控 Java
后端开发中的微服务架构实践与挑战####
在数字化转型加速的今天,微服务架构凭借其高度的灵活性、可扩展性和可维护性,成为众多企业后端系统构建的首选方案。本文深入探讨了微服务架构的核心概念、实施步骤、关键技术考量以及面临的主要挑战,旨在为开发者提供一份实用的实践指南。通过案例分析,揭示微服务在实际项目中的应用效果,并针对常见问题提出解决策略,帮助读者更好地理解和应对微服务架构带来的复杂性与机遇。 ####
|
17天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
34 8
|
14天前
|
算法 NoSQL Java
微服务架构下的接口限流策略与实践#### 一、
本文旨在探讨微服务架构下,面对高并发请求时如何有效实施接口限流策略,以保障系统稳定性和服务质量。不同于传统的摘要概述,本文将从实际应用场景出发,深入剖析几种主流的限流算法(如令牌桶、漏桶及固定窗口计数器等),通过对比分析它们的优缺点,并结合具体案例,展示如何在Spring Cloud Gateway中集成自定义限流方案,实现动态限流规则调整,为读者提供一套可落地的实践指南。 #### 二、
36 3
|
16天前
|
负载均衡 Java 开发者
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
深入探索Spring Cloud与Spring Boot:构建微服务架构的实践经验
59 5
|
12天前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
29 1
|
14天前
|
监控 安全 持续交付
构建高效微服务架构:策略与实践####
在数字化转型的浪潮中,微服务架构凭借其高度解耦、灵活扩展和易于维护的特点,成为现代企业应用开发的首选。本文深入探讨了构建高效微服务架构的关键策略与实战经验,从服务拆分的艺术到通信机制的选择,再到容器化部署与持续集成/持续部署(CI/CD)的实践,旨在为开发者提供一套全面的微服务设计与实现指南。通过具体案例分析,揭示如何避免常见陷阱,优化系统性能,确保系统的高可用性与可扩展性,助力企业在复杂多变的市场环境中保持竞争力。 ####
33 2