Cómo crear una Spark SQL View en Lakehouse en Microsoft Fabric

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

Este tutorial muestra cómo crear una Spark SQL View en un Lakehouse en Microsoft Fabric, útil para encapsular lógica de transformación, reutilizar consultas en Notebooks y Warehouses, y controlar el acceso a datos. Explicaré el porqué de cada paso y mostraré el cómo, con ejemplos prácticos, cifras plausibles (p. ej.: cuentas, tamaños aproximados) y consejos para evitar errores comunes que suelen surgir en entornos de datos corporativos.

Requisitos previos

Cuenta con acceso a un workspace de Microsoft Fabric y permisos para editar un Lakehouse.
Lakehouse con al menos una tabla o archivo cargado (por ejemplo una tabla llamada sales_raw) que contenga, por ejemplo, 100k–5M de filas y 10–20 columnas.
Conocimientos básicos de Spark SQL y acceso a Notebooks o Query editor en el Fabric.

Paso 1: Elegir el lugar y preparar los datos

Decida en qué Lakehouse crear la View (por ejemplo sales_lakehouse). El objetivo es que la View quede próxima a las tablas base para evitar lecturas remotas. Verifique que la tabla base (sales_raw) existe y tiene columnas limpias. Haga una validación inicial: cuente filas, verifique tipos e identifique valores nulos o outliers. Esto ayuda a estimar el impacto en el rendimiento (p. ej.: un scan de 1M de filas puede tardar 10–30s dependiendo del 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;

Si encuentra, por ejemplo, un 20% de amounts nulos, trate o filtre antes de construir la View para evitar resultados inesperados y para optimizar scans.

Paso 2: Crear una View temporal (opcional) para probar la lógica

Antes de crear una View persistente, pruebe la lógica con una temp view en un Notebook. Así evita crear objetos permanentes que luego necesite eliminar y puede iterar rápidamente. Use datos limitados (LIMIT 1k) para probar el rendimiento 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()

Compruebe muestras (5–10 filas) y estadísticas básicas: MIN/MAX/AVG para columnas numéricas, conteo de NULLs. Esto evita errores como casts inválidos al promover columnas a DATE o NUMERIC.

Paso 3: Definir la lógica de la View en Spark SQL

Escriba la consulta definitiva que encapsula la transformación. Manténgala simple y documentada: nombres de columnas explicativos, filtros claros y comentarios inline. Si es una transformación compleja, divida en subqueries nombradas. Esto facilita el mantenimiento, las pruebas y la optimización — por ejemplo, reducir el conjunto de datos antes de realizar 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;

Comentario: si la tabla tiene 2M de filas y el filtro reduce a 1.2M, la View funciona en la lógica y refleja cambios de la tabla base sin copia de datos. Para cargas muy grandes, considere particionar la tabla base por order_date para mejorar los scans.

Paso 4: Ejecutar la creación de la View en el entorno correcto

Abra el Query editor del Lakehouse o un Notebook con contexto para el Lakehouse y ejecute el CREATE VIEW. Asegúrese de que el contexto (catalog/schema) está correcto para evitar crear la View en el lugar equivocado. Si lo prefiere, puede usar T-SQL en un Warehouse conectado al Lakehouse, pero aquí usamos Spark SQL para compatibilidad con Notebooks y automatización 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

Tras ejecutar, valide con un SELECT de verificación. Si hay error, revise los mensajes: problemas comunes incluyen permisos insuficientes, tipos incompatibles en el CAST, o nombres de tabla/catálogo incorrectos.

Paso 5: Controlar permisos y documentar

Después de crear la View, ajuste permisos en el Lakehouse para que solo los equipos autorizados lean o modifiquen la View. En Fabric, normalmente se concede SELECT a un grupo de analistas y CONTROL u OWNERSHIP solo a administradores. Documente el propósito, la versión de la lógica y las dependencias (tablas base) en un archivo README en el mismo Lakehouse o en el repositorio Git asociado.

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

Incluya también notas sobre SLAs esperados (p. ej.: consultas a esta View deben responder en < 5s para muestras de 100 filas) y cuándo materializar la View si el coste computacional es elevado.

Verificar el resultado

Para confirmar que la View se creó y funciona: haga consultas simples, verifique planes de ejecución (EXPLAIN) y use la View en un Notebook o Warehouse. Verifique también que los cambios en la tabla base se reflejan en la View (porque es lógica, no copia). Ejecute pruebas de rendimiento con filtros típicos (p. ej.: WHERE region = 'EUROPE') y mida las ejecuciones — si el tiempo medio es superior a 30s para filtros comunes, considere materializar o revisar particionamiento.

-- 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';

Conclusión

Crear una Spark SQL View en un Lakehouse en Microsoft Fabric ayuda a reutilizar lógica de transformación, simplificar queries y gestionar acceso. Próximos pasos prácticos: crear views parametrizadas, transformar la View en tabla materializada cuando haya necesidad de rendimiento, e incluir la creación de la View en el control de versiones (Git) con comentarios de cambio. Consejo final: si las consultas están lentas, revise el particionamiento y las estadísticas de la tabla base o materialice resultados que sean caros de calcular repetidamente.