測試數據輸送機

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）結果

數據流水線測試是系統學科，不是一組不同的檢查。將測試金字塔、合同和可觀察性與相容性、電路演變和流不變量的實踐相結合。然後發布將變得快速，事件是罕見和短暫的，對數據的信任是可持續的。