数据工程终极设计模式——数据质量模式引言在数据驱动决策中，data quality 不只是一个技术问题，它是洞察和模型

引言

在数据驱动决策中，data quality 不只是一个技术问题，它是洞察和模型可靠性的基础。不准确或不完整的数据可能会悄悄侵蚀信任、破坏 machine learning outputs，并误导 dashboards，而且通常不会被立即发现。然而，在许多组织中，确保数据质量仍然是事后考虑的问题，要么被孤立在下游，要么被默认认为是另一个团队的责任。随着系统变得更加分布式，use cases 也越来越 mission-critical，主动的数据质量方法变得必不可少。本章介绍可复用的 data quality patterns，帮助构建能够验证所摄入数据、预判故障，并在 anomalies 出现时发出 alerts 的 pipelines。你将通过真实世界示例，例如有缺陷的 discount data 污染 pricing model，理解糟糕 data hygiene 的影响，以及在整个 pipeline 中系统化实施 validations、schema enforcement 和 error handling 的必要性。

本章不会规定单一工具，而是提供适用于 batch、streaming 和 hybrid environments 的战略实践。你将学习如何实现 column-level 和 cross-field validations，维护 schema contracts，检测 duplicates，监控 freshness 和 distribution skews，并结合 lineage 和 metrics 纳入 observability。本章会在这些语境中讨论 Great Expectations、dbt、Soda SQL 和 OpenLineage 等工具。通过设计具备自我感知能力的 pipelines，也就是内置 logging、monitoring、anomaly detection 和 schema enforcement，你可以确保数据不仅快速到达，而且完整、准确，并能够自信地驱动业务结果。

结构

本章将覆盖以下主题：

Data Validation、Anomaly Detection 和 Error Handling
Data Lineage and Observability
Schema Enforcement and Versioning
Duplicate Detection and Data Deduplication
Data Quality Metrics and Monitoring

Data Validation、Anomaly Detection 和 Error Handling

想象一家银行批准了一笔高额贷款，因为某个 customer 的 income 被错误记录成实际金额的 10 倍；或者一个 supply chain dashboard 因为 timestamp mismatch 显示库存水平创下历史新低。这些不只是 data glitches，它们是 trust 的失败。

在数据系统中，“garbage in, garbage out” 不只是一句口号，而是一条警示性的真理。无论你是在构建 data warehouse、训练 machine learning model，还是开发 real-time dashboard，确保数据质量和可靠性都是基础。本节将介绍三项关键实践，它们有助于确保 data integrity：validation、anomaly detection 和 error handling。它们不是相互孤立的工具，而是互相联动的系统，可以帮助更早、更频繁、更自动化地捕获并修正问题。

Data Validation

Data validation 是任何稳健 data pipeline 中的第一道 checkpoint。它涉及在数据进一步处理之前，验证数据是否符合预期 formats、types 和 business rules。

Data Validation 的常见技术

Schema Validation：确保 data types、formats 和 nullability 符合预期。

示例：“Customer Age” 必须是 18 到 100 之间的 integer。

Business Rule Enforcement：

示例：“Loan amount should not exceed 5x monthly income.”

Tools and Examples

Python（pydantic）：

from pydantic import BaseModel, conint

class Customer(BaseModel):
    age: conint(ge=18, le=100)
    income: float

Apache Spark：

from pyspark.sql.types import StructType, StructField, IntegerType

schema = StructType([
    StructField("customer_id", IntegerType(), False),
    StructField("age", IntegerType(), True)
])

df = spark.read.schema(schema).csv("customer.csv")

SQL：

CREATE TABLE customers (
age INT CHECK (age >= 18 AND age <= 100),
income DECIMAL(10,2) NOT NULL
);

Where to Apply Validation

在 API level，尤其是 data ingestion 期间。
在 ETL / ELT transformations 期间。
将 external datasets 导入 warehouse 时。

早期 validation 可以防止错误数据污染 downstream systems，确保 analytics 和 machine learning pipelines 保持可靠。

Anomaly Detection

Validation checks 确保数据符合预期规则，而 anomalies 是看起来合法、但异常到足以引发怀疑的数据点。捕获这些 outliers 对发现 errors、fraud 或 unexpected patterns 至关重要。

Anomalies 包括：

Point Anomalies：单个异常突出数据点。示例：某个 customer 的 age 被记录为 200。

Contextual Anomalies：在特定上下文中显得异常的数据点。示例：普通工作日 sales 突然激增。

Collective Anomalies：一组 values 单独看都正常，但组合起来异常。示例：异常 clickstream patterns。

Techniques to Detect Anomalies

检测 anomalies 对维护 machine learning systems 的可靠性和性能非常关键，因为它有助于识别 unexpected patterns、data issues 或 model behavior deviations，这些问题可能影响结果。

Statistical Methods：

import numpy as np

z_scores = (data - data.mean()) / data.std()
anomalies = data[np.abs(z_scores) > 3]

Rule-Based Thresholding：

