数据湖和集中存储

（部分： 技术和基础设施）

简短摘要

Data Lake是集中存储原材料和整合数据集的基本层。对于iGaming，它接受投注/支付/游戏日志事件，合作伙伴卸载，来自OLTP的CDC，并将它们交给分析师，反欺诈者，CRM和BI。Lakehouse：开放式柱式格式+ACID表层+单一目录+交易/数据版本。成功的关键是计划和参与纪律，成本管理，PII安全和严格的运营文化（DQ，线性，DR）。

Data Lake在iGaming平台中的作用

分析的单一真理点：无论来源和格式如何，都要存储原始和清除的数据。
灵活性：支持击球和流媒体（CDC/连接器，活动流）。
演变：从原始的青铜到保形的Silver和Gold商业展示柜。
责任分工：prod服务写入总线/站点，分析/ML从Lake层消费。

建筑模型： Lake vs Lakehouse

数据湖（S3/ADLS/GCS+Parquet/ORC）：读取计划，廉价存储，格式灵活性。
Lakehouse （Delta/Iceberg/Hudi在Parquet之上）：ACID交易,upsert/merge,时间旅行,紧凑型文件,真空,索引/聚类。
练习：对于iGaming来说，Lakehouse作为主层是有益的，外部OLAP（ClickHouse/BigQuery/Snowflake/Pinot）作为店面和香料引擎。

奖章图层模型

青铜（Raw/Staging）：来自源的原始文件（CDC、日志转储、合作伙伴CSV、webhooks）。最低验证，"原样"。
Silver （Conformed）：清洗/去除、货币/时区正常化、类型转换、SCD测量、一致性密钥。
黄金（Marts/Serving）：GGR/NGR/LTV/Retention的单元，BI/CRM/antifrod下的实体店面。
TTL：在Bronze上具有侵略性，在Silver上具有中等性，在Gold单位上具有长期性。

格式和表格层

柱子：Parquet（事实上的标准），ORC。

开放表格式（ACID）：

Delta Lake-交易，"MERGE"，时间旅行，优化/真空，Z订单。
Apache Iceberg 是带有清单/snapshot，隐藏派对，"MERGE/DELETE/UPDATE"，时间旅行的表格。
Apache Hudi-抄写上/读取上，upsert优化，增量提取。
根据生态系统和对电路upsert/流/灵活演变的要求做出选择。

目录和转移

单一目录（Hive Metastore/Unity/Glue/平台目录）存储方案，部分，版本，权利。
要求：与表层的事务一致性,支持多个引擎（Spark、Trino/Presto、Flink、dbt）、审计/在线。

模式和演变

Schema contract：捕获必填字段，类型，语义；来源（"schema_version"）。
演变：增加可选的字段，禁止在没有迁移的情况下发生变化；piplines中的自动支票电路。
PII分段：敏感字段-分为具有加密和单独权限的单独列/表。

数据分派和退出

日期/小时是事件的基本关键；dop.字段："country"、"product"、"tenant_id"。

Hive-style путь: `s3://lake/bronze/payments/source=pspA/dt=2025-11-05/hour=13/part-0001.parquet`.

聚类/排序：Z-order/Sort按经常过滤的字段（player_id，国家）键。
文件大小：瞄准128-1024 MB；避免"小文件"（见下文）。
虚拟扬声器（Iceberg/Delta）用于隐藏党派化。

小文件与复合问题

来源流传着小桶→扫描和元数据的退化。
解决方桉：定期optimize/compaction （coalesce）, compaction任务调度程序,butch-micro bundle on ingestion, "autoOptimize"（如果可用）。
Merge-on-read与copy-on-write策略是写作潜伏期与读取速度之间的平衡。

无花果： batch，stream，CDC

来自OLTP（Debezium/连接器）→青铜的CDC（分钟新鲜）。
Stream（Kafka/Flink/Spark Structured Streaming）→ Silver/Gold增量（upsert/merge）。
Batch（合作伙伴报告/CSV/JSON）-通过带有清单的"接收器"，通过checksum控制拍摄。
Idempotency： keys （idempotency_key), dedup by （key, ts））,"水印"（watermarks）,用于以后到达的记录。

数据质量（DQ）和线性

DQ支票：完整性、密钥唯一性、范围、参考完整性（国家/货币列表）、业务规则（GGR ≥ 0）。
线条：从报告到源的依赖项图、模型代码版本和表格快照。
电路控制：自动背部/前向复合测试，阻止"断开"更改。
下载审核：谁/时间/多少,被拒绝的批次,转发。

伺服器和访问

