Como criar uma Delta Table Lakehouse com ACID no Microsoft Fabric

João Barros 30 de September de 2026 6 min de leitura

Este tutorial explica como criar uma Delta Table num Lakehouse do Microsoft Fabric e como garantir propriedades ACID essenciais: atomicidade (transacção), consistência de leitura e gestão de esquema (schema). Saber criar e gerir Delta Tables é útil para pipelines ETL/ELT, histórico de dados, auditoria e integração com Spark e Power BI. No final terá pequenos testes práticos para verificar que as operações básicas funcionam e para inspecionar os metadados.

Pré-requisitos

Conta com acesso a um workspace do Microsoft Fabric com permissões de edição (pelo menos Contributor no workspace).
Um Lakehouse criado no workspace (OneLake integrado) e o caminho do Lakehouse disponível. Ex.: lakehouse://meu_workspace/meu_lakehouse/tables.
Noções básicas de Spark SQL ou PySpark e acesso a um Notebook ou Spark Job dentro do workspace.
Recomendado: testar primeiro em ambiente de desenvolvimento com conjuntos de dados pequenos (100–10 000 linhas) antes de migrar para produção.

Passo 1: Preparar o ambiente e a ligação ao Lakehouse

Abra um Notebook no workspace do Microsoft Fabric (Python ou Spark SQL). Verifique o caminho do Lakehouse que vai usar. Vamos usar Spark SQL para compatibilidade com outras áreas do Fabric e para reutilizar em Jobs. O objectivo é definir uma variável de caminho e garantir que as permissões permitem escrita no OneLake.

-- exemplo Spark SQL: definir caminho do Lakehouse
SET lakehouse_path = 'lakehouse://<seu_workspace>/<seu_lakehouse>/tables';

Concretamente, confirme no UI do Lakehouse o nome exacto (case-sensitive). Se preferir Python, pode ler a configuração com spark.conf.get('lakehouse_path') depois de a definir no Notebook.

Passo 2: Criar um directório para a Delta Table e escrever dados iniciais

Uma Delta Table em Lakehouse é materializada em OneLake como ficheiros Parquet e um directório _delta_log com metadados. Primeiro crie um pequeno DataFrame (ex.: 3–5 linhas) e grave-o como Delta. Isto cria o layout e o primeiro commit que garante atomicidade da operação inicial.

-- Spark SQL: criar tabela temporária e gravar em formato delta
CREATE OR REPLACE TEMP VIEW vendas_tmp AS
SELECT * FROM VALUES
  (1, '2026-01-01', 100.0),
  (2, '2026-01-02', 150.5)
AS t(id, data_venda, valor);

-- gravar como Delta table no Lakehouse
CREATE TABLE IF NOT EXISTS delta.`${lakehouse_path}/vendas_delta`
USING DELTA
AS SELECT * FROM vendas_tmp;

Depois de correr, verifique: a operação CREATE TABLE gera um commit no _delta_log (um ficheiro JSON com metadados). Se esta operação falhar, a tabela não terá sido criada e não haverá ficheiros Parquet válidos.

Passo 3: Ler a Delta Table com consistência e testar transacções

Uma das vantagens do Delta é que leituras obtêm um snapshot consistente do estado da tabela mesmo que ocorram escritas concorrentes. Teste uma operação de escrita seguida de uma leitura para confirmar o comportamento ACID básico.

-- Exemplo: adicionar linha (transacção simples)
INSERT INTO delta.`${lakehouse_path}/vendas_delta` VALUES (3, '2026-01-03', 200.0);

-- Ler a tabela após a escrita
SELECT * FROM delta.`${lakehouse_path}/vendas_delta` ORDER BY id;

Num cenário de concorrência, um leitor que iniciou antes de um commit verá a versão anterior; um leitor que inicia depois do commit verá a nova versão. Isto garante isolamento de leitura. Em testes práticos, inserir 100–1 000 linhas e medir o tempo de commit (normalmente segundos, conforme o tamanho dos ficheiros) ajuda a calibrar cargas.

Passo 4: Actualizar esquema (schema evolution) de forma segura

Se precisar de adicionar uma coluna, use schema evolution para não quebrar leitores antigos. Delta suporta alterações de esquema controladas. Pode optar por alterar a tabela explicitamente ou fazer append com mergeSchema.

-- Adicionar coluna opcional 'cliente' sem falhar com schema evolution
ALTER TABLE delta.`${lakehouse_path}/vendas_delta`
ADD COLUMNS (cliente STRING);

-- Ou gravar com opção de mergeSchema em operações de escrita via DataFrame (PySpark)
# Python (PySpark) exemplo mínimo
from pyspark.sql import SparkSession
spark = SparkSession.builder.getOrCreate()
df = spark.createDataFrame([(4, '2026-01-04', 75.0, 'Cliente A')], ['id','data_venda','valor','cliente'])
df.write.format('delta').mode('append').option('mergeSchema','true').save(spark.conf.get('lakehouse_path') + '/vendas_delta')

Em ambientes de produção, adopte políticas: por exemplo, permitir apenas colunas opcionais (nullable) ou seguir um processo de revisão para mudanças de esquema. Teste com 1–2 colunas novas e confirme que aplicações existentes continuam a funcionar.

Passo 5: Usar Time Travel básico para recuperar versões

Delta permite consultar versões antigas (Time Travel). Isto é útil para desfazer alterações ou auditar o histórico. Cada commit incrementa a versão — comece por verificar versão 0, 1, etc. Em tabelas pequenas isto é imediato; em tabelas grandes a consulta a versões antigas continua indexada através do _delta_log.

-- Ver a versão anterior (exemplo: versão 0, 1, ...)
SELECT * FROM delta.`${lakehouse_path}/vendas_delta` VERSION AS OF 0;

-- Ou usar timestamp (exemplo)
SELECT * FROM delta.`${lakehouse_path}/vendas_delta` TIMESTAMP AS OF '2026-01-01 00:00:00';

Experimente: faça 3 commits (inserções) e consulte VERSION AS OF 1 para ver o estado intermédio. Isto facilita auditoria e recuperações pontuais.

Verificar o resultado

Confirme que a pasta vendas_delta existe no Lakehouse (OneLake) e que os ficheiros _delta_log e os ficheiros parquet estão presentes. No Notebook, pode listar o directório com comandos da interface (ex.: %fs ls) ou usar APIs:

-- exemplo (Notebook): listar ficheiros
%fs ls /lakehouse///tables/vendas_delta
-- ou em PySpark
spark.read.format('delta').load(spark.conf.get('lakehouse_path') + '/vendas_delta').show()

Procure ficheiros _delta_log/00000000000000000001.json (exemplo) e ficheiros parquet com nomes como part-00000-... .parquet. Execute um SELECT final e verifique as linhas, a nova coluna 'cliente' e que as versões anteriores retornam os dados esperados. Se tudo estiver conforme, tem uma Delta Table pronta para uso com Power BI (Direct Lake) ou para integrar em pipelines ETL/ELT.

Conclusão

Criou uma Delta Table no Lakehouse do Microsoft Fabric, testou escrita, leitura consistente, alteração de esquema e Time Travel básico. Próximos passos recomendados: automatizar escritas com um Spark Job (agendado), configurar retenção de logs e optimizações como compaction/OPTIMIZE para tabelas com milhões de linhas, e expor a tabela para Power BI com Direct Lake. Dica: antes de operações em produção, teste schema evolution e recuperações com Time Travel em ambiente de desenvolvimento para evitar conflitos e perda de dados.