第 6 章：数据工程

目标

为什么数据质量是决定机器学习系统能否在生产环境中成功的基础？

机器学习系统高度依赖数据质量：再强大的算法也无法弥补糟糕的数据，但优秀的数据工程却能让简单模型取得惊人的效果。与传统软件明确依赖代码逻辑不同，ML 系统的行为由数据模式决定，因此质量成为系统可信度的首要因素。理解数据工程原则，是构建能在多样化生产环境下稳定运行、长期保持性能、并能随数据规模和复杂度增长而扩展的 ML 系统的基础。

学习目标

• 运用“四大支柱”框架（质量、可靠性、可扩展性、治理），系统性评估数据工程决策。

• 计算 ML 系统的基础设施需求，包括存储容量、处理吞吐量和标注成本。

• 设计保持训练 - 服务一致性的数据管道，防止生产 ML 系统最常见的故障根源。

• 根据质量、成本、规模权衡，评估数据获取策略（现有数据集、网页抓取、众包、合成数据）。

• 架构适用于不同 ML 工作负载的数据存储系统（数据库、数据仓库、数据湖、特征库）。

• 实施数据治理实践，包括数据溯源、隐私保护和偏差缓解，贯穿数据全生命周期。

数据工程是一门系统性学科

上一章探讨的系统性方法论为机器学习开发奠定了流程基础，但每个阶段都离不开一个前提：坚实的数据基础设施。传统软件依靠代码定义计算逻辑，而机器学习则依赖数据塑造系统行为。这一范式转变使数据成为工程过程中的“一级公民”，需要像管理代码一样严谨地管理数据，这正是数据工程的使命。

工作流方法论提供了 ML 系统的组织框架，而数据工程则是实现这些方法论的技术底座。再先进的建模技术和严格的验证流程也无法弥补数据基础设施的缺陷，而良好的数据系统却能让传统方法获得显著性能提升。

本章将数据工程视为一门系统性工程学科，专注于设计、构建和维护将异构原始信息转化为可靠、高质量、适用于机器学习的数据集的基础设施。与传统软件系统的显式、确定性逻辑不同，ML 系统的行为特征源于底层数据模式，因此数据基础设施的质量成为系统效能的决定性因素。数据获取、处理、存储和治理的架构决策，直接影响 ML 系统能否在生产环境中达到预期性能。

数据工程定义

数据工程是一门_系统性学科，致力于设计、构建和维护数据基础设施，将原始信息转化为可靠、可访问、适用于机器学习的数据集。涵盖_数据获取、处理、存储和治理，确保系统具备_可扩展性、安全性_，并与技术需求和业务目标保持一致。数据工程关注_打造稳定基础_，通过原则性数据管理，支撑成功的机器学习系统。

数据工程决策的重要性在于，数据质量问题会在 ML 系统中层层传递。传统软件遇到异常输入时通常会显式报错，便于开发者及时修正。而 ML 系统则不同：数据质量缺陷会在处理流程中悄然积累，往往直到生产环境出现灾难性故障才被发现。单个标注错误看似微不足道，但系统性标注不一致会在整个特征空间腐蚀模型行为。生产环境中的数据分布缓慢漂移，也会逐步降低系统性能，最终不得不全面重训模型。

这些挑战要求超越临时修补和被动应对，采用系统性工程方法。有效的数据工程需要像设计工作流一样系统性分析基础设施需求。本章将围绕四大支柱（质量、可靠性、可扩展性、治理）构建数据工程决策的理论框架，为从数据获取到生产部署的技术选择提供系统性指导。我们将探讨这些原则如何贯穿数据全生命周期，阐明构建可适应、可扩展数据基础设施所需的系统性思维。

我们不孤立分析技术组件，而是关注工程决策的系统性关联，展示数据基础设施的内在互联性。这种整体分析视角，尤其重要于后续章节将要探讨的计算框架——这些框架正是依赖于精心设计的数据集。

四大支柱框架

构建高效 ML 系统，既要理解数据工程是什么，更要有一套结构化框架，指导数据基础设施的原则性决策。存储格式、数据摄取模式、处理架构、治理策略等选择，都需要系统性评估，而非临时拍板。该框架将数据工程归纳为四大支柱，确保系统具备功能性、稳健性、可扩展性和可信性。

四大基础支柱

每一个数据工程决策——无论是存储格式选择还是管道设计——都应以四大基础原则为评判标准。每个支柱通过系统性决策为系统成功贡献关键能力。

首先，数据质量是系统成功的基石。质量问题会在 ML 生命周期中层层放大，形成“数据级联”现象，即早期失误会在后续环节被放大。质量包括准确性、完整性、一致性和对目标任务的适用性。高质量数据是模型成功的前提，其数学基础可参考 第 3 章：深度学习基础 和 第 4 章：DNN 架构 。

在质量基础之上，ML 系统需要一致、可预测的数据处理，能优雅应对故障。可靠性要求系统在组件故障、数据异常或负载突发时仍能持续运行。这包括在数据管道中实现全面的错误处理、监控和恢复机制。

可靠性保障了稳定运行，而可扩展性则应对增长挑战。ML 系统从原型到生产服务，数据量和处理需求会急剧增加。可扩展性要求系统能应对数据量、用户规模和计算需求的增长，而无需彻底重构。

最后，治理为前三者提供运行框架。数据治理确保系统在法律、伦理和业务约束下运行，保持透明和问责。这包括隐私保护、偏差缓解、合规性，以及明确的数据所有权和访问控制。

系统性思维下的支柱整合

理解每个支柱的独立意义只是第一步，真正高效的数据工程在于认识到它们是一个统一系统的互联方面，任何一处决策都会影响其他支柱。质量提升要兼顾可扩展性约束，可靠性需求影响治理实现，治理政策又会塑造质量指标。这种系统性视角贯穿本章，我们将探讨各技术主题如何支撑并平衡这些基础原则，同时系统性管理它们之间的张力。

如图 2 所示，行业调查显示数据科学家有 60-80% 的时间花在数据准备上¹。这反映了当前数据工程实践多为临时应对而非系统性方法。通过持续应用四大支柱框架，团队可减少数据准备时间，同时构建更可靠、可维护的系统。

框架在数据生命周期中的应用

四大支柱框架贯穿数据工程系统从问题定义到生产运维的全过程。我们首先明确问题定义和治理原则，这将影响后续所有技术决策。框架随后指导数据获取策略，质量和可靠性要求决定数据来源和验证方式。处理和存储决策则受可扩展性和治理约束影响，运维实践确保四大支柱在系统生命周期内持续发挥作用。

该框架指导我们系统性地探索数据工程的各个组成部分。后续章节将详细分析数据获取、摄取、处理和存储，探讨支柱如何在具体技术决策中体现：如何在质量与规模间权衡数据获取技术，如何在治理约束下设计存储架构，如何在大规模处理下保持可靠性。

下表全面展示了各支柱在数据管道主要阶段的具体体现。该矩阵既可作为系统设计的规划工具，也可作为故障排查的参考。

为便于理解，我们将以关键词识别（KWS）系统为案例，贯穿全章，展示框架原则如何转化为工程决策。

数据级联与系统性基础的必要性

机器学习系统面临一种区别于传统软件工程的独特故障模式——“数据级联”²，即 Sambasivan 等人提出的现象：早期数据质量缺陷会在整个管道中放大，导致模型失效、项目终止甚至用户伤害。与传统软件遇到异常输入即报错不同，ML 系统会悄然退化，直到质量问题严重到必须重建系统。

数据级联往往源于团队在数据采集和处理前，未建立清晰的质量标准、可靠性要求和治理原则。这一根本性漏洞促使我们采用“四大支柱”框架：质量、可靠性、可扩展性、治理，为防止级联故障、构建稳健 ML 系统提供系统性基础。

图 3 展示了各阶段可能出现的数据隐患及其对后续流程的影响。数据采集阶段的失误尤为致命，如图所示，初始环节的疏漏会在模型评估和部署阶段（见 第 8 章：AI 训练 和 第 13 章：机器学习运维 ）暴露，可能导致高昂代价甚至推倒重来。因此，从一开始就投资数据工程技术，有助于及早发现错误，减轻级联效应。

早期确立治理原则

理解了质量问题如何在 ML 系统中级联，我们必须确立治理原则，确保数据工程系统在伦理、法律和业务约束下运行。这些原则不是事后补充，而是从一开始就要融入每一个技术决策。

治理原则的核心，是数据系统必须在全生命周期内保护用户隐私和安全。这意味着从系统设计初期就要实施访问控制、加密和数据最小化，而不是事后补丁。隐私要求直接影响数据采集方式、存储架构和处理方法。

除了隐私保护，数据工程系统还需主动识别和缓解数据采集、标注和处理中的偏差。这需要多样化采集策略、代表性抽样和全流程偏差检测。数据来源、标注方法和质量指标的技术选择都会影响系统公平性。数据中的隐性分层（如某些群体样本不足或模式不同），会导致模型在表面表现良好但在特定群体系统性失效，因此人口均衡和代表性必须从采集环节工程化。

治理还要求系统有清晰的数据来源、处理决策和质量标准文档。这包括数据溯源、处理日志和明确的数据质量责任归属。

最后，数据系统必须遵守相关法规，如 GDPR、CCPA 及行业规范。合规要求影响数据保留策略、用户同意机制和跨境数据传输协议。

治理原则与质量、可靠性、可扩展性技术支柱密不可分。若系统侵犯隐私，则无法称为可靠；若质量指标助长不公平，则毫无意义。

问题定义的结构化方法

在治理基础上，我们需要系统性的问题定义方法。正如 Sculley 等人所强调，ML 系统的问题框架远超传统软件开发。无论是处理数百万用户交互的推荐系统、分析医学影像的视觉系统，还是处理多样文本的自然语言模型，每种系统都带来独特挑战，需在治理和技术框架下慎重考量。

明确目标，为项目从数据采集到部署运维提供统一方向。这些目标需兼顾技术性能与治理要求，形成可衡量的结果，包括准确率和公平性指标。

系统性问题定义确保治理原则和技术需求从一开始就融合，而非事后补救。为实现这一融合，采集前必须完成以下关键步骤：

1. 明确问题定义
2. 设定清晰目标
3. 建立成功基准
4. 理解终端用户参与/使用场景
5. 理解部署约束和限制
6. 执行数据采集
7. 迭代优化

框架在关键词识别案例中的应用

为展示系统性原则的实际运用，关键词识别（KWS）系统是理想案例，能将四大支柱框架应用于真实数据工程挑战。这类系统为智能手机、智能音箱等语音激活设备提供唤醒词检测，需在极低资源下实现高准确率。

如图 4 所示，KWS 系统作为轻量级、常驻前端，触发更复杂的语音处理。该系统体现了框架四大支柱的互联挑战（见 第 6 章：数据工程 ：质量（多环境高准确率）、可靠性（电池供电下持续运行）、可扩展性（极限内存约束）、治理（隐私保护）。这些约束解释了为何许多 KWS 系统仅支持少数语言：为小语种收集高质量、代表性语音数据，因治理和扩展性挑战而成本高昂，说明四大支柱必须协同才能成功部署。

基于框架理解，我们可将问题定义方法应用于 KWS 案例，展示四大支柱如何指导工程决策：

1. 问题识别：KWS 需在环境噪声和其他语音中检测特定关键词。核心问题是设计能在有限计算资源下高准确、低延迟、极少误报/漏报的系统。新 KWS 模型开发应明确目标关键词及应用场景和部署环境。

2. 目标设定：KWS 系统目标需平衡多重需求。性能指标包括高准确率（关键词检测 98%）、低延迟（200 毫秒内响应）。资源约束要求极低功耗以延长嵌入式设备电池寿命，模型体积需适配设备内存。

3. 成功基准：建立衡量 KWS 系统成功的指标。关键指标包括真阳性率（正确识别关键词占所有关键词）、假阳性率（将非关键词误识为关键词，包括静音、噪声、超词）。检测/错误权衡曲线在流式音频上评估 KWS，比较每小时误接受数（假阳性/总评估时长）与漏检率（漏检/总关键词），如@nayak2022improving 所示。运维指标包括响应时间（关键词到系统响应）和功耗（持续监听平均功率）。

4. 利益相关者参与与理解：利益相关者包括设备制造商、软硬件开发者和终端用户。需理解各方需求和约束。制造商关注低功耗，开发者重集成易用性，用户则关注准确和响应速度。平衡这些需求，塑造系统架构决策。

5. 嵌入式系统约束理解：嵌入式设备有自身挑战，影响 KWS 设计。内存限制要求模型极小（如 16KB，仅存权重，预处理代码也需适配）。处理能力有限（几百 MHz），需极致优化。功耗关键，多数设备电池供电，KWS 需实现持续监听下亚毫瓦功耗。环境多样性也带来复杂性，设备需适应从安静卧室到嘈杂工厂的部署场景。

6. 数据采集与分析：KWS 系统的数据质量和多样性决定成败。数据集需涵盖人口多样性（不同口音、年龄、性别），确保广泛识别。关键词发音多样性需关注，采集发音细微差异。背景噪声多样性至关重要，需采集或增强不同环境噪声，训练模型适应真实场景。

7. 迭代反馈与优化：原型 KWS 开发后，需确保系统随部署场景和用例变化持续符合定义目标。需在真实场景测试，收集反馈，发现某些用户或场景表现不佳，针对失败模式迭代优化数据集和模型。

基于问题定义，KWS 系统展示了多种数据采集策略如何贯穿项目生命周期。Google Speech Commands 等现有数据集为原型开发提供基础，包含精心标注的唤醒词语音样本。但这些数据集在口音、环境、语言多样性上常有缺口，需补充策略。

为弥补覆盖不足，网页抓取可从视频平台和语音数据库采集多样语音，捕捉自然发音和唤醒词变体。众包平台如 Amazon Mechanical Turk³可针对特定人群和环境采集唤醒词，尤其适合小语种或特殊声学条件。

最后，合成数据生成通过语音合成和音频增强，补齐剩余缺口，创造无限唤醒词变体，涵盖多样环境、说话人特征和背景条件。综合策略让 KWS 系统在多样真实场景下表现稳健，体现系统性问题定义如何贯穿数据策略。

框架原则通过 KWS 案例确立后，接下来将探讨数据管道架构如何将抽象概念转化为实际操作。

数据管道架构

数据管道是四大支柱框架的系统性实现，将原始数据转化为适用于 ML 的格式，同时保持质量、可靠性、可扩展性和治理标准。管道不是简单线性流程，而是需协调多数据源、变换流程和存储系统的复杂系统，确保在不同负载下持续稳定。管道架构将抽象原则转化为具体工程决策，如验证策略、错误处理机制、吞吐优化和可观测性基础设施。

以 KWS 系统为例，管道需处理持续音频流，实现实时关键词检测低延迟，并确保隐私保护。管道需从开发环境处理样本音频扩展到生产环境处理数百万并发流，同时保持严格质量和治理标准。

如架构图所示，ML 数据管道包含多个层次：数据源、摄取、处理、标注、存储和 ML 训练（见图 5）。每层在数据准备流程中扮演特定角色，选择合适技术需理解四大支柱在各阶段的体现。我们不孤立优化各层，而是分析质量需求如何影响扩展约束，可靠性需求如何塑造治理实现，支柱如何共同决定系统效能。

管道设计受存储层级和 I/O 带宽限制，而非 CPU 能力。理解这些约束，才能构建高效系统应对现代 ML 负载。存储层级权衡（高延迟对象存储适合归档，低延迟内存适合实时服务）、带宽限制（机械盘 100-200MB/s，内存 50-200GB/s）影响每个管道决策。

在这些性能约束下，设计决策需与具体需求对齐。流式数据需考虑消息持久性（失败可重放）、顺序保证（事件序列）、地理分布。批处理需关注数据量与内存关系、处理复杂度、是否需分布式。单机工具适合 GB 级数据，TB 级需分布式集群。各层间的互动，通过四大支柱视角，决定系统效能并指导后续技术决策。

质量通过验证和监控

质量是可靠 ML 系统的基础，管道通过各阶段的系统性验证和监控来实现质量。生产经验表明，数据管道问题是 ML 失败的主要来源，研究显示 30-70% 的故障归因于此：模式变化导致下游处理失败、分布漂移降低模型准确性、数据损坏悄然引入错误。这些失败尤其隐蔽，往往不会导致明显的系统崩溃，而是缓慢降低模型性能，直到影响用户后才显现。因此，质量支柱要求主动监控和验证，及时发现问题，防止级联成灾。

理解这些指标在实践中的应用，需考察生产团队如何大规模实施监控。大多数组织采用基于严重程度的警报系统，不同类型的故障触发不同的响应机制。最关键的警报指示系统完全失效：管道停止处理超过 5 分钟，或主要数据源完全不可用。这种情况需要立即处理，因为它会阻止所有下游模型训练或服务。更微妙的降级模式则需要不同的检测策略。当吞吐量降至基线水平的 80% 以下，或错误率超过 5%，或质量指标偏离训练数据特征超过 2 个标准差时，系统会发出需要紧急但非立即处理的降级警报。这些渐进式故障往往比完全宕机更危险，因为它们可能在数小时或数天内持续存在，悄然破坏模型输入，降低预测质量。

以处理用户交互事件的推荐系统为例，其基线吞吐量为 50,000 条记录每秒，监控系统跟踪多个相互依赖的信号。瞬时吞吐量警报在处理能力低于 40,000 条记录每秒超过 10 分钟时触发，考虑到正常流量波动的同时，捕捉到真实的容量或处理问题。数据流中每个特征都有其质量档案：如 user_age 特征在记录中出现空值的比例从训练数据的不足 1% 骤增至 5% 以上，说明上游数据源可能出现故障。重复数据检测在采样数据上运行，监控同一事件是否多次出现——这一模式可能表明重试逻辑出错或数据库查询意外重复返回相同记录。

这些监控维度在考虑端到端延迟时尤为重要。系统不仅需跟踪数据是否到达，还要跟踪从事件发生到特征可用于模型推理的整个过程耗时。当 95 百分位数⁴延迟超过 30 秒时，监控系统需要找出是哪一个管道阶段引入了延迟：摄取、变换、验证还是存储。

质量监控不仅限于简单的模式验证，还包括捕捉服务数据是否类似于训练数据的统计特性。生产系统会在 24 小时窗口内跟踪滚动统计数据。对于数值特征，如 transaction_amount 或 session_duration，系统会持续计算均值和标准差，然后应用 Kolmogorov-Smirnov 检验⁵比较服务数据与训练数据的分布。

分类特征则需不同的统计方法。监控系统跟踪类别频率分布。当出现训练数据中从未出现的新类别，或现有类别的相对频率发生显著变化（如“移动设备”与“桌面”流量比例变化超过 20%），系统会标记潜在的数据质量问题或真实的分布变化。这种统计监控能捕捉到简单模式验证完全忽视的微妙问题：假设年龄值仍在 18-95 的有效范围内，但分布却从主要是 25-45 岁转变为 65 岁以上，说明数据源发生了变化，将导致模型性能受损。

管道级验证则包括多种策略协同工作。模式验证在数据进入管道时同步执行，立即拒绝格式错误的记录，防止其向下游传播。现代工具如 TensorFlow Data Validation (TFDV)⁶能自动从训练数据推断模式，捕捉预期数据类型、值范围和存在要求。

这种同步验证必须简单快速，仅检查可在单条记录上微秒级评估的属性。更复杂的验证，如需要比较服务数据与训练数据分布，或跨多条记录汇总统计信息的验证，必须异步运行，以免阻塞摄取管道。统计验证系统通常对 1-10% 的服务流量进行抽样——足以检测到有意义的变化，同时避免分析每条记录的计算开销。这些样本在滚动窗口中累积，通常为 1 小时、24 小时和 7 天，不同窗口揭示不同模式。每小时窗口可检测到数据源突然切换到特征不同的备份时的突发变化，而每周窗口则揭示用户群体或行为的渐进式漂移。

也许最隐蔽的验证挑战来自训练 - 服务偏差⁷，即相同特征在训练和服务时的计算方式不同，导致模型悄然退化。这通常发生在训练管道使用一套库或逻辑进行批处理数据时，而服务系统则使用不同的实现实时计算特征。例如，推荐系统可能在训练时通过将用户档案与完整交易历史连接来计算“用户生命周期内的购买次数”，而服务系统却意外地使用了每周更新一次的缓存物化视图。

可靠性通过优雅降级

在质量监控发现问题后，可靠性确保系统在出现故障时仍能有效运行。管道面临着数据源暂时不可用、网络分区、上游模式变化或负载激增等持续挑战。可靠性支柱要求系统优雅处理这些故障，而不是陷入全面停机。这种弹性来自系统性故障分析、智能错误处理和自动恢复策略，即使在不利条件下也能维持服务连续性。

