【实习总结】大数据开发的日常工作

之前写过了大数据开发的岗位选择以及数据岗位的学习路径。

岗位选择：https://www.nowcoder.com/discuss/462382334675779584?sourceSSR=users

学习路径：https://www.nowcoder.com/discuss/463804300381245440?sourceSSR=users

但对于还处于比较迷茫，不知道是否要投入到大数据的怀抱的同学，其实还希望了解到大数据开发每天的真实工作是哪些，想到我也刚结束一段实习、大家很多正在火热的准备暑期实习，所以顺便写一下实习的情况吧。

1 实习

1. 入职：入职当天，半天进行入职培训，然后下午就是在开通各种权限，包括工具权限、文档权限、平台权限等等。或者是申请各类账号，通常而言公司对于实习生的权限管控较为严格，很多时候申请需要和自己的直属主管（leader）打好招呼。

2. 导师：不同的公司有不同的叫法，大部分是叫mentor、网易叫buddy、阿里叫师兄。不论叫什么，作用都是一样的，所有工作和生活上的问题都可以请教自己的导师，整个实习期间基本也是由导师安排你的工作和学习计划。建议在入职第一周内和mentor以及leader单独聊一次，一方面相互了解，另一方面确定自己实习的整体计划和工作安排。不要害怕提问！！mentor是你最好的资源！！

3. 熟悉环境：这部分分为两个一个是熟悉团队，了解团队的人员分配、组织架构以及大家所负责的领域，其实很难一下子记住，建议只记住一些小组长之类的人，这样起码有相关问题知道找谁。第二个是熟悉工作中要用到的工具、平台，比如数据开发的像网易的猛犸、阿里的DataWorks等等，工欲善其事必先利其器嘛。

当然还要包括企业文化，隐私，安全（数据安全和人身安全），反腐，基础知识学习

4. 熟悉业务：衡量数据开发一段实习的质量，最主要的就是对整个数仓的理解，换言之就是对业务的熟悉程度辣。现在一般的公司和团队都会维护自己的数仓资产白皮书，这是了解数仓的最好入门方式，在有了整体的框架后，有机会也可以去和各个数据域的负责同学或者数分业务同学单聊。这些对于之后简历的包装以及面试都是很有帮助的。

5. 需求开发：通常而言，在基本了解了开发流程以及基础的平台使用后，就会安排一些小的需求啦。然后慢慢的随着对业务和开发能力的提升，就会逐渐派一些大活，甚至后续需要自己独立接需求（包括评审、开发、测试）了。不过，需求开发的时候有任何问题还是要去和mentor讨论哦。

如果大家有兴趣，下一篇就写一下大数据需求开发的全流程

6. 周报日报：一般团队都会要求新人或实习生写每日日报（今日工作、明日计划、总结思考）、以及周报（周报是所有人都要写的），一般而言会要求邮件抄送给整个团队，或者专门放在团队的共享文档中，所以也不能瞎写。leader偶尔闲了会想看一下实习生最近在忙啥。

7. 开会：一天开好多会，有时候真的不是为了卷加班，而是白天一直在开会，晚上才有时间坐下来写代码做开发。。

2 工作

2.1 oncall

如翻译可见，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），但相对而言我个人感觉数据工作是最难有成就感的了，数据毕竟是冰冷的，而且也不会有实际功能的产出。