Si vienes del mundo “clásico” de datos, probablemente estás acostumbrado a ver almacenamiento y cómputo como un paquete: cada motor con su propio repositorio, su propio formato y, en la práctica, sus propios silos. Microsoft Fabric propone un giro fuerte: separar el almacenamiento del cómputo y estandarizar el formato de los datos para que múltiples motores trabajen sobre la misma “verdad” sin duplicar.

El resultado es una base analítica unificada donde OneLake pone el “suelo”, Delta Parquet define el “idioma” y Lakehouse/Warehouse aportan las “experiencias” de cómputo para distintos perfiles.

El cambio de paradigma: desacoplar almacenamiento y estandarizar el formato

La idea central es sencilla, pero poderosa:

• Un solo lago lógico (OneLake) para almacenar.
• Un formato abierto y optimizado (Delta Parquet) para leer/escribir.
• Varios motores (Spark, T-SQL, etc.) que consumen/transforman la misma copia de datos.

Esto reduce fricción: menos ETL para “pasar” datos entre plataformas, menos duplicación, menos inconsistencias y, bien diseñado, mejor gobernanza.

1) OneLake: el cimiento unificado de almacenamiento

Piensa en OneLake como el “OneDrive para los datos” dentro de Fabric: una capa lógica central donde reside todo, independientemente de qué motor lo use.

Lo que lo hace clave

• Almacenamiento centralizado: se apoya en Azure Data Lake Storage (ADLS) Gen2 y busca eliminar silos al ofrecer una ubicación única para datos de la organización.
• Separación de cómputo y almacenamiento: el almacenamiento vive en OneLake; el cómputo vive en los motores. Esto permite escalar cada cosa por separado (y diseñar mejor costos/rendimiento).
• Virtualización con Shortcuts: con shortcuts puedes “traer” datos externos (por ejemplo, en S3 o ADLS externos) sin moverlos físicamente, logrando una unificación lógica bajo el mismo paraguas.

Idea práctica: OneLake no es solo “un lugar para guardar archivos”; es el punto de encuentro para que diferentes experiencias analíticas trabajen como si compartieran el mismo disco.

2) Delta Parquet: el lenguaje común que lo hace posible

El secreto de la integración no es solo dónde se guardan los datos, sino cómo.

• Formato abierto: Lakehouse y Warehouse almacenan en OneLake usando Delta Parquet.
• Interoperabilidad real: si Spark escribe una tabla en Delta, otro motor optimizado para Delta puede leerla inmediatamente sin conversiones ni procesos de copiado.

Esto habilita un escenario muy concreto: “produzco datos con ingeniería/ciencia de datos y los consumo con SQL/BI sin duplicar”.

3) Lakehouse: flexibilidad para ingeniería y ciencia de datos

El Lakehouse mezcla lo mejor de un lago (flexibilidad) con lo mejor de un almacén (tablas gestionadas y estructuras más ordenadas).

Por qué existe

• Transformación y exploración con Spark: ideal para notebooks (Python/Scala/R), procesamiento distribuido, y manejo de datos estructurados y no estructurados.
• SQL analytics endpoint: cada Lakehouse expone automáticamente un endpoint SQL (normalmente de lectura), para que perfiles analíticos consulten con T-SQL sin tener que entrar al mundo Spark.

Traducción en equipos: ingeniería de datos y data science trabajan en su entorno natural, y a la vez habilitan consumo SQL para analistas.

4) Warehouse: estructura empresarial con SQL completo

El Warehouse en Fabric es la evolución del data warehouse tradicional, pero ya no “vive encerrado” en archivos propietarios tipo .mdf. Su base sigue estando en el lago.

Qué lo caracteriza

• Motor SQL distribuido: pensado para cargas analíticas complejas, con capacidades completas de SQL (incluyendo lectura/escritura y rendimiento empresarial).
• Datos almacenados como Delta en OneLake: el Warehouse guarda físicamente como Delta Parquet, lo que hace que otros motores de Fabric también puedan acceder a esa misma copia desde el lago.

Resultado: tienes la experiencia de un warehouse “de negocio”, sin romper la filosofía de datos abiertos en el lago.

La pieza final: Cross-Querying (consultas entre motores)

Aquí es donde Fabric se siente realmente “unificado”: consultar cruzado entre Lakehouse y Warehouse como si todo estuviera dentro del mismo universo.

¿Qué habilita?

• Un Warehouse puede hacer JOIN a tablas que viven en un Lakehouse (o incluso en otro Warehouse del mismo workspace).
• Sin movimiento de datos: no necesitas copiar, exportar, ni replicar para analizar en conjunto.
• Se refuerza la filosofía One Copy: almacenar una vez, consumir desde múltiples experiencias.

Ejemplo conceptual (T-SQL) de cómo se ve esa intención:

-- Ejemplo conceptual: unir dimensiones “curadas” (Warehouse)
-- con hechos transformados por ingeniería (Lakehouse)
SELECT
    d.CustomerName,
    f.OrderDate,
    f.SalesAmount
FROM Warehouse.dbo.DimCustomer d
JOIN Lakehouse.dbo.FactSales f
    ON d.CustomerId = f.CustomerId
WHERE f.OrderDate >= '2025-01-01';

Nota: los nombres exactos (schemas/rutas) dependen de cómo esté publicado/registrado en tu workspace, pero el punto es el mismo: consulta cruzada sobre Delta en OneLake.

¿Cuándo usar Lakehouse vs Warehouse?

No es “uno u otro”. En Fabric, el diseño ganador suele ser complementario.

Usa Lakehouse cuando…

• Necesitas Spark/notebooks para transformar grandes volúmenes.
• Trabajas con datos semi-estructurados o no estructurados.
• Estás en modo exploración, feature engineering o pipelines de ciencia de datos.

Usa Warehouse cuando…

• Necesitas una capa de consumo SQL empresarial robusta.
• Tu organización estandariza en SQL para reporting, modelos semánticos, autoservicio BI y gobierno.
• Quieres estructuras claras (dimensiones/hechos) y rendimiento consistente para analítica de negocio.

Patrón típico: Lakehouse “aterriza y transforma” → Warehouse “modela para consumo” → Power BI “expone insights”.

Buenas prácticas rápidas para que la unificación funcione de verdad

• Diseña por capas (Bronze/Silver/Gold): aunque sea en Fabric, la disciplina sigue importando.
• Gobernanza desde el inicio: permisos, dominios, nomenclatura, propietarios de datos.
• Evita duplicar por costumbre: si estás copiando para “pasar” de Lakehouse a Warehouse, revisa si tu caso se resuelve con cross-querying o una capa curada mínima.
• Documenta contratos de datos: qué significa cada métrica, cuál es la tabla “fuente de verdad”, y cómo se versiona.

Conclusión

La integración OneLake + Delta Parquet + Lakehouse/Warehouse no es un detalle técnico: es una forma diferente de pensar una plataforma analítica. OneLake centraliza el almacenamiento, Delta Parquet estandariza el formato y Lakehouse/Warehouse ofrecen experiencias distintas sobre la misma copia de datos.

Cuando lo implementas bien, pasas de “múltiples silos conectados por ETL” a un modelo donde los datos se almacenan una vez y se consumen desde varios motores con mínima fricción, reforzando el enfoque One Copy