Tudo que você vai construir no Lakehouse: Pipeline na Prática

• Por que "Lakehouse" e não Data Warehouse ou Data Lake puro: limitações de cada um
• A Medallion Architecture explicada em 3 caixas: Bronze (cru), Silver (limpo), Gold (analítico)
• O que cada ferramenta da stack faz em uma linha
• Diagrama final que você vai construir nas próximas 5 semanas
• Pré-requisitos da máquina: Docker Desktop, RAM, disco

1. Setup do projeto — clonar o repositório base com docker-compose.yml da turma, estrutura de pastas, .env template
2. Subir MinIO — docker compose up minio, acessar console em localhost:9001, criar buckets bronze, silver, gold
3. Subir Spark + Iceberg — container tabulario/spark-iceberg, validar com pyspark interativo, criar primeiro catálogo Iceberg apontando pro MinIO
4. Subir Airflow — docker compose up airflow-webserver airflow-scheduler, acessar UI em localhost:8080, login admin/admin, ver DAGs de exemplo
5. Subir Superset — docker compose up superset, acessar em localhost:8088, criar conta admin, deixar conexão pra Spark Thrift configurada (sem dados ainda)
6. Teste smoke — criar uma tabela Iceberg vazia, escrever 3 linhas, ler de volta, ver o arquivo Parquet no MinIO
7. Tour rápido dos UIs — onde olhar quando algo quebrar: MinIO logs, Spark UI, Airflow logs

• Mudar a porta padrão do Superset para localhost:8090 e validar que continua funcionando
• Criar mais um bucket no MinIO chamado staging e tirar screenshot
• Postar no canal da turma um print do docker compose ps mostrando todos os containers em estado running

• O dataset Olakehouse: o que cada CSV contém e como se relacionam (diagrama ER simplificado)
• Bronze ≠ "jogar CSV no S3": qual é a regra do jogo da camada cru
• Por que Iceberg e não Parquet puro: ACID, time travel, schema evolution em 3 exemplos visuais
• Conceito de "catalog" no Iceberg — onde mora o metadado

1. Baixar o dataset Olakehouse — script que pega os 9 CSVs e coloca em data/raw/
2. Subir os CSVs pro MinIO — usando mc (MinIO client) ou boto3, copiar pra bucket bronze/_raw/olakehouse/
3. Criar o catálogo Iceberg — configuração Spark apontando catalog olakehouse pro warehouse no MinIO bucket bronze
4. Ler primeiro CSV via PySpark — spark.read.csv("s3a://bronze/_raw/olakehouse/orders.csv"), inspecionar schema, mostrar problemas óbvios (datas como string, valores nulos)
5. Escrever como tabela Iceberg — df.writeTo("olakehouse.bronze.orders").create(), ver no MinIO os arquivos Parquet + pasta metadata/
6. Repetir pros 9 CSVs — em loop ou um por um, na prática é mecânico
7. Demo de time travel — re-ingerir orders.csv adulterado (apagar 10 linhas), depois recuperar a versão anterior com VERSION AS OF
8. Demo de schema evolution — adicionar coluna nova em orders, ver que as queries antigas não quebram

• Adicionar uma 10ª "tabela" Bronze sintética chamada evento_curso com os campos aluno, data, evento — popular com 3 linhas reais (seu nome, a data de hoje, "ingestao_concluida")
• Apagar a versão atual e usar time travel pra recuperar
• Postar no canal o snippet SQL/PySpark do time travel funcionando

• Silver vs Gold: o que muda em cada camada e por quê
• Modelagem dimensional na unha — fato e dimensão em 1 slide (estrela)
• PySpark essencial que vai aparecer hoje: select, withColumn, join, groupBy, window
• Decisões de modelagem que vamos tomar pro Olakehouse (qual é a tabela fato, quais dimensões)

1. Limpar orders — tipos corretos (datas como timestamp), filtrar status válidos, remover duplicatas
2. Limpar customers — normalizar UF e cidade (uppercase, sem acentos)
3. Limpar order_items — tipos numéricos corretos, validar valores não-negativos
4. Limpar products — fazer join com product_category_name_translation pra ter categoria em inglês
5. Limpar payments — agregar formas de pagamento múltiplas por pedido
6. Cada Silver é escrita como tabela Iceberg olakehouse.silver.{nome}

