测试数据输送机

1）为什么要测试数据输送机

• 有效性（correctness）和稳定性（resilience）。
• 更改的可预测性（计划/逻辑演变）。
• 遵守SLO的新鲜度，完整度，潜伏期。
• 通过自动验证快速发布（发布速度）。

2）数据测试金字塔

自下而上：很多快速的本地测试→较少的集成→有点端到端。

1.单位转换测试（函数，UDF，SQL-vid，dbt模型）。
2.数据质量测试（新鲜/完整/唯一性/范围规则）。
3.合同和计划（计划/合同测试，演变）。
4.Pipline集成测试（DAG：ingest storage transform marts）。
5.E2E测试（从源到店面/API），包括权利（RLS/CLS）和导出。
6.负载/性能（体积、速度、成本服务）。
7.数据溷沌测试（延迟、重复、订单外、不可用）。

3）测试类型： 我们到底要检查什么

3.1单一逻辑测试

纯变换函数；基于property（不变式：等效性，单调性）。
SQL/DBT：将结果与基准（金集）进行比较，禁止"SELECT"，按时间检查过滤器。

3.2数据质量测试（DQ）

新鲜：店面延迟≤目标阈值。
完整性：预期人数/占用率。
唯一性：无重复密钥。
域规则：范围，指数完整性，业务不变性。
异常：出路，重复爆发，时间间隔。

3.3合同和计划

更改兼容性（SemVer：MAJOR/MINOR/PATCH）。
具有强制性专栏，类型，限制。
固定的KPI语义：公式和聚合窗口。

3.4集成和E2E

DAG完整性：触发器，依赖性，等效重播。

完整路径： 来源→ raw → curated → arts → BI/API；RLS/CLS.

3.5性能和成本

p95/p99 jobs潜伏期,throughput （rows/s）,体积/成本。
性能回归测试和扫描限制。

3.6安全和隐私

PII/PCI掩蔽（确定性令牌化）。
RLS/CLS验证：用户只看到自己的。
出口/快照：没有"原始"个人字段。

4）流媒体细节（Kafka/Flink/Spark Structured Streaming）

Watermarks and lateness：测试后期事件（T+Δ）,正确重新计算。
意义上的Exactly-once："event_id"，等效记录（upsert/merge）。
顺序外：通过"event_time"对聚合进行不变式；捕获"ingested_at"。
丢失/重播：模拟掉落/重播，测试店面的正确性。

5）相似性和确定性（如何测试）

重新启动步骤会产生相同的结果（使用相同的窗口选项）。
记录-通过迭加和原子交换。
Merge逻辑SCD1/SCD2包含冲突测试（最后的写作-胜利，源优先性）。
UDF/聚合确定性：相同的输入→相同的输出。

6）测试数据管理

Golden datasets：手动验证的小基准。
合成+数据工厂：覆盖域边缘（nulls, extreme values, Unicode, TZ）。
已确定的prod samples：隐私合规性。
分层伪造品：原始事件，中间层，最终展示柜。

7）数据合同： 示例和规则

yaml dataset: orders schema:
- name: order_id; type: string; unique: true
- name: user_id; type: string; not_null: true
- name: amount; type: decimal(18,2); min: 0
- name: event_time; type: timestamp; tz: UTC freshness_sla: 10m dq_rules:
- "pct_null(user_id) < 0. 1%"
- "duplicates(order_id) = 0"
- "sum(amount) >= 0"
evolution:
allowed_minor_additions: true breaking_changes_require: approval: 'data-governance'
actions_on_violation:
- quarantine_partition
- replay_last_60m

8）SLO的可观察性和测试

出口指标：Freshness，Completeness，Uniqueness，Latency到Grafana/Prometheus。
SLO-alerta作为销售中的"红色"单位测试（合成）。
回归报告："X p95发布后↑ 40%"。

9） CI/CD和环境

CI：unit+DQ+PR合同；schema-diff;静态SQL （linter）分析。
沙箱/堆迭：运行集成和e2e,溷沌测试安全数据。
功能标记：金丝雀乔巴/模型/公式。
编目：方案版本，KPI公式，线性；自动更新文档。

10）混沌数据测试（混沌数据）

注入重复/遗漏、延迟、订单外。
经纪人/批次下降，"bit"文件，计划漂移。
验证：自动维修（replay/backfill），quarantine和alerta，MTTR数据。

11）负载和成本

具有p95/piki配置文件的流量生成器。
Scan/Step限制（bytes scanned, time caps）。
A/B价值分析仪："旧"vs"新"模型/查询。

12）工具（近似类）

DQ/合同：dbt测试，Great Expectations，Deeug，Soda，Custom linters。
编排：Airflow/Dagster/Argo/Prefect（每个步骤的测试操作员）。
平台：BigQuery/Snowflake/Redshift/ClickHouse/Delta/Iceberg/Hudi。
流媒体：Kafka，Flink，Spark Streaming；用于本地环境的TestContainers。
Observability: Prometheus/Grafana/Otel;DataHub/Amundsen/Collibra目录。

13）反模式

"没有什么可测试的-只是SQL"：没有units和DQ →指标被打破。
只有E2E：缓慢，不稳定，故障的原因尚不清楚。
SELECT：在MINOR演化中崩溃。
在测试中实时阅读OLTP：不稳定性和长笛。
缺少黄金套件：没有什么可比较的结果。
没有相容性测试：重新启动会破坏数据。
被遗忘的流媒体：没有测试lateness/out-of-order/重新交付。

14）实施路线图

1.基础：转换的统一测试，金集，linter SQL，DQ规则top-10店面。
2.合同：在CI, SemVer, schema-diff,自动兼容性检查。
3.集成：DAG测试,idempotency, e2e用于关键线程。
4.流媒体：watermarks/lateness, dedup/idempotent sinks测试。
5.SLO和混乱：销售质量指标，Alerta，混沌场景，MTTR目标。
6.优化：perf回归，预算警卫，金丝雀发行。

15）发行前的支票清单

• Unit测试涵盖了关键转换和UDF。
• 新鲜/完整/唯一性/范围的DQ规则通过。
• 合同和计划绿色；没有变形就没有变化。
• 异位性已得到验证；atomic sink/merge工作。
• 流媒体：供水商/长期数据/订单覆盖；到位。
• 显示SLO度量；配置了Alertes；runbooks是。
• 测试数据是安全的；PII被伪装；RLS/CLS已验证。
• 没有Perf回归；已达到扫描限制/时间限制。
• 基础场景混沌测试已通过；MTTR目标是可以实现的。

16）迷你模板示例

16.1 Unit SQL测试（pseudo-dbt）：

sql
-- tests/assert_positive_amount. sql select count() as c from {{ ref('fct_payments') }}
where amount < 0 having c = 0

16.2新鲜度规则（Great Expectations Style）：

yaml expect_table_row_count_to_be_between:
min_value: 1000 mostly: 0. 99 expect_column_values_to_not_be_null:
column: user_id expect_column_values_to_be_unique:
column: txn_id

16.3在流中检查lateness（伪代码）：

python emit(events_out_of_window <= threshold)
emit(reprocessed_events == late_events_detected)

16.4 Contract-test (schema-diff CI):

bash schema-diff --current models/orders. yml --target prod_schema. yml --semver

17）结果

数据流水线测试是系统学科，不是一组不同的检查。将测试金字塔、合同和可观察性与相容性、电路演变和流不变量的实践相结合。然后发布将变得快速，事件是罕见和短暂的，对数据的信任是可持续的。