Onde aparecem mais ferramentas reconhecíveis em reunião com TI corporativo de empresa média-grande. Foco: você entende a stack moderna de engenharia de dados o suficiente pra avaliar proposta do cliente e propor integração do Team Studio sem cair em armadilha.

Pré-requisito: Semana 1 (SQL fundamentals). Tempo estimado: 4 horas de leitura + 1 hora de exercício. Output prático: você sustenta conversa de 30 min sobre engenharia de dados sem perder o fio e identifica oportunidades reais pro Team Studio.

Por que essa semana importa

ETL/ELT é onde TUDO acontece em empresa média-grande: - Dados nascem em sistemas operacionais (CRM, ERP, e-commerce) - Precisam ir pra algum lugar central pra virar relatório e decisão - O processo de mover/transformar é caro, complexo e raramente bem feito

Quando você for vender Team Studio, agentes que VOCÊ implanta vão precisar: - LER desses pipelines (alimentar agentes com contexto fresco) - ESCREVER neles (ações dos agentes precisam ir pra algum sistema central) - NÃO QUEBRAR eles (cliente sangra se ETL travar)

Cliente que conhece ferramentas (Airflow, dbt, Snowflake) percebe NA HORA se você fala dessa stack ou não. É filtro de credibilidade.

Bônus: ETL/ELT também é onde aparecem oportunidades pro Team Studio entregar VALOR REAL (automação de pipelines, validação por IA, alertas semânticos).

1. O modelo mental: a vida de um dado

Imagina o dado pessoal de um cliente novo que acabou de comprar:

1. Nasce em: e-commerce (Shopify, sistema próprio, etc)
2. Aparece em: sistema de pagamento (Stripe, Asaas)
3. Replicado em: CRM (HubSpot, Salesforce)
4. Carregado em: data warehouse (pra analytics)
5. Transformado em: tabelas de relatório (LTV, cohort, etc)
6. Consumido por: BI tool (Tableau, Metabase, Looker)
7. Mostrado em: dashboard pro CEO

Da venda ao dashboard, o dado passa por 5-10 sistemas, 3-5 transformações, 2-3 ferramentas diferentes. O conjunto desses caminhos é chamado de stack de dados ou modern data stack.

Engenharia de dados é a disciplina de fazer isso ACONTECER de forma confiável, escalável e barata. Sua trabalho não é virar dev de dados. Seu trabalho é entender o suficiente pra: - Identificar onde Team Studio pode plugar - Saber se o que cliente fala faz sentido - Não comprar briga errada

2. ETL vs ELT - a diferença que mudou a indústria

2.1 ETL (Extract, Transform, Load) - paradigma tradicional

Como funcionava até ~2015:

[Origem] → Extract → Transform → Load → [Destino]
  1. Extract: pega dado bruto da origem (banco, API, planilha)
  2. Transform: limpa, agrega, transforma EM SERVIDOR INTERMEDIÁRIO (separado)
  3. Load: carrega no destino já transformado

Característica: transformação acontece ANTES de chegar no warehouse. Servidor intermediário precisa de muito processamento.

Por que funcionava: warehouses antigos (anos 2000) eram caros e fracos. Não dava pra fazer transformação pesada dentro deles. Tinha que pré-processar fora.

Ferramentas clássicas: Informatica, Talend, IBM DataStage, SSIS (Microsoft).

2.2 ELT (Extract, Load, Transform) - paradigma moderno

Como funciona desde ~2015:

[Origem] → Extract → Load → [Warehouse] → Transform → [Tabelas finais]
  1. Extract: pega dado bruto
  2. Load: joga DIRETO no warehouse, sem transformar
  3. Transform: transforma DENTRO do warehouse usando SQL

Característica: transformação no warehouse. Aproveita poder do warehouse moderno (Snowflake, BigQuery, Redshift).

Por que ganhou: warehouses cloud explodiram em performance e desabaram de preço. Faz sentido carregar tudo bruto e transformar lá. Mais flexível, mais barato, mais rápido pra mudar.

Ferramentas modernas: dbt (transformação), Fivetran (ingestão), Airbyte (ingestão open source), Snowflake/BigQuery/Databricks (warehouse).

2.3 Por que isso importa pra você

