1.1 O problema: dado existe, dado confiável não

Quase toda empresa já tem dados: num banco de produção, numa planilha, num CRM SaaS, nos logs de um servidor, num arquivo que alguém exporta toda segunda-feira. O que quase nenhuma empresa tem de graça é esse dado reunido, limpo, histórico, versionado e disponível no momento em que uma decisão precisa dele.

Engenharia de Dados é a disciplina que projeta e opera os sistemas que transformam dados dispersos e crus em produtos de dados confiáveis: tabelas, APIs e feeds que um analista, um dashboard, um modelo de ML ou um agente de IA podem consumir sem precisar saber de onde aquilo veio nem se está certo.

1.2 Quem faz o quê: o time de dados

Em empresas pequenas, uma pessoa faz vários desses papéis (o famoso "time de dados de 1"). Em empresas grandes, são times separados. O engenheiro de dados fica na fronteira entre os sistemas de produção e o mundo analítico/IA — é quem conhece os dois lados.

1.3 A stack de dados moderna, em uma imagem mental

          FONTES                 INGESTÃO            ARMAZENAMENTO         TRANSFORMAÇÃO           CONSUMO
  ┌───────────────────┐   ┌──────────────┐   ┌──────────────────┐   ┌───────────────┐   ┌────────────────┐
  Banco OLTP (Postgres) ─▶  CDC/Debezium  ─▶
  APIs SaaS (Stripe...) ─▶  Airbyte/ELT   ─▶   Data Lake (S3) +      dbt / Spark SQL      BI / dashboards
  Eventos de app        ─▶  Kafka         ─▶   Lakehouse (Iceberg/  ─▶ modelagem +      ─▶  ML / feature store
  Arquivos (CSV/Parquet)─▶  batch load    ─▶   Delta) ou Warehouse    testes + docs        Reverse ETL → SaaS
  Logs                  ─▶  Fluent Bit    ─▶   (BigQuery/Snowflake)                        Agentes de IA / RAG
  └───────────────────┘   └──────────────┘   └──────────────────┘   └───────────────┘   └────────────────┘
              ▲                                        ▲                       ▲
        Orquestração (Airflow / Dagster / Prefect) coordena tudo: agenda, dependências, retries, backfill
        Governança & observabilidade (catálogo, lineage, testes de qualidade, custo) cobre todas as etapas

Essa é a espinha dorsal de praticamente todo sistema analítico sério em 2026. Cada módulo desta apostila aprofunda uma dessas caixas. Note dois blocos transversais, que atravessam todas as etapas: orquestração (Módulo 6) e governança/observabilidade (Módulo 9).

1.4 As competências de base (o que assumir daqui pra frente)

• SQL de verdade: não só SELECT ... WHERE, mas JOIN, GROUP BY, window functions, CTEs, e entender plano de execução. SQL é a língua franca de dados e não vai a lugar nenhum.
• Python: manipular dados (pandas/Polars), chamar APIs, escrever scripts robustos com tratamento de erro, empacotar código. Não precisa ser cientista da computação, precisa ser confiável.
• Linha de comando + Git: você vai viver no terminal e todo pipeline sério mora num repositório com CI.
• Modelagem de dados: saber desenhar tabelas que fazem sentido para consulta analítica (Módulo 5).
• Noções de sistemas distribuídos e cloud: o porquê de particionar, o que é um objeto no S3, o que custa dinheiro.

2.1 Batch × Streaming

2.2 ETL × ELT

As três letras: Extract (tirar da fonte), Transform (limpar, juntar, aplicar regra de negócio), Load (gravar no destino analítico). O que mudou foi a ordem:

• ETL (clássico, anos 1990–2010): transforma antes de carregar, num servidor de processamento dedicado. Nasceu quando armazenamento em data warehouse era caríssimo — você só guardava o dado já refinado.
• ELT (padrão moderno): carrega o dado cru no lake/warehouse primeiro e transforma lá dentro, com SQL, usando o poder de processamento elástico da própria plataforma. Virou padrão porque armazenamento ficou barato e warehouses/engines ficaram absurdamente rápidos.

