Durante años, el stack de datos de Microsoft fue un rompecabezas. Azure Data Factory para ingesta. Azure Synapse para procesamiento. Azure Data Lake Storage para almacenamiento. Power BI para visualización. Cada pieza funcionaba, pero integrarlas requería trabajo de infraestructura real, gestión de identidades cruzadas, y pipelines frágiles que conectaban servicios que no fueron diseñados para hablar entre sí.
Microsoft Fabric es la respuesta a ese problema. No es una herramienta más — es una plataforma SaaS que unifica todas esas piezas bajo una sola superficie, un solo modelo de seguridad, y lo más importante: un solo sistema de almacenamiento.
OneLake: un lago para gobernarlos a todos
OneLake es el fundamento de Fabric. Es una capa de almacenamiento unificada — un único Data Lake lógico para toda la organización — que vive automáticamente en cada tenant de Fabric sin que tengas que provisionar nada.
La diferencia con ADLS Gen2 — el Data Lake tradicional de Azure — es filosófica. En ADLS, vos creabas cuentas de storage, contenedores, y cada equipo o servicio tenía los suyos. La fragmentación era inevitable. OneLake es uno solo, organizado en workspaces e ítems, con una jerarquía clara:
OneLake
└── Tenant (tu organización)
└── Workspace (área de trabajo / dominio)
├── Lakehouse
│ ├── Tables/ ← datos en formato Delta
│ └── Files/ ← datos crudos, cualquier formato
├── Warehouse
└── Dataset (Power BI)Todo lo que guardás en Fabric — tablas de un Lakehouse, datos de un Warehouse, resultados de un notebook — vive en OneLake. No hay movimiento de datos entre servicios porque todos comparten el mismo storage. Eso elimina una clase entera de problemas: sincronización, latencia entre capas, costos de egress.
Delta Lake: el formato que sostiene todo
OneLake almacena las tablas en formato Delta Lake — el estándar open source creado por Databricks que combina archivos Parquet con un transaction log. Esa decisión tiene implicancias profundas.
Un directorio Delta se ve así en OneLake:
orders/
├── _delta_log/
│ ├── 00000000000000000000.json ← creación de la tabla
│ ├── 00000000000000000001.json ← primer INSERT
│ ├── 00000000000000000002.json ← UPDATE de precio
│ └── 00000000000000000010.checkpoint.parquet
├── part-00000-abc123.snappy.parquet
├── part-00001-def456.snappy.parquet
└── part-00002-ghi789.snappy.parquetEl _delta_log es la clave. Cada operación queda registrada como una entrada JSON. Eso habilita cuatro capacidades que no existen en Parquet puro:
Transacciones ACID: si un job falla a mitad de un write, los datos quedan consistentes. No hay archivos a medias ni estados corruptos.
Time Travel: podés consultar el estado de una tabla en cualquier versión anterior o timestamp.
# En un notebook de Fabric (PySpark)
df = spark.read.format("delta") \
.option("versionAsOf", 5) \
.load("abfss://workspace@onelake.dfs.fabric.microsoft.com/lakehouse.Lakehouse/Tables/orders")
# O por timestamp
df = spark.read.format("delta") \
.option("timestampAsOf", "2026-06-01") \
.load("abfss://...")Schema enforcement: si intentás escribir una columna con tipo incorrecto, el write falla antes de tocar los datos. El schema es un contrato, no una sugerencia.
Operaciones MERGE/UPSERT: actualizás registros existentes e insertás los nuevos en una sola operación atómica.
from delta.tables import DeltaTable
target = DeltaTable.forPath(spark, "abfss://.../Tables/orders")
target.alias("target").merge(
source=updates_df.alias("source"),
condition="target.order_id = source.order_id"
).whenMatchedUpdateAll() \
.whenNotMatchedInsertAll() \
.execute()Lakehouse: donde viven los datos crudos y transformados
El Lakehouse de Fabric es un ítem que combina la flexibilidad de un Data Lake con la capacidad de consultar datos estructurados con SQL. Tiene dos zonas:
Files/: zona cruda. Cualquier formato — CSV, JSON, Parquet, imágenes, PDFs. Es tu zona de landing para datos sin procesar.
Tables/: zona curada. Exclusivamente formato Delta. Cada tabla acá queda automáticamente disponible en el SQL Endpoint del Lakehouse — podés consultarla con T-SQL sin configurar nada.
Un flujo típico en el Lakehouse sigue el patrón medallón:
# Bronze: datos crudos tal como llegan
df_raw = spark.read.json("Files/raw/sales_2026_06_07.json")
df_raw.write.format("delta").mode("append").save("Tables/bronze_sales")
# Silver: limpios, tipados, deduplicados
df_silver = df_raw \
.dropDuplicates(["order_id"]) \
.withColumn("amount", col("amount").cast("double")) \
.filter(col("status") != "CANCELLED")
df_silver.write.format("delta").mode("overwrite").save("Tables/silver_sales")
# Gold: agregados listos para consumo
df_gold = df_silver \
.groupBy("region", "product_id") \
.agg(sum("amount").alias("total_revenue"), count("*").alias("order_count"))
df_gold.write.format("delta").mode("overwrite").save("Tables/gold_revenue_by_region")Data Warehouse: SQL empresarial sin infraestructura
El Data Warehouse de Fabric es un motor SQL distribuido, compatible con T-SQL, que también almacena sus datos en OneLake en formato Delta. La diferencia con el SQL Endpoint del Lakehouse es importante:
SQL Endpoint del Lakehouse: es de solo lectura. Refleja automáticamente las tablas Delta del Lakehouse. No podés crear tablas propias, vistas, stored procedures, ni hacer writes desde T-SQL.
Data Warehouse: lectura y escritura completa. Podés crear tablas, vistas, stored procedures, funciones, y ejecutar INSERT/UPDATE/DELETE en T-SQL nativo. Es la opción para equipos SQL-first que no quieren saber de Spark.
-- Crear tabla en el Warehouse
CREATE TABLE dbo.fact_sales (
sale_id BIGINT NOT NULL,
order_date DATE NOT NULL,
customer_id INT NOT NULL,
product_id INT NOT NULL,
quantity INT NOT NULL,
unit_price DECIMAL(10,2) NOT NULL,
total_amount DECIMAL(10,2) NOT NULL
);
-- CTAS desde una vista cruzada con el Lakehouse
CREATE TABLE dbo.dim_product AS
SELECT DISTINCT
product_id,
product_name,
category,
subcategory
FROM lakehouse.dbo.silver_products; -- cross-database query
-- Consulta analítica
SELECT
dp.category,
DATETRUNC(month, fs.order_date) AS month,
SUM(fs.total_amount) AS revenue,
COUNT(DISTINCT fs.customer_id) AS unique_customers,
AVG(fs.total_amount) AS avg_ticket
FROM dbo.fact_sales fs
JOIN dbo.dim_product dp ON fs.product_id = dp.product_id
GROUP BY dp.category, DATETRUNC(month, fs.order_date)
ORDER BY month DESC, revenue DESC;Lakehouse vs Data Warehouse: cuándo usar cada uno
La pregunta que más confunde a quienes empiezan con Fabric. La respuesta depende de quién consume los datos y cómo:
Usá el Lakehouse cuando tenés un equipo de ingeniería de datos que trabaja con Python o Spark, cuando los datos llegan en múltiples formatos, cuando necesitás procesar volúmenes masivos con transformaciones complejas, o cuando hacés ML sobre los mismos datos.
Usá el Data Warehouse cuando tu equipo es SQL-first (analistas, BI developers), cuando necesitás stored procedures y lógica de negocio encapsulada en T-SQL, o cuando migrás desde un DWH on-premise y querés el menor cambio posible.
La buena noticia: no es una decisión excluyente. Podés tener un Lakehouse para ingesta y transformación, y un Warehouse que lo consume con cross-database queries, todo sobre el mismo OneLake.
OneLake Shortcuts: datos sin moverlos
Los Shortcuts son probablemente la feature más subestimada de Fabric. Permiten crear referencias virtuales a datos que viven fuera de OneLake — ADLS Gen2, Amazon S3, Google Cloud Storage — sin copiarlos. Para Fabric, el shortcut aparece como si fuera una carpeta local.
El caso de uso más poderoso: si tenés datos históricos en S3 que no querés migrar, creás un shortcut y los consultás desde Fabric como si estuvieran en OneLake. Sin ETL, sin duplicación, sin costo de storage adicional.
# Desde un notebook, el shortcut a S3 se ve como cualquier path de OneLake
df = spark.read.format("delta").load(
"abfss://workspace@onelake.dfs.fabric.microsoft.com/"
"lakehouse.Lakehouse/Files/shortcut_s3_historical"
)
# También podés crear shortcuts hacia otro Lakehouse dentro del mismo tenant
# — ideal para compartir datos entre equipos sin duplicarlosLas otras experiencias de Fabric
Fabric no es solo Lakehouse y Warehouse. La plataforma cubre todo el ciclo de vida del dato:
Data Factory: pipelines de ingesta con más de 150 conectores. Similar a Azure Data Factory pero integrado nativamente. Tiene Dataflows Gen2 para transformaciones low-code con Power Query.
Real-Time Intelligence: procesamiento de eventos en tiempo real con Eventstream (ingesta) y KQL Database (análisis de series temporales con Kusto Query Language). El equivalente de Azure Event Hubs + Azure Data Explorer, pero dentro de Fabric.
// KQL — consulta sobre eventos de los últimos 15 minutos
Orders
| where ingestion_time() > ago(15m)
| where status == "FAILED"
| summarize error_count = count() by bin(ingestion_time(), 1m), region
| order by ingestion_time() descData Science: notebooks Python/R con acceso directo al Lakehouse, integración con MLflow para tracking de experimentos, y AutoML. Los modelos entrenados se pueden guardar como ítems de Fabric y versionar.
Power BI: nativo en Fabric, con Direct Lake mode — una modalidad que lee directamente los archivos Delta de OneLake sin importar datos al modelo semántico. Es hasta 10x más rápido que DirectQuery en datasets grandes.
Fabric vs Databricks vs Snowflake
La comparación honesta:
Databricks sigue siendo superior para casos de ML avanzado, procesamiento Spark a muy gran escala, y equipos de data engineering con alto nivel técnico. Su ecosistema open source (Delta Lake, MLflow, Unity Catalog) es más maduro. Fabric usa Delta Lake pero con un subconjunto de sus capacidades.
Snowflake tiene ventaja en gobernanza de datos multicloud, compartir datos entre organizaciones (Data Sharing), y para equipos SQL puros. Su separación de compute y storage es más granular que Fabric.
Fabric gana cuando la organización ya está en el ecosistema Microsoft — Azure, Microsoft 365, Power BI, Teams. La integración es nativa, la curva de adopción es baja para equipos que ya usan Power BI, y el modelo de licenciamiento por capacidad (F-SKUs) puede ser más predecible que el pay-per-query de Snowflake o el DBU de Databricks.
El modelo de capacidad: cómo se paga
Fabric usa un modelo de capacidades (F-SKUs) — comprás compute en bloques de CUs (Capacity Units) y todos los workloads del tenant comparten ese pool. F2 es el mínimo (desarrollo), F64 es el rango enterprise. El storage en OneLake se factura aparte, por GB.
Lo importante: cuando la capacidad está pausada, el storage sigue disponible y los datos no se pierden. Podés pausar en horarios de baja actividad y reactivar en minutos — algo que no existe de forma tan directa en Snowflake o Databricks sin configuración adicional.
Conclusión
Microsoft Fabric es la apuesta más ambiciosa que Microsoft hizo en el espacio de datos en años. La idea de unificar ingesta, transformación, almacenamiento, análisis en tiempo real, ML y BI sobre un solo lake con un solo modelo de seguridad es conceptualmente correcta.
La plataforma tiene roughness en algunos bordes — ciertas features de Delta Lake no están implementadas, el motor Spark es menos configurable que en Databricks, y la madurez de algunas experiencias varía. Pero el ritmo de desarrollo es agresivo y la propuesta de valor para organizaciones Microsoft-first es clara.
OneLake como concepto — un solo lago, múltiples motores, cero movimiento de datos — es la dirección correcta para la industria. Fabric llegó primero a implementarlo de forma integrada.