DP-700: como implementar Data Lakehouse com OneLake e Delta

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

Vou explicar como implementar um Data Lakehouse em Microsoft Fabric usando OneLake e Delta tables. Esta competência é relevante para o exame DP-700 porque mostra como organizar dados persistentes para analytics e, na prática, melhora fiabilidade, desempenho e governação das soluções analytics. A abordagem Lakehouse combina simplicidade operacional com garantias ACID que são cruciais quando tens cargas de trabalho com milhões de linhas e múltiplos consumidores (ETL, data science, Power BI).

O que precisas de saber

Um Data Lakehouse combina a escalabilidade de um data lake com estruturas e garantias de um data warehouse. No contexto do Fabric, OneLake é o armazenamento unificado e Delta tables (formato Delta) trazem transacções ACID, snapshots e partições. Conceitos-chave:

OneLake: camada de armazenamento centralizada do Fabric — armazena ficheiros Parquet, Delta e outros, acessível por todos os workloads (Data Engineering, Power BI, Spark, etc.). Um único repositório facilita políticas de retenção e encriptação a nível de ficheiro.
Delta table: formato que implementa transacções ACID, permite updates, deletes, merge e time-travel; mantém um transaction log que coordena operações concorrentes e permite restaurar estados anteriores (por exemplo, recuperar uma versão de há 3 dias).
Lakehouse layout: zonas típicas (raw, curated, serving); utilizar controlos de acesso e políticas de retenção. Por exemplo, uma organização pode ter 10 TB na zona raw, 2 TB na zona curated e 200 GB optimizados na zona serving para relatórios interativos.

Exemplo simples: um fluxo de ingestão coloca ficheiros CSV na zona raw em OneLake; um pipeline transforma esses ficheiros para Parquet/Delta na zona curated; consultas analíticas fazem-se sobre Delta tables na zona serving. Em ambientes com 100M–500M de registos, é comum compactar ficheiros em blocos de 100–256 MB para optimizar leituras.

Como funciona na prática

Passos essenciais para implementar um Lakehouse com OneLake e Delta no Fabric:

Planeamento do layout de OneLake: criar pastas/contentores para raw/, curated/ e serving/ com políticas de acesso diferentes (ex.: apenas o serviço de ingestão tem write em raw/; equipa de transformação tem write em curated/; analistas têm read em serving/).
Ingestão inicial: usar Dataflows, Synapse pipelines, ou Spark para copiar ficheiros para raw/. Para cargas constantes, avalia usar streaming (append) ou bateladas com intervalos de 15 minutos a 24 horas conforme a latência desejada.
Transformação para Delta: converter os dados em Delta tables, aplicar partição quando relevante e manter schemas versionados. Por exemplo, particionar por year/month para conjuntos temporais com dezenas de milhões de linhas por mês.
Expor para consumo: registar as Delta tables no catálogo de dados (metastore) e configurar permissões para equipas de analytics, definindo grupos e níveis de acesso (read, read/write, admin).

Exemplo de código Spark (conceito) para criar uma Delta table a partir de dados CSV no OneLake. Isto é executado num Notebook Spark no Fabric:

// montar caminho OneLake
val rawPath = "abfss://container@account.dfs.microsoft.com/raw/sales/"
val curatedPath = "abfss://container@account.dfs.microsoft.com/curated/sales_delta/"

// ler CSV
val df = spark.read.option("header", "true").csv(rawPath)

// limpeza e tipagem
import org.apache.spark.sql.functions._
val dfClean = df.withColumn("amount", col("amount").cast("double"))

// escrever como Delta, particionar por ano
dfClean.write.format("delta")
  .mode("overwrite")
  .partitionBy("year")
  .save(curatedPath)

// registar no metastore
spark.sql(s"CREATE TABLE IF NOT EXISTS curated.sales USING DELTA LOCATION '$curatedPath'")

Notas: no Fabric os caminhos e permissões são geridos via OneLake; a sintaxe pode variar se usares Python/Scala/SQL em diferentes ambientes (Notebook Spark, Dataflow, etc.). Em produção, adiciona testes de esquema e validação de qualidade (ex.: percentagem de nulls) antes de sobrescrever uma tabela Delta.

Erros comuns

2–3 armadilhas frequentes ao implementar um Lakehouse em Fabric:

Não particionar correctamente: escolher colunas de partição com muita cardinalidade (por exemplo, customer_id único por linha) cria milhares/milhões de pequenos ficheiros; escolher colunas com muito baixa cardinalidade força leituras de muitos dados. Regra prática: idealmente tens centenas a alguns milhares de ficheiros por partição, e ficheiros finais com ~100–250 MB.
Ignorar o transaction log: manipular ficheiros Delta directamente sem usar o motor Delta (ex.: copiar/renomear ficheiros em OneLake) corrompe o estado. Usa sempre operações suportadas (WRITE, MERGE, VACUUM via Delta APIs). O transaction log permite time-travel e é crítico para consistência com cargas concorrentes.
Permissões mal definidas: dar acesso directo à zona raw sem controlo pode causar corrupção ou fugas de dados. Segregar zonas e aplicar políticas de acesso e protecção de dados — por exemplo, apenas 2 identidades com write em raw, uma equipa de data engineering com write em curated e analistas com read em serving.

Como praticar

Para consolidar esta competência, pratica o seguinte:

Cria um workspace no Fabric (ou usa uma subscrição de avaliação) e monta um fluxo simples: colocar ficheiros CSV em raw, transformá‑los para Delta na zona curated e registar a tabela no metastore. Faz isso com um dataset de teste de 1–10 GB (10M–50M linhas) para ver comportamento real.
Testa operações Delta: INSERT, UPDATE, DELETE e MERGE; verifica o time-travel (restaurar uma versão anterior) e usa VACUUM para remover ficheiros antigos (nota: retenção por defeito é 7 dias).
Experimenta optimizações: criar partições, compactar ficheiros (OPTIMIZE) e medir impacto nas queries. Em muitos casos OPTIMIZE+ZORDER reduz tempos de consulta interativos em 30–70% dependendo do padrão de acesso.
Mede custos e desempenho: executa queries antes e depois da optimização, regista tempos e I/O lido para justificar alterações de layout.

Para preparação formal do exame, usa o Practice Assessment OFICIAL e gratuito da Microsoft e a study guide oficial (ambos gratuitos). Estes recursos ajudam a ver as áreas medidas pelo exame sem recorrer a materiais proibidos.

Em resumo

OneLake + Delta implementam um Lakehouse que traz escalabilidade e garantias ACID para analytics.
Organiza o armazenamento em zonas (raw/curated/serving) e aplica permissões e políticas de retenção para proteger dados e facilitar auditorias.
Particionamento adequado, uso correcto do transaction log e operações suportadas Delta (MERGE/OPTIMIZE/VACUUM) são cruciais para integridade e desempenho em datasets de dezenas a centenas de milhões de linhas.
Pratica num workspace Fabric: cria Delta tables, executa MERGE/UPDATE/DELETE, experimenta OPTIMIZE e time-travel, e mede sempre impacto em latência e custos.