数据工程师 · 任务逐条

把管道搭起来

连接常见数据源的接头现在是买的,不是写的;而变换代码的规格清晰到生成完全应付得来。这类工作在不同公司之间重复了二十年 —— 那正是让一项任务变便宜的条件。

管道在跑,不等于数字是对的。在一个成熟的数据团队里,时间从来不是花在「把它搭起来」上,而是花在「让它保持真实」上。

数据错了,但什么都没报错

「无声地错了」是这份工作的标志性失效模式,而它不是一个「更好的工具就能解决」的检测问题 —— 它要求你知道这个数字对这门生意本来应该意味着什么,而那长在人身上,不长在表结构里。测试只能抓住你想到要测的东西。

这是一条关于失效性质的判断,不是对它发生频率的测量。无声的数据错误在任何地方都没有被量化过 —— 一部分原因是,按定义它们要么被很晚发现,要么根本没被发现。

为「一个数字是什么意思」负责

自然语言转 SQL 的工具让查询变便宜,反而让「定义」更承重而不是更轻:一旦任何人都能问,答案就完全取决于模型捡起了哪一个定义。分析师那一页的证据指向同一处 —— 在一个用真实企业数仓构建的基准上,纯模型得分为零,而它在公开基准上是 80 到 90 分;这个落差在于表结构与语义,不在于 SQL。

那个基准讲的是查询,不是「定义归谁管」,而且它的作者在卖一套替代系统 —— 分析师页上的那条记录写明了这一点。它确立的是「企业表结构会打败当前的模型」;它没有确立「有人正在为维护语义而被招聘」。

「一直问下去」要花多少钱

数仓现在会自己把那条昂贵的查询指出来并建议怎么改 —— 这是实打实的帮助。剩下的是「这个答案值不值这笔钱」的决定,而那需要你知道谁在用这个数字、用它来做什么。

它没有说整体成本是在涨还是在跌;而查询变便宜往往会让被问出来的问题变多 —— 这可能把账单推向任意一个方向。

哪些必须留、必须删、或者根本不该收

这是一条在管道里实现的法律义务,而法律义务是挂在人身上的,不是挂在系统上的。工具可以在有人定下规则之后去执行它;而「定下它」以及「事后能证明合规」,是留下来的那一部分。

要求因市场与数据类型而差异极大。能把这一项判定下来的,是一次点名到数据团队留存或删除做法的执法 —— 监管机构说清楚谁本该删掉什么、在什么时候之前 —— 而不是针对整家公司的处罚。

喂饱那些用句子回答的系统

检索质量现在是一个披着 AI 外衣的数据问题,而它落在这里,是因为它讲的是管道、权限与新鲜度,不是模型。在生成式功能进入产品之前,这不是一份工作。

新工作出现不等于新增编制。在多数公司里,这件事是被「本来就管着数仓的那个人」顺手接过去的,而这里没有任何东西说明相反的情况。