一次印象深刻的bug调试经历

最近一段时间，再做一个用pig写的基于曝光数据的为大广告主提供一些搞搞效果数据的项目，最近苦逼的加班了好久，周末加过班、晚上加班、回家以后跑数据还得加班，总之是我大学毕业一年半以来最苦逼的日子。

 

本来给pm的档期是今天上线，可是由于需求太紧张、工期紧，直到昨天还在看自己跑出来的数据是否合理。然后发现了曝光数据一个字段根本没有上报，导致数据有数据丢失的现象，然后就临时采用生成随机值补全的方式来处理（用PM的话说，是比没有数据好一点点），然后C君就开始改自己的pig脚本呢，然后上线重跑。其实本来说调个bug应该不是什么太难的事情，可是现实正是如我经常说的“数据大了什么都有可能是问题”一样，每次fix一个bug以后，就要跑大量的数据，如果修改的是只需要跑最近几天的数据还有，最怕的就是跑基础的数据，因为基础数据需要的是几十天甚至四百多天的数据，每天将近1G，甚至有的数据是几十G。

 

------------------------------------------------------华丽的分割线。。。。。。。。。。。。。。。

 

不介绍背景了，直接切入主题。

昨天晚上因为fix了bug，要重跑数据，于是乎，C君就启动了任务，然后我就启动了我的任务等待（依赖关系，后面还有其他的依赖关系），最终C君的任务在凌晨0点左右跑完了，我的任务自然就跑起来了，不过，又过了一个多小时，我发现自己的数据还没有生成，就去oozie的监控页面查看job情况，发现失败了。然后我就自然而然的以为是由于任务跑重了造成了，然后就重启了job。感觉没有问题了，等到了3点左右，我发现任务失败，然后就仔细去Hadoop的任务监控页面进行查看，发现Java内存溢出，这时候完全没有头绪了，已经正常跑了，然后就想可能是由于这个oozie队列任务太多，分配的内存少了，然后换了个queue。然后我就睡觉了，睡到早上7点多醒来（我定了个5点半的闹钟，根本没有听见。。），发现任务依然失败，然后就么有头绪了。后来看着看着问题，就又睡着了（实在太困了）。。。后来九点多，起床洗漱去上班，在路上一直在想，想到应该是由于昨天跑的数据，有些被过滤的app端的数据又有了，导致加载入udf中的数据太多了，“恩，对，就是这样”，然后我就开始分析应该怎么解决，在到公司之前已经想好了。让程序的join从pin维度降到campaign维度。然后回来以后就跟老大一起分析，说了自己的想法。

 

下一步就开始解决问题。先去请教了一个pig大牛，确认了是由于加载数据太多导致的，如果不是在udf里面的话，除了特殊操作外，pig会利用磁盘来优化的。因为加载数据量为70天的曝光数据，大牛说了个可能是特殊的账号导致的，但是，由于数据量太大，因此也不能确定。然后还有一个方案，配置了一下Hadoop的mapreduce的的内存，认为有可能是默认太小导致的，但是发现还是不OK；然后就分析因为是订单数据，用户账号应该不会为空，就排除了这种排查；下面就是终极方案，把pin维度拆成campaign维度来操作，然后就开始写程序了。

 

写了程序，逻辑不能改造，最重要的是要保证输出的schema和原来的保证一致，纠结了好久，然后就改呀改呀改呀，最终还没有改好；我就又去请求大牛了。去之前我先去让C君确认一下昨天改的随机生成id的feature是OK的，问了一下数据量，然后他说这次修复，也就是增加了10%以内的数据，然后我就开始怀疑不是数据量增大的问题。从大牛那回来以后，我就开始check我的订单数据里面的pin，老大也跟我说越来越感觉不是数据量的问题，然后他就开始check曝光数据。后来，我发现了订单里面有个pin为0，我就让老大看看曝光数据里面有多少pin为0的曝光，后来一个shell执行完了，发现问题已经水落石出了，一天的曝光里面pin为0的量为40w，然后要加载70天的数据，这样算下来是2800w，尼玛，这不内存溢出就怪了。后来发现这个pin为0的订单是正常的，曝光数据里面应该是有错误上报的，上报了很多的0，正好那个人在10月19号买了东西，有了订单，这样这个bug暴露出来了。。继续check，想为什么以前没有问题，因为19号的数据跑了很多次了，后来发现是由于C君在自己的pig脚本里面进行了这个过滤，但是昨天让他改成使用UDF来判断，但是UDF里面没有对这个0的情况进行过滤，导致昨天晚上跑任务暴露出来了这个bug。虽然0 pin是正常的，但是曝光里面不正常，所以就丢去这一个人影响也不大。然后就过滤了pin。

 

最终，纠结的一天过去了，今天也上不了线了。然后我跑了下程序，不到5分钟一天的数据跑完了。。

 

最终总结了一下：

1. 初期的数据调研很重要，哪怕花现在的两倍或者三倍时间都值得，因为现在已经跑了三四次数据了

2. codereview的重要性，如果大家都遵守约定，提交cr，这样的话UDF里面就不会漏掉0这个pin了

3. 排查问题要进行多方面的了解，如果我了解到只是增加了10%，那么我就会直接找特殊情况了，本来我以为是两倍或者三倍了

4. 加强沟通，前期不沟通，后期的修改成本是很高的

5. 架构的设计，设计一定要合理，否则会出现工作量加重后者难以扩展的情况

6. 二八原则，编码只占20%，其他占80%

 

最近很苦逼，但是痛并快乐着

 

下面是我的一个个人公众帐号，微信扫一扫，可以关注一下哦～