数据质量、对账与数据湖测试

• 数据质量六维度
• 可执行规则
• 落地实现

六维度落地为可执行规则，每个维度定义 SQL 检测规则。完整性：关键字段非空率、行数是否缺失（如 count(where col is null) 应=0 或低于阈值）。唯一性：主键唯一（count(distinct key) = count(*)）。及时性：数据新鲜度/延迟（如最新分区时间与当前时间差小于阈值）。有效性：字段格式、范围、枚举有效（如金额>0、日期格式合法）。准确性：与基准/期望值比对（对账、校验值在合理范围）。一致性：跨表/跨口径一致（同名指标结果一致）。规则以 SQL 或配置形式定义，由质量平台定时执行，产出检测结果（通过/违规）、触发告警。每条规则包含：维度、检测表达式、阈值、作用表/字段、严重度。通过规则库管理与阈值调优，实现可配置、可复现的质量检测。

六维度是数据质量的框架，落地为可执行规则才能持续监控。把抽象维度转成具体 SQL 检测表达式与阈值，由平台执行，能让质量检测可量化、可自动化、可跟踪。

• 批流一体
• 实时与离线对账
• 对账设计

批流一体中实时链路与离线链路对同一业务计算，结果可能因时间窗口、口径、延迟不同而有差异。对账设计：设定统一口径（统计周期、去重规则、指标定义），对同一时间窗口分别从实时链路与离线链路取结果（行数、金额、去重指标），进行比对。对账策略：T+0 准实时对账（实时链路结果与离线当日结果比对，容忍短暂延迟）与 T+1 全量对账（离线全量结果与实时累计结果比对）。误差容忍：定义允许误差（如金额差 < 0.1%、行数差 < 阈值），对超出误差的差异告警定位。设计要点：统一时间口径（防时区/秒级错位）、统一去重口径、固定比对窗口、差异明细可下钻。对账结果用于发现实时链路的数据丢失、重复或口径不一致。

批流对账是保障"实时数据可信"的关键。核心是统一口径与设计误差容忍，否则实时与离线天然差异会误报。T+0 与 T+1 结合，既能快速感知又能全量核对，差异可下钻定位。

• 告警分级
• 修复闭环
• 与血缘联动

告警分级：按严重度（P0/P1/P2，如关键交易数据错误、SLA 超时、一般质量下降）分级，不同级别触发不同响应（阻断发布、告警通知、仅记录）。修复闭环：告警→定位→修复→验证→关闭，形成闭环。与血缘联动：质量事故发生时，通过血缘定位问题表的上游依赖（找到根因数据源）与受影响的下游（下游影响范围），快速圈定事故影响面；修复后通过血缘验证下游受影响表是否需要重刷。响应流程：告警触发→血缘分析定位根因与影响→评估严重度分级→阻断/放行决策→修复上游→按血缘重刷下游→质量验证→关闭事故。血缘联动让响应从"点"扩展到"链"，精准高效。

告警分级让响应有优先级，修复闭环保证问题闭环，血缘联动让定位与影响评估精准。三者结合形成完整的数据质量事故响应体系，避免孤立处理。

• 数据湖 ACID 特性
• 并发写入
• 时间旅行与回滚

数据湖 ACID 测试验证三个特性。并发写入：多个任务并发写同一表，验证乐观锁/冲突检测正确，无脏写、无覆盖丢失，按快照隔离保证一致性；测试并发写冲突时，后提交者失败或重试，数据不损坏。时间旅行（time travel）：按历史快照版本查询，验证能读取任意时间点的数据快照，历史数据不被变更破坏。回滚：通过回滚到指定快照版本，验证数据恢复到该版本状态，后续写入被撤销。测试方法：构造并发写入场景并发起，验证结果一致；写入多个版本后按版本查询与回滚，断言快照正确。配合 ACID 的一致性（读已提交、不出现部分写入）验证。

数据湖 ACID 让湖上数据具备事务性。并发写入保证一致性，时间旅行保证可追溯，回滚保证可恢复。测试验证这些特性，能防止并发写损坏数据、历史丢失，是数据湖可靠性的关键。

• 质量规则即代码
• Great Expectations
• dbt test

"质量规则即代码"把数据质量规则作为代码版本管理，随代码审查、CI 执行。Great Expectations：用 Expectation（如 expect_column_values_to_not_be_null、expect_column_values_to_be_between）定义数据质量套件，用数据源校验并生成 Data Docs 报告，支持批流数据校验。dbt test：在 dbt 模型中定义 schema.yml 的测试（not_null、unique、accepted_values、自定义 tests），配合 dbt test 命令执行，作为 CI 的一部分。实现方式：规则（expectation/test）写入代码库，版本管理；CI 中自动执行校验，失败时阻断发布或告警；规则变更走代码审查。这样质量规则可追溯、可复用、可回归，与数据管道集成。

