为分析与 ML 服务数据

一句话

你以为数据管道的终点是「数据进了仓库」，其实终点是有人基于它做出决定或动作。本章要建立三条认知：服务数据的第一原则是信任，错一次就很难挽回；服务前先问谁用、用来做什么，分析、机器学习、反向 ETL 三类用户要的东西完全不同；口径要只定义一次，而把数据写回业务系统，就等于把错误直接送进业务动作，必须有护栏。

Glossary · 术语表

坐标

Part II「生命周期详解」最后一章。上接第 8 章「查询、建模与转换」（数据已加工好），下启 Part III 的安全与隐私。它对应生命周期的最后一站「服务（serving）」——作者称这是数据工程师大显身手、价值被真正检验的地方。现实里对应 BI 报表、对外数据产品、特征供给与反向 ETL 同步。

这章要解决什么

设想一家做商家 SaaS 的公司：数仓里几百张已建模的表；管理层每天 8 点看经营日报；二十来个分析师随手查数；产品里给 2 万家商家嵌了一个「我的销售」看板，高峰时上千人同时刷新；风控模型要三年的历史订单做训练；销售团队希望在 CRM 里直接看到每条线索的成交概率。不懂本章的典型后果：

• 信任崩塌。日报晚到两小时、或与财务对不上一次，管理层就回到 Excel，平台沦为摆设。
• 一个仓库硬扛所有负载。用跑批量报表的数仓直接支撑上千并发的对外看板，延迟从毫秒拖到十几秒。
• 口径分裂。「活跃商家」在 BI、Notebook、对外看板里各算一遍，三个数字三种答案。
• 模型线上变差。训练数据用了「事后才知道」的字段，离线指标漂亮、上线就失效。

核心内容，讲透

一、服务前的总原则：信任、用户、数据产品

信任是第一位的。作者的判断是：建立数据信任要很久，失去只要一次。手段有二：一是数据校验与可观测性，在用户发现之前先发现问题；二是和使用方约定 SLA，例如「日报数据每天 8 点前就绪、关键指标与财务对账误差为零」，再用 SLO 持续度量是否达标。数据晚了、错了，要主动告知，而不是等人来问。

先问用途和用户。好问题不是「你要什么数据」，而是「拿到数据后你要采取什么行动」。同一份订单数据，给 CEO 的是一张趋势图，给分析师的是可自由切片的明细，给模型的是带标签的历史样本。

数据产品（data product）。作者借用「用户雇佣产品来完成某项任务」的视角：把对外提供的数据集当产品来做，有明确用户、要解决的问题和反馈渠道，而不是一次性的取数需求。

自助分析不是默认答案。让每个人自己拖拽出报表听上去美好，但书里提醒，自助分析在实践中常常落空：高管只想看结论，并不想自己拖表；真正需要自助的是能提出新问题的分析型用户，而且要给他们有边界的自由——干净的模型、清楚的口径、合适的权限。

数据定义与数据逻辑。数据定义是一个词的含义（什么算「客户」）；数据逻辑是计算公式（GMV 是否含退款、按下单还是付款时间算）。这些知识常只存在老员工脑子里，作者主张把它们显式写下来、在一处集中维护。数据网格（data mesh）则把「服务」下放：每个业务域把自己的数据当产品，直接对其他域提供。

二、分析：业务、运营、嵌入式三类

业务分析用历史与当前数据支持决策，三种形态：仪表盘（几项 KPI 一目了然）、报表（固定格式、定期发出）、即席分析（ad hoc，分析师临时深挖一个问题，结论好用就沉淀成报表）。

运营分析关注此刻，要求实时或近实时：应用监控、库存告警、线上转化率突降。它要的是「现在出了什么事、该立刻做什么」，数据延迟以秒计。

嵌入式分析是面向外部客户的分析，嵌在产品里：智能温控器 App 里的用电曲线、电商后台里的销售看板。作者指出它把要求一下拉高：数据要新、查询要快（用户不会等十几秒）、并发要高（成千上万客户同时查），而且每个客户只能看到自己的数据——多租户隔离要做到行级。这类负载常交给专门的实时 OLAP 引擎（如 Druid、Pinot、ClickHouse），而不是批量数仓。

三、机器学习：数据工程师要懂多少

作者坦言，数据工程与 ML 工程的边界因组织而异：有的团队数据工程师只交付干净的原始数据，有的一路负责到特征计算与供给。无论边界在哪，数据工程师都应懂一些 ML 基础：监督与无监督学习的区别、分类与回归、何时用传统模型何时用深度学习、特征工程、批量训练与在线学习、标注数据从哪来。懂这些，才知道该交付什么样的数据。

