Armazéns de dados e modelos OLAP

(Secção Tecnologia e Infraestrutura)

Resumo curto

O Armazém de Dados (DWH) é a base dos analistas de iGaming: relatórios aos reguladores, lucratividade de produtos/mercados, LTV de banda, antifrod, segmentação CRM e real-time dashboard. O DWH sustentável é baseado em um modelo claro de dados (Star/Snowflake/Data Vault), integração confiável (ETL/ELT + CDC), desempenho elaborado (motores invertebrados, partituras, MVs), semântica rigorosa de métricas, segurança/PII e controle de custo.

Abordagens arquitetônicas

DWH clássico (Kimball vs Inmon)

Kimball (Dimensional/Star/Snowflake): vitrines rápidas de relatórios; foco em factos e dimensões, história SCD. Um tempo rápido.
Inmon (Corporate Informa Factory): núcleo normalizado + vitrine; mais difícil em termos de tempo, mas rigoroso e centralizado.

Data Vault 2. 0

Hubs-Links-Satélites: modelo escalável «cru» para integrar as fontes e auditar as alterações. As vitrines do Star estão a ser construídas.

Data Lake / Lakehouse

Data Lake: arquivos crus (Parquet/ORC) + diretórios (Hive/Glue/Unity/Metastore).
Lakehouse: camada única para batch/stream, tabelas ACID (Delta/Iceberg/Hudi), time-travel, upsert/merge, arquivos compactos, Z-order/Clustering.

Medallion (Bronze–Silver–Gold)

Bronze: dados crus (raw) + CDC.
Silver: limpos e conformados.
Gold: vitrines de negócios/métricas/cubos.
Adequado para híbridos (Kafka → Bronze; Silver в Lakehouse; Gold в ClickHouse/BigQuery/Snowflake).

Modelos OLAP: Star, Snowflake, Data Vault

Star Schema (estrela)

Tabelas fact: transações (taxas, depósitos, sessões).
Dimensions: jogador, jogo, provedor, data/hora, geo, canal de atração.
Vantagens: joyons simples, desempenho previsto.

Snowflake

Normalização de medidas (hierarquia de países/regiões/cidades, hierarquia de produtos).
Mais: menos duplicação; menos, mais joynes.

Data Vault → Star

Mudanças crus dobramos em DV (auditoria, reprodução total), vitrines de relatórios construídos como Star/Snowflake.

Integração: ETL/ELT, CDC, alterações lentas

Pipeline

Outbox/CDC do OLTP (Postgres/MySQL) → Kafka/conectores → Bronze.
ELT: limpeza, deadup, normalização na Silver.
Lógica de negócios e agregações no Gold/vitrines.

SCD (Slowly Changing Dimensions)

Tipo 1: reiniciar (para campos irrelevantes).
Tipo 2: histórico (versões datadas) - padrão para perfis/canais/preços.
Tipo 3: armazenamento de pares de valores (raramente).

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;

Camada semântica e métricas «verdadeiras»

Digite uma única camada de métricas (semantic layer): definições de GGR, NGR, Net Deposits, ARPU, LTV, Churn, Retenção Cohorts.
As métricas como código (dbt metrics/LookML/Semantic Layer) → as mesmas fórmulas em todos os relatórios.
Calendário: tabela de datas/horas com atributos TZ/região/fim de semana/campanha.

Armazéns e motores: seleção para perfil

Invertebrados e DWH na nuvem

ClickHouse: escalas/agregações ultrarrápidas, representações materializadas, projeções; diferente para eventos/telemetria e vitrines de marketing.
BigQuery: servidor, zoom, cachês automáticos/clusters; Preço por scan; confortável para cargas mistas e ad-h.
Snowflake: separação compute/armazenamento, clusters sob demanda, time-travel; transparente para diferentes comandos.
Redshift/Vertica/Pinot/Druid: opções sob OLAP/real-time.

Sintonizar para baixo do perfil

Particionamento por data/região/canal.
Clusterização/triagem por chave de filtragem/joyn.
Compactação e codificação por dicionários.
Pré-regulações (rollup, cubes), apresentações materializadas.
Recursos Approx (HyperLogLog/approx_distinct) para avaliações baratas.

Engenharia de desempenho

Particionamento e clusterização

