数据存储和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：存储一对值（很少）。

示例SCD2（SQL，通用表示）：

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/区域/周末/活动属性的日期/小时表。

存储和引擎： 选择配置文件

🚨 Check Alignment of PH>结肠和云DWH

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流进行增量更新。

ClickHouse示例（持有MV）：

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和预算中没有惊喜。