GH GambleHub

Processos ETL/ELT

1) Destino e contexto

As linhas de montagem ETL/ELT fornecem downloads previsíveis, transformações e publicação de dados para relatórios (GGR/NGR, reguladores), analistas/ML e painéis operacionais.

ETL: Transformemos antes do download em DWH/Lakehouse (menos em estagiários modernos).
ELT: Primeiro carregamos para Lakehouse (Bronze/Silver) e depois transformamos SQL/motores (recomendado).

2) Arquitetura de referência

1. Ingest/Edge: HTTP/gRPC/Batch, CDC de OLTP, provedor S3/FTP de descarga.
2. Bronze (raw, append-only): payload's imutáveis, partições por data/mercado/tenante.
3. Silver (clean/conform): normalização, dedução, guias, SCD, FX/temporizações.
4. Gold (serve): Vitrines denormalizadas sob BI/regulador/modelo.
5. Orquestra: Airflow/Dagster/Preferect (DAG 'i, SLA, retais, deslocamentos).
6. DQ/Contracts: Schema Registry + DQ-как-код, consumer-driven tests.
7. Observabilidade: métricas de Pipline, lineage, logs, coque-dashboard.

3) Seleção de ETL vs ELT

CritérioETLELT (recomendado)
Flexibilidade de redefiniçãobaixaalta (time-travel, reprocessing)
Customais caro ao crescerideal ao escalar
Controle de qualidadeno ingestem Silver/Gold + DQ-como-código
Histórico/forenselimitadocompleta (Bronze append-only)

Prática: em iGaming - ELT + CDC: Carregamos rapidamente, depois normalizamos e acreditamos.

4) Encartes e CDC

Abordagens de delta:
  • CDC (Debezium/logs-replicação): alterações no OLTP → Bronze → MERGE no Silver.
  • Watermark hora: 'updated _ at> max _ loaded _ ts'.
  • Hash-diff: comparação de 'md5 (row)' para o detalhe de alterações.
  • Upsert/MERGE: Idempotidade dos downloads.
Exemplo do MERGE (Delta/Iceberg):
sql
MERGE INTO silver. payments s
USING stage. payments_delta d
ON s. transaction_id = d. transaction_id
WHEN MATCHED THEN UPDATE SET
WHEN NOT MATCHED THEN INSERT;

5) Contratos e esquemas

Schema-first: JSON/Avro/Protobuf em Registry; 'schema _ versão' em eventos/arquivos.
Evolução: back-compatível (adição nullable); breaking - '/v2 '+ dupla gravação.
Os campos obrigatórios são 'event _ time (UTC)', 'event _ id', 'trace _ id', 'user _ pseudo _ id', 'market'.

6) DQ-como-código (conjunto mínimo)

yaml table: silver. payments owner: data-payments slo:
freshness_minutes: 15 completeness_percent: 99. 5 rules:
- name: unique_tx # uniqueness of transactions type: unique columns: [transaction_id]
severity: critical
- name: currency_whitelist type: in_set column: currency set: [EUR,USD,GBP,TRY,BRL]
severity: major
- name: amount_positive type: range column: amount_base min: 0. 01 severity: critical
- name: fk_user type: foreign_key column: user_pseudo_id ref_table: dim. users_scd severity: critical

7) Orquestra: DAG 'e, dependentes, SLA

Design DAG: de fontes para vitrines; dependências claras entre as tarefas.
Retraias e idempotidade: backoff, repetições «limpas», checkpoint's.
Deslocamento (catchup): um dogão cuidadoso de períodos perdidos.
SLA, por exemplo, Gold. daily está pronto até as 06:00 locais; alertas de violação.
Configuração: mercados/tenentes/datas via vars; um único modelo de job 'ov.

8) Idempotidade e exactly-once

Em ingest: duplicados podem ser → por «(event _ id, fonte)».
Em processamento: upsert/merge; funções de transformação «limpas».
Em sink: Comites transaccionais ou idempotent writes; Controlo da dupla contabilidade.
Outbox/Inbox: publicação transacional de eventos de domínio do OLTP.

9) Backfill и reprocessing

Backfill: preenchimento inicial/faixas históricas.
Reprocessing: reajuste quando a lógica/correção é alterada.
Guardrails: limites de faixa, quotas, janelas de tempo, dry-run com comparações de métricas.
Marca: 'logic _ version', 'reprocessed _ at', 'recalc _ reason'.

10) Modelagem Silver/Gold

Silver (3NF/BCNF): factos 'fact _ bets/payments/payouts', medições 'dim _ users/games/providers/markets (SCD II)', normalização de moedas/temporizão.
Gold: vitrines denormalizadas sob BI/regulador/modelo; pacotes de exportação imutáveis (WORM) + assinatura.

Exemplo do Gold: GGR Daily

sql
CREATE OR REPLACE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
b. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. games g ON g. game_id = b. game_id
GROUP BY 1,2,3;

11) Privacidade e residência

PII-Minimização: Toquenização; muppings de ID real em um circuito isolado.
RLS/CLS: políticas de acesso por papel/jurisdição, camuflagem.
Residency: diretórios/chaves individuais para EEA/UK/BR; proibição de join's cruzados sem fundamento.
DSAR/PTBF & Legal Hold: edições seletivas, arquivos WORM para relatórios, auditoria de exportações.

