数据湖和流汇总

1）目的和价值

Data Lake/Lakehouse是长期存储和大规模读取的基础层，其中：

产品/游戏/付款的流量按原样降落在Bronze中。
Silver通过提供一致的密钥和质量来规范化和丰富。
Gold是用于BI，调节剂，防冻剂/RG的聚合店面（包括real -/near-real-time）。

在Lakehouse上汇总线程会产生：低延迟报告，可预测的成本，可重复性和前瞻性。

2）参考体系结构

1.Ingest/Edge: HTTP/gRPC, OTel, batch endpoints → шина (Kafka/Redpanda).

2.Bronze（仅限append-only）：对象存储+ACID表（Delta/Iceberg/Hudi），按日期/market/tenant分期付款；存储原始付费。
3.流计算：Flink/Spark/Beam-窗口单元，CEP，dedup，在线外观。
4.Silver （clean/conform）：货币标准化/时间区、FK/参考书、用于测量的 SCD。
5.Serving/OLAP： ClickHouse/Pinot/Druid-面板的实例化分钟/秒组合。
6.黄金（serve）：白天/小时店面、监管切口、不可改变的出口包装（WORM）。
7.控制轮廓：Schema Registry, DQ代码,lineage,目录,secrety/KMS, RBAC/ABAC。

3）合同和计划

Schema-first: JSON/Avro/Protobuf;必填字段：'event_time （UTC）'、'event_id'、'trace_id'、'user_pseudo_id'、'market'、'schema_version'。
演变：反向兼容→添加无效；破解→ '/v2'+双重记录。

目录： 域名描述,所有者,SLA新鲜度,DQ规则,lineage.

4）将溪流降落到湖中

Exactly-once在底部：on-least-once出版+Idempotent sink（MERGE/upsert by 'event_id'）。
Dedup： Stream+Silver中的stateful。
文件编译：小型文件→定期OPTIMIZE/VACUUM读取和成本。
时间旅行：包括调试、中继和审核。

Iceberg派对示例（DDL想法）：

sql
CREATE TABLE bronze. payment_events (
event_id STRING, user_pseudo_id STRING, currency STRING,
amount DECIMAL(18,2), market STRING, event_time TIMESTAMP, payload STRING
)
PARTITIONED BY (days(event_time), market);

5）流汇总： 窗户和水上市场

窗口是：

Tumbling是用于稳定面板的固定（例如1分钟/5分钟）。
Hopping-"平滑"度量的重叠（步骤<窗口）。
Session-非活动行为中断。
Watermarks：管理后期数据（通常为2-5分钟）,发布前/校正规则。

Flink SQL-按市场提供1分钟的存款：

sql
SELECT market,
TUMBLE_START(event_time, INTERVAL '1' MINUTE) AS ts_min,
COUNT() AS deposits_1m,
SUM(amount_base) AS sum_1m
FROM silver. payments
GROUP BY market, TUMBLE(event_time, INTERVAL '1' MINUTE);

6）聚合物实现

OLAP引擎（ClickHouse/Pinot/Druid）：存储用于行车记录仪和操作分析的分钟/秒单元。
Lakehouse Gold：保留每日津贴/小时切片，用于报告和合并（可重复性）。

ClickHouse-材料化视图（每分钟GGR）：

sql
CREATE MATERIALIZED VIEW mv_ggr_1m
ENGINE = AggregatingMergeTree()
PARTITION BY toDate(event_time)
ORDER BY (toStartOfMinute(event_time), market, provider_id) AS
SELECT toStartOfMinute(event_time) AS ts_min,
market,
provider_id,
sumState(stake_base) AS s_stake,
sumState(payout_base) AS s_payout
FROM stream. game_events
GROUP BY ts_min, market, provider_id;

黄金-白天切片（Lakehouse）：

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(event_time) AS event_date,
market, provider_id,
SUM(stake_base) AS stakes_eur,
SUM(payout_base) AS payouts_eur,
SUM(stake_base) - SUM(payout_base) AS ggr_eur
FROM silver. fact_game_financials
GROUP BY 1,2,3;

7）Silver： 正常化和协调

时间和货币：'event_time （UTC）'、'amount_base'、'fx_rate_used'、'fx_source'。
密钥/参考：'user_pseudo_id'、'game_id'、'provider_id'、'market'。
SCD II：测量历史化（users/games/providers/RG/KYC）。
DQ规则：键的唯一性，参考书，和数范围，时间有效性。

8）汇总注册表和"正确"定义

语义层：单个GGR/NGR公式，投注/获胜，转换，ARPPU，latency p95。
测试度量："metric_version"和"as-of"计算。
基座卡：所有者，公式，来源，准备就绪的SLA。

9）Exactly-once/等效性和顺序

总线：at least-once+分党（本地顺序）。
处理：通过"event_id"（TTL 24-72 h），SER/窗口运算符进行调整。
Sink：事务性商品或idempotent upsert/merge。
Outbox/Inbox：从OLTP中发布具有保修期的域事件。

10）后期数据和调整

