之前写过了大数据开发的岗位选择以及数据岗位的学习路径。
岗位选择:https://www.nowcoder.com/discuss/462382334675779584?sourceSSR=users
学习路径:https://www.nowcoder.com/discuss/463804300381245440?sourceSSR=users
但对于还处于比较迷茫,不知道是否要投入到大数据的怀抱的同学,其实还希望了解到大数据开发每天的真实工作是哪些,想到我也刚结束一段实习、大家很多正在火热的准备暑期实习,所以顺便写一下实习的情况吧。
1 实习
入职:入职当天,半天进行入职培训,然后下午就是在开通各种权限,包括工具权限、文档权限、平台权限等等。或者是申请各类账号,通常而言公司对于实习生的权限管控较为严格,很多时候申请需要和自己的直属主管(leader)打好招呼。
导师:不同的公司有不同的叫法,大部分是叫mentor、网易叫buddy、阿里叫师兄。不论叫什么,作用都是一样的,所有工作和生活上的问题都可以请教自己的导师,整个实习期间基本也是由导师安排你的工作和学习计划。建议在入职第一周内和mentor以及leader单独聊一次,一方面相互了解,另一方面确定自己实习的整体计划和工作安排。不要害怕提问!!mentor是你最好的资源!!
熟悉环境:这部分分为两个一个是熟悉团队,了解团队的人员分配、组织架构以及大家所负责的领域,其实很难一下子记住,建议只记住一些小组长之类的人,这样起码有相关问题知道找谁。第二个是熟悉工作中要用到的工具、平台,比如数据开发的像网易的猛犸、阿里的DataWorks等等,工欲善其事必先利其器嘛。
当然还要包括企业文化,隐私,安全(数据安全和人身安全),反腐,基础知识学习
熟悉业务:衡量数据开发一段实习的质量,最主要的就是对整个数仓的理解,换言之就是对业务的熟悉程度辣。现在一般的公司和团队都会维护自己的数仓资产白皮书,这是了解数仓的最好入门方式,在有了整体的框架后,有机会也可以去和各个数据域的负责同学或者数分业务同学单聊。这些对于之后简历的包装以及面试都是很有帮助的。
需求开发:通常而言,在基本了解了开发流程以及基础的平台使用后,就会安排一些小的需求啦。然后慢慢的随着对业务和开发能力的提升,就会逐渐派一些大活,甚至后续需要自己独立接需求(包括评审、开发、测试)了。不过,需求开发的时候有任何问题还是要去和mentor讨论哦。
如果大家有兴趣,下一篇就写一下大数据需求开发的全流程
周报日报:一般团队都会要求新人或实习生写每日日报(今日工作、明日计划、总结思考)、以及周报(周报是所有人都要写的),一般而言会要求邮件抄送给整个团队,或者专门放在团队的共享文档中,所以也不能瞎写。leader偶尔闲了会想看一下实习生最近在忙啥。
开会:一天开好多会,有时候真的不是为了卷加班,而是白天一直在开会,晚上才有时间坐下来写代码做开发。。
2 工作
2.1 oncall
![](https://i-blog.csdnimg.cn/blog_migrate/403f2b63ffb1fc6f54fa1ded627ad0de.png)
如翻译可见,oncall就是随时待命、随叫随到
实际上,在互联网公司中,大数据开发是个需要值夜班的岗位。因为数据调度的任务基本都是在凌晨进行调度,所以一旦晚上任务出了问题,需要值班同学及时处理以确保基线稳定产出。同样的,比如支付宝崩了、微博删热搜,哪怕是大半夜也得有人来处理,所以一旦线上数据有问题反馈对应的owner就得及时处理。
由于楼主之前实习负责过一些流量域的业务,而流量域恰恰是数据问题的重灾区,就比如商户的曝光pv小于商户的曝光uv。一般而言的处理流程如下,开始oncall:
用户向客服小二反馈数据问题
小二无法解决,建群拉产品,向产品阐述问题
PM发现是数据问题,找到对应数据域的负责的大数据开发同学(ads层同样有owner划分)
ads 层开发的同学把后端开发拉进群,让后端开发的人是否出现问题(先排除数据接口的问题):后端开发出问题:问题解决。后端开发没出问题:提供后端查询的 SQL 语句。
数据开发的同学拿这个 SQL 看表是否有问题。
发现表有问题,查生成表格的 SQL 是否有 bug:有 bug:修改,问题解决。没 bug:查这个 SQL 中 SELECT FROM 的表格,假如是 dwd 层。
把 dwd 层的数据开发拉进群。
dwd 层的数据开发进行上面一样的操作,查生成表格的 SQL 是否有 bug:有 bug:修改,问题解决。没 bug:查这个 SQL 中 SELECT FROM 的表格,假如是 ods 层。
把 ods 层的数据开发拉进群。
ods 层的数据开发进行上面一样的操作,查生成表格的 SQL 是否有 bug:有 bug:修改,问题解决。没 bug:埋点出现问题。
拉出埋点日志明细,把埋点的前端开发拉进群。
查到问题:反馈给 PM,PM 反馈给客服小二,客服小二反馈给用户。
基本每次排查问题都需要群里拉一堆人,然后相互排(甩)查(锅)问题,数据问题排查真的是极其耗时,基本每次少则半天多则一两天。
2.2 重构
重构顾名思义就是将原有的表下线、重新构建一个既能包含原有字段又能满足新业务发展的模型。当然有的时候也有原来的代码实在是太依托答辩,所以需要进行优化。而在数仓当中,一张中间表的重构,比如dws层,会涉及到一大堆的下游任务,dws层、ads层任务的切换,所以要十分慎重,对于数据的一致性要求极高。
重构的好处在于统一指标,让表格更合理,更方便管理。另外缩短运行时间。
比如:
ods → 90 分钟 →tb1
tb1 → 30 分钟 → tb2
最终耗时:90 + 30 = 120 分钟
我们将tb1拆解为两个新表tb3、tb4,改用新表之后:
ods → 30 分钟 → tb3
ods → 40 分钟 →tb4
2 个 新 dwd 表 → 50 分钟 → tb2
最终耗时 max(30, 40) + 50 = 90 分钟
这样就节约了30min
2.3 迭代
模型的迭代一般就是在现有模型上进行操作:
新增维度:常见的比如说现在大老板希望能看到不同时段用户的购买情况,划分为:上午、下午、晚上、深夜、凌晨,那么就需要从最原始的代码中底层开发增加这个维度,而且一旦是cube型的模型,还需要和BI确定好分析的维度,因为如果增加所有的分析维度,数据的计算量可能会呈倍数增长
新增指标:通常就是将原模型中没有的指标计算出来,有的时候需要从新的dwd表计算增加上游依赖,大部分时候直接从原有的上游依赖增加计算逻辑即可。比如原来BI只关心商户的曝光uv、pv,现在他们想看商户的引导uv、pv那么就需要新增这两个指标。
口径变更:在阿里经常会存在组织结构的变化(业务的组织结构),比如原来的业务线分为商超、果蔬、便利店,现在要划分为,大商场、水果生鲜、买菜、便利店,那么在数据模型中对应的口径也需要变化,以便于业务方使用数据。
通常而言,模型的迭代较为快速,只要与需求方确认好口径即可。
2.4 新模型
这个工作周期长,难度大,需要和 PM、QA、RD、UI 等等很多人合作
1.角色
新模型都是大活,从 0 到 1,可能开发周期一两个月甚至更长。在此之前先了解一下工作中的角色:
PM(Product Manager):产品经理,负责提需求;
RD(Research and Development):研发,包括前端,后端,数据研发;
QA(Quality Assurance):测试,开发完测试有没有 bug;
DA(Data Analyst):数据分析师。
2.评审
了解了角色,下面就看做需求的整个流程:
需求的来源:其一:用户提给 PM 提要求,想要看什么数据(比如日活);其二:PM 对照其他公司的竞品抄一个过来;其三:PM 自己拍脑袋想出来。
DA 先验证这些指标是否有用。
确认有用,PM 提出需求,写 PRD(Product Requirements Document)。
需求初评会议:由 PM 发起,概述背景、收益及产品方案;数据研发侧对数据探查、工作量评估、人力评估;
数据研发侧确定人力(即 leader 安排谁来干这个活)。(此时前端、后端、测试也确定了人力)
各方对齐时间节点。
需求详评会议:PM,RD,QA进行数据详评;明确时间范围、指标口径、周期等。
3.研发
开始研发,具体步骤如下:
新指标录入管理系统(保证每个指标在每次使用时的英文名称统一,即一致性);
数据 Owner 与各方沟通,出方案(包括数据从哪个表产出,如何关联,最终产出多少个表,最终数据从 Hive 推到 Elasticsearch 还是 ClickHouse,这里是重点,很复杂,后面再讨论);
技术评审:所有数据研发参与,数据 Owner 讲自己的技术方案,其他数据研发看合理性以及是否有问题;
排期,多少天做完;
开发;
自测;
QA 参与测试,数据研发根据结果修改 bug;
4.上线
测试完成之后,还要与前后端联调:
QA 出具测试报告;
回溯历史数据;
与前后端联调;
上线。
5.复盘
统计资源消耗、数据量、任务运行的时间等等。
到此一个新模型的需求堪堪结束,但实际上这才是潘多拉的盒子,随后就是无穷无尽的oncall、迭代、回溯。。。
2.5 回溯
数据回溯也称为补数据,通常而言这是大数据开发工作中最为耗时耗力的工作板块。比如我们对对模型进行了迭代,或者上线了一个新模型,那么下游业务方希望能看到以前的数据,比如前一年的数据,进行年环比,那么就需要对历史数据进行回刷,需要注意以下:
检查代码是否有需要改动?(例行任务和回刷任务可能有的代码需要改变)比如:MaxCompute上常用MAX_PT函数,那么如果下游不考虑数据精度,就不用修,否则就得按照dt去回刷
上游任务时候满足回刷历史数据分区,比如我要回刷到2021-01-01,但上游表只有2022-01-01的数据,那么就要考虑是否要把上游一起刷了,或者直接用最近的数据去回刷
回溯时并行度应该开多少?(资源是很紧张的,不能乱开并行,而且存在自依赖任务)
开始回溯时要时刻盯着队列资源,队列资源多的时候可以增加并发。关于队列可以看之前的文章,关于 Yarn 队列如何进行调度。
2.6 同步
数据模型产出后,需要要供给到BI报表或者后端使用,还需要将数据同步,毕竟不管是报表还是其他业务使用都是要考虑数据查询速度的,所以一般会用一些OLAP,比如ClickHouse、PG等等,所以数据产出后,还要将数仓中的数据推到OLAP中,不过这个一般较为简单、通过平台工具即可。
以上就是大数据开发的一些日常工作啦,不过上述只是从大的角度上去写了一下,其实像其中涉及到的开会、数据测试、数据探查都是极其枯燥并且无法逃脱的,80%的时候都要投入进去,而且每一个模型都是在不断的修改、所以这也就是为什么大数据开发对模型设计能力要求较高。
希望大家看完本文对大数据开发日常工作有一定认识,是不是真的愿意在这样的工作中投入热爱和激情(虽然听说后端也是crud),但相对而言我个人感觉数据工作是最难有成就感的了,数据毕竟是冰冷的,而且也不会有实际功能的产出。