Quando cliente diz "nosso ETL roda à noite e leva 4 horas", ele provavelmente está numa stack OLD. Quando diz "nosso ELT moderno é dbt + Snowflake", ele tá na onda atual.

Não é hierárquico (moderno não é "melhor"): empresas grandes têm AMBOS. Sistema legado fica em ETL, sistema novo em ELT. Migração leva anos.

Pergunta que destrava reunião:

"Vocês estão em ETL tradicional ou ELT moderno? Qual ferramenta? Estamos pensando em ler dados das transformações finais pros agentes - vocês têm staging area específica ou vamos direto nos models do dbt?"

Essa pergunta posiciona você como quem entende a stack, não como vendedor de IA genérico.

3. Batch vs Streaming - quando cada um faz sentido

3.1 Batch processing

Processa lotes de dados em intervalos fixos. Exemplo: ETL roda toda madrugada às 2h.

Quando faz sentido: - Relatórios diários/semanais (não precisa real-time) - Volume grande sem urgência (consolidação financeira mensal) - Custo é fator (batch é mais barato que streaming)

Ferramentas: Airflow, Dagster, Prefect (orquestração), Spark batch, cron + script.

3.2 Streaming processing

Processa eventos UM POR UM, conforme entram. Latência: milissegundos a segundos.

Quando faz sentido: - Detecção de fraude em tempo real - Dashboards "ao vivo" (operações críticas) - Personalização instantânea - Comunicação entre microserviços

Ferramentas: Apache Kafka, AWS Kinesis, Google Pub/Sub, Apache Flink, Apache Beam.

3.3 Híbrido (lambda / kappa architecture)

A maioria das empresas tem dos dois. Eventos críticos rodam em streaming, resto em batch. Arquiteturas formais:

  • Lambda architecture: batch + streaming em paralelo, resultados unificados
  • Kappa architecture: tudo streaming, batch é só "tipo especial" de streaming

Você não precisa entender esses dois em profundidade. Reconhecer os nomes é suficiente.

3.4 Quando você precisa identificar isso

Cliente diz "queremos que seu agente reaja imediatamente quando cliente fizer X". Você precisa avaliar:

  • Sistema de origem é batch ou streaming?
  • Se batch (atualiza só 1x/dia), agente não vai conseguir "reagir imediatamente"
  • Se streaming, agente pode subscrever a eventos

Sem entender isso, você promete coisa que infra do cliente não entrega.

Pergunta de reunião:

"Os eventos que vamos consumir são publicados em streaming (Kafka, Pub/Sub) ou são gerados em batch? Qual a latência esperada do dado chegar pra gente?"

4. Data lake vs Data warehouse vs Lakehouse - a divisão moderna

4.1 Data warehouse - o veterano

O que é: banco otimizado pra ANALYTICS, com schema estruturado, queries SQL pesadas.

Características: - Schema definido antes (schema-on-write) - Dados curados, limpos, prontos pra análise - Performance excelente em queries analíticas - Geralmente colunar (armazena por coluna, não por linha - bom pra agregações)

Quando usar: relatórios, dashboards, BI, análise estruturada.

Ferramentas dominantes: - Snowflake (cloud, mais popular hoje) - BigQuery (Google) - Amazon Redshift (AWS) - Azure Synapse (Microsoft) - Databricks SQL (relativamente novo, ambiguamente warehouse/lakehouse)

4.2 Data lake - o flexível

O que é: armazenamento de dados BRUTOS em formato nativo, sem schema pré-definido.

Características: - Schema definido DEPOIS (schema-on-read) - Aceita qualquer formato (CSV, JSON, parquet, ORC, imagens, vídeos) - Barato pra armazenar (S3, GCS, ADLS) - Performance pior pra queries (precisa ferramenta em cima)

Quando usar: armazenar tudo que pode ser útil no futuro, dados não-estruturados, ML/AI.

Ferramentas: - AWS S3 (armazenamento, mais popular) - Google Cloud Storage - Azure Data Lake Storage

E pra consultar: - Apache Spark, Presto/Trino, Athena (AWS)

4.3 Lakehouse - a tentativa de unificar

