分析和ETL流水線

（部分： 技術和基礎設施）

簡短摘要

分析流水線將iGaming的「原始」操作事件（投註，存款，PSP webhooks，遊戲邏輯）轉換為穩定的指標展示（GGR/NGR，LTV，重組，反欺詐信號）。基準：單層模型（Bronze/Silver/Gold），DQ/線性工具學科，增量和冪等，可觀察性和SLO，成本控制。決策考慮了負載配置文件（錦標賽高峰），監管性（PII/本地化）以及企業對數據新鮮度的要求。

1）體系結構： ETL vs ELT, batch vs stream

ETL （Extract → Transform → Load）：轉換為DWH。適用於需要在「雲」之前控制環境/秘密的轉換。
ELT （Extract → Load → Transform）： Lake/Lakehouse/DWH的原材料,以下是SQL/引擎 （dbt/SQL腳本）。適用於柱式引擎和靈活的叠代。
Batch：計劃窗口（每5/15/60分鐘，夜間）。便宜且可預測。
Stream: почти real-time (Kafka → Flink/ksqlDB → OLAP).用於近實時（5-60秒）陳列櫃和防凍劑/CRM信號。
混合動力車：青銅充滿了串流，Silver/Gold是增量擊球模型。

建議：在iGaming中保持ELT+流媒體：通過CDC/outbox → Bronze（分鐘新鮮度）的活動,在Silver/Gold中進行增量轉換。

2）分層模型（Medallion）

青銅（Raw）： 原始事件/CDC沒有業務邏輯。Parquet/ORC格式，原樣模式，最小驗證。
Silver（匹配）：清洗、重復數據消除、ID歸一化、SCD測量、貨幣/時區統一。
黃金（Marts）：商業展示（事實/測量,立方體）,材料化觀點,預聚會（天/國家/產品）。

優點：可重復性、透明進化、不同層的SLO和TTL。

3）來源和裝載： CDC, outbox,文件

CDC （Change Data Capture）：來自OLTP （Postgres/MySQL）的更改流,具有順序和等效性保證。
Outbox模式：事件記錄在服務事務的outbox表/集合中→連接器發布到總線/湖泊。
文件下載：PSP卸載，合作夥伴報告；使用清單，雙重控制（checksum）和接收目錄。

實踐：對每個來源的資源進行驗證（計劃版本）,對每個來源進行現場合同和質量期望。

4）管弦樂隊： DAG，成癮，deploy

DAGi：顯式依賴關系（raw → staging → dims → facts → marts）。
任務的相等性：重新啟動而不會產生副作用（partition-overwrite，「MERGE」/upsert）。
環境分離：Dev/Stage/Prod，人工制品促銷活動，「手動門」（manual approval），用於昂貴的背景。
計劃：cron/時間窗口+事件觸發器（按文件/批次到來）。
秘密：來自秘密經理；禁止DAG代碼中的秘密。

python with DAG("dwh_daily", schedule="0  ") as dag:
bronze = ingest_cdc(source="payments", partition=hour())
silver = dedup_normalize(input=bronze)
dims  = build_dimensions(input=silver)
facts = build_facts(input=silver, dims=dims)
marts = build_marts(input=facts)
bronze >> silver >> [dims, facts] >> marts

5）數據質量（DQ）和線性

DQ支票：完整性（計數，後期武器），密鑰唯一性，範圍/域規則（總和≥ 0，參考書中的貨幣）。
觸發閾值：硬停止/軟失效,根據表的關鍵性而定。
線性/目錄：從復制到源（表、列、度量標準）,所有者,文檔,PII分類。
電路控制：自動兼容性測試（backward -/forward-compatible），alert to「打破」更改。

6）建模： SCD，surrogate鍵，正常化

測量SCD2： 「valid_from/valid_to/is_current」、surrogate key （'_sk'）和natural key （'_id'）。
SCD1：覆蓋非必要屬性（例如接口區域）。
Surrogate keys：穩定的'_sk' for join, natural keys for獨特。
測量標準化：在層次結構深度較深的地方snowflake；換句話說，星星是為了速度。

7）增量模型和分組

水印（「updated_at」,「ingest_ts」）：僅讀取新/更改的行。
增量策略：業務密鑰上的「MERGE」，批次上的「INSERT OVERWRITE」，小批次的「DELETE+INSERT」。
參與：按日期/小時/地區分列；聚類（sort keys/Z-order）通過過濾和加入密鑰。
實例化視圖：GGR/NGR預聚合,流行截面的緩存。
Approx裝置：便宜的top-N店面HLL/approx_distinct。

sql
MERGE INTO fact_deposits f
USING staging_deposits s
ON (f. deposit_id = s. deposit_id)
WHEN MATCHED THEN UPDATE SET amount = s. amount, status = s. status, updated_at = s. updated_at
WHEN NOT MATCHED THEN INSERT (...)
VALUES (...);

8）Backfill，重建和歷史管理

