Arquitetura Lakehouse com Databricks: Delta Lake, Unity Catalog e Camada Bronze Governada
Guia tecnico para converter Parquet em tabela Delta gerenciada com rastreabilidade via _delta_log
Este conjunto de questões marca uma transição importante no aprendizado. Até aqui, o leitor pode já ter trabalhado com arquivos, transformações e persistência de dados. Agora, o desafio sobe de nível: não basta mais manipular dados; é preciso começar a estruturar o ambiente em que esses dados passam a existir como ativos governados, rastreáveis e confiáveis. O foco deste TP é justamente a fundação do Lakehouse com Delta Lake e Unity Catalog, a implementação da camada Bronze e a compreensão do que acontece “sob o capô” quando arquivos comuns passam a se tornar tabelas inteligentes e governadas.
Ao longo das questões, o leitor enfrentará desafios que exigem mais do que execução mecânica de comandos. Será necessário compreender a hierarquia de governança do Unity Catalog, criar e organizar objetos como catalog, schema e volume, converter arquivos Parquet em tabelas Delta, distinguir uma tabela meramente existente de uma tabela realmente gerenciada, inspecionar a estrutura física de armazenamento e interpretar o papel da pasta `_delta_log` e dos arquivos JSON de transação. Em outras palavras, o problema aqui não é apenas “como fazer”, mas “o que estou criando”, “por que isso existe” e “como sei que isso é confiável”.
Se conseguir resolver satisfatoriamente todas as questões, o leitor demonstrará um conjunto de competências muito mais robusto do que a simples capacidade de usar o Databricks. Ele mostrará que entende os fundamentos da governança em um Lakehouse, sabe estruturar namespaces de dados com Unity Catalog, compreende a lógica da arquitetura Medallion e consegue implementar uma camada Bronze de forma coerente com a ideia de ingestão bruta com histórico. Também demonstrará que é capaz de transformar arquivos em tabelas Delta governadas, entendendo que o valor técnico dessa transformação não está só no formato, mas nas garantias operacionais e transacionais que passam a existir.
Do ponto de vista técnico, quem conclui esse percurso passa a dominar skills centrais de engenharia de dados em ambiente moderno. Entre elas estão a criação de objetos de governança, a distinção entre arquivo, volume, tabela, schema e catalog, a conversão de dados persistidos em Parquet para tabelas Delta, a noção de managed table, a inspeção da estrutura física de uma tabela e a capacidade de explicar por que o Delta Lake oferece confiabilidade que o Parquet isolado não oferece. Isso significa começar a pensar menos como alguém que apenas armazena arquivos e mais como alguém que projeta e administra ativos de dados sob regras, contexto e controle.
Sequência operacional sugerida
Mapa mental mínimo antes de executar
Catalog é o contêiner mais alto da governança. Ele define o domínio lógico em que schemas, tabelas e volumes passam a existir.Schema é a subdivisão dentro do catalog. Em iot_bronze, o nome já comunica domínio de IoT e camada Bronze da arquitetura Medallion.Volume não é tabela. Ele é armazenamento governado para arquivos, útil para receber insumos brutos antes da materialização tabular.Tabela é o objeto lógico consultável. O nome registrado no Unity Catalog é a face lógica; a pasta física em storage é a face material.Confundir arquivo com tabela, volume com tabela e Parquet com Delta. Parquet puro entrega arquivos colunares; Delta entrega arquivos mais um livro-caixa transacional que controla estado, versões e consistência.
O que a questão pede
sensorflow_catalog e sensorflow_catalog.iot_bronze, validando a existência dos objetos.Comandos de referência
CREATE CATALOG IF NOT EXISTS sensorflow_catalog;
CREATE SCHEMA IF NOT EXISTS sensorflow_catalog.iot_bronze;
SHOW CATALOGS;
SHOW SCHEMAS IN sensorflow_catalog;Com catalog e schema criados, a solução passa a ter namespace governado para tabelas e volumes do domínio de IoT.
Como defender a decisão
catalog representa o domínio organizacional principal. Ele é o nível mais alto da governança e concentra as regras do conjunto de ativos.schema organiza a camada de trabalho dentro desse domínio. Em iot_bronze, a escolha do nome não é estética: ela deixa explícitos camada e assunto.catalog.schema.objeto, ele mostra que entende namespace governado, e não apenas sintaxe SQL.O que a questão pede
iot_bronze.O que isso quer dizer de verdade
Comandos de referência
CREATE VOLUME IF NOT EXISTS sensorflow_catalog.iot_bronze.raw_files;
-- exemplo de leitura dos parquets do TP2
SELECT *
FROM parquet.`/Volumes/sensorflow_catalog/iot_bronze/raw_files/tp2/*.parquet`;
CREATE OR REPLACE TABLE sensorflow_catalog.iot_bronze.sensor_events_bronze
USING DELTA
AS
SELECT *
FROM parquet.`/Volumes/sensorflow_catalog/iot_bronze/raw_files/tp2/*.parquet`;O volume é armazenamento governado para arquivos. A tabela é um objeto lógico registrado no catálogo. Guardar Parquet no volume resolve organização física; criar a tabela Delta resolve governança tabular, descoberta e operação confiável.
Salvar Parquet em diretório não é suficiente: o exercício exige objeto tabular Delta registrado e governado no Unity Catalog.
O que a questão pede
Comandos de referência
DESCRIBE DETAIL sensorflow_catalog.iot_bronze.sensor_events_bronze;
DESCRIBE EXTENDED sensorflow_catalog.iot_bronze.sensor_events_bronze;
-- use a location retornada para inspecionar a pasta fisica
%fs ls <location-da-tabela>
dbutils.fs.ls("<location-da-tabela>")
%fs ls <location-da-tabela>/_delta_log
SELECT *
FROM json.`<location-da-tabela>/_delta_log/00000000000000000000.json`;Managed vs external
managed table, não declare LOCATION manual no CREATE TABLE. Deixe o Databricks controlar o ciclo de vida físico da tabela.MANAGED e a Location retornada no DESCRIBE EXTENDED ou no DESCRIBE DETAIL.external aponta para um caminho definido explicitamente. Tabela managed continua sendo um objeto lógico do catálogo, mas sua área física fica sob administração da plataforma.Como explicar a confiabilidade do Delta
_delta_log, onde ficam commits, metadados e ações que permitem reconstruir um snapshot consistente da tabela.A pasta _delta_log registra versões da tabela, operações de escrita, metadados e checkpoints lógicos. É isso que permite explicar por que o leitor enxerga uma tabela consistente, e não apenas um diretório com arquivos espalhados.