数据质量与验证

• 五个质量维度的定义区分
• 各维度对应的验证手法
• 数据质量规则的落地方式

数据质量五维度的测试方法：完整性——校验必填字段非空、无 NULL、无缺失记录，用 NOT NULL 约束统计与 COUNT 比对记录数；准确性——校验数据值与真实业务值一致，比对源与目标、系统与人工预期的值，用抽样或规则（如金额范围、日期格式）验证；一致性——校验同一业务实体在不同表/系统间取值一致，跨表比对、跨系统对账；时效性——校验数据及时更新，比对数据时间戳与当前时间、SLA 时延，检测过期数据；唯一性——校验主键、业务唯一键无重复，用 GROUP BY HAVING COUNT>1 检测重复。测试方法可落地为 SQL 校验查询、质量规则引擎（如 Great Expectations）或对账脚本，统计数据质量报告。

五个维度回答了"数据是否齐全、正确、一致、及时、唯一"五个问题，是数据质量测试的通用框架。测试时把每个维度转化为可执行的校验规则，量化出通过率，才能持续度量与改进。

• 数据质量框架的期望与断言机制
• 在 ETL 各阶段嵌入验证的位置
• 失败处理与 CI 集成

在 ETL 管道中嵌入数据验证，核心是"在关键节点断言数据符合期望"。Great Expectations：定义 Expectation（如 expect_column_values_to_not_be_null、expect_column_values_to_be_between、expect_table_row_count_to_be_between），用 Validator 对数据源执行验证，生成 Data Docs 报告，返回通过的 expectation 数；可嵌入批处理在抽取、转换、加载后各跑一次。dbt tests：在模型上定义 unique、not_null、accepted_values、relationships 等 schema test，或自定义 singlar/unit test，dbt test 在 build 后执行，失败即中断。验证点通常放在：源数据接入后（探查）、转换后（业务规则）、加载目标后（完整性）。失败处理：质量门禁失败时阻断发布或告警，quality gate 通过率不达标则报警。CI 中把框架作为流水线任务，输出报告与统计。

这类框架把"期望"声明化，让数据验证从手写 SQL 变成可维护、可复现、可报告的规则集。嵌入 ETL 的关键点位、失败即阻断（或告警），才能把数据质量问题挡在业务使用之前。

• 数据血缘的概念与表达
• 通过血缘确定变更影响范围
• 血缘驱动的测试范围选择

数据血缘描述数据从源到目标（表、字段、任务、报表）的流动关系，形成"上游到下游"的依赖图。测试应用：当上游表/字段/逻辑变更时，用血缘追踪出所有直接与间接依赖的下游表、视图、报表、指标，确定回归测试范围，避免遗漏影响面。做法：血缘信息来自元数据管理平台（如 DataHub、Amundsen）或 SQL 解析（解析 ETL 中的 SELECT/INSERT 关系），测试时按血缘图做"变更影响分析"，对受影响的下游数据重新执行校验与对账。血缘还能辅助定位问题根因——下游数据异常时顺链向上定位是哪个上游变更导致。血缘驱动的测试侧重"变更后影响哪些下游"，优先测试受影响链路，兼顾全链路冒烟。

数据血缘的价值在于把"变更影响"从凭经验判断变成有据可依的依赖图。测试借此确定回归范围、定位根因，是数据治理与测试结合的关键能力。

• 数据漂移的度量指标
• 分布变化的监控手段
• 触发回归测试的机制

数据漂移检测是持续监控数据分布（均值、方差、分位数、分类占比、空值率等）随时间的变化。基础做法：定时跑统计 SQL 计算关键指标，与历史基线（如过去 7/30 天）对比，用相对偏差、PSI（Population Stability Index，用于分类分布）、Kullback-Leibler 散度等量化变化。当漂移超过阈值时告警，并触发回归测试：对受影响的数据管道、报表、模型重新跑校验与对账，确认漂移是否导致业务规则或模型失效。触发机制可做成：漂移告警 → 自动触发 CI 中相关 Job 的回归 → 输出报告。测试要区分"数据本身合理变化"与"数据质量问题"，避免误报，需结合阈值、历史上下文与业务规则判断。