针对 ML 数据管道的系统性故障模式分析揭示了可预测的模式，需采取特定工程对策。数据损坏故障发生在上游系统引入细微格式变化、编码问题或字段值修改时，这些问题可能通过基本验证，但会破坏模型输入。例如，日期字段从“YYYY-MM-DD”格式切换为“MM/DD/YYYY”格式，可能不会触发模式验证，但会破坏任何基于日期的特征计算。模式演变⁸故障发生在源系统添加字段、重命名列或更改数据类型时，打破下游处理对特定字段名称或类型的预期。

建立在故障分析基础上的有效错误处理策略，确保问题被系统性地控制和恢复。对瞬时错误（如网络中断或临时服务故障）实施智能重试逻辑，需采用指数退避策略，避免对恢复中的服务造成过大压力。简单的线性重试（每秒重试一次）会对处于恢复中的服务造成洪水般的连接请求，可能阻碍其恢复。指数退避策略（先等待 1 秒，再等 2 秒，接着 4 秒，依此类推）则为服务恢复提供了喘息空间，同时保持了重试的持续性。许多 ML 系统采用死信队列⁹，将多次重试仍失败的数据存储在单独位置，便于后续分析和潜在重处理，而不阻塞主管道。例如，处理金融交易的管道遇到格式错误数据时，可以将其路由到死信队列，而不是丢失关键记录或停止所有处理。

超越临时错误处理，级联故障预防需要电路断路器¹⁰模式和舱壁隔离，以防单个组件故障传播至整个系统。当特征计算服务失败时，断路器模式会在检测到重复故障后停止调用该服务，防止调用方因等待超时而导致自身失败。

自动化恢复工程实现了超越简单重试逻辑的复杂策略。渐进式超时增加防止在服务恢复时对其施加过大压力，同时保持对瞬时问题的快速恢复——初始请求在 1 秒后超时，但在检测到服务降级后，超时延长至 5 秒，然后是 30 秒，给服务稳定的时间。多级后备系统在主要数据源失败时提供降级服务：在实时计算失败时提供稍微过时的缓存特征，或在确切计算超时的情况下使用近似特征。当无法计算过去 30 天的用户偏好时，推荐系统可能回退到使用过去 90 天的偏好，提供稍微不那么准确但仍然有用的推荐，而不是完全失败。全面的警报和升级程序确保在自动恢复失败时进行人工干预，并在故障发生时捕获足够的诊断信息，以便快速调试。

这些概念在处理金融市场数据的 ML 系统时变得具体。当实时数据源失败时，错误处理可能涉及切换到稍有延迟的数据源，同时向运维团队发出警报。死信队列捕获格式错误的价格更新以供调查，而不是静默丢弃。电路断路器防止系统在市场数据提供商恢复期间不堪重负。全面的错误管理确保下游过程获得可靠、高质量的数据用于训练和推理，即使在分布式系统不可避免的故障面前。

可扩展性模式

在质量和可靠性确保系统正确操作的同时，可扩展性则应对不同的挑战：系统如何随着数据量的增长而演变，以及 ML 系统如何从原型发展为生产服务。能够在 GB 级别有效运作的管道，在 TB 级别可能因缺乏分布式处理能力而崩溃。可扩展性涉及设计能够处理不断增长的数据量、用户基础和计算需求的系统，而无需完全重新设计。关键在于可扩展性约束在管道各阶段的不同表现，摄取、处理和存储需要不同的架构模式。

ML 系统通常遵循两种主要的摄取模式，每种模式在数据流动时机和处理方式上有所不同，反映出在成本、延迟和复杂性之间的不同权衡。当实时数据处理不是关键，且数据可以在预定时间间隔内处理时，批量摄取（Batch Ingestion）是一种有效的方法。比如，零售公司可以选择在夜间处理每日销售数据，通过批量摄取在第二天早上更新库存预测的 ML 模型。批处理通过在大数据量上摊销启动成本，利用可用或成本最低的资源进行高效计算。例如，处理一 TB 交易数据的作业可以使用 100 台机器运行 10 分钟，这比维持始终在线的基础设施更具资源效率。

与这种定期处理方式相对，流式摄取（Stream Ingestion）则是实时处理到达的数据。这一模式对于需要立即数据处理、数据快速失去价值的场景，以及需要对事件实时响应的系统至关重要。例如，金融机构可能会使用流式摄取进行实时欺诈检测，处理每一笔实时交易，立即标记可疑活动。然而，当下游系统无法跟上数据产生速度时，流处理必须处理背压问题¹¹——当流量激增时，系统必须缓冲数据（需要内存）、抽样（丢失部分数据）或向生产者施压（可能导致失败）。数据新鲜度服务水平协议（SLA）¹²正式规定了这些要求，指定数据生成和处理可用之间的最大可接受延迟。

认识到单一方法的局限性，许多现代 ML 系统采用混合方式，结合批处理和流处理以应对不同数据速度和用例。这种灵活性使系统能够同时处理历史数据和实时数据流，提供数据全景。生产系统在选择模式时，必须权衡成本与延迟的关系：实时处理的成本可能是批处理的 10-100 倍。这种成本差异源于多个因素：流处理系统需要始终在线的基础设施，而不是可以根据工作负载启停的可调资源；为确保不丢失事件，流处理需维护冗余处理；低延迟网络和存储是满足毫秒级 SLA 的必要条件；流处理无法像批处理那样，通过在大数据量上摊销启动成本来实现规模经济。处理一 TB 训练数据在 10GB/s 网络吞吐量下需要 74 秒，接近训练周期本身的时间。这一分析揭示了高吞吐量存储（NVMe SSD 实现 5-7GB/s）和网络基础设施（25-100Gbps 互连）对 ML 工作负载的关键性，因为数据移动时间与计算时间相当。

可扩展性架构支持从开发到生产的全流程，同时在每个阶段保持高效，容量规划确保基础设施与工作负载需求相匹配。

治理通过可观测性实现

在通过质量、可靠性和可扩展性满足功能性需求后，我们转向治理支柱。治理支柱在管道中体现为全面的可观测性——了解数据如何流经系统、如何转化以及谁可以访问。有效的治理需要追踪数据从源头到最终数据集的全流程，维护合规所需的审计追踪，并实施强制组织政策的访问控制。在关注系统功能的其他支柱之外，治理确保操作在法律、伦理和业务约束内进行，同时保持透明和问责。

数据溯源追踪每个数据集的完整来源：哪些原始数据源提供了数据、进行了什么转换、何时处理、执行了什么版本的处理代码。对于 ML 系统，溯源对于调试模型行为和确保可重复性至关重要。当模型预测错误时，工程师需要追溯管道：哪些训练数据导致了这个预测，这些数据的质量指标是什么，进行了什么转换，我们能否重现这个场景以便调查？现代溯源系统如 Apache Atlas、Amundsen 或商业产品，通过自动捕获管道流动的方式对管道进行仪器化。每个管道阶段都会用描述其来源的元数据注释数据，创建审计线索，以便于调试和合规。

审计追踪补充了溯源，通过记录谁在何时访问了数据来满足合规性框架的要求，如 GDPR 要求组织证明适当的数据处理，包括跟踪对个人信息的访问。ML 管道在数据访问点实施审计日志记录：当训练作业读取数据集时、服务系统检索特征时或工程师查询数据进行分析时。这些日志通常记录用户身份、时间戳、访问的数据和目的。例如，医疗保健 ML 系统的审计追踪通过显示只有授权人员访问患者数据、访问是出于合法医疗目的、数据未被保留超过允许时间，来证明合规性。生产系统中审计日志的规模可能相当可观——高流量推荐系统可能每天生成数百万条审计事件——这就需要高效的日志存储和查询基础设施。

访问控制在每个管道阶段强制执行关于谁可以读取、写入或转换数据的策略。ML 系统通常实施基于属性的访问控制，考虑数据敏感性、用户角色和访问上下文。例如，数据科学家可能可以自由访问匿名化的训练数据，但需要批准才能访问包含个人信息的原始数据。生产服务系统可以读取特征数据但不能写入，防止意外损坏。访问控制与数据目录集成，后者维护关于数据敏感性、合规要求和使用限制的元数据，支持数据在流经管道时的自动化政策执行。

来源元数据的保留确保了调试和合规所需的可重复性。当六个月前训练的模型表现优于当前模型时，团队需要重现当时的训练环境：确切的数据版本、转换参数和代码版本。ML 系统通过全面的元数据捕获实现这一点：训练作业记录数据集校验和、转换参数值、可重复性随机种子和代码版本哈希。特征库维护历史特征值，支持训练条件的随时重建。对于我们的 KWS 系统，这意味着跟踪强制对齐生成标签的版本、应用的音频归一化参数、合成数据生成设置以及众包批次对训练数据的贡献。

这些治理机制的集成，将管道从不透明的数据转换器转变为可审计、可重复的系统，能够证明适当的数据处理。这一治理基础设施对于监管合规至关重要，同时也维护了对 ML 系统的信任，因为它们在日益影响用户生活的决策中发挥着重要作用。

在确立了通过验证和监控实现质量，通过优雅降级实现可靠性，通过适当模式实现可扩展性，以及通过可观测性实现治理的全面管道架构后，我们接下来要确定的，是这些精心设计的系统中实际流动的数据。

战略性数据获取

数据获取不仅仅是收集训练样本。这是一个战略性决策，决定了我们系统的能力和局限。我们选择的训练数据来源，直接影响质量基础、可靠性特征、可扩展性潜力和治理合规性。因此，数据来源的选择必须与既定的框架要求相一致。每种获取策略（现有数据集、网页抓取、众包、合成生成）在质量、成本、规模和伦理考虑上都有不同的权衡。关键在于，没有一种方法可以满足所有要求；成功的 ML 系统通常结合多种策略，平衡它们的互补优势与竞争约束。

回到我们的 KWS 系统，数据源决策对四大支柱的深远影响，在 第 6 章：数据工程 的综合案例中得到了充分体现。要实现 98% 的准确率，覆盖多样的声学环境（质量支柱），需要代表性数据，涵盖不同口音、年龄和录音条件。保持一致的检测能力，尽管设备差异（可靠性支柱），需要来自不同硬件的数据。支持数百万并发用户（可扩展性支柱），需要的数据量是人工收集无法经济提供的。保护始终监听系统的用户隐私（治理支柱），限制了采集方式，并要求仔细的匿名化。这些相互关联的要求展示了获取策略必须系统性评估，而非临时选择。

数据源评估与选择

在确立数据获取的战略重要性后，我们首先从质量驱动选择。当质量要求主导获取决策时，经过精心策划的数据集、专家众包和受控网页抓取之间的选择，取决于准确性目标、所需领域专业知识和模型开发的基准要求。质量支柱要求我们理解数据不仅仅是表面正确，还要准确反映部署环境，并充分覆盖可能导致失败的边缘情况。

Kaggle 和 UCI 机器学习库 等平台，为 ML 从业者提供了现成的数据集，能迅速启动系统开发。这些现有数据集的主要优势在于成本效益，因为从零构建数据集需要大量时间和资源，尤其是生产级 ML 系统需要大量高质量训练数据时。基于此成本效益，许多数据集（如 ImageNet）已成为机器学习社区的标准基准，促进了不同模型和架构间的一致性能比较。对于 ML 系统开发者而言，这些数据集的即时可用性，使团队能够在数据采集和预处理上迅速开展实验和原型开发。

尽管有这些优势，ML 从业者仍需仔细考虑现有数据集的质量保证方面。例如， ImageNet 数据集在验证集上的标签错误率高达 3.4%。虽然流行数据集受益于社区的审查，帮助识别和纠正错误和偏见，但大多数数据集仍然是“无人管理的花园”，如果不加以处理，质量问题可能会严重影响下游系统性能。正如 Gebru 等人在其论文中强调的，仅仅提供数据集而不附带文档，可能导致误用和误解，潜在地放大数据中存在的偏见。

除了质量问题，现有数据集附带的支持文档也是极其宝贵的，但往往仅存在于广泛使用的数据集中。良好的文档提供了数据采集过程、变量定义的见解，有时甚至提供了基准模型性能。这些信息不仅有助于理解，还促进了研究的可重复性，这是科学诚信的基石；目前，机器学习系统的可重复性危机亟待改善。当其他研究人员可以访问相同数据时，他们可以验证发现、测试新假设或应用不同的方法，从而更快速地推动我们的工作。

数据质量问题在大数据场景下尤为突出，数据量和多样性加剧了质量隐患，因此需要在规模上实施系统化的质量验证方法。

即使有适当的文档，理解数据收集的上下文也是必要的。当使用流行数据集时，研究人员必须避免潜在的过拟合，这可能导致性能指标虚高。这些数据集有时并不能反映真实世界的数据，详见 这篇文章 。

在所有这些上下文问题中，数据集如何反映真实世界的部署条件，是 ML 系统的一个关键考虑因素。依赖标准数据集可能导致训练和生产环境之间出现令人担忧的脱节。这种不一致在多个 ML 系统都训练于相同数据集时尤为严重（见图 6），可能导致偏见和局限性在整个模型生态系统中传播。

对于我们的 KWS 系统而言，现有数据集如 Google 的 Speech Commands（见 Warden 2018）提供了重要的起点，快速原型开发和基准性能指标。然而，质量驱动的评估很快揭示了其局限性：口音多样性不足、录音环境过于单一、仅支持主要语言。基于质量的获取策略意识到了这些局限，并规划了补充方法，以展示基于框架的思维如何超越可用数据集的简单选择。

可扩展性与成本优化

当质量驱动方法在创建准确、精心策划的数据集方面表现出色时，它们面临着固有的规模限制。当规模需求占主导地位——需要数百万或数十亿个样本，而人工策划无法经济提供时，网页抓取和合成生成提供了获取大规模数据集的途径。可扩展性支柱要求理解不同获取策略背后的经济模型：每个标注样本的成本、吞吐量限制以及这些限制如何随数据量变化而变化。在千级样本规模下有效的策略，在百万级样本规模下可能变得不可承受，而需要高启动成本的策略则可能在大规模下获得有利的摊销。

网页抓取是一种强大的数据获取方式，特别是在现有数据集不足的领域。通过自动化从网站提取数据，这一技术已成为现代 ML 系统开发的必备工具，使团队能够构建量身定制的数据集。当人工标注数据稀缺时，网页抓取展现出其独特价值。例如，计算机视觉系统的重大数据集如 ImageNet 和 OpenImages 就是通过系统化的网页抓取构建的，极大推动了计算机视觉领域的发展。

超越计算机视觉应用，网页抓取的影响远不止于图像识别。在自然语言处理领域，网页抓取的数据推动了越来越复杂的 ML 系统的发展。大型语言模型如 ChatGPT 和 Claude，依赖于从公共互联网和媒体抓取的大量文本数据，学习语言模式并生成响应。类似地，GitHub 的 Copilot 等专用 ML 系统，通过针对性地抓取代码库，展示了如何创建强大的领域特定助手。

在这些基础性发展之上，生产 ML 系统通常需要持续的数据采集，以维持相关性和性能。网页抓取通过收集股票价格、天气模式或产品信息等结构化数据，促进了这一点。然而，这种持续采集对 ML 系统提出了独特挑战。数据一致性至关重要，因为网站结构或内容格式的变化可能会中断数据管道，影响模型性能。因此，适当的数据管理通过数据库或数据仓库，不仅用于存储，还用于维护数据质量和支持模型更新。

然而，除了强大的功能外，网页抓取也带来了多个挑战，ML 系统开发者必须仔细考虑。法律和伦理限制可能会限制数据收集，因为并非所有网站都允许抓取，违反这些限制可能会带来严重后果。使用抓取数据构建 ML 系统时，团队必须仔细记录数据来源，并确保遵守服务条款和版权法。处理用户生成内容时，隐私问题变得尤为重要，通常需要系统化的匿名化程序。

除了法律和伦理约束，技术限制也会影响网页抓取数据的可靠性。网站的速率限制可能会减慢数据收集，而网页内容的动态变化可能会引入不一致，影响模型训练。如图 7 所示，网页抓取可能会产生意外或无关的数据，例如，历史图像出现在当代图像搜索中，这些噪声数据可能会污染训练数据集，降低模型性能。这些问题突显了在基于网页抓取的数据构建的 ML 管道中，彻底的数据验证和清理过程的重要性。

众包则是另一种可扩展的方法，通过分布式人力计算加速数据集创建。像 Amazon Mechanical Turk 这样的平台，通过将标注任务分配给全球劳动力，极大地加速了数据准备阶段。众包的一个重要例子是 ImageNet 数据集 ，该数据集通过将图像标注任务分配给 Mechanical Turk 的贡献者而建立，推动了计算机视觉的革命。

在这一大规模标注工作基础上，数据集的可用性促进了深度学习的突破，包括 2012 年展示大规模神经网络强大能力的 AlexNet 模型。ImageNet 的成功凸显了如何通过众包获取大规模、高质量的数据，推动机器学习系统达到前所未有的性能。众包的潜力还体现在超越传统标注任务的应用中。例如，导航应用 Waze 利用用户众包数据提供实时交通更新、路线建议和事件报告。这些多样化的应用展示了众包的主要优势：可扩展性。通过将微任务分发给大量受众，项目可以快速、经济地处理海量数据。这一可扩展性对于需要大量数据集以实现高性能的机器学习系统尤为重要。贡献者的多样性带来了广泛的视角、文化洞察和语言变体，丰富了数据集，提高了模型跨人群泛化的能力。

除了可扩展性，众包还具有灵活性。任务可以根据初步结果动态调整，允许数据收集的迭代改进。例如，谷歌的 reCAPTCHA 系统利用众包验证人类用户，同时为机器学习模型标注数据集。

超越人类生成数据，合成数据生成则是终极的可扩展解决方案，通过算法生成无限训练样本，而非人工收集。这一方法通过消除人力，改变了数据获取的经济学。如图 8 所示，合成数据与历史数据集结合，创建更大、更具多样性的训练集，弥补稀缺或偏见的真实数据不足，提升模型的泛化能力。这一方法在获取真实数据既不切实际又成本高昂的领域尤为宝贵。汽车行业已广泛采用合成数据来训练自动驾驶系统；物理碰撞测试数据获取有限，合成数据可以在虚拟环境中模拟各种驾驶场景，确保模型能够处理各种复杂情况。这种方法对于推动自动驾驶汽车的能力发展至关重要。

在此基础上，生成式建模技术的进步大幅提升了合成数据的质量。现代 AI 系统能生成与真实世界分布高度相似的数据，使其适用于从计算机视觉到自然语言处理的多种场景。例如，生成模型可用于为目标识别任务创建合成图像，产出与真实图像高度匹配且多样化的数据集。同样，合成数据也被用于模拟语音模式，增强语音识别系统的稳健性。

除质量提升外，合成数据在那些获取真实数据不切实际或成本高昂的领域尤为重要。汽车行业已采用合成数据训练自动驾驶系统；物理上可实施的碰撞测试数量有限，无法获取足够的真实样本来教会 ML 系统如何避免事故。捕捉真实场景——尤其是近乎事故或异常道路状况等罕见边缘案例——本质上很困难。合成数据使研究者能够在受控的虚拟环境中 模拟这些场景 ，确保模型在广泛条件下获得训练。这一方法对推进自动驾驶技术能力已被证明极为宝贵。

除了安全关键应用，合成数据在增强现有数据集方面也发挥着重要作用。通过引入数据集的变化，增强模型的稳健性，使其能够更好地适应不同的环境和说话人风格。在语音识别中，数据增强技术如 SpecAugment 通过引入噪声、偏移或音调变化，增强模型在不同环境和说话人风格下的泛化能力。这一原则同样适用于其他领域，合成数据可以填补代表性不足或边缘案例的空白。

基于我们的 KWS 系统，可扩展性支柱驱动了 2300 万训练样本的需求——这一数据量是人工收集无法经济提供的。网页抓取补充了基础数据集，提供多样的语音样本。众包则针对性地收集了代表性不足的语言数据。合成数据生成通过语音合成和音频增强，填补了剩余的样本缺口，创造了无限的唤醒词变体。这一综合多源策略展示了可扩展性需求如何塑造获取决策，各种方法如何为整体数据生态系统贡献特定能力。

可靠性贯穿多样条件

除了质量和规模，可扩展性支柱还需解决一个关键问题：我们收集的数据能否使模型在部署环境的各种条件下都能可靠运行？如果训练数据在统计特性上与生产环境相去甚远，即使数据质量再高，也无法支撑可靠的生产系统。稳健模型的覆盖要求超越简单的样本量，涵盖地理多样性、人口统计代表性、时间变化和边缘案例等高风险场景。

