數據存儲和OLAP模型
（部分： 技術和基礎設施）
簡短摘要
數據倉庫（DWH）是iGaming分析的參考層：向監管機構報告，產品/市場盈利能力，隊列LTV，反欺詐分析，CRM細分和實時儀表板。可持續的DWH建立在清晰的數據模型（Star/Snowflake/Data Vault），強大的集成（ETL/ELT+CDC），深思熟慮的性能（柱式引擎，分期，MVs），嚴格的度量，安全性/PII和成本管理語義上。
架構方法
經典DWH （Kimball vs Inmon）
Kimball （Dimensional/Star/Snowflake）：快速報告展示；專註於事實和維度，SCD歷史。快速超時。
Inmon（企業信息工廠）：規範化核心+店面；時間更重，但嚴格和集中。
Data Vault 2.0
Hubs-Links-Satellites：用於源集成和更改審核的可擴展的「原始」模型。在上面建造了Star店面。
Data Lake / Lakehouse
數據湖：原始文件（Parquet/ORC）+目錄（Hive/Glue/Unity/Metastore）。
Lakehouse：用於擊打/流的單個層，ACID表（Delta/Iceberg/Hudi），時間旅行，upsert/merge，緊湊文件，Z命令/集群。
Medallion (Bronze–Silver–Gold)
青銅：原始數據（raw）+CDC。
Silver：純化和保形。
黃金：商業展示/度量/立方體。
適用於混合動力車（Kafka → Bronze；Silver в Lakehouse;Gold в ClickHouse/BigQuery/Snowflake).
OLAP型號： Star、Snowflake、Data Vault
Star Schema（明星）
表的事實：交易（利率、存款、會話）。
Dimensions：玩家，遊戲，提供商，日期/時間，地理，吸引渠道。
優點：簡單的joynes，可預測的性能。
Snowflake
測量標準化（國家/地區/城市層次結構，產品層次結構）。
優點：減少重復；減去-更多的joynes。
Data Vault → Star
原始更改堆疊在DV（審計，完全可重復性）中，報告店面以Star/Snowflake的形式構建。
整合： ETL/ELT，CDC，緩慢變化
Pipline
來自OLTP的Outbox/CDC（Postgres/MySQL）→ Kafka/連接器 →青銅。
ELT：在Silver清洗，去除，正常化。
黃金/店面中的業務邏輯和聚合。
SCD (Slowly Changing Dimensions)
類型1：重寫（對於非必要字段）。
類型2：歷史性（日期版本）-配置文件/頻道/價格的標準。
類型3：存儲一對值（很少）。
sql
-- insert new dimension version
INSERT INTO dim_player (player_sk, player_id, country, valid_from, valid_to, is_current)
SELECT gen_sk(), s. player_id, s. country, now(), '9999-12-31', true
FROM staging_player s
LEFT JOIN dim_player d ON d. player_id = s. player_id AND d. is_current = true
WHERE d. player_id IS NULL OR d. country <> s. country;
-- closing the old version
UPDATE dim_player d
SET valid_to = now(), is_current = false
FROM staging_player s
WHERE d. player_id = s. player_id AND d. is_current = true AND d. country <> s. country;語義層和「真實」度量
輸入單一度量層（semantic layer）： GGR、NGR、Net Deposits、ARPPU、LTV、Churn、Retention Cohorts定義。
度量標準作為代碼（dbt metrics/LookML/Semantic Layer）在所有報告中→相同的公式。
日歷：具有TZ/區域/周末/活動屬性的日期/小時表。
存儲和引擎： 選擇配置文件
ClickHouse：超快速掃描/聚合，實例化表示，投影；不同於活動/遙測和營銷展示。
BigQuery：服務器文件，縮放，自動緩存/群集；掃描的價格；方便混合載荷和臨時載荷。
Snowflake：compute/storage部門，按需群集，時間旅行；對不同的團隊透明。
Redshift/Vertica/Pinot/Druid：OLAP/real-time下的變體。
調諧到配置文件
按日期/地區/頻道參加。
聚類/分類過濾鍵/joins。
用字典壓縮和編碼。
預聚集（rollup，cubes），實例化表示。
Approx功能（HyperLogLog/approx_distinct）用於廉價評分。
性能設計
參與和聚類
派對是隔間的邊界。活動白天/小時分期付款。
聚類（sort keys/Z-order）-加快範圍並加入。
實例化視圖（MV）
GGR/NGR按天/國家/產品進行預估。
從CDC流進行增量更新。
sql
CREATE MATERIALIZED VIEW mv_ggr_daily
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMMDD(ts)
ORDER BY (country, product_id, toDate(ts)) AS
SELECT toDate(ts) AS d,
country,
product_id,
sum(stake) AS stake_sum,
sum(win) AS win_sum,
sum(stake - win) AS ggr
FROM bets
GROUP BY d, country, product_id;增量模型（dbt/ELT）
分批使用「insert_overwrite」策略，CDC密鑰使用「merge」策略，「updated_at」使用「watermark」策略。
聯合戰略
每個分段中的測量副本（denorm）。
Broadcast small dims;按鍵排序的shuffle large事實。
成本： 控制和優化
BigQuery/Snowflake：限制掃描尺寸（設計parts/Clusters）,包括結果cache/materialized views,限制BI自動任務。
ClickHouse：分期付款的大小、商品的頻率、存儲預算（原始事件的TTL,聚合耐用）。
度量的語義減少了「雙重」計算。
Data pruning： Bronze的續集,Gold的聚合。
數據質量（DQ）,目錄,lineage
DQ支票：完整性（完整性），唯一性，範圍，業務規則（例如，聚合中的GGR ≥ 0）。
Data Catalog&Lineage：表/字段說明、所有者、PII分類、從報告到源的跟蹤。
電路控制：事件/CDC合同，不兼容更改的變量。
安全性、合規性和多重性
PII分段：單獨區域，掩碼/別名，帶有KMS加密的列。
RBAC/ABAC：項目/電路/表/字符串（RLS）級別的角色，「需要知道」的角色。
數據本地化：區域buckets/warehouses （EU/TR/LATAM）。
訪問審核：誰閱讀/更改了店面和模型。
DR、備用和可重復性
數據代碼驗證（dbt/git）, Dev/QA/Prod環境。
轉移器/目錄快照+表格轉換（時間旅行）。
Bronze/Silver/Gold 重組/TTL層；出口關鍵店面。
遊戲日：恢復店面，檢查指標的完整性。
實時和混合店面
流到OLAP：Kafka → ClickHouse/Pinot/Druid用於分鐘展示。
Materialized views+CDC用於近乎在線的更新（5-15分鐘）。
語義層保持相同：度量標準在實時和測試中相同。
「GGR by Days and Country」展示示例（由SQL概括）
sql
CREATE TABLE fact_bets (
bet_id BIGINT,
player_sk BIGINT,
game_sk BIGINT,
country_sk BIGINT,
stake DECIMAL(18,2),
win DECIMAL(18,2),
ts TIMESTAMP
) PARTITION BY DATE(ts);
CREATE TABLE dim_country (
country_sk BIGINT PRIMARY KEY,
iso2 STRING,
region STRING,
valid_from TIMESTAMP,
valid_to TIMESTAMP,
is_current BOOL
);
-- Showcase
CREATE MATERIALIZED VIEW mart_ggr_daily AS
SELECT
DATE(ts) as d,
c. region,
SUM(stake) AS stake_sum,
SUM(win) AS win_sum,
SUM(stake - win) AS ggr
FROM fact_bets f
JOIN dim_country c ON c. country_sk = f. country_sk AND c. is_current
GROUP BY d, c. region;實施支票
1.定義源和域,記錄指標字典。
2.選擇模型：用於原始/審核層的DV+用於店面的Star。
3.根據關鍵查詢和窗口設計批次/群集。
4.配置CDC/ELT、SCD策略和surrogate鍵。
5.輸入語義層（度量作為代碼）和日期/小時日歷。
6.為昂貴的報告創建MVs/預聚合。
7.啟用DQ/目錄/lineage和模式控制。
8.定義RBAC/PII/本地化、加密、審核。
9.定制p95/p99監控、成本、降解差異和超支。
10.常規的DR演習和周圍環境的可重復性。
反模式
「一個沒有派對的巨大事實」→ TB掃描和計數正在增長。
不同行列中的度量定義不一致。
在企業需要歷史性的地方缺乏SCD2。
過早的測量標準化：多余的喬因和緩慢的報告。
沒有DQ支票和線性的原始數據→無關緊要的報告。
缺乏退縮/TTL →垃圾儲存和成本爆炸。
結果
可靠的iGaming-DWH是清晰的模型（DV→Star），單一度量詞典，正確的分期/聚類，實例化店面，嚴格的DQ/線性以及 RBAC/PII/本地化。添加混合流媒體以實現新鮮度、ELT驅動和價值紀律-並獲得一個可持續的分析平臺,可擴展到錦標賽、監管報告和臨時研究,而p99和預算中沒有驚喜。