夏明武电信行业数据挖掘与大数据心得体会39

电信行业数据挖掘与大数据心得体会夏明武[e-mail]互联网市场大小2011中国互联网收入，广告512亿元，增长57%网络游戏428亿，增长20%；电商7735.6亿，增长68%行业排头兵净利润率估计，广告35%，网游55%，电商1%，利润分别为179亿，235亿，77亿假设2012增长与利润水平不变，行业利润分别为广告280亿，游戏280亿，电商130亿艾瑞咨询互联网数据挖掘三个方向广告水军剔除剔除水军，可以大大减少广告开支、节约成本。这是节流。商品推荐这一块可以参考amazon的商品推荐，现在电商都在学amazon的商品推荐，只是都做得不好。这一块做好可以增加销售量。带来真金白银。这也就是开源。社交网络分析等现在新浪微薄的数据质量最高，大有可为。目前已经有很多公司在新浪上做社会化网络数据挖掘，但还可以容纳更多公司。上周，美国小型音乐公司LimitedRun宣布他们确信其在Facebook上的广告点击有超过80%来自于机器人程序，并表示将会向Facebook追究此事。@wx伍星：真心觉得直接的收入才驱动数据分析挖掘的发展，广告，电商，游戏行业的挖掘分析，较web网站挖掘分析先进很多回复@孙晗：这是真实的人际社会，所填信息比较真实和准确，能得到大量其它信息根本不可能产生的信息。//@孙晗:为何说新浪的数据质量高咧互联网数据挖掘三个方向中国移动数据经营分析系统10年经营分析系统建设，BI是否有用？SAS、SPSS在中国移动市场消失，数据挖掘基本失败，原因？客户细分问题？分析报告一定是正确的吗？信令数据介绍CS域语音主叫语音被叫短信发送短信接收位置更新开机关机位置切换信令数据介绍PS域彩信发送彩信接收WAP连接WAP使用WAP断开信令名词解释LAC：locationareacode位置区码（移动通信系统中）,是为寻呼而设置的一个区域,覆盖一片地理区域。CELL：采用基站识别码或全球小区识别进行标识的无线覆盖区域叫做小区。IMSI：InternationalMobileSubscriberIdentificationNumber国际移动用户识别码，是区别移动用户的标志，储存在SIM卡中，可用于区别移动用户的有效信息。信令名词解释IMEI：InternationalMobileEquipmentIdentity，是国际移动设备身份码的缩写，国际移动装备辨识码，是由15位数字组成的“电子串号”，它与每台手机一一对应，而且该码是全世界唯一的。MSISDN:MobileSubscriberInternationalISDN/PSTNnumber(ISDN即是综合业务数字网，是IntegratedServiceDigitalNetwork的简称)，即手机号码。信令数据能做什么？实时营销（精准营销、精确营销）事件营销（信令监控、信令分析、数据挖掘）基于信令数据和客户统一视图的数据挖掘高中生高中生家长大学生飞机来港客户飞机离港客户景区游客火车站到达客户火车站离开客户数据挖掘的创新规则以界面化的方式展示给业务人员参数可调整，业务人员可以根据业务经验调整业务人员可以直接界面执行数据挖掘，重跑数据通过外呼查全和查准前端界面规则配置到数据库中环境发生大变化时，业务人员熟悉模型规则，就能很方便给研发提新需求，研发远程开发后远程发包部署实时营销（精准营销、精确营销）速度实时合适的时间合适的地点给客户推荐合适的内容实时营销（精准营销、精确营销）案例两城一家机场旅客推荐各种套餐高考考生推荐各种业务体育场观众推荐歌星歌曲实时营销（精准营销、精确营销）流量规划功能简介根据url实时分类，做实时内容营销url无法分类结果,可以开发程序，调用爬虫，获取网站分类规则，做实时内容营销（socket调用获取url分类结果）根据搜索关键字，做实时内容营销结合信令数根据IMEI提取终端信息，结合url分类，做实时流量营销根据基站信息，做url实时位置营销据，实时提取BOSS侧流量信息，当流量超标时实时提醒（如看视频超出流量套餐）数据来源于信令PS域（Gn、Gb接口）核心规则处理由标准C程序开发，针对信令数据特征优化，简洁高效中国移动面临的问题用户会大规模从2G迁移到3G，或者是4G3G时代，流量费和2G相比，价格大幅下降。用户会自主选择使用什么应用。如苹果的AppStore、谷歌的GooglePlayStore。电信运营商的短信、彩信、手机报等等，对普通大众，都不在重要，通过套餐包提供就行。3G时代，语音业务，不再区分本地、长途、国内漫游。中国移动面临的问题全国统一套餐有几十个套餐基本就够了，不再需要每省几千、几万个套餐，那是一个太庞大、太复杂系统。3G时代，腾讯微信提供的语音视频，苹果FaceTime的视频通话，都将使语音直接走流量包就可以，套餐中无法再单独包括语音部分的资费。流量的价格远远低于语音的价格。这会使电信运营商彻底管道化。变成卖水、卖电一样的企业。中国移动面临竞争的个人建议电信运营商可以一方面收购使用水、使用电的的上下游公司的股份。可以考虑成立投资公司做投资。收购腾讯的部分股权，支持腾讯，腾讯发展壮大，中国移动也能跟着获益。中国移动入股，买下雅虎所占股份。也可以投资支付宝。中国移动面临竞争的个人建议将来的趋势就是移动互联网。中国移动，包括中国联通、中国电信，如果自己做不好移动互联网，那就投资给这些移动互联网企业。合适的多占股份，风险大的就少占股份。完全可以向风投转变。中国移动也可以继续尝试做各种应用，做平台，和各厂商合作。深挖互联网数据金矿。中国移动面临竞争的个人建议互联网时代，电信运营商面临着和阿里巴巴一样的问题，互联网的大数据，成本压力，财报压力。为了压缩成本，也需要去做去IOE化运动。现有系统无需改变，也不必迁移。电信运营商完全可以从零开始，打造一套适应互联网竞争的新一代互联网系统。中国移动面临竞争的个人建议未来的实时数据仓库（新一代经营分析系统）和全国互联网数据集中化中，在成本压力，财报压力，外部竞争压力加剧，互联网企业颠覆式创新的革命下，也不得不走阿里巴巴曾经走的路。投资阿里巴巴、支付宝、腾讯、京东、凡客、库巴、优酷、土豆、新浪、网易、搜狐、携程、大众点评网、豆瓣、如家快捷酒店、锦江之星等等。中国移动也可以去做电商。如果觉得自己业务运营水平高，可以学习亚马逊、京东做电商，做的更全面。中国移动面临竞争的个人建议如果觉得自己国企特色，做不好，可以学习阿里巴巴（天猫）、淘宝，做开放平台。这条路也挺不错。需要有大魄力才行。中国移动和百度合作的建议移动互联网时代，手机号码仍然是稀缺资源。百度、腾讯、阿里巴巴三大巨头，腾讯和阿里巴巴都有自己的号码（用户id）资源，这背后代表着用户信息。百度没有用户信息，在移动互联网时代处于很大劣势。移动运营商用户资源很丰富，信息也很全。中国移动完全可以和百度合作，把用户信息共享给百度，这样百度就可以做预搜索或其它各种工作。中国移动投资百度，资源共享，合作共赢。关于10张标签表，每张表8000万记录，每张表几百几千个标签字段，关联取数据，秒级出结果的高效方法?大数据关联查询创新案例方案1：数据库内方案把所有客户统一视图大标签宽表先按地市分表，再按号码分别拆分为10000张表。每张小表中包括所有需要的几百、几千个字段。小表总表数为1万到几万之间，详细为地市数量*1000。有的省份，小表数据量为2000条到8000条。前端访问时，不再需要做多表sql关联，数据量级别为千行级的单表sql查询语句速度也很快。起10000个线程并发执行，可以做到实时。方案2：数据库外方案把所有客户统一视图大标签宽表按地市分文件，再按号码继续拆分为1000个文件。每个小文件中包括所有需要的几百、几千个字段。小文件总数量为1万到几万之间，详细为地市数量*1000。如果是直辖市，直接拆分为10000个小文件。使用标准C，开发出处理程序，并发启动1万到几万个线程，每个线程把小文件数据加载到各自内存中。当需要处理数据时，实用LUA来访问数据，每个线程需要处理的数据量为千行级。总体速度应该在毫表级，可以实时把数据回传给前端。像有的省，如果地市用户提取客户群，则同样只需访问此地市的1000个小内存文件，速度能更快。方案1细节：表文件、和线程的数量可以根据实际需要调整，可以调整到100张表、1000张表、或者是100个文件、1000文件、再或者是100个线程、1000个线程。具体还需要查询资料，依据现场机器配置，做性能调优而定。如果并发线程压力太大的话，可以考虑改为减少并发线程数，或者改为串行。当数据无法做大表关联时，每次只需从单行记录就可去到。方案1细节：分表或分文件时，按手机号码尾号2位或3位来分，手机号码尾号本身是均匀的。在同一地市的小表中，每张小表的数据量是基本接近相同的。地市之间，考虑到不同地市的用户数不同，则可以对不同地市的分表或分文件数量做优化，用户数多的地市分表和文件多，用户数少的地市分表或文件少，尽量和所有的100、1000或10000以上的表或文件中数据量保持一致，这样并发处理线程同时处理，完成时间也能基本相同。方案2细节：数据为每月或每日凌晨初始化读入，载入到内存后。在上班时间访问，直接查询内存静态数据，速度快，但也涉及到内存分配太大的问题。此时，需要考虑做并发或者分布式处理。涉及到硬件投资增加问题，不建议采购小型机，改为采购刀片服务器或其它服务器。数据也可采用前端调用时再动态加载，根据机器配置，让线程分批次加载数据并处理。这样对硬件要求低，但速度相对会慢。方案2细节：前端向后台通信采取socket方式，后台处理完数据后，可以把最终数据合并，再加载到数据库中的表，也可以由各线程把各自数据分批插入到数据库中的表。数据加载完成后，再通过socket通知前端处理完毕。LUA具体如何处理和优化，细节尚待研究，需要花时间。细致工作还有很多，需要继续研究和深入下去。方案2细节：如果要考虑到硬件成本、分布式部署、开发时间和难度问题，可以接下来优化为采用hadoop方案。采用hadoop方案后，整体数据量在千万级，有些省例外，到了亿级。硬件投资改为采购几台PCServer，硬件投入为几万元。数据都在库外处理，NOSQL方式，数据库可以改为使用开源数据库MySQL，存放配置信息。这样DB2、Oracle或其它数据库都可以替换掉。方案2细节：整体来说，实用hadoop方式或库外标准C开发方式后，可以更有效减少中国移动在硬件上的投入，在数据库的投入。可以把节省的成本投一部分到应用软件厂商上。这样，中国移动就可以和应用软件厂商实现共赢。这也是IT业界的发展趋势。至于hadoop方案，客户统一视图标签月表每月生成一次，日表每日按生产一次。生成后为静态数据，每日上班时间数据不会更新，为静态数据。方案2细节：基于此特点，可以在每日凌晨把客户统一视图数据加载到hadoop中，白天访问时直接查询数据，速度快，效率高。数据加载到内存数据库中做查询，我目前用到的是solo+lucene，有的同事用的是MongoDB。云计算方案，应该是可以考虑借鉴谷歌做搜索查询这块的成功经验。云计算方案，貌似用流计算也不错。Yahoo的S4听说挺不错。微薄友的点评：得意的那些事儿大表，谷歌的bigtable是最佳实践blueprint，思想可以参考。从分表分库转向规模的bigdatarebalance。这才是所有的性能优化的起源和本质。这里面cap理论和dht算法是技术实现原理。当然mapreduce大大简化了数据的normalize和并行计算。hadoop的出现提供了这些。各种混合架构只是