理解覆盖要求需要分析潜在的失败模式。地理偏差发生在训练数据主要来自特定地区时，导致模型在其他地区表现不佳。对图像数据集的研究发现显著的地理偏斜，主要基于西方图像训练的图像识别系统在其他地区的图像上表现不佳。人口统计偏差则出现在训练数据未能代表全体用户时，可能导致歧视性结果。时间变化在现象变化时尤为重要——仅基于历史数据训练的欺诈检测模型可能无法应对新出现的欺诈模式。边缘案例的收集尤其具有挑战性，但却至关重要，因为这些罕见场景往往是导致严重后果的高风险情境。

边缘案例收集的挑战在于自动驾驶汽车开发中尤为明显。正常驾驶条件下的数据采集相对简单，但近乎事故、异常行人行为或罕见天气条件等边缘案例的捕捉则困难重重。合成数据生成通过模拟这些罕见场景提供了解决方案，但验证合成样本是否准确代表真实边缘案例则需要仔细的工程设计。一些组织通过定向数据收集来应对，例如让测试驾驶员故意制造边缘案例，或通过工程师从事件报告中识别需要更好覆盖的场景。

如前所述，数据集趋同（见图 6）代表了另一种可靠性挑战。当多个系统在相同数据集上训练时，它们会继承相同的盲点和偏见。整个模型生态系统可能在相同的边缘案例上失效，因为都训练于相同的覆盖缺口数据上。这种系统性风险促使多样化数据采集策略的实施，确保每个组织在公共基准之外收集补充数据，从而确保其模型发展出不同的优势和劣势，而不是共享的失败模式。

对于我们的 KWS 系统，可靠性体现在各种声学环境中唤醒词检测的一致性，包括安静的卧室、嘈杂的街道、不同口音和各个年龄段的说话人。数据源策略明确了这些多样性要求：网页抓取捕捉不同视频源的自然语音变化，众包针对代表性不足的人群和环境，合成数据则系统性地探索声学条件的参数空间。若没有这种针对性的数据源策略，系统可能在测试集上表现出色，但在生产部署中却表现不稳定。

治理与伦理采集

数据获取中的治理支柱涵盖法律合规、对数据贡献者的伦理对待、隐私保护，以及对数据来源和局限性的透明度。与关注系统能力的其他支柱不同，治理确保数据采集在适当的法律和伦理边界内进行。治理失败的后果超越系统性能，可能导致声誉受损、法律责任，以及对数据收集或使用不当的个人造成潜在伤害。

法律约束显著限制了在不同司法管辖区和领域的数据收集方法。并非所有网站都允许抓取，违反这些限制可能会带来严重后果，正如当前围绕大型语言模型训练数据的诉讼所示。版权法规定了公开内容用于训练的标准，而各司法管辖区标准不同。服务条款可能禁止将数据用于机器学习训练，即使技术上可以访问。隐私法规如欧洲的 GDPR 和加州的 CCPA 对个人数据收集提出了严格要求，需征得同意、支持删除请求，有时还需解释算法决策。医疗数据则需遵循美国 HIPAA 等额外法规，要求对患者信息采取特定保护措施。组织必须仔细遵循这些法律框架，记录数据来源，并确保在整个获取过程中遵守规定。

除了法律合规，伦理采集要求对人类贡献者的公平对待。我们之前审视的众包案例——OpenAI 将数据标注外包给肯尼亚工人，每小时支付低至 1.32 美元，审查创伤性内容——突显了当经济压力压倒伦理考量时可能发生的治理失败。许多工人因接触令人不安的材料而遭受心理伤害，却得不到足够的心理健康支持。这一案例强调了在经济欠发达地区外包数据工作时可能出现的权力不平衡。缺乏公平补偿、对处理敏感内容的工人支持不足、工作条件不透明，都是影响人类福祉的治理失败，超越了系统性能。

针对这些问题，行业标准的伦理众包实践开始出现。公平补偿意味着支付至少当地最低工资，理想情况下与工人所在地区的类似工作水平相当。工人福祉要求为处理敏感内容的工人提供心理健康资源，限制其接触创伤材料的时间，确保合理的工作条件。透明度要求清晰沟通任务目的、贡献如何被使用以及工人权利。像人工智能合作伙伴关系这样的组织，已发布伦理众包的指导方针，建立可接受实践的基准。

在数据获取中，质量、可扩展性和可靠性支柱关注系统能力，而治理支柱则确保数据获取在适当的伦理和法律边界内进行。隐私保护是数据获取中的另一个关键治理问题，特别是当数据涉及未明确同意用于机器学习训练的个人时。处理敏感数据时，匿名化成为关键能力。从数据工程的系统设计角度看，匿名化不仅仅是合规要求，更是影响数据管道架构、存储策略和处理效率的核心设计约束。机器学习系统必须在整个生命周期内处理敏感数据：在收集、存储、转换、模型训练，甚至错误日志和调试输出中。一次隐私泄露可能会危及不仅仅是单个记录，而是整个数据集的安全，使其在未来开发中无法使用。

从业者已开发出一系列匿名化技术，以降低隐私风险。最简单的方法是掩码，通过更改或模糊处理敏感值，使其无法直接追溯到原始数据主体。例如，财务账户或信用卡号码中的数字可以用星号、固定虚拟字符或哈希值替换，以保护敏感信息在显示或记录时的安全。

在直接保护的基础上，概括则通过降低数据的精度或粒度，减少重新识别的可能性。例如，将确切的出生日期或地址替换为更广泛的类别，如年龄范围或邮政编码前缀。比如，用户的确切年龄 37 岁可以概括为 30-39 岁的年龄范围，而其确切地址可能被归类为城市级别的粒度。这一技术通过以聚合形式共享数据来降低重新识别风险，但需谨慎选择粒度——过粗会丧失分析价值，过细则可能在某些条件下仍然允许重新识别。

与简单的标识符替换不同，伪匿名化则通过用人工标识符或“伪名”替换直接标识符（如姓名、社会安全号码、电子邮件地址），从而保护数据主体的身份。这些伪名不得泄露或易于追溯到原始数据主体，从而实现对同一个体记录的链接而不暴露其身份。

更正式的隐私保护方法是 k-匿名性，通过抑制或概括准标识符（即可能用于重新识别个体的属性，如邮政编码、年龄和性别），确保数据集中每条记录在至少 k-1 条其他记录中是不可区分的。例如，若 k=5，则每条记录必须与至少另外四条记录共享相同的准标识符组合，以防止攻击者仅通过查看这些属性就定位个体。这一方法提供了正式的隐私保证，但可能需要显著的数据扭曲，并且无法防范同质性或背景知识攻击。

在最复杂的隐私保护方法中，差分隐私通过向查询结果或数据集引入经过精心校准的噪声或随机数据扰动，确保任何单个个体数据的包含或排除对输出没有显著影响，从而隐藏其存在。引入噪声的过程由ε差分隐私中的ε参数控制，平衡数据效用和隐私保证。这一方法提供了强大的数学隐私保证，广泛应用于学术和工业界，但引入的噪声可能会影响数据准确性和模型性能，因此需要仔细调整参数以平衡隐私和实用性。

下表总结了每种匿名化方法的关键特征，帮助从业者根据特定隐私要求和数据效用需求选择合适的技术。

如比较表所示，有效的数据匿名化在隐私和效用之间取得平衡。掩码、概括、伪匿名化、k-匿名性和差分隐私等技术，针对重新识别风险的不同方面。通过仔细选择和组合这些方法，组织可以在尊重个人隐私权利和期望的同时，负责任地从敏感数据集中获取价值。

对于我们的 KWS 系统，治理约束贯穿始终。语音数据本质上包含生物特征信息，需进行隐私保护，这驱动了对匿名化、同意要求和数据保留政策的决策。多语言支持则提出了公平性问题——系统是否仅服务于商业价值高的语言，还是也涵盖较小语言社区？公平的众包实践确保提供语音样本或标注的注释者获得适当补偿，并理解其贡献的用途。对数据来源和局限性的透明度，使用户能够理解系统能力和潜在偏见。这些治理考量不仅限制了获取方式，也塑造了哪些方法在伦理和法律上是可接受的。

综合获取策略

在审视了每个支柱如何塑造获取选择后，我们现在明白，现实世界的 ML 系统很少单独使用一种获取方法。相反，它们战略性地结合多种方法，以平衡竞争的支柱要求，认识到每种方法都为整体数据生态系统贡献了互补的优势。数据获取的艺术在于理解这些来源如何协同工作，创建同时满足质量、可扩展性、可靠性和治理约束的数据集。

我们的 KWS 系统就是这种综合方法的典范。Google 的 Speech Commands 数据集提供了经过质量保证的基础，支持快速原型开发和性能基准的建立。然而，对其质量驱动的评估很快揭示了其局限性：口音多样性不足、仅支持主要语言、录音环境过于单一。网页抓取通过从视频平台和语音数据库收集多样的语音样本，部分弥补了这些缺陷，捕捉了跨环境的自然语音变化。尽管网页抓取在规模上超越了人工收集，但其自动化过滤仍需保持合理的质量。

众包则填补了现有数据集和网页抓取无法充分覆盖的特定领域：如代表性不足的口音、特定人群和环境。通过精心设计众包任务，明确指南和质量控制，系统在规模和质量之间达成了平衡，同时确保对贡献者的伦理对待。合成数据生成则通过系统性地探索参数空间，补充了长尾的稀有条件，解决了自然采集难以获得的样本。这一方法不仅提高了模型对各种声学条件的适应能力，也为模型性能的影响因素提供了控制实验的可能。

这些方法的综合运用，展示了我们的框架如何指导数据获取策略。质量要求推动了对策划数据集和专家审查的使用。可扩展性需求则促使了合成数据和网页抓取的应用。可靠性要求则确保了跨人口统计和环境的多样化采集。治理约束则塑造了对同意、匿名化和公平补偿政策的决策。这些获取策略的整合，体现了如何通过框架化思维，系统性地满足多重工程约束，确保数据的全面性、质量和合规性。

在详细探讨了数据获取策略后，我们接下来将分析数据摄取过程——数据如何从外部来源流入我们的系统，并在此过程中保持质量、可靠性、可扩展性和治理标准。

数据摄取

数据摄取是数据进入 ML 系统的关键环节，将来自多种外部来源的数据转化为标准化的管道输入。这一边界层必须处理因多源获取策略而产生的异构性，同时保持我们既定的质量、可靠性、可扩展性和治理标准。从外部来源到受控管道环境的转变，给我们的四大支柱带来了不同的挑战。质量支柱要求在数据进入管道前进行验证，以防问题向下游传播。可靠性支柱要求在源头故障和数据异常情况下，仍能保持操作。可扩展性支柱则需要优化吞吐量，以应对不断增长的数据量和速度。治理支柱则在外部数据进入受信环境时，强制实施访问控制和审计追踪。摄取环节的精心工程设计，确保了问题数据无法进入管道，同时允许 ML 系统所需的数据流动。

批处理与流处理摄取模式

为系统性应对这些摄取挑战，ML 系统通常遵循两种主要模式，反映了数据流动时机和处理方式的不同。这两种模式各有特征和适用场景，塑造了系统在成本、延迟和复杂性之间的平衡。理解何时应用批处理或流处理摄取，或两者的组合，需分析工作负载特性与我们的框架要求之间的关系。

批量摄取（Batch Ingestion）是指在指定时间段内收集一组数据后再进行处理。这种方法适用于对实时数据处理要求不高、数据可以在预定时间间隔内处理的场景。例如，零售公司可以选择在夜间处理每日销售数据，通过批量摄取在第二天早上更新库存预测的 ML 模型。批处理通过在大数据量上摊销启动成本，利用可用或成本最低的资源进行高效计算。例如，处理一 TB 交易数据的作业可以使用 100 台机器运行 10 分钟，这比维持始终在线的基础设施更具资源效率。

与这种定期处理方式相对，流式摄取（Stream Ingestion）则是实时处理到达的数据。这一模式对于需要立即数据处理、数据快速失去价值的场景，以及需要对事件实时响应的系统至关重要。例如，金融机构可能会使用流式摄取进行实时欺诈检测，处理每一笔实时交易，立即标记可疑活动。然而，当下游系统无法跟上数据产生速度时，流处理必须处理背压问题¹¹——当流量激增时，系统必须缓冲数据（需要内存）、抽样（丢失部分数据）或向生产者施压（可能导致失败）。数据新鲜度服务水平协议（SLA）¹²正式规定了这些要求，指定数据生成和处理可用之间的最大可接受延迟。

认识到单一方法的局限性，许多现代 ML 系统采用混合方式，结合批处理和流处理以应对不同数据速度和用例。这种灵活性允许系统同时处理历史数据和实时数据流，提供数据全景。生产系统在选择模式时，必须权衡成本与延迟的关系：实时处理的成本可能是批处理的 10-100 倍。这种成本差异源于多个因素：流处理系统需要始终在线的基础设施，而不是可以根据工作负载启停的可调资源；为确保不丢失事件，流处理需维护冗余处理；低延迟网络和存储是满足毫秒级 SLA 的必要条件；流处理无法像批处理那样，通过在大数据量上摊销启动成本来实现规模经济。处理一 TB 训练数据在 10GB/s 网络吞吐量下需要 74 秒，接近训练周期本身的时间。这一分析揭示了高吞吐量存储（NVMe SSD 实现 5-7GB/s）和网络基础设施（25-100Gbps 互连）对 ML 工作负载的关键性，因为数据移动时间与计算时间相当。

可扩展性架构支持从开发到生产的全流程，同时在每个阶段保持高效，容量规划确保基础设施与工作负载需求相匹配。

治理通过可观测性实现

在通过质量、可靠性和可扩展性满足功能性需求后，我们转向治理支柱。治理支柱在管道中体现为全面的可观测性——了解数据如何流经系统、如何转化以及谁可以访问。有效的治理需要追踪数据从源头到最终数据集的全流程，维护合规所需的审计追踪，并实施强制组织政策的访问控制。在关注系统功能的其他支柱之外，治理确保操作在法律、伦理和业务约束内进行，同时保持透明和问责。

数据溯源追踪每个数据集的完整来源：哪些原始数据源提供了数据、进行了什么转换、何时处理、执行了什么版本的处理代码。对于 ML 系统，溯源对于调试模型行为和确保可重复性至关重要。当模型预测错误时，工程师需要追溯管道：哪些训练数据导致了这个预测，这些数据的质量指标是什么，进行了什么转换，我们能否重现这个场景以便调查？现代溯源系统如 Apache Atlas、Amundsen 或商业产品，通过自动捕获管道流动的方式对管道进行仪器化。每个管道阶段都会用描述其来源的元数据注释数据，创建审计线索，以便于调试和合规。

审计追踪补充了溯源，通过记录谁在何时访问了数据来满足合规性框架的要求，如 GDPR 要求组织证明适当的数据处理，包括跟踪对个人信息的访问。ML 管道在数据访问点实施审计日志记录：当训练作业读取数据集时、服务系统检索特征时或工程师查询数据进行分析时。这些日志通常记录用户身份、时间戳、访问的数据和目的。例如，医疗保健 ML 系统的审计追踪通过显示只有授权人员访问患者数据、访问是出于合法医疗目的、数据未被保留超过允许时间，来证明合规性。生产系统中审计日志的规模可能相当可观——高流量推荐系统可能每天生成数百万条审计事件——这就需要高效的日志存储和查询基础设施。

访问控制在每个管道阶段强制执行关于谁可以读取、写入或转换数据的策略。ML 系统通常实施基于属性的访问控制，考虑数据敏感性、用户角色和访问上下文。例如，数据科学家可能可以自由访问匿名化的训练数据，但需要批准才能访问包含个人信息的原始数据。生产服务系统可以读取特征数据但不能写入，防止意外损坏。访问控制与数据目录集成，后者维护关于数据敏感性、合规要求和使用限制的元数据，支持数据在流经管道时的自动化政策执行。

来源元数据的保留确保了调试和合规所需的可重复性。当六个月前训练的模型表现优于当前模型时，团队需要重现当时的训练环境：确切的数据版本、转换参数和代码版本。ML 系统通过全面的元数据捕获实现这一点：训练作业记录数据集校验和、转换参数值、可重复性随机种子和代码版本哈希。特征库维护历史特征值，支持训练条件的随时重建。对于我们的 KWS 系统，这意味着跟踪强制对齐生成标签的版本、应用的音频归一化参数、合成数据生成设置以及众包批次对训练数据的贡献。

这些治理机制的集成，将管道从不透明的数据转换器转变为可审计、可重复的系统，能够证明适当的数据处理。这一治理基础设施对于监管合规至关重要，同时也维护了对 ML 系统的信任，因为它们在日益影响用户生活的决策中发挥着重要作用。

在确立了通过验证和监控实现质量，通过优雅降级实现可靠性，通过适当模式实现可扩展性，以及通过可观测性实现治理的全面管道架构后，我们接下来要确定的，是这些精心设计的系统中实际流动的数据。

ETL 与 ELT 比较

在选择摄取模式的同时，设计有效的数据摄取管道还需理解提取 - 转换 - 加载（ETL）¹³和提取 - 加载 - 转换（ELT）¹⁴方法之间的差异，如图 9 所示。这些范式决定了数据转换相对于加载阶段的时序，显著影响 ML 管道的灵活性和效率。ETL 与 ELT 的选择影响计算资源的消耗位置、数据可用于分析的速度，以及当需求变化时转换逻辑的演变难易程度。

ETL 是一种成熟的范式，数据首先从源头提取，然后转换以匹配目标模式或模型，最后加载到数据仓库或其他存储中。这种方法通常会将数据存储为准备查询的格式，对于需要一致、预处理数据的 ML 系统来说，这可能是个优势。转换步骤在数据到达仓库之前的单独处理层中进行，使其在持久化之前能够验证和标准化。例如，预测客户流失的 ML 模型可能使用 ETL 将来自多个来源的客户互动数据标准化和汇总——将不同的时间戳格式转换为 UTC，将文本编码标准化为 UTF-8，以及计算“过去 30 天总购买次数”等聚合特征——然后加载为适合模型训练的格式。

ETL 的优势在于处理流程和模式稳定的场景。只有经过清洗、验证和转换的数据才会到达仓库，减少了存储需求，简化了下游查询。安全性和隐私合规可以在转换过程中执行，确保敏感数据在到达存储之前被掩码或加密。质量验证在加载之前进行，防止损坏或无效数据进入仓库。对于具有稳定特征管道和明确数据质量要求的 ML 系统，ETL 提供了原始数据与训练数据之间的清晰分离。

然而，当模式或需求频繁变化时，ETL 的灵活性不足，这在快速发展的 ML 项目中很常见。当转换逻辑发生变化（如添加新特征、修改聚合或修正错误）时，所有源数据必须重新通过 ETL 管道处理以更新仓库。这一重新处理可能需要数小时或数天，减缓 ML 开发的迭代速度。转换层需要专用基础设施和专业知识，增加了数据管道的操作复杂性和成本。

这时，ELT 方法的优势便显现出来。ELT 通过先加载原始数据，再根据需要在目标系统内应用转换，逆转了这一过程。这种方法通常出现在现代数据湖或按读模式解析的环境中，当分析需求不断变化时，提供了更灵活的应对方式。原始源数据快速加载到可扩展存储中，转换则利用仓库的计算资源进行。现代云数据仓库如 BigQuery、Snowflake 和 Redshift 提供了强大的计算能力，能够在几分钟内对 TB 级数据执行复杂转换。

通过推迟转换，ELT 可以适应同一数据集的不同用途，这在 ML 项目的探索性数据分析阶段或同时开发多个具有不同数据需求的模型时尤为有用。当发现转换逻辑错误时，团队可以通过简单地重新运行转换查询来修正数据，而无需重新从源头摄取。这种灵活性加快了 ML 实验的速度，因为特征工程需求变化迅速。

然而，ELT 对存储系统和查询引擎的要求更高，后者必须处理大量未处理的信息。原始数据存储量大于转换后数据，增加了成本。当多次对同一原始数据执行转换时，查询性能可能会下降，因为每次转换都需在原始数据上执行，而不是读取预计算的结果。隐私和合规性在原始敏感数据保留于存储中而非摄取时被掩盖时变得更加复杂。

在实践中，许多 ML 系统采用混合方法，根据每个数据源或 ML 模型的具体需求，选择 ETL 或 ELT。例如，结构化数据可能使用 ETL，从关系数据库中提取时模式明确且稳定，而非结构化数据如文本或图像则可能使用 ELT，因其转换需求可能随着 ML 模型的优化而演变。高流量点击流数据可能使用 ELT，以实现快速加载和灵活转换，而敏感的财务数据则可能使用 ETL，以在持久化之前强制执行加密和掩码。