Vantagens do ELT que caem em entrevista: você preserva o dado bruto (pode reprocessar com lógica nova sem re-extrair da fonte), a transformação vira código SQL versionado e testável (dbt), e você não mantém um servidor de ETL separado.

2.3 OLTP × OLAP

2.4 Formatos de arquivo: o detalhe que decide o custo

Regra prática: Avro (ou Protobuf) no transporte de eventos; Parquet no armazenamento analítico. CSV e JSON são formatos de borda — tolere na entrada, nunca deixe virar a base do seu lake.

3.1 As quatro fontes e como se lê cada uma

3.2 Full load × incremental

• Full load: copia a tabela inteira toda vez. Simples e sempre correto, mas caro e lento acima de alguns milhões de linhas. Ótimo para tabelas pequenas e dimensões.
• Incremental por marca d'água (watermark): guarda o maior updated_at (ou id) já carregado e, na próxima execução, pega só WHERE updated_at > :ultima_marca. Barato, mas exige que a fonte tenha uma coluna confiável de atualização e não perde deletes (a linha apagada some da fonte sem deixar rastro).

# Ingestão incremental com a biblioteca dlt (Python) — padrão enxuto e testável
import dlt
from dlt.sources.sql_database import sql_database

pipeline = dlt.pipeline(
    pipeline_name="vendas",
    destination="filesystem",          # grava Parquet no lake
    dataset_name="bronze",
)

source = sql_database().with_resources("pedidos", "itens_pedido")
# incremental: dlt guarda o estado do cursor entre execuções
source.pedidos.apply_hints(incremental=dlt.sources.incremental("updated_at"))

info = pipeline.run(source, write_disposition="merge", primary_key="id")
print(info)

3.3 CDC — Change Data Capture o jeito profissional de ler um banco

Em vez de consultar a tabela periodicamente, o CDC lê o log de transações do banco (o WAL do Postgres, o binlog do MySQL) e emite um evento para cada INSERT, UPDATE e DELETE. Vantagens decisivas:

• Captura deletes e updates — o incremental por watermark não captura.
• Não pesa na fonte: ler o log não compete com as consultas da aplicação.
• Baixa latência: a mudança aparece no destino em segundos.
• Histórico completo: você vê a sequência de estados de cada linha, não só o valor atual.

// Evento CDC do Debezium para um UPDATE (formato resumido)
{
  "op": "u",                          // c=create, u=update, d=delete, r=snapshot
  "ts_ms": 1738000000000,
  "before": { "id": 42, "status": "pendente" },
  "after":  { "id": 42, "status": "pago" },
  "source": { "table": "pedidos", "lsn": 987654321 }
}

Arquitetura clássica: Debezium (conector) lê o WAL → publica no Kafka → um consumidor (ou Kafka Connect com sink) grava no lakehouse, onde um MERGE aplica os eventos na tabela final. É assim que se mantém uma réplica analítica quase em tempo real de um banco de produção.

3.4 Idempotência e entrega: os dois problemas que sempre voltam

• Idempotência: rodar a mesma carga duas vezes deve dar o mesmo resultado que rodar uma. Consegue-se com MERGE/upsert por chave (em vez de INSERT), ou escrevendo em partições que são substituídas inteiras (overwrite da partição do dia). Sem idempotência, todo retry vira dado duplicado.
• Semânticas de entrega: at-most-once (pode perder), at-least-once (pode duplicar — o padrão realista), exactly-once (não perde nem duplica — caro, exige transações do fim ao fim). Na prática você projeta para at-least-once + consumidor idempotente, que dá o efeito de exactly-once sem o custo.

4.1 Data Warehouse o clássico que funciona

Um banco analítico gerenciado, colunar, otimizado para SQL sobre grandes volumes: BigQuery, Snowflake, Redshift, Databricks SQL. Você joga dados estruturados dentro, escreve SQL, e a plataforma cuida de armazenamento, índice, escala e otimização.

• Prós: SQL puro, rapidíssimo, governança madura (permissões, auditoria), zero infra para gerir.
• Contras: dado semiestruturado e não estruturado (imagem, áudio, texto livre, logs brutos) cabe mal; você fica preso ao formato interno do fornecedor; custo de armazenamento é mais alto que object storage cru.

