Data Lake e armazenamento centralizado

(Secção Tecnologia e Infraestrutura)

Resumo curto

O Data Lake é uma camada básica de armazenamento central de matérias-primas e datasets consolidados. Para iGaming, ele aceita eventos de apostas/pagamentos/logs de jogo, download de parcerias, CDC de OLTP e os entrega a analista, antifrode, CRM e BI. Prática moderna - Lakehouse: formatos invertebrados abertos + camada de tabela ACID + diretório único + transações/versões de dados. A chave para o sucesso é a disciplina de esquemas e partitização, gerenciamento de custo, segurança PII e cultura operacional rigorosa (DQ, lineage, DR).

O papel do Data Lake na plataforma iGaming

Um único ponto de verdade para os analistas: armazenamento de dados crus e limpos, independentemente da origem e do formato.
Flexibilidade: suporte a batch e streaming (CDC/conectores, event striam).
Evolução de Bronze crus para Silver e vitrines de negócios Gold.
Divisão de responsabilidade: os serviços de prod escrevem no pneu/estagiário, o analista/ML consome a partir de camadas de lake.

Modelos arquitetônicos: Lake vs Lakehouse

Data Lake (S3/ADLS/GCS + Parquet/ORC): schema-on-read, armazenamento barato, flexibilidade de formatos.
Lakehouse (Delta/Iceberg/Hudi acima do Parquet): transações ACID, upsert/merge, time-travel, arquivos compactos, vácuo, indexação/clusterização.
Prática: para iGaming beneficia Lakehouse como camada principal, enquanto OLAP (ClickHouse/BigQuery/Snowflake/Pinot) externa como vitrines e motores de espólio.

Modelo de camadas medalhadas

Bronze (Raw/Staging): arquivos crus de fontes (CDC, logs-dampos, associados CSV, webhooks). O mínimo de validação, «como é».
Silver (Conformed): limpeza/dedução, normalização de moedas/fusos horários, impressão de tipos, medidas SCD, chaves consistentes.
Gold (Marts/Serving): Equipamentos para GGR/NGR/LTV/Retenção, vitrines materializadas sob BI/CRM/antifrode.
TTL: agressivo em Bronze, moderado em Silver, a longo prazo em unidades Gold.

Formatos e camadas de tabela

Invertebrados: Parquet (padrão de facto), ORC.

• Delta Lake - transações, 'MERGE', time-travel, otimização/vácuo, Z-order.
• Apache Iceberg - Tabelas de manifestos/snapshots, partilhamento oculto, 'MERGE/DELETE/UPDATE', time-travel.
• Apache Hudi - copy-on-write/merge-on-read, upsert-otimização, extração aumentada.
• Escolha por ecossistema e requisitos de upsert/stryming/flexibilidade da evolução dos circuitos.

Diretório e Metastor

Diretório único (Hive Metastore/Unity/Glue/Plateias de Plataforma) armazena esquemas, partituras, versões, direitos.
Requisitos: coerência transacional com camada de tabela, suporte para vários motores (Spark, Trino/Pró, Flink, dbt), auditoria/lineage.

Esquemas e evolução

Schema contract: fixe os campos obrigatórios, os tipos, a semântica; fontes de versionização ('schema _ versão').
Evolução: adição de campos opcionais, proibição de alterações de quebra sem migração; cadernetas automáticas em pipas.
Segmentação PII: campos sensíveis - em colunas/tabelas individuais criptografadas e permissões individuais.

Particionamento e lay-out de dados

Data/hora - chave básica para eventos; mais campos: 'country', 'product',' tenant _ id '.
Hive-style путь: `s3://lake/bronze/payments/source=pspA/dt=2025-11-05/hour=13/part-0001. parquet`.
Clusterização/triagem: Z-order/Sort keys para campos frequentemente filtrados (player _ id, country).
Tamanho do arquivo: Apontar para 128-1024 MB; evite «small files» (veja abaixo).
Colunas virtuais (Iceberg/Delta) para particonização oculta.

Problema de small files e compactação

As fontes removem os chancinhos → a degradação das raias e metadados.
Solução: optimize/competition periódica (coalesce), planificador de tarefas de compactação, batch-micro-bundle em «autoOptimize» (se disponível).
Política de merge-on-read vs copy-on-write - equilíbrio entre latência e velocidade de leitura.

Injecto: batch, stream, CDC

CDC de OLTP (Debezium/conectores) → Bronze (frescor de minutos).
Stream (Kafka/Flink/Spark Estrutured Streaming) → Silver/Gold (upsert/merge).
Batch (relatórios de parcerias/CSV/JSON) - por meio de «receptores» com manifestos, controle de duplicações por checksum.
Idempotency: chaves (idempotency _ key), dedução por (key, ts), marcas de água (watermarks) para gravações posteriores.

Qualidade de dados (DQ) e lineage

