Lakehouses en Microsoft Fabric

¿Qué te enseña este módulo?

Este es el módulo donde vemos el elemento fundamental del data engineering en Fabric: el lakehouse. Los objetivos oficiales del módulo son:

1. Describir características y capacidades de los lakehouses en Fabric.
2. Crear un lakehouse.
3. Ingestar y transformar datos en un lakehouse.
4. Consultar y analizar los datos con SQL y Spark.

Peso en el examen DP-700

El lakehouse es el corazón de la DP-700. Aparece transversalmente en los tres dominios:

🎯 Qué cambia respecto a la DP-600

En la DP-600 el lakehouse se cubre desde la perspectiva del consumo Power BI: Direct Lake, semantic models, medidas DAX. En DP-700 el enfoque cambia radicalmente y aparecen conceptos que ANTES no se profundizaban:

• 🆕 Managed vs external tables (a nivel Spark)
• 🆕 Schema-enabled lakehouses (feature moderna)
• 🆕 SQL analytics endpoint sync: cómo funciona el metadata sync y cómo forzarlo
• 🆕 Delta Lake profundo: transaction log, time travel, ACID en detalle
• 🆕 Automatic table discovery en Tables
• 🆕 Cambio importante 2025: los default semantic models YA NO se crean automáticamente

Definición

Un lakehouse en Microsoft Fabric es un item de storage que combina lo mejor de dos mundos:

• 🌊 Flexibilidad del data lake: puede almacenar cualquier tipo de dato (estructurado, semi-estructurado, no estructurado) en su formato nativo.
• 🏛️ Capacidad analítica del data warehouse: puedes definir tablas con schema, aplicar transacciones ACID, y consultar con SQL.

La idea fundamental: puentear la brecha entre data lake y data warehouse trayendo capacidades de base de datos directamente sobre tu data lake, eliminando la necesidad de mantener sistemas separados.

¿Dónde vive un lakehouse?

Un lakehouse vive en un workspace de Fabric y físicamente sus datos se almacenan en OneLake (que como vimos en el Módulo 1, está construido sobre ADLS Gen2). Cada lakehouse ocupa una parte del OneLake del tenant.

¿Qué hace un lakehouse diferente de un data lake tradicional?

Un data lake tradicional (por ejemplo, un contenedor ADLS Gen2 sin más) es un almacén de ficheros. No sabe qué es una "tabla", no soporta transacciones, y para consultar sus datos necesitas un motor externo (Spark, Hive, etc.).

Un lakehouse añade encima:

• Un metastore que registra qué carpetas son tablas.
• Un formato de tabla (Delta Lake) que aporta ACID, schema, versionado, time travel.
• Un SQL analytics endpoint para consultar con T-SQL sin configurar nada.
• Integración nativa con el resto del ecosistema Fabric (Power BI, notebooks, pipelines, etc.).

⚠️ AVISO CRÍTICO: cambio de septiembre 2025

Este punto es super importante porque en muchos materiales antiguos (incluida la DP-600) se dice que al crear un lakehouse se generan 3 items: lakehouse, SQL analytics endpoint y semantic model por defecto.

Qué se crea AHORA al crear un lakehouse

Solo se crean 2 items en tu workspace:

1. 🏠 El lakehouse propiamente dicho (contiene Tables, Files y shortcuts).
2. 🔎 El SQL analytics endpoint (auto-provisionado, read-only, permite T-SQL).

Si quieres un semantic model, tienes que crearlo tú explícitamente después. Ya no es automático.

Qué eran los default semantic models (contexto)

Solo por si te aparecen en preguntas antiguas: un default semantic model era un modelo Power BI que se creaba automáticamente al crear el lakehouse, contenía las mismas tablas, estaba acoplado al lakehouse (si borrabas el lakehouse, se borraba el modelo) y usaba Direct Lake mode. Ahora los semantic models son items independientes que tú creas cuando los necesitas.

Este es un tema muy examinable. Un lakehouse organiza los datos en dos carpetas top-level: Tables y Files.

La carpeta Tables

Propósito: almacenar tablas Delta Lake estructuradas y consultables.