A partição é o limite do compartimento. Partituras diurnas/horárias para eventos.
Clusterização (sort keys/Z-order) - acelera as faixas e join.

Visualizações materializadas (MV)

Pré-contagem GGR/NGR por dias/países/produtos.
Atualização aumentada do strip CDC.

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;

Modelos incorporados (dbt/ELT)

Estratégias 'insert _ overwrite' por partituras, 'merge' por chave CDC, 'watermark' por 'updated _ at'.

Estratégia Join

Réplica as medições em cada segmento partitário (denorm).
Broadcast small dims; shuffle largue facts com arrumação por chave.

Custo: controle e otimização

BigQuery/Snowflake: Limite o tamanho do scan (projete partituras/clusters), inclua o result cache/materialize views, e limite as buscas automáticas BI.
ClickHouse: tamanho das partições, frequência dos murjes, orçamento por armazenamento (TTL para eventos crus, agregações duráveis).
A semântica das métricas reduz os cálculos duplos.
Data pruning: Retalho para Bronze, agregação para Gold.

Qualidade de dados (DQ), diretório, lineage

Cheques DQ: totalidade (completeness), exclusividade, faixas, regras de negócios (por exemplo, GGR ≥ 0 em unidades).
Data Catalog & Lineage: descrições de tabelas/campos, proprietários, classificação PII, rastreamento de relatório a origem.
Controle de esquema: contrato de eventos/CDC, alertas em mudanças incompatíveis.

Segurança, Complacência e Multi-Tenência

Segmentação PII: áreas individuais, camuflagem/pseudonimização, colunas com criptografia KMS.
RBAC/ABAC: papéis ao nível de projeto/esquema/tabela/linha (RLS), vozes para «need-to-know».
Localização de dados: buckets/warehouses regionais (EU/TR/LATAM).
Auditoria de acesso: quem leu/alterou vitrines e modelos.

Dr., bacapes e reprodutividade

Versionização do código de dados (dbt/git), ambiente Dave/QA/Prod.
Snapshots metastor/catálogo + versionização de tabelas (time-travel).
Retenschn/TTL camadas Bronze/Silver/Gold; exportação de vitrines críticas.
Game-day: restauração de vitrines, verificação da integridade das métricas.

Real-time e vitrines híbridas

Stream-to-OLAP: Kafka → ClickHouse/Pinot/Druid para vitrines de minutos.
Materializador views + CDC para atualizações quase online (5-15 min).
A camada semântica permanece unificada: as métricas são idênticas no real-time e no batch.

Exemplo de vitrine «GGR por dias e países» (SQL genérico)

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;

Folha de cheque de implementação

1. Identifique as fontes e os domínios e fixe o dicionário de métricas.
2. Selecione DV para camadas de áudio/crude + Star para vitrines.
3. Projete partituras/clusters sob as principais pesquisas e janelas.
4. Configure o CDC/ELT, a política SCD e o surrogate keys.
5. Digite uma camada semântica (métricas como código) e um calendário de datas/horas.
6. Crie MVs/pré-relatório para relatórios caros.
7. Inclua DQ/diretório/lineage e controle de circuitos.
8. Defina RBAC/PII/localização, criptografia, auditoria.
9. Configure o monitoramento p95/p99, custo, alertas para degradação e sobrepreço.
10. Ensinamentos DR regulares e reprodutividade de ambientes.

Antipattern

«Um fato gigante sem partituras», o scan de terabytes, e a conta aumenta.
Definições incoerentes de métricas em diferentes dashboards.
Falta de SCD2 onde o negócio requer histórico.
A normalização prematura das medições, os relatórios extras e lentos.
Dados crus sem cheques DQ e lineage → relatórios «nada».
Falta de retenção/TTL → armazenamento de lixo e explosão de custos.

Resumo

Um iGaming-DWH confiável é um modelo claro (DV→Star), um dicionário de métricas, partituras/clusterização corretas, vitrines materializadas, DQ/lineage rigorosos e RBAC/PII/localização. Adicione uma estirpe híbrida para frescura, controle ELT e disciplina de custo - e obtenha uma plataforma de análise sustentável que se escala para torneios, relatórios regulatórios e pesquisa ad-house sem surpresas no p99 e orçamento.