数据正常化

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）和时间/货币标准化。有了这样的"骨架"，金色店面变得可预测，报告是可比的，拥有成本是可控制的。