传统SP业务运营数据分析系统填坑记

笔者所在的公司为北京的一家传统电信增值业务运营商，也就是电信行业熟知的SP（Service Provider）。SP业务曾经拯救了2000年互联网泡沫下的多数公司，不少互联网公司如搜狐、新浪、网易等，至今仍保有SP业务。相对于近几年迅速崛起的移动互联网来说，SP已属于传统业务。公司在行业中处于渠道分发商的角色，上游技术提供方为2.5G时代增值业务技术的领头羊高阳，下游接入多家SP渠道，起着承上启下的作用。需要即时接收上游海量日志，同时需要为下游同步计费信息。公司规模不大，管理远不及大公司那般规范，个人需要承担系统维护、产品设计开发、测试乃至数据统计等多项职责，类似于经常见于报端的全栈工程师（吐槽一下，其实是因为小公司缺钱，养不起那么多专业分工的工程师，呵呵）。因现有系统运行历史较为久远，电信级的海量数据日积月累，公司原有数据运营分析系统已不堪重负。因历史遗留原因，原有系统存在以下问题：

（1） 原有网关（接收上游同步日志的工具）的代码已经丢失，无法通过代码调试来查找问题！！！

（2） 原有统计后台由ASP Maker工具生成，配置文件和查询条件写死在代码中，造成每接入一家SP就要复制粘贴一个文件夹，并修改其中的配置文件！

（3） 每天都要进行的数据统计竟然从视图中查询，并且因数据量过大，需要不断修改查询条件，只能查询较近几天的数据，月查询时页面超时！

（4） 因数据量过大，同步数据严重积压，SP合作伙伴不能及时收到同步的数据很是恼火，业务合作数量也受到影响；

（5） 数据量分布并不均匀，一到并发数多的时候，网关就容易发生内存溢出，造成业务失败；

（6） 上游推送的日志因数量巨大，并未完全写入数据库中，而是以一定格式写入日志中，这也给业务统计造成一大难题，无法快速准确的统计用户的呼叫量。按传统方法，每次统计一次呼叫量居然要耗费一个多小时！

（7） 因运营商不断开放新的号段，原有号段表数据更新缓慢，造成按地市统计的数量不准确。

互联网圈里流传过这样一个段子：如果你站得高看得远，那是因为站在巨人的肩膀上；反之，如果你站得不够高、看得不够远，那是因为你站在巨人挖的大坑里！生命不息，填坑不止！你无法以历史遗留问题为借口，然后满是沟壑的现状怨天尤人，填坑正是公司雇佣你的价值所在。所以，还是带上工具，搬砖填坑吧！

源代码丢失，单步调试的方法是用不上了，但上帝为了关上了一扇门的同时，也为你打开了一扇窗。因公司的渠道分发地位，并不关心单个失败的原因，而是关心同一批失败的共性原因以及所占比例，统计学接过代码调试的枪，成了问题查找的利器。最初的做法是先做定性分析，然后抽取部分特征数据进行验证，属于样本分析的方法。但这种方法说服力并不强，可能会造成遗漏或主次原因不分，仍需改进。

有些问题的改造方法以现有成熟技术并不难，只是因为现有系统的运行历史过于久远，技术落后导致的。比如，废弃了视图，改为实表，并且通过每天凌晨的定时作业，将每天汇总的结果写入到统计表中，然后数据查询时，历史数据之间查询统计表，只有当天的数据才查询数据源表。系统每天产生数万条计费记录，而作业产生的统计表数据每天只有数百条，这样源数据表的查询压力迅速下降了两个量级。通过大量使用作业，二次加工的统计数据过程变得简单方便，无需人工干预，不仅查询的速度上来了，同步积压的问题也解决了。

说到视图，这里谈点看法，视图是若干查询记录汇总成的一张虚表，好处是不占用存储空间，但却占用内存空间。在过去存储昂贵的过去，数据量很小，而存储有限的时代，数据表的设计原则应遵循E.F.Code的第三范式，以达到存储空间的最小占用。然而，在存储已非常廉价，数据量大以及查询速度成为首要矛盾的大数据时代，视图在工程上应当回避使用，表的设计也应适当存在些冗余，减少联表查询操作，以加快查询速度。有次在群里听说师弟做毕业设计时仍要求符合第三范式，光权限设计就占用了五张表，不禁一身冷汗，这样的系统能承受得了多大的数据量？

用php重新开发了SP数据分析系统，采用账号分配和权限控制的方法，一个系统替代了原有的多个ASP系统。这个在技术上并不难，然而，系统的推广却因运营人员对原有系统的习惯而进展缓慢，造成我需要同时维护两套系统！想减轻工作量反而却加倍，而后一次系统重装带来的升级反而使新系统顺利上线。由此得到的教训是，数据分析系统是给他人使用的，在开发之前一定要做好用户的思想说法工作，而不只是方便好用用户就买账，用户习惯的惯性是巨大的，开发新系统要尽量兼顾已有系统的使用习惯。

至于数据量并发问题，原因数据库系统是sql2000的，升级sql 2008版后问题解决。保持软件的更新很重要。号段更新问题，因为上游传递的日志信息不仅有号码，还有号码所在当前区号，在数据中建立了一张区号和地市的对应关系表，当用户号码对应的号段在号段表中不存在时，通过查找区号表来向号段表中自动添加号段。不直接使用区号的原因是因为这个区号为提供移动通信的服务区号，不一定为号码归属地区号，加上原有号段表中已拥有了大量号段，在统计上出差的概率很小，上线后抽测误差在可接受的范围内。

接下来，就剩下硬骨头在每天产生的几百兆的文本中统计呼叫量和分析失败原因了。在熟悉日志结构和查询规则后，开始寻找填坑的利器。做技术最忌讳的是手里握有一把锤子，看什么都是钉子。而应根据任务的不同，寻找最适合的工具。首先，公司的服务器系统是Windows 2003，Linux下的awk等利器是用不上的，数据量由达不到TB级，公司也不会为这个问题采用像hadoop这样的架构来采购设备。既要马儿跑，又要马儿不吃草，小公司的需求和资源供给上就是存在这样的矛盾。很幸运，找到了能，满足这样需求的利器—Python！用Python提取所需的号码，一共写了5个版本，最后用Django搭建了Web端，终于使这一日常查询工作由一个多小时下降到几秒钟，最终由非技术的运营人员接手此项工作，本人得以解放，可以学习Python的其他技能了。这一阶段的具体过程之后会单独写一篇文章《人生苦短，我用Python》，这里就不详述了。

综合运用PHP、SQL Server和Python，之前的坑算是填完了。生命不息，挖坑不止；填坑不易，且填且珍惜。