ETL/ELT過程

1）目的和上下文

ETL/ELT流水線為報告（GGR/NGR，調節器），分析/ML和操作面板提供可預測的加載，轉換和發布數據。

ETL：在DWH/Lakehouse中轉換為下載（在現代堆棧中較少見）。
ELT：首先裝載到Lakehouse （Bronze/Silver）,然後使用SQL/引擎進行轉換（推薦）。

2）參考體系結構

1.Ingest/Edge：HTTP/gRPC/Batch，OLTP的CDC，上載S3/FTP提供商。
2.青銅（raw, append-only）：不變的付費,按日期/市場/tenant分期付款。
3.Silver （clean/conform）：正常化、演繹、參考、SCD、FX/時間段。
4.黃金（serve）： BI/調節/模型下的非正規店面。
5.編排：Airflow/Dagster/Prefect（DAG'i，SLA，retrai，移位）。

6.DQ/Contracts: Schema Registry + DQ-как-код, consumer-driven tests.

7.可觀察性：piplines，lineage，logi，cost-dashbords的度量。

3）選擇ETL vs ELT

標準	ETL	ELT（建議）
重新計算的靈活性	低點	高級（時間旅行、重新提供）
成本	身材更高	縮放時是最佳的
質量控制	在ingest上	在Silver/Gold+DQ代碼上
歷史性/forenzics	有限的	完整（Bronze append-only）

練習：在iGaming-ELT+CDC中：快速裝載，然後標準化並計算。

4）Increments和CDC

三角洲的方法：

CDC （Debezium/log復制）：將OLTP →青銅→ MERGE更改為Silver。
Watermark按時間：'updated_at> max_loaded_ts'。
Hash-diff：比較更改檢測器的「md5 （row）」。
Upsert/MERGE：下載的平均值。

MERGE示例（Delta/Iceberg）：

sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5）合同和計劃

Schema-first：Registry中的JSON/Avro/Protobuf；事件/文件中的「schema_version」。
演變：可匹配（不可分割的添加）；破解-「/v2」+雙重記錄。
必填字段：'event_time （UTC）'、'event_id'、'trace_id'、'user_pseudo_id'、'market'。

6） DQ編碼（最低設置）

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: unique_tx # uniqueness of transactions type: unique columns: [transaction_id]
severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
severity: major
- name: amount_positive type: range column: amount_base min: 0. 01 severity: critical
- name: fk_user type: foreign_key column: user_pseudo_id ref_table: dim. users_scd severity: critical

7）樂團： DAG'i，成癮，SLA

DAG設計：從源頭到櫥窗；任務之間的顯式依賴關系。
Retrai和等效性：backoff，「幹凈」的重復，checkpoint's。
移位（catchup）：錯過時間的整齊的追趕。
SLA：例如，黃金。每日準備到當地時間06：00；違規警報。
參數化：市場/tenant/日期通過 vars；一個單一的工作模式。

8）異位性和異位性

在ingest上：可以通過「（→，source）」來event_id重復。
在處理中：upsert/merge；「純」變換函數。
在sink中：事務性公文或idempotent寫作；「雙重核算」控制。
Outbox/Inbox：從OLTP對域事件進行事務性發布。

9) Backfill и reprocessing

Backfill：主要填充/歷史範圍。
Reprocessing：在邏輯/修補程序更改時重新計算。
Guardrails：範圍限制，配額，時間窗口，dry-run與度量比較。
標記：「logic_version」，「reprocessed_at」，「recalc_reason」。

10）Silver/Gold建模

Silver（3NF/BCNF）：事實'fact_bets/payments/payouts'，測量'dim_users/games/providers/markets（SCD II）'，貨幣標準化/時間區。
黃金：BI/調節/模型下的非正規店面；不可更改的出口包（WORM）+簽名。

黃金示例： GGR日報

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

11）隱私和居留權

PII最小化：令牌化；在隔離電路中模仿真實的ID。
RLS/CLS：角色/司法管轄區的訪問策略，掩蓋。
住宅：EEA/UK/BR的單獨目錄/密鑰；無故禁止跨區域合作。
DSAR/RTBF&Legal Hold：選擇性編輯、報告WORM存檔、出口審核。

12）可觀察性和SLO

SLI/SLO基準：

