數據湖和集中存儲

（部分： 技術和基礎設施）

簡短摘要

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。這樣的基礎可以擴展到錦標賽高峰，並支持擊球分析以及近乎現實的測試。-時間展示。