O que é: arquitetura híbrida que tenta combinar flexibilidade do lake com performance do warehouse, usando formatos abertos (Apache Iceberg, Delta Lake, Apache Hudi) que adicionam estrutura ao lake.

Por que apareceu: empresas tinham warehouse + data lake separados. Caro, complexo, dado duplicado. Lakehouse promete UM lugar só.

Características: - Dados em formato aberto no lake (Parquet + metadata via Iceberg/Delta) - ACID transactions no lake (incomum, mas Iceberg/Delta entregam) - Schema evolution sem reescrever tudo - Acessível por SQL (warehouse-like) E por Spark/ML (lake-like)

Ferramentas dominantes: - Databricks (criou Delta Lake, lidera o movimento) - Snowflake com Iceberg tables (entrando agora) - AWS com Iceberg (suporte nativo recente)

4.4 Como saber qual o cliente usa

Pergunte direto. Resposta típica de cliente moderno:

"Temos Snowflake como data warehouse, S3 como data lake pra dados não-estruturados, e estamos migrando partes pra Databricks com Iceberg pra ter um lakehouse unificado."

Isso é normal. Empresa grande tem os 3, em fases diferentes de maturidade.

5. Pipelines de dados - como tudo se move

Pipeline é a esteira que pega dado de um lugar e leva pra outro, fazendo transformações no caminho. Em modern data stack, pipeline tem 3 partes lógicas:

5.1 Ingestion (entrada)

Trazer dado de sistema-fonte pro warehouse/lake. Ferramentas:

  • Fivetran: SaaS, conecta 300+ origens com 1 clique, caro mas zero esforço
  • Airbyte: open source, alternativa barata ao Fivetran, mais hands-on
  • Stitch: SaaS, comprado pela Talend
  • Custom (Python + Pandas/Polars): pra origens específicas sem conector pronto

O que essas ferramentas resolvem: lidar com APIs malucas, mudanças de schema, falhas de rede, deduplicação, idempotência.

5.2 Transformation (transformação)

Limpar, agregar, juntar tabelas pra criar dados úteis. Ferramenta dominante:

  • dbt (data build tool): padrão de indústria. Você escreve SQL em arquivos .sql, dbt orquestra dependências e gera tabelas/views no warehouse. Tem testes, documentação, versionamento via Git.

dbt é IMPORTANTÍSSIMO de conhecer. Se cliente moderno tem analytics, provavelmente tem dbt.

Alternativas/complementares: - Spark (PySpark, Scala): pra transformações pesadas em data lake - Pandas/Polars/DuckDB (Python): pra transformações pequenas

5.3 Orchestration (orquestração)

Coordenar os pipelines: quando rodar, em que ordem, o que fazer se quebrar.

  • Apache Airflow: padrão histórico, baseado em Python, DAGs (Directed Acyclic Graphs)
  • Dagster: alternativa moderna, foco em data assets em vez de tasks
  • Prefect: alternativa Python, simpler que Airflow
  • AWS Step Functions / Google Cloud Workflows / Azure Data Factory: orquestradores cloud-nativos

Sinal de empresa madura: tem orquestrador documentado, com retry, alerts, observability. Sinal de empresa imatura: cron + bash script + WhatsApp do dev quando quebra.

5.4 Qualidade e observability

Pipelines quebram. Dado vem errado. Ninguém percebe até relatório do CEO mostrar número absurdo.

Ferramentas que ajudam: - Great Expectations: testes de qualidade de dados (assertions) - Monte Carlo, Bigeye: observability de dados (alerta quando algo muda) - dbt tests: built-in no dbt, simples mas eficaz

Pergunta de reunião:

"Vocês têm observability de dados? Como sabem se uma tabela ficou estranha sem alguém reclamar?"

Resposta dela revela MUITO sobre maturidade.

6. Modern Data Stack - a stack que aparece em 80% das empresas médias

Setup típico de empresa média/grande "moderna":

[Sistemas-fonte: CRM, ERP, e-commerce]
        ↓
[Fivetran / Airbyte] → Ingestão
        ↓
[Snowflake / BigQuery] → Warehouse
        ↓
[dbt] → Transformação
        ↓
[Tableau / Looker / Metabase] → BI
        +
[Airflow / Dagster] → Orquestrando tudo acima