在 ETL/ELT 架构中实现流处理组件时，分布式系统原理变得至关重要。CAP 定理¹⁵从根本上限制了流系统设计的选择。Apache Kafka¹⁶优先考虑一致性和分区容忍性，适用于可靠的事件排序，但在网络分区期间可能会出现可用性问题。Apache Pulsar 强调可用性和分区容忍性，提供更好的容错能力，但一致性保证有所放松。Amazon Kinesis 通过精心配置在三者之间取得平衡，但需要理解这些权衡以便正确部署。

多源集成策略

无论采用 ETL 还是 ELT，在数据摄取中集成多样数据源都是 ML 系统面临的关键挑战。数据可能来自各种来源，包括数据库、API、文件系统和物联网设备。每个来源可能有其特定的数据格式、访问协议和更新频率。集成挑战不仅在于连接这些来源，还在于将它们不同特征的异构数据标准化为统一的管道，以便后续处理阶段可靠消费。

鉴于数据源的多样性，ML 工程师必须为每个数据源开发稳健的连接器或适配器，以有效集成这些来源。这些连接器处理数据提取的细节，包括身份验证、速率限制和错误处理。例如，在与 REST API 集成时，连接器将管理 API 密钥、遵循 API 文档或 HTTP 头中指定的速率限制，并正确处理 HTTP 状态码——在瞬时错误（500、503）时重试，在身份验证失败（401、403）时中止，在被限制（429）时退避。设计良好的连接器将这些细节抽象，向下游处理提供一致接口，无论数据来自 API、数据库还是文件系统。

除了基本连接性，源集成还涉及在摄取点进行数据转换。这可能包括将 JSON¹⁷或 XML 响应解析为结构化格式、将时间戳转换为标准时区和格式（通常为 UTC 和 ISO 8601），或系统化地执行基本数据清理操作，如修剪空格或标准化文本编码。目标是在数据进入 ML 管道时标准化数据格式，简化后续处理。这些转换不同于 ETL 或 ELT 中的业务逻辑转换——它们解决技术格式变异，而非内容语义转换。

除了数据格式标准化，确保数据源的可靠性和可用性也至关重要。一些数据源可能会出现停机或数据质量不一致的情况。实施带有指数退避的重试机制，可以优雅地处理瞬时故障。当数据源出现故障时，系统可以自动切换到备用数据源、提供缓存数据或降级服务，而不是完全失败。例如，当实时市场数据源失败时，系统可以切换到稍有延迟的备用数据源，同时向运维团队发出警报。死信队列捕获格式错误的数据，以便后续调查，而不是静默丢弃。电路断路器防止系统在市场数据提供商恢复期间不堪重负。这种全面的错误管理确保下游过程获得可靠、高质量的数据，用于训练和推理，即使在分布式系统不可避免的故障面前。

案例研究：为 KWS 选择摄取模式

将这些摄取概念应用于我们的 KWS 系统，生产实现同时展示了流式和批量模式的协同，反映了我们在问题定义阶段确立的双重操作模式。摄取架构直接实现了我们四大支柱框架的要求：通过音频特征验证质量，通过一致的操作确保可靠性，通过处理数百万音频流实现可扩展性，以及通过源认证和追踪维护治理。

流式摄取模式处理来自活动设备的实时音频数据，需在 200 毫秒的延迟要求内检测唤醒词。这需要精心实现的发布 - 订阅机制，使用 Apache Kafka 等系统缓冲到来的音频数据，并在多个推理服务器之间实现并行处理。流式路径优先考虑我们的可靠性和可扩展性支柱：在设备负载和网络条件变化时，保持一致的低延迟操作，同时处理来自部署设备的数百万条并发音频流。

与此实时处理并行，批量摄取则处理模型训练和更新所需的数据。这包括我们在获取阶段确立的多样数据源：来自众包的唤醒词新录音、合成数据填补的覆盖缺口、以及提供真实检测和误报示例的验证用户交互。批处理通常遵循 ETL 模式，音频数据经过预处理——归一化音量水平、极端噪声过滤和一致时长分割——后存储为优化的训练格式。这一处理符合我们的质量支柱，确保训练数据经过一致转换，保留区分唤醒词和背景语音的声学特征。

整合这些多样数据源对 KWS 系统提出了独特挑战。实时音频流需在使用高峰期实施速率限制，以防系统过载。众包数据则需系统化验证，以确保录音质量符合我们在问题定义阶段确立的规范：信噪比足够、说话距离适中、标注正确。合成数据则需验证其对唤醒词变体的真实代表性，避免生成声学上不合理的样本，误导模型训练。

语音交互系统所需的复杂错误处理机制，在实时音频处理时尤为明显。死信队列存储识别失败的尝试，以便后续分析，帮助识别在数据收集、处理或模型推理中可能出现的模式性错误。例如，处理唤醒词“Alexa”时，系统需验证多个音频质量指标：信噪比是否高于我们在要求定义中设定的最低阈值、采样率是否与训练数据规范一致、录音时长是否在预期的 1 到 2 秒内、说话人距离指标是否表明该语音是针对设备而非偶然说出。无效样本将被路由到死信队列以供分析，而不是直接丢弃。这些失败往往揭示了需要在下一个模型迭代中关注的边缘案例。有效样本则在实时处理和后续训练数据更新中同时被利用，展示了生产系统如何通过精心的数据工程持续改进。

这一摄取架构完成了外部数据进入受控管道的边界层。随着可靠摄取的建立——验证数据质量、优雅处理错误、应对大规模吞吐和维护治理控制——我们接下来将系统性数据处理，转化摄取的原始数据为适合机器学习的特征，同时保持训练 - 服务一致性，这对生产系统至关重要。

系统化数据处理

在建立可靠的数据摄取后，我们进入管道中技术挑战最大的阶段：系统化数据处理。这里，一个基本要求——在训练和服务中应用相同的转换——成为约 70% 生产 ML 故障的根源。这一惊人统计数据凸显了训练 - 服务一致性作为所有处理决策中心组织原则的重要性。

数据处理实现了我们在问题定义阶段设定的质量要求，将原始数据转化为适合机器学习的格式，同时保持可靠性和可扩展性标准。处理决策必须在提高模型准备度的同时，保持数据完整性，并在整个转换管道中遵循治理原则。每一个转换——从归一化参数到分类编码，再到特征工程逻辑——都必须在两个上下文中一致应用。考虑一个简单的例子：在训练中通过去除货币符号和转换为浮点数来归一化交易金额，但在服务中忘记应用相同的预处理。这种看似微不足道的不一致，可能导致模型准确率下降 20-40%，因为模型接收到的输入格式与训练时截然不同。正因如此，训练 - 服务一致性成为处理系统设计的核心组织原则。

对于我们的 KWS 系统，处理决策直接影响四大支柱，如我们在问题定义中所确立的那样。质量转换必须在保留声学特征的同时，消除不同录音条件带来的差异。可靠性要求在我们多源获取策略下，处理方式保持一致，尽管音频格式各异。可扩展性则要求高效算法，处理来自部署设备的数百万音频流。治理确保在处理过程中保护用户语音数据的隐私。

确保训练 - 服务一致性

我们从质量作为数据处理的基石开始。在这里，质量支柱体现为确保在训练期间应用的变换与在服务期间应用的变换完全一致。该一致性挑战不仅仅是运行相同的代码——还要求将训练数据上计算得到的参数（归一化常数、编码字典、词汇映射等）进行持久化并在服务时重用。缺乏这类纪律性会导致模型在服务时接收到与训练时本质不同的输入，从而引起性能下降，这类问题通常表现微妙且难以调试。

数据清洗包括识别并修正数据集中的错误、不一致和不准确之处。原始数据常包含缺失值、重复项或异常值等问题，如果不加处理会显著影响模型性能。关键在于：清洗操作必须是确定性且可重现的——对于相同输入，无论在训练还是服务中执行，清洗应产生相同输出。这一要求决定了哪些清洗技术可以安全地用于生产 ML 系统。

数据清洗可能包括基于确定性键删除重复记录、通过可一致应用的规则对缺失值进行插补或删除、以及系统性地修正格式不一致。例如在客户数据库中，姓名可能存在大小写或格式的不一致。数据清洗过程应对这些条目进行标准化，确保 “John Doe”、“john doe” 和 “DOE, John” 被视为同一实体。清洗规则——如转换为首字母大写、重排为“名 姓”格式——必须以在训练和服务中完全相同方式执行的代码形式捕获。如本章贯穿强调的，所有清洗操作在两种上下文中都必须一致应用，以维护系统可靠性。

异常值检测与处理是数据清洗的另一重要方面，但也带来一致性挑战。异常值有时代表罕见但有价值的事件，也可能来自测量错误或数据损坏。ML 从业者在决定如何处理异常值时必须谨慎权衡数据的性质与模型需求。简单的基于阈值的异常值移除（移除距离均值超过 3 个标准差的值）在训练 - 服务一致性方面是安全的，前提是均值和标准差在训练时计算并在服务时重用。然而，更复杂的异常检测方法（考虑特征间关系或时间模式）需要细致工程，以确保在两端一致应用。

质量评估与数据清洗并行进行，为评估数据的可靠性和可用性提供系统化方法。该过程涉及检查数据质量的多个方面，包括准确性、完整性、一致性与时效性。在生产系统中，数据质量会以基本指标难以捕获的微妙方式退化：先前从不含空值的字段开始出现稀疏模式，数值分布偏离训练范围，或者出现训练期间未见过的类别值。

为应对这些微妙退化模式，生产级质量监控需要超越简单的缺失值计数。关键指标包括按特征的空值模式（突增暗示上游故障）、计数异常（例如 10 倍增长常指数据重复或管道错误）、值域违规（价格变为负数、年龄超出合理上限）以及数据源间连接失败率。统计漂移检测¹⁸ 对于监控均值、方差和分位数随时间的变化至关重要，以便在影响模型性能之前捕捉渐进式退化。例如，在电商推荐系统中，用户会话平均时长可能因站点改版在半年内从 8 分钟稳步上升到 12 分钟，但若突然跌至 3 分钟，则可能是数据采集出错。

为支持这些监控需求，质量评估工具涵盖从简单统计度量到复杂的基于机器学习的方法。数据剖析工具提供汇总统计和可视化，帮助识别潜在质量问题；而高级方法采用无监督学习算法在大规模数据集中检测异常或不一致。建立明确的质量指标和阈值，确保进入 ML 管道的数据满足可靠训练与推理的最低标准。关键是将相同的质量标准和验证逻辑在训练与服务中保持一致，防止质量问题造成训练 - 服务偏差。

变换（Transformation）技术将数据从原始形式转换为更适合分析和建模的格式，操作范围从简单的单位转换到复杂的数学变换。常见变换任务包括归一化与标准化，用于将数值特征缩放到统一范围或分布。例如在房价预测模型中，面积和房间数尺度相差很大，归一化这些特征能让它们对模型预测的贡献更均衡。维持训练 - 服务一致性要求在训练数据上计算得到的归一化参数（均值、标准差）被持久化并在服务时相同应用。这通常意味着将这些参数与模型工件一并持久化——或存放在模型文件中，或保存在独立的参数文件里——并在服务初始化时加载。

除了数值缩放外，变换还可能包括对分类变量的编码、对日期与时间数据的处理，或创建派生特征。例如独热编码（one-hot encoding）常用于将分类变量转换为多数机器学习算法可理解的格式。分类编码必须同时处理训练期间出现的类别与服务期间遇到的未知类别。稳健做法是在训练时计算类别词表（即训练中观察到的所有类别），并将其与模型一起持久化；在服务时对未知类别映射为特殊的 “unknown” 标记或使用默认值。缺乏这种纪律性，服务端遇到训练时未见过的类别会导致错误或性能下降。

特征工程（Feature Engineering）是使用领域知识创建可提升模型效果的新特征。该步骤更偏向艺术而非纯科学，需要对数据和问题有深刻理解。特征工程可能涉及组合现有特征、从复杂数据类型中提取信息，或基于领域洞见创造全新的特征。例如在零售推荐系统中，工程师可能构建反映客户购买“近期性 - 频率 - 货币价值（RFM）”的特征。

特征工程的重要性不可低估。良好设计的特征往往能显著提升模型性能，有时其影响甚至超过算法选择或超参数调优。然而，特征工程的创造性必须与生产系统的一致性需求权衡。每一个工程化特征在训练与服务中都必须以相同方式计算。这意味着应将特征工程逻辑实现为可在训练与服务端共享的库或模块，而不是分别重写。许多组织为确保跨环境的一致性而构建特征存储（feature store）。

将这些处理概念应用于我们的 KWS（关键词识别）系统时，摄取管道中的音频录音——无论来自众包、合成生成还是真实捕获——都需要精细的清洗以保证唤醒词检测的可靠性。原始音频通常存在我们在问题定义中已预见的缺陷：从安静卧室到嘈杂工厂的背景噪声、录音电平导致的信号截断、不同麦克风和说话人产生的音量差异，以及来自多样采集设备的不一致采样率。清洗管道必须在标准化这些差异的同时，保留能区分唤醒词与背景语音的声学特征——这是直接影响我们达到 98% 精度目标的质量保持要求。

针对 KWS 的质量评估扩展了一般原则，采用音频特定的指标。除了检查空值或模式合规外，系统还跟踪背景噪声水平（信噪比需高于 20 dB）、音频清晰度评分（频谱分析）、以及说话速率一致性（唤醒词时长应在 500–800 毫秒范围内）。质量评估管道会自动标记那些背景噪声可能阻碍准确检测、唤醒词说得过快或不清晰导致模型无法区分，或存在截断/失真破坏音频信号的录音。自动化过滤确保仅高质量样本进入模型开发，避免图 3 中所示的“垃圾进，垃圾出”级联效应。

将音频数据转换为 KWS 可用形式涉及将原始波形转为适用于 ML 的表示，同时保持训练 - 服务一致性。如图 10 所示，变换管道将音频信号转换为标准化的特征表示——通常为梅尔频率倒谱系数（MFCCs）¹⁹ 或频谱图（spectrograms）²⁰——这些表示强调与语音相关的特征，减少不同录音条件间的噪声和可变性。

这些音频特征变换需在训练与服务间一致实现，并将变换参数（如窗长、步长、滤波器参数等）与模型一并记录与部署，以确保端到端一致性和可复现性。

通过分布式处理实现可扩展性

在质量和可靠性得到保障后，我们面临的下一个挑战是规模。当数据集不断增大、ML 系统日益复杂时，数据处理的可扩展性成为瓶颈。回顾我们讨论过的数据处理阶段——清洗、质量评估、转换和特征工程——当这些操作需要处理 TB 级数据时，单机方案已无法胜任。原本适用于 GB 级内存数据的清洗技术，必须重新设计以适应分布式系统。

这些挑战在以下场景中尤为突出：质量评估需比数据到达速度更快地处理数据，特征工程操作需在转换单条记录前先对整个数据集计算统计量，以及当转换管道在大规模下成为瓶颈时。处理流程必须从开发阶段（笔记本上的 GB 级数据）平滑扩展到生产阶段（集群上的 TB 级数据），同时保持行为一致。

为解决扩展瓶颈，数据必须在多台计算资源间分区，这就引入了协调难题。分布式协调的根本限制在于网络往返延迟：本地操作以微秒级完成，而网络协调需毫秒级，存在 1000 倍的延迟差。这也解释了为何需要全局协调的操作（如在 100 台机器上计算归一化统计量）会成为瓶颈。每个分区可快速计算本地统计量，但合并结果时则需所有分区的信息。

在这个规模下，数据本地性变得至关重要。通过网络传输 1TB 训练数据（10GB/s）需 100 多秒，而本地 SSD 读取（5GB/s）只需 200 秒，这推动 ML 系统架构向“计算靠近数据”演进。当处理节点以 RAM 速度（50-200GB/s）访问本地数据，但网络带宽仅有 1-10GB/s 时，带宽失配成为根本瓶颈。地理分布进一步加剧挑战：跨数据中心协调需应对 50-200ms 的网络延迟、部分故障以及数据跨境的合规限制。理解哪些操作易于并行、哪些需高昂协调，是决定系统架构和性能的关键。

如果精心设计，单机处理可胜任相当大的工作负载。现代服务器配备 256GB 内存，可通过外存处理（out-of-core）流式处理 TB 级数据。Dask、Vaex 等库提供类似 pandas 的 API，自动流式并行计算。团队在投资分布式基础设施前，应充分挖掘单机优化潜力：采用高效数据格式（如 Parquet²¹ 替代 CSV）、最小化内存分配、利用向量化操作和多核并行。单机处理的运维简单性——无需网络协调、无部分故障、调试简单——只要性能足够，优先选择。

当数据量或计算需求超出单机能力时，分布式处理框架成为必需，但并行加速的极限受 Amdahl 定律约束：

$$ \text{Speedup} \leq \frac{1}{S + \frac{P}{N}} $$

其中 $S$ 为不可并行的串行部分，$P$ 为可并行部分，$N$ 为处理器数量。这解释了为何 KWS 特征提取在 64 核下可获得近 64 倍加速（当 $S \approx 0$，即“尴尬并行”），但如全局归一化统计等需协调的操作，即使 64 核也只能获得 10 倍加速，因为串行聚合阶段成为瓶颈。理解这一关系，有助于架构决策：高串行比例的操作应在更少更快的核上运行，高并行度任务则应最大化分布式。

Apache Spark 提供了分布式计算框架，可自动在集群间并行转换、分区数据、调度任务并实现容错。Beam 提供统一 API，支持批处理和流处理，可在 Spark、Flink、Dataflow 等多种引擎上运行同一转换逻辑。TensorFlow 的 tf.data API 优化了 ML 训练的数据加载管道，支持分布式读取、预取和转换。选择哪种框架，取决于是批处理还是流处理、转换的并行性以及可用的执行环境。

另一个重要考量是预处理与实时计算的平衡。大量预处理可加速模型训练和推理，但也会带来存储需求增加和数据陈旧风险。生产系统常采用混合策略：对计算量大但变化慢的特征预处理，而对变化快的特征实时计算。具体平衡取决于存储成本、计算资源和新鲜度需求。计算代价高但变化慢（如用户人口统计、商品流行度）的特征适合预处理，变化快（如当前会话状态、实时库存）的特征则必须实时计算。

在我们的 KWS 系统中，可扩展性在多个阶段体现。开发阶段用单机处理样本数据，便于快速迭代。大规模训练时，数据集（2300 万样本）超出单机能力或需并行实验时，需分布式处理。音频文件间天然独立，转换无需协调，工人各自从分布式存储读取分配的音频，计算特征并写回，属于“尴尬并行”模式，可实现近线性扩展。生产部署则需在资源极度受限的边缘设备（如 16KB 内存）上实时处理，需精细优化和量化以适配设备能力。

数据转换溯源追踪

在数据处理的四大支柱中，治理确保问责和可复现性。治理支柱要求追踪每次转换的应用、执行时间、代码版本和参数。这一转换溯源是调试、合规（如法规要求可解释性）和发现转换 bug 后迭代改进的基础。没有全面溯源，团队无法复现训练数据、无法解释模型为何做出特定预测，也无法在修复处理 bug 后安全地重处理数据，避免不一致。

转换版本控制记录每个数据集由哪个处理代码版本生成。当转换逻辑变更（修 bug、加特征、提质）时，版本号递增。数据集打上生成时的转换版本标签，便于 bug 修复后定位需重处理的数据。这一版本控制不仅限于代码，还包括整个处理环境：库版本（不同 NumPy 版本可能导致数值差异）、运行配置（环境变量影响行为）、执行基础设施（CPU 架构影响浮点精度）。

参数追踪则记录转换时用到的具体值。归一化需存储训练数据上计算的均值和标准差，分类编码需存储词汇表（所有出现过的类别），特征工程需存储用到的常数、阈值等。这些参数通常与模型工件一起序列化，确保服务端与训练端一致。现代 ML 框架如 TensorFlow、PyTorch 提供了将预处理参数与模型捆绑的机制，简化部署并确保一致性。

处理溯源用于可复现性，追踪从原始数据到最终特征的完整转换历史，包括读取了哪些原始文件、应用了哪些转换、参数为何、何时处理。Apache Atlas、Amundsen 等溯源系统可自动捕获这一流程。模型预测出错时，工程师可沿溯源链追查：哪些训练数据导致该行为、数据质量如何、应用了哪些转换、能否复现场景以便调查。

代码版本将处理结果与生成它的确切代码关联。当处理代码托管于 Git 等版本控制时，每个数据集应记录生成它的 commit hash。这样可重现当时的处理环境：检出对应代码、安装依赖、用相同参数运行。Docker 等容器技术可将整个处理环境（代码、依赖、系统库）封装为不可变镜像，数月或数年后仍可复现结果。