if transaction_amount > 1000000:
    alert("Transaction exceeds expected business threshold")

Machine Learning：

from sklearn.ensemble import IsolationForest

clf = IsolationForest()
preds = clf.fit_predict(data)

Time Series Tools：

Facebook Prophet，用于 trend / seasonality。
Twitter 的 AnomalyDetection R package。

Visual Detection：

Box Plots：适合发现 distributions 中的 outliers。
Line Charts：揭示随时间变化的 spikes、dips 和 trends。

Anomaly detection 是 validation 的补充，它识别“可接受范围之内的意外情况”，构成第二层数据防线。

Error Handling

即使有强大的 validation 和 anomaly detection，现实世界的 data pipelines 中 errors 仍然不可避免。系统必须被设计成能够检测、隔离并从 failures 中恢复，而不破坏整个 workflow。

Common Types of Errors

Schema mismatches
Null 或 missing values
API 或 database connection timeouts
Ingestion 期间的 malformed records

Error Handling Strategies

有效的 error handling strategies 对确保 machine learning systems 的稳定性和韧性至关重要，使它们能够优雅管理 failures，并在 production environments 中维持一致 performance。

Try-Except Logic：

try:
    process(record)
except ValueError as e:
    log_error(e)
    continue

Dead-letter Queues（DLQs） ：在 Kafka 或 Pub/Sub 等 streaming systems 中，problematic messages 会被发送到 DLQs，供 inspection 和 reprocessing。

Retries with Backoff：

import time

for i in range(3):
    try:
        response = fetch_data()
        break
    except:
        time.sleep(2 ** i)  # exponential backoff

Graceful Degradation：Pipeline 不直接崩溃，而是 fallback 到 default values，或跳过 record。

Monitoring and Alerts：与 Prometheus、ELK Stack 或 Datadog 等工具集成，跟踪 failure rates 并触发 alerts。

Example Scenario

想象一个 ingesting loan applications 的 batch job。其中一条 record 的 “loan amount” field 包含意外字符，导致 job 失败。如果已具备 error handling：

Faulty record 会被跳过并记录。
Alert 会发送给 data engineering team。
Batch 其余部分继续处理。

Error handling 为数据系统增加韧性，确保一颗坏苹果不会毁掉整筐苹果。

Data Lineage and Observability

Data lineage 指的是在组织生态系统内，数据贯穿生命周期移动时的全面追踪。从数据生成或摄入点，到最终被 users、reports 或 systems 消费，lineage 会以视觉化和语义化方式捕获每一次 transformation、hop 和 dependency。

从核心上看，data lineage 帮助回答三个关键问题：

这些数据来自哪里？
它在途中发生了什么？
它现在在哪里被使用，由谁使用？

通过映射这段旅程，组织可以建立对 data assets 的信任，执行 regulatory compliance，并快速排查数据问题。

Data Lineage 的关键组成部分

Data Lineage 的关键组成部分如下：

Data Sources：数据的来源。它可以来自 internal systems，例如 CRM、ERP；third-party APIs；sensor networks（IoT）；databases；或 external files。Lineage 从这里开始捕获 metadata。

Transformations：数据一旦被摄入，通常会经历 cleaning、joining、enrichment、filtering 和 aggregation。Lineage 会记录每个 transformation step，包括所使用的 logic，例如 SQL、ETL jobs 和 scripts。

Storage Systems：包括 staging areas 等 intermediate storage，以及 data lakes、warehouses 或 marts 等最终目的地。Lineage 会跟踪这些 systems 中的每一次 read / write operation。

Data Consumers：Lineage 显示数据最终去向，以及由谁消费：dashboards、machine learning models、reports、applications 或 downstream pipelines。

Relationships between Assets：识别 fields、columns 或 tables 如何关联。例如，如果两张 tables 在 transformation 中被 join，lineage 会记录这种 relationship。

Metadata and Annotations：丰富的 lineage systems 会包含 annotations、version histories、user tags 和 comments，为数据提供额外业务或技术上下文。

Benefits of Implementing Data Lineage

Data lineage 不只是 documentation exercise，它是让组织能够清晰、敏捷且自信地管理数据的基础能力。随着现代数据环境日益复杂，追踪数据从 origin 到 consumption point 的能力变得不可或缺。实施 lineage 会在 operations、compliance、analytics 和 collaboration 等方面带来一系列战略优势。

Faster Issue Resolution through Root Cause Analysis

当 reports、dashboards 或 Machine Learning outputs 中出现 inconsistencies 或 anomalies 时，定位问题来源通常非常耗时。Data lineage 通过清晰展示数据经历的每一个 processing step，缩短了这个周期。团队可以从错误数据点向 raw source 回溯，识别导致问题的具体 transformation 或 logic。这项能力显著减少 downtime，并加速 issue resolution。

Safer and More Informed Change Management