Backfill：具有資源限制和窗口的單個DAGi；明確的「真相之窗」（例如2024-01-01..2025-11-05）。
重構：確定性變換→重復運行產生相同的結果。編譯模型代碼版本。
時間旅行/表版本：方便調查和DR「邏輯錯誤」。
Retraction：具有協議的數據反饋（刪除/修復）策略。

9） CLO/SLA/SLO輸送機

新鮮（freshness）： Bronze ≤ 1-5分鐘,Silver ≤ 15分鐘,Gold ≤ 60分鐘（示例）。

可靠性： DAG ≥ 99成功運行百分比。x%.

性能：節點持續時間p95/p99；每黨的時間預算。
Lag監視：ingest流積壓，隊列深度，「late data」份額。
Alerts：新鮮/體積中斷,DQ fails,掃描成本上升,MV降解。

10）成本： 預測和優化

聚會和集群將掃描量最小化。
熱標記的實現（天/國家/產品）。
常用行車記錄板的結果緩存/MVs。
控制重新啟動的頻率（沒有「每5分鐘」沒有理由）。
TTL：青銅的激進重構，中銀色，長金（僅單位）。
能力規劃：目錄指標，比賽/活動高峰預測。

11）安全、PII和本地化

數據分類：PII/財務/運營。
加密：靜止和過境；KMS/基於角色的訪問。
標識：散列/掩碼,單獨的鍵列。
RLS/vyuhi用於多影子（通過「tenant_id」）。
本地化：按區域劃分的儲存和處理區（歐盟/TR/LATAM）；僅導出到允許的位置。
審核：讀取/寫入關鍵表,訪問目錄。

12）可觀察性： 度量，標誌，步道

流水線度量：任務持續時間、隊列、錯誤、轉發、處理字節/行量、成本。
Logs：結構化；「trace_id」/「run_id」上的相關性。
Tracing：從源到店面（ingest → transform → load → BI）。
Dashbords：層的新鮮度，DAG的成功，最昂貴的查詢，p95/p99。

13）工具（角色參考）

編排：DAG編排器（帶有調度器，後臺，警報器，秘密）。
轉換：SQL建模（「模型作為代碼」），單位模型測試，文檔。
DQ/合同：檢查框架和數據集的SLA。
線性/目錄：自動生成約束圖,搜索所有者。
流媒體：窗口/聚合處理器,sink/source連接器。

（根據公司的堆棧和安全要求選擇特定的供應商。）

14）模式示例

GGR店面模板（廣義SQL）

sql
CREATE OR REPLACE TABLE mart_ggr_daily AS
SELECT
DATE(b. ts) AS d,
c. country_code,
SUM(b. stake) AS stake_sum,
SUM(b. win)  AS win_sum,
SUM(b. stake - b. win) AS ggr
FROM fact_bets b
JOIN dim_country c ON c. country_sk = b. country_sk AND c. is_current
WHERE b. ts >= DATE_SUB(CURRENT_DATE, INTERVAL 60 DAY)
GROUP BY d, c. country_code;

帶有「水印」的增量模型"

sql
INSERT INTO fact_bets PARTITION (dt)
SELECT
FROM staging_bets
WHERE updated_at > (SELECT COALESCE(MAX(watermark), '1970-01-01') FROM _meta_watermarks WHERE table='fact_bets');
-- then update watermark

DQ檢查（想法）

sql
-- 1) key uniqueness
SELECT deposit_id FROM fact_deposits GROUP BY deposit_id HAVING COUNT()>1;

-- 2) negative amounts (error)
SELECT FROM fact_deposits WHERE amount < 0;

15）實施支票

1.定義指標字典（GGR/NGR/LTV/Retention）和所有者。
2.在Bronze/Silver/Gold層中記錄SLO的新鮮度。
3.標準化來源合同（方案、DQ、SLA）。
4.構造DAG圖，具有相等的步驟和孤立的秘密。
5.實現增量（按批次排列的MERGE/overwrite）和「水印」。
6.啟用DQ（關鍵/軟檢查）、lineage和數據目錄。
7.配置可觀察性（度量、日誌、跟蹤）和Alerta。
8.鍵入轉發/TTL和backfill/轉發策略。
9.提供PII控制、加密、RLS和本地化。
10.進行遊戲日：模擬源的下降，「打破」電路，質量回火。

16）反模式

「每人一晚ETL」，沒有分期付款和增量。
缺少DQ和lineage →矛盾的報告和「捉鬼敢死隊」。
每次啟動時完全重新設計表（成本爆炸）。
實時硬韌帶，無緩沖區/後退。
將PII和公共展示櫃混合在一起，無需細分或掩蓋。
沒有撤回/刪除策略（無法糾正錯誤）。

結果

iGaming中的可持續分析管道是ELT+流式下載到具有剛性DQ/線性，增量模型，透明編排器和可測量SLO的分層模型中。添加成本控制、PII/本地化策略、定期的背景調查/DR演習-您的分析平臺將可靠地擴展到錦標賽高峰,為企業提供所需的新鮮度和質量數據。