• ✅ Soporta queries SQL vía el SQL analytics endpoint
• ✅ Enforcea schemas (rechaza escrituras que no cumplan el schema)
• ✅ Soporta transacciones ACID
• ✅ Accesible desde Power BI para reporting
• ✅ Se auto-optimiza con V-Order compression
• ✅ Automatic table discovery: cuando pones datos Delta en Tables, Fabric los registra automáticamente en el metastore

La carpeta Files

Propósito: almacenar datos raw o semi-estructurados en su formato nativo.

• ✅ Soporta cualquier formato de fichero: CSV, JSON, Parquet, imágenes, PDFs, XML, TXT, etc.
• ✅ Flexible para exploración y procesamiento
• ✅ Ideal para staging antes de transformar a Tables
• ❌ NO enforcea schema
• ❌ NO soporta queries T-SQL directas (Files no aparece en SQL endpoint)
• ✅ Spark puede leerlos programáticamente

🎯 Comparativa esencial

🎯 Automatic table discovery (importante)

Cuando pones datos Delta en la carpeta Tables, Fabric hace automáticamente:

1. Valida el formato (Delta).
2. Extrae metadata: nombres de columnas, tipos, compresión, particiones.
3. Registra la tabla en el metastore.
4. La expone en el SQL analytics endpoint y en el Lakehouse explorer.

No tienes que escribir CREATE TABLE manualmente para los datos que "aterrizas" en Tables.

Cuándo usar cada uno (regla práctica)

• Files → datos raw sin procesar, staging, bronze de medallion, ficheros no estructurados (PDFs, imágenes, logs), datos que quieres reprocesar más tarde.
• Tables → datos ya limpios y con schema definido, silver/gold de medallion, todo lo que quieras consumir desde SQL o Power BI.

Delta Lake es la tecnología subyacente de todas las tablas de un lakehouse. Vamos a profundizar porque en DP-700 te van a preguntar por sus features específicas.

¿Qué es Delta Lake?

Delta Lake es un formato de tabla open-source desarrollado por Databricks que aporta fiabilidad y capacidades relacionales sobre ficheros Parquet en un data lake. En Fabric es el formato por defecto para tablas y es la base de toda tabla del lakehouse.

Estructura física de una Delta table

Tables/mi_tabla/
├── part-00000-....parquet    ← Ficheros de datos (Parquet)
├── part-00001-....parquet
├── ...
└── _delta_log/               ← Transaction log (JSON)
    ├── 00000000000000000000.json
    ├── 00000000000000000001.json
    └── ...

• Los datos son ficheros Parquet (columnar, comprimido).
• El transaction log es una carpeta _delta_log con ficheros JSON que registran cada cambio a la tabla.
• Cada operación (insert, update, delete, merge) genera una nueva entrada en el log.

Los cuatro superpoderes de Delta Lake 🌟

🎯 A) ACID Transactions. Delta garantiza Atomicity (una operación se completa entera o no se ejecuta), Consistency (los datos siempre están en un estado válido), Isolation (múltiples usuarios pueden leer/escribir sin corromper datos) y Durability (los cambios persisten aunque el sistema falle). Esto es lo que hace que puedas escribir concurrentemente desde varios notebooks sin corromper la tabla.

🎯 B) Schema Enforcement. Delta valida cada escritura contra el schema definido. Si intentas escribir una fila que no cumple el schema (tipo distinto, columna extra sin declararla, etc.), la operación falla. Esto previene data corruption por schema drift.

🎯 C) Time Travel. Delta mantiene el historial de todas las versiones de una tabla. Puedes consultar cómo estaba la tabla en un punto pasado:

# PySpark, por número de versión
df = spark.read.format("delta").option("versionAsOf", 5).load("Tables/mi_tabla")

-- Spark SQL, por timestamp
SELECT * FROM mi_tabla TIMESTAMP AS OF '2026-04-01T10:00:00'

Uso práctico: auditar cambios, revertir errores, análisis histórico, debugging. Por defecto, las versiones se guardan 30 días (configurable con logRetentionDuration). Después, VACUUM puede purgar ficheros viejos y ya no tendrás time travel a esos puntos.

🎯 D) Efficient Updates and Deletes. Los data lakes tradicionales con Parquet no soportan updates ni deletes (los ficheros son inmutables). Delta permite UPDATE, DELETE y MERGE INTO (upsert) de forma eficiente añadiendo nuevos ficheros y marcando los antiguos como obsoletos en el log.

