最近一段时间,再做一个用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%
最近很苦逼,但是痛并快乐着
下面是我的一个个人公众帐号,微信扫一扫,可以关注一下哦~
相关推荐
【标题】:“记一次灵异般的 Bug 调试经历1” 【描述】:这篇文章讲述了作者在Quora上的一个热门经历,他受雇于一位心理学家修复一款输出异常的软件,该软件由其前任研究生编写。软件会在用户交互时显示不友好的潜...
GoBug是一款专为Go语言设计的32位调试工具,它简化了对Go程序进行调试的复杂性,使得开发者可以更高效地定位和解决问题。在本文中,我们将深入探讨GoBug的功能、使用方法以及它在Go语言开发中的价值。 首先,了解Go...
fire-bug调试
总的来说,这篇文章不仅是作者个人经验的总结,也是对整个行业在软件开发和调试中可能遇到的普遍问题的深刻反思。通过这些经验教训,读者可以学习如何更加全面和系统地思考问题,减少bug的发生,提升代码质量。对于...
嵌入式系统开发领域的码农们在面对bug调试时,有许多特有的技巧和经验需要掌握。本文将结合作者十年的嵌入式开发经验,分享一些在编码、测试和调试阶段减少bug的有效方法。 首先,嵌入式系统与传统PC软件的主要区别...
本篇文章将详细探讨Firefox的bug调试工具,特别是其JavaScript(JS)调试功能。 Firefox的调试工具,最经典的版本就是Firebug,它是一款开源的网页开发与调试插件。虽然现在Firefox已经将其功能整合到内置的开发者...
firefox bug (调试工具) 工具->附件添加
还有一种情况是Bug的隐蔽性和周期性,即某些Bug可能因其他Bug的存在而未被执行,需要多次修复和测试才能发现。 软件Bug的危害不可忽视。根据2002年美国国家标准技术研究所的报告,美国每年因Bug损失达595亿美元,占...
电子-嵌入式码农的10年Bug调试经验.zip,单片机/嵌入式51单片机
总之,这个“串口调试的好工具”是一个为串口通信提供便利的实用软件,它的稳定性和无BUG特性使得它在实际应用中备受信赖。对于需要进行串口调试的工程师而言,拥有这样一个工具将大大提高工作效率,减少调试过程中...
与单片机Bug战斗的经历教会了我们一个重要道理:优秀的调试技巧和严谨的编程习惯是解决问题的关键。通过合理地利用串口监控、细致的注释以及规范的命名规则,我们不仅能够更高效地解决编程过程中遇到的问题,还能在...
如何处理测试中发现的BUG软件测试软件测试的主要目的在于发现软件存在的错误(Bug),对于如何处理测试中发现的错误,将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误,才能消除软件错误,保证要发布的...
我们写好的程序在生成exe后,直接运行exe程序崩溃了,但又不好断点调试exe程序,除了在程序中添加log进行查看,还有一种实用的方法就是dump调试,专门针对exe运行崩溃的一种调试。它可以在exe崩溃后自动生成一个dump...
Bug管理系统源码 项目管理 模块管理 人员管理 角色管理 我的主页 组员-- 查看Bug并解决Bug 组长-- 查看Bug并解决Bug,查看未分配Bug&def已解决的Bug 角色: 组长 组员(开发&def测试) new Assigned Resolved ...
标题:“内核208天bug分析”描述:“腾讯大神写的内核timer调试笔记,典型的208天才重现一次的bug调试技巧” 知识点: 1. 内核bug现象:从描述中提到这是一个典型的内核bug,该bug表现形式为每208天重现一次,这种...
标题中的“网络调试助手测试没有bug”表明我们讨论的是一款用于网络调试的软件工具,它在测试阶段表现良好,没有发现任何错误或异常,即“bug”。这通常意味着该工具的功能稳定,性能可靠,能够有效地帮助用户进行...
给你一个项目,你如何开展测试工作 进销存项目的大小和(测试)规模 你负责哪部分的测试,怎么测的,和其他模块的关系有哪些 ...你发现了哪些印象深刻的Bug,举例说明 项目中你遇到了哪些困难,是如何解决的
【Eclipse调试Bug的七种常用技巧】 在软件开发过程中,调试是不可或缺的一部分,尤其是在使用Eclipse这样的集成开发环境(IDE)时。Eclipse提供了多种强大的调试工具和技术,帮助开发者快速定位并修复问题。以下是...
根据提供的标题、描述以及部分无法正常解析的内容,我们可以推断这篇文章是关于一次特别的编程错误(bug)经历。虽然原始内容包含大量无法识别的字符,但通过标题和描述,我们可以构建一篇关于处理复杂或罕见编程...
在IT行业中,"Bug"一词是程序员和软件开发者们最熟悉的术语之一。它指的是软件中存在的错误、缺陷或不正常的行为,这些问题可能导致程序运行出错、功能失效或者用户体验下降。"Bug奋斗史汇总"这一标题揭示了我们将要...