四年过去，Joe Reis 几乎不想改写他的数据工程书

“四年前的昨天。”Joe Reis 回顾《数据工程基础》（Fundamentals of Data Engineering）的文章，就以这句话开头。这本书于 2022 年 7 月 26 日出版，他的文章发布于 2026 年 7 月 27 日。

他自问：如果今天再写，会不会写得不一样？他的简短回答是：大体保持原样，只有几点保留。

数据工具更新很快。一位作者四年后仍认可自己的框架，这一点值得留意。

如果你想做前线部署工程师（FDE），这一点就更重要。在客户现场，技术栈轮不到你来选。你能带去的是一种看待系统的方式，而 Reis 与 Matt Housley 这本书教的正是这个。

五个阶段，一套排查方法

全书的核心是一个五阶段的数据生命周期：Generate、Store、Ingest、Transform、Serve。听起来像幻灯片里的示意图，但出问题时就能看出它的价值。

假设你在一家零售连锁企业做 FDE。运营负责人抱怨，今天早上的营收报表比收银员报上来的数字少。很多开发者会打开看板，也就是 Serve 阶段，开始检查 SQL。

生命周期的思路是反过来，从源头查起。门店的 POS 系统（Generate）几点同步完？负责拉取数据的任务（Ingest）几点运行？

假设 POS 凌晨 2 点同步完，Ingest 任务凌晨 1 点就跑了。那么上次同步以来的所有交易都不会出现在报表里，哪怕你的 SQL 完全正确。

问题不在 Transform 或 Serve，所以改 SQL 解决不了任何问题。合理的修复是强制执行顺序：Ingest 只在 POS 报告同步完成后运行，而不是按固定时间运行。

五个阶段给了你逐一排除的顺序。在客户现场，这个顺序能省下几个小时的瞎猜。

价值在六条暗流

上面的例子其实是 Orchestration 问题，而 Orchestration 是书中六条“暗流”之一。暗流不是阶段，而是贯穿每个阶段。Reis 本人也认为这是全书最有用的部分。

暗流对 FDE 的价值在于，它们可以变成在客户现场提出的问题。套用到上面的零售连锁企业，每条暗流都能变成一个具体的调研问题：

暗流	可向零售客户提出的问题
安全	POS 数据里有没有顾客手机号？谁能读取？
数据管理	各部门说的“营收”是同一个意思吗？
DataOps	数据管道出故障时，通知谁？多快通知到？
数据架构	门店数据进入报表前要经过哪些系统？
Orchestration	哪些任务必须在哪些任务之前完成？谁来检查这个顺序？
软件工程	数据管道代码有没有代码评审、测试和版本控制？

第一次需求调研的小建议：不要带着功能清单去，而是带着类似这样的六个问题去，记下客户在哪里犹豫。项目往往就会在那里出问题。

当问题横跨两朵云

再把例子往前推一步。假设这家零售企业把 POS 数据存在一朵云上，看板却跑在另一朵云上。Google Cloud 把这种架构称为多云，即至少组合使用两家公有云厂商，给出的理由之一是避免被单一厂商绑定。

这时，上面的时序问题就难发现得多，因为 Ingest 和 Serve 分处两地，有两套日志。

先检查数据从一朵云流向另一朵云的交接点，问三个问题：传输任务的运行时间与源端写完的时间相比如何？两边记录时间用的是同一个时区吗？传输失败时，谁收到告警，在哪朵云上？

如果有人建议把这个传输任务迁到 serverless 上来理顺流程，请记住 Corey Quinn 写过：遗憾的是，serverless 的承诺至今仍未兑现。同意之前，先问清楚它能否真正解决这个交接点上的执行顺序和告警问题。

关于 AI/ML，Reis 仍未决定是否把它列为第七条暗流，但他明确表示，无论如何，AI/ML 都会在数据工程中占据重要位置。对为客户部署 Agent 或模型的 FDE 来说，这提醒我们：输出质量仍取决于上游的五个阶段。

谁该读，按什么顺序读

Johnny Winter 在 Greyskull Analytics 上撰文，建议所有从事数据工作的人都备一本，而不仅是数据工程师。对想转 FDE 岗位的后端或全栈开发者来说，这本书应该在任何工具文档之前读。

Winter 也指出了一个不足：部分存储章节写得非常细。先精读生命周期和暗流的章节，立刻套用到手头的一条数据管道上；等项目真正用到时，再回头读存储章节。

写简历时，可以借用书里的说法。不要写“优化了 ETL”，而是写你在 Ingest 阶段发现了一个导致 Serve 阶段报表失真的问题，并说明怎么修复的。看岗位描述时，留意“端到端数据管道”或“对接客户数据基础设施”这类表述，这些岗位需要的正是这种思维方式。

工具还会更替很多次。一个连作者本人四年后都想保留的框架，值得带进你接下来的每一个数据项目。