这两天工作上发生了一件事,让我很难平静

这两天工作上发生了一件事,让我很难平静。

过年前最后一天(我买了五点半的电影票打算早走的,我知道过年前是最后能刷R1的时候)。下午三点的时候发现来了一个High priority的ticket,是一个中国cube的ETL挂在cube process上了,是比较基本的问题。我就先开了profiler看process的错误。很快发现是process measure group P的时候报了个numeric overflow bigint的错。然后我就想办法在那个partition找哪个数据的值超长了。看了一下P的view的定义,只看到一个column是bigint,再仔细一看这个column的定义,我记起来别的cube的这个column曾经也出过一样的错。这个column的设计本来就有点奇怪,把store_key, item_key和一个measure X的值concat起来(当中有2个0间隔)再转bigint。按照我们系统目前的store_key, item_key的位数来看,measure X只要超过两位数就会overflow。然而当时PM说,这个measure只能是0到5六个值。估计是开发看了这个需求,也没想过可能需要处理超长的效果。(去年11月的时候我第一次遇到这个问题时,我的第一反应是把这个问题给DEV,因为这样危险的设计在我看来很可怕。在和QA确认的时候才得知还有限制0到5这回事。)

当时我急着赶电影,我就回复了一下:“这和ticket XXX是一样的问题。X数据只能是0到5。可是现在我们有42002这么大的数据。请检查一下是不是又重复load了文件。我已经关闭了这个silo的ETL。”这一句重复的文件的猜测,是因为去年我检查这个问题的时候,时间比较充裕,就顺便检查了一下数据源的历史记录,发现了重复的文件。实际上,这一次不一定是同样的原因造成数据过大。然而我想,是个operation(他们天天看数据,天天set up文件load)都会明白,接下来就该是他们去修复数据了。

春节值班的时候,我特意留意了一下这个ticket,我惊讶地发现他们没有更新。我猜是因为没人看见我说我关了ETL,所以它没有继续报错,所以没人注意到这件事。于是我把ETL又开了。(我们的产品环境就是这么混乱。)

隔了几天我又值班,发现operation看到了这个ticket,然而第一个回复是(一个脑子比较僵硬的中国男operation):“我没有看到有重复文件,所以根XXX应该不是一样的问题,请再看看为什么cube process挂。”在我之前值班的开发同学M回复说:“为了跑过去,我已经从DB里删了数据,并且把删的数据存在了table_name_bak里。”这里的table_name是我们基本的measure group A。接下来,是operation老大吩咐美国的operation把坏的数据用正确的方法unload掉。

年后上班这个ticket仍没有解决,并且变成了urgent回到我头上,而问题还是原来那一个。不过加上了最近有过attribute变动,变成如果要process,是把所有partition都要process才能过去。这个cube属于之前中国特殊数据load,为了缩短上线时间,他们把这个retailer的数据全都做了redundant load,实际客户看到的数据只有我们load的数据的十分之一都不到,所以full process很慢。负责monitor新数据load的operation女生不知道这些,因为是周一ETL总体很忙,她无法在数据源unload数据。于是她一个劲催我也删一下数据嘛。

我的各种本能都告诉我不该在产品环境删数据。以前我的经理是BI开发的经理,如果他在我会跟他聊几句,肯定会避免发生接下来的事情。现在我的经理是APP开发经理,他的BI经验其实不多,我就没想跟他聊(实际上他虽然看所有的urgent ticket,但也并没有明白我实际上后来犯了个错)。

事实就是,我知道这是numeric overflow;我知道>5的数据都不对(进了cube也会因为dimension没有而不显示),虽然如果是8这样的值还不会造成overflow报错;operation一直在跟我强调过年值班的开发M同学删了数据后面就process进去了。“你看他那时回复的呀!”我有一种如果我不删数据,我就没有M同学有能力的压力。(实际上,M也是有技术但没有产品sense的人,在BI的方面,经验也是比我差一截。然而他是开发我是产品技术支持,而且他是男生,男生的无知自信对技术和产品sense差一些的人来说,就等于强大,不幸的是我们公司都是这样的人。)我还有一半的思绪在想如果要对这么大的表删数据,性能会不会很可怕。

结果我就按照M说的,把measure group A的不合法数据删了。

接下来是7小时的full process。

昨天早上上班的时候,我看到晚上的process挂了。我幡然醒悟:造成overflow的数据是measure group P的。P是从A算出来的。等于我删数据并没有帮助数据process成功,反而耽误了一天的时间。

我把这一点告诉了operation的女生,她还疑问:为什么M删了以后就process成功了呢?要么是M其实删了P的数据。如果要删P数据,鉴于它的计算逻辑非常复杂,如果暴力删数据会造成什么情况我说不清。我当时是觉得M一定是删了P的数据,因为他对P的逻辑肯定没有我熟悉,所以因为无知无畏而删是有可能的。后来仔细看超级长的ticket,我才发现更合理的解释是美国的opertaion当时unload掉了错误的数据(P会在ETL中重新计算一遍),只不过新的错误数据又来了。请operation按照正常的手法unload数据才是正确的做法,是我一开始的建议,但是在催促和担心自己看起来没有男开发一样的本事,再加上没有人来管我,我做了一个错误的操作。

现在,在我的坚持下,operation终于退回去修了数据,现在cube process终于跑过去了。

这个错误并没有引起任何关注。这件事的后果只是,本来delay了7天的数据多delay了一天。我的经理没发现我做错了,operation还没有来责怪我,我估计也不会。因为在我们其他的产品支持工程师里,比我这个错厉害很多的错多了去了。我一直在配合大家工作的同时,默默尽力坚持我的标准。这个错已经不是第一个让我觉得“啊,我现在怎么标准降低这么多啊?”的事件了。

一方面没受到指责,也更说明管理的混乱。另一方面,我自己也很难原谅自己犯了一个可以避免的错误。我从一开始对问题的鉴别,和对解决问题的建议都是正确的。我们公司的管理太fucked up才造成我从这么正确的起点开始都能走到错误的操作。

Leave a Reply

Your email address will not be published. Required fields are marked *