🎯 V-Order (feature exclusiva de Fabric)

V-Order es una optimización de escritura específica de Fabric (no está en Delta open-source estándar) que reordena y comprime los ficheros Parquet para acelerar las lecturas desde motores columnar (VertiPaq de Power BI, engine del Warehouse, etc.).

• Está activado por defecto en Fabric (spark.sql.parquet.vorder.enabled = true).
• Añade un pequeño overhead al escribir, pero acelera muchísimo las lecturas (especialmente desde Direct Lake y SQL analytics endpoint).
• Recomendación oficial: dejarlo activado para tablas que se leen mucho.

🎯 OPTIMIZE y VACUUM (mantenimiento crítico)

Con el tiempo, las tablas Delta acumulan muchos ficheros pequeños (por muchas operaciones de escritura pequeñas) y ficheros obsoletos que ya no se necesitan (por updates/deletes). Dos comandos clave para mantener el rendimiento:

OPTIMIZE: compacta ficheros pequeños en ficheros más grandes.

OPTIMIZE mi_tabla

Opcional: Z-ORDER para co-localizar datos por columnas frecuentemente filtradas:

OPTIMIZE mi_tabla ZORDER BY (columna_frecuente)

VACUUM: elimina ficheros obsoletos que ya no forman parte de la tabla activa.

VACUUM mi_tabla RETAIN 168 HOURS  -- Retiene 7 días de historial

Este es un tema con matices sutiles que hay que dominar.

Managed tables (el caso normal)

Una managed table es una tabla donde Fabric controla tanto el metadata como los ficheros de datos.

# La ruta no se especifica; Fabric la gestiona
df.write.format("delta").saveAsTable("mi_tabla_managed")

Comportamiento: los ficheros se guardan en Tables/mi_tabla_managed/, aparece en el Lakehouse explorer bajo Tables, y si haces DROP TABLE se borran también los ficheros de datos. 🎯 Es el enfoque recomendado y "estándar" para lakehouses en Fabric.

External tables (matices importantes)

Una external table es una tabla donde Fabric controla solo el metadata, pero los ficheros de datos viven en otra ubicación.

# Se especifica una ruta externa (por ejemplo en Files o en ADLS)
df.write.format("delta").saveAsTable(
    "mi_tabla_external",
    path="Files/mi_carpeta/mi_tabla_external"
)

# O apuntando a ADLS Gen2 directamente
df.write.format("delta").saveAsTable(
    "mi_tabla_external",
    path="abfss://container@storage.dfs.core.windows.net/mi_tabla"
)

Comportamiento: el metadata se registra en el metastore, los datos viven en la ruta especificada (fuera de Tables/), y si haces DROP TABLE se borra solo el metadata, los ficheros permanecen.

⚠️ Matiz crítico: la documentación oficial DP-700

Cómo entender esta aparente contradicción:

1. Con CREATE TABLE nombre USING DELTA LOCATION '...' (SQL DDL puro) → NO soportado en lakehouses.
2. Con df.write.format("delta").saveAsTable(nombre, path='...') desde Spark → SÍ funciona técnicamente (Spark lo crea), pero es un enfoque que puede darte problemas.
3. La recomendación oficial para acceder a datos externos es usar shortcuts, no external tables.

¿Qué son?

Los schemas en un lakehouse permiten agrupar tablas en colecciones nombradas (como sales, marketing, hr). Es equivalente al concepto de "schema" en SQL Server. Cuando creas un lakehouse nuevo, los schemas están habilitados por defecto desde el portal. Se crea automáticamente un schema llamado dbo.

Por qué usar schemas (6 beneficios oficiales)

1. 🎯 Organizar tablas por dominio — más manejable cuando crece el número de tablas.
2. 🎯 Control de acceso a nivel schema — dar permisos por schema, aplicar RLS/CLS a tablas dentro del schema.
3. 🎯 Consultas cross-workspace con el four-part namespace: workspace.lakehouse.schema.table.
4. 🎯 Schema shortcuts — mapear todo un schema a una carpeta con múltiples tablas Delta en otro lakehouse o ADLS.
5. 🎯 Features avanzadas — como materialized lake views requieren schema-enabled lakehouses.
6. 🎯 Naming rules — los nombres de schema solo pueden contener letras, números y guiones bajos (_).

