数据越来越多地被用来支撑决策，但原始数据常常散落在各个业务系统里，格式不统一，口径也对不上。阿里云数据研发工程师要做的，是把这些数据加工成业务方能直接使用、并且敢用的数据。这份工作既需要扎实的工程能力，也离不开对业务的理解。这个岗位具体是什么样子，可以从日常工作、一个典型场景、所需能力和职业方向来看。
一、和数据分析师有什么不同
数据分析师更多是拿数据回答问题，数据研发则负责让数据本身可靠地产出。一条指标从业务系统走到报表，中间可能经过几十个加工节点。哪一步出了错，报表上的数字就会悄悄偏掉，而且往往要等业务方发现异常才会有人知道。所以数据研发关心的是链路稳不稳、跑得快不快，以及出问题之后好不好查。
服务对象大致分两类。一类是云产品内部的数据团队，处理计费、监控、用户行为等内部数据。另一类是面向外部客户的数据平台项目，帮企业搭建自己的数据中台。两类工作的技术底子差不多，但交付节奏和稳定性要求不一样。内部项目通常更看重长期维护，外部项目则更看重按期交付，并且要经得起客户业务方的验收。
二、日常工作通常包括什么
一名数据研发工程师的日常，大致落在以下几类任务上：
- 数据集成，把业务库、日志和第三方数据接入数据平台。离线同步还是实时采集，通常取决于下游对时效的要求。
- 数仓建模，按 ODS、DWD、DWS、ADS 分层设计模型。分层的意义在于口径统一、重复计算可控。层次划得太细会拉长链路，划得太粗又难以复用，需要结合实际取舍。
- ETL 开发，用 SQL 或 Python 编写加工任务，并在调度平台上配置依赖关系和重跑策略。重跑策略最好提前想清楚，否则上游补录数据时，下游可能出现重复计算或漏算。
- 实时计算，基于 Flink 等流式引擎处理订单、风控、监控等时效敏感的场景。流任务一旦上线，状态管理和故障恢复就成了日常要盯的事。
- 数据质量与治理，为核心表设置校验规则，建立指标血缘，配置告警。血缘不只是文档，它决定了出问题时能不能在几分钟内找到源头。
这些事情看着分散，最后都指向同一个结果：数据要按时产出，业务方看得懂，也敢拿去用。
三、一个典型场景：大促前的数据准备
大促是检验数据链路的典型场景。大促前两周，数据团队一般会集中做三件事。
第一，梳理交易、支付、库存这几条核心链路的数据依赖，画出血缘图，标出哪些任务处在关键路径上。关键路径一旦延迟，后面依赖它的报表都会跟着晚。
第二，对实时大屏用到的 Flink 作业做压测，观察峰值流量下的端到端延迟和 checkpoint 耗时。压测结果常会暴露平时看不出的问题，比如某个算子的状态越涨越大，或者数据倾斜让个别并行度拖慢整体。扩容余量要留，但不必留得过多，资源成本也要算进去。
第三，给核心指标配置双通道校验。离线结果和实时结果每小时比对一次，差异超过阈值就告警。阈值没有标准答案，通常要参考历史波动来定。设得太松会漏报，设得太紧，值班的人很快就会麻木。
假如大促期间上游支付回调的某个字段临时变更，实时订单金额就可能出现偏差。有了前期的血缘梳理和校验规则，定位问题会快很多，回滚解析逻辑通常就能恢复数据。事后复盘时，最好把这类事件转成新的质量规则，纳入日常巡检，否则同样的问题会反复出现。
四、需要具备哪些能力
- 编程与 SQL，SQL 写得熟是基本要求，关键是会调优，能读懂执行计划，知道一个查询慢在哪里。至少熟悉一门编程语言，比如 Java、Python 或 Scala，能写工具脚本，也能看懂引擎相关的代码。
- 数据仓库理论，维度建模、缓慢变化维、指标口径管理这些概念，要有实际理解。它们听起来像理论，但每次口径争议、每次历史数据回刷，都会用到。
- 分布式计算原理，了解 MaxCompute、Hadoop 或 Spark 的基本执行模型，知道数据倾斜和小文件是怎么产生的。不少性能问题出在数据分布和执行方式上，SQL 本身未必有错。
- 工程化习惯，用版本管理，做代码评审，给关键逻辑写自动化测试。数据任务和业务代码一样会被修改、会被交接，没有这些习惯，半年后就没人敢动它。
- 业务理解，能和产品、运营把指标定义说清楚，知道一个数字背后对应哪些业务动作。很多数据问题其实是口径没有对齐，技术上并不复杂。
五、职业发展的几个方向
数据研发的成长路径大致有三条。
往技术深处走，可以成为数据平台或实时计算方向的专家，负责引擎优化和架构设计。这条路对底层原理和排查能力要求高，适合喜欢钻问题的人。
往数据治理走，负责数据标准、质量体系和数据安全。企业的合规要求越来越细，这类工作也越来越需要专人负责，但它要求同时懂技术和制度。
往业务和管理走，可以带领数据团队，承接某个业务域的数据规划。这条路更依赖沟通能力，也需要长期积累对业务的理解。
不管选哪条路，项目经验的积累和对数据质量的重视都是比较可靠的基础。数据研发不太追求速度，更看重的是一次次大促平稳过去，以及业务方放心使用某个指标的那一刻。