Freshness Silver p95 ≤ 15分鐘；黃金日報準備到06：00 lock。時間。
Completeness ≥ 99.5%，Validity（方案）≥ 99。9%.
Job 's的成功率≥ 99。0%，MTTR事件≤ 24-48小時。

Dashbords：Freshness heatmap，DQ損失漏鬥，成本/查詢和成本/GB，線性圖。

13）生產力和成本

參與：日期/市場/特南特；通過過濾器聚類/Z順序。
格式：Parquet+ACID（Delta/Iceberg/Hudi），壓縮和統計。
復合：與小文件作鬥爭（OPTIMIZE/VACUUM）。
實物化：穩定單元；避免巨型飛躍。
Chargeback：預算，反沖配額/反沖配額；調度到低負載窗口。

14）典型的DAG任務示例（Airflow偽代碼）

python with DAG("elt_payments_daily", schedule="@daily", start_date=..., catchup=True) as dag:
extract = BashOperator(task_id="extract_cdc", bash_command="run_cdc_to_bronze. sh {{ ds }}")
load  = BashOperator(task_id="load_to_silver", bash_command="sql/run_merge_silver. sql {{ ds }}")
dq   = BashOperator(task_id="dq_checks", bash_command="dq/run_checks. sh silver. payments {{ ds }}")
gold  = BashOperator(task_id="build_gold_ggr", bash_command="sql/build_gold_ggr. sql {{ ds }}")
export = BashOperator(task_id="export_regulator", bash_command="export/run_worm_pack. sh {{ ds }}")

extract >> load >> dq >> gold >> export

15）流程和RACI

R（響應）：數據工程（DAG'i，Silver/Gold模型），數據平臺（infra，Registry，DQ）。

A (Accountable): Head of Data/CDO.

C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).

I （Informed）： BI/產品/營銷/運營。

16）實施路線圖

MVP（3-5周）：

1.湖畔青銅/銀色（ACID）+Payments/Gameplay的CDC/鑲嵌物。

2.DQ編碼（10-15個規則）和基本的Freshness/Completeness dashbords。

3.第一個金色展示（GGR Daily）帶有SLA「直到06：00」，帶有簽名的WORM導出。

4.在SLA/DQ上編排DAG和Alerta。

第二階段（5-10周）：

域擴展，users/games/providers的SCD II。
語義層度量；線性/影響分析；backfill/reprocessing過程。
區域化（EEA/UK），RLS/CLS，成本控制（配額/滯後）。

第三階段（10至16周）：

重復模擬器（what-if），自動生成店面/度量文檔。
成本優化（聚類，實現，TTL，復合）。
DR演習和時間旅行恢復。

17）售前支票清單

Registry中的合同/計劃，兼容性測試為綠色。
CDC/increments和MERGE是冪等的；在ingest上的惡作劇。
DQ規則是活動的（critical → fail+DLQ）, SLA-dashbords是自定義的。
金色店面已記錄下來，語義層中的度量公式。
RBAC/ABAC,加密,駐留,DSAR/RTBF/Legal Hold驗證。
合並/OPTIMIZE/VACUUM時間表；backfill/replay限制。
Runbook'以及事件和重新設計，出口審計（WORM+hash）。

18）反模式和風險

「以防萬一」：使用CDC/increments。
原始數據和報告數據的混合：將Bronze/Silver/Gold分開。
缺少DQ和線性：沒有可證明和可重復性。
分析層中的PII：隔離面膜，應用CLS/RLS。
整體的「夜間」喬巴：粉碎，分批並行。
忽略成本：註意小型文件,實現聚合,輸入配額。

19）詞匯表（簡短）

ETL/ELT-提取/轉化/下載（下載前/下載後）。
CDC-捕獲更改。
SCD-測量歷史化（I/II/III）。
WORM-報告包的不可更改存儲。
時間旅行-閱讀表格的歷史版本。

20）結果

現代ETL/ELT不是腳本，而是可管理的平臺：合同和DQ，等效嵌合/CDC，青銅/銀/金層學科，可觀察性和SLO，隱私性和經濟性。按照本指南，您將獲得可復制和可審核的輸送機，這些輸送機始終如一地為報告，產品和模型提供大規模且沒有驚喜。

ETL/ELT過程

與我們聯繫

快速聯繫

影片即將更新

我們目前正忙於各項專案