数据漂移是"数据变了但仍可能正常"的灰度信号。监控分布 + 阈值告警 + 触发回归，把"数据变化"转化为"可验证的测试动作"，重点在于用统计指标量化漂移、用阈值控制误报。

• 脱敏的不可逆与不可识别
• 统计分布保真的验证
• 业务可用性的验证

数据脱敏验证需同时满足"安全性"与"可用性"两个维度。安全性：脱敏后无法还原原始数据（不可逆性）、无法通过脱敏值反推敏感信息（如姓名、手机号、身份证）、脱敏规则一致（同一标识脱敏结果一致）；用检测脚本验证脱敏字段中不含原始样本、无关联推断风险。可用性（分布保真）：脱敏后数据的统计分布（均值、方差、分位数、分类占比、取值区间）与原数据基本一致，才能用于测试与开发；做法是脱敏前记录原始分布，脱敏后跑统计对比，断言偏差在容忍范围内。业务可用性：外键关系、唯一约束、格式约束在脱敏后仍成立，测试/开发环境能正常跑通业务。对保留型（format-preserving）脱敏需验证保形与分布。

脱敏是安全与可用性的平衡。测试既要确认"敏感信息不可还原"，又要确认"统计特征与业务可用性不破坏"——只有分布保真、关系完整，脱敏数据才能放心用于测试。

• 完整性、一致性、准确性的区分
• 各维度的验证手段
• 与业务规则结合

三个核心维度分别验证不同层面。数据完整性（约束）：验证主键、唯一、外键、CHECK、NOT NULL 等约束正确执行，非法数据被拒绝、合法数据通过，这是"结构层面"的保证。一致性（事务）：验证 ACID，尤其是并发下隔离级别、事务回滚、死锁处理，保证并发操作后数据仍一致，这是"事务层面"的保证。准确性（业务规则）：验证业务口径下的计算、状态流转、金额规则正确，如库存扣减、折扣计算、状态校验，这是"语义层面"的保证。三者需配合：完整性保证"数据合法"，一致性保证"并发正确"，准确性保证"业务正确"。测试时分别用约束用例、并发用例、业务规则用例覆盖，并组合验证。

完整性、一致性、准确性回答了"数据是否合法、并发是否安全、结果是否对"三个问题。三者维度不同，测试方法不同，但都围绕"数据库数据可信"展开，理解其区分才能设计全面覆盖。

• SQL 注入用例的构造与验证
• 权限越权测试
• 敏感数据脱敏验证

SQL 注入测试：对所有拼接 SQL 的输入点（查询参数、排序字段、用户输入）构造注入载荷，如 ' OR '1'='1、'; DROP TABLE users;--、注释与 UNION 注入，断言使用参数化查询（PreparedStatement/ORM 参数绑定）后注入被当作字面量处理、不产生非预期结果；用静态扫描（如 Checkmarx、Semgrep）查找字符串拼接 SQL 的代码。权限越权测试：按角色/用户构造访问，验证水平越权（访问他人数据，如 id=123 改写他人记录）与垂直越权（普通用户访问管理接口）被拒绝，配合 RBAC 权限断言。敏感数据脱敏：验证接口返回与日志中不泄露手机号、身份证、密码等，脱敏规则生效（掩码、加密），且脱敏后的数据不可还原。测试可用自动化安全扫描工具（OWASP ZAP、SQLMap）结合手工用例。

安全测试的要点是"攻击者视角"。SQL 注入验证参数化是否可靠、越权验证权限边界是否真实、脱敏验证敏感信息是否真正被保护，三者共同保障数据安全。

• 分层抽样的原理与实施
• 样本量与置信度计算
• 抽样评估的适用边界