Se cliente menciona pelo menos 3 dessas, ele tá na onda moderna. Se mencionou Informatica + Oracle + Cognos, é stack legada (válida mas diferente).

Por que isso importa pro Team Studio: - Em stack moderna, plugar agente é mais fácil (APIs, eventos, SQL padrão) - Em stack legada, integração é mais difícil mas oportunidade é MAIOR (cliente precisa muito mais de ajuda)

7. Idempotência e DLQ - conceitos que importam em pipelines

7.1 Idempotência (já apareceu antes)

Operação que pode ser executada várias vezes sem mudar resultado final.

Em pipelines: se job quebra no meio e roda de novo, NÃO pode duplicar dados.

Exemplo ruim (não idempotente): "INSERT pra cada linha do CSV". Se rodar 2x, dobra dados.

Exemplo bom (idempotente): "UPSERT pra cada linha (insere se não existe, atualiza se existe)". Rodar 2x dá mesmo resultado.

7.2 DLQ (Dead Letter Queue)

Fila pra mensagens que falharam após N retries. Não some, fica esperando ser tratada manualmente.

Por que importa: streaming/event-driven sem DLQ = dado se perde silenciosamente quando processor falha.

Pergunta de reunião:

"O processador de eventos tem DLQ configurada? Onde caem mensagens que falham?"

7.3 Backfill e replay

  • Backfill: rodar pipeline pra dado HISTÓRICO (geralmente porque mudou lógica ou achou bug retroativo)
  • Replay: re-processar eventos antigos (em streaming)

Pipeline precisa SUPORTAR backfill/replay sem catastrofar. Não-trivial.

8. Onde Team Studio entra na stack de dados

Agora a parte interessante. Onde um agente do Team Studio pode plugar?

Caso 1: Agente lê do warehouse pra responder cliente

Cliente quer agente WhatsApp que responde "qual meu saldo de cashback?". O agente: 1. Consulta clientes no warehouse via SQL 2. Calcula cashback baseado em regra de negócio (dbt model customer_rewards) 3. Responde via WhatsApp

Integração: agente tem credencial de leitura no warehouse. Roda SQL via SDK do Snowflake/BigQuery.

Caso 2: Agente escreve em sistema-fonte que vira evento pra pipeline

Agente captura lead via WhatsApp e cria contato no Salesforce. Salesforce gera evento. Pipeline (Fivetran) puxa pra warehouse. Em 1-2h, lead aparece em dashboards.

Integração: agente chama API do Salesforce. Resto do pipeline funciona como sempre.

Caso 3: Agente processa eventos em streaming

Cada compra emite evento Kafka. Agente subscreve, decide se manda mensagem WA personalizada, manda.

Integração: agente é Kafka consumer. Mais técnico, mas escalável.

Caso 4: Agente cria/atualiza dbt models

Avançado: agente analisa pergunta de negócio, gera SQL dbt, cria nova model. Cliente revisa, aprova, vira tabela permanente.

Integração: agente acessa repo Git do dbt, abre PR. Mais "AI augmenta engenheiro de dados" do que substitui.

Pergunta de reunião que abre oportunidade:

"Qual fluxo do dado de vocês toma mais tempo do time hoje? Pipelines com mais bugs? Análises ad-hoc? Documentação? Vamos olhar onde IA tira mais peso."

9. Cinco perguntas que destravam reunião de dados

9.1 "Qual a stack de dados de vocês? Warehouse, transformation tool, orchestration, BI."

Por que importa: te dá mapa em 2 minutos. Se cliente lista bem, é maduro. Se gagueja, sistema é caótico.

9.2 "Volume de dado? Quantos registros principais (clientes, pedidos, eventos)? Quantos GBs no warehouse?"

Por que importa: define complexidade real. 10 GB é trivial. 10 TB é projeto. 10 PB é categoria diferente.

9.3 "Latência aceitável pro Team Studio? Quase-real-time (segundos) ou batch (1h-24h)?"

Por que importa: define arquitetura toda da integração. Confirma expectativa antes de prometer.

9.4 "Vocês têm dbt ou ferramenta similar? Posso ver os models que importam pra nossos casos de uso?"