4.2 Data Lake barato e flexível, perigoso se largado

Object storage (S3, GCS, Azure Blob) cheio de arquivos — Parquet, JSON, CSV, imagens — organizados em pastas. Barato, guarda qualquer coisa, qualquer engine lê (Spark, Trino, DuckDB).

4.3 Lakehouse o padrão de 2026

A ideia: ficar com o armazenamento barato e aberto do lake (Parquet no S3) e ganhar por cima dele as garantias do warehouse — transações ACID, esquema forçado, evolução de esquema, versionamento (time travel), UPDATE/DELETE/MERGE. Isso é feito por uma camada de formato de tabela aberto que fica entre os arquivos e as engines:

Como funciona por baixo (vale para os três): além dos arquivos Parquet de dados, existe uma camada de metadados — arquivos de manifesto que listam quais Parquet compõem a tabela naquela versão. Um commit é trocar o ponteiro de metadados atomicamente. Daí saem: transações (leitores veem sempre uma versão consistente), time travel (basta apontar para um snapshot antigo), e DELETE sem reescrever tudo (marca arquivos/linhas como removidos).

-- Com uma tabela Iceberg, isto simplesmente funciona sobre arquivos no S3:
MERGE INTO silver.clientes t
USING bronze.clientes_cdc s ON t.id = s.id
WHEN MATCHED AND s.op = 'd' THEN DELETE
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

-- time travel: como estava a tabela ontem?
SELECT * FROM silver.clientes FOR TIMESTAMP AS OF '2026-08-29 00:00:00';

4.4 Arquitetura Medallion (bronze / silver / gold)

A forma canônica de organizar as camadas dentro do lakehouse:

Por que essa separação importa: quando uma regra de negócio muda, você reescreve silver/gold e faz backfill a partir do bronze, sem tocar na fonte. Quando um dashboard está errado, você sabe em qual camada investigar.

4.5 Warehouse ou lakehouse? a decisão real

Na prática, muitos times fazem híbrido: lake/lakehouse para bronze/silver e ingestão bruta, warehouse (ou a camada SQL do próprio lakehouse) para gold e BI. E a fronteira está se dissolvendo: Snowflake e BigQuery leem Iceberg nativamente hoje.

5.1 dbt: transformação como engenharia de software

dbt (data build tool) é o padrão de fato da camada T do ELT. A ideia é simples e poderosa: você escreve cada transformação como um SELECT num arquivo .sql, e o dbt cuida de criar a tabela/view, resolver a ordem de execução (grafo de dependências), rodar testes e gerar documentação.

-- models/silver/stg_pedidos.sql
with fonte as (
    select * from {{ source('bronze', 'pedidos') }}
),
limpo as (
    select
        id                              as pedido_id,
        cliente_id,
        lower(trim(status))             as status,
        valor_centavos / 100.0          as valor_reais,
        cast(criado_em as timestamp)     as criado_em
    from fonte
    where id is not null
)
select * from limpo

# models/silver/stg_pedidos.yml — testes e documentação junto do modelo
models:
  - name: stg_pedidos
    description: "Pedidos limpos e tipados, um por linha."
    columns:
      - name: pedido_id
        description: "Chave primária do pedido."
        tests: [unique, not_null]
      - name: status
        tests:
          - accepted_values: { values: ['pago', 'pendente', 'cancelado'] }
      - name: cliente_id
        tests:
          - relationships: { to: ref('stg_clientes'), field: cliente_id }

O que o dbt te dá "de graça": dbt run materializa tudo na ordem certa; dbt test valida os contratos; dbt docs gera um site navegável com o lineage (de qual fonte cada coluna veio); ref() torna o grafo de dependências explícito; ambientes (dev/prod) isolados; e versionamento git com pull request e CI como qualquer código.

5.2 Materializações

5.3 Modelagem dimensional: star schema o que BI espera

A camada gold quase sempre segue o esquema estrela (Kimball): uma tabela fato no centro, cercada de tabelas dimensão.

