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
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.
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).
- 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.