Databricks

Após concluir a ingestão Source → Landing, avançamos para a construção da camada Bronze. O objetivo desta etapa foi transformar os arquivos Parquet armazenados em Unity Catalog Volumes em tabelas Delta gerenciadas no Unity Catalog, mantendo a Bronze como uma camada append-only, auditável e reprocessável. A arquitetura até este ponto ficou assim: Neon PostgreSQL ↓ Foreign Catalog: neon_hotelaria.public ↓ Job Source → Landing ↓ Unity Catalog Volume /Volumes/hotelaria_dev/landin

Antes de avançarmos para a construção da camada Bronze, identificamos a necessidade de fortalecer a base do projeto. Até este ponto, já tínhamos uma ingestão funcional do Neon PostgreSQL para a Landing usando Databricks Asset Bundles, watermark e Unity Catalog Volumes. No entanto, para que o laboratório se aproxime mais de um projeto real de engenharia de dados, decidimos incluir uma camada de governança técnica antes de continuar. Esse ajuste contempla: contratos por tabela

Nesta etapa do laboratório, o objetivo é estruturar a primeira parte do pipeline de engenharia de dados: a ingestão incremental dos dados do Neon PostgreSQL para a camada Landing no Databricks. O fluxo implementado até aqui é: Neon PostgreSQL ↓ Foreign Catalog no Databricks ↓ Job com Databricks Asset Bundles ↓ Landing em Unity Catalog Volume ↓ Arquivos Parquet particionados por tabela, data e batch Nesta fase ainda não estamos carregando a Bronze. O foco é apenas garantir que

Após definir a organização dos ambientes e camadas no Databricks, o próximo passo do laboratório será criar uma fonte de dados relacional real para simular um cenário próximo de produção. Neste projeto, usaremos o Neon PostgreSQL como banco transacional de origem e o Databricks Free Edition como plataforma Lakehouse para ingestão, transformação e organização dos dados nas camadas landing, bronze, silver e gold. A ideia é simular o fluxo: Neon PostgreSQL ↓ Databricks Connector

Em um projeto real de engenharia de dados no Databricks, a organização entre ambientes e camadas deve considerar governança, segurança, isolamento, manutenção e clareza arquitetural. A estrutura recomendada é separar os ambientes de desenvolvimento, homologação e produção no maior nível possível, preferencialmente por workspaces distintos, e organizar as camadas do Lakehouse dentro do Unity Catalog usando catálogos e schemas. Modelo recomendado para um projeto real Em um ambi

Recentemente, em um projeto na empresa onde trabalho, me deparei com uma abordagem peculiar para a gestão e deploy de artefatos no...

Olá, comunidade de dados! Quem trabalha com engenharia e análise de dados sabe que uma das tarefas mais comuns é a integração com fontes...

Na engenharia e análise de dados com Databricks, a eficiência e a organização do código são fundamentais. Entre as diversas ferramentas...

No universo da engenharia e análise de dados com Databricks, uma das decisões fundamentais ao estruturar seu Lakehouse é a escolha do...