• Fato (fct_): os eventos mensuráveis do negócio. Cada linha é uma ocorrência (uma venda, um clique, um pagamento). Colunas = chaves para as dimensões + métricas numéricas aditivas (valor, quantidade). Cresce sem parar.
• Dimensão (dim_): o contexto descritivo pelo qual você fatia as métricas — dim_cliente, dim_produto, dim_data, dim_loja. Colunas = atributos textuais para filtrar e agrupar. Muda devagar.

                    ┌─────────────┐
                    │  dim_data   │
                    └──────┬──────┘
   ┌─────────────┐   ┌─────┴───────┐   ┌──────────────┐
   │ dim_cliente ├───┤ fct_vendas  ├───┤ dim_produto  │
   └─────────────┘   │ (grão: 1    │   └──────────────┘
                     │  item de    │
                     │  pedido)    │
                     └─────┬───────┘
                    ┌──────┴──────┐
                    │  dim_loja   │

5.4 Slowly Changing Dimensions (SCD) avançado

Um cliente muda de cidade. A dimensão deve refletir só o valor atual, ou preservar o histórico?

• SCD Tipo 1: sobrescreve. Simples; perde história. Bom quando o passado não importa (corrigir um erro de digitação).
• SCD Tipo 2: cria uma nova linha para o novo estado, com valido_de, valido_ate e uma flag is_current. Preserva o histórico — a venda de janeiro continua ligada à cidade que o cliente tinha em janeiro. É o tipo que cai em entrevista; o dbt tem a macro snapshot pronta para isso.

6.1 Por que orquestração existe

Um pipeline real não é um script. É: "às 2h, extraia 6 fontes (algumas dependem de VPN); quando todas terminarem, rode 40 modelos dbt na ordem certa; se o modelo de receita passar nos testes, atualize o dashboard e o feed de ML; se qualquer coisa falhar, tente de novo 3 vezes com espera crescente e, se ainda falhar, chame alguém no Slack; e se eu precisar recalcular março inteiro, me deixe reprocessar dia a dia sem duplicar nada".

Um orquestrador resolve isso: você descreve o DAG (grafo acíclico dirigido) de tarefas e dependências, e ele cuida de agendamento, execução, paralelismo, retries, estado, histórico e observabilidade.

6.2 As três ferramentas

# Airflow 2/3 — DAG com a TaskFlow API
from airflow.decorators import dag, task
from pendulum import datetime

@dag(
    schedule="0 2 * * *",               # todo dia às 2h
    start_date=datetime(2026, 1, 1),
    catchup=False,                       # não reprocessa o passado ao ligar
    default_args={"retries": 3, "retry_delay": 300},
    tags=["vendas"],
)
def pipeline_vendas():

    @task
    def extrair(fonte: str) -> str:
        # idempotente: sobrescreve a partição da data de execução
        return carregar_bronze(fonte, particao="{{ ds }}")

    @task
    def transformar(caminhos: list): dbt_run(select="silver+ gold+")

    @task
    def publicar(): atualizar_marts_e_feature_store()

    dados = extrair.expand(fonte=["pedidos", "itens", "clientes"])
    transformar(dados) >> publicar()

pipeline_vendas()

6.3 Os conceitos que você tem que dominar

• Agendamento e data interval: o Airflow pensa em janelas. O run "de 29/08" processa os dados do dia 29 e roda depois que o dia fecha. A variável {{ ds }} (data do intervalo, não "hoje") é o que torna o pipeline reprodutível.
• Idempotência + backfill: como cada run é ligado a uma data e sobrescreve a partição daquela data, você pode reexecutar qualquer intervalo (backfill) e o resultado é o mesmo. Pipeline não idempotente + backfill = dados duplicados.
• catchup: ao ativar um DAG com start_date no passado, catchup=True faz ele rodar todos os intervalos perdidos. Quase sempre você quer catchup=False e faz backfill manual e controlado.
• Retries com backoff: falhas transitórias (rede, rate limit) se resolvem sozinhas em 3 tentativas com espera crescente. Falhas de lógica não — não mascare bug com retry.
• Sensores e event-driven: esperar um arquivo chegar, uma tabela ficar pronta, um evento externo. Prefira sensores em modo reschedule/deferrable para não segurar um worker parado.
• Idempotência de side effects: se a tarefa manda e-mail ou dispara pagamento, retry pode reenviar. Proteja com chave de idempotência.
• SLA e alertas: "esse dado tem que estar pronto até 6h". O orquestrador dispara alerta se estourar, mesmo sem erro.