当全量比对成本过高时，用分层抽样在不同层（如按业务类型、时间区间、地区、数据量级）内随机抽样，保证各层代表性，避免抽样偏差。样本量由置信度与可接受误差决定：用公式 n = Z²·p·(1-p)/E²（Z 为置信水平对应分位数，p 为预期质量缺陷率，E 为允许误差）计算最小样本量，例如 95% 置信度（Z=1.96）、假设缺陷率 2%、误差 1% 时需约 753 条。抽样后用统计推断整体质量，并给出置信区间；对高风险层（关键表、核心字段）可提高抽样比例或全量。分层抽样适合"只评估整体质量水平"的场景，但对"逐条精确比对"仍不够，需结合校验和采样后进行全量比对。

抽样的价值是用可控成本估计整体质量，核心是"分层控偏差、样本量定置信"。理解样本量公式与分层的思想，才能在不做全量比对时给出有统计依据的质量结论。

• 三类根因的区分方法
• 根因定位的排查路径
• 问题闭环管理

区分三类根因需按"数据流"逐层排查。ETL 逻辑问题：ETL 代码本身有 bug（转换错误、JOIN 错误、去重不当），特征是源数据正常但目标数据错；可通过对比源与目标的映射、重跑 ETL、检查脚本日志定位。源数据异常：源系统本身数据有问题（脏数据、缺失、异常值），特征是源头已错，目标只是"如实传递"；需回溯源系统核对。口径变更：业务口径变了（统计定义、时区、货币单位、过滤条件），特征是需要重新定义计算逻辑、数据历史口径与现状不一致；需对比业务需求与实现。定位手段：血缘追踪上游、比对源与目标抽样、检查告警与变更记录。闭环：记录问题、分出根因类别、指派修复（改 ETL / 通报源系统 / 改口径）、发新版本、重跑验证、更新质量规则防复发。

数据质量问题根因多元，盲目改代码会掩盖真问题。按"源数据→ETL→口径"逐层排查，再用闭环流程（定位→修复→验证→防复发）治理，才能系统性解决。

• 常用统计检测方法
• 自动识别异常的规则设计
• 小样本误报控制

统计方法用于自动识别数据质量异常：均值方差漂移——比较当前窗口的均值/方差与历史基线，偏差超阈值即异常；Z-score——z = (x - μ)/σ，当某值离均值超过 3σ 视为离群点，适合检测单点异常；分位数规则——用 IQR（四分位距）或指定分位数（如 P5/P95）界定正常范围，超出即异常，对非正态分布更稳健。自动识别需结合业务上下文设置阈值，避免一刀切。小样本误报控制：样本过小时均值/方差估计不稳定、3σ 规则易误报；对策是延长观测窗口、用中位数/分位数替代均值、混合多窗口（短窗口触发 + 长窗口确认）、设置最小样本量门槛、结合分类/计数占比而非仅数值。对突发但合理的数据变化（如大促）需加白名单或季节性调整。

统计方法的核心是把"数据异常"变成可计算的偏差。小样本误报是最大陷阱，因为小样本下统计量本身不稳定，需用稳健统计量、多窗口确认与最小样本门槛来抑制误报。

• 质量报告的分层呈现
• 规则违反的自动派单
• 跟踪整改与闭环验证

数据质量报告分层呈现：面向不同角色给不同粒度——高层（管理层）看整体质量分数、趋势、关键指标达标率；中层（数据负责人）看按数据域/表/维度的质量明细；执行层（工程师）看具体到规则、字段、样本的违规详情。规则违反自动派单：质量检查任务发现违规后，按规则绑定的负责人/数据域自动生成工单（接入 Jira/TAPD 等），附上违规详情、样本、影响范围。跟踪整改：工单指派后跟踪状态（待处理→处理中→已修复），设定优先级与 SLA。闭环验证：修复后重新运行同一质量规则，确认通过率达标、无复发，才关闭工单；同时把本次根因沉淀为防复发规则，纳入质量问题库。整体形成"发现→派单→整改→复验→防复发"的闭环。

