数据工程生命周期

一句话

你以为生命周期是「采集用 A、存储用 B、转换用 C」的一张工具清单，其实本章给的是五组「动手前先问清」的问题：数据从哪来、怎么进来、放哪、怎么加工、给谁用，再加上六条贯穿全程的暗流。这一章最反直觉的一句结论是：批处理仍是默认，实时流要有业务理由才值得付它的代价。

Glossary · 术语表

坐标

Part I「基础与构件」第 2 章。第 1 章画出生命周期总图，这一章逐站展开、并把六条暗流讲清；第 3 章在此之上谈架构原则，Part II（第 5–9 章）再给生成、存储、采集、转换、服务各写一章。对应现实里「搭一条数据管道前，到底该先想清楚什么」。

这章要解决什么

工具的名字每年都在变，而数据管道出事的方式几十年没变：上游悄悄改了字段、数据迟到或重复、实时管道是为一张日报建的、看板没人用、有人误删了不该删的数据。这些都不是某个工具的 bug，而是某一站没问对问题，或某条暗流没人管。

本章先区分两个概念：数据生命周期是数据从产生到销毁的完整一生；数据工程生命周期是其中数据工程师负责的那一段。然后给每一站列一份评估清单。作者的经验判断是：源系统和采集是整个生命周期里最大的瓶颈——因为它们在你的控制之外。

核心内容，讲透

一、生成：你不拥有源系统，但必须读懂它

源系统（source system）是数据的出生地：业务数据库、App 埋点、第三方 API、IoT 设备。数据工程师通常不拥有它，却要为它的一切变化买单。书里给的评估问题，归纳起来是这几类：

• 数据怎么持久化、以什么速率产生？每秒多少事件、每小时多少 GB。设想一个电商库每秒写入 2000 笔订单，一天就是约 1.7 亿行，这直接决定后面每一站的规模。
• 质量如何？会不会重复、会不会迟到（late-arriving data）、多久出一次错。
• 模式怎么演变？有固定 schema 的关系库，还是无 schema、随应用代码改变结构的文档库？上游加一列、改一个类型，你怎么知道？
• 读它会不会拖垮它？在生产 OLTP 库上跑大查询，可能拖慢真实用户的下单。
• 给你的是快照还是变更？是周期性的全量状态，还是一条条「谁改了什么」的变更事件。

书里的建议是和源系统的主人建立联系：上游的改动最好在发生前就通知到你，而不是在报表坏了以后才倒查。

二、存储：不是一站，而是贯穿全程的地基

在书的总图里，存储画在其它几站的下方：采集要落地、转换要读写、服务要查询，每一站都踩在存储上。选存储时要问：读写速度能不能匹配上下游？会不会成为瓶颈？未来数据量涨十倍怎么扩？是只存不算（如对象存储），还是能直接查询（如云数仓）？能不能记录元数据和血缘？

书里一个很实用的划分是按访问频率分「温度」：

温度划分的意义在于成本：同样 1 PB，全放热层和按冷热分层，账单可以差出一个数量级。代价是冷数据取回要等、还另收取回费，所以「以为冷、其实常被查」的数据放错层，反而更贵。

三、采集：最容易卡住的一站

采集（ingestion）把数据从源系统搬进存储。它是生命周期里最脆弱的一环：源系统没响应、数据质量突然变差、上游改了格式，任何一个都会让下游整条线断掉。这一站有两组关键选择。

批 vs 流。书里有一个重要的视角：数据在产生时本质上都是连续的事件流，批处理只是把这条流按大块切开来处理的一种方便做法。流式采集让下游几乎实时拿到数据，但书里反复提醒先问：实时能带来什么批处理给不了的业务价值？要多花多少钱、多少运维时间？基础设施出故障时流管道还靠得住吗？结论是批处理仍是绝大多数场景的合理默认，只有找到能证明这些代价值得的业务用例，才上真正的实时。

推 vs 拉。推（push）是源系统主动把数据写给你；拉（pull）是你按时间表去源系统取。变更数据捕获（CDC，change data capture）两种都有：按时间戳定时查「上次之后改了哪些行」是拉；读数据库自己的变更日志（如 MySQL 的 binlog）、一有提交就转发出去，更接近推。

四、转换：把原始数据变成有用的东西

转换（transformation）是数据开始产生价值的地方。书里列了几层：类型映射（把字符串变日期）、清洗与标准化（去重、统一单位）、建模（整理成分析友好的结构）、业务逻辑（「活跃用户」到底怎么算），以及给机器学习做特征化（featurization），即从原始数据里提炼出模型能用的输入。