Data environments 是动态的，schema changes、logic updates 和 infrastructure migrations 都很常见。如果缺乏 data assets 之间连接关系的可见性，这些 changes 可能破坏 downstream dependencies，影响 dashboards、APIs 或 machine learning models。Lineage 允许团队在实施前评估 proposed changes 的完整影响。清楚知道哪些 components 依赖某个 column 或 table，可以确保 modifications 被安全引入，并让所有 stakeholders 充分知情。

Strengthened Compliance and Audit Readiness

遵守 data privacy 和 protection regulations，要求对数据如何被处理和访问具备透明性和问责能力。Lineage 提供证明 personal 或 sensitive data 按规定标准处理所需的证据。它充当一条 living audit trail，展示数据如何在系统中移动、谁与其交互，以及它如何被转换。这会简化 internal audits，并支持 external regulatory reviews。

Improved Collaboration across Functions

Data lineage 弥合了 technical 和 non-technical stakeholders 之间的沟通缺口。Engineers、analysts、data stewards 和 business users 可以参考同一张 lineage map，理解 data dependencies、business logic 和 transformation flows。这个共同参考点可以加速 onboarding、减少重复工作，并促进负责生产和消费数据的 teams 更好对齐。

Enhanced Trust and Transparency in Data

为了让 decision-makers 信赖 analytics，底层数据必须值得信任。Lineage 通过让 data products 的构建过程透明化，提升用户信心。Users 可以验证 metrics 来自哪里、应用了哪些 assumptions，以及 aggregations 如何执行。这种可见性建立了对 data-driven decisions 的信心，并提升 data assets 在组织内的采用率。

Techniques for Capturing and Managing Data Lineage

组织可以根据 infrastructure、toolchain 和成熟度，使用多种技术捕获 data lineage。每种方法在 accuracy、automation、scalability 和 implementation complexity 方面都有自己的优势和取舍。稳健的 lineage strategy 可能会组合多种方法，以提供完整的数据流和依赖关系视图。

Pattern-Based Lineage

这种技术通过分析 datasets 之间的 metadata 来推断 lineage，例如 table names、column headers、data types 和 field usage。它不依赖解析 transformation logic 或 execution traces，而是识别暗示数据关系的相似性和 patterns。

Advantages：Technology-agnostic，并且相对容易跨不同平台实施。

Limitations：可能遗漏嵌入在 code 或 scripting logic 中的 transformations，导致 lineage accuracy 出现缺口。

Self-Contained Lineage

在紧密集成的数据平台中，例如某些 data lakes 或 unified analytics environments，lineage 会通过原生 tracking processing steps 和 metadata 在内部捕获。这些平台会自动记录同一环境中数据何时被写入、转换和读取。

Advantages：在平台边界内自动化且准确。

Limitations：对 external systems 或 cross-platform dependencies 几乎没有可见性。

Tagging-Based Lineage

这种方法会在数据流经 pipelines 时嵌入 identifiers 或 labels。这些 tags 可以从 source 跟踪到 destination，从而无需直接检查 transformation logic 就能实现 traceability。

Advantages：在由单一 orchestration tool 或 engine 处理 transformations 的集中式环境中很有效。

Limitations：依赖 tags 的一致使用；对于绕过 tagging mechanism 的数据不起作用。

Parsing-Based Lineage

Parsing-based lineage 涉及对执行数据 transformations 的 code 进行逆向分析，例如 SQL scripts、ETL workflows 或 data processing pipelines，以提取 inputs 和 outputs 之间的关系。它是最全面、最准确的方法。

Advantages：对 transformations 提供深度可见性，尤其适用于 custom logic 或复杂 pipelines。

Limitations：实施可能很复杂，需要支持多种 programming languages 和 tools。

Hybrid Lineage Strategies

许多现代数据平台采用 hybrid approach，将 parsing-based insights 与 pattern recognition、tagging 和 native platform tracking 结合起来。这使得 lineage 可以在 heterogeneous systems 中形成更整体、更准确的视图。

Establishing Resilience through Data Observability

在现代 data-driven organizations 中，快速检测和解决数据问题不仅是技术要求，也是业务必需。随着 pipelines 变得更复杂、data volumes 增长，识别会破坏 reporting、analysis 或 machine learning outputs 的 silent failures 变得更困难。这正是 data observability 发挥关键作用的地方。

Data observability 指的是实时监控、理解并确保 data systems 在多个维度上保持健康的能力。它通过让团队在问题发生时立即检测和诊断，提供一种主动的数据质量方法，并在问题影响业务结果之前进行处理。

Core Dimensions of Data Observability

一个全面的 observability framework 会监控数据及其基础设施的多个方面：

Freshness：跟踪数据是否按时到达，并符合预期 intervals。例如，如果某张 table 应该每天更新，但最近一次 refresh 已经是两天前，observability systems 会将其标记为潜在问题。

Volume：监控 ingest 和 processed data 的 size 或 row count。Volume 的异常下降或激增，可能表示 partial loads、schema mismatches 或 upstream failures。