在我们的 KWS 系统中，转换治理追踪对模型行为有关键影响的音频处理参数。例如，音频归一化到标准音量时，需持久化参考音量；FFT 转换到频域时，需记录窗口大小、步长和窗函数类型（Hamming、Hanning 等）；计算 MFCC 时，需记录系数数量、频率范围、Mel 滤波器参数。这些参数的全面追踪带来多项关键能力：调试模型失败时可精确复现训练数据，验证服务端与训练端预处理一致，系统性研究预处理选择对模型准确率的影响。没有治理基础设施，团队只能依赖手工文档，难免过时或出错，最终导致训练 - 服务偏差，损害生产性能。

端到端处理管道设计

将清洗、评估、转换和特征工程各环节整合，处理管道将各步骤组合为一致、可复现的工作流。管道确保训练和推理阶段数据一致准备，降低数据泄漏风险，提高 ML 系统可靠性。管道设计决定了处理逻辑的迭代难易、数据增长时的扩展能力，以及系统维持训练 - 服务一致性的可靠性。

现代 ML 框架和工具通常提供构建和管理数据处理管道的能力。例如，Apache Beam、TensorFlow Transform 允许开发者定义可在训练和服务期间一致应用的数据处理步骤。数据处理框架的选择需与更广泛的 ML 框架生态系统（见 第 7 章：AI 框架 ）匹配，框架特定的数据加载和预处理工具会显著影响开发效率和系统性能。

除了工具选择，有效的管道设计还需考虑模块化、可扩展性和版本控制。模块化管道便于单独更新和维护各处理步骤。每个转换阶段应实现为独立模块，输入输出清晰，便于独立测试和替换，不影响其他阶段。管道的版本控制至关重要，确保数据处理的变更可追踪，并能与模型性能变化关联。当模型准确率下降时，版本控制有助于定位是否处理变更所致。

TensorFlow Extended 在图 10 中很好地展示了管道组件的模块化分解，显示了从初始数据摄取到最终模型部署的完整流程。图中展示了数据如何流经验证、转换、特征工程等阶段，最终进入模型训练。每个管道组件都可独立版本化、测试和扩展，同时保持整体系统一致性。

在我们的 KWS 处理管道中，需同时支持训练的批处理和推理的实时处理，并确保两种模式间的一致性。管道设计保证训练数据上计算的归一化参数（如音量均值、频率响应曲线、时长统计）被存储，并在服务期间一致应用。这一架构决策体现了我们的可靠性支柱：用户期望无论设备生产时间或模型版本如何，唤醒词检测都能保持一致，这要求处理管道在训练迭代和部署环境间保持稳定行为。

高效的数据处理是 ML 系统成功的基石。通过以四大支柱为视角——训练 - 服务一致性保障质量、幂等转换保障可靠性、分布式处理保障可扩展性、全面溯源保障治理——精心清洗、转换和工程化数据，实践者可显著提升模型性能和系统可靠性。随着机器学习领域不断发展，数据处理的技术和工具也在持续演进，使其成为值得深入研究和实践的前沿领域。在系统化处理建立后，下一步我们将探讨数据标注，这一环节将人工判断引入自动化管道，同时在质量、可靠性、可扩展性和治理维度保持同样的系统性要求。

数据标注

在建立系统化数据处理后，数据标注成为更广泛数据工程领域内一个特别复杂的系统挑战。随着训练数据集规模达到数百万甚至数十亿条，支持标注操作的基础设施对系统性能的影响愈发关键。标注代表了人机协作的系统工程，其中我们的四大支柱指导基础设施决策，方式与自动化管道阶段截然不同。质量支柱体现在通过共识机制和金标准验证确保标签准确性。可靠性支柱要求平台架构能够协调数千个并发标注者，确保数据不丢失、不损坏。可扩展性支柱推动 AI 辅助标注，以增强人类判断力而非取而代之。治理支柱则要求对参与标注的人工贡献者提供公平补偿、减轻偏见并确保其获得伦理对待，因为他们的劳动创造了支持 ML 系统的训练数据。

现代机器学习系统必须高效处理跨整个数据管道的标签创建、存储和管理。系统架构必须支持各种标注工作流，同时保持数据一致性、确保质量并有效管理计算资源。当处理大规模数据集或实时标注需求时，这些要求会相互叠加。系统性挑战不仅在于存储和管理标签，生产 ML 系统还需要强大的管道，将标注工作流与数据摄取、预处理和训练组件集成，同时保持高吞吐量并适应不断变化的需求。

标签类型及其系统需求

要构建有效的标注系统，首先必须了解不同类型标签如何影响系统架构和资源需求。考虑一个实际示例：构建一个智能城市系统，需要从视频流中检测和跟踪各种物体，如车辆、行人和交通标志。标签用于捕捉关键任务或概念的信息，每种标签类型都有不同的存储、计算和验证需求。

分类标签是最简单的形式，通过特定标签（或多标签分类中的标签）对图像进行分类，例如将图像标记为“汽车”或“行人”。尽管概念上简单，但对于处理数百万视频帧的生产系统来说，必须高效存储和检索这些标签。存储需求适中——每个图像一个整数或字符串——但检索模式很重要：训练通常随机抽样子集，而验证则需要顺序访问所有标签，因此驱动不同的索引策略。

边界框超越了简单的分类，通过识别物体位置来标识感兴趣物体的边界框。我们的系统现在不仅需要跟踪物体的存在，还需要跟踪它们在每帧中的位置。这种空间信息引入了新的存储和处理挑战，特别是在跨视频帧跟踪移动物体时。每个边界框需要存储四个坐标（x，y，宽度，高度）外加物体类别，使得存储需求相比分类增加了 5 倍以上。更重要的是，边界框注释需要像素级的精确定位，耗时是分类的 10-20 倍，这对标注吞吐量和成本产生了重大影响。

分割图则通过逐像素分类物体，提供了最全面的信息，突出显示每个物体的不同颜色。例如，在我们的交通监控系统中，这可能意味着精确勾勒出每辆车、行人和路标。这些详细的注释显著增加了我们的存储和处理需求。对于 1920x1080 图像的分割掩码需要 200 万个标签（每个像素一个），而不是可能的 10 个边界框或单个分类标签。这种 100,000 倍的存储增加以及手动分割每幅图像所需的数小时，使得这种方法仅在需要像素级精度时才适用。

图 12 展示了这些常见标签类型及其日益复杂的特性。鉴于这些复杂性，标签格式的选择在很大程度上取决于我们的系统需求和资源限制。虽然简单的交通计数可能只需分类标签，但自动驾驶汽车则需要详细的分割图来做出精确的导航决策。领先的自动驾驶汽车公司通常维护混合系统，为同一数据存储多种标签类型，以便在不同应用间灵活使用。单个摄像头帧可能具有分类标签（场景类型：高速公路、城市、乡村）、边界框（用于障碍物检测的车辆和行人）和分割掩码（用于路径规划的路面），每种标签类型服务于不同的下游模型。

除了这些基本标签类型，生产系统还必须处理丰富的元数据，以维护数据质量和调试模型行为。Common Voice 数据集就在语音识别中体现了复杂的元数据管理：跟踪说话者人口统计信息以确保模型公平性、记录数据过滤的质量指标、验证标签可靠性的状态以及多语言支持的语言信息。如果我们的交通监控系统在雨天表现不佳，那么数据收集时的天气条件元数据将有助于识别和解决该问题。现代标注平台开发了复杂的元数据管理系统，能够高效地对这些元数据和主要标签进行索引和查询，使其能够在训练数据选择和后期分析中进行过滤。

这些元数据需求表明，标签类型选择如何影响整个系统设计。一个为简单分类标签构建的系统，将需要对处理管道进行重大修改，以高效处理分割图。基础设施必须针对所选标签格式优化存储系统，为训练期间的读取实现高效数据检索模式，保持质量控制管道以进行验证，并管理标签更新的版本控制。当标签被更正或细化时，系统必须跟踪哪些模型版本使用了哪些标签版本，以便在标签质量改进与模型性能提升之间建立关联。

实现标签准确性和共识

在标注领域，质量面临独特挑战。质量支柱在这里的重点是确保标签的准确性，尽管许多标注任务固有的主观性和模糊性。即使有明确的指导方针和细致的系统设计，仍然不可避免会有一部分标签不正确。挑战不在于完全消除标注错误（这是一项不可能的任务），而在于系统地测量和管理错误率，使其保持在不降低模型性能的范围内。

正如图 13 所示，标注失败源于两种不同的原因，需要不同的工程响应。一些错误源于数据质量问题，即底层数据确实模糊不清或损坏——就像模糊的青蛙图像，即使是专家注释者也无法确定物种。其他错误则需要深厚的领域专业知识，只有具备专业知识的专家才能确定正确标签，例如黑鹳的识别。这些不同的失败模式驱动了对注释者资格、任务路由和共识机制的架构决策。

鉴于这些根本的质量挑战，生产 ML 系统实施了多层次的质量控制。系统的质量检查通过对标注数据的随机抽样进行专家审查和统计方法，持续监控标注管道以标记潜在错误。基础设施必须高效处理这些检查，确保在数百万个示例中进行而不形成瓶颈。抽样策略通常验证 1-10% 的标签，以检测灵敏度与审查成本之间的平衡。风险较高的应用（如医疗诊断或自动驾驶汽车）可能对 100% 的标签进行多次独立审查，而较低风险的应用（如产品推荐）可能仅通过抽查验证 1%。

除了随机抽样方法外，对每个数据点收集多个标签（通常称为“共识标注”）有助于识别有争议或模糊的案例。专业标注公司为此过程开发了复杂的基础设施。例如， Labelbox 的共识工具跟踪注释者之间的一致性，并自动将有争议的案例路由给专家审查。 Scale AI 实施分级质量控制，由经验丰富的注释者验证新团队成员的工作。共识基础设施通常为每个示例收集 3-5 个标签，使用 Fleiss’ kappa 等指标计算注释者之间的协议，该指标测量超出偶然一致性的协议。协议度低（kappa 值低于 0.4）的示例将被路由到专家审查，而不是通过非专家的多数投票强制达成一致。

共识方法反映了可扩展系统的基本经济权衡。专家审查的成本是众包标注的 10-50 倍，但通过非专家的多数投票在模糊示例上强制达成一致会产生系统性偏见标签。通过仅将真正模糊的案例路由给专家（通常通过低注释者间协议率识别的 5-15% 示例），系统在成本和质量之间取得平衡。这种分层方法使得在保证质量标准的同时，能够以经济的方式处理数百万个示例。

尽管技术基础设施提供了质量控制的基础，但成功的标注系统还必须考虑人因。当与注释者合作时，组织需要健全的培训和指导系统。这包括良好的文档，清楚标注正确内容的示例，边缘案例的视觉演示及处理方法，定期反馈机制，向注释者展示其在金标准示例上的准确性，以及校准会议，让注释者讨论模糊案例以达成共识。对于复杂或特定领域的任务，系统可能实施分级访问，基于注释者在类似示例上的表现将具有挑战性的案例路由给具有适当专业知识的注释者。

质量监控会生成大量数据，必须高效处理和跟踪。组织通常监控注释者间协议率（跟踪多个注释者是否对同一示例达成一致）、标签置信度分数（注释者对其标签的确定程度）、每次注释花费的时间（过快可能表示粗心，过慢可能表示困惑）、错误模式和类型（系统性偏见或误解）、注释者表现指标（在金标准示例上的准确性）和偏见指标（某些注释者人口统计信息是否系统性地标注不同）。这些指标必须在数百万个示例中高效计算和更新，通常需要专用分析管道，近实时处理标注数据以在大规模数据影响之前发现质量问题。

构建可靠的标注平台

从标签质量转向系统可靠性，我们考察平台架构如何支持一致的操作。质量关注标签准确性，而可靠性确保平台架构本身在规模上稳定运行。从数百到数百万个示例的标注扩展，同时保持质量，需要理解生产标注系统如何在多个架构组件之间分离关注点。根本挑战在于，标注代表了人机协作的工作流，系统性能不仅依赖于基础设施，还依赖于对人类注意力、专业知识和一致性的管理。

基础是一个持久的任务队列，持久存储标注任务，确保在系统重启或注释者断开连接时不会丢失工作。大多数生产系统为此使用消息队列，如 Apache Kafka 或 RabbitMQ，而非数据库，因为消息队列提供了自然的排序、并行消费和重放能力，而数据库则不易支持。每个任务携带超出待标注数据的元数据：任务类型（分类、边界框、分割）、所需专业知识水平、紧急程度以及准确标注所需的任何上下文——可能是相关示例或相关文档。

将任务路由到注释者的分配服务实现了比简单的轮询分配更复杂的匹配逻辑。医学影像标注系统将胸部 X 光片专门路由给具有放射科专业知识的注释者，这通过他们与金标准示例的专家标签一致性来衡量。但仅仅匹配专业知识还不够——只查看胸部影像或仅关注特定病理的注释者可能会产生盲点，在熟悉的示例上表现良好，但在不太常见的案例上表现较差。因此，生产系统会限制分配，确保没有注释者的 30% 以上任务来自单一类别，从而保持广泛的接触面，防止过度专业化导致对不熟悉示例的质量下降。

当任务需要多个注释以确保质量时，共识引擎会确定何时收集到足够的标签以及如何汇总可能冲突的意见。简单的多数投票适用于大多数注释者自然达成一致的明确分类任务：识别图像中是否包含汽车，几乎不会产生分歧。但对于更主观的任务，如情感分析或识别细微的图像属性，注释者之间可能会产生合理的分歧。一种常见模式是为每个示例收集 3-5 个标签，计算注释者之间的协议（使用 Fleiss’ kappa，超出偶然的协议），将协议度低（通常 kappa 值低于 0.4）的示例路由给专家审查，而不是强制对真正模糊的案例达成一致。

这种分层方法反映了塑造平台架构的基本经济权衡。专家审查的成本是众包标注的 10-50 倍，但通过非专家的多数投票在模糊示例上强制达成一致会产生系统性偏见标签——偏向于更容易标注的模式，而这些模式可能并不反映对模型稳健性重要的复杂性。通过仅将真正模糊的案例路由给专家（通常通过低注释者间协议率识别的 5-15% 示例），系统在成本和质量之间取得平衡。平台必须高效实现这种路由逻辑，跟踪哪些示例需要专家审查，并确保它们被送到适当资格的注释者那里，而不会形成瓶颈。

保持大规模下的质量需要通过金标准注入进行持续测量。系统定期在任务流中插入已知正确标签的示例，而不透露哪些是金标准。这使得可以计算每个注释者的准确性，而不会出现霍桑效应（测量改变行为）——注释者无法在金标准示例上“更努力”，因为他们不知道哪些是金标准。持续低于 85% 准确率的注释者将获得额外的培训材料、更详细的指导，或在表现未改善时被移除。除了简单的准确性，系统还会从多个维度跟踪质量：对同一任务的同行注释者之间的协议（检测系统性分歧，表明对指导方针的误解）、每个任务的时间（过快可能表示粗心，过慢可能表示困惑）以及一致性（同一注释者在几天前看到的类似示例上是否可靠地应用标签）。

标注平台的可靠性构建

从标签质量转向系统可靠性，我们需要考察平台架构如何支持一致的操作。标签质量关注标签本身的准确性，而可靠性则确保标注平台在大规模下依然稳定运行。要将标注规模从几百扩展到数百万，同时保持高质量，必须理解生产级标注系统如何在多个架构组件间分离关注点。标注本质上是“人机协作”流程，系统性能不仅取决于技术基础设施，还依赖于对人类注意力、专业能力和一致性的管理。

平台的基础是持久化任务队列，确保即使系统重启或标注者断线，任务也不会丢失。生产系统通常采用消息队列（如 Apache Kafka、RabbitMQ），而不是数据库，因为消息队列天然支持排序、并行消费和重放，数据库则难以高效实现这些能力。每个任务不仅包含待标注数据，还携带元数据：任务类型（分类、边界框、分割）、所需专业水平、紧急程度，以及准确标注所需的上下文（如相关示例或文档）。

任务分配服务负责将任务智能分配给标注者，远比简单的轮询分配复杂。例如医学影像标注系统，会将胸片专门分配给在金标准样本上与专家标签高度一致的标注者。但仅靠专业匹配还不够——如果标注者只接触某一类别或某一病理，容易形成“盲区”，在熟悉样本上表现良好，但在不常见案例上表现较差。因此，生产系统会限制分配，确保任何标注者收到的单一类别任务不超过 30%，以保证广泛的样本覆盖，防止过度专业化导致质量下降。

当任务需要多重标注以确保质量时，共识引擎负责判断何时收集到足够标签，以及如何聚合可能冲突的意见。对于明确的分类任务，大多数标注者自然达成一致，简单的多数投票即可。但对于主观性强或细粒度属性的任务，标注者间可能出现合理分歧。常见做法是每个样本收集 3-5 个标签，计算标注者间一致性（如 Fleiss’ kappa），对于一致性低（如 kappa < 0.4）的样本，系统会自动路由给专家审核，而不是强行让非专家达成一致。

这种分层方法反映了平台架构的经济权衡。专家审核每例成本是众包标注的 10-50 倍，但强行让非专家在模糊样本上达成一致会产生系统性偏见，标签更倾向于易标注的模式，未能反映模型稳健性所需的复杂性。通过仅将真正模糊的样本（通常占 5-15%，通过低一致性自动识别）路由给专家，系统在成本和质量之间取得平衡。平台必须高效实现这种路由逻辑，跟踪哪些样本需专家审核，并确保及时分配给合格标注者，避免形成瓶颈。

大规模下保持质量需要持续的金标准注入。系统会定期在任务流中插入已知正确标签的样本，但不告知标注者哪些是金标准。这样可以计算每个标注者的准确率，而不会因“霍桑效应”导致行为改变——标注者无法在金标准样本上“刻意表现”。持续低于 85% 准确率的标注者会收到额外培训、详细指南，或在表现未改善时被移除。除了准确率，系统还会多维度跟踪质量：与同行标注者的一致性（检测对指导方针的误解）、每任务耗时（过快可能粗心，过慢可能困惑）、一致性（同一标注者对不同时间的类似样本是否稳定标注）。

这些系统在大规模下对性能要求极高。例如，每小时处理 1 万条标注的平台，既要满足低延迟分配，又要保证数据库写入能力。每条标注都立即写入 PostgreSQL 等持久数据库，约需每秒 2-3 次写入，数据库可承受。但任务分发——为 10 万并发标注者分配新任务——要求亚秒级响应，数据库难以支撑高并发请求。因此，生产系统采用两层存储架构：Redis 缓存活跃任务，实现 <100ms 分配延迟，标注结果则每 100 条批量写入 PostgreSQL（每 30-60 秒），既保证持久性又避免数据库小写入压力。

系统的横向扩展依赖于精细的数据分区。任务按 task_id 分片，任务队列可独立扩展；标注者绩效指标按 annotator_id 分片，分配决策可快速查找；聚合标签按 example_id 分片，模型训练时高效检索。这种分区策略使系统能日处理数百万任务，支持 10 万 + 并发标注者，任务分配中位延迟 <50ms，证明“人机协作”系统在合理架构下可与自动化流水线媲美。

除了架构设计，理解标注经济学也揭示了为何 AI 辅助扩展变得必不可少。数据标注是 ML 系统最大的隐性成本之一，但项目规划时往往只关注算力和训练费用，忽视了标注成本。团队会精细优化 GPU 利用率、计算每小时训练成本，但每例标注成本（按条计价）常常被忽略，实际往往远超算力开销。全面的经济模型显示，随着 ML 系统成熟、数据需求扩展到百万甚至十亿级，AI 辅助扩展不只是有益，而是经济上的必然选择——在后续 ML 运维章节（ 第 13 章：机器学习运维 ）会进一步分析生命周期成本的复合效应。

标注成本结构呈乘法模型，既包含直接标注成本，也包含质控和返工开销：

$$ \text{总成本} = N \times \text{单例标注成本} \times (1 + R_{\text{专家审核}}) \times (1 + R_{\text{返工}}) $$

其中 $N$ 为样本数，$\text{单例标注成本}$为每条标签基础费用，$R_{\text{专家审核}}$为需专家审核比例（通常 5-15%），$R_{\text{返工}}$为需返工比例（通常 10-30%）。例如，100 万条标签，每条 $0.10，10% 需专家审核（每条 $0.50），20% 需返工，总成本达 $138,000，而不是简单计算的 $100,000。相比之下，训练同样数据的 ResNet-50 算力成本仅 $50——标注成本高出近 3000 倍，说明标注经济学主导系统总成本，却在规划阶段常被低估。