Cómo se crean

Desde el portal: es el default al crear un lakehouse (schemas enabled by default). Desde la REST API: hay que especificarlo:

POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/lakehouses

{
  "displayName": "Lakehouse_created_with_schema",
  "description": "A schema enabled lakehouse.",
  "creationPayload": {
    "enableSchemas": true
  }
}

🎯 Four-part namespace (cross-workspace queries)

Con schemas puedes referenciar tablas en cualquier workspace desde un notebook:

-- Referenciar una tabla en otro workspace + lakehouse + schema
SELECT * FROM mi_workspace.mi_lakehouse.sales.orders

Esto es super poderoso para arquitecturas donde distintos workspaces tienen distintos dominios de datos.

Uso desde notebooks

# Notación completa
df = spark.sql("SELECT * FROM sales.orders")

# Notación completa cross-workspace
df = spark.sql("SELECT * FROM ws_ventas.lh_gold.sales.orders")

# Notación simplificada (usa el default lakehouse y schema dbo)
df = spark.sql("SELECT * FROM orders")  # Equivale a dbo.orders del default lakehouse

Schema shortcuts

Un schema shortcut crea un schema en tu lakehouse que referencia todas las tablas Delta de una carpeta en otro lakehouse o en ADLS Gen2. Al referenciar, no copia datos. Uso típico: publicar un "catálogo de datos" desde un workspace maestro a workspaces de consumo.

⚠️ Limitaciones actuales

Compatibilidad con lakehouses no-schema: Spark puede consultar y hacer joins entre lakehouses schema-enabled y no-schema en el mismo código. No hay incompatibilidad total, pero la migración manual sigue siendo la única opción.

En Fabric hay cinco métodos oficiales para meter datos en un lakehouse:

1. Upload manual

Cuándo: pruebas, exploración, ficheros pequeños ad-hoc. Desde el Lakehouse explorer: menú → Upload → seleccionas fichero/carpeta local. Los ficheros van a Files por defecto (no a Tables).

2. Load to Table

Cuándo: quieres una tabla Delta rápida sin código desde un CSV o Parquet. Desde el Lakehouse explorer: seleccionas un fichero en Files → botón derecho → Load to Table. Soporta Parquet y CSV, puedes append u overwrite, es no-code, ideal para pruebas rápidas.

3. Dataflows Gen2

Cuándo: quieres transformar con Power Query en modo low-code, o cuando el equipo viene de Excel/Power BI. Usa la interfaz visual de Power Query M, conecta a más de 300 fuentes, y al final escribe a Lakehouse (o Warehouse) como destino.

4. Notebooks (PySpark, Spark SQL, Scala, R)

Cuándo: transformaciones complejas, código personalizado, ML, integración con librerías Python.

# Leer un CSV desde Files y escribirlo como tabla Delta
df = spark.read.option("header", "true").csv("Files/mi_csv.csv")
df.write.format("delta").mode("overwrite").saveAsTable("mi_tabla")

5. Data Factory pipelines

Cuándo: mover datos desde fuentes externas (on-prem, otra cloud, SaaS), orquestación con dependencias, retry logic, movimientos batch masivos. Usa la actividad Copy Data dentro de un pipeline.

🎯 Regla del pulgar para el examen

Como ya vimos los shortcuts en profundidad en el Módulo 1, aquí solo repasamos lo específico del lakehouse:

Dónde crear shortcuts

• En Tables: solo top-level, y si es Delta → se registra automáticamente como tabla.
• En Files: en cualquier nivel, cualquier formato, pero no se registra como tabla.

Tres tipos de shortcut en Tables

• New table shortcut: apunta a una única tabla Delta.
• New schema shortcut: apunta a una carpeta con múltiples tablas Delta → aparece como un schema con todas las tablas.
• New shortcut (Files): para cualquier formato y estructura.

Por qué usar shortcuts en un lakehouse

Reduce copias de datos, permite consultar datos entre workspaces/tenants sin duplicar, acceder a storage externo (ADLS, S3, GCS) sin ingesta, combinar datos multi-fuente sin ETL y reducir costes de storage.

Ya vimos los métodos de ingesta. Para transformación las herramientas son las mismas pero con distinta filosofía:

Notebooks (favorito del data engineer)