书中强调两点。第一，业务逻辑是转换最大的驱动力，也是最容易出错、最该有人负责的部分——同一个「月活」在三张报表里有三种口径，比任何技术故障都伤信任。第二，每个转换都要能说清成本和回报：这一步省了谁的时间、支撑了哪个决策？尽量让转换简单、彼此隔离。

五、服务：数据只有被用上才有价值

服务（serving）是最后一站。书里有个辛辣的提醒：要警惕数据虚荣项目——大张旗鼓建了湖、建了仓，却没人在用。服务分三类：

• 分析：BI 报表（看过去）、运营分析（看现在，如实时监控订单量）、嵌入式分析（把看板做进产品里给客户看）。最后一种要特别小心多租户（multitenancy）：一个客户绝不能看到另一个客户的数据。
• 机器学习：给模型训练和推理供数，常借助特征存储（feature store）。书里建议先问：数据质量够不够、可发现吗、是否代表真实情况（ground truth）、有没有偏差。在打好分析基础之前就冲 ML，往往事倍功半。
• 反向 ETL（reverse ETL）：把加工好的结果写回业务系统，比如把「流失风险分」写进 CRM、广告平台，让一线直接用上。

六、六条暗流：让每一站都靠得住

暗流（undercurrents）不是生命周期中的某一站，而是每一站都要做的事：

• 安全：最小权限原则（principle of least privilege），只给完成工作必需的权限、用完即收。书里直言人和组织才是最大的安全漏洞，比技术漏洞更常见。
• 数据管理：沿用 DAMA 的框架，包括数据治理（可发现性、元数据、责任人）、数据质量（准确、完整、及时）、血缘（lineage，数据从哪来经过了什么）、主数据管理，以及数据生命周期管理——GDPR、CCPA 这类法规要求能按需删除个人数据，「删干净」是工程问题。
• DataOps：把敏捷、DevOps 的做法搬到数据上，三根支柱是自动化、可观测与监控、事故响应。目标是在业务方发现数据错误之前先发现它。
• 数据架构：理解业务需求，在成本与简洁之间做设计取舍（第 3 章展开）。
• 编排（orchestration）：按 DAG 调度任务、管依赖、失败重试与告警。它不等于 cron：cron 只认时间，编排器认依赖——上游没跑完，下游就不该开跑。Apache Airflow 是代表。
• 软件工程：数据处理代码、基础设施即代码、管道即代码、测试与评审。工具再托管，写出可维护代码的能力也省不掉。

关键权衡与选型

表 1 · 采集与处理的时间粒度：什么场景选什么

判据：先问「数据晚到 1 小时，业务会损失什么？」答不出具体损失，就用批。

表 2 · 推、拉与日志 CDC

温度分层同样是权衡：热层快但贵，冷层便宜但取回慢、还另收取回费。按访问频率分层，并定期复核「冷数据是不是其实常被查」。

为什么重要 / 落到真实系统

这一章的框架几乎一一对应现代数据栈：生成端是 MySQL / PostgreSQL 等业务库和埋点；采集端是 CDC 工具、托管连接器与 Kafka；存储端是对象存储加云数仓或湖仓；转换端是 SQL 建模与 Spark；服务端是 BI、特征存储和反向 ETL 工具；编排与数据质量工具横跨全程。架构评审里被问「这条管道靠谱吗」，好的回答是逐站报出源头速率、采集方式与延迟、存储分层、转换口径负责人、服务对象，再说明每条暗流由谁兜底。

易错点与争议

• 「先选工具再想需求」。本章的顺序是反的：先问下游要什么、多新鲜，再倒推每站怎么做。
• 「实时一定比批好」。流处理贵在长期运维，乱序、重复、回放都要处理；为一张每天只看一次的日报建流管道，是最常见的过度设计。
• 「增量拉取就是 CDC 的全部」。按时间戳拉取看不到物理删除，也依赖时间戳列可靠；需要完整变更历史时要读日志。
• 「编排就是 cron」。cron 不懂依赖和重试，上游失败下游照跑，脏数据一路传下去。
• 「存储只是一站」。它是全程的地基，冷热分层直接决定账单。
• 「数据管理是合规部门的事」。血缘、质量、删除能力都得在管道里实现，事后补代价极高。
• 时代局限与争议。书出版于 2022 年，对「流优先」持审慎态度；此后流处理托管服务越来越成熟，成本门槛在下降，部分团队主张默认流式。另外，书中对向量数据、给大模型准备数据的着墨不多。

要点