每条标签成本随任务复杂度和专业要求差异巨大。简单图片分类众包仅需 $0.01-0.05/条，专家审核则升至 $0.50-2.00。边界框标注简单场景 $0.05-0.20/框，复杂密集场景 $1.00-5.00。语义分割每图像 $5-50，医学影像专家标注每例 $50-200。计算机视觉系统如需千万级标签，单价从 $0.02 到 $0.05 的差异即带来 $300,000 的项目成本，往往超过全部基础设施预算，却常在标注启动后才被发现。

随着标注需求随着现代 ML 系统呈指数级增长，可扩展性变得至关重要。可扩展性支柱推动 AI 辅助标注作为增强人类标注的倍增器，而非替代者。仅靠人工标注无法跟上现代 ML 系统的数据需求，而完全自动化的标注又缺乏人类提供的细致判断。AI 辅助标注找到了二者之间的平衡点：利用自动化处理明确案例，加速标注，同时保留人类对模糊或高风险决策的判断。正如图 13 所示，AI 辅助提供了几条扩展标注操作的路径，每条路径都需要仔细设计系统，以平衡速度、质量和资源使用。

现代 AI 辅助标注通常结合多种方法协同工作。预标注是指利用 AI 模型为数据集生成初步标签，随后由人工审核和修正。主要标注平台在这项技术上进行了大量投资。 Snorkel AI 通过基于规则的启发式和弱监督信号，使用程序化标注自动生成初始标签。Scale AI 在特定领域（如自动驾驶）部署预训练模型，加速标注，人工则对车辆和行人等进行验证和修正。像 SuperAnnotate 这样的公司提供自动化预标注工具，可将计算机视觉任务的人工工作量减少 50-80%。这种通常采用半监督学习技术的方法，能够节省大量时间，尤其是对于极大数据集。

大型语言模型（LLM）的出现，如 ChatGPT，进一步改变了标注管道。LLM 除了可以进行简单分类外，还可以生成丰富的文本描述、根据示例创建标注指南，甚至解释其标签分配的推理。例如，内容审核系统使用 LLM 执行初步内容分类，并生成对政策违规行为的解释，供人工审核员验证。然而，集成 LLM 也带来了新的系统挑战，如推理成本（API 调用可能每个示例 $0.01-$1）、速率限制（云 API 通常限制在每分钟 100-10,000 个请求）和输出验证（LLM 偶尔会生成自信但错误的标签，需要系统验证）。许多组织采用分层方法：对例行案例使用较小的专用模型，对需要细致判断或稀有领域专业知识的复杂场景使用较大 LLM。

主动学习等方法通过智能优先标注哪些示例需要人工关注来补充这些方法。这些系统持续分析模型不确定性，以识别有价值的标注候选。与随机标注未标注数据的样本相比，主动学习选择当前模型最不确定的示例或标签将最能提高模型性能的示例。因此，基础设施必须高效计算不确定性指标（通常是预测熵或集成模型之间的分歧）、维护按信息量排序的任务队列，并根据传入标签调整优先级策略。考虑一个医学影像系统：主动学习可能会识别出不寻常的病理进行专家审查，而通过预标注让专家仅需验证的常规案例则由系统处理。这种方法与随机抽样相比，可以减少 50-90% 的标注需求，但需要仔细工程设计，以防止反馈循环，即模型的不确定性偏向于标注哪些数据。

随着这些 AI 组件的相互作用，质量控制变得愈发重要。系统必须通过系统的指标监控 AI 和人工的表现。模型置信度校准很重要：如果 AI 说它有 95% 的信心，但实际上在该置信水平下的准确率只有 75%，那么预注释可能会误导人工审核。人机一致性率揭示了 AI 辅助是帮助还是阻碍：当人工经常覆盖 AI 建议时，预注释可能引入偏见，而不是加速工作。这些指标需要在整个标注管道中仔细仪表化，跟踪不仅仅是最终标签，而是人类和 AI 在每个阶段之间的交互。

在自动驾驶汽车等安全关键领域，这些系统在处理大量传感器数据流时，必须保持特别严格的标准。Waymo 的标注基础设施据报道每天处理数百万个传感器帧，使用 AI 预标注来标记常见物体（车辆、行人、交通标志），同时将不寻常的场景（施工区域、紧急车辆、异常道路条件）路由给人工专家。尽管如此大规模，系统仍需保持实时性能，采用分布式架构，预标注在 GPU 集群上运行，而人工审核则横向扩展到数千名注释者，负载均衡确保任一组件都不会成为瓶颈。

确保伦理和公平的标注

与之前各节将治理重点放在数据和流程上不同，标注治理则集中于人类福祉。此处的治理支柱解决人工贡献者的伦理对待、偏见减轻和公平补偿——这些挑战与自动化管道阶段的治理截然不同，因为人类福祉直接相关。处理自动驾驶数据的公司往往在数据标注上外包给低收入国家，利用成本差异进行大规模标注，但这也带来了伦理和治理挑战。

例如，OpenAI 在开发 ChatGPT 时，将数据标注任务外包给肯尼亚工人，涉及对模型可能生成的有害或不当材料进行内容审核和标注。这些工人被要求审查和标注令人不安的内容，如血腥暴力和露骨材料，以训练 AI 识别和避免此类输出。尽管这种方法提高了 ChatGPT 的安全性和实用性，但也引发了对工作条件、任务性质和薪酬的重大伦理担忧。

许多贡献者的时薪低至 $1.32，需审查和标注高度创伤性的材料。这种工作的心理负担，加之低工资，令其公平性和透明性受到质疑。此事件突显了众包伦理实践中的关键缺口。工人，尤其是来自经济弱势地区的工人，未能获得足够的支持以应对任务的心理影响。缺乏心理健康资源和不充分的补偿，加上将数据标注任务外包给低收入地区时可能出现的权力失衡，均需引起重视。

不幸的是，ChatGPT 肯尼亚事件中暴露的问题并非 OpenAI 所独有。许多依赖众包进行数据标注的组织面临类似问题。随着机器学习系统变得愈加复杂，且对标注数据集的需求激增，业界亟需建立标准和最佳实践，以确保数据标注的伦理性。公平补偿应至少达到当地最低工资标准，理想情况下应与工人所在地区的同类工作薪酬相当——不仅仅是法律规定的最低标准，而是对需要持续注意力的熟练工作的公平报酬。对于敏感内容审核，这通常意味着反映心理负担的额外薪酬，可能是基础工资的 2-3 倍。

工人福祉要求为处理敏感内容的工人提供心理健康资源。像 Scale AI 这样的组织实施了结构化支持，包括：限制接触创伤性内容（通过不同内容类型轮换注释者、限制每天处理令人不安材料的小时数）、提供免费心理咨询服务的渠道，以及在注释者遇到特别令人不安的内容时提供即时支持。这些措施虽然增加了运营成本，但对确保伦理操作至关重要。透明度要求清晰沟通任务目的、贡献将如何使用、工人可能遇到何种内容以及工人权利，包括跳过可能引起心理不适的任务。

除了工作条件，数据标注中的偏见也是一个关键治理问题。注释者在标注过程中会带入自身的文化、个人和职业偏见，这可能反映在数据集中。例如，@wang2019balanced 发现，主要由某一地理区域的注释者标注的图像数据集，在物体识别任务上表现出偏见，在其他区域的图像上表现不佳。这凸显了注释者池的多样性需求，注释者的群体特征多样性有助于抵消个体偏见，尽管无法消除。定期进行偏见审计，检查标签分布是否在注释者人口统计信息之间系统性地不同，监控是否存在系统性偏见的模式（某些区域的所有图像质量评分较低），并通过额外培训或指导方针的细化来解决识别出的偏见，确保标签支持公平的模型行为。

数据标注还面临数据隐私和伦理方面的挑战。领先的数据标注公司为应对这些挑战开发了专门的解决方案。例如，Scale AI 维护专门的团队和安全基础设施，以处理医疗和金融等敏感数据，提供符合 HIPAA 标准的标注平台和严格的数据访问控制。Appen 实施严格的数据访问控制和匿名化协议，确保注释者在不必要时无法看到个人身份信息。Labelbox 为具有严格安全要求的组织提供私有云部署，支持在组织边界内进行标注而无需数据外泄。这些保护隐私的技术与我们在未来章节中探讨的安全性考虑直接相关²²，后者将建立在此处的数据治理基础上，解决 ML 生命周期中敏感数据的全面保护策略。

除了隐私和工作条件，实时数据的动态特性也是数据标注治理的另一个限制。标注时准确的标签，可能会随着数据底层分布的变化而变得过时或无效。这一概念被称为概念漂移（concept drift），因此需要持续的标注工作和对现有标签的定期重新评估。治理框架必须考虑标签版本控制（跟踪标签何时由谁创建）、重新标注策略（当概念演变时系统地重新标注数据）和退休策略（识别何时应弃用旧标签而不是用于训练）。

最后，当前标注方法的局限性在处理边缘案例或稀有事件时变得明显。在许多实际应用中，通常是那些不寻常或稀有的实例最为关键（例如，医疗诊断中的罕见疾病，或自动驾驶中的不寻常道路条件）。然而，这些案例在大多数数据集中是欠代表的，可能在大规模标注工作中被忽视或错误标注。治理要求对稀有事件采取明确策略：针对代表性不足场景的定向收集活动、稀有案例的专家审查要求，以及系统跟踪以确保尽管频率较低但仍获得适当关注的稀有事件。

这一案例强调了考虑 AI 系统背后人力劳动的重要性。尽管众包提供了可扩展性和多样性，但也带来了无法忽视的伦理责任。在构建驱动 AI 创新的数据集时，组织必须优先考虑贡献者的福祉和公平对待。标注中的治理，归根结底是承认训练数据不仅仅是比特和字节，而是值得尊重、获得公平补偿和伦理对待的人类劳动的产物。

案例研究：KWS 系统中的自动化标注

在 KWS 案例研究中，数据标注阶段——在系统化问题定义、多样化数据收集策略（涵盖质量和覆盖率要求）、摄取模式（处理批量和流式工作负载）以及处理管道（确保训练 - 服务一致性）等环节建立后——我们现在面临一个独特的挑战：如何在不成比例增加人工标注成本的情况下，生成数百万条带标签的唤醒词样本。多语言口语词库（MSWC）展示了自动化标注如何通过其创新的方法来应对这一挑战，该数据集包含来自 50 种不同语言的 340,000 个关键词的 23.4 百万条一秒钟语音示例。

这种规模直接反映了我们框架支柱的实际应用。实现我们在不同环境中 98% 准确率的质量目标，需要数百万个训练示例，以涵盖我们在问题定义中识别的声学变化。可靠性要求在不同声学条件下的代表性——不同的背景噪音、说话风格和录音环境。可扩展性则要求实现自动化，因为 2340 万个示例即使以每个标签 10 秒的速度标注，也需要约 2600 人年的努力，单靠人工标注在经济上不可行。治理要求透明的数据来源和语言多样性，确保语音激活技术服务于多语言的说话人，而不仅仅是最具商业价值市场的集中。

如图 15 所示，这一自动化系统始于配对的语音录音和相应的转录，这些数据来自 Common Voice 或多语言字幕内容平台。系统通过强制对齐²³ 处理这些输入——这是一种计算技术，通过同时分析音频和转录文本，识别连续语音中的精确单词边界。

在这些精确的时间标记基础上，提取系统生成干净的关键词样本，同时处理我们在问题定义中预见的工程挑战：背景噪声干扰单词边界、说话者意外拉伸或压缩单词超出目标时长 500-800 毫秒、以及较长单词超出一秒钟边界。MSWC 提供自动化质量评估，分析音频特征以识别录音质量、语音清晰度或背景噪声等潜在问题——在无需人工审核的情况下，维护 2300 万个样本的一致标准至关重要。

现代语音助手开发者通常在此自动化标注基础上进行构建。尽管自动化语料库可能不包含产品所需的特定唤醒词，但它们为 KWS 原型开发提供了起点，特别是在商业数据集不存在的欠服务语言中。生产系统通常会针对具有挑战性的案例（如不寻常的口音、稀有单词或困难的声学环境）叠加定向人工录制和验证，这需要在自动处理和人工专业知识之间优雅协调的基础设施。这展示了四大支柱的整合：通过定向人工验证确保质量，通过自动化一致性确保可靠性，通过强制对齐实现可扩展性，以及通过透明的数据来源和多语言覆盖实现治理。

强制对齐、提取和质量控制的精密协调，展示了深思熟虑的数据工程如何直接影响生产机器学习系统。当语音助手响应其唤醒词时，它依赖于这一标注基础设施，以及我们在本章中审视的收集策略、管道架构和处理转换。存储架构，接下来我们将讨论的内容，完成了这一图景，决定了这些经过精心标注的数据集如何在整个 ML 生命周期中组织、访问和维护，从而实现高效的训练迭代和可靠的规模服务。

战略性存储架构

在建立系统化处理管道，将原始数据转化为适合机器学习的格式后，我们必须设计存储架构，以支持整个 ML 生命周期，同时维持我们的四大支柱框架。存储决策决定了我们如何有效维护数据质量、确保在不同负载下的可靠访问、扩展以处理不断增长的数据量以及实施治理控制的复杂权衡，这些权衡从根本上塑造了 ML 系统的操作方式。

机器学习的存储需求与传统应用程序的事务性系统截然不同。ML 工作负载优先考虑高吞吐量的顺序读取、频繁写入和行级更新的低需求，以及对模式灵活性而非严格结构的需求。为电子商务或银行系统提供服务的数据库在每秒执行数百万次单独的产品查找时表现良好，但需要反复扫描整个产品目录的 ML 训练作业则需要完全不同的存储优化。一个为在线特征服务而优化的数据库，在需要对大规模数据集进行复杂查询时，往往会因为性能下降而无法满足需求。

本节将探讨如何将存储架构与 ML 工作负载特征相匹配，比较数据库、数据仓库和数据湖，然后探讨用于特征存储的专用 ML 基础设施，以及存储需求如何在 ML 生命周期中演变。

ML 存储系统架构选项

存储系统的选择是一个关键的架构决策，影响从开发到生产操作的 ML 生命周期的方方面面。数据库、数据仓库和数据湖之间的选择不仅决定了数据存放的位置，还决定了团队在开发过程中迭代的速度、模型访问训练数据的方式以及服务系统在生产中检索特征的方式。理解这些权衡需要检查基本存储特性和不同 ML 任务的特定访问模式。

关键的见解是，不同的 ML 工作负载根据其访问模式和延迟需求，具有根本不同的存储需求：

• 数据库（OLTP）：在需要低延迟、随机访问单个记录的在线特征服务中表现出色。实时推送个性化推荐时，需要毫秒级查找特定用户特征（年龄、位置、偏好）的用户档案。

• 数据仓库（OLAP）：针对结构化数据的模型训练进行了优化，在大型、干净的表上需要高吞吐量、顺序扫描。训练处理数百万交易及其数百个特征的欺诈检测模型，受益于只读取相关特征的列式存储。

• 数据湖：处理探索性数据分析和非结构化数据（图像、音频、文本）的训练，灵活性和低成本存储大规模数据至关重要。计算机视觉系统需要将 TB 级原始图像与元数据、注释和中间处理结果一起存储，只有数据湖才能提供所需的模式灵活性和成本效益。

数据库在操作和事务性目的上表现出色，维护产品目录、用户档案或交易历史，提供强一致性保证和低延迟点查找。对于 ML 工作流，数据库在以下特定角色中表现良好：存储经常变化的特征元数据、管理实验跟踪（事务一致性很重要）或维护需要原子更新的模型注册表。处理结构化用户属性（如 user_id、age、country、preferences）的 PostgreSQL 数据库，为需要实时获取单个用户特征的服务系统提供毫秒级查找。然而，当 ML 训练需要在多个周期中反复扫描数百万条记录时，数据库就显得力不从心了。优化事务性查找的行式存储，在训练需要从每条记录中提取 20 列而不是 100 列时变得低效。

数据仓库填补了这一分析空白，针对跨集成数据集的复杂查询进行了优化，这些数据集被转换为标准化模式。现代仓库如 Google BigQuery、Amazon Redshift 和 Snowflake 使用列式存储格式，使得在训练时可以高效读取特定特征，而无需加载整个记录——当表包含数百列但训练只需其中一部分时，这一点尤为重要。这种列式组织在典型 ML 工作负载中提供了 5-10 倍的 I/O 减少。例如，对于一个具有 100 列的欺诈检测数据集，模型通常只使用 20 个特征——列式存储只读取所需列，未压缩的 I/O 减少达到 80%。许多成功的 ML 系统从数据仓库提取训练数据，因为结构化环境简化了探索性分析和迭代开发。数据分析师可以快速计算汇总统计信息、识别特征之间的相关性并使用熟悉的 SQL 接口验证数据质量。

然而，数据仓库假设模式相对稳定，对于真正的非结构化数据（图像、音频、自由格式文本）或在实验性 ML 管道中常见的快速演变格式处理起来比较吃力。当计算机视觉团队希望将原始图像与提取的特征、来自不同标注供应商的多种注释格式、中间模型预测和嵌入向量存储在一起时，强制将所有这些内容放入严格的仓库模式中，会造成更多的摩擦而非价值。模式演变变得困难：向大型数据集添加新特征类型需要 ALTER TABLE 操作，这可能需要数小时，阻塞其他操作并减缓迭代速度。

数据湖则解决了这些局限性，原生存储结构化、半结构化和非结构化数据，在读取时再推迟模式定义——这种模式被称为读取时模式（schema-on-read）。这种灵活性在 ML 开发早期阶段尤其有价值，此时团队需要尝试各种数据源，尚不确定哪些特征会证明有用。一个推荐系统可能在同一个数据湖中存储：以 JSON 格式记录的事务日志、JPEG 格式的产品图像、文本文件格式的用户评论、以 Parquet 格式存储的点击流数据，以及 NumPy 数组格式的模型嵌入。与其将这些异构类型强制放入一个共同的模式中，不如将它们保留为原生格式。应用程序仅在读取时施加模式，使得不同的消费者可以根据各自的分析需求以不同的方式解释相同的数据——一个团队从事务日志中提取购买金额，而另一个团队分析时间模式。

这种灵活性带来了重大的治理挑战。如果没有严格的元数据管理和目录服务，数据湖将退化为“数据沼泽”——数据无序存放，相关数据变得几乎无法找到，从而破坏了最初采用数据湖的生产力优势。一个数据湖可能包含数千个数据集，分布在数百个目录中，名称如“userdata_v2_final”和“userdata_v2_final_ACTUALLY_FINAL”，只有最初的作者（他们已经离开公司）才明白它们之间的区别。成功的数据湖实施依赖于可搜索的元数据，关于数据血缘、质量指标、更新频率、所有权和访问模式的详细信息——实质上是提供了类似仓库的可发现性，覆盖湖泊规模的数据。像 AWS Glue Data Catalog、Apache Atlas 或 Databricks Unity Catalog 这样的工具提供了这一元数据层，使团队能够在投入处理工作之前发现和理解数据。

表 3 总结了这些存储系统类型的基本权衡：

选择合适的存储需要系统评估工作负载需求，而不是跟随技术趋势。当数据量保持在一个 TB 以下时，查询模式涉及频繁更新和复杂联接，延迟要求需要在 10 毫秒以内，强一致性是强制性要求时，数据库是最佳选择。为实时推荐服务的用户档案存储就是这种模式的典型例子：以千字节为单位的小型每用户记录，偏好更新时频繁读写，确保用户能够立即看到自己的更新，延迟要求低于 10 毫秒。当分析查询需要跨大数据集进行时，数据库就显得力不从心了，尤其是当查询复杂性增加时——需要跨总计数 GB 而非 MB 的表进行聚合或联接，或者当分析工作负载开始影响事务系统性能时，通常会迁移到数据仓库。

数据仓库在数据量从一个 TB 扩展到 100 TB 之间表现出色，分析查询模式主导事务操作，批处理延迟在分钟到小时之间可接受，且主要工作负载为结构化数据和相对稳定的模式。当查询复杂性增加时——需要跨总计数 GB 而非 MB 的表进行聚合或联接——或者当分析工作负载开始影响事务系统性能时，通常会迁移到数据仓库。数据仓库在处理实时流式数据时显得不足，后者的延迟要求以秒为单位，或者当非结构化数据超过 20% 的工作负载时，由于仓库模式的刚性，会对异构数据造成过大的摩擦。