Por que importa: dbt models são "linguagem comum" entre vocês. Se você fala "deixa eu ver o fct_orders.sql", cliente percebe que entende.

9.5 "Como vocês monitoram qualidade de dado? E como ficam sabendo quando pipeline quebra?"

Por que importa: revela cultura de dados. Se resposta é vaga, há oportunidade pra Team Studio entregar valor visível rápido (alertas semânticos com IA, validações automáticas).

10. Exercício prático

Cenário: cliente Team Studio em potencial. Empresa de e-commerce médio (R$ 50M/ano), 5 anos de operação. Diz na primeira call:

"Temos Shopify pro store, Bling pro ERP, ActiveCampaign pra email, e tudo cai num data warehouse Postgres caseiro que rodamos faz 3 anos. Relatório do CEO vem de planilhas que o time financeiro atualiza manualmente toda segunda. Já contratamos 2 empresas pra arrumar e ambas falharam. Você consegue resolver?"

Pratique: faça 5 perguntas pra desambiguar a situação ANTES de comprar a briga. Depois, identifique 2 oportunidades onde Team Studio pode entregar valor real.

(Sugestões de perguntas no fim do documento.)

11. Material extra

Leitura essencial: - Blog do dbt (https://www.getdbt.com/blog) - não importa se você não usa dbt; vocabulário moderno mora aqui - "Designing Data-Intensive Applications" (Martin Kleppmann), capítulos 10-12 (Batch e Streaming) - "Fundamentals of Data Engineering" (Joe Reis + Matt Housley) - visão moderna completa

Vídeos curtos: - YouTube: "Modern Data Stack Explained" (vários canais cobrem em 15 min) - YouTube: "dbt Tutorial" (qualquer série bem ranked) - 30 min te dá noção do que é

Brincadeira prática (1h): - Crie conta grátis no Snowflake (30 dias trial) - Use o dataset público SNOWFLAKE_SAMPLE_DATA - Faça 3 queries SQL simples - Sinta o que é warehouse moderno (queries em segundos sobre milhões de linhas)

12. Sugestões pro exercício prático (não veja antes de tentar)

5 perguntas que eu faria pro cliente do exercício:

  1. "Volume de pedidos por mês? Quantos clientes únicos vocês têm hoje? Isso me ajuda a entender se Postgres caseiro ainda aguenta ou se já tá em colapso."

  2. "Quem cuida do Postgres hoje? É alguém in-house ou freelancer? Se alguém saiu sem documentar, vocês têm DBA pra retomar?"

  3. "Quais relatórios o CEO vê toda segunda? Quais perguntas ele faz fora desses relatórios e ninguém responde? Aqui mora a dor real."

  4. "Por que as 2 empresas anteriores falharam? Foi falta de competência delas, dificuldade técnica do seu sistema, ou problema de comunicação com o time interno?" (Última é a mais comum.)

  5. "Tem alguém no time financeiro que GOSTARIA de não atualizar planilha toda segunda? Quem? Vamos conversar com essa pessoa primeiro." (Identifica champion interno.)

2 oportunidades onde Team Studio entrega valor real:

Oportunidade 1: Agente "Eike financeiro" que consulta o Postgres caseiro toda segunda às 7h, gera relatório resumido por WhatsApp pro CEO. Curto-circuita as planilhas manuais. Setup: 1 tarde. Valor: economiza 6h/semana de alguém no time financeiro.

Oportunidade 2: Agente que monitora Bling+Shopify e alerta no WhatsApp quando dado some, valor zera, ou pedidos param de chegar. Vira "observability de dados poor man's" sem precisar contratar Monte Carlo. Setup: 2 tardes. Valor: cliente para de descobrir problema pelo CEO reclamando.

13. Próxima semana

Esta semana fecha o Bloco A (Dados). O Bloco B (Cloud e Infra) começa em seguida:

  • Semana 4: Modelos cloud e os 3 grandes provedores - IaaS/PaaS/SaaS, AWS vs GCP vs Azure (forças e fraquezas), regiões e zonas, VPC e networking, custos cloud que explodem (egress, idle, FinOps)
  • Semana 5: Escalabilidade, autoscaling, SLA e disaster recovery - fecha o Bloco B com cenário Black Friday