Cheques DQ: totalidade, exclusividade das chaves, faixas, integridade arbitral (listas de países/moedas), regras de negócios (GGR ≥ 0).
Linedge: gráfico de dependências do relatório à origem, versão do código do modelo e da tabela.
Controle de esquema: testes automáticos de back/forward-compat que bloqueiam alterações «quebrantes».
Auditoria de downloads: quem/quando/quantos lotes rejeitados, retais.

Serving e acesso

Motores SQL: Spark/Trino/Pró para ad-house e transformações; dbt para modelos ELT.
Real-time/near-real-time: Pinot/Druid/ClickHouse como vitrines; Lakehouse é uma fonte através do sink incorporativo.
Data Sharing: Sharing Tabels/Snapshot a comandos externos sem cópia (se suportado pelo formato).

Segurança, PII e multi-tenência

Criptografia: at-rest (KMS) e in-transit (TLS).
IAM/RBAC/ABAC: papéis ao nível de diretório/tabela/coluna/linha (camuflagem, políticas dinâmicas).
Segmentação por região (localização UE/Turquia/LatAm): isolamento de baquetas e poóis de processamento.
Multi-tenante: namespace/diretórios e prefixos de caminho, filtros por 'tenant _ id', opcional por 'row-level policies'.
Auditoria de acesso: logs de leitura/alteração de metadados, retensas e registros não personalizados.

Gerenciamento de custo

Classes de armazenamento: quente (muitas vezes lido) na sala de aula padrão, arquivo em classes frias/glacier com políticas TTL.
Particionamento/cluster reduz as raias → menos de $ $ $.
Vitrines materializadas para relatórios caros; cachê de resultados BI.
Compacto e «tamanho de arquivo correto» - menos metadados e I/O.
Cotas e orçamento: limites para clusters de compute/jobs, relatórios de custo por dataset/comando.
Remoção de lixo: 'VACUUM/REWRITE' em formatos de tabela, TTL Bronze.

DR. e reprodução

Versionização das tabelas (time-travel) e do diretório.
Replicação cruzada regional de baquetes e metadados.
PITR: Armazenamento de registros de transações de tabelas (Delta/Iceberg/Hudi) e logs de pipline.
Game-day: exercícios regulares de recuperação e mudança de região.

Observabilidade e SLO

SLO frescura: Bronze ≤ 5 min, Silver ≤ 15-30 min, Gold ≤ 60 min (exemplo).
Métricas: volume/tamanho dos arquivos, tamanho médio do parquinho, tempo das raias, proporção de partições omitidas, frequência de competência, custo/dataset, erros DQ, dados atrasados.
Alerts: aumento de small files, aumento de custos, degradação p95/p99, violação de DQ/circuitos, atraso de sintomas.

Convenções de naiming e caminhos (modelo)

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

Os nomes dos datasets são 'bets _ raw', 'payments _ cdc', 'players _ silver', 'mart _ ggr _ daily'.
Colunas metadadas: 'ingest _ ts', 'fonte', 'schema _ version', 'trace _ id', 'tenant _ id'.

Exemplos (genérico)

1) Iceberg: tabela Silver com partição oculta por data

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: upsert incorporativo de CDC

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) Política TTL para Bronze (ideia)

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

Folha de cheque de implementação

1. Selecione o formato de tabela (Delta/Iceberg/Hudi) e o diretório; alinhar com os motores (Spark/Trino/Flink/dbt).
2. Defina as camadas de medalhão, as regras TTL e a responsabilidade dos comandos.
3. Fixe schema contracts, controle de evolução, segmentação PII e criptografia.
4. Projete lay-out: partituras, variedades-chaves, tamanho-alvo do arquivo; Ativar a competition.
5. Configure o ingest (CDC/stream/batch) com idumpotência e dedução.
6. Inclua DQ/lineage, diretório de metadados e auditoria.
7. Defina o SLO de frescura/custo, dashboards de métricas e alertas.
8. Organize o DR.: snapshots/replicação/recuperação + exercícios regulares.
9. Normalize o naiming e os caminhos, os metacolônicos ('ingest _ ts', 'fonte', 'schema _ versão').
10. Leve as vitrines Gold e real-time para os motores OLAP/RT adequados.

Antipattern

Um «saco» comum sem camadas e TTL → caos e explosão de valor.
A partilha é apenas por tempo, sem contar com o país/produto, os scans pesados.
Fluxos que criam milhares de arquivos menores/hora sem competência.
A falta de controle de esquema e DQ → alterações «quebrantes» e desconfiança dos relatórios.
Misturar PII com vitrines Gold sem disfarçar/dividir direitos.
Hardcod permissões a nível de baquetas em vez de diretório e políticas de tabela.

Resumo

O atual Data Lake para iGaming é um Lakehouse com formato de tabela aberta, catálogo único e modelo de medalhas. Disciplina de circuitos/partituras, competência vs small files, DQ/lineage, segurança PII e higiene de custo transformam a camada ayutlake em fundações sustentáveis: barata de armazenamento, rápida leitura, previsível SLO e pronta para DR. Essas fundações são escaladas sob picos de torneio e suportam e batch analíticos, e near vitrine-real-time.