Allowed lateness： 2-5分钟用于操作展示；Gold的每日重新装配。
校正：在OLAP和Gold rebor（idempotent）中发射前。
标志：'late=true'、'correction_of= <event_id>'用于审核。

11）可观察性与DQ

SLI/SLO（地标）：

p95 ingest→1-分钟≤ 2-5 c；黄金日报准备到06：00 lock。
Completeness ≥ 99.5%;Schema validity ≥ 99.9%;Trace coverage ≥ 98%.
Piplines度量标准：lag/throughput/busy time/state size, late-ratio, dup-rate.
DQ-dashbords： Freshness/Completeness/Validity,损失漏斗,热键卡。
线性：从青铜到黄金/出口的路径；变更时的影响分析。

12）隐私、居住、安全

PII最小化：别名，单独的安全映射。
居住地：EEA/UK/BR-单独的目录和加密密钥；无故禁止跨区域合作。
加密：transit中TLS；KMS/CMK at-rest;出口签名+监管下的WORM。
DSAR/RTBF/Legal Hold：选择性编辑、冻结删除、可审核访问。

13）生产力和成本

参与：按日期/市场/特南特分列；按常用过滤属性聚类/Z顺序。
复合：消除小文件,常规OPTIMIZE/VACUUM。
实现：每分钟/秒-在OLAP中；每天/每小时-黄金。

Tiered storage： hot/warm/cold, SLA恢复,chargeback by commands （成本/GB,成本/查询）.

聚合/草图：HyperLogLog/approx-distinct在可以接受的位置。

14）示例（片段）

Flink CEP-存款结构（10分钟）：

python if count_deposits(window=10MIN) >= 3 \
and sum_deposits(window=10MIN) > THRESH \
and all(d. amount < REPORTING_LIMIT for d in window_events):
emit_alert("AML_STRUCTURING", user_id, snapshot())

SQL-加载到Silver时的难题：

sql
CREATE TABLE silver. payments AS
SELECT EXCEPT(rn) FROM (
SELECT p., ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time) rn
FROM bronze. payment_events p
) WHERE rn = 1;

Iceberg/Delta-MERGE相等：

sql
MERGE INTO silver. fact_bets s
USING stage. fact_bets_delta d
ON s. bet_id = d. bet_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

15）流程和RACI

R (Responsible):

数据平台（Lakehouse/目录/ACID，堆积），

流化（聚合/CEP/dedup），

域分析（度量/黄金）。

A (Accountable): Head of Data/CDO.

C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), SRE (SLO/стоимость), Security.

I （Informed）： BI/产品/营销/运营。

16）实施路线图

MVP（3-5周）：

1.Lakehouse Bronze/Silver（ACID表），来自Kafka的ingest，注册计划。

2.OLAP中的基本流单元（1-5分钟）；金色展示柜。ggr_daily （D+1至06：00）。

3.Payments/Gameplay的DQ，Freshness/Completeness dashbords。

4.压缩/OPTIMIZE，最小成本度量和Alerta lag/late/dup。

第二阶段（5-10周）：

银扩展（用于users/games/providers的SCD II），线性和影响分析。
异步外观（RG/KYC/ASN/BIN），后期校正管理。
语义层度量，导出规则（WORM/签名）。

第三阶段（10至16周）：

多区域，DR/继电器模拟器，自动调谐窗口和水上市场。
Cost-dashbords，chargeback/配额，tiered存储和存档。
自动生成店面文档和度量卡。

17）售前支票清单

登记册中的计划和合同；背对背测试为绿色。
包括dedup，watermark/allowed lateness，DLQ。
Compaction/OPTIMIZE/VACUUM是按计划配置的。

[] SLO: p95 ingest→minute-view, Gold до 06:00;Alerta lag/late/dup/state size。

DQ规则是活跃的；从青铜到出口都可以看到线程。

[] RBAC/ABAC и KMS;居住和DSAR/RTBF/Legal Hold测试。

控制成本（成本/GB,成本/查询,冷份额）,中继限制。

18）反模式和风险

一个表中原始数据和报告数据的混合：违反可重复性。
缺乏堆积：小文件爆炸→昂贵的查询。
"追溯"计算FX：打破历史记录和报告。
没有watermarks/late polity："漂浮"店面和alerta。
Full reload不需要：使用注释/MERGE和调整。
PII在分析中：将mappings分开,包括CLS/RLS。

19）词汇表（简短）

Lakehouse是数据湖+ACID表和SQL引擎。
Bronze/Silver/Gold-原始/规范化/伺服层。
Watermark是事件时间窗口就绪的边界。
Materialized View是一个预期的快速阅读展示。
时间旅行-阅读表格的历史版本。
WORM是出口文物的不可变存储。

20）结果

具有正确流汇总的数据湖是层和合同的学科："原样"的青铜，用于正常化和质量的Silver，用于分钟面板的OLAP，用于可重现报告的金色。通过管理窗口和水厂、重复数据消除和堆迭、隐私和成本，您可以获得快速、可验证和兼容的产品、合规性和运营管理展示。

数据湖和流汇总

联系我们

快速联系

视频即将更新

我们目前正忙于各项项目