治理闭环的关键是"每个质量问题都有责任方、有跟进、有验证、有沉淀"。分层报告让不同角色各取所需，自动派单 + 复验闭环让质量规则不流于形式，真正落地。

• 事件驱动同步的最终一致性
• 延迟与乱序下的验证
• 对账与断言方法

微服务间通过事件（如 Kafka、RocketMQ）同步数据，最终一致性测试需验证：事件生产与消费——一个服务写库并发布事件，另一个服务消费后更新自己的数据，最终两端一致。验证方法：先写入源数据，触发事件，等待消费完成（轮询或等待 offset 追平），再对源与目标做对账，断言最终一致；考虑事件延迟、乱序、重复消费、消费失败重试，验证系统能通过幂等消费与补偿机制收敛到一致。用测试事件总线（如嵌入式 Kafka、Testcontainers Kafka）模拟真实队列，构造延迟与重复场景。还需验证"最终"时限——在可接受时间内达成一致，超时则告警。对账脚本定期比对源与目标，检测不一致并触发补偿。

最终一致性是"以时间换一致性"，测试的关键是验证系统"最终收敛"，而非"瞬时一致"。测试要覆盖延迟、乱序、重复、失败重试等使其收敛的因素，用对账断言最终一致。

• Schema-on-Read 与 Schema-on-Write 的差异
• 数据湖数据质量保障手段
• 验证与监控方式

数据湖采用 Schema-on-Read（读取时定义 schema），原始数据可先入湖、读时再解析，因此数据质量保障比传统仓库更复杂。保障手段：入湖时做"准入校验"（元数据、文件格式、校验和、分区合理性），对原始数据先做轻量检查（非空、格式、大小）再入湖；读取/分析时用模式校验（如 Databricks、Glue 读取时 schema 推断）验证字段类型与约束；对派生层（curated/refined 层）建立更严格的质量规则。用数据质量框架（Great Expectations）对湖内各层执行期望校验，监控空值率、异常值、分区缺失、重复记录。还需验证冷热路径（批处理 + 流式）数据一致，schema 演进（新增字段、字段类型变更）下旧数据仍可读。

Schema-on-Read 把质量责任从"写入时"转移到了"读取与使用时"，因此保障策略是"入湖轻检查 + 读时强校验 + 派生层严格规则"。理解了这一点，才能设计适配数据湖的质量体系。

• 全量与增量迁移的比对策略
• 丢失与重复的检测方法
• 校验和与对账机制

全量迁移比对：迁移前对源表做基线（记录数、主键集合、校验和），迁移后对目标做同样的统计，比对总数、主键集合、逐行校验和（如对每行字段做哈希聚合）一致，无丢失、无重复、无错位。增量迁移比对：用递增列（时间戳/自增 ID）或日志捕获（CDC）定位增量，比对增量区间内的记录数、主键、校验和，并验证断点续传与追平（源与目标最终一致）。丢失检测：用主键集合差集（MINUS/EXCEPT）找出源有目标无的记录；重复检测：用 GROUP BY 主键 HAVING COUNT>1 找出目标重复。对账脚本定期比对，检测不一致告警。测试还需覆盖迁移中断、重试、并发写入、延迟场景。

迁移比对的核心是"用可还原的锚点（主键、校验和、计数）验证源与目标等价"。全量比对主键与校验和、增量比对增量区间，配合丢失/重复查询，能系统发现迁移缺陷。

• 索引失效场景的构造
• 慢查询数据构造
• 锁等待场景构造与验证

构造场景数据：索引失效——对索引列加函数或隐式类型转换（如 WHERE DATE(created_at)=...、WHERE char_col=123）、LIKE '%x'、OR 条件，使索引不可用；用 EXPLAIN 验证 type=ALL、key=null。慢查询——构造大数据量（几十万到百万行）配合未索引列查询、深度分页（LIMIT 大偏移）、多表 JOIN 无索引，实际测量耗时超阈值。锁等待——多个并发事务更新同一行/同一区间，加长事务保持时间，用 SHOW PROCESSLIST、performance_schema 观察 state 为 Waiting for lock、锁等待时间与超时，构造不同隔离级别下锁表现。验证方法：EXPLAIN 执行计划、慢查询日志、锁等待统计、性能指标（耗时、吞吐）。数据构造需用脚本化批量生成（存储过程、程序批量插入），保证场景可复现。