12) Observabilidade e SLO

Referências SLI/SLO:
  • Freshness Silver p95 ≤ 15 min; Gold daily está pronto antes das 06:00. do tempo.
  • Completeness ≥ 99. 5%, Validity (esquema) ≥ 99. 9%.
  • Sucesso job's ≥ 99. 0%, MTTR incidentes ≤ 24-48 h.

Dashboards: Freshness heatmap, vórtice de perda DQ, vale & query/GB, lineage-grafo.

13) Desempenho e custo

Particionamento: data/mercado/tenante; clusterização/Z-order por filtros.
Formatos: Parquet + ACID (Delta/Iceberg/Hudi), compressão e estatísticas.
Compactação: luta contra small files (OPTIMIZE/VACUUM).
Materialização: unidades estáveis; evitar os gigantescos on-the-fly join 'ov.
Chargeback: orçamentos, quotas de replay/backfill; planejamento em janelas de baixa carga.

14) Exemplos de tarefas típicas DAG (pseudocode Airflow)

python with DAG("elt_payments_daily", schedule="@daily", start_date=..., catchup=True) as dag:
extract = BashOperator(task_id="extract_cdc", bash_command="run_cdc_to_bronze. sh {{ ds }}")
load  = BashOperator(task_id="load_to_silver", bash_command="sql/run_merge_silver. sql {{ ds }}")
dq   = BashOperator(task_id="dq_checks", bash_command="dq/run_checks. sh silver. payments {{ ds }}")
gold  = BashOperator(task_id="build_gold_ggr", bash_command="sql/build_gold_ggr. sql {{ ds }}")
export = BashOperator(task_id="export_regulator", bash_command="export/run_worm_pack. sh {{ ds }}")

extract >> load >> dq >> gold >> export

15) Processos e RACI

R (Resolvível): Data Engineering (DAG 'i, modelos Silver/Gold), Data Platford (Infra, Registry, DQ).
A (Accountable): Head of Data/CDO.
C (Consulted): Compliance/Legal/DPO (PII/residency/Legal Hold), Finance (FX/GGR), Risk (RG/AML), SRE (SLO/стоимость).
I (Informed): BI/Produto/Marketing/Operações.

16) Mapa de trânsito de implementação

MVP (3-5 semanas):

1. Lakehouse Bronze/Silver (ACID) + CDC/encartes para Payments/Gamplay.

2. Código DQ (10-15 regras) e dashboards de base Freshness/Completeness.

3. Primeira vitrine Gold (GGR Daily) com SLA antes das 06:00, exportação WORM com assinatura.

4. Orquestra DAG e alertas em SLA/DQ.

Fase 2 (5-10 semanas):
  • Extensão de domínios, SCD II para users/games/providers.
  • Camada semântica de métricas; lineage/efeito-análise; procedimentos backfill/reprocessing.
  • Regionalização (EEA/UK), RLS/CLS, controle de custo (quotas/chargeback).
Fase 3 (10-16 semanas):
  • Simulador de réplica (what-if), geração automática de documentação de vitrines/métricas.
  • Otimização de custo (clusterização, materialização, TTL, compactação).
  • Ensinamentos de DR. e time-travel recuperação.

17) Folha de cheque antes de vender

  • Contratos/circuitos em Registry, testes de compatibilidade são verdes.
  • CDC/encartes e MERGE são idimpotentes; Dedup no ingest.
  • As regras DQ estão ativas (critical → fail + DLQ) e as regras SLA são configuradas.
  • As vitrines gold são documentadas com fórmulas de métricas na camada semântica.
  • RBAC/ABAC, criptografia, residência, DSAR/PHILBF/Legal Hold testados.
  • Compactação/OPTIMIZE/VACUUM agendada; limites para backfill/réplicas.
  • Runbook 'e incidentes e reprocessing, auditoria de exportações (WORM + hash).

18) Anti-pattern e riscos

Full reload «por precaução»: use CDC/encartes.
Mistura de dados crus e relatórios: mantenha o Bronze/Silver/Gold separado.
Falta de DQ e lineagem: não há comprovabilidade ou reprodução.
PII em camadas analíticas: isole os muppings, aplique CLS/RLS.
Jobs «noturnos» monolíticos, fracionem, paralelamente às partições.
Sem valor: Siga os small files, materialize as unidades, insira quotas.

19) Glossário (breve)

ETL/ELT - extração/transformação/download (antes/depois do download).
CDC - captura de mudanças.
SCD - histórico de medições (I/II/III).
O WORM é um armazenamento imutável de pacotes de relatórios.
Time-travel - leitura de versões históricas de tabelas.

20) Total

O atual ETL/ELT não é um cenário, mas uma plataforma controlada, como contratos e DQ, encartes idumpotentes/CDC, disciplina de camadas Bronze/Silver/Gold, observabilidade e SLO, privacidade e economia. Seguindo este manual, você receberá linhas de montagem reproduzidas e auditáveis que alimentam estáveis relatórios, produtos e modelos em escala e sem surpresas.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Telegram
@Gamble_GC
Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.