數據正常化

1）任命

正常化消除了重復和異常的更新，設置了單個參考書和密鑰，使數據保持一致且便宜。在iGaming中，這對GGR/NGR，AML/RG分析，監管報告，防凍劑和ML至關重要。

2）我們歸一化的地方

Bronze （raw）：我們不能正常化-forenzics的存儲原樣（只有append-only）。
Silver （clean/conform）：基本規範化（3NF/BCNF、參考、密鑰、SCD）。
Gold （serve）：目標店面-可以進行有管理的非正規化閱讀/BI。

3）基本原則

1.Schema-first：所有表均具有顯式圖和鍵。
2.單個ID是：'user_pseudo_id'，'session_id'，'game_id'，'provider_id'，'transaction_id'。
3.統一目錄：貨幣，市場/轄區，KYC/RG狀態，遊戲提供商，流量渠道。
4.時間和貨幣：存儲「event_time」（UTC）和標準化的「amount_base」+「fx_source」。
5.進化：語義版本，只有不帶有「祈禱」間隔的兼容更改。
6.PII最小化：用戶-通過偽ID；mapping是單獨存儲的，訪問受到限制。

4）正常形式快速

1NF：原子值，列中沒有數組（數組→兒童表）。
2NF：屬性取決於整個復合密鑰。
3NF：沒有傳遞依賴項（屬性僅取決於密鑰）。
BCNF：每個行列式都是關鍵。適用於「內核」（payments/gameplay）。

練習：銀支付模式和遊戲活動保持最低3NF；更嚴格的BCNF-用於參考書和參考表。

5）參考域模型（Silver）

5.1個目錄

`dim.users'（偽ID，國家，年齡範圍，RG狀態）。
`dim.遊戲（game_id，provider_id，類型，RTP，波動）。
`dim.提供者（provider_id、類型、許可證）。
`dim.markets'（管轄區代碼、監管機構）。

`dim.fx_rates` (date, ccy_from, ccy_to, rate, fx_source).

5.2事實（狹窄的事件/事務表）

`fact.payments` (transaction_id, user_pseudo_id, amount_orig, currency, amount_base, market, event_time, psp_ref, method).

`fact.bets` (bet_id, user_pseudo_id, game_id, stake_base, stake_ccy, outcome, event_time).

`fact.payouts` (payout_id, user_pseudo_id, game_id, amount_base, event_time).

聯系：關於穩定鑰匙的事實↔指南。所有金額均以「原始貨幣」和「基本貨幣」（amount_base)，記錄「fx_source」。

6）緩慢變化的測量（SCD）

I型（重寫）：拼寫/非關鍵修補程序。
Type II（歷史記錄）：「valid_from/valid_to/is_current」,審核更改（例如RG狀態更改）。
Type III（備用列）：「之前/之後」用於簡短的比較。

建議：針對RG/KYC/營銷渠道-SCD II；對於遊戲指南（RTP）-具有影響驗證的SCD II。

sql
CREATE TABLE dim. users_scd (
user_pseudo_id STRING,
country STRING,
rg_status STRING,
valid_from TIMESTAMP,
valid_to  TIMESTAMP,
is_current BOOLEAN
);

7）重復數據消除和密鑰

內部鏈接的代理密鑰（BIGINT/UUID）。
自然鍵（例如PSP的「transaction_id」）-分別驗證和存儲。
在Silver的業務密鑰上，在ingest+上通過「（event_id，source）」進行演繹。

sql
CREATE TABLE silver. payments AS
SELECT EXCEPT(rn) FROM (
SELECT p., ROW_NUMBER() OVER (PARTITION BY transaction_id ORDER BY event_time) rn
FROM bronze. payment_events p
)
WHERE rn = 1;

8）貨幣標準化與時差

「event_time」-始終為UTC；對於店面，我們添加了市場/時區。
貨幣：「amount_orig」和「amount_base」（例如EUR）+「fx_source」，「fx_rate_used」。
每日課程固定：'dim。fx_rates'源和哈希簽名。

sql
SELECT t. transaction_id,
t. amount_orig,
t. currency,
r. rate AS fx_rate_used,
t. amount_orig r. rate AS amount_base
FROM bronze. payment_events t
JOIN dim. fx_rates r
ON r. date = DATE(t. event_time) AND r. ccy_from = t. currency AND r. ccy_to = 'EUR';

9）參考書的一致性