1. fato_vendas — granularidade item de pedido. Colunas: order_id, item_id, customer_key, product_key, tempo_key, geo_key, valor, frete, dias_entrega, nota_review
2. dim_cliente — 1 linha por customer_unique_id, com UF e cidade
3. dim_produto — 1 linha por produto, com categoria traduzida
4. dim_tempo — calendário 2016–2018 com dia, mês, trimestre, dia da semana
5. dim_geografia — UF + região (Sul, Sudeste, etc.) construída na unha
6. Validações — COUNT(*) em cada Gold, conferir se totais batem com Silver

• Adicionar uma coluna calculada em fato_vendas chamada entregou_atrasado (boolean, comparando order_estimated_delivery_date com order_delivered_customer_date)
• Rodar uma query agregada: percentual de pedidos atrasados por UF
• Postar o resultado top-5 no canal da turma

• Por que orquestrador e não cron + script: dependência, retry, observabilidade
• Anatomia de uma DAG: tasks, dependências, schedule, retries
• Operators que vamos usar hoje: BashOperator, PythonOperator, SparkSubmitOperator
• O que NÃO colocar dentro da DAG: lógica de transformação pesada (essa fica nos scripts Spark)

1. Estrutura do diretório — dags/, dags/scripts/, dags/sql/. Mostrar como o Airflow lê DAGs do filesystem
2. DAG esqueleto — olakehouse_daily.py com schedule @daily, sem tasks ainda; ver no Airflow UI
3. Task 1 — ingest_bronze — PythonOperator que executa o script de ingestão dos CSVs pro MinIO
4. Task 2 — transform_silver — BashOperator rodando spark-submit do script Silver da semana passada
5. Task 3 — build_gold — outro spark-submit pro script de Gold
6. Task 4 — validate_gold — PythonOperator que confere COUNT(*) mínimo nas tabelas Gold e falha se zero
7. Dependências — ingest_bronze >> transform_silver >> build_gold >> validate_gold
8. Configurar retry — default_args com retries=2, retry_delay=timedelta(minutes=5)
9. Simular falha — adulterar credencial do MinIO, ver task ingest_bronze falhar, ver retry automático, ver e-mail/notificação no log
10. Sensor + reprocesso — adicionar FileSensor que espera novo lote chegar em s3a://bronze/_landing/
11. Reprocessar dia anterior — pelo UI, clicar em "Trigger DAG" com execution_date retroativo, ver Airflow respeitando idempotência

• Adicionar uma 5ª task notify_done que escreve no log (ou posta no Slack via webhook, se já tiver) "pipeline OK em {ds}"
• Mudar o schedule pra rodar de hora em hora apenas das 9h às 18h em dias úteis (cron expression)
• Postar o trecho de cron no canal da turma

• Como o Superset se conecta a Iceberg via Spark Thrift Server (arquitetura em 1 slide)
• Diferença entre dataset, chart e dashboard no Superset
• 5 perguntas de negócio típicas que o Olakehouse permite responder — e que vão virar nossos gráficos hoje
• O que faz um dashboard ser "bom": menos é mais

1. Subir o Spark Thrift Server — start-thriftserver.sh no container Spark, expondo porta 10000
2. Configurar database no Superset — driver pyhive ou sqlalchemy-trino, URL hive://spark:10000/olakehouse
3. Validar conexão — rodar SELECT COUNT(*) FROM olakehouse.gold.fato_vendas no SQL Lab do Superset
4. Registrar datasets — gold.fato_vendas + 4 dimensões como datasets no Superset

1. Chart 1 — Big Number — receita total
2. Chart 2 — Time series — receita diária ao longo de 2017–2018
3. Chart 3 — Bar chart — top 10 categorias por receita
4. Chart 4 — Mapa do Brasil — receita por UF
5. Chart 5 — Scatter — dias de entrega vs nota média da review
6. Montar o dashboard — arrastar os 5 charts, adicionar filtros (período, UF, categoria), salvar como Visão de Vendas Olakehouse
7. Compartilhar — gerar link público (read-only) ou exportar PDF

1. Cada aluno tem 3min pra: subir o docker compose up, rodar a DAG, mostrar o dashboard, apontar uma insight de negócio que descobriu nos dados
2. Feedback rápido da turma + professor
3. Entrega oficial dos certificados de conclusão

Em vez de desafio, a tarefa é finalizar o repo GitHub durante a semana:

• README explicando como subir e rodar o pipeline
• Pasta dags/ com a DAG
• Pasta transformacoes/ com os scripts Spark
• Pasta dashboards/ com o JSON exportado do dashboard Superset
• Screenshot do dashboard no README