Schema：检测结构变化，例如新增或删除 columns、data type mismatches 或 renamed fields。如果不及时处理，这些 changes 可能破坏 downstream models 或 dashboards。

Distribution：查看 value ranges、null percentages 和 data skew 等统计属性。突然偏离，例如 customer age 平均值从 35 变成 120，可能是 logic 或 input errors 的早期信号。

Lineage Integration：当与 data lineage 集成时，observability 可以帮助定位问题并判断影响范围。例如，source table 中的 missing value 可以被追踪到其 downstream dashboards 和 consumers。

Benefits of Data Observability

Data observability 通过主动暴露问题、减少 resolution time，并增强对 data systems 的信任，带来显著价值。相比依赖手动检查或对 broken dashboards 做出被动反应，具备 observability 的团队可以自信管理 data pipelines 的健康状况，并在潜在 failures 影响 operations 之前进行预判。

主要收益包括：

Early Detection of Data Quality Issues

Observability tools 会针对 anomalies 发出 alerts，例如 missing data、unusual distributions 或 late arrivals，在它们表现为下游业务问题之前进行提示。这种 early detection 让团队能够快速处理 root causes，并防止 errors 在 dependent systems 中级联扩散。

Faster Troubleshooting and Resolution

通过清晰了解数据如何流动和转换，团队可以更高效地定位问题来源。这在调试复杂 pipelines 时尤其有用，因为传统 logging 可能不足以支撑问题定位，或会导致 resolution 延迟。

Improved Data SLAs and Reliability

组织可以定义并监控 data Service Level Agreements（SLAs），例如 freshness targets 或 completeness thresholds。稳定满足这些 SLAs，可以提升 data consumers 的信任，并确保 analytical outputs 保持及时可靠。

Operational Efficiency

通过自动化 health checks 和 monitoring，observability 减少了 manual diagnostics 的负担。Data teams 可以将注意力从 firefighting 和 reactive maintenance 转移到构建 scalable infrastructure 和交付新能力上。

Enhanced Trust across the Business

透明的 observability practices 表明 data operations 具备成熟度。当 stakeholders 知道 data quality 被持续验证和监控时，他们会更信任用于战略决策的 insights、reports 和 models。

Key Practices for Successful Implementation

虽然 data observability 的概念容易理解，但真正落地需要有意设计、深度集成，以及 engineering、data 和 operations teams 之间的协作。目标不只是监控数据错误，而是在整个数据生态中构建主动问责和持续改进的文化。

一个有效的 observability framework 会结合 automated metrics collection、real-time validation、alerting mechanisms 和 visual diagnostics，同时避免引入过高 overhead。

Instrument Data Pipelines for Key Metrics

首先识别 data pipelines 中的关键阶段，例如 ingestion、transformation、loading，并在这些点实施 metric logging。捕获 freshness timestamps、row counts、error rates、schema snapshots 和 execution durations。这会创建一个 baseline，用于衡量 anomalies。

Automate Data Profiling and Quality Checks

嵌入 automated checks，验证重要 datasets 的 distribution patterns、null percentages 和 categorical consistency。按固定 intervals 调度这些 validations，并在 deviations 发生时标记出来。Thresholds 不仅应反映技术规则，也应反映业务预期。

Establish Centralized Dashboards and Alerts

将 observability signals 汇总到 centralized platform，使 data teams 可以跟踪 system-wide health。实时可视化 anomalies、pipeline statuses、SLA compliance 和 schema changes。当 thresholds 被突破或 anomalies 被检测到时，通过 email、chat 或 incident management tools 设置 alerts。

Define SLAs and Set Alert Thresholds

为每个 dataset 或 pipeline 清晰定义什么是“healthy”。这可能包括：

Data freshness 必须在 24 小时以内。
Critical columns 中的 null values 不得超过 1%。
Pipeline success rate 必须保持在 98% 以上。

建立 alert conditions，当这些 SLAs 面临风险时通知相关团队。

Incorporate Observability into CI/CD

将 data quality checks 和 schema validation 集成到 deployment pipelines 中。这确保任何 code 或 transformation 在进入 production 前，都必须通过基本 observability gates。Breaking changes 会在 lifecycle 更早阶段被捕获，减少 downstream impact。

Connect Observability to Lineage and Metadata

当 observability 与 data lineage 和 metadata catalogs 配合时，它会更强大。如果检测到 anomaly，lineage 可以让团队追踪其 upstream source，并评估 downstream impact。Metadata 则为 data behavior 增加上下文，帮助团队更有意义地解释 signals。

Foster a Data Reliability Mindset

除了 tools 和 dashboards，observability 的成功还取决于文化。鼓励 teams 像对待 software outages 一样严肃对待 data incidents。进行 retrospectives、记录 root causes，并持续优化 monitoring coverage，以弥补检测空白。

Schema Enforcement and Versioning

