# 数据工程师

> 把数据从「它发生的地方」搬到「有人问起它的地方」,并且是最先发现这两边对不上的那个人。

网页: https://flyvolo.ai/zh/careers/data-engineer
影响指数: 50/100 · 置信度 低置信度 · 评估于 2026-09-12
这不是失业概率。

## 适用范围

适用于搭建并运行数据管道、数仓,以及它们之上那层模型的工程师。查询结果的那批人在「数据分析师」页;机器学习工程是另一份工作,有它自己的一页。这一页还的是一张欠条 —— 分析师那一页的适用范围里一直写着「数据工程师情况不同」。

## 任务

### 把管道搭起来

- 方向: 正在自动化
- 依据: 有证据(附已核实记录)
- 为什么: 连接常见数据源的接头现在是买的,不是写的;而变换代码的规格清晰到生成完全应付得来。这类工作在不同公司之间重复了二十年 —— 那正是让一项任务变便宜的条件。
- 这还不能说明什么: 管道在跑,不等于数字是对的。在一个成熟的数据团队里,时间从来不是花在「把它搭起来」上,而是花在「让它保持真实」上。
- 记录:
  - 2024-11-12 · 限制或撤回 · 在 632 个取自真实数仓的企业数据工作流上,代码智能体解出 21.3% —— 而在更早的学术基准 Spider 1.0 上是 91.2% — https://flyvolo.ai/zh/changes/ev-20241112-data-engineer-1 (来源: https://arxiv.org/abs/2411.07763)

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

- 方向: 仍由人主导
- 依据: 有证据(附已核实记录)
- 为什么: 「无声地错了」是这份工作的标志性失效模式,而它不是一个「更好的工具就能解决」的检测问题 —— 它要求你知道这个数字对这门生意本来应该意味着什么,而那长在人身上,不长在表结构里。测试只能抓住你想到要测的东西。
- 这还不能说明什么: 这是一条关于失效性质的判断,不是对它发生频率的测量。无声的数据错误在任何地方都没有被量化过 —— 一部分原因是,按定义它们要么被很晚发现,要么根本没被发现。
- 记录:
  - 2026-04-13 · 实际部署 · 美国商品期货交易委员会在联邦 AI 用例清单中报告,它每天运行一个孤立森林模型来标出可能有误的数据加载 — https://flyvolo.ai/zh/changes/ev-20260128-data-engineer-2 (来源: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory)

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

- 方向: 仍由人主导
- 依据: 有证据(附已核实记录)
- 为什么: 文本转 SQL 工具让查询变便宜,也因此让定义变得更承重而不是更不重要:一旦人人都能问,答案就完全取决于模型拿到的是哪个定义。在 632 个取自真实企业数仓的数据工作流上,一个代码智能体只解决了 21.3%,而在同类任务的学术版本上是 91.2%;差距出在数仓的结构和语义上,而不是 SQL 上。
- 这还不能说明什么: 那个基准讲的是查询,不是谁负责定义;21.3% 是 2024 年底一个智能体在一个模型上的结果。它确立了企业数据结构难倒了当前的模型;它没有确立有人正在被雇来维护语义。
- 记录:
  - 2024-11-12 · 限制或撤回 · 在 632 个取自真实数仓的企业数据工作流上,代码智能体解出 21.3% —— 而在更早的学术基准 Spider 1.0 上是 91.2% — https://flyvolo.ai/zh/changes/ev-20241112-data-engineer-1 (来源: https://arxiv.org/abs/2411.07763)

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

- 方向: 正在被增强
- 依据: 有证据(附已核实记录)
- 为什么: 数仓现在会自己把那条昂贵的查询指出来并建议怎么改 —— 这是实打实的帮助。剩下的是「这个答案值不值这笔钱」的决定,而那需要你知道谁在用这个数字、用它来做什么。以优步为例,它说自己的数据平台会自动找出没人用的表和浪费的算力,把降本动作作为工单发给各自的负责人。
- 这还不能说明什么: 它没有说整体成本是在涨还是在跌;而查询变便宜往往会让被问出来的问题变多 —— 这可能把账单推向任意一个方向。
- 记录:
  - 2024-02-01 · 实际部署 · 优步的数据平台自动找出没人用的表和浪费的算力,把降本动作作为工单发给各自的负责人 — https://flyvolo.ai/zh/changes/ev-20240201-data-engineer-4 (来源: https://www.uber.com/ie/en/blog/datacentral-ubers-observability-and-chargeback-platform/)

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

- 方向: 仍由人主导
- 依据: 推断(VOLO 的推理,未附来源)
- 为什么: 这是一条在管道里实现的法律义务,而法律义务是挂在人身上的,不是挂在系统上的。工具可以在有人定下规则之后去执行它;而「定下它」以及「事后能证明合规」,是留下来的那一部分。
- 这还不能说明什么: 要求因市场与数据类型而差异极大。能把这一项判定下来的,是一次点名到数据团队留存或删除做法的执法 —— 监管机构说清楚谁本该删掉什么、在什么时候之前 —— 而不是针对整家公司的处罚。

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

- 方向: 新出现的任务
- 依据: 有证据(附已核实记录)
- 为什么: 检索质量现在是一个披着 AI 外衣的数据问题,而它落在这里,是因为它讲的是管道、权限与新鲜度,不是模型。在生成式功能进入产品之前,这不是一份工作。
- 这还不能说明什么: 新工作出现不等于新增编制。在多数公司里,这件事是被「本来就管着数仓的那个人」顺手接过去的,而这里没有任何东西说明相反的情况。
- 记录:
  - 2026-04-13 · 实际部署 · 45 个美国联邦机构里有 35 个报告,自己机构的资料上跑着一套知识检索系统 — https://flyvolo.ai/zh/changes/ev-20260413-data-engineer-3 (来源: https://github.com/ombegov/2025-Federal-Agency-AI-Use-Case-Inventory/blob/3c225ba8438e48306ace7698c8c7feb9486cbc69/Data/2025_consolidated_COTS_AI_use_cases.csv)

## 怎么引用

- 单位是任务,不是职位名:说哪些任务在变、哪些不变。
- 每项任务的依据与限制要一起带上;推断不是结论。
- 本页不给年份。不要从中推出一个。
- 更多: https://flyvolo.ai/llms.txt