质量规则即代码让规则像代码一样管理（版本、审查、CI）。Great Expectations 与 dbt test 将规则声明化，自动执行并出报告，实现质量检测的工程化与持续化。

• 埋点数据质量
• 字段缺失率与重复上报
• 采样偏差

埋点数据质量测试覆盖三类指标。字段缺失率：监控关键字段（如用户 ID、事件 ID、时间戳）的缺失率，超过阈值（如 5%）告警，验证埋点字段完整性。重复上报：检测重复事件（同一事件 ID 多次上报），通过去重统计重复率，验证埋点去重逻辑与重复上报治理。采样偏差：埋点采样（如按比例采样）导致样本与总体偏差，验证采样比例正确、样本分布（按平台、版本、地区）与总体一致，无系统性偏差。监控方式：建立埋点质量规则，定时执行（缺失率、重复率、采样一致性的 SQL 检测），纳入质量监控平台。测试断言：埋点数据符合质量阈值，异常时告警定位。

埋点数据是分析的基础，其质量直接影响分析结论。字段缺失、重复、采样偏差会扭曲统计。监控这三类指标能保证埋点数据可信、可分析。

• 对账机制类型
• 适用场景
• 代价

三种对账机制各有适用场景与代价。行数对账：对比源目标行数，开销小、速度快，能发现明显的丢数/重复，但无法发现字段级错误，适用于高频快速对账。金额汇总对账：对比关键指标（金额 sum、count、去重）的汇总，能发现聚合口径错误，开销中等，适用于金额/指标类核心数据。抽样比对：对样本数据做全字段比对，能发现字段级差异，但只覆盖抽样部分，可能漏掉未抽中的错误；全量比对精度最高但开销最大（全量 join 对比）。选择策略：行数+金额对账做快速基准，全量/抽样比对做深度校验；按数据重要性选择对账深度（重要数据全量、次要抽样）。代价与覆盖率权衡：全量最准最贵，抽样快但可能漏测。

对账机制的本质是"覆盖率与代价的权衡"。行数/金额快速低成本，抽样/全量深度高成本。按数据重要性与变更风险选择对账深度，能兼顾效率与质量。

• 湖仓一体
• 同步延迟
• 重复与丢失验证

湖仓一体中数据湖与数仓同步，需验证同步一致性。同步延迟：监控数据湖到数仓的同步延迟（数据产生到数仓可用的时间），验证满足 SLA（如 T+1 内完成），延迟超阈值告警。重复验证：对比同一数据在湖与仓中的主键，验证数仓无重复（未因同步重复写入）。丢失验证：对比湖与仓的行数、主键集合，验证数仓无丢失（湖中数据都同步到仓）。验证方法：对同一时间窗口的数据，在湖与仓分别统计行数、主键、字段，做对账；用唯一主键差集找出丢失/重复；监控同步任务的进度与延迟。同步链路（增量抽取、CDC）的断点续传也需验证，确保同步不丢不重。

湖仓同步的一致性决定数据湖与数仓的可用性。延迟 SLA、重复与丢失是同步质量的核心。通过对账 + 延迟监控 + 主键差集，能验证同步正确、无丢失无重复。

• Schema 演进
• 列/类型/分区变化
• 历史读取与下游消费

Schema 演进测试验证列与分区变更的影响。列新增：新增列后，验证历史数据读取时新列默认值正确、旧数据不报错、下游消费兼容。列删除：删除列后，验证历史数据仍可读、下游不引用已删列。类型变更：列类型变更（如 int→long、string→json）后，验证历史数据能正确读取与转换，不报错、不丢失精度。分区结构变化：分区字段/分区布局变化后，验证历史分区可读、新分区正确、查询能兼容新旧分区。验证方法：对演进前后的表做查询，读取旧快照与新数据，断言结果正确；用下游消费（查询、报表）验证兼容性。Schema 演进要保证向后兼容（旧数据可读）与向前兼容（新 schema 可写）。

Schema 演进是数据湖的常见需求，演进不当会导致历史数据不可读或下游崩溃。测试验证列/类型/分区变更对历史读取与下游的影响，保证演进兼容、数据可用。

• 小文件合并
• 查询性能与并发冲突
• 压缩失败回滚