• Lenguajes: PySpark, Spark SQL, Scala, SparkR.
• Interactivos: cell-by-cell, con visualizaciones inline.
• Copilot en notebooks: genera código PySpark/Spark SQL desde lenguaje natural y explica código existente.
• Ideal para: lógica compleja, machine learning, integración con librerías Python.

Dataflows Gen2 (favorito del analista)

• Interfaz Power Query M (misma que Excel y Power BI).
• Low-code visual, 300+ conectores.
• Ideal para: usuarios familiarizados con Power BI, transformaciones tabulares.

Pipelines (orquestación visual)

• Interfaz visual para diseñar workflows.
• Actividades: Copy Data, Notebook, Dataflow, Stored Procedure, etc.
• Ejecución secuencial o paralela con dependencias.
• Ideal para: orquestar el pipeline completo (ingesta → transformación → carga).

Este es uno de los temas más importantes y examinables del módulo. Presta atención especial.

¿Qué es?

El SQL analytics endpoint es una interfaz T-SQL read-only sobre las tablas Delta del lakehouse. Se auto-provisiona con cada lakehouse al crearlo, no hay que configurar nada. Detrás del capó corre en el mismo motor que Fabric Data Warehouse, así que tiene rendimiento comparable a un warehouse relacional para consultas.

Otros items que también auto-provisionan SQL analytics endpoint

No es exclusivo del lakehouse. También lo tienen Warehouses (obvio), Mirrored databases, SQL databases in Fabric y Azure Cosmos DB in Fabric. Un workspace puede tener más SQL analytics endpoints que lakehouses, porque cada item cuenta.

🎯 Es READ-ONLY sobre las tablas Delta

Puedes hacer:

• ✅ SELECT (consultas)
• ✅ CREATE VIEW (vistas)
• ✅ CREATE FUNCTION (funciones)
• ✅ CREATE PROCEDURE (procedimientos)
• ✅ Aplicar seguridad SQL (RLS, CLS, OLS)

NO puedes hacer:

• ❌ INSERT / UPDATE / DELETE / MERGE en las tablas Delta (para eso usa Spark)
• ❌ CREATE TABLE sobre las tablas auto-generadas (son gestionadas por el sistema)
• ❌ DROP TABLE sobre las auto-generadas

Para modificar datos debes usar Spark desde un notebook.

🎯 Metadata sync (importantísimo)

Cuando cambias las tablas Delta desde Spark (creas una nueva, insertas filas, etc.), el SQL endpoint tiene que sincronizarse para reflejar esos cambios.

• Un proceso background lee los Delta logs del /Tables y actualiza el schema SQL.
• Es automático y transparente.
• La latencia normal es de segundos a menos de un minuto.
• El proceso corre solo cuando el SQL endpoint está activo. Se detiene tras 15 minutos de inactividad.

⚠️ Cuándo hay delays significativos

1. Muchos lakehouses en el mismo workspace → un solo proceso de auto-discovery para todo el workspace. Solución: mover cada lakehouse a su propio workspace.
2. Muchos ficheros pequeños en la tabla Delta (fragmentación) → el escaneo es más lento. Solución: OPTIMIZE regular.
3. Alto volumen de cambios simultáneos durante ETL grande → delay esperado hasta procesar todo.
4. Alta cardinalidad de particiones → escaneo más lento. Solución: elegir particiones con menor cardinalidad, target ~1 GB por partición.

🎯 Cómo forzar refresh del metadata (3 formas)

A) Desde el portal: en el SQL analytics endpoint editor → botón Refresh en el ribbon.

B) Vía REST API:

POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/sqlEndpoints/{sqlEndpointId}/refreshMetadata

C) Vía T-SQL stored procedure (feature reciente): Fabric expone un stored procedure para forzar el refresh desde T-SQL.

Casos de uso típicos

• Consultas ad-hoc: investigar datos rápidamente.
• Conexión desde BI: Power BI, Excel, Azure Data Studio, SSMS.
• Validación de datos: verificar resultados de transformaciones.
• Vistas curadas: crear CREATE VIEW con joins y business logic para consumidores.

Los notebooks son la herramienta principal del data engineer en Fabric.

Spark SQL vs PySpark

Spark SQL (sintaxis SQL familiar):