7.1 Quando você realmente precisa de distribuído

7.2 Como o Spark divide o trabalho

• Partições: o Spark quebra o dataset em pedaços (partições); cada core processa uma partição por vez, em paralelo, entre os nós do cluster.
• Transformações lazy: filter, select, join não executam na hora — constroem um plano. Só uma ação (write, count, collect) dispara a execução, e aí o otimizador (Catalyst) reescreve o plano inteiro.
• Narrow vs wide transformations: narrow (map, filter) processa cada partição isolada — barato. Wide (groupBy, join, distinct) precisa redistribuir dados entre nós pela chave — isso é o shuffle.

Shuffle: o gargalo que você tem que conhecer avançado

O shuffle escreve dados em disco e os transfere pela rede entre executores para reagrupá-los por chave. É a operação mais cara do Spark e a causa nº 1 de jobs lentos. Você reduz shuffle:

• Filtrando cedo (menos dado entra no shuffle) e selecionando só as colunas necessárias.
• Broadcast join: se um lado do join é pequeno (< ~10–100 MB), o Spark envia uma cópia dele para todos os nós e evita o shuffle do lado grande. O Adaptive Query Execution faz isso sozinho em versões recentes.
• Evitando data skew: se 80% das linhas têm a mesma chave, uma partição fica gigante e o job todo espera por ela. Técnicas: salting da chave, ou deixar o AQE dividir a partição quente.

# PySpark: leitura de Parquet particionado, filtro cedo, join com broadcast
from pyspark.sql import functions as F
from pyspark.sql.functions import broadcast

vendas = (spark.read.parquet("s3://lake/silver/vendas/")
          .filter(F.col("data").between("2026-01-01", "2026-06-30"))   # predicate pushdown
          .select("data", "loja_id", "valor"))

lojas = spark.read.parquet("s3://lake/silver/dim_loja/")              # pequena

resultado = (vendas.join(broadcast(lojas), "loja_id")                     # sem shuffle do lado grande
             .groupBy("regiao", "data").agg(F.sum("valor").alias("receita")))

resultado.write.mode("overwrite").partitionBy("data").parquet("s3://lake/gold/receita_regiao/")

7.3 O ecossistema de engines em 2026

8.1 Kafka: o log distribuído, append-only

Kafka não é uma fila que apaga a mensagem depois de lida. É um log particionado e durável: produtores anexam registros ao fim de um tópico; consumidores leem em seu próprio ritmo, guardando um offset (posição). Os dados ficam por um tempo de retenção configurável (dias, semanas ou "para sempre" com compaction).

• Tópico → partições: o paralelismo. A ordem é garantida dentro de uma partição, não entre partições. A chave do registro decide a partição (mesma chave → mesma partição → ordem preservada para aquela entidade).
• Consumer group: N consumidores dividem as partições de um tópico entre si; escala horizontal de leitura até o nº de partições.
• Replicação: cada partição tem réplicas em brokers diferentes; um leader atende, os followers copiam. acks=all + min.insync.replicas=2 = escrita durável.
• Schema Registry: contratos de esquema (Avro/Protobuf) versionados para produtores e consumidores não quebrarem um ao outro.

8.2 O que muda ao processar um fluxo infinito

Tempo de evento × tempo de processamento

Um clique aconteceu às 20h59 (event time) mas chegou ao seu processador às 21h03 (processing time), porque o celular estava sem sinal. Se você agrega por tempo de processamento, esse clique cai na janela errada. Sistemas sérios agregam por event time — e para isso precisam de watermarks.

Watermark

Um watermark é a afirmação do sistema: "acredito que já não vou receber eventos com timestamp anterior a T". Ele avança conforme o tempo de evento observado, com uma folga configurável (ex.: "tolero 5 min de atraso"). Quando o watermark passa do fim de uma janela, a janela fecha e emite o resultado. Eventos que chegam depois disso são late data: descartados, enviados para um side output, ou aplicados como atualização, conforme a política.