在现代数据系统中，变化不可避免。Data sources 会演进，business rules 会变化，pipelines 需要适应。然而，如果底层数据结构，也就是 schemas，没有得到恰当治理，这些变化可能引入严重风险。Schema enforcement 和 versioning 正是为解决这一挑战而存在，它们确保结构变化是有意的、兼容的，并且可以贯穿 data lifecycle 被追踪。

这些实践共同保护 downstream systems 的可靠性，防止 silent failures，并为长期 scalability 打下基础。

Schema Enforcement

Schema enforcement 指的是在数据流入 processing 或 storage systems 之前，验证并约束 incoming data 的结构，例如 column names、data types 和 required fields。这相当于 data producers 和 consumers 之间的一份 contract，确保数据符合预期规则。

关键 enforcement rules 包括：

Field Presence：Required columns 必须存在，例如 customer_id、timestamp。

Data Types：Columns 必须具有一致且合法的 data types，例如 integer、date。

Value Constraints：对 ranges、lengths 或 allowed categories 的可选规则，例如 age > 0，status IN ('active', 'inactive')。

Field Ordering or Structure：对 JSON、XML 或 Avro-based schemas 尤其相关。

通过早期 reject 或 quarantine malformed records，schema enforcement 可以防止 downstream breakages，保留 data quality，并减少 data engineering teams 的 debugging overhead。

Common Validation Dimensions

Schema enforcement systems 通常会在多个结构和语义属性上验证数据，包括：

Validation Dimension	Purpose
Field Presence	确保 mandatory fields，例如 `user_id`、`transaction_date`，存在于所有 records 中
Data Type Consistency	确认每个 field 包含正确类型的 values，例如 `price` 是 float，而不是 string
Nullability Enforcement	限制哪些 fields 可以或不可以包含 null values
Field Format Rules	根据预期 formats 验证 fields，例如 ISO date formats、phone numbers
Allowed Value Sets	将 field values 限制在预定义选项中，例如 `status` 是 `'open'`、`'closed'` 之一
Nested Field Structure	适用于 semi-structured data，确保 JSON 或 Avro fields 遵循一致层级

表 10.1：Schema Enforcement 的常见 Validation Dimensions

Enforcement Points within Data Workflows

Schema enforcement 可以根据 system architecture 和 use case，在不同阶段应用：

At the Ingestion Layer：在数据写入 storage 或转发到 downstream processes 之前，根据定义好的 schema 验证摄入数据。这在 streaming platforms 和 data lakes 中很常见，尤其适用于 schema-on-write approaches。Non-compliant records 会被 rejected、logged，或 routed 到单独 quarantine path。

Within Transformation Logic：在 data transformation 期间，无论使用 SQL、Spark 还是 ETL scripts，schema constraints 都会通过 casting、filtering 或 validation checks 显式执行。Typed dataframes 或 dbt 中的数据模型，在 processing 期间执行 structure 很有用。

At the Point of Consumption：Schema-on-read mechanisms 在 query time 验证数据结构，尤其适用于摄入 JSON 或 CSV 等 loosely-typed formats 的系统。这确保 consumers，例如 dashboards 或 ML pipelines，只与 well-structured 和 validated data 交互。

Techniques and Tools for Enforcing Schemas

不同工具和框架提供内置 schema enforcement capabilities：

Typed DataFrames in Spark and Pandas：在 data loading 期间执行 types 和 presence constraints。

SQL Constraints：使用 CHECK、NOT NULL 和 ENUM constraints，在 relational databases 中维护结构。

Schema Definition Languages：Avro、Parquet 和 Protobuf 等 formats 允许显式定义 schemas，并在 data serialization 期间验证。

ETL Platforms and Validators：dbt、Great Expectations 和 custom validation scripts 等工具帮助跨 pipelines 执行业务级 schema rules。

Practical Example：在 Apache Spark 中执行 Schema

from pyspark.sql.types import StructType, StructField, StringType, IntegerType

schema = StructType([
    StructField("customer_id", StringType(), nullable=False),
    StructField("age", IntegerType(), nullable=True),
    StructField("email", StringType(), nullable=True)
])

df = spark.read.schema(schema).json("/data/customers.json")

在这个例子中，pipeline 确保每条 record 都包含 customer_id，并且它是 non-null string，同时 age 和 email 等 optional fields 符合预期类型。违反 schema 的 records 会根据配置触发 exceptions，或被标记为 corrupt。

Schema Versioning

随着 data ecosystems 逐渐成熟，datasets 的结构不可避免地会发生变化：新增 fields、调整 types，以及删除 deprecated attributes。如果管理不当，这些变化可能引入重大风险：broken dashboards、failed model training 或 incompatible API contracts。Schema versioning 提供了一种 disciplined approach 来管理这些结构变化，使 teams 能够安全、系统且透明地演进 data models。

在动态组织中，product features、reporting requirements 和 compliance needs 会快速演进。因此，datasets 的结构必须适应变化。没有 version control 时，即使是很小的变化，例如重命名一个 field，也可能破坏 dozens of downstream systems 的 assumptions。Schema versioning 通过为结构变化引入 explicit control、compatibility checks 和 traceability 来缓解这种风险。