SQL引擎：Spark/Trino/Presto用于临时和转换；用于ELT模型的dbt。
实时/近实时：Pinot/Druid/ClickHouse作为店面；Lakehouse是通过增量sink的来源。
数据共享：表格/snapshot对外部命令没有拷贝（如果格式支持）。

安全性、PII和多重性

加密：at rest（KMS）和in-transit（TLS）。
IAM/RBAC/ABAC：目录/表/列/字符串级别的角色（掩码、动态策略）。
按地区划分（欧盟/土耳其/拉特姆本地化）：隔离垃圾桶和计算池。
多重性：namespace/目录和路径前缀，"tenant_id"过滤器，可选-row-level policies。
访问审核：元数据读取/更改逻辑、重构和不可修改日志。

成本管理

存储类：标准类中的热（通常可读），带有TTL策略的冷/冰川类中的存档。
分党/集群将扫描减少→低于$。
用于昂贵报告的实例化店面；BI结果缓存。
编译和"正确的文件大小"-少于元数据和I/O。
配额和预算编制：计算集群/joba的限制，dataset/团队的价值报告。
垃圾清除：表格格式的"VACUUM/REWRITE"，TTL青铜。

DR和可重复性

转化表（时间旅行）和目录快照。
跨区域垃圾箱和元数据复制。
PITR：存储表事务日志（Delta/Iceberg/Hudi）和管道日志。
游戏日：定期进行区域恢复和切换演习。

可观察性和SLO

SLO新鲜：青铜≤ 5分钟，Silver ≤ 15-30分钟，黄金≤ 60分钟（示例）。
度量标准：文件的体积/数量、平均镶板文件大小、扫描时间、错过批次的百分比、计算频率、成本/数据集、DQ错误、延迟数据。
Alerta：小文件激增，成本上升，p95/p99降解，DQ/电路中断，流式胶带滞后。

神经元和路径公约（模板）


s3://<lake>/<layer>/<domain>/<dataset>/
source=<sys>/      # для Bronze dt=YYYY-MM-DD/
hour=HH/
country=XX/

Dataset名称是：'bets_raw'，'payments_cdc'，'players_silver'，'mart_gr_daily'。
元数据栏："ingest_ts"，"source"，"schema_version"，"trace_id"，"tenant_id"。

示例（广义）

1）Iceberg： 按日期显示隐藏部分的银表

sql
CREATE TABLE silver. bets (
bet_id    BIGINT,
player_id   BIGINT,
country    STRING,
stake     DECIMAL(18,2),
win      DECIMAL(18,2),
event_ts   TIMESTAMP,
ingest_ts   TIMESTAMP,
schema_version INT
)
PARTITIONED BY (days(event_ts))
TBLPROPERTIES ('format-version'='2');

2）Delta： CDC的增量upsert

sql
MERGE INTO silver. players t
USING bronze. players_cdc s
ON t. player_id = s. player_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

3）青铜的TTL政策（想法）


bronze/: keep 30 days silver/: keep 365 days (non-PII), 90 days (PII masked)
gold/marts/: keep 2–3 years (aggregated)

实施支票

1.选择表格格式（Delta/Iceberg/Hudi）和目录；与引擎（Spark/Trino/Flink/dbt）保持一致。
2.定义奖章层、TTL规则和命令责任。
3.记录计划合同、进化控制、PII分段和加密。
4.设计lay-out：批次，品种键，目标文件大小；启用compaction。
5.将ingest （CDC/stream/batch）配置为具有等效性和重复数据消除功能。
6.启用DQ/Lineage、元数据目录和审核。
7.确定SLO的新鲜度/价值,dashbords度量和alerta。
8.组织DR：snapshots/复制/恢复+定期练习。
9.标准化神经元和路径，元支架（"ingest_ts"，"source"，"schema_version"）。
10.在合适的OLAP/RT引擎中推出金色店面和实时浏览。

反模式

一个没有层和TTL的通用"麻袋"→溷乱和成本爆炸。
仅按时间分期,不考虑国家/产品→重型扫描。
创建数千个小文件/小时的线程,没有匹配。
缺乏计划控制和DQ →"打破"变化和对报告的不信任。
将PII与金色店面混合，而无需掩盖/分享权利。
Bucket级别的Hardcode访问权限代替目录和表格策略。

结果

适用于iGaming的现代Data Lake是Lakehouse，具有开放式表格格式，单一目录和奖章模型。计划/分期付款的纪律，针对小型文件，DQ/线性，PII安全性和成本卫生的匹配，将湖泊层转变为可持续的基础：便宜的存储，快速的阅读，SLO可预测的并且可以进行DR。这样的基础可以扩展到锦标赛高峰，并支持击球分析以及近乎现实的测试。-时间展示。