小文件合并（compaction）测试验证其效果与风险。查询性能：对比合并前后查询耗时，验证合并减少小文件后查询性能提升（扫描文件数减少、元数据压力下降）。并发写入冲突：压缩任务与并发写入同一表时，验证乐观锁/冲突检测正确，压缩不覆盖并发写入的新数据、不产生冲突导致的脏数据。压缩失败回滚：压缩任务失败时，验证能回滚到压缩前状态，数据不损坏、不丢失，通过快照/版本机制恢复。验证方法：构造大量小文件，执行压缩，对比性能与文件数；并发写与压缩同时进行，验证一致性；注入压缩失败，断言回滚正确。压缩后数据完整性（行数、内容）也需验证。

压缩是数据湖的治理手段，但引入并发冲突与失败风险。测试验证压缩提升性能、不破坏并发写一致性、失败能安全回滚，保证压缩治理的可靠性。

• 脱敏规则
• 不可逆性
• 业务可用性与一致性

脱敏测试验证两个目标：不可逆与业务可用。不可逆性：验证脱敏算法（哈希、掩码、替换、随机化）无法还原原始数据，如哈希加盐、掩码不可逆；测试脱敏后无法通过反推得到原值。业务可用性：验证脱敏后数据仍可用于业务（类型、格式、分布、关联关系保持），如手机号脱敏后仍可区分、关联键脱敏后仍可 join；金额/日期脱敏后仍可计算。一致性：同一字段多次脱敏结果稳定（确定性脱敏），且脱敏不破坏业务逻辑（如对外 join 的关联性）。测试覆盖不同脱敏类型（不可逆哈希、可逆加密区分）、不同敏感字段（身份证、手机号、金额）、边界值。断言脱敏算法正确、不可逆、业务可用。

脱敏要在"安全"与"可用"间平衡。不可逆保证隐私安全，业务可用保证数据价值。测试验证两者并兼顾一致性，确保脱敏既安全又可用。

• 实时 vs 离线对账
• T+0 与 T+1 机制
• 误差容忍

实时对账（T+0）与离线对账（T+1）机制不同。T+0 准实时核对：实时链路数据与准实时数据（当日分批）比对，及时发现数据问题，但数据可能未完全落齐，存在短暂延迟，需容忍较大的误差（如允许行数因迟到数据差异）。T+1 全量核对：离线链路全量数据与实时链路累计结果比对，数据完整、口径稳定，误差应当很小，用于精确对账。差异点：T+0 快但误差大（数据不完整），T+1 慢但准确（数据完整）。误差容忍设计：T+0 容忍"进行中"的差异（迟到数据、未落齐），T+1 要求严格一致（仅容忍浮点/口径误差）。机制上 T+0 做快速感知、T+1 做精确核对，两者结合。

实时与离线对账本质是"时效 vs 准确"的权衡。T+0 快速感知但需容忍数据未落齐，T+1 精确但滞后。理解差异并设计误差容忍，能避免误报与漏报。

• 误报治理
• 阈值调优
• 告警去重与回归

误报治理降低无效告警。阈值调优：基于历史数据分布设定合理阈值，避免阈值过紧（误报）或过松（漏报）；用历史数据的正常波动范围确定阈值，并持续验证。告警去重：对同一问题/同一表/同一根因的重复告警去重合并，避免告警风暴；通过聚合规则（按表、按时间、按根因）合并，只保留关键告警。回归验证：对历史告警做回归，评估阈值调整后是否仍能正确捕获真实问题、不误报不漏报；建立告警基线，验证阈值变化导致的正误报变化。方法：用标注的"真实问题"样本集，评估规则精确率/召回率，调优阈值使两者平衡。

误报治理提高告警可信度。阈值调优靠历史分布与样本评估，告警去重减少噪音，回归验证保证调优不引入漏报。三者为质量监控"放得出、放得准"。

• 数据新鲜度
• 同步延迟 SLA
• 度量方法

数据新鲜度监控度量数据湖与数仓同步延迟。度量指标：数据产生时间（事件时间）到数据在湖/仓可用时间（处理时间）的差值，即同步延迟；也可用最新数据分区时间与当前时间的差（数据新鲜度）。SLA 度量：为不同表/数据源定义 SLA（如 T+1 内完成、关键表 1 小时内可用），监控同步延迟是否达标。实现：记录每个数据分区/数据集的写入完成时间戳，与数据产生时间比对，计算延迟；延迟超过 SLA 阈值触发告警。对实时链路（Kafka 到湖/仓）度量端到端延迟，对离线链路度量调度完成时间。监控覆盖同步任务进度、延迟分布（p50/p95）与 SLA 达成率，异常时告警定位。

数据新鲜度是湖仓可用性的关键 SLA。通过度量同步延迟与 SLA 达标，能及时发现数据滞后、提前暴露分析时效问题。延迟分布与达成率监控让新鲜度可量化、可管理。

• 职责划分
• 规则建设与监控运维
• 发布验证协同

