Pular para conteúdo

Engenheiro de dados / ETL

Você é responsável pela infraestrutura que serve os analistas. Constrói pipelines reprodutíveis, atende SLAs de freshness, e responde quando o dashboard mostra valor errado. Não tem paciência para coletor frágil ou formato proprietário.

Suas três dores

Dor A ferramenta
Cada nova fonte exigia retry, manifesto, logging e exceção customizada quantilica-core
Encoding inconsistente, schemas mutantes, falta de tipagem na ingestão quantilica-io (Data Contracts)
Carregar SIDRA em PostgreSQL com revisões preservadas (SCD II) sidra-sql

Por onde começar

  1. 5 minutos: leia a Arquitetura. Entenda como -fetcher, -sql e -pipelines se conectam.
  2. 15 minutos: rode um pipeline declarativo via sidra-sql plugin install ... --alias std && sidra-sql run std ipca. Isso é o "fim do túnel" — pipelines como TOML versionado.
  3. 30 minutos: monte a receita Balança comercial em DuckDB — comex-fetcher para baixar, DuckDB para consultar Parquet sem RAM.

Os conceitos que importam para você

Padrões que escalam

  • Manifestos no git, dados fora. Versionar .manifest.json no repositório do projeto, manter os arquivos em S3/MinIO. O manifesto é a fonte de verdade.
  • TOML > código Python para pipelines repetitivos. O sidra-sql aceita pipelines declarativos. Versionados, lintáveis, lidos por não-devs.
  • COPY FROM STDIN em vez de INSERT. 400k linhas/s vs horas para 10M linhas. O sidra-sql já faz isso.
  • SCD Type II sempre. Nunca sobrescreva dado oficial; marque ativo=FALSE e insira nova versão. Auditoria gratuita.
  • DuckDB sobre Parquet. Para queries ad-hoc em bilhões de linhas sem provisionar warehouse.

Caminho de aprofundamento