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

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

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

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

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

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

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

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

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

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

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

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

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

如翻译可见，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 反馈给客服小二，客服小二反馈给用户。

基本每次排查问题都需要群里拉一堆人，然后相互排（甩）查（锅）问题，数据问题排查真的是极其耗时，基本每次少则半天多则一两天。

重构顾名思义就是将原有的表下线、重新构建一个既能包含原有字段又能满足新业务发展的模型。当然有的时候也有原来的代码实在是太依托答辩，所以需要进行优化。而在数仓当中，一张中间表的重构，比如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

模型的迭代一般就是在现有模型上进行操作：

新增维度：常见的比如说现在大老板希望能看到不同时段用户的购买情况，划分为：上午、下午、晚上、深夜、凌晨，那么就需要从最原始的代码中底层开发增加这个维度，而且一旦是cube型的模型，还需要和BI确定好分析的维度，因为如果增加所有的分析维度，数据的计算量可能会呈倍数增长

新增指标：通常就是将原模型中没有的指标计算出来，有的时候需要从新的dwd表计算增加上游依赖，大部分时候直接从原有的上游依赖增加计算逻辑即可。比如原来BI只关心商户的曝光uv、pv，现在他们想看商户的引导uv、pv那么就需要新增这两个指标。

口径变更：在阿里经常会存在组织结构的变化（业务的组织结构），比如原来的业务线分为商超、果蔬、便利店，现在要划分为，大商场、水果生鲜、买菜、便利店，那么在数据模型中对应的口径也需要变化，以便于业务方使用数据。

通常而言，模型的迭代较为快速，只要与需求方确认好口径即可。

这个工作周期长，难度大，需要和 PM、QA、RD、UI 等等很多人合作

新模型都是大活，从 0 到 1，可能开发周期一两个月甚至更长。在此之前先了解一下工作中的角色：

PM（Product Manager）：产品经理，负责提需求；

RD（Research and Development）：研发，包括前端，后端，数据研发；

QA（Quality Assurance）：测试，开发完测试有没有 bug；

DA（Data Analyst）：数据分析师。

了解了角色，下面就看做需求的整个流程：

需求的来源：其一：用户提给 PM 提要求，想要看什么数据（比如日活）；其二：PM 对照其他公司的竞品抄一个过来；其三：PM 自己拍脑袋想出来。

DA 先验证这些指标是否有用。

确认有用，PM 提出需求，写 PRD（Product Requirements Document）。

需求初评会议：由 PM 发起，概述背景、收益及产品方案；数据研发侧对数据探查、工作量评估、人力评估；

数据研发侧确定人力（即 leader 安排谁来干这个活）。（此时前端、后端、测试也确定了人力）

各方对齐时间节点。

需求详评会议：PM，RD，QA进行数据详评；明确时间范围、指标口径、周期等。

开始研发，具体步骤如下：

新指标录入管理系统（保证每个指标在每次使用时的英文名称统一，即一致性）；

数据 Owner 与各方沟通，出方案（包括数据从哪个表产出，如何关联，最终产出多少个表，最终数据从 Hive 推到 Elasticsearch 还是 ClickHouse，这里是重点，很复杂，后面再讨论）；

技术评审：所有数据研发参与，数据 Owner 讲自己的技术方案，其他数据研发看合理性以及是否有问题；

排期，多少天做完；

开发；

自测；

QA 参与测试，数据研发根据结果修改 bug；

测试完成之后，还要与前后端联调：

QA 出具测试报告；

回溯历史数据；

与前后端联调；

上线。

统计资源消耗、数据量、任务运行的时间等等。

到此一个新模型的需求堪堪结束，但实际上这才是潘多拉的盒子，随后就是无穷无尽的oncall、迭代、回溯。。。

数据回溯也称为补数据，通常而言这是大数据开发工作中最为耗时耗力的工作板块。比如我们对对模型进行了迭代，或者上线了一个新模型，那么下游业务方希望能看到以前的数据，比如前一年的数据，进行年环比，那么就需要对历史数据进行回刷，需要注意以下:

检查代码是否有需要改动？（例行任务和回刷任务可能有的代码需要改变）比如：MaxCompute上常用MAX_PT函数，那么如果下游不考虑数据精度，就不用修，否则就得按照dt去回刷

上游任务时候满足回刷历史数据分区，比如我要回刷到2021-01-01，但上游表只有2022-01-01的数据，那么就要考虑是否要把上游一起刷了，或者直接用最近的数据去回刷

回溯时并行度应该开多少？（资源是很紧张的，不能乱开并行，而且存在自依赖任务）

开始回溯时要时刻盯着队列资源，队列资源多的时候可以增加并发。关于队列可以看之前的文章，关于 Yarn 队列如何进行调度。

数据模型产出后，需要要供给到BI报表或者后端使用，还需要将数据同步，毕竟不管是报表还是其他业务使用都是要考虑数据查询速度的，所以一般会用一些OLAP，比如ClickHouse、PG等等，所以数据产出后，还要将数仓中的数据推到OLAP中，不过这个一般较为简单、通过平台工具即可。

以上就是大数据开发的一些日常工作啦，不过上述只是从大的角度上去写了一下，其实像其中涉及到的开会、数据测试、数据探查都是极其枯燥并且无法逃脱的，80%的时候都要投入进去，而且每一个模型都是在不断的修改、所以这也就是为什么大数据开发对模型设计能力要求较高。

希望大家看完本文对大数据开发日常工作有一定认识，是不是真的愿意在这样的工作中投入热爱和激情（虽然听说后端也是crud），但相对而言我个人感觉数据工作是最难有成就感的了，数据毕竟是冰冷的，而且也不会有实际功能的产出。