日常-工作上的那点事儿

从年中开始，在一个流量预测的项目上辗转了多月，最近也快临近上线了。这么多月以来，没少碰壁，这次码字主要想总结一些坑，避免以后再次遇到还会掉在同一个坑里。。。

自己的问题？

如果你发现预测的指标相较于你的以往的测试或者在训练集上变得出奇的差，不要下意识就慌着去怀疑自己的代码效果是不是没有那么好。当然，首先第一步还是看看自己的代码里面是不是有bug，比如是否有些代码临时被注释了，变量是否传错了，又或者设定了错误的时间日期（今天预测昨天）等等。。。

对于自己的代码还是比较熟悉的，所以能够很快的找出其中的“bug”。紧接着，排除完自己的原因后，往数据这一part去着手检查。

数据的问题？

通过一些可视化工具进行EDA-数据探索性分析，将以往的数据变化趋势展现出来，比如每天流量的走势，变量的分布等等。人是视觉动物，所以很容易从图中发现问题，观察是否哪天的数值远远跑出了以往的变化范围，将这些问题点mark下来，相当于在一个坑位做了一个记号，后面填坑的时候有精确的定位点。

除了通过可视化的方式进行数据分析，还有一个简单粗暴无脑的方法。直接
下载数据源，打开excel文件，查看原始数据是否有缺失，翻倍，异常等现象。当然不是很推荐这种傻大粗的方法，不过对于一个对数据敏感的人来说，这个方法还是很好用的。如果确定了是数据的问题后，从以下两个part进行检查。

首先是抽取数据的代码，检查代码的逻辑是否出错，错误类似预测part的代码。这次项目在取数这一part就出现了传错变量的坑，导致有些变量后续没用上。。。

其次是查看数据源头，即上游数据。上游数据大多是来自于数据中台，但是数据中台同时也是不同部门数据的汇聚处，所以这其中包含了多个层级关系，不同层级之间有可能会出现数据断层 or 数据错误累计，这时候需要跟相关的同事一步步进行排查。

这次项目的数据源就出现多个致命错误。。。

• 比如每天数据获取时没有去重处理，导致某些字段的数值翻倍；
• 每天的定时任务（数据中台汇集数据）因为服务器的资源调度不够而导致数据汇聚失败，出现了数据缺失，数据错位等现象。

说实话，服务器资源调度不足确实是个硬伤，没法日志记录，一旦卡死还没法自动停止，除非有个人能够时时刻刻监测着任务的状态。