专业书籍精读 · Fundamentals of Data Engineering · 第 1 章
Fundamentals of Data Engineering · Ch 1 · Data Engineering Described · Reis & Housley · 2022
你在外卖软件上看到「本周你点了 9 单奶茶」，老板在周会上看到「上月复购率涨了 3%」，推荐系统猜中你想吃什么——这些数字和推荐背后，都有人先把散落在几十个系统里的原始记录搬出来、洗干净、整理好。干这件事的人，就叫数据工程师。这一章回答：这个岗位到底做什么，它和大家更熟的「数据科学家」边界在哪。
把一家公司的数据想成一座城市的自来水系统。水源是河流、水库、井（各种业务系统）；用水的是家家户户、餐馆、工厂（分析师、数据科学家、AI 模型）。中间那一整套取水、管道、水厂、净化、加压、送到每个水龙头的工程，就是数据工程。用户只在乎拧开龙头有干净的水；没人会夸管道，但管道一坏，全城都知道。
把数据工程单独当成一门手艺，好处是让分析和 AI 真正落地：科学家回去做科学，数据按时、可信地送到。一个刚起步的团队，最该做的是先选对少量现成工具、快点拿出一两个看得见的成果，而不是一上来自己造轮子。一句诚实的代价：这份工作做得好时几乎「看不见」，价值很难单独算清，团队常常要先证明自己才能拿到资源。
数据工程师是公司数据的「自来水公司」：把原始数据从源头送到每个要用的人手上，干净、准时、安全——它是分析和 AI 的地基，不是附属品。
想看书里对数据工程的正式定义、生命周期与六条「暗流」、它四十年的演进、A 型与 B 型工程师、三级数据成熟度怎么各自取舍？ → 切到精读版
你以为数据工程就是「写 ETL 脚本、把表从 A 搬到 B」，其实本书给它的定义要宽得多：数据工程是开发、实施并维护一套系统与流程，把原始数据变成高质量、一致的信息，供分析、机器学习等下游使用；它是安全、数据管理、DataOps、数据架构、编排、软件工程这六件事的交汇点。这一章要在读者脑中立起一个框架——数据工程师管的是「数据生命周期」，而不是某一个工具——全书剩下的章节都挂在这个框架上。
全书第 1 章，Part I「基础与构件」的开篇。它先定义岗位、画出生命周期总图，第 2 章再把生命周期逐段展开，第 3、4 章讲架构与选型，Part II 逐个讲采集、存储、转换、服务。对应现实里「公司要不要设数据工程岗、这个岗位该做什么」这一类组织决策。
「数据工程师」这个头衔在 2010 年代才流行起来，至今定义混乱：有公司指的是写 Spark 作业的人，有的指维护数据仓库的人，有的其实是给数据科学家打杂。定义不清的后果很具体——招错人、分错活、预算批不下来，以及最常见的那个：花高价请来的数据科学家，大部分时间耗在找数据和洗数据上。本书作者的观察是，数据科学家估计有 70%–80% 的时间耗在金字塔底部的收集、搬运、清洗上。
这一章要做三件事：给岗位一个能落地的定义；用历史解释为什么这个岗位会出现、又为什么在 2020 年代变了样；再给出判断「我的公司需要什么样的数据工程」的两把尺子——工程师的 A / B 类型和公司的数据成熟度。
本书最核心的一张图是数据工程生命周期（data engineering lifecycle）：数据从生成（源系统里产生）开始，经过采集（ingestion，把数据搬进来）、存储（storage）、转换（transformation，清洗、建模、聚合），最后服务（serving）给分析、机器学习和反向 ETL（reverse ETL，把加工后的数据写回业务系统）。存储贯穿各阶段。
生命周期底下流着六条暗流（undercurrents）：安全、数据管理（治理、质量、元数据、血缘）、DataOps（把 DevOps 的自动化、可观测、事故响应搬到数据上）、数据架构、编排、软件工程。暗流不是一个阶段，却决定每个阶段做得好不好。
为什么要这样定义？因为工具十年一换，而这几个阶段几十年不变。把职责锚在生命周期上，换工具时你的知识不会作废。书里明确说，本书偏向原则而非具体工具，也是这个原因。
作者把这个岗位的来历分成四段：
作者借用 Monica Rogati 2017 年的「数据科学需求层次」金字塔：从下往上是收集 → 搬运与存储 → 探索与转换 → 聚合与标注 → 学习与优化。AI 和机器学习只是塔尖；下面几层不牢，塔尖做不起来。
数据工程坐在数据科学的上游：它负责把下三层做扎实，让数据科学家拿到干净、可信、按时更新的数据，回去做真正的建模与分析。这条边界不是「谁更高级」，而是分工——让管道专家修管道，让科学家做科学。
书里列的技能分两半。业务侧：能跟技术和非技术的人沟通、能界定需求、懂敏捷 / DevOps / DataOps 的文化、能控制成本、持续学习。技术侧：SQL、Python、一门 JVM 语言（Java 或 Scala）、bash 是基本功，并且要懂生命周期和暗流里每一块的原理与权衡。
岗位在组织里夹在中间：上游是软件工程师、数据架构师、DevOps / SRE——他们的系统产生数据，数据工程师要懂源系统的数据怎么来、多大量、会不会改结构；下游是数据分析师、数据科学家、ML 工程师——他们是客户。此外还要对接 CEO、CTO、CDO（首席数据官）、产品与项目经理，把数据工作和业务目标对齐。
这一章给出两把尺子。第一把是A 型 vs B 型（借自数据科学里的同名分类）：
表 1 · A 型与 B 型数据工程师
| 类型 | 做什么 | 适合谁 | 代价 / 风险 |
|---|---|---|---|
| A 型（Abstraction） | 用现成工具和托管服务搭架构，尽量少造轮子 | 几乎所有公司、各个成熟度阶段 | 受制于厂商能力与定价；锁定风险 |
| B 型（Build） | 自研能扩展的数据工具与系统，服务核心竞争力 | 数据就是产品或护城河的公司（成熟期为主） | 人力贵、维护负担长期存在；造了不该造的轮子 |
两者不是二选一的人设，而是一个连续区间：同一个人也可能两种活都做。判据只有一条——只在能形成竞争优势的地方自己造，其余一律用现成的。
第二把尺子是公司的数据成熟度（data maturity）——不是看数据多大、工具多新，而是看数据被用得多好：
表 2 · 三级数据成熟度：该做什么、别做什么
| 阶段 | 数据工程重点 | 要避开的坑 |
|---|---|---|
| ① 起步用数据 | 拿到高层支持；定一个合适的数据架构；盘点手上的数据；尽快交付一两个看得见的成果 | 被技术本身分心；在没有差异化的地方干重活；过早自研 |
| ② 用数据扩张 | 建立正式的数据实践；做可扩展、健壮的架构；引入 DevOps / DataOps；为机器学习打基础 | 因为「大厂在用」就追最新技术；忽视团队本身才是瓶颈 |
| ③ 以数据领先 | 新数据源能无缝接入；自动化；只在有竞争优势处自研；补齐目录、血缘、治理 | 自满——成熟度会退化，需要持续维护 |
经验法则：一个 20 人的初创公司不需要自建 Hadoop 集群——托管仓库加一个编排工具就能撑很久；把省下的人力花在跟业务对齐上，比调集群参数更值钱。
这一章的框架直接对应现代数据栈的分工：采集用 CDC（变更数据捕获）或托管连接器，存储用对象存储 + 云数仓 / 湖仓，转换用 SQL 建模工具，编排用调度器，服务给 BI 和 ML。面试或架构评审里被问「数据工程师和数据科学家怎么分工」，好的回答不是列工具，而是画出生命周期，指出哪几段归谁、暗流由谁兜底。
演进史也是一条「B 型 → 开源 → A 型」的轨迹：大公司为自己造的工具开源，几年后变成别人的托管服务。
大厂实证
① 定义：把原始数据变成高质量、一致的信息供下游使用；是安全、数据管理、DataOps、架构、编排、软件工程的交汇。
② 生命周期：生成 → 采集 → 存储 → 转换 → 服务；数据工程师管从拿到源数据到交付用例这一段。
③ 六条暗流托着每一段，决定管道是否安全、可信、可运维。
④ 演进：数据仓库（1989）→ GFS / MapReduce / Hadoop（2003–2006）→ 大数据工程 → 2020 年代的生命周期工程师。
⑤ 与数据科学的边界：数据工程打牢需求金字塔的下三层，坐在数据科学上游。
⑥ A 型用现成工具搭，B 型自研；只在有竞争优势处自己造。
⑦ 成熟度三级：起步、扩张、领先，每级重点与陷阱不同；成熟度看用得多好，不看数据多大。
⑧ 技能一半是业务：沟通、需求、成本；一半是技术：SQL、Python、JVM、bash 加生命周期原理。
⑨ 易错：把它等同于 ETL、把它当科学家的助手、因为别人在用就追新工具。