搜索
查看: 424|回复: 0

我的大数据工作经历

[复制链接]

1

主题

0

回帖

0

好友

新手上路

发表于 2024-5-30 11:48:01 | 显示全部楼层 |阅读模式
我今年42了,离开大厂也有四年的时间了。这四年时间主要是自己瞎玩、带娃。最近加入了学会,觉得有必要把自己从2006年到2020年的数据工作做一些记录,尤其是遇到的问题,给分享出来,也算是一个数据从业者的小路书吧。

1. 2006-2008年在中国雅虎
我2006年校招加入了当时的中国雅虎,我是数学系毕业的,说实话计算机能力是水得不能再水,我也没想到能够面试通过。也因为中国雅虎在2005年已经被阿里巴巴收购了,所以那时候已经算是阿里的员工了,阿里也算慷慨,竟然还给了我们这帮应届生一点点的期权。我记得我当时的阿里工号是6816。后来我入职后专门问了面试我的同事,他当时诡异的一笑,说因为当时太缺人了。原来2005年周鸿祎把中国雅虎的人带走了很多,尤其是工程师,所以我这种人也就被招进去了,这里面更戏剧的是当时我原本是被分配去了SNS部门做PHP开发,后来据说是当时CTO谭晓生看了我是数学系毕业的,就给我临时调配到了数据部门,所以当时我特别尴尬,给我分配的入职导师不在我的实际工作部门,导致有半个月时间我没事儿干。
在雅虎的日子,最值得怀念的事情是:美国yahoo的内部技术和项目知识库(被叫做backyard)对我们是完全开放的。也就是说,除了特别机密的技术资料和项目之外,美国yahoo的所有技术文档和项目我都可以看到。当时对我来说真的是一个技术宝库啊,而这个时候我的菜鸡身份反而成了优势,因为我的脑子完全是空白啊,对于当时最先进的互联网技术和工程实践的学习完全没有任何的偏见和惯性思维。yahoo 2005年的时候把Dough Cutting也就是hadoop的开发作者招聘进去了,yahoo的搜索部门记录了大量的使用hadoop进行分布式数据处理的文档。而这个时候阿里也好、中国雅虎我们数据部门也好,要不是用手写的perl脚本,要不就是用oracle数据库做数据统计呢。是有巨大代差的。而当时雅虎中国数据部门最头痛的问题就是数据的汇总统计总是不稳定、不及时,扩展计算和运维非常困难。我当时所在的tiger team就接了一个有挑战性质的工作,尝试能否使用hadoop进行分布式的数据处理。惭愧的是,从那个时候开始我才正式开始阅读计算机方向的专业论文,Google的MapReduce论文。
现在回头来看,我当时的学习环境简直太好了:一是我可以看到yahoo美国搜索team的大量实践应用的案例和项目文档记录,能够快速知道hadoop的问题和能力。二是yahoo美国日志team在大规模数据处理方面的大量内部文档和工具设计,尤其是他们内部自研了一个叫做MyNa的分布式日志处理系统。再配合起google的map reduce论文,毫不夸张的说,当时国内知行合一最好的大规模数据处理应用学习环境就在我的team了。当我对论文中间的描述有些似是而非的时候,我就可以去yahoo内部的hadoop文档里面去找对应的设计实践,当我对hadoop的设计实践有些疑问为什么要这么搞的时候,我又可以去看MyNa的一些项目记录,了解到实际的工程过程中的具体场景。所以当时我经常是在公司呆到晚上11点之后,就为了看资料。
当时tiger team里面做了一下分工,我负责探索hadoop,因为美国yahoo日志team主要用MyNa,所以我相当于B方案做策应,团队主要的希望还是放在另外一个同事去落地MyNa在国内的部署。我记得当时有个印象特别深刻的事情是:有一天周会,负责MyNa的同事提到他们遇到一个诡异的问题,就是系统有一定几率会出现segfault崩掉,看起来是内存不足造成,但是由于MyNa代码非常复杂,一时间没法定位到问题。我当时脑子突然出现一个灵感,MyNa本质上也是一个类似Map-Reduce架构的系统,会不会和hadoop一样,是因为key值造成的数据倾斜导致的问题,我就鼓起勇气说了自己的看法。后面他们按照这个思路去排查,发现还真是这个原因。我很高兴啊,因为切实感受到原来合理的架构设计和算法设计在一些场合是比代码编写能力更重要的,尤其是这种复杂的分布式数据系统。后来在团队leader的支持下,我搭建了一个独立的hadoop小集群,也就只有2台机器,用来处理雅虎的NCP业务的数据。这个系统直到后来中国雅虎关闭,都还能正常运行。这应该是hadoop在国内最早的数据处理场景的工业落地了。不过我在代码方面的能力实在是太菜了,起了个大早,赶了个晚集。没有能力成为hadoop的contributer在开源社区去贡献自己的力量。
在差不多同时,还配合了yahoo美国在中国部署Data highway项目,这是一个准实时的全球数据采集系统,在2007年的中国互联网业界,简直是超前的不能再超前了。我花了很多时间去看data highway的设计文档,和项目落地过程中的各种会议记录。算是一个祛魅过程,让我知道海量的数据是可以用实时采集系统+高吞吐量处理系统结合起来处理的,这个平台系统具备足够的通用性和扩展性,而不再是我们自己在公司用perl语言编写单机处理脚本那样漏洞百出。
随着各种数据处理任务越来越多,数据任务间开始出现依赖关系了,我的这个数据任务是需要另外一个同事的先导任务完成才可以开始,同时这些数据任务的监控报警也是一个麻烦事情。我记得当时我写的一个定时计算任务,由于前置任务比较大,产出时间时快时慢,我的任务总是没办法稳定的按时正确执行,每天早上总是能收到大量的报警要手动处理,而且有一次我还写错了报警逻辑,代码一口气给我发了上千条报警短信,那天我的手机别的事情干不了就在那里震动收报警短信了。我调研了一番,发现无论是yahoo美国还是开源系统都没有一个轻量级的数据任务调度和监控报警的工具,也是初生牛犊不怕虎,就和我另外一个同事波波配合,主动领下一个任务去从头开发他,我负责做设计,波波代码能力特别好,他负责核心代码,我负责打下手。
回复

使用道具 举报

您需要登录后才可以回帖 登录

手机版|CCF Link ( 版权所有 中国计算机学会  京ICP备13000930号-4|京公网安备 11010802032778号   )

GMT+8, 2025-4-26 23:21 , Processed in 0.046775 second(s), 20 queries .

快速回复 返回顶部 返回列表