数据工程师

从一个源头抽出来、把形状改对、装进一个能查询的地方,并给整件事排上调度。

上游某个字段的含义变了、某个任务跑了两遍、时区偏了 —— 而所有看板依然是绿的。

定义什么算活跃用户、什么算收入、什么算流失 —— 并在两个团队希望它有不同含义时守住这个定义。

分区、存储分层、某人排了每小时一次却全表扫描的那条查询,以及月底那张账单。

留存期限、删除请求、个人数据被允许待在哪里,以及你能不能证明这一点。

把对的文档、对的新鲜度、对的访问规则,送进 AI 功能所读取的那个东西里。

搭管道 —— 教程教的那件事,也是你会被招进来做的那件事 —— 是暴露的那一半。撑得住的是「知道一个数字本来应该是什么意思」,而这只能通过靠近用它的那些人来学。一份离业务很远的数据工作,是这个岗位里风险更高的那个版本。

查询变便宜,抬高了「谁为定义负责」的价值,压低了「只搬运数据」的价值。如果你一周主要在接数据源和排调度,那是暴露的那种配置;如果主要在争论「什么才算一个客户」,那是耐久的那种。

保住并强化

守住语义,不是守住管子

当任何人都能用话问出一个问题,答案就取决于工具捡起了谁的定义。成为决定那件事的人,是耐久的位置。

调整职责

把检索那一层接过来

公司里每一个 AI 功能最终都会变成三个问题:读哪些文档、多新、谁有权看 —— 那就是这份工作换了个名字。

相邻转岗

往决策那一侧走

分析工程与产品分析坐在数仓和「据此行动的人」之间,而这套推理可以直接迁移过去。

逐项去问,因为它们不是一起动的。搭管道与排调度是暴露的那部分,而且早在生成式工具之前就一直在变便宜。而「察觉到一个数字悄悄不再是它原来的意思」完全没有动,因为那份知识关于生意,不关于数据。一个你自己能核对的信号:上个季度某个数字出错时,是谁发现的、怎么发现的。

本站的证据指向相反的方向,而且很具体。在一个用真实企业数仓查询日志构建的基准上,纯模型得分为零、智能体方案约 10%,而同一类模型在公开基准上是 80 到 90 分。这个落差不在 SQL —— 在于动辄上千张表的表结构,以及长在表结构之外的含义。查询变便宜,抬高的是「维护那份含义的人」的价值。

取决于你会做哪一半 —— 而这件事值得在转过去之前问清楚。主要是接数据源和排调度的岗位,处在暴露的那一半,而且已经商品化很多年了。靠近业务、需要你就定义去争论的岗位,是耐久的那一半。两种情况的职位名称是一样的,所以在面试时问一句:最近三次争论是关于什么的。

这门生意到底怎么赚钱 —— 细到足以让你在某个数字与它不再自洽时察觉出来。工具每几年换一次,而每一种都能在几周内学会;而「看着一张看板说出『这不可能对』」的能力,才是区分留下来的人的东西。它恰好也是一个读你表结构的模型做不到的事。