它充当 data platforms 中支持 continuous delivery 的机制，让不同 consumers 能够与不同 schema versions 交互，而不会中断。

Types of Schema Changes and Compatibility Considerations

并非所有 schema changes 的影响都一样。理解哪些 changes 是 backward-compatible、forward-compatible 或 breaking，对有效 versioning 至关重要。

Type of Change	Compatibility	Example
Adding a new nullable field	Backward-compatible	向 customer table 添加 `middle_name`
Changing a field name	Breaking	将 `dob` 重命名为 `date_of_birth`
Changing a field type	Potentially breaking	将 `user_id` 从 string 转换为 integer
Removing a required field	Breaking	从 transaction data 中删除 `account_status`
Reordering fields（in some formats）	May be compatible	在 Avro 或 JSON 中重排 fields 可能不影响
Adding constraints or value checks	Breaking for invalid data	在 SQL 中添加新的 `CHECK` constraint

表 10.2：Schema Changes 类型

Teams 应评估每个 proposed change 的 downstream impact，并应用 semantic versioning principles 来指导安全 deployments。

Approaches to Schema Versioning

Schema versioning strategies 会根据 system design、data format 和 organizational maturity 而变化。常见方法包括：

Tagged Versioning of Schema Definitions：Schemas 使用 labels 显式版本化，例如 v1、v2、v3，并存储在 version control system 或 schema registry 中。每个 pipeline 或 application 都可以引用它被构建时支持的 schema version。

Schema Registries：集中式 repository，常与 Avro、Protobuf 或 JSON Schema 一起使用，存储 schema definitions 以及 version history、compatibility rules 和 evolution policies 等 metadata。Producers 注册 schema changes，consumers 在接受 updates 前验证 compatibility。

Embedded Version Metadata in Data：每条 record 或每个 batch 都在 metadata 中包含 schema version identifier。Consumers 读取 version，并应用相应 parsing logic。这在 event-driven systems 或 data lakes 中尤其有用，因为多个 schema versions 可能共存。

Data Contract Enforcement：Producers 和 consumers 就一份 contract 达成一致，也就是 schema 和 rules，并通过 tools 或 configuration files 维护。任何结构变化都必须经过 contract approval process，通常会在 CI/CD pipeline 中自动化执行。

Practical Example：Versioning Customer Records

想象一个 pipeline，其中 customer data 最初包含三个 fields：customer_id、name 和 signup_date。随着时间推移，业务需要加入 email。

不是直接修改 existing schema，而是引入一个新版本：

// v1 schema
{
"customer_id": "string",
"name": "string",
"signup_date": "date"
}

// v2 schema (backward-compatible)
{
"customer_id": "string",
"name": "string",
"signup_date": "date",
"email": "string"
}

尚未准备好使用 email field 的 consumers，可以继续引用 v1；更新后的 pipelines 则采用 v2。Versioning 避免 surprise failures，并允许 schema changes 以受控方式 rollout。

Duplicate Detection and Data Deduplication

在任何大规模数据系统中，duplicate records 都是不可避免的现实。它们会因为多种原因出现，例如 manual data entry errors、inconsistent integrations、repeated imports 或 system glitches。如果不加控制，duplicates 可能导致 skewed analytics、inflated metrics、machine learning models 的 training data 有缺陷，以及糟糕的 customer experiences。Duplicate detection 和 deduplication strategies 在确保 data pipelines 中的 data integrity、accuracy 和 efficiency 方面发挥关键作用。

Duplicate data 造成的不只是 redundancy；它还会破坏业务决策和运营流程：

Misleading Analytics：Customer registrations、transactions 或 website visits 等 count-based metrics 可能被高估。

Data Quality Degradation：当 duplicates 稀释或误代表真实 entities 时，matching、segmentation 和 personalization workflows 会变得不那么有效。

Resource Inefficiency：由于不必要的数据复制，storage costs 上升，query performance 下降。

Operational Friction：在 CRM 或 financial systems 中，duplicates 可能导致多次 outreach attempts、billing errors 或 fragmented records。

Sources of Duplicates in Data Pipelines

理解 duplication 的常见来源，有助于设计有针对性的预防和检测策略：

Multiple Data Entry Points：多个独立系统捕获同一个 entity，尤其是 customer，但没有 shared identifiers。

Manual Entry Variations：拼写错误、不同命名习惯或不完整输入，例如 “John Smith” 与 “Jon Smyth”。

System Integration Lag：Upstream systems 中的 timing mismatches 导致同一 batch 被部分重新处理。

Lack of Primary Key Enforcement：Database level 缺失或不一致地执行 uniqueness constraints。

Schema Drift：Field naming 或 typing 不一致，例如 customer_id 与 cust_id，阻碍准确 joins 或 matching。

Techniques for Detecting Duplicates

检测 duplicates 需要结合 deterministic 和 probabilistic methods，具体取决于 data quality 和 structure。