性能场景的验证依赖"数据量 + 查询形态"的组合。构造能触发索引失效、慢查询、锁竞争的确定数据，用 EXPLAIN 与监控指标佐证，才能把隐性问题量化成可回归的测试。

• 质量门禁的规则与指标
• 关键表覆盖策略
• 阈值配置与告警机制

CI 中的数据质量门禁设计需明确"什么算通过"。规则通过率：定义质量检查的总通过率门槛（如 99%），低于门槛则阻断构建/发布；对关键规则（主键唯一、必填非空）可设 100% 强制通过。关键表覆盖：识别核心表（订单、用户、库存等）与核心字段，配置为强制覆盖，非关键表允许部分覆盖或告警不阻断。告警阈值：分出"阻断"与"告警"两级——低于红线阈值（如通过率 <98%）阻断，介于黄线阈值（如 98%~99.5%）告警但不阻断；关键表不达标直接阻断。配置可通过质量规则文件（如 dbt tests、Great Expectations 的 suite）随代码版本管理，CI 中执行检查并输出报告，按阈值分级处理。门禁需可配置化，避免频繁误阻断。

门禁设计是"质量要求"与"交付效率"的平衡。用分级阈值（阻断/告警）+ 关键表强制覆盖 + 版本化规则，既守住质量底线又不因非关键问题阻塞发布。

• 主从延迟的监控
• 双写一致性的对账
• 对账脚本的持续化机制

跨库一致性需持续监控。主从延迟监控：定期读取从库的 show slave status 的 Seconds_Behind_Master 或对比主从的 GTID/位点，监控延迟是否超过阈值；对数据可用性，抽查从库读取到主库最新数据的时间差。双写一致性对账：当两个库分别写入同一业务数据时，用对账脚本定期比对两侧对应的表，比较记录数、主键集合、校验和（逐行哈希），找出不一致记录并告警；对账脚本可接入定时任务（Cron、调度平台）或事件触发，持续运行。对账需处理时间窗口（两侧写入可能有时差），用"业务时间窗口 + 幂等重对账"避免误报；发现不一致后触发补偿或通知人工处理。监控指标接入告警平台，超阈值自动告警。

跨库一致性的核心是"持续对账 + 延迟监控"。主从监控关注"读到的数据是否新鲜"，双写对账关注"两侧数据是否一致"，两者都要持续化、可告警、可补偿，才能保证跨库数据可信。

• 元数据驱动质量规则的原理
• 自动生成规则的手段
• 规则与元数据的一致性维护

元数据驱动质量规则：数据目录（如 DataHub、Atlas、Amundsen）中记录的字段定义、数据类型、是否必填、是否是主键、枚举取值范围、业务含义，可直接转化为质量规则。例如字段类型为数值 → 生成范围/非空规则；枚举字段 → 生成 accepted_values 规则；必填字段 → 生成 not_null 规则；主键 → 生成 unique 规则；有外键关系 → 生成引用完整性规则。新表字段自动生成：当新表/新字段注册到数据目录时，根据其元数据模板自动生成对应的质量规则（如 Great Expectations 的 suite 或 dbt 的 schema test 文件），无需手工编写。规则与元数据需联动维护：元数据变更（字段类型、枚举变更）时自动更新规则，防止规则过时。可用"元数据 + 规则模板"的映射引擎，把目录元数据渲染成可执行的质量规则。

元数据是质量规则的"事实来源"，把字段定义、枚举、约束自动映射为规则，让质量规则随元数据自动生成与维护，避免手工编写导致的遗漏与过时，是数据治理自动化的重要方向。