其中最容易出事的是时间点正确性（point-in-time correctness）：训练样本里的每个特征，只能取「预测那一刻已经知道」的值。比如预测一笔订单会不会退款，若训练时用了订单最终状态里才有的字段，模型等于偷看了答案——离线评估很好，上线就失效。另一个坑是训练与线上不一致：训练用批作业算特征，线上用另一套代码实时算，两套逻辑稍有差异就让模型变差。特征平台（feature store）把同一份特征定义同时供给离线训练与线上推理，正是为此而生。

四、七种服务方式

文件交换：导出 CSV、Excel，或把文件放进共享的对象存储桶交给合作方。最原始也最普遍，但版本、权限与时效难管。数据库：最常见的方式，用户直接查数仓或 OLAP 库；云数仓可给不同团队分配独立的计算资源，避免一个人的大查询拖慢所有人。流式系统：为运营分析提供持续更新的结果。查询联邦：用 Trino 一类引擎同时查多个源，不必先搬数据，适合探索与临时需求，但会把负载压到源系统上。数据共享：云数仓之间直接授权访问同一份数据，不用复制、不用跑管道，Snowflake、BigQuery 等都支持。语义层与指标层：见下一节。Notebook：数据科学家最常用的入口；作者提醒 pandas 会把数据全部读进单机内存，数据一大就要换 Spark、Dask、Ray 或云端托管环境，且数据库凭证不应明文写进 Notebook。

五、语义层：口径只定义一次

语义层（semantic layer）/ 指标层（metrics layer）把业务指标的定义集中写成代码，例如「GMV = 已付款订单金额之和，扣除当月退款」，由工具编译成针对各数据库的 SQL。所有下游——BI、Notebook、对外看板——都通过它取数，而不是各自写一遍。作者举 Looker 的 LookML 与 dbt 的指标定义为例。好处是「写一次、处处一致」；代价是多了一层要维护、要学习的抽象。

六、反向 ETL：把结果送回业务系统

反向 ETL（reverse ETL）把数仓里算好的结果写回业务系统：线索评分写进 Salesforce，用户分群写进营销平台，风险标签写进客服系统。作者不太喜欢这个名字，但认可它的价值：销售不会为了看一个分数去打开 BI，数据得去他们已经在用的地方。市面上有 Hightouch、Census 等专门工具，也可自己写。

书里最值得记住的是它的风险：反馈环（feedback loop）。作者举了广告出价的例子——模型根据数仓数据算出出价，经反向 ETL 写回广告平台；新的投放结果再流回数仓，驱动下一轮出价。一旦逻辑有误，循环会自我放大，出价一路走高，广告费在没人察觉时被大量烧掉。对策是设上限、加监控与人工复核。

七、与谁合作、底层横切关注点

服务环节直接面对数据分析师、数据科学家、ML 工程师和业务方。底层关注点里，作者特别点了安全（最小权限、按行与按列控制可见性，对外分享时用视图或脱敏数据）、DataOps（监控数据是否按时到、质量是否异常、查询是否变慢）与编排（服务依赖上游所有步骤按序完成）。服务是用户最先感知故障的地方，所以监控必须盖到这一层。

关键权衡与选型

表 1 · 七种服务方式（外加反向 ETL）

表 2 · 三类分析的要求

自助与否同样是权衡：给能提出新问题的分析型用户开放自助，配上干净模型与语义层；给只看结论的人做好固定仪表盘。对 ML 团队，数据工程交付到哪一层（原始数据、清洗表还是现成特征）要事先说定，否则特征逻辑会在两边各写一份。

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

面试题「给商家后台做一个实时销售看板」的好答案会这样落地：数仓里按订单事实表建模，指标在语义层定义一次；对外看板走实时 OLAP 引擎，从 Kafka 实时摄入、按商家做行级隔离，目标 p99 亚秒；内部日报仍走云数仓，约定 8 点前就绪的 SLA 并监控；风控训练集按时间点正确地生成；成交概率经反向 ETL 写回 CRM，同步时设变化幅度上限与告警。每一步都对应本章一个概念。

易错点与争议

• 「数据进了仓库就算交付」。没人用、没人信的数据等于没做；服务环节才是验收。
• 「上自助 BI，取数需求就消失了」。多数人只想要结论；自助只适合少数分析型用户，且要有边界。
• 「一个数仓扛所有负载」。批量报表与上千并发的对外看板是两种负载，混跑会互相拖垮。
• 「训练数据越全越好」。用了预测时刻还不知道的字段，就是偷看答案，离线越好、线上越惨。
• 「联邦查询免搬数据，所以免费」。负载转嫁给源系统，业务库可能被分析查询拖慢。
• 「反向 ETL 只是一条同步任务」。它把分析结果变成业务动作，错误代价最高，需要护栏与告警。
• 时代局限。书出版于 2022 年，语义层与反向 ETL 当时仍是新兴品类，后来部分被数仓与 BI 厂商吸收；但「先问用途、守住信任、口径只定义一次」的判断没有过时。

要点