Exact Match Detection：基于 key fields 的严格相等来识别 duplicates，例如 customer_id、email、transaction_id。

适合 clean、uniquely keyed datasets 的系统。
快速且高效，但无法捕获 near-duplicates。

Fuzzy Matching and Similarity Scoring：使用 Levenshtein distance、Jaccard similarity 或 cosine similarity 等 distance metrics 比较 textual 或 structured fields。

可以捕获由 typos、formatting inconsistencies 或 casing differences 导致的 near-duplicates。
常用于 customer master data management（MDM）和 record linkage tasks。

Rule-Based Heuristics：应用 business-specific rules，例如基于部分 fields 匹配，尤其是 same phone number and birthdate，或 standardized formats，例如 normalized addresses。

适合 fuzzy logic 本身不足或过于泛化的领域。
需要 domain expertise 来设计有效规则。

Machine Learning and Entity Resolution：利用 classification models 预测两条 records 是否指向同一 entity，使用 field similarity、frequency 或 record patterns 等 features。

对复杂 matching needs 高度灵活且适应性强。
需要 labeled training data 和 feature engineering。

Strategies for Data Deduplication

一旦识别出 duplicates，下一步是在不丢失数据或造成不一致的情况下解决它们。Deduplication 涉及 merge、remove 或 flag redundant records。

Record Merging：将 duplicate records 合并为单一 canonical representation。它也可能涉及 conflict resolution，例如选择最新 address 或合并 field values。

Record Removal：删除 exact 或 near-exact duplicates，通常用于 confident matches 已被发现，且只需要保留一个实例时。

Record Flagging：标记 suspected duplicates 而不移除，以便 human review 或 downstream filtering。

Windowed Deduplication in Streaming Systems：在 real-time pipelines 中，deduplication 通常会在 time-based 或 ID-based windows 内执行，以捕获 replays 或 delayed events。

Example：Deduplicating Customer Records

假设有一个 dataset，其中 customers 通过 name 和 phone number 识别：

Name	Phone	Email
John Smith	1234567890	john@example.com
Jon Smith	1234567890	jon.smith@mail.com
John Smith	1234567890	john.smith@xyz.com

表 10.3：Deduplicating Customer Records

基于 name 的 fuzzy matching 和基于 phone number 的 exact match，可能表明这些 records 指向同一个人。Deduplication rule 可以保留 email 最完整或 latest update timestamp 最新的 record，同时 archive 或 merge 其他 records。

Data Quality Metrics and Monitoring

Data 的价值取决于其可靠性。无论数据平台规模多大、技术多先进，如果支撑决策的数据不准确、不完整或不一致，整个生态都会被削弱。为了确保 high-quality data，组织必须定义、衡量并监控关键 quality indicators。这些 data quality metrics 提供了评估 datasets 健康和可用性的标准化框架，帮助 teams 早期发现问题、优先处理修复事项，并持续改进 data systems。

Metrics 是量化 indicators，用于衡量 dataset 在多大程度上符合预期标准。它们帮助回答关键问题，例如：

数据是否准确且及时？
Required values 是否存在并保持一致？
数据是否值得用于 reporting 和 analysis？

通过将 data quality metrics 嵌入 pipeline，组织可以实时监控 data health，比较不同 sources 或 systems 之间的 quality，并为 quality ownership 建立问责机制。

Core Data Quality Dimensions and Their Metrics

Data quality 的每个维度都反映了一个会影响数据如何被信任和使用的具体属性。以下是最常见的维度及其相关 metrics。

Dimension	Definition	Common Metrics
Accuracy	反映数据是否正确表示其试图建模的真实世界 values	Verified values 百分比；与 trusted source 的 match rate
Completeness	衡量所有 required data 是否存在	Missing values 百分比；field population rate
Consistency	评估 data values 是否跨 systems 或 formats 对齐	Conflicting records 百分比；cross-system match rate
Validity	评估数据是否符合定义 formats、ranges 或 rules	Valid entries 百分比；format compliance rate
Uniqueness	表示是否存在 duplicate records 或 repeated entries	Duplicate keys 数量；unique records 百分比
Timeliness	捕获数据相对于使用时点的当前程度	Data latency；time since last update
Freshness	衡量数据最近一次创建或修改的时间	Timestamp lag；过去 N 天更新的数据百分比
Integrity	指 structural soundness，以及是否遵守定义好的 relationships	Referential integrity violations；orphaned foreign key records
Conformity	检查数据是否遵循 naming standards、units 或 formats	匹配 naming conventions 的 fields 百分比；unit standardization compliance

表 10.4：Data Quality Dimensions

这些 metrics 中的每一个，都提供了观察 data reliability 某个方面的视角。它们共同让 teams 能够诊断 quality degradation 的根因，并随着时间监控改进进展。

Applying Metrics in Practice

Data quality metrics 应定期计算，嵌入 data validation layers，并通过 dashboards 展示给 technical 和 business stakeholders。示例包括：

