📊 Data Engineering — Nível Engenheiro de Dados

Como engenheiro de dados a candidatar a AI Engineer, és esperado dominar pipelines, storage e integração com sistemas de AI.

---

🎯 Frase que impressiona

I see data engineering and AI as deeply connected — the quality of our RAG system depends entirely on the pipeline that feeds it. Clean data, incremental ingestion and proper lineage are what separate production systems from prototypes.

---

1️⃣ Data + AI Architecture

Data sources (DB, APIs, files)
         ↓
   ETL/ELT Pipeline
         ↓
Data Lake / Warehouse  →  Feature Store  →  AI System
         ↓                      ↓
    Bronze/Silver/Gold    Offline (batch)
                              ↓
                         Online serving
                              ↓
                    RAG | LLMs | Embeddings

Colaboração: Data Architect (ex: Diogo) define modelos e governance. DE implementa pipelines.

---

2️⃣ Medallion Architecture (Lakehouse)

Benefício: Reprocessar silver sem re-ingestar bronze. Linhagem clara.

---

3️⃣ ETL vs ELT — Trade-offs

ELT domina em cloud warehouses com compute elástico. dbt = padrão para transformações.

---

4️⃣ Data Modeling — Dimensional

Star schema: Fact table (métricas) + dimension tables (contexto). Joins simples.

Snowflake schema: Dimensões normalizadas. Menos redundância, mais joins.

Fact vs Dimension:

• Fact: eventos transacionais (vendas, cliques), foreign keys para dims, métricas
• Dimension: entidades (cliente, produto, tempo), chave surrogate

SCD (Slowly Changing Dimensions):

• Type 1: Overwrite (sem histórico)
• Type 2: Nova linha com valid_from/valid_to (histórico)
• Type 3: Coluna "previous" (só última mudança)

---

5️⃣ Orchestration — Airflow

DAG: grafo direcionado de tasks com dependências. Schedule (cron) ou trigger manual.

Operators: PythonOperator, BashOperator, SnowflakeOperator, HttpOperator...

Conceitos:

• XCom: passar dados entre tasks (pequenos)
• Variables: config (DB URL, etc.)
• Sensors: esperar condição (ficheiro chegar, partição existir)
• Task groups: organizar DAGs grandes
• Backfill: reprocessar histórico (airflow dags backfill -s 2024-01-01)

Retries: retries=3, retry_delay. Idempotência nas tasks.

---

6️⃣ dbt — Transformações

Models: ficheiros SQL que criam tabelas/views. DAG de dependências automático.

Incremental: {{ config(materialized='incremental') }} — só processar linhas novas. Filtro por updated_at ou CDC.

Tests: unique, not_null, accepted_values, relationships. Custom tests em Python.

Docs: dbt docs generate — lineage, descrições. Colaboração com negócio.

---

7️⃣ Spark — Conceitos Chave

Arquitetura: Driver (coordena) + Executors (processam). Cluster manager (YARN, K8s).

Transformations vs Actions:

• Transformations: lazy (map, filter, join) — build DAG
• Actions: eager (count, collect, write) — executam o plano

Shuffle: operações que redistribuem dados (groupBy, join sem mesma key). Custo alto — minimizar.

Partitioning: repartition(n) vs coalesce(n). Partições = paralelismo. Partição por coluna para filtrar eficiente.

Broadcast join: tabela pequena em memória em todos os executors. Evita shuffle.

---

8️⃣ CDC — Change Data Capture

O que é: capturar apenas alterações (insert, update, delete) em vez de full dump.

Métodos:

• Log-based: Debezium lê binlog/WAL. Baixa latência, não impacta DB.
• Trigger-based: triggers escrevem para tabela de changes.
• Timestamp: WHERE updated_at > last_run. Mais simples, pode perder deletes.

Uso: sincronizar DB transacional com warehouse, lake. Streaming para Kafka.

---

9️⃣ Incremental Loading

Estratégias:

• Watermark: SELECT * WHERE updated_at > :last_watermark. Guardar watermark após sucesso.
• CDC: Stream de changes.
• Full refresh: para dados pequenos ou sem timestamp.

Idempotência: mesmo input = mesmo output. Permitir retries sem duplicados.

---

🔟 Data Quality

dbt tests: schema, unique, not null, FK integrity.

Great Expectations: expectations em Python. Profiling, validação de distribuições.

Data contracts: schema definido (Avro, Protobuf). Producer/consumer acordo. Schema evolution.

Para RAG: encoding correto, HTML removido, deduplicação, metadados consistentes.

---

1️⃣1️⃣ Feature Store

O que é: repositório de features para ML. Offline (batch, treino) + Online (low-latency, inferência).

Feast, Tecton: definem features em código. Sincronizam warehouse → online store (Redis, DynamoDB).

Uso em AI: features para modelos clássicos; contexto para RAG (metadata de docs).

---

1️⃣2️⃣ Snowflake (Bonus na vaga)

Streams: tabela de metadados sobre changes. CREATE STREAM ON TABLE x. Consumir com SELECT * FROM stream. CDC nativo.

Tasks: scheduled SQL. CREATE TASK ... SCHEDULE = 'USING CRON 0 8 * * *'. Pipeline: Stream deteta → Task processa.

Snowpipe: ingestão serverless de ficheiros (S3, GCS). Auto-ingest ou REST API.

Data sharing: partilhar tabelas entre contas sem copiar. Secure data sharing.

Clustering: CLUSTER BY (col) — ordena dados fisicamente. Melhora query performance.

Zero Copy Clone: clone instantâneo de DB/schema/tabela. Copy-on-write. Útil para dev, branch.

---

1️⃣3️⃣ Data Engineering para RAG

Fontes (PDF, Notion, Slack, DB)
    ↓
Extractor (format-specific)
    ↓
Parser (text extraction, metadata)
    ↓
Chunker (semantic or fixed)
    ↓
Embedder (batch)
    ↓
Vector DB (upsert)

Incremental: hash do conteúdo ou updated_at. Só processar alterados.

Orquestração: Airflow DAG diário ou event-driven (webhook quando doc muda).

Idempotência: mesmo doc_id → mesmo vector. Upsert por id.

---

1️⃣4️⃣ Data Lineage

O que é: rastrear origem e transformações de cada dado.

OpenLineage: standard, integra com Airflow, dbt, Spark.

Valor: debug "de onde veio este valor?", impact analysis (que pipelines afetam esta tabela?).

---

Ferramentas Resumidas