Tipos de janela

• Tumbling (fixa): blocos contíguos sem sobreposição — "a cada 1 min".
• Sliding (deslizante): janelas que se sobrepõem — "últimos 5 min, atualizando a cada 1 min".
• Session (sessão): agrupa eventos separados por menos de um gap de inatividade — sessão de navegação de um usuário.

8.3 Flink × Spark Structured Streaming × Kafka Streams

-- Flink SQL: contagem de eventos por minuto, por tipo, tolerando 30 s de atraso
SELECT
    window_start,
    tipo,
    COUNT(*) AS total
FROM TABLE(
    TUMBLE(TABLE eventos, DESCRIPTOR(ts_evento), INTERVAL '1' MINUTE)
)
GROUP BY window_start, tipo;

-- ts_evento é event time; o watermark foi definido no DDL da tabela:
--   WATERMARK FOR ts_evento AS ts_evento - INTERVAL '30' SECOND

8.4 Exactly-once na prática avançado

"Exactly-once" de verdade não significa que cada mensagem é fisicamente processada uma vez — significa que o efeito observável é como se fosse. Consegue-se combinando:

• Checkpointing: o processador salva periodicamente seu estado + os offsets lidos, de forma atômica. Em falha, ele volta ao último checkpoint e reprocessa a partir dali.
• Sink transacional ou idempotente: a escrita no destino participa da mesma transação do checkpoint (Kafka transactions, two-phase commit no Flink) ou o destino aceita a mesma linha duas vezes sem efeito (upsert por chave).

9.1 Data quality: as seis dimensões

# Great Expectations / dbt tests / Soda — a ideia é a mesma: contratos executáveis
# exemplo em dbt: teste custom de reconciliação (a soma tem que bater com a origem)
# tests/assert_receita_bate_com_origem.sql — o teste passa se retornar 0 linhas
with destino as (select sum(valor_reais) v from {{ ref('fct_vendas') }} where data = '{{ var("run_date") }}'),
     origem  as (select sum(valor_centavos)/100.0 v from {{ source('bronze', 'pedidos') }} where data = '{{ var("run_date") }}')
select destino.v, origem.v
from destino, origem
where abs(destino.v - origem.v) > 0.01

9.2 Data contracts avançado

O maior gerador de incidentes de dados: um time de produto renomeia uma coluna, muda um tipo ou o significado de um enum, sem avisar — e três pipelines quebram silenciosamente rio abaixo. Um data contract é um acordo versionado e validado em CI entre quem produz e quem consome o dado: esquema, tipos, semântica, garantias de qualidade, SLA de atualização, e política de mudança (o que exige major version). Na prática: um arquivo YAML/JSON Schema no repositório do produtor, checado no pipeline de deploy dele — a mudança incompatível falha o build do time de origem, não o seu dashboard às 8h.

9.3 Observabilidade de dados

Monitoramento de infra (CPU, "o job terminou?") não detecta o pior tipo de falha: o pipeline rodou com sucesso e entregou dado errado. Observabilidade de dados acrescenta cinco sinais (os "pilares", popularizados por ferramentas como Monte Carlo, e hoje também open source com Elementary, re_data, Soda):

• Freshness: a tabela atualizou dentro do esperado?
• Volume: o nº de linhas está dentro da faixa histórica? (queda de 40% = alerta)
• Schema: colunas adicionadas/removidas/retipadas sem aviso?
• Distribuição: % de nulos, cardinalidade, min/max, média — desviaram do normal?
• Lineage: quando algo quebra, quais tabelas e dashboards a jusante são afetados? (impacto) e de onde veio? (causa raiz)

9.4 Catálogo, lineage e governança

• Catálogo de dados (DataHub, OpenMetadata, Unity Catalog, Amundsen): inventário pesquisável de todas as tabelas — descrição, dono, freshness, colunas, tags de PII, popularidade. Responde "que tabela eu uso para receita e posso confiar nela?".
• Lineage em nível de coluna: "esta métrica do dashboard vem de qual coluna de qual fonte, passando por quais modelos?". Essencial para auditoria e análise de impacto.
• Governança e privacidade: classificar PII, mascarar/tokenizar dado sensível, controle de acesso por linha/coluna, políticas de retenção, e o direito ao esquecimento (LGPD/GDPR) — que num lake imutável exige desenho específico (ex.: crypto-shredding: apagar a chave de criptografia daquele titular).