Accuracy：在 loan disbursement system 中，将记录的 disbursement amounts 与 core banking system 中的金额进行比较，以检测 mismatches。

Completeness：衡量 daily onboarding dataset 中有多少 new customer records 缺少 PAN 或 Aadhaar fields。

Timeliness：检查 yesterday’s transactions 是否按预期在 morning analytics job 前被摄入。

Uniqueness：在 credit bureau data merges 中检测 duplicate voter IDs。

Monitoring Data Quality

定义 data quality metrics 很重要，但只测量一次是不够的。在真实系统中，数据流是连续、动态且日益复杂的。因此，quality 可能逐渐退化，也可能突然失败。Monitoring 会让这些 metrics 活起来，将静态 checks 转化为持续 oversight。它使 data teams 能主动跟踪 data health、实时捕获 anomalies，并在组织内执行 accountability。

Monitoring 将 data quality 从一次性的 profiling task 转变为实时运营职能。目标是自动检测问题、通知相关 stakeholders，并将 quality checks 集成到更广泛的 data observability 和 governance 生态中。

设计良好的 monitoring systems 帮助 teams 回答：

这个 dataset 今天表现是否符合预期？
Null values 或 duplicates 是否突然激增？
Critical fields 是否仍以正确 format 和 frequency 到达？
Data quality 的变化是否与近期 code deployments 或 system updates 相关？

Characteristics of an Effective Monitoring Framework

一个稳健的 data quality monitoring system 应具备以下特征：

Characteristic	Description
Automated and Continuous	按 schedule 或在 new data 到达时实时运行 checks
Threshold-Based Alerting	当 quality metrics 超过预定义 thresholds 时触发 alerts
Granular and Context-Aware	理解 data domains、field importance 和 business relevance
Role-Specific Views	为 engineers、analysts 和 business users 提供定制化 insights
Actionable Outputs	与 ticketing systems、logs 或 dashboards 集成，以启动响应

表 10.5：Monitoring Framework 的特征

Integration Points across the Data Lifecycle

Data quality monitoring 可以嵌入多个阶段：

At Ingestion

在数据落入 data lakes 或 warehouses 时，验证 structural conformity 和 completeness。

监控来自 APIs、Kafka streams 或 batch files 的 freshness 和 record volume。

During Transformation

检查 joins、aggregations 和 enrichments 的准确性。

跟踪 transformation 后的 row counts 和 data type changes。

At Consumption Layers

如果 dashboards 由过时或不完整的 tables 驱动，则发出 alert。

监控关键 reporting tables 的 schema changes 或 broken relationships。

Tools and Approaches for Scalable Monitoring

组织会组合使用工具和实践来实施 monitoring：

Data Quality Frameworks：Great Expectations、Deequ 和 Soda 等工具扫描 datasets，并验证 custom expectations。

Metric Stores and Observability Platforms：Prometheus、Grafana 或 OpenTelemetry 等平台可以适配 data systems，用于跟踪 performance 和 anomalies。

Pipeline Orchestration Systems：与 Airflow 或 Dagster 等工具集成，使 job execution 期间能早期发现 failures。

Custom Dashboards and Alerts：通过 BI tools 或 monitoring dashboards 中的定制化界面，将 anomalies 暴露给正确的 stakeholders。

因此，通过建立清晰 metrics，并在整个 data lifecycle 中嵌入 continuous monitoring，组织可以从 reactive firefighting 转向 proactive data governance。这些实践不仅保护 data products 的可靠性，也会在 teams 和 stakeholders 之间建立信任。当 data quality 变得可衡量、可监控且可管理时，它就会从隐藏风险转变为战略资产。

结论

本章探索了维护高质量、可信赖 data pipelines 的核心支柱。我们从 data validation、anomaly detection 和 error handling 的基础开始，这些实践确保 incorrect 或 incomplete data 在造成 downstream issues 前被早期捕获。随后，我们考察了 data lineage 和 observability，它们为数据如何跨 systems 移动和表现带来 transparency 与 real-time monitoring。

我们还覆盖了 schema enforcement 和 versioning，使数据结构可以随时间保持一致并安全演进。随后是 duplicate detection 和 deduplication 技术，它们帮助在 record-level data 中保持 uniqueness 和 accuracy。最后，我们建立了 data quality metrics 和 monitoring 如何让 teams 持续衡量、跟踪并改进 datasets 的可靠性。

这些实践共同构成了在现代数据环境中运营化 data quality 的完整策略。

下一章中，我们将把重点转向 Data Governance and Compliance。我们将逐步探索组织如何通过 role-based access control、masking 和 encryption，以及遵守 GDPR、HIPAA 和 CCPA 等关键监管框架来保护数据。我们还将覆盖 metadata management、data cataloging，以及 audit logging 和 provenance tracking 的重要性。这些实践对于在当今以数据为中心的世界中保护敏感数据、确保伦理使用并履行法律义务至关重要。