%%sql
SELECT * FROM sales.orders WHERE order_date >= '2026-01-01'

O desde una celda Python:

df = spark.sql("SELECT * FROM sales.orders WHERE order_date >= '2026-01-01'")
display(df)

PySpark (API programática con DataFrames):

from pyspark.sql.functions import col

df = (spark.table("sales.orders")
      .filter(col("order_date") >= "2026-01-01"))

display(df)

Cuándo usar cada uno

• Spark SQL: cuando ya sabes SQL y la lógica es analítica pura (SELECT, JOIN, GROUP BY…).
• PySpark: cuando necesitas lógica programática, loops, funciones Python personalizadas, ML, integración con librerías Python.

Copilot en notebooks

Puede generar código PySpark o Spark SQL desde lenguaje natural, explicar código existente y sugerir optimizaciones. Útil especialmente si estás aprendiendo PySpark: solo tienes que escribir un comentario # Filtra pedidos del último trimestre y te sugiere el código.

Cross-workspace queries

-- Join entre lakehouses de distintos workspaces
SELECT o.order_id, c.customer_name
FROM ws_ventas.lh_gold.sales.orders o
JOIN ws_maestros.lh_maestros.dim.customers c
  ON o.customer_id = c.customer_id

Esta es una feature muy potente para arquitecturas de data mesh.

En la DP-600 este tema es central. Aquí lo repasamos con los detalles que aparecen en DP-700.

Cómo Power BI conecta al lakehouse

A) Query directo al SQL analytics endpoint: analistas pueden conectar Power BI o Excel directamente al SQL endpoint para consultas ad-hoc. B) Crear un semantic model: modelo con relaciones, medidas y business logic. Desde septiembre 2025 hay que crearlo manualmente (ya no es automático).

Direct Lake (modo por defecto)

Direct Lake es un modo revolucionario donde Power BI lee directamente los ficheros Parquet de Delta sin importar ni copiar datos. Ventajas: rendimiento de Import mode (in-memory), sin necesidad de refresh (los datos siempre reflejan el estado del lakehouse) y sin duplicación de storage. Requiere: capacidad Fabric (F SKUs) o Premium (P SKUs).

🎯 Direct Lake on SQL vs Direct Lake on OneLake

Direct Lake on SQL endpoints: va a través del SQL analytics endpoint, puede hacer fallback a DirectQuery si se dan ciertas condiciones, es el modo tradicional / más común.

Direct Lake on OneLake: va directamente a los ficheros Delta en OneLake, NO soporta fallback a DirectQuery. Si algo falla → error (report visuals fail to render). Es el modo recomendado para modelos nuevos.

🎯 DirectQuery Fallback (Direct Lake on SQL)

Qué es: cuando Direct Lake no puede satisfacer la query, cae automáticamente a DirectQuery, que va al SQL endpoint. La query funciona, pero más lento.

Escenarios que provocan fallback (te lo pueden preguntar):

1. La tabla tiene RLS a nivel SQL en el SQL endpoint.
2. La tabla tiene Dynamic Data Masking (DDM) en el SQL endpoint.
3. La tabla tiene OLS a nivel SQL en el SQL endpoint.
4. La tabla se basa en una SQL view no materializada.
5. La tabla excede los guardrails de la capacity (número de parquet files, row groups, filas).
6. No has hecho refresh (framing) después de modificar la tabla Delta subyacente.

🎯 Controlar el fallback: DirectLakeBehavior

Se configura en el modelo (Properties del semantic model) o programáticamente con TOM/TMSL.

Diagnosticar fallback

EVALUATE TABLETRAITS()

La columna [DirectLakeFallbackInfo] muestra el motivo. None = está usando Direct Lake.

Cómo evitar fallback

• Ejecutar OPTIMIZE y VACUUM regularmente en las Delta tables (para no exceder guardrails).
• Materializar vistas como Delta tables en vez de dejarlas como SQL views.
• Mover RLS/OLS al semantic model en lugar de al SQL endpoint.
• Refresh (framing) del semantic model después de cambios.
• Escalar la capacity si los datos exceden guardrails del SKU actual.

Este apartado toca el Dominio 1 del examen. Lo profundizaremos en la Fase 4, aquí introducimos.

Niveles de acceso

