刚进组的时候，别人问我数据研发工程师做什么，我只能含糊的说就是写SQL，等到跟着项目跑了两个迭代，才发现远不是敲几行查询语句那么轻松，很多精力都耗在处理上游丢过来乱七八糟的数据上。对接的业务系统经常临时改字段，有的字段昨天还在传整数，今天就塞进来一串文本，任务调度跑起来直接报错，告警消息一条接着一条弹到企业微信，半夜爬起来看日志是常有的事。
一开始总以为，核心工作就是把报表需要的指标算出来，把分层模型建好就完事。拿到需求单，先对着原型文档梳理口径，把各个业务表的关联关系画在草稿纸上，写好ETL脚本，配置调度时间，测试几次数据能跑通，就觉得交付完成了。上线没两天，业务侧过来找，说报表数字和他们后台看到的对不上，两边对着日志一条条核对，最后才查到，是上游有一部分数据是延迟入库的，调度时间设置太早，漏掉了那批晚到的数据。
口径这件事，最磨人。
同一个指标，运营、产品、业务负责人脑子里的定义完全不一样。运营觉得只要点击就算入统计，产品要过滤掉自己内部测试账号的点击记录，业务那边又想把凌晨零点之后的流量归到前一天。每次对齐都要拉上三四个人开短会，反复确认边界条件，改完脚本重新跑数，跑出来的结果又有可能触发新的疑问。有时候改完一版，隔一周业务想法变了，口径又要推倒重来，之前建好的中间层表跟着调整，上下游所有依赖这个表的任务都要重新验证。
搭建数据模型只是其中一块工作，还要维护整套数据链路。上游的日志采集、数据库同步出问题的时候，数据会断流，下游的看板、离线任务全部跟着失效。有一回同步服务卡住，连续三个小时没有增量数据进来，只能一边催负责同步的同事排查，一边手动补跑历史分区，补数据的时候还要小心翼翼，生怕覆盖掉已经正常产出的分区，导致历史报表全部错乱。那个下午坐在工位上，反复刷新分区状态，盯着数据量一点点涨回来，神经绷得很紧。
也会做一些自助查询的底层支持，给业务同学开放查询权限，建好视图，写好常用的指标脚本，方便他们自己拉取数据。但不是所有人都懂数据底层的结构，经常有人直接跑一个没有限制条件的大查询，扫描上亿条原始数据，把集群资源占满，别的任务排队卡住。遇到这种情况，就得找到对应的人，跟他解释查询为什么慢，调整查询逻辑，或者帮他改成预计算好的指标，减少资源消耗。
空闲一点的时候，会慢慢梳理历史遗留的脏脚本。很早之前的任务没有规范注释，字段没有说明，分层混乱，一个大SQL堆在一起，谁改都怕动坏别的逻辑。一点点拆成中间表，加上注释，梳理清楚依赖链路，减少重复计算。这个活没有短期产出，业务不会因为这个给正向反馈，只是后面维护的时候，不用再对着一团看不懂的代码发呆。
还有线上问题复盘。每次数据异常之后，整理清楚哪里出了问题，是源数据变更没通知，还是调度策略不合理，或是口径对齐遗漏了场景，同步给上下游的同事，尽量避免同样的问题重复出现。但很多时候，上游业务迭代节奏很快，变更通知经常跟不上，这种风险很难完全规避。
这些都只是我在这个团队里接触到的状态，不同公司的数据研发工程师做什么差别挺大的，有的团队侧重实时链路开发，天天写Flink任务，有的偏离线数仓建设，还有的会花很多精力做数据治理，清理无效数据、补充元数据。没有一套统一固定的工作模板。
那天加班到很晚，补完延迟分区的数据，关掉调度平台页面，窗外的路灯亮成一片。