Selo de estado:
Preview(teto atual do produto) · Curso ACD-100 — Fundamentos Ingestia · Aula 6 de 10 · Atualizado em 2026-10-04.
Objetivo#
Ao final desta aula você vai descrever Bronze/Silver/Gold, push×pull, isolamento — e desenhar, para qualquer tabela sua, o caminho da fonte até o datamart que o painel lê, com os nomes reais de cada parada.
Vídeo#
Identificador no manifesto: acd-100-06-como-os-dados-fluem · duração-alvo 8 min · tela do produto: /overview.
Roteiro de gravação (6 capítulos):
| # | Minutagem-alvo | Capítulo | Tela do produto |
|---|---|---|---|
| 1 | 0:00–0:30 | Abertura: título + selo. "A ideia em uma frase": cópia crua auditável → limpa e organiza → tabelas prontas, tudo isolado por cliente. | /overview |
| 2 | 0:30–2:00 | As 5 estações no desenho: Fonte → Landing → Bronze → Silver → Gold → Dashboard/Q&A. Uma frase por estação. | /overview |
| 3 | 2:00–3:45 | O que cada camada faz com a tabela vendas: Bronze verbatim com carimbos; Silver com regras de qualidade e deduplicação (rejeitadas sempre visíveis); Gold com os marts agregados. | /sources (hub de uma fonte) |
| 4 | 3:45–5:00 | Push × pull; full × incremental por watermark × backfill. Honestidade: não é CDC — CDC é Roadmap. | /sources |
| 5 | 5:00–6:30 | Isolamento por workspace: datasets e landing por prefixo; segredos redigidos. As duas trilhas ao vivo (validar → landing → bronze → registrar e ingest → bronze → silver → gold → publish). | /dags |
| 6 | 6:30–8:00 | Estado Preview / NÃO MEDIDO, erros comuns e o "faça você mesmo": desenhar o caminho de vendas até aurora_gold. | /overview |
Conteúdo#
A ideia em uma frase
O Ingestia pega dados que já existem no seu negócio (banco, planilha, ERP, arquivos), guarda uma cópia crua e auditável, limpa e organiza essa cópia e, no final, entrega tabelas prontas (marts) para dashboards e perguntas em linguagem natural — tudo isolado por cliente (workspace).
As 5 estações
Fonte → Landing → Bronze → Silver → Gold → Dashboard / Q&A- Fonte — de onde o dado vem: banco (PostgreSQL, MySQL, SQL Server, Oracle, BigQuery), planilha (Google Sheets), ERP/CRM (Omie, Bling, Conta Azul, Tiny, NF-e, Salesforce, HubSpot), anúncios (Meta Ads, Google Ads) ou arquivos (CSV, JSON, Parquet). Qual desses está disponível hoje é o catálogo de conectores que diz (aula 7).
- Landing — a zona de pouso no Google Cloud Storage. Os brutos chegam aqui antes de qualquer transformação: o "banco de imagens" do dado como ele chegou.
- Bronze — o dado carregado verbatim (cru, como texto), sem conversão, com carimbos de auditoria
_ingest_at,_source,_row. Nada é descartado aqui. - Silver — o dado limpo e tipado: regras de qualidade, deduplicação e derivações (ex.:
receita = preço × quantidade). O que reprova nas regras é contado e fica de fora — a diferença nunca some em silêncio. - Gold — os datamarts agregados, prontos para consumo (receita por mês, por UF, por categoria, KPIs). É o que os dashboards e a IA leem.
Esse desenho de três camadas é o medalhão. Ele separa "o que chegou" de "o que está limpo" de "o que está pronto" — assim um erro de limpeza nunca destrói o dado original.
O que cada camada faz com vendas
A implementação de referência usa uma tabela sintética vendas com pedido_id, data_pedido, cliente_id, uf, categoria, produto, preco_unitario, quantidade, forma_pagamento, status.
| Camada | O que acontece |
|---|---|
| Bronze | Cada linha entra como texto, em transação, com _ingest_at, _source, _row. Garante o número de campos (preenche faltantes com ""). Nunca descarta linha. |
| Silver | Regras linha a linha — uma reprovação = linha descartada e contada: status cancelado sai; quantidade precisa ser inteiro > 0; preço aceita formato BR (1.299,90) e US (199.90) e precisa ser > 0; data YYYY-MM-DD válida (deriva mes); UF normalizada para 2 letras; pedido_id obrigatório; categoria vazia vira "Sem categoria" (não descarta); deduplicação por pedido_id, mantendo a 1ª ocorrência; receita derivada. |
| Gold | Marts recriados a cada run (idempotente): gold_receita_mensal, gold_receita_uf, gold_receita_categoria (com share) e gold_kpis (receita total, pedidos, ticket médio, nº de UFs, período). Cada run grava um registro em pipeline_runs. |
| Publish | Rodar o pipeline republica o painel gold — os dados ficam visíveis sem ação manual. |
A regra de ouro da Silver: rejectedRows = bronzeRows − silverRows. A diferença é sempre visível.
Push × pull
| Modelo | Como funciona | Exemplos |
|---|---|---|
| Pull ("Nós buscamos") | O Ingestia conecta na sua fonte e puxa no horário agendado. | Banco de dados, BigQuery, ERP/CRM, anúncios, Google Sheets, object storage |
| Push ("Você deposita") | Você envia os arquivos para a landing e o Ingestia carrega no Bronze. | Upload de CSV / JSON / Parquet |
Fontes de arquivo aceitam os dois modos. Bancos e SaaS são sempre pull.
Depois da primeira carga
A primeira carga traz o histórico. Depois, cada atualização pode ser full (recalcula tudo; sempre correta, mais cara; o fallback seguro), incremental por watermark (só o que é novo desde a última execução, usando uma coluna crescente como marca d'água; muito mais barata) ou backfill (um histórico maior sob demanda).
Incremental por watermark não é CDC
A carga incremental do Ingestia é por marca d'água, não captura de INSERT/UPDATE/DELETE do log da fonte. CDC de verdade é Roadmap — não existe hoje. Não prometa "replicação em tempo real".
Onde cada cliente mora
Cada workspace tem o seu próprio espaço, derivado de um prefixo saneado: datasets <prefix>_bronze, <prefix>_silver, <prefix>_gold e landing gs://{bucket}/landing/{prefix}/.... Um cliente nunca lê o dataset ou o bucket de outro — invariante de todas as páginas de Dados. Segredos de conexão são cifrados e redigidos em qualquer log ou mensagem de erro.
Como aparece no produto
O produto mostra o progresso ao vivo em duas trilhas:
- Ingestão de uma fonte (hub da fonte em
/sources/[id], botão Processar agora):validar → landing → bronze → registrar— confere a conexão, envia os brutos à landing, carrega verbatim na Bronze e atualiza o catálogo (lastSyncAt). - Pipeline de engenharia (
/pipeline):ingest → bronze → silver → gold → publish.
Na tela de execução você confere os contadores Bronze / Silver / rejeitadas e os marts Gold gerados. Se a fonte mudar de formato, o schema drift avisa: coluna nova é info (aditivo, nada quebra); coluna removida, tipo mudado ou tabela removida são atencao (um mart que lê aquilo quebra). Se um cabeçalho vier com acento ou espaço, o saneamento automático reescreve o nome e recarrega — sem inventar dado.
Exemplo: três linhas da Aurora
O CSV vendas.csv chega com P-1001 (SP, pago), P-1002 (RJ, pago) e P-1003 (MG, cancelado). O caminho: vendas.csv → landing/aurora/... → aurora_bronze (3 linhas, todas como texto) → aurora_silver (2 linhas; P-1003 reprovou por status; rejectedRows = 1; preços 12,90 e 29,90 viraram número; receita calculada) → aurora_gold (receita por UF: SP e RJ). O painel "Vendas por filial" e a pergunta "qual filial mais vendeu" leem só o Gold.
Erros comuns
- Achar que a Bronze "limpa". Ela guarda tudo; limpeza é Silver.
- Apontar o painel para Bronze ou Silver. BI lê Gold — e o desafio prático do selo Fundamentos reprova widget que referencia
*_bronze. - Ler rejeitadas como perda. São contadas e visíveis de propósito; investigue a regra que reprovou.
- Esperar que o fim da DAG atualize todo painel. A atualização do dashboard é uma etapa própria (aula 8).
Estado: Preview, com NÃO MEDIDO onde é nuvem
O pipeline determinístico é provado em teste. A execução real em BigQuery/Cloud Run é NÃO MEDIDO: custo e latência de nuvem não são publicados. Sem o ambiente de nuvem do workspace configurado, a execução falha com mensagem em vez de fingir sucesso.
Faça você mesmo#
Desenhe o caminho de vendas até aurora_gold no workspace de treino Aurora Varejo:
- Numa folha ou no bloco de notas, escreva as 5 estações em linha: Fonte → Landing → Bronze → Silver → Gold.
- Em Orquestração → Pipelines (
/sources), abra a fonte de vendas e localize a trilhavalidar → landing → bronze → registrarao lado de Processar agora. Não clique ainda — a execução é tema da aula 7. - Escreva embaixo de cada estação o nome real do destino:
landing/aurora/...,aurora_bronze,aurora_silver,aurora_gold. - Pegue as três linhas do exemplo (
P-1001,P-1002,P-1003), marque qual não passa da Silver e por qual regra; calculerejectedRows. - Classifique em push ou pull: upload de CSV, PostgreSQL, Omie.
- Marque no desenho onde o painel e a IA leem (só Gold) e onde está o isolamento (o prefixo
aurorano dataset e na landing).
Você terminou quando o seu desenho tem as cinco estações com nomes reais, uma linha rejeitada com a regra justificada, a classificação push/pull correta e o Gold como única leitura do BI e da IA.
Checagem rápida#
Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.
Documentação relacionada#
Capacidades ensinadas#
(conceitual — sem capacidade específica da matriz) — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".