数据质量团队与测试团队职责分工但协同。数据质量团队：负责数据质量规则建设（六维度规则、口径、阈值）、监控运维（告警、误报治理、事故响应）、质量基线与 SLA 管理。测试团队：负责数据管道与任务的功能/性能测试、发布验证（新任务上线前验证）、回归测试。协同点：质量规则作为测试的验收标准（测试验证规则正确）；测试团队发现的规则问题反馈质量团队完善；发布验证时，质量团队提供质量规则与基线，测试团队验证新发布任务满足质量要求；质量事故由质量团队定位、测试团队验证修复。建立共享的规则库与告警平台，两个团队在其上协同，避免重复与冲突。

分工明确避免职责重叠，协同保证质量闭环。质量团队管"规则与监控"，测试团队管"发布与验证"，通过共享规则库与流程协同，实现数据质量与发布质量的双重保障。

• 对账失败处置
• 告警与阻断
• 自动重跑与人工复核

对账失败的自动化处置流程分级设计。告警：对账失败先触发告警，通知相关方，记录失败明细。阻断发布：对关键对账失败（如 P0 数据错误）阻断依赖该数据的发布，防止错误数据扩散。自动重跑：对可由重跑恢复的失败（如瞬时故障、调度延迟）自动重跑，重跑后重新对账，验证是否恢复。人工复核：对无法自动解决或需判定的失败（如口径差异、数据缺失）进入人工复核，由人工决策（修复、放行、标记）。流程设计：对账失败→分级（可自动重跑 vs 需人工）→自动重跑或人工复核→验证→关闭。配置处置策略（按对账项、严重度、失败类型），形成"自动为主、人工兜底"的闭环，减少人工干预同时保证安全。

对账失败处置要兼顾效率与安全。告警、阻断、自动重跑自动化处理常规失败，人工复核兜底复杂问题。分级处置让流程高效可靠，避免盲目全自动或全人工。

• 数据质量基线
• 历史分布
• 阈值与异常判定

建立数据质量基线需基于历史数据分布。步骤：采集历史数据（足够周期，如 30/90 天）的指标分布（行数、缺失率、金额、分区数等），计算均值、标准差、分位数（p5/p95/p99）。设定阈值：基于分布设定正常范围（如均值±3σ 或 p5~p95），超出范围判定异常；对波动型指标用同比/环比偏差（如当日比昨日变化超阈值）。异常判定：结合统计（Z-score、分位数）与业务规则（固定阈值、突发检测），区分"正常波动"与"真异常"。基线需随数据变化周期更新（如节假日、活动影响），并人工校准。测试验证：用历史数据评估阈值，验证能捕获真实异常且不误报；用标注样本评估精确率/召回率。

静态阈值常误报，基于历史分布的动态基线与统计判定更准确。通过分位数、标准差与业务规则结合，能区分正常波动与异常，并持续校准基线。

• 数据血缘应用
• 上游依赖定位
• 下游影响圈定

数据血缘在质量事故定位中快速圈定上下游。上游定位：问题表出现质量问题时，通过血缘回溯其上游依赖（源表、算子、任务），定位根因数据源与脏数据来源；沿血缘向上逐层排查，找到最先出问题的环节。下游影响：通过血缘向前推导，找出依赖问题表的所有下游表与应用，圈定受影响范围（哪些报表、指标、任务受影响），评估影响面。快速圈定：血缘关系预构建（SQL 解析、元数据血缘），事故发生时按图查询上下游，生成影响明细（受影响表、任务、负责人）。结合血缘联动，精准修复与针对性重刷下游，避免全量重刷。

血缘是事故定位的"地图"。向上找根因、向下找影响，让定位从"点"变"链"，快速、精准。预构建血缘 + 按图查询，是质量事故响应效率的关键。

• 口径差异
• 差异识别
• 差异解决

源系统与目标系统对同一指标口径不同（如含税/不含税、去重规则、统计周期）会导致对账差异。识别：对账差异时，先排查是否为口径差异而非数据 bug——对比两边的口径定义（含税、去重键、时间口径、过滤条件），通过差异模式（如固定比例差、金额差=税费）识别口径因素。解决：建立统一的"口径映射"（源口径→目标口径的换算规则），对账时按映射归一化后再比对；对已知口径差异，在差异明细中标注原因（如"差异=税费"），避免误报；对口径不一致的指标，建立口径字典明确定义，推动源系统与目标系统统一。测试：构造口径差异场景，验证对账能识别、归一化并正确解释差异，而非误报为数据错误。

口径差异是"假异常"的常见来源。识别口径差异（相比数据 bug）与建立口径映射归一化，能避免误报。治理口径差异需统一口径字典并推动收敛，是长期工作。