Como criar um Spark SQL View em Lakehouse no Microsoft Fabric

João Barros 29 de August de 2026 6 min de leitura

Este tutorial mostra como criar um Spark SQL View num Lakehouse no Microsoft Fabric, útil para encapsular lógica de transformação, reutilizar consultas em Notebooks e Warehouses, e controlar acesso a dados. Vou explicar o porquê de cada passo e mostrar o como, com exemplos práticos, números plausíveis (ex.: contagens, tamanhos aproximados) e dicas para evitar erros comuns que tipicamente surgem em ambientes de dados corporativos.

Pré-requisitos

Conta com acesso a um workspace do Microsoft Fabric e permissões para editar um Lakehouse.
Lakehouse com pelo menos uma tabela ou ficheiro carregado (por exemplo uma tabela chamada sales_raw) contendo, por exemplo, 100k–5M de linhas e 10–20 colunas.
Conhecimentos básicos de Spark SQL e acesso a Notebooks ou Query editor no Fabric.

Passo 1: Escolher o local e preparar os dados

Decida em que Lakehouse criar a View (por exemplo sales_lakehouse). O objetivo é que a View fique próxima das tabelas base para evitar leituras remotas. Verifique que a tabela base (sales_raw) existe e tem colunas limpas. Faça uma validação inicial: conte linhas, verifique tipos e identifique valores nulos ou outliers. Isto ajuda a estimar impacto de performance (ex.: um scan de 1M de linhas pode demorar 10–30s dependendo do Warehouse).

-- Exemplo: verificar colunas e algumas linhas
SELECT * FROM sales_lakehouse.catalog.sales_raw LIMIT 10;
-- Contar linhas para estimativa
SELECT COUNT(*) AS total_rows FROM sales_lakehouse.catalog.sales_raw;

Se encontrar 20% de amounts nulos, por exemplo, trate ou filtre antes de construir a View para evitar resultados surpreendentes e para optimizar scans.

Passo 2: Criar uma View temporária (opcional) para testar a lógica

Antes de criar uma View persistente, teste a lógica com uma temp view num Notebook. Assim evita criar objetos permanentes que depois precise de remover e pode iterar rapidamente. Use dados limitados (LIMIT 1k) para testar performance localmente.

# Em PySpark (Notebook)
spark.sql("CREATE OR REPLACE TEMP VIEW tmp_sales AS
SELECT customer_id, order_date, amount, region
FROM sales_lakehouse.catalog.sales_raw
WHERE amount > 0 LIMIT 1000")

# Verificar
spark.sql("SELECT * FROM tmp_sales LIMIT 5").show()

Verifique amostras (5–10 linhas) e estatísticas básicas: MIN/MAX/AVG para colunas numéricas, contagem de NULLs. Isto evita erros como casts inválidos ao promover colunas para DATE ou NUMERIC.

Passo 3: Definir a lógica da View em Spark SQL

Escreva a consulta definitiva que encapsula a transformação. Mantenha-a simples e documentada: nomes de colunas explicativos, filtros claros e comentários inline. Se for uma transformação complexa, divida em subqueries nomeadas. Isto facilita manutenção, teste e optimização — por exemplo, reduzir o conjunto de dados antes de fazer joins pesados.

-- Exemplo de lógica para uma View
CREATE OR REPLACE VIEW sales_lakehouse.catalog.vw_sales_clean AS
SELECT
  customer_id,
  CAST(order_date AS DATE) AS order_date,
  amount,
  UPPER(region) AS region
FROM sales_lakehouse.catalog.sales_raw
WHERE amount IS NOT NULL AND amount > 0;

Comentário: se a tabela tiver 2M de linhas e o filtro reduzir para 1.2M, a View funciona na lógica e reflecte alterações da tabela base sem cópia de dados. Para cargas muito grandes, considere particionar a tabela base por order_date para melhorar scans.

Passo 4: Executar a criação da View no ambiente correcto

Abra o Query editor do Lakehouse ou um Notebook com contexto para o Lakehouse e execute o CREATE VIEW. Certifique-se de que o contexto (catalog/schema) está correcto para evitar criar a View no espaço errado. Se preferir, pode usar T-SQL num Warehouse ligado ao Lakehouse, mas aqui usamos Spark SQL para compatibilidade com Notebooks e automação programática.

-- No Notebook ou Query editor (Spark SQL)
spark.sql(open('create_view.sql').read())
-- ou executar directamente a instrução SQL do passo anterior

Após executar, valide com um SELECT de verificação. Se houver erro, verifique mensagens: problemas comuns incluem permissões insuficientes, tipos incompatíveis no CAST, ou nomes de tabela/catálogo incorrectos.

Passo 5: Controlar permissões e documentar

Após criar a View, ajuste permissões no Lakehouse para que apenas equipas autorizadas leiam ou alterem a View. No Fabric, normalmente concede-se SELECT a um grupo de analistas e CONTROL ou OWNERSHIP apenas a administradores. Documente o propósito, versão da lógica e dependências (tabelas base) num ficheiro README no mesmo Lakehouse ou no repositório Git associado.

-- Exemplo: verificar permissões (comandos dependem da UI do Fabric)
-- No UI: Lakehouse -> Security -> Grant SELECT a grupo-analistas

Inclua também notas sobre SLAs esperados (ex.: consultas a esta View devem responder em < 5s para amostras de 100 linhas) e quando materializar a View se o custo de computação for elevado.

Verificar o resultado

Para confirmar que a View foi criada e funciona: faça consultas simples, verifique planos de execução (EXPLAIN) e use a View num Notebook ou Warehouse. Verifique também que alterações na tabela base reflectem na View (porque é lógica, não cópia). Execute testes de desempenho com filtros típicos (ex.: WHERE region = 'EUROPE') e meça execuções — se o tempo médio for superior a 30s para filtros comuns, considere materializar ou rever particionamento.

-- Testes rápidos
SELECT COUNT(*) FROM sales_lakehouse.catalog.vw_sales_clean;
SELECT * FROM sales_lakehouse.catalog.vw_sales_clean LIMIT 10;
-- Ver plano de execução para identificar scans pesados
EXPLAIN SELECT * FROM sales_lakehouse.catalog.vw_sales_clean WHERE region = 'EUROPE';

Conclusão

Criar um Spark SQL View num Lakehouse no Microsoft Fabric ajuda a reutilizar lógica de transformação, simplificar queries e gerir acesso. Próximos passos práticos: criar views parametrizadas, transformar a View em tabela materializada quando houver necessidade de performance, e incluir a criação da View no controlo de versões (Git) com comentários de mudança. Dica final: se as consultas estiverem lentas, verifique particionamento e estatísticas da tabela base ou materialize resultados que são caros de calcular repetidamente.