当数据量超过 100 TB 时，数据湖变得必不可少，模式灵活性对于数据源或实验性特征的快速演变至关重要，成本优化至关重要（在规模上通常比数据仓库便宜 10 倍），且多样的数据类型必须共存。大规模模型训练，特别是对于结合文本、图像、音频和结构化特征的多模态系统，需要数据湖的灵活性。考虑一个自动驾驶汽车系统：存储来自测试车辆的 TB 级别的摄像头图像和激光雷达点云、时间序列格式的车辆遥测数据、手动标注的物体和行为注释、用于稀有场景的自动生成的合成数据，以及用于与真实情况比较的模型预测。强制将这些多样化的内容放入仓库模式中，将需要大量的转换工作，并丢弃原生格式所保留的细微差别。然而，数据湖需要复杂的目录管理和元数据治理，以防止质量下降——这一区别对于数据湖和数据沼泽之间的生产力差异至关重要。

表 4 概述了不同存储层的成本 - 性能权衡：

正如表 4 所示，这些指标揭示了为何 ML 系统采用分层存储架构。考虑存储我们 KWS 训练数据集（736 GB）的经济性：对象存储每月费用为 $15-18，便于长期保留原始音频，而将工作数据保存在 NVMe 上以便于活动训练，每月费用为 $74-220，但提供 50 倍更快的数据加载速度。性能差异直接影响迭代速度——以 5 GB/s 加载数据的训练，在 7360 秒内完成数据集加载，而以典型对象存储速度加载则需 7,360 秒，二者相差 50 倍，这决定了团队是能够每天多次迭代实验，还是必须等待数小时才能进行实验。

除了我们已经检查的基本存储能力外，ML 工作负载还引入了传统数据库和仓库无法处理的独特要求。理解这些特定于 ML 的需求及其性能影响，塑造了基础设施决策，这些决策贯穿整个开发生命周期，从实验性笔记本到处理数百万请求的生产服务系统。

现代 ML 模型包含数百万到数十亿的参数，需要高效的存储和检索模式，这与传统数据截然不同。GPT-3 的模型权重存储大约需要 700GB，采用 32 位浮点数——这比许多组织的整个操作数据库还要大。这个轨迹显示了加速的规模：从 2012 年的 AlexNet 的 6000 万个参数到 2020 年的 GPT-3 的 1750 亿个参数，模型大小在八年内增长了约 2900 倍。存储系统必须高效处理这些密集的数值数组，以满足容量和访问速度的要求。在分布式训练期间，当多个工作节点需要协调访问模型检查点时，存储带宽变得至关重要。与典型文件顺序组织不同，模型权重受益于块对齐存储，使得跨参数组的并行读取成为可能。当 64 个 GPU 同时从共享存储读取不同的参数分片时，存储系统必须提供接近网络接口限制的总带宽——通常为 25 千兆比特每秒或更高——而不会引入同步瓶颈，导致昂贵的计算资源空转。

ML 开发的迭代特性引入了与传统软件截然不同的版本控制要求。虽然 Git 在跟踪代码更改（文本文件，增量修改）方面表现出色，但在大型二进制文件（即使是小的模型更改也会导致全新检查点）方面却无能为力。对 10 个 10GB 模型版本的天真存储将消耗 100GB，但大多数 ML 版本控制系统仅存储版本之间的增量，按模型实际更改的比例减少存储。像 DVC（数据版本控制）和 MLflow 这样的工具维护对模型工件的指针，而不是存储副本，从而实现高效版本控制，同时保留重现任何历史模型的能力。一个典型的 ML 项目在超参数调整过程中会生成数百个模型版本——每次训练运行一个版本，因为工程师探索学习率、批量大小、架构和正则化策略。没有系统地捕获训练配置、准确性指标、训练数据版本与模型权重的对应关系，结果无法重现，尤其是当昨天的模型表现优于今天的模型时，团队无法确定是哪个配置导致了结果。这个可重现性挑战与数据治理中审查的治理要求直接相关，后者规定合规性通常要求证明特定模型预测是由哪些数据和过程产生的。

分布式训练生成大量中间数据，要求存储系统在大规模上处理并发读/写操作。当在 64 个 GPU 上训练 ResNet-50 时，每个处理单元处理其数据部分，要求存储系统在同步期间每几秒处理 64 次约 100MB 的中间结果写入。通过牺牲计算来优化内存的策略减少了内存需求，但增加了存储 I/O，因为中间值写入磁盘。存储系统必须提供低延迟访问，以支持高效同步——如果工作节点在等待存储时花费的时间超过执行计算的时间，则分布式处理将适得其反。同步模式因并行策略而异：某些方法需要从所有工作节点收集结果，其他方法则需要工作节点之间的顺序通信，混合策略则结合了这两种模式，并具有复杂的数据依赖性。

带宽层次结构从根本上限制了 ML 系统设计，造成了无法通过任何计算优化克服的瓶颈。尽管现代服务器提供 50 到 200 GB/s 的 RAM 带宽，但网络存储系统通常仅提供 1 到 10 GB/s，甚至高端 NVMe SSD 的顺序吞吐量也仅为 1 到 7 GB/s。当 GPU 可以比存储更快地处理数据时，昂贵的加速器在等待数据时可能会空转。以 ResNet-50 训练为例，模型包含 2500 万个参数，总计 100MB，处理 32 张图像的批量需 5MB 的输入数据，每次前向传播执行 40 亿次操作。每次操作移动 26 字节——与传统计算工作负载相比，异常高，后者通常低于 1 字节/操作。当 GPU 理论上可以以每秒 10 GB 的速度处理计算时，存储却只能以每秒 1 GB 的速度提供数据，这 10 倍的带宽失配成为限制训练吞吐量的主要瓶颈。无论是通过更快的矩阵乘法内核、改进的内存访问模式还是更好的并行化，GPU 优化都无法克服这一根本的 I/O 限制。

理解这些定量关系，有助于做出明智的存储系统选择和数据管道优化的架构决策，这在分布式训练期间变得尤为重要，如 第 8 章：AI 训练 中所述。训练吞吐量方程揭示了关键的依赖关系：

$$ \text{Training Throughput} = \min(\text{Compute Capacity}, \text{Data Supply Rate}) $$

$$ \text{Data Supply Rate} = \text{Storage Bandwidth} \times (1 - \text{Overhead}) $$

当存储带宽成为限制因素时，团队必须通过更快的介质、并行化或缓存来提高存储性能，或通过压缩、量化或架构更改来减少数据移动需求。大语言模型的训练可能需要每小时处理数百 GB 的文本，而计算机视觉模型在大规模分布式集群上处理高分辨率图像时，可能需要超过 50 GB/s 的持续数据传输速率。这些要求解释了专门的 ML 存储系统的兴起，这些系统优化了数据加载管道：PyTorch DataLoader 通过多个工作进程并行化 I/O，TensorFlow tf.data API 通过预取和缓存进行优化，以及像 NVIDIA DALI（数据加载库）这样的框架，将数据增强卸载到 GPU 上，而不是从存储中加载预先增强的数据。

文件格式选择通过影响 I/O 量和解压缩开销，显著影响吞吐量和延迟。与基于行的格式（如 CSV 或 JSON）相比，列式存储格式（如 Parquet 或 ORC）对典型 ML 工作负载提供 5-10 倍的 I/O 减少。减少的原因有二：只读取所需列而非整个记录，以及列级压缩利用列内值模式。考虑一个具有 100 列的欺诈检测数据集，模型通常只使用 20 个特征——列式格式只读取所需列，未压缩的 I/O 减少达到 80%。对于具有有限基数的分类特征，列压缩尤其有效：一个具有 200 个唯一值的国家代码列，在 1 亿条记录中通过字典编码压缩 20 到 50 倍，而通过游程编码压缩排序列（仅存储值变化）也能获得显著压缩。两者结合可实现高达 20 到 100 倍的总 I/O 减少，直接转化为更快的训练迭代和更低的基础设施成本。

压缩算法选择涉及压缩比和解压缩速度之间的权衡。虽然 gzip 实现了 6 到 8 倍的更高压缩比，但 Snappy 仅实现了 2 到 3 倍的压缩，但以每秒 500 MB 的速度解压缩——大约是 gzip 每秒 120 MB 的速度的 3 到 4 倍。对于训练而言，速度优势往往超过了空间节省。以 gzip 压缩的 100 GB 数据集训练需 17 分钟的解压缩时间，而 Snappy 仅需 5 分钟。当训练在 50 个周期中反复处理数据时，这种每个周期 12 分钟的差异累计起来就是 10 小时——这可能是实验是在一夜之间完成还是需要等待多天才能得到结果的关键所在。选择的影响贯穿整个系统：更快的解压缩使得更高的批量大小成为可能（在解压缩后内存中容纳更多示例）、减少了缓冲需求（减少了需暂存的解压缩数据量）和更好的 GPU 利用率（等待数据时空闲时间更少）。

存储性能优化不仅限于格式和压缩，还包括数据布局策略。基于常用查询参数进行数据分区，显著提高检索效率。处理用户交互的推荐系统可能按日期和用户人口统计属性对数据进行分区，从而在训练最近的数据子集或特定用户群体时，无需扫描整个数据集。分区策略与分布式训练模式相互作用：范围分区按用户 ID 实现数据并行训练，每个工作节点处理一致的用户子集，而随机分区则确保工作节点看到多样化的数据分布。分区粒度很重要——过少的分区限制并行性，而过多的分区则增加元数据开销，降低分区内顺序读取的效率。

ML 生命周期中的存储

随着 ML 系统从初始开发阶段推进到生产部署和持续维护，存储需求会发生重大变化。理解这些变化的需求，有助于设计支持整个生命周期的基础设施高效运行，而不是在系统扩展或需求变化时进行后期改造。同一数据集在探索性分析（随机抽样以进行可视化）、模型训练（顺序扫描多个周期）和生产服务（随机访问单个预测）中的访问方式可能截然不同，因此需要适应这些多样化模式的存储架构。

在开发阶段，存储系统必须支持探索性数据分析和迭代模型开发，此时灵活性和协作比原始性能更为重要。数据科学家同时处理各种数据集，尝试特征工程方法，并快速迭代模型设计以完善方法。关键挑战在于管理数据集版本，而不至于占用过多存储空间。天真地为每个实验复制整个数据集的方法会迅速耗尽存储空间——在 100 GB 数据集上进行 10 次实验将需要 1 TB 的存储。像 DVC 这样的工具通过指针跟踪数据集版本，仅存储增量，从而实现高效实验。该系统维护从原始数据到转换后训练数据集的血缘关系，支持成功实验在数月后重新创建时的可复现性。

开发阶段的协作需要在数据可访问性和安全性之间取得平衡。数据科学家需要高效访问数据集以进行实验，但组织同时必须保护敏感信息。许多团队实施分层访问控制，广泛提供合成或匿名数据集以便于实验，而访问包含敏感信息的生产数据则需要批准和审计跟踪。这在不必要地暴露敏感信息的情况下，加快了代表性数据的快速迭代。

训练阶段的需求则大幅转向吞吐量优化。现代深度学习训练需要反复处理大规模数据集，跨越几十或几百个周期，因此 I/O 效率对可接受的迭代速度至关重要。高性能存储系统必须提供足够的吞吐量，以同时向多个 GPU 或 TPU 加速器提供数据，而不会造成瓶颈。当在 8 个 GPU 上训练 ImageNet 的 ResNet-50 时，每个 GPU 每个周期处理约 4000 张图像，批量大小为 256 张图像。以每个周期 30 秒计算，这需要在所有 GPU 上以每秒 40,000 张图像的速度加载数据——大约 500 MB/s 的解压缩图像数据。如果存储系统无法维持这一吞吐量，可能导致 GPU 空转，直接降低训练效率，增加基础设施成本。

预处理与实时计算之间的平衡在训练期间变得至关重要。大量预处理减少了训练时的计算需求，但增加了存储需求，并带来数据陈旧风险。计算机视觉的特征提取可能会将 150 KB 的图像转换为 5 KB 的 ResNet 特征——实现 30 倍的存储减少，消除重复计算。然而，当特征提取逻辑更改时，预计算的特征会变得过时，需对整个数据集重新计算。生产系统通常实施混合方法：预计算昂贵且稳定的转换（如特征提取），而对快速变化的特征则在训练期间实时计算。这种平衡取决于每个特征的具体特性。

部署和服务阶段的需求则优先考虑低延迟随机访问，而非高吞吐量顺序扫描。实时推理要求存储解决方案能够在毫秒级时间内检索模型参数和相关特征。对于每秒服务 10,000 个请求、延迟预算为 10 毫秒的推荐系统，特征存储必须支持每秒 100,000 次随机读取。内存数据库如 Redis 或复杂的缓存策略成为满足这些延迟要求的关键。边缘部署场景则引入额外限制：嵌入式设备的存储容量有限、与中央数据存储的连接不稳定，以及在不干扰推理的情况下更新模型。许多边缘系统实施分层存储，频繁更新的模型在本地缓存，而不常变化的参考数据则定期从云存储中提取。

模型版本控制在部署期间变得至关重要。存储系统必须促进模型版本之间的平滑过渡，确保服务中断最小，同时允许快速回滚以防新版本表现不佳。阴影部署模式，即新旧模型并行运行以进行验证，要求存储系统能够高效地同时提供多个模型版本。A/B 测试框架则需要每个请求选择模型版本，要求快速加载模型，而无需同时在内存中维护数十个模型版本。

监控和维护阶段则引入长期存储考虑，重点在于调试、合规性和系统改进。捕获传入数据及其预测结果，支持持续分析以检测数据漂移、识别模型故障和维护监管合规性。对于边缘和移动部署，存储限制使数据收集变得复杂——系统必须在收集足够的漂移检测数据和有限的设备存储及网络带宽之间取得平衡。受监管行业通常要求不可变存储以支持审计：医疗保健 ML 系统必须保留不仅仅是预测结果的完整数据来源，且需显示哪些训练数据和模型版本生成了每个诊断建议，可能长达数年或数十年。

热存储保留最近数据（过去一周），温存储保留中期数据（过去一个季度），冷归档存储则保留长期数据（过去几年），以满足合规性和深度分析的需要。这些层之间的过渡涉及访问延迟、存储成本和检索复杂性之间的权衡，系统必须在数据老化时自动管理。

特征存储：连接训练和服务

特征存储²⁴ 已成为关键基础设施组件，解决了在训练和服务环境之间保持一致性，同时实现跨模型和团队的特征重用的独特挑战。传统 ML 架构在训练时和服务时往往以不同的方式计算特征，导致训练 - 服务偏差，悄然降低模型性能。

当检查典型的 ML 开发工作流时，特征存储解决的根本问题变得清晰。在模型开发期间，数据科学家在笔记本或脚本中编写特征工程逻辑，通常使用与生产服务系统不同的库和语言。训练可能使用 SQL 对历史数据进行聚合计算“用户的过去 30 天总购买量”等特征，而服务则使用微服务以增量方式更新缓存值来计算相同特征。这些实现应该产生相同的结果，但细微差异——处理时区转换、处理缺失数据或四舍五入数值——导致训练和服务特征出现偏差。对生产系统的研究发现，Uber 约有 30% 到 40% 的初始部署受到训练 - 服务偏差的影响，这促使他们开发了集成特征存储的 Michelangelo 平台。

特征存储提供特征定义的单一真实来源，确保整个 ML 生命周期各阶段的一致性。当数据科学家定义特征“user_purchase_count_30d”时，特征存储维护该特征的定义（SQL 查询、转换逻辑或计算图），并在提供历史特征值用于训练或实时值用于服务时一致地执行它。这种架构模式消除了一个类别的微妙错误，这些错误通常很难调试，因为模型成功训练但在生产中表现不佳，且没有明显错误。

除了确保一致性，特征存储还实现了跨模型和团队的特征重用，显著减少了重复工作。当多个团队构建需要类似特征的模型时——如用于流失预测和追加销售模型的客户终生价值、用于推荐和个性化的用户人口统计特征、用于搜索排名和相关项目建议的产品属性——特征存储防止每个团队重新实现略有不同的特征。集中式特征计算减少了开发时间和基础设施成本，同时提高了模型的一致性。一个计算用户嵌入向量的推荐系统，这些向量在数百个维度上表示偏好，聚合数月的交互历史进行计算。特征存储一次计算这些嵌入并将其提供给所有用户。

特征存储通常实现双重存储模式，以优化不同的访问模式。离线存储使用列式格式（如 Parquet）在对象存储上，针对训练期间的批量访问进行了优化，此时在训练时对数百万个示例进行顺序加载是常见的。在线存储使用键值系统（如 Redis），针对服务时的随机访问进行了优化，此时需要在毫秒内检索单个特征向量。存储之间的同步变得至关重要：随着训练生成的新模型使用当前特征值，这些模型部署到生产时，期望在线存储提供一致的特征。特征存储通常实现定期批量更新，将新特征值从离线存储传播到在线存储，更新频率取决于特征的新鲜度要求。

时间旅行能力将复杂特征存储与简单缓存层区分开来。训练需要访问特定时间点的特征值，而不仅仅是当前值。考虑训练流失预测模型：对于在 1 月 15 日流失的用户，模型应使用 1 月 14 日计算的特征，而不是反映其流失状态的当前特征。时间点正确性确保训练数据与生产条件匹配，后者使用当前可用的特征来预测未来结果。实现时间旅行需要存储特征历史，而不仅仅是当前值，这大幅增加了存储需求，但使得在历史数据上进行正确训练成为可能。

特征存储性能特征直接影响训练吞吐量和服务延迟。对于训练，离线存储必须支持高吞吐量的批量读取，通常在训练开始时以每分钟加载数百万个特征向量。列式存储格式支持从包含数百个潜在列的宽特征表中高效读取特定特征。对于服务，在线存储必须支持每秒数千到数百万次读取，并具有单数字毫秒的延迟。这种双重模式优化反映了根本不同的访问模式：训练执行大规模顺序扫描，而服务执行小规模随机查找，要求针对每种模式优化的不同存储技术。

生产部署面临的额外挑战包括特征新鲜度和成本管理。实时特征需要立即更新，这对在线存储的容量和同步逻辑施加了压力。当用户将商品添加到购物车时，推荐系统希望在几秒钟内获得反映当前购物车内容的更新特征，而不是几小时。流式特征计算管道实时处理事件，持续更新在线存储，而不是通过定期批量作业。然而，流式处理引入了关于精确一次处理语义、处理迟到事件和管理每秒数百万次更新特征计算成本的复杂性。

特征存储在大规模下的成本管理变得重要。出于时间旅行能力而存储的全面特征历史会成倍增加存储需求：保留一年的每日特征快照需要 365 倍的存储，而不是仅保留当前值。生产系统实施保留策略，在时间上正确性和存储成本之间取得平衡，可能保留一年的每日快照、五年的每周快照，并在合规性要求的情况下清除旧历史。在线存储成本随着特征维度和实体数量的增加而增加：存储 100 万用户的 512 维嵌入向量，单精度（32 位浮点数）大约需要 200 GB，通常为可用性和低延迟访问而在多个区域复制，成本大幅增加。

特征存储迁移对于具有现有 ML 基础设施的组织来说是一项重大任务。遗留系统在众多库和管道中临时计算特征，使得集中化变得具有挑战性。成功的迁移通常是渐进的：从新特征开始进入特征存储，同时逐步迁移高价值的遗留特征，优先考虑那些在多个模型中使用或已知会导致训练 - 服务偏差问题的特征。保持抽象层，支持与特定特征存储实现无关的特征访问，防止与特定实现的紧密耦合，从而促进未来迁移，以应对需求变化或更好技术的出现。

现代特征存储实现包括开源项目如 Feast 和 Tecton，Databricks 特征存储和 AWS SageMaker 特征存储的商业产品，以及主要科技公司定制的解决方案。每种实现对支持的特征类型（结构化与非结构化）、支持的基础设施（云原生与本地）和与 ML 框架的集成进行了不同的权衡。特征存储作为关键 ML 基础设施的趋同，反映了特征工程占据 ML 开发工作的大部分，系统支持特征的基础设施为整个组织的 ML 投资组合提供了复利效益。

案例研究：KWS 系统的存储架构

完成我们对 KWS 案例研究的全面分析——追踪系统从初始问题定义、数据收集策略、管道架构、处理转换到标注方法——我们现在考察存储架构如何支持整个数据工程生命周期。这些存储决策直接反映并支持了早期阶段的选择。我们在 Framework Application Through Keyword Spotting Case Study 中建立的众包策略，决定了原始音频的数量和多样性要求。我们在 Systematic Data Processing 中设计的处理管道，定义了必须高效存储和检索的中间特征。我们在 Ensuring Training-Serving Consistency 中确定的质量指标，塑造了跟踪数据来源和质量分数所需的元数据存储需求。存储架构将这些线索结合在一起，使系统能够从开发到生产部署无缝运行。