統一目錄目錄（遊戲，提供者，市場，貨幣）。
DQ驗證器：「in_set」，FK引用，唯一性，SCD一致性。
來自外部來源（遊戲提供商，國家/地區，PSP）的「精細」dimension的自我發生。

10）何時去規範化

• 穩定的「廣泛」報告（GGR，風險展示）；
• 加速BI 查詢/dashbords；
• 在SLA閱讀下的realtime店面（ClickHouse/Pinot）。

• 真理的來源仍然是銀。
• 非歸一化字段-從Silver計算/復制；邏輯轉換。
• 任何非正規化都被記錄下來並測試為正確。

11）「星星」和「雪花」模型"

明星：一個事實+平面測量-更容易和更快地閱讀，更昂貴的寫入/匹配。
雪花：測量標準化（連接目錄下）-重復較少,更難查詢。

建議：黃金更常見的是「明星」，銀色更常見的是正常化的「雪花」。

12）方案的演變（安全變化）

背對背兼容：添加不可分割的專欄；新的標誌參考值。
破解：重命名/類型修改/語義轉移-僅通過「/v2」和遷移期間的雙重記錄。
合同：JSON/Avro計劃註冊，消費者兼容性測試。

13）用於正常化的DQ控制

• 鍵的唯一性是：「transaction_id」，「bet_id」。
• 參考完整性：FK在「dim」上。
• 貨幣：whitelist的「currency」，「fx_rate_used」不是NULL，「amount_base>=0」。
• 時間：智能窗口中的「event_time」；沒有「未來」事件。
• SCD正確：非相交範圍「valid_from/valid_to」。

14） SQL模型示例

sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);

sql
CREATE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
m. 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. markets m ON m. code = b. market
JOIN dim. games g  ON g. game_id = b. game_id
GROUP BY 1,2,3;

15）隱私和合規性

將用戶別名化為Silver；與實際ID的關聯-在單獨的受保護環路中。
RLS/CLS和字段掩碼（分析中沒有電子郵件/PAN）。
目錄/密鑰區域化，DPO控制以擴展電路。

16）可觀察性和線性

Bronze → Silver → Gold的數據線，轉換版本和合同。
度量標準：完全無效,validity, FK錯誤,重復,時間漏洞,請求成本。
當參考書和FX來源中斷時的Alerts。

17) RACI

R：數據工程（Silver/Gold模型），數據平臺（電路寄存器，DQ）。

A: Head of Data/Architecture.

C: Compliance/DPO (PII/retention), Finance (FX/GGR), Risk (RG/AML).

I： BI/產品/營銷/運營。

18）實施路線圖

1.參考目錄（市場，貨幣，提供者，遊戲）。

2.銀模型的事實。payments`, `fact.bets"，"dim。"（3NF），SCD II代表'dim。users`.

3.貨幣正常化/時區，基本DQ規則（FK/uniqueness/in_set)。

4.第一個黃金展示櫃（GGR Daily）和焊接測試。

• SCD擴展，遊戲事件覆蓋，提供者保形模型。
• 圖形兼容性自動測試，遷移模擬器，元數據目錄。
• 按鍵/批次優化，聚類/Z順序。

• 黃金，SLA/成本的非正規化政策；「星星/雪花」節奏。
• 自動生成文檔，行列中的線性圖。
• 區域目錄和加密密鑰，DR演習。

19）質量檢查表

• 單一密鑰和手冊已獲得批準。
• Silver in 3NF，SCD應用於「慢速」測量。
• 貨幣/時間段已歸一化；「fx_source」已固定。
• DQ規則（FK/uniqueness/range/in_set）是活躍的。
• 非正規化已經記錄下來，正確性測試已經通過。
• 在行車記錄儀上可以看到線條和新鮮度/完整度度量。

20）頻繁的錯誤以及如何避免錯誤

在分析中混合PII：拆分mappings,應用CLS/RLS。
Silver正常化不足：導致3NF，否則昂貴的支持和焊接錯誤。
FX「關於報告的事實」：課程必須記錄在事件中，而不是「追溯」。
關鍵維度沒有SCD：RG/KYC/通道歷史丟失。
黃金重新歸一化：多余的加入→受控的非歸一化。
模式的不透明演變：使用註冊和消費者測試。

21）結果

正常化是銀級學科：單鍵和參考書，用於事實和測量3NF/BCNF，正確歷史（SCD）和時間/貨幣標準化。有了這樣的「骨架」，金色店面變得可預測，報告是可比的，擁有成本是可控制的。