All Posts

Após concluirmos as camadas Landing, Bronze e Silver, avançamos para a construção da camada Gold do laboratório. Até este ponto, o pipeline já estava estruturado assim: Neon PostgreSQL ↓ Databricks Lakehouse Federation ↓ Landing em Unity Catalog Volume ↓ Bronze append-only em Delta ↓ Silver por domínios, com qualidade, quarentena, SCD Tipo 1 e SCD Tipo 2 A Gold foi criada como a camada de consumo analítico, orientada a KPIs, modelo estrela, dimensões, fatos e perguntas de neg

Após concluir as camadas Landing e Bronze, avançamos para a construção da camada Silver do laboratório. Até este ponto, o pipeline já estava funcionando assim: Neon PostgreSQL ↓ Databricks Lakehouse Federation ↓ Landing em Unity Catalog Volume ↓ Bronze append-only em Delta A partir desta etapa, o objetivo foi transformar os dados brutos da Bronze em tabelas Silver mais confiáveis, padronizadas, deduplicadas e organizadas por domínio de negócio. A arquitetura passa a ser: Neon

Antes de iniciar a camada Silver, identificamos um ponto importante na arquitetura do projeto: o deploy em dev já estava funcionando, mas o processo de promoção para prod ainda não estava completamente estruturado. Até então, o projeto executava corretamente em: hotelaria_dev Mas os contratos ainda continham referências fixas ao ambiente de desenvolvimento, como: hotelaria_dev /Volumes/hotelaria_dev/... hotelaria_dev.bronze.<tabela> Isso dificultaria a promoção para produção,

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

Quando sento para desenhar uma arquitetura de dados, especialmente em ecossistemas como Databricks ou qualquer plataforma moderna de dados, existe um conceito que muitas vezes é negligenciado no início, mas que costuma cobrar um preço alto depois: a cardinalidade. Se você já trabalhou com Star Schema — ou Esquema Estrela — sabe que ele continua sendo uma das abordagens mais eficientes e compreensíveis para modelagem analítica. Ele facilita a vida do usuário final, melhora a l

Olá, que prazer ter você aqui! Se você acompanhou meu post recente no LinkedIn, viu que eu toquei em uma ferida comum na nossa área: a diferença entre um Data Lake funcional e um "pântano de dados". Mas, como prometido, decidi trazer esse debate para cá, com muito mais profundidade, para que possamos analisar detalhadamente o que o DMBOK (Data Management Body of Knowledge) nos ensina sobre os pilares da Engenharia de Dados. Prepare o café, porque hoje vamos dissecar os Metad

A Armadilha do "Frankenstein" de Dados: Quando a Complexidade Vira Inimiga da Engenharia Existe uma confusão recorrente na engenharia de dados moderna: associar complexidade com maturidade técnica . Na prática, quanto mais experiente o time, mais simples tende a ser a arquitetura. Mas o que vemos em muitos projetos, principalmente em ambientes cloud modernos, é o oposto: uma sobreposição de ferramentas que cria um ecossistema difícil de operar, difícil de evoluir e, principal

Olá, aqui é o Michel Santana. Se você já sentiu o frio na barriga de ver um pipeline quebrar porque o sistema de origem mudou o formato de um arquivo ou porque um banco de dados transacional "travou" durante uma extração pesada, este artigo é para você. Hoje, quero mergulhar no que considero ser o "porto seguro" de qualquer arquitetura de dados moderna: a Landing Zone . Quando comecei a estudar arquiteturas de dados, percebi que muitos problemas de corrupção de dados nas cama

Se você acompanha minha jornada no LinkedIn ou aqui no blog, sabe que sou um defensor ferrenho de que ferramentas são apenas meios para um fim. Aprender Databricks, dominar o Google Cloud Platform (GCP) ou escrever scripts complexos em PySpark é essencial, mas se não entendermos o porquê e o como os dados fluem dentro de uma organização, seremos apenas operadores de ferramentas, e não engenheiros de dados completos. Recentemente, revisitei um material que considero a "bíbli

Recentemente, revisando alguns materiais fundamentais da nossa área, me deparei com uma página que considero a "bússola moral" de qualquer projeto de dados sério. A imagem, extraída do excelente livro Fundamentos de Engenharia de Dados (de Joe Reis e Matt Housley), apresenta a famosa "Hierarquia de Necessidades da Ciência de Dados", originalmente proposta por Monica Rogati. Sempre que vejo essa pirâmide, sou transportado para diversas reuniões de kick-off de projetos em que

Quando a gente fala de Engenharia de Dados , o "mover bits" é só uma parte da história. A outra, e talvez a mais crítica, é garantir que esses bits não sejam apenas transportados, mas que cheguem com qualidade e no tempo certo . E, honestamente, depois de trabalhar em diversos projetos, aprendi que a falha em um pipeline de dados tem um custo altíssimo, que vai desde relatórios incorretos até prejuízos reais ou decisões regulatórias erradas. Foi exatamente com esse mindset

Quando comecei minha jornada na Engenharia de Dados, uma das primeiras e maiores confusões era entender a diferença prática entre Data Warehouse (DW) e Data Lake . E, para adicionar uma camada de complexidade e de evolução a esse cenário, hoje temos o Data Lakehouse , que se tornou um pilar na minha rotina de trabalho. Neste artigo, vou descomplicar essa evolução. Vou mostrar por que essa distinção importa e como a arquitetura que você escolhe pode ser o divisor de águas ent

Fala, pessoal! Aqui é o Michel Santana . Quando a gente começa a mergulhar de cabeça no universo da Engenharia de Dados, uma das primeiras coisas que precisamos internalizar é que nem todo dado é criado igual . Parece óbvio, eu sei, mas a forma como gerenciamos, armazenamos e processamos informações para rodar um sistema é drasticamente diferente da forma como as tratamos para gerar insights estratégicos. É aí que entra a distinção crucial entre Dados Operacionais e Dados A

O primeiro mergulho na lama dos dados Quando comecei a trabalhar com engenharia de dados, achei que o grande desafio seria fazer os dados fluírem — puxar de APIs, extrair de planilhas, salvar no Data Lake. Mas com o tempo percebi que o verdadeiro desafio não era mover os dados… era confiar neles . De nada adianta ter uma arquitetura em nuvem robusta, com pipelines automatizados, se os dados que chegam ao analista estão sujos, incompletos ou distorcidos. É como construir uma

Quando falamos em fontes de dados em um ambiente corporativo, é quase impossível não esbarrar no Microsoft SharePoint. Seja para listas de controle, planilhas de Excel que o time de Finanças atualiza, ou arquivos CSV gerados por algum processo departamental, o SharePoint funciona muitas vezes como um "data mart" semi-estruturado. Como engenheiros de dados, nosso trabalho é trazer esses dados para o nosso ambiente de processamento (seja um Data Lake, um Data Warehouse ou um La

Pare de usar o Dataflow para transportar terabytes de dados. Use-o para orquestrar milhares de tarefas e evite o temido Out of Memory. Olá, pessoal. Sou Michel Santana. Como Engenheiro de Dados, um dos problemas mais frustrantes (e caros) que vejo em projetos é o famoso Out of Memory (OOM) em pipelines de Dataflow. Você já passou por isso? Você configura um pipeline para processar um grande volume de dados talvez alguns terabytes de logs, ele começa a rodar, o gráfico de exec