典型的 KWS 存储架构实施了前面讨论的分层方法，每个层次服务于我们早期工程决策中出现的不同目的。来自各种来源的原始音频文件——通过我们设计的活动、合成数据填补覆盖空白以及来自部署设备的真实捕获——存储在使用云对象存储服务（如 S3 或 Google Cloud Storage）构建的数据湖中。这一选择反映了我们的可扩展性支柱：随着我们收集数百万个多样化示例以在各种环境中实现 98% 的准确率，音频文件的数量可能会增加到数百 GB 或 TB。数据湖的灵活模式适应不同的采样率、音频格式和录音条件，而无需对异构来源强加严格结构。对象存储提供的每 GB 低成本——通常是数据库存储成本的十分之一——使得在不产生过高费用的情况下，保留全面的数据历史以便于模型改进和调试成为可能。

数据湖存储全面的来源元数据，满足我们治理支柱的要求，这些元数据在早期管道阶段被证明是必不可少的。对于每个音频文件，系统维护来源类型（众包、合成或真实）、收集日期、在伦理上收集和同意的人口统计信息、由我们验证管道计算的质量评估分数，以及处理历史，显示已应用的转换。这些元数据使得在训练数据选择时能够过滤，并支持隐私法规和伦理 AI 实践所要求的合规性。

来自我们处理管道的处理特征（如声谱图、MFCC 和其他适合 ML 的表示）转移到一个结构化的数据仓库中，以优化训练访问。这满足了原始存储的不同性能需求：原始音频主要在处理管道执行转换时访问，而处理特征在训练周期中被反复读取，因为模型在数十次迭代中反复处理数据集。仓库使用列式格式（如 Parquet），使得在训练时高效加载特定特征成为可能。对于像 MSWC 这样具有 2300 万个示例的数据集，列式存储使训练 I/O 减少了 5 到 10 倍，相比基于行的格式，直接影响模型开发过程中的迭代速度——这可能是训练需要数小时还是数天的关键所在。

KWS 系统从实施我们审视过的架构模式的特征存储中获益匪浅。常用的音频表示可以一次计算并存储，以供不同实验或模型版本重用，避免重复计算。特征存储实现了双重架构：离线存储在对象存储上使用 Parquet 格式，针对训练数据提供高吞吐量的顺序读取，而在线存储则使用 Redis，针对低延迟推理进行优化，支持我们在问题定义中确定的 200 毫秒延迟要求。这一双重架构解决了训练的批量访问模式（顺序读取数百万个示例）与服务的随机访问模式（实时检索单个音频片段的特征）之间的根本矛盾。

在生产中，边缘设备的存储需求变得至关重要，因为我们的系统需要部署到资源受限的设备上。模型必须足够紧凑，以适应我们在问题定义中设定的 16 KB 内存限制，同时保持快速访问模型参数以实现实时唤醒词检测。边缘设备通常以量化模型的专用格式（如 TensorFlow Lite 的 FlatBuffers）存储，这些格式支持内存映射访问，而无需违反延迟要求的反序列化开销。缓存在多个层次上应用：频繁访问的模型层存储在 SRAM 中以实现最快访问，完整模型存储在闪存中以便于跨电源周期持久化，而基于云的模型更新则定期提取，以保持当前的唤醒词检测模式。这种多层次缓存确保设备即使在网络连接间歇的情况下，也能有效运行——这是针对在农村地区（连接有限）到城市环境（网络拥堵）等不同网络环境中部署的消费设备的可靠性要求。

数据治理

我们所检查的存储架构——数据湖、数据仓库、特征存储——不仅仅是技术基础设施，而是治理执行机制，决定了谁可以访问数据、如何跟踪使用情况以及系统是否符合监管要求。我们在本章中所做的每一个架构决策，从数据获取策略到处理管道，再到存储设计，都带来了治理影响，这些影响在系统面临监管审计、隐私违规或伦理挑战时表现得尤为明显。数据治理从抽象政策转变为具体的工程实践：访问控制系统强制执行谁可以读取训练数据，审计基础设施跟踪每次数据访问以确保合规，保护隐私的技术保护个人信息，同时支持模型训练，血缘系统记录原始音频录音如何转变为生产模型。

我们的 KWS 系统体现了当复杂存储遇到敏感数据时，治理所面临的挑战。支持便捷语音激活的始终在线架构，带来了深远的隐私顾虑：设备持续处理用户家中的音频，特征存储维护跨越数百万用户的语音模式历史，边缘存储缓存源自全人群训练数据的声学模型。这些技术能力不仅实现了我们的质量、可靠性和可扩展性要求，同时也带来了围绕同意管理、数据最小化、访问审计和删除权利的治理义务，这些都需要同样复杂的工程解决方案。有效的治理通过在整个 ML 生命周期中系统实施隐私保护、安全控制、合规机制和问责基础设施，解决这些相互关联的挑战。

安全性和访问控制架构

生产 ML 系统实施分层安全架构，其中治理要求转化为可执行的技术控制，适用于每个管道阶段。现代特征存储通过实施基于角色的访问控制（RBAC）很好地体现了这种集成——将组织政策（数据科学家可以读取训练特征，服务系统可以读取在线特征，但都不能修改原始源数据）映射为防止未经授权访问的数据库权限。这些访问控制系统在我们检查的存储层之间操作：对象存储如 S3 强制执行存储桶策略，决定哪些服务可以读取训练数据，数据仓库实施列级安全，隐藏大多数查询中敏感字段如用户标识符，特征存储则维护单独的读/写路径，具有不同的权限要求。

我们的 KWS 系统需要特别复杂的访问控制，因为语音数据在组织和设备边界间流动。边缘设备本地存储量化模型和缓存音频特征，要求加密以防止提取——语音助手的模型参数，尽管单独看起来不敏感，但可能导致竞争对手的逆向工程或泄露训练数据特征。特征存储维护单独的安全区域：生产区域，服务系统使用具有只读访问权限的服务凭据检索实时特征；训练区域，数据科学家使用单独凭据访问历史特征，这些凭据会被跟踪以便审计；运维区域，SRE 团队可以访问管道健康指标，而无需查看实际的语音数据。这种架构分离通过 Kubernetes 命名空间实现，云部署中具有单独的 IAM 角色，确保即使一个组件（如服务系统漏洞）被攻破，也不会暴露训练数据或授予对生产特征的写入访问。

访问控制系统与整个数据生命周期的加密集成。存储在数据湖中的训练数据使用服务器端加密，密钥通过专用密钥管理服务（AWS KMS、Google Cloud KMS）管理，这些服务强制执行分离：训练作业凭据可以解密当前训练数据，但无法解密已使用的历史版本，从而实现数据最小化。特征存储实施静态加密（使用平台管理的密钥加密存储）和传输中加密（所有管道组件与特征存储之间的通信均使用 TLS 1.3）。对于 KWS 边缘设备，从云训练系统向数百万个分布式设备传输的模型更新需要端到端加密和代码签名，以验证模型完整性，防止对抗性模型注入，可能会危及设备安全或用户隐私。

技术隐私保护方法

当访问控制决定谁可以使用数据时，隐私保护技术决定系统即使对授权用户也暴露什么信息。差分隐私（differential privacy），我们在 第 17 章：可信 AI 中深入探讨的内容，提供了单个训练示例不会通过模型行为泄露的正式数学保证。在生产中实施差分隐私需要仔细工程设计：在模型开发中添加经过校准的噪声、跟踪所有数据使用的隐私预算——每个查询或训练运行消耗预算、强制执行系统范围内的总隐私损失限制，以及通过测试基础设施验证已部署模型满足隐私保证，通过对抗性攻击尝试提取训练数据。

KWS 系统面临特别严峻的隐私挑战，因为始终在线架构需要持续处理音频，同时最小化数据保留和暴露。生产系统通过架构选择实现隐私：设备端处理，唤醒词检测完全在本地运行，使用存储在边缘闪存中的模型，音频仅在检测到唤醒词时才会被传输；联邦学习方法，设备在本地音频上进行训练以改善唤醒词检测，但仅将聚合的模型更新发送回中央服务器，而不传输原始音频；以及自动删除策略，检测到的唤醒词音频仅在质量监控时短暂保留，然后被永久删除。这些不仅仅是政策声明，而是体现在存储系统设计中的工程要求——数据湖实施生命周期策略，自动在 30 天后删除语音样本，除非经过额外同意被标记为长期研究使用，特征存储则实施生存时间（TTL）字段，导致用户语音模式过期并从在线服务存储中清除。

删除请求的处理复杂性，尤其是 GDPR 和类似法规要求的处理，进一步增加了系统的复杂性。当用户行使“被遗忘权”时，系统必须定位并删除不仅仅是源音频录音的所有派生特征，包括存储在特征存储中的模型嵌入、可能编码语音特征的模型嵌入，以及引用用户的审计日志——同时保持审计完整性以确保合规。这需要系统的数据血缘跟踪，我们接下来将审视的内容，使系统能够识别通过分布式存储层和管道阶段派生的所有数据工件。

为合规性架构

合规性要求转变为系统架构约束，塑造管道设计、存储选择和操作程序。GDPR 的数据最小化原则要求限制收集和保留仅为声明目的所必需的数据——对于 KWS 系统，这意味着仅在训练之外需要保留语音样本时，才需证明其合理性，记录在系统设计文档中，并在期限届满后自动删除。访问权利要求系统检索与用户相关的所有数据——实际上，是查询分布式存储系统（数据湖、数据仓库、特征存储）并合并结果，这一能力需要在所有存储层之间保持一致的用户标识符，以及支持用户级高效查询的索引，而不是全表扫描。

全球范围内运营的语音助手面临特别复杂的合规性环境，因为监管要求因管辖区而异，并且根据用户年龄、数据敏感性和处理地点的不同而有所不同。加利福尼亚州的 CCPA 授予类似于 GDPR 的删除权，但时间表和例外情况不同。针对儿童的语音数据会触发美国的 COPPA 要求，在收集 13 岁以下用户的数据之前，需获得可验证的父母同意——当语音特征无法可靠地揭示年龄时，这需要额外的身份验证机制。欧洲对跨境数据传输的要求限制了将欧盟用户的语音数据存储在指定国家之外的服务器上的可能性，除非存在特定的保护措施，这推动了区域数据湖、特征存储复制策略和处理本地化的架构决策。

标准化文档框架如数据卡 (图 17) 将这些合规性要求转化为操作文档。数据卡不是与系统分开维护的法律文件，而是可执行规范：训练管道在处理之前检查输入数据集是否具有有效的数据卡，模型注册表要求所有训练数据都引用数据卡，服务系统则强制执行仅使用合规数据训练的模型才能部署到生产。对于我们的 KWS 训练管道，数据卡记录的不仅是 MSWC 数据集的特征，还包括同意基础（研究使用、商业部署）、地理限制（可以训练全球模型，不能在特定区域训练模型，需额外同意）和保留承诺（音频在特征提取后删除，特征保留用于模型迭代）。

构建数据血缘基础设施

数据血缘从合规文档转变为操作基础设施，推动治理能力贯穿 ML 生命周期。现代血缘系统如 Apache Atlas 和 DataHub²⁵ 与管道调度器（Airflow、Kubeflow）集成，自动捕获关系：当 Airflow DAG 从 S3 读取音频文件，将其转换为声谱图，并将特征写入仓库时，血缘系统记录每一步，创建一个图，追踪任何特征如何追溯到其源音频文件，并向前追溯到所有使用它训练的模型。当用户行使 GDPR 权利时，这一自动化跟踪对于删除请求至关重要——当用户行使 GDPR 权利时，血缘图识别所有派生工件（提取的特征、计算的嵌入、训练的模型版本），这些工件必须被删除或重新训练。

生产 KWS 系统在我们本章审视的所有阶段实施血缘跟踪。源音频摄取创建血缘记录，将每个音频文件链接到其获取方式（众包平台、网络爬虫源、合成生成参数），以验证同意要求。处理管道执行扩展血缘图，音频变为 MFCC 特征、声谱图和嵌入——每次转换都会添加节点，记录输出工件、代码版本、超参数和执行时间戳。训练作业创建特征集合到模型工件的血缘边，记录哪些数据版本训练了哪些模型版本。当语音助手设备下载模型更新时，血缘跟踪记录该部署，以便在训练数据后发现质量或合规性问题时进行追溯。

血缘的操作价值超出了合规性，还包括调试和可复现性。当 KWS 对特定口音的准确性下降时，血缘系统使得追踪受影响的预测回到已部署的模型，识别出训练数据对该口音的代表性不足。当研究团队希望重现六个月前的实验时，血缘图捕获生成该结果所需的确切数据版本、代码提交和超参数。特征存储本地集成血缘：每个特征都包括关于源数据、转换逻辑和计算时间的元数据，使得查询“哪些模型依赖于用户位置数据”成为可能，以指导数据源更改时的影响分析。

审计基础设施和问责制

当血缘跟踪数据存在及其转换方式时，审计系统则记录谁何时访问了数据，创建合规性所需的问责路径。生产 ML 系统生成大量审计事件——每次训练数据访问、特征存储查询和模型预测都可能生成审计事件，对于大规模系统，这些事件迅速累积到每天数十亿条。如此大规模需要专用基础设施：不可变的追加-only 存储（通常使用云原生服务如 AWS CloudTrail 或 Google Cloud Audit Logs），防止篡改历史记录，高效索引（通常是 Elasticsearch 或类似系统），使得能够在不进行全表扫描的情况下查询特定用户或数据集的访问，以及自动化分析，检测潜在安全漏洞或政策违规的异常模式。

KWS 系统实施多层审计架构，平衡粒度、性能和成本。边缘设备在本地记录关键事件——唤醒词检测、模型更新、隐私设置更改——日志定期上传到集中存储以便于合规性保留。特征存储记录每个查询及其请求元数据：哪个服务请求了特征、访问了哪些用户 ID、检索了哪些特征，从而能够进行安全调查时的分析，如“谁访问了这个特定用户的语音模式”。训练基础设施记录数据集访问，记录哪些作业在何时读取了哪些数据分区，实现了证明已删除用户数据不再出现在新模型版本中的问责。

血缘和审计系统的集成，提供了全面的治理可观察性。当监管机构审计语音助手提供商时，血缘图展示用户音频如何转变为模型，审计日志证明谁访问了这些音频，从而提供了证明合规所需的透明度。当安全团队调查可疑的数据外泄时，审计日志识别可疑的访问模式，而血缘图揭示了被破坏的凭据可以接触到哪些数据。机器学习团队在调试模型质量问题时，血缘追踪特定训练数据的问题，审计日志确认没有未经授权的修改发生。这一操作治理基础设施，贯穿于我们在本章中审视的数据工程实践，转变为可执行的技术控制，维护信任，确保 ML 系统在复杂性和影响力上有效扩展。

随着机器学习系统越来越多地嵌入高风险应用（医疗诊断、财务决策、自动驾驶汽车）中，施加于治理基础设施的工程严谨性，将决定不仅仅是合规性，还有公众信任和系统问责。区块链启发的防篡改日志²⁶ 和通过基础设施即代码实现的自动化政策执行等新兴方法，有望增强治理控制的可靠性和可审计性，尽管它们也引入了自身的复杂性和成本权衡，组织必须根据其特定需求仔细评估。

常见误区与陷阱

数据工程是每个 ML 系统的基础，但它仍然是被低估的 ML 开发方面之一。管理数据管道、确保质量和维护治理的复杂性，导致了许多可能导致成本高昂的错误，这些错误可能会破坏即使是最复杂的模型。

误区： 更多数据总是能带来更好的模型性能。

这一普遍信念驱使团队收集海量数据集，而不考虑数据质量或相关性。虽然在适当的策划下，更多的数据确实可以改善性能，但原始数量往往会引入噪声、不一致和无关的示例，从而降低模型性能。相比之下，经过适当标注和代表性覆盖的小型高质量数据集，通常会优于数据质量存在问题的大型数据集。海量数据集的计算和存储成本也会带来实际限制，限制实验和部署选项。有效的数据工程优先考虑数据质量和代表性，而非单纯的数量。

陷阱： 将数据标注视为简单的机械任务，可以在没有监督的情况下外包。

组织通常将数据标注视为低技能工作，可以由外部团队或众包平台快速完成。这种方法忽视了可靠标签所需的领域专业知识、一致性要求和质量控制。糟糕的标注指南、培训不足的工人和质量验证不充分，导致标签噪声，根本限制了模型性能。在这些标签错误影响模型训练后再进行纠正的成本，远远超过了对适当标注基础设施和监督的投资。

误区： 数据工程是一项一次性设置的工作，可以在模型开发开始之前完成。

这种误解将数据管道视为静态基础设施，而不是需要持续维护和适应的动态系统。现实世界的数据源会随着时间推移而变化，出现模式演变、质量下降和分布变化。部署在生产中的模型会遇到新的数据模式，要求管道更新和质量检查。将数据工程视为完成的基础设施，而不是持续的工程实践，往往会导致系统故障，因为它们无法适应不断变化的需求。

误区： 训练和测试数据的划分足以确保模型的泛化能力。

尽管适当的训练/测试 划分可以防止对训练数据的过拟合，但并不能保证在真实世界中的表现。生产数据可能因时间、地域或人口统计变化，与开发数据集存在显著差异。在经过精心策划的测试集上获得 95% 准确率的模型，在部署到新地区或新时间段时，可能会发生灾难性失败。稳健的评估需要理解数据收集偏差、实施持续监测，并保持代表实际部署条件的验证集，以反映实际部署条件。

陷阱： 构建数据管道时不考虑故障模式和恢复机制。

数据管道通常仅针对一切顺利的情况进行设计，而忽视了数据源可能失败、格式可能变化和质量可能下降的现实。当生产系统崩溃或无声无息地产生错误结果时，团队才发现这些问题。一个处理金融交易的管道，如果没有对格式错误的数据进行适当的错误处理，可能会丢失关键记录或重复交易。稳健的数据工程需要明确处理故障，包括数据验证、检查点、回滚能力和异常检测机制，以便在下游系统受到影响之前发现问题。

总结

数据工程作为基础设施，将原始信息转化为机器学习系统的基础，决定了模型性能、系统可靠性、伦理合规性和长期可维护性。本章揭示了数据管道每个阶段所需的细致工程决策，这些决策从数据获取策略到处理管道，再到存储设计，贯穿于整个 ML 生命周期。看似简单的“准备数据”任务，实际上包含了数据质量与获取成本、实时处理与批量效率、存储灵活性与查询性能、隐私保护与数据实用性之间的复杂权衡。

数据系统的技术架构展示了工程决策如何在管道中累积，形成强大、可扩展的基础或脆弱、维护成本高的技术负担。数据获取策略必须应对自然界中几乎不存在完美数据集的现实，采用复杂的方法，从众包和合成生成到仔细策划和主动学习。存储架构决策贯穿整个 ML 生命周期，影响训练迭代速度、服务延迟、特征一致性和操作成本。流式数据处理和实时特征存储的出现，反映了对 ML 系统能够持续适应变化环境的需求，同时保持一致性和可靠性。

关键要点

• 四大支柱——质量、可靠性、可扩展性和治理——形成了一个相互关联的框架，优化一个支柱会与其他支柱产生权衡，因此需要系统地平衡，而不是孤立优化。

• 训练 - 服务一致性是数据工程面临的最关键挑战，当训练和服务环境之间的转换逻辑不同时，会导致大约 70% 的生产 ML 失败。

• 数据标注成本通常超过模型训练成本的 1,000-3,000 倍，但在项目规划中却很少受到重视。理解完整的经济模型（基础成本 × 审查开销 × 返工倍数）对现实预算编制至关重要。

• 有效的数据获取需要战略性地结合多种方法——现有数据集用于质量基准，网络爬虫用于规模，众包用于覆盖，合成生成用于边缘案例——而不是依赖单一方法。

• 存储架构决策贯穿整个 ML 生命周期，影响训练迭代速度、服务延迟、特征一致性和操作成本。分层存储策略在性能要求和经济限制之间取得平衡。

• 数据治理不仅仅是合规性问题，还能实现技术能力：血缘跟踪实现调试和可复现性，访问控制实现隐私保护架构，偏见监测实现系统演变过程中的公平性改善。健全的数据治理实践的集成，确保 ML 系统在复杂性和影响力上有效扩展时，仍然可靠、合规和透明。数据卡、血缘跟踪和自动化监控创建了所需的可观察性，以便在数据漂移、隐私违规和质量下降影响模型行为之前，及时发现并加以修正。这些工程基础设施为 第 8 章：AI 训练 中的分布式训练策略、 第 10 章：模型优化 中的模型优化技术以及 第 13 章：机器学习运维 中的 MLOps 实践奠定了可靠的数据基础设施先决条件，成为有效扩展 ML 系统的基础。