9.5 FinOps de dados: o custo é um requisito

• Storage: compacte arquivos pequenos (o "small files problem" mata performance e custo), use formatos colunares, defina políticas de tiering e expiração, remova snapshots antigos do Iceberg/Delta (VACUUM/expire_snapshots).
• Compute: particione para que consultas leiam menos; materialize incremental em vez de full-refresh; desligue clusters ociosos; monitore as 10 consultas mais caras do mês.
• Alertas de custo: um bug de JOIN cartesiano pode gerar uma fatura de milhares num fim de semana — tenha limite e alerta.

9.6 DataOps: rodar isso como time

• Tudo em git + CI/CD: modelos dbt, DAGs e configs em repositório; PR com review; CI roda testes de dados e dbt build num ambiente efêmero antes do merge.
• Ambientes isolados: dev / staging / prod com dados e permissões separados.
• Idempotência e replay em todo lugar (Módulos 3 e 6) — é o que torna incidente recuperável.
• On-call e runbooks: alerta acionável (não ruído), com dono claro e passo a passo de diagnóstico. Postmortem sem culpa após incidente.
• SLAs/SLOs de dados publicados: "a tabela X está pronta até 7h em 99% dos dias".

10.1 Roadmap de estudo (12 semanas, para quem já sabe SQL e Python básico)

Escolha uma nuvem para aprofundar (AWS é a mais pedida; GCP tem o BigQuery, muito comum; Azure aparece em corporações). Os conceitos transferem; o que muda são nomes de serviços.

10.2 Banco de perguntas de entrevista (com a resposta que aprova)

10.3 Projetos de portfólio que geram entrevista

1. Lakehouse ponta a ponta (o projeto-âncora): ingestão de uma API pública (ou dataset como o de táxis de NYC) → bronze em Iceberg/Delta → dbt para silver/gold com star schema → Airflow orquestrando tudo → testes em CI → um dashboard simples (Metabase/Streamlit). README explicando cada escolha. Este projeto sozinho já cobre 80% de uma entrevista.
2. CDC em tempo quase real: Postgres + Debezium + Kafka + consumidor que faz MERGE num Iceberg; painel mostrando o lag. Diferencial: demonstrar deletes propagando corretamente.
3. Comparativo de engines: a mesma transformação de ~50 GB em pandas, Polars, DuckDB e Spark, com tabela de tempo/memória/custo e uma conclusão honesta sobre quando cada uma vale a pena.
4. Pipeline de streaming: gerador de eventos → Kafka → Flink SQL com janela por event time e watermark → sink agregado; documentar o comportamento com dados atrasados.

Em todos: o README é o que o recrutador técnico lê. Explique o porquê de cada ferramenta, os trade-offs aceitos, e mostre um diagrama da arquitetura. Código limpo com decisões mal justificadas perde para arquitetura simples bem explicada.

10.4 Certificações e leituras que pesam

• Certificações com valor real: dbt Analytics Engineering Certification; Astronomer Certified: Airflow Fundamentals; Databricks Certified Data Engineer Associate/Professional; Google Professional Data Engineer; AWS Data Engineer Associate. Escolha a que casa com a stack das vagas que você quer.
• Leituras de referência: Fundamentals of Data Engineering (Reis & Housley) — o mapa da disciplina, leitura quase obrigatória; Designing Data-Intensive Applications (Kleppmann) — os fundamentos de sistemas distribuídos que sustentam os Módulos 3, 7 e 8; The Data Warehouse Toolkit (Kimball) — a bíblia da modelagem dimensional do Módulo 5.
• Prática contínua: tudo desta apostila roda local e de graça — duckdb, dbt-core, airflow standalone, docker compose com Kafka + Debezium, Iceberg/Delta via PySpark. Monte um repositório-laboratório e vá acumulando.