A) Workspace roles (colaboradores): como vimos en el Módulo 1, Admin, Member, Contributor, Viewer. Aplican a todo el workspace. B) Item-level sharing: si quieres dar acceso solo a un lakehouse sin darle acceso a todo el workspace. Ideal para analistas o report developers.

Permisos del SQL analytics endpoint

Sobre el SQL endpoint puedes aplicar:

• 🎯 Row-Level Security (RLS): filtrar filas por usuario.
• 🎯 Column-Level Security (CLS): ocultar columnas por usuario.
• 🎯 Object-Level Security (OLS): ocultar tablas o vistas.
• 🎯 Dynamic Data Masking (DDM): mostrar datos enmascarados a usuarios sin permiso.

Schema-level permissions

Si tu lakehouse tiene schemas habilitados, puedes dar permisos por schema, no solo por tabla. Útil para separar acceso por dominio de negocio.

Sensitivity labels

Puedes aplicar Microsoft Purview sensitivity labels al lakehouse. Los labels se propagan a los items downstream (semantic models, reports basados en el lakehouse).

Integración con Purview

Fabric se puede extender con Microsoft Purview para: data lineage (rastreo de origen a consumo), data catalog, data classification y compliance policies.

Este apartado es nuevo respecto a DP-600. Del módulo oficial:

Datos bien estructurados = base para AI

La documentación explica que la calidad de tus tablas del lakehouse impacta directamente en la calidad de las capacidades AI de Fabric. Cuando creas tablas con schemas claros, nombres consistentes, columnas descriptivas y documentación, las haces accesibles tanto para analistas humanos como para Fabric IQ data agents y Copilot.

Fabric IQ Data Agents

Los data agents de Fabric IQ pueden consultar tus tablas del lakehouse a través del SQL analytics endpoint, traduciendo preguntas en lenguaje natural a queries SQL. La calidad de las respuestas depende directamente de cómo estructures y documentes tus datos.

Copilot en Power BI

Cuando el semantic model está bien construido sobre tablas de lakehouse con relaciones claras y medidas de negocio, Copilot puede generar visualizaciones y responder preguntas razonando sobre tus datos.

• Trampa 1: "Al crear un lakehouse se crean 3 items" → ❌ Desde septiembre 2025 solo se crean 2: el lakehouse y el SQL analytics endpoint. El default semantic model ya no es automático.
• Trampa 2: "Ficheros Parquet o CSV en Tables se ven como tabla" → ❌ NO. Solo Delta tables aparecen automáticamente. Parquet/CSV en Tables no se registran; hay que convertirlos a Delta primero (o hacer Load to Table).
• Trampa 3: "Puedo modificar datos desde el SQL analytics endpoint" → ❌ NO. Es read-only sobre las tablas Delta. Para escribir: Spark.
• Trampa 4: "Los cambios del lakehouse aparecen instantáneamente en el SQL endpoint" → ❌ Hay metadata sync que puede tardar de segundos a varios minutos. Si necesitas datos ya, hay que forzar refresh.
• Trampa 5: "External tables son la forma recomendada de acceder a datos externos" → ❌ La recomendación oficial es shortcuts.
• Trampa 6: "Direct Lake siempre funciona" → ❌ Puede hacer fallback a DirectQuery (RLS, DDM, OLS, views, guardrails excedidos, framing pendiente).
• Trampa 7: "V-Order hay que activarlo manualmente" → ❌ Está activado por defecto en Fabric.
• Trampa 8: "VACUUM se puede bajar por debajo de 7 días" → ⚠️ Se puede pero no debes, porque rompe el time travel y puede corromper lecturas concurrentes.
• Trampa 9: "Un shortcut a datos no-Delta en Tables aparece como tabla SQL" → ❌ Solo aparecen como tabla los shortcuts que apuntan a datos Delta.
• Trampa 10: "Puedo compartir un schema-enabled lakehouse directamente" → ❌ Actualmente NO vía workspace sharing. Workaround: usar shortcuts.
• Trampa 11: "El default semantic model existe y se puede seguir creando" → ❌ Ya no se crean automáticamente desde sept 2025; los existentes fueron decoupled en nov 2025 como items independientes.

Lakehouse vs Warehouse

Managed vs External tables

Tables vs Files

Direct Lake on SQL vs on OneLake

Métodos de ingesta