Artefactos de Fabric
Todos los items que puedes crear en Fabric, organizados por experiencia. Qué hace cada uno, cuándo elegirlo, cómo se relaciona con los demás y cómo encaja en OneLake. Con guías de decisión incluidas. 🌸
📑 En esta página
¿Qué es un artefacto (item)?
En Fabric, un artefacto (o item, ambos términos se usan indistintamente) es cualquier cosa que puedas crear dentro de un workspace: un Lakehouse, un Warehouse, un Notebook, un Pipeline, un informe de Power BI… todos son items. Son la unidad mínima de contenido en Fabric.
Cada item tiene cuatro propiedades esenciales que conviene recordar:
- Vive en un workspace — que a su vez vive en una capacidad.
- Tiene un tipo — Lakehouse, Notebook, Semantic Model, etc. Cada tipo tiene sus propias pestañas, acciones y experiencia de edición.
- Tiene representación en OneLake — los items de datos
(Lakehouse, Warehouse, KQL DB) reservan una carpeta en el lago con el
sufijo del tipo (
MiItem.Lakehouse). - Tiene permisos propios — que se heredan del workspace por defecto, pero pueden ajustarse a nivel item o incluso a nivel tabla.
En las secciones siguientes los agrupamos por experiencia — la misma organización que verás en el selector de abajo a la izquierda del portal Fabric. Empezamos por los más fundamentales.
Data Engineering
Transformación a gran escala con Spark y Notebooks sobre Delta Lake.
Lakehouse
La unión entre un data lake y un data warehouse
Un Lakehouse es un item híbrido: combina la flexibilidad
de un data lake (archivos de cualquier tipo en Files/) con la
disciplina de un warehouse (tablas Delta en Tables/ con
esquema, estadísticas y SQL). Es el item más polivalente de Fabric y,
probablemente, por donde deberías empezar.
Dos vistas importantes acompañan siempre a un Lakehouse: el Lakehouse Explorer (UI principal donde ves Tables y Files) y un SQL analytics endpoint generado automáticamente, que expone todas las tablas Delta como si fuera un warehouse de sólo lectura consultable con T-SQL desde cualquier cliente.
Cuando creas un Lakehouse, Fabric también crea automáticamente un semantic model por defecto listo para consumir desde Power BI con Direct Lake. Una sola acción, tres items bajo el capó.
Notebook
Código interactivo con PySpark, SQL, Scala o R
El Notebook de Fabric es un entorno de celdas estilo Jupyter, ejecutándose sobre clusters Spark gestionados por Fabric. Soporta cuatro kernels: PySpark (el más habitual), Spark SQL, Scala y SparkR. Cada notebook puede montar varios lakehouses como fuentes y escribir en cualquiera de ellos.
Características que lo diferencian de un Jupyter estándar:
colaboración en tiempo real estilo Google Docs,
versionado Git integrado, ejecución programada desde un
Pipeline, parametrización con %%configure, y el %%sql
magic para escribir SQL directamente contra las tablas montadas.
También hay Data Wrangler, una UI low-code que genera código PySpark/Pandas a partir de clics para limpiar datos — perfecta para explorar antes de escribir el pipeline definitivo.
Spark Job Definition
Ejecutar un .py o .jar empaquetado como job de producción
A diferencia del Notebook (que es interactivo), un Spark Job
Definition apunta a un fichero de código — un .py,
un .jar o un .R — que vive en tu Lakehouse, y
define cómo ejecutarlo: argumentos, ficheros de referencia, main class…
Es la pieza para despliegues serios de pipelines Spark con código
externo bien versionado.
Environment
Configuración reutilizable para Spark: librerías, pool, propiedades
Un Environment encapsula la configuración de ejecución
que varios notebooks o jobs quieren compartir: versión de Spark, runtime,
pool de cómputo personalizado, librerías públicas (pip/conda) y librerías
privadas (.whl/.jar subidas por ti) y
propiedades de configuración Spark.
En lugar de configurar cada notebook a mano, los ligas a un Environment compartido y se aplican todos los ajustes automáticamente. Es imprescindible en cualquier equipo con más de 2–3 notebooks en producción.
Data Factory
Ingesta, movimiento y orquestación de datos — con dos sabores: low-code y code-first.
Data Pipeline
Orquestador visual estilo Azure Data Factory
Un Pipeline es un grafo de actividades: copiar datos de
un origen a otro, ejecutar un Notebook, lanzar un Dataflow, llamar una
REST API, mover ficheros, enviar un email, esperar a un evento… todo con
dependencias, condicionales (If), bucles (ForEach),
triggers temporales y triggers por eventos.
Si vienes de Azure Data Factory o Synapse Pipelines, los Pipelines de Fabric son prácticamente idénticos — misma UI, mismas actividades, mismos conceptos. La mayor diferencia es que aquí todo vive dentro de Fabric sin integration runtimes externos.
Actividades destacadas: Copy data (el workhorse para mover datos entre 100+ conectores), Notebook, Dataflow Gen2, Stored procedure, Office 365 outlook, Teams, Web (REST), y actividades de control de flujo.
Dataflow Gen2
Power Query como ciudadano de primera en Fabric
El Dataflow Gen2 es, en esencia, el editor de Power Query que ya conoces de Power BI Desktop, pero ejecutándose en el cloud como un item de Fabric independiente. Conectas a fuentes, aplicas transformaciones con el editor visual de Power Query (lenguaje M) y escribes el resultado a un destino: Lakehouse, Warehouse, KQL Database, Azure SQL…
La diferencia clave con los Dataflows clásicos (Gen1) es precisamente el output destination: antes el dato se quedaba encerrado en el dataflow. Ahora aterriza en un item de destino como tabla normal, lista para ser consumida por el resto de Fabric.
Dataflow Gen2 es low-code: no necesitas saber programar. Transformas con clics y Power Query genera el M por debajo.
Copy Job
Movimiento masivo de datos con carga incremental, sin Pipeline
El Copy Job es un item nuevo y sorprendentemente útil: hace una sola cosa — copiar datos de A a B — pero lo hace muy bien y con features que antes requerían construir un pipeline complejo.
Soporta full load, incremental (con watermark automático), Change Data Capture en orígenes compatibles, selección de tablas, mapeo de columnas y schedule propio. Ideal para replicar una base de datos entera al lago sin montar un Pipeline con ForEach y actividades Copy.
Mirrored Database
Réplica casi en tiempo real de una base de datos operacional
Mirroring es quizá la pieza más interesante de todo Fabric para ingeniería de datos. Conectas una base de datos operacional — Azure SQL DB, Azure Cosmos DB, Azure SQL Managed Instance, Snowflake, PostgreSQL, Databricks Unity Catalog — y Fabric mantiene una réplica continua en OneLake, en formato Delta, con latencia de segundos.
Es gratis (no consume capacity units de storage) y no requiere ETL: los datos llegan siempre frescos. A partir de ahí, los puedes consumir con Power BI Direct Lake, unirlos con otras tablas en un Notebook o consultarlos desde el SQL endpoint.
Data Warehouse
El mundo del T-SQL puro, las transacciones multi-tabla y el SQL de toda la vida.
Warehouse
Data warehouse relacional con T-SQL completo sobre Delta
Un Warehouse de Fabric es un motor relacional estilo
SQL Server/Synapse, pero con la particularidad de que sus datos se
almacenan como tablas Delta en OneLake. Es read-write
en T-SQL completo: CREATE TABLE, INSERT,
UPDATE, DELETE, MERGE,
transacciones multi-sentencia, stored procedures, vistas, funciones…
A diferencia del SQL endpoint de un Lakehouse (que es sólo lectura), aquí puedes escribir con SQL y el motor se encarga de materializar los cambios en Delta manteniendo consistencia ACID.
Bajo el capó, el motor es MPP (Massively Parallel Processing) distribuido,
con optimización automática, sin tunning manual de distribuciones (adiós
a las viejas HASH/ROUND_ROBIN de Synapse
Dedicated).
SQL Analytics Endpoint
Vista T-SQL de sólo lectura, autogenerada sobre un Lakehouse
El SQL analytics endpoint no se crea a mano — aparece automáticamente en cada Lakehouse y expone sus tablas Delta como si fueran tablas de un warehouse. Puedes consultarlas con T-SQL desde SSMS, Azure Data Studio, o cualquier cliente TDS. Es read-only: para escribir, usas el Notebook que alimenta el Lakehouse.
Es la forma más sencilla de exponer tu Lakehouse al mundo SQL sin esfuerzo adicional. Perfecto para analistas que quieren consultar con SELECT pero no quieren aprender PySpark.
Data Science
Machine learning end-to-end con MLflow, modelos registrados y experimentos.
ML Model
Modelo registrado con versiones y metadata, listo para inferencia
Un ML Model es un modelo entrenado registrado en el model registry de MLflow, integrado directamente en Fabric. Cada vez que entrenas y loggeas un modelo con MLflow desde un Notebook, aparece como una nueva versión del item. Fabric guarda automáticamente artefactos, métricas, firma de entrada/salida y dependencias.
Desde el item puedes aplicar el modelo a nuevos datos (inferencia batch)
con PREDICT, una función de Fabric que carga el modelo y lo
aplica sobre una tabla del lake sin escribir código PySpark a mano.
Experiment
Conjunto de runs de entrenamiento para comparar y trackear
Un Experiment agrupa runs — cada intento de entrenamiento con sus hiperparámetros, sus métricas y su artefacto. La UI permite comparar runs en tabla o en gráficos, ver cuál tuvo mejor F1, mejor MAE, etc., y promover el ganador a ML Model registrado.
Es el contenedor natural para fases de exploración en ciencia de datos, donde pruebas 20 configuraciones antes de elegir la buena.
Real-Time Intelligence
Streaming, series temporales y respuestas a eventos con latencia de segundos.
Eventstream
Pipeline low-code para flujos de eventos en tiempo real
Un Eventstream es un editor visual donde conectas orígenes de eventos (Azure Event Hubs, Kafka, IoT Hub, CDC de bases de datos, sample data, custom app), aplicas transformaciones en tiempo real (filtros, agregaciones por ventana, joins con tablas de referencia) y escribes a destinos: KQL Database, Lakehouse, Reflex/Activator, Custom Endpoint…
Es el sustituto low-code de Azure Stream Analytics dentro de Fabric. Arrastras nodos, los conectas, le das a "Publish" y el stream empieza a fluir. No hay que escribir SQL de streaming a mano.
KQL Database / Eventhouse
Base de datos para series temporales, logs y telemetría
Una KQL Database es el motor Azure Data Explorer (ADX/Kusto) integrado en Fabric. Especializada en datos de series temporales, logs, telemetría e eventos: ingestas miles de eventos por segundo y consultas con KQL (Kusto Query Language), un lenguaje potente y muy distinto a SQL.
Un Eventhouse es un contenedor de una o varias KQL Databases que comparten cómputo. La distinción es de empaquetado: a efectos prácticos, piensa en KQL Database como "la base de datos" y en Eventhouse como "el servidor".
Ventaja importante: los datos de KQL Database se sincronizan automáticamente con OneLake en formato Delta (OneLake availability), así que los puedes consumir también desde Spark, Warehouse o Power BI Direct Lake sin tocar nada.
KQL Queryset
Colección de queries KQL guardadas y compartidas
Un Queryset es el equivalente a un fichero
.kql: una hoja con consultas Kusto que puedes guardar,
compartir con el equipo y ejecutar contra una o varias KQL Databases.
Similar a una "hoja de SSMS" pero en web y versionable.
Real-Time Dashboard
Dashboards con latencia de segundos, nativos sobre KQL
Un Real-Time Dashboard es como un informe de Power BI pero nativo de la experiencia Real-Time: cada tile es una query KQL y se refresca automáticamente en ventanas cortas (segundos). Está diseñado para escenarios operativos: salas NOC/SOC, monitorización de producción, seguimiento de logística en vivo.
No reemplaza a Power BI para análisis tradicional — es complementario. Piensa en él para cuando la latencia importa más que la pulcritud visual.
Activator (Reflex)
Reglas que disparan acciones cuando los datos cumplen una condición
Activator (antes "Reflex") es la pieza que cierra el círculo de los datos en tiempo real: define reglas tipo "cuando esta métrica supere X durante Y minutos, haz Z", y Activator dispara la acción — enviar un email, un mensaje de Teams, llamar a un webhook, lanzar un Power Automate flow…
Funciona sobre varios orígenes: Eventstream, KQL Database, incluso métricas de visuales Power BI. Es el puente entre "tengo datos" y "alguien debería enterarse".
Power BI
Los items de Power BI siguen siendo los mismos — con algunas novedades por estar dentro de Fabric.
Semantic Model
El modelo tabular con tablas, medidas DAX y relaciones — antes "dataset"
El Semantic Model (nombre actual de lo que antes llamabas "dataset") es el cerebro analítico de Power BI: tablas, relaciones, jerarquías, medidas DAX, perspectivas, seguridad (RLS/OLS) y traducciones. Un solo modelo puede alimentar muchos informes.
En Fabric puede funcionar en tres modos: Import (como siempre, VertiPaq en memoria), DirectQuery (consulta en vivo al origen) y el nuevo Direct Lake (lectura directa de tablas Delta desde OneLake, con rendimiento casi nativo de Import pero sin duplicar datos ni necesitar refresco).
Report
Informe de Power BI: páginas, visuales, interactividad
Un Report es un conjunto de páginas con visuales conectados a un Semantic Model. Exactamente lo mismo que conoces de Power BI Desktop — no cambia porque vivas en Fabric en lugar de en el servicio clásico.
Lo que sí cambia es que puedes crear un Report directamente desde el portal Fabric, sin abrir Desktop, aunque el editor web sigue siendo más limitado que el de Desktop para temas avanzados de diseño y formato condicional.
Paginated Report
Informes pixel-perfect estilo Reporting Services (RDL)
Los Paginated Reports (antes SSRS / Reporting Services) son informes orientados a impresión y exportación: layouts fijos, paginación controlada, tablas que se extienden sobre múltiples páginas, cabeceras y pies personalizados. Se diseñan con Power BI Report Builder, una app de escritorio distinta de Desktop.
Dashboard
Colección de tiles (pinned) desde varios informes
Un Dashboard es una única página donde anclas visuales desde uno o varios informes. Es una vista agregada, no interactiva de la misma forma que un informe, y su rol ha ido difuminándose con los años a favor de los informes multi-página.
¿Cuándo uso qué? — guía rápida de decisión
Con tanto item es fácil perderse. Aquí tienes un árbol de decisión rápido con las preguntas más habituales:
🤔 Decision cheat-sheet
Lakehouse vs Warehouse — el duelo eterno
Es la pregunta más frecuente sobre Fabric. Ambos almacenan en OneLake, ambos usan Delta, ambos son consultables con T-SQL… pero hay diferencias importantes que determinan cuándo elegir uno u otro.
| Característica | 🏠 Lakehouse | 🏢 Warehouse |
|---|---|---|
| Motor principal | Spark (PySpark, Scala, SQL, R) | Motor relacional MPP tipo SQL Server |
| Escritura T-SQL | ❌ El SQL endpoint es sólo lectura | ✅ T-SQL completo: INSERT/UPDATE/DELETE/MERGE |
| Transacciones multi-tabla | ❌ No soportadas (Delta es tabla a tabla) | ✅ Sí, ACID completas |
| Stored procedures | ❌ No (sí hay notebooks parametrizados) | ✅ Sí, estilo SQL Server |
| Ficheros no estructurados | ✅ Sí — área Files/ |
❌ No, sólo tablas relacionales |
| Streaming y tablas grandes (TB) | ✅ Su fuerte | 🟡 Posible pero no es lo típico |
| Skill del equipo ideal | Data engineers / PySpark | DBAs / desarrolladores SQL |
| Formato de almacenamiento | Delta Parquet en OneLake | Delta Parquet en OneLake (mismo formato) |
| Power BI Direct Lake | ✅ Sí | ✅ Sí |