azure Mac & Windows

Fabric — tu primer pipeline de datos: de una API pública a una tabla consultable

datablog azure

Actualizado: 2026-05-25

1. Qué es un Workspace

Un workspace (área de trabajo) es el contenedor principal de Fabric. Todo lo que creas en Fabric vive dentro de un workspace: lakehouses, notebooks, warehouses, pipelines, reportes.

Fabric tenant
└── Workspace: aprendizaje-fabric
    ├── Lakehouse: mi_primer_lakehouse
    ├── Notebook: transformaciones.ipynb
    ├── Warehouse: analytics_db
    └── Reporte Power BI: dashboard_ventas

Un mismo tenant puede tener múltiples workspaces — uno por proyecto, entorno o equipo.

Tipos de workspace

El tipo de workspace determina qué puedes crear dentro y qué capacidad lo respalda:

Tipo	Capacidad	Soporta
Power BI Pro	Shared de Microsoft	Solo elementos de Power BI
Prueba de Fabric	Trial capacity (60 días)	Todos los workloads de Fabric
Fabric	Capacity F-SKU (pago)	Todos los workloads de Fabric
Power BI Premium	Capacity P-SKU (retirado)	Power BI + algunas capacidades avanzadas

Para crear un workspace de Prueba de Fabric o Fabric, la Fabric capacity debe estar activa en el tenant — sin ella, esos tipos aparecen deshabilitados en el formulario de creación.

Qué hay dentro de un workspace vacío

Al crear un workspace, la interfaz muestra: - Nuevo elemento — crea cualquier tipo de elemento (Lakehouse, Notebook, Pipeline, etc.) - Flujos de tareas prediseñados — guías paso a paso para escenarios específicos (ver: fabric-flujos-de-tareas-prediseñados) - Importar / Migrar — para traer elementos desde fuera de Fabric

Dentro de un workspace puedes crear muchos tipos de elementos: notebooks, pipelines, warehouses, reportes. Pero si quieres ir más allá de consumir dashboards y entender cómo se construyen los datos que hay detrás, el primer elemento que necesitas conocer es el Lakehouse. Es el corazón de cualquier proyecto de datos en Fabric: donde los datos llegan, se transforman y quedan disponibles para que todo lo demás los consuma. Los notebooks los procesan, los pipelines los cargan, los reportes los visualizan. Todo orbita alrededor del Lakehouse.

2. Qué es un Lakehouse

Un Lakehouse es el elemento central de Data Engineering en Fabric. Combina lo mejor de un data lake (almacenamiento flexible de archivos) con lo mejor de un data warehouse (tablas consultables con SQL).

Las dos vistas

Al abrir un Lakehouse se muestran dos secciones en la barra lateral:

Files → almacenamiento libre de archivos. Acepta cualquier formato: CSV, JSON, Parquet, imágenes, etc. Es el lado "lago de datos" — sin estructura impuesta.
Tables → tablas Delta consultables con SQL. Es el lado "warehouse" — datos estructurados, con esquema definido.

El mismo dato puede llegar como archivo crudo a Files y luego procesarse para convertirse en una tabla en Tables.

Los tres puntos de conexión

Un Lakehouse no es solo una interfaz visual — expone tres formas de conectarse a sus datos desde otros workloads:

Punto de conexión	Para qué sirve	Workload
Notebook	Procesar datos con Python/Spark	Data Engineering
Punto de conexión de análisis SQL	Consultar tablas con SQL (lectura)	Data Warehouse
Punto de conexión del centro de eventos	Conectar con datos en streaming	Real-Time Intelligence

Esto es OneLake en acción: el mismo dato físico, accesible desde tres workloads distintos sin moverlo ni copiarlo.

Qué cubre la capacidad — modelo de costos

La capacidad (F-SKU) no es solo para Gen2 ni para Spark. Es un pool compartido que todos los workloads de Fabric consumen:

Workload	Qué incluye
Data Engineering	Notebooks Spark, Spark Job Definitions, Lakehouses
Data Factory	Dataflow Gen2, Pipelines, Copy Activity
Data Warehouse	Warehouse, SQL Analytics Endpoint
Data Science	Notebooks ML, Experimentos, Modelos
Real-Time Intelligence	Eventstream, Eventhouse, KQL Database
Power BI	Reportes, Dashboards, Modelos Semánticos
Databases	SQL Database

Pagas la capacidad encendida por tiempo — no por query ni por volumen procesado. Cinco queries de 100M filas cuestan lo mismo que cinco queries de 100 filas si las corres en el mismo rango de tiempo. Es predecible pero requiere disciplina: dejar la capacidad encendida sin usar consume igual.

Comparación con BigQuery:

	Fabric (F-SKU)	BigQuery
Modelo	Pago por tiempo encendido	Pago por datos escaneados
Predecibilidad	Alta — precio fijo	Variable — depende del volumen
Riesgo	Capacidad ociosa encendida	Query mal escrita que escanea TBs
Ideal para	Workloads constantes y predecibles	Workloads esporádicos o impredecibles

Cómo elegir el SKU correcto — el criterio es paralelismo y tiempo:

El tamaño del dataset no determina el SKU. Lo determina cuántos trabajos necesitas correr al mismo tiempo y en qué ventana de tiempo.

Situación	SKU recomendado
100 Dataflows grandes pero con tiempo suficiente	F2 con scheduling por turnos
100 Dataflows que deben terminar antes de las 8am	F16 o F32 para correrlos en paralelo
Workloads esporádicos, uso puntual	F2 o F4, pausar cuando no se usa

Con una F2 y scheduling bien organizado, los trabajos corren en cola uno por uno. Cuesta mucho menos pero requiere planificar los turnos manualmente. Es la estrategia de equipos pequeños con presupuesto ajustado.

Cómo se configura el scheduler:

Desde el workspace, en los tres puntos del Dataflow Gen2 → Programar actualización. Se define frecuencia (horaria, diaria, semanal), hora exacta y zona horaria — idéntico al scheduler de Power BI Service.

La diferencia clave con Power BI Pro:

Power BI Pro:
Fuente → [scheduler] → Modelo Power BI → Reporte

Fabric:
API/DB → [scheduler] → Lakehouse (tabla Delta) → Modelo semántico → Reporte
                                                 → Notebook
                                                 → Warehouse
                                                 → Otro Dataflow

En Power BI Pro el scheduler actualiza el modelo del reporte. En Fabric actualiza la tabla en el Lakehouse — la fuente misma. Todo lo que consume esa tabla recibe los datos frescos automáticamente, sin configurar nada más en cada reporte.

El Lakehouse en perspectiva — equivalencias con GCP y AWS

Si vienes de otros clouds, el Lakehouse colapsa dos servicios en uno:

GCP	AWS	Fabric
Cloud Storage	S3	OneLake (archivos Parquet)
BigQuery	Athena	SQL Analytics Endpoint
Cloud Storage + BigQuery	S3 + Athena	Lakehouse

El storage (archivos Parquet) y el motor SQL viven juntos, sin configurar permisos entre servicios ni pagar transferencia de datos entre ellos.

La diferencia filosófica con BigQuery: BigQuery es serverless puro — no ves los archivos debajo. En Fabric el Lakehouse te hace consciente de que hay Parquet físico en OneLake. Más transparente, más control, más complejidad.

Acciones disponibles dentro del Lakehouse

Desde la barra de herramientas del Lakehouse:

Obtener datos — importar datos desde fuentes externas (CSV, base de datos, API, etc.)
Nuevo modelo semántico — crear una capa semántica sobre las tablas para usar en Power BI
Abrir cuaderno — abrir un Notebook Spark ya conectado a este Lakehouse
Agregar al agente de datos — exponer los datos del Lakehouse a un agente de IA
Administrar la seguridad de OneLake — controlar permisos de acceso al nivel de OneLake

3. Pipeline opción A — Notebook (requiere F8 o superior)

El camino más directo para cargar datos de una API al Lakehouse es un Notebook de Spark. El código es Python estándar: llamas la API, conviertes la respuesta a un DataFrame y lo escribes como tabla Delta con una línea.

Nota: Este código no se pudo ejecutar en el trial FTL4 (equivalente a F4, 8 VCores). Spark necesita mínimo 2 nodos Medium (16 VCores) para arrancar una sesión. Con F8 o superior funciona sin modificaciones.

# NOTA: Este código requiere F8 o superior (mínimo 16 VCores).
# Con el trial FTL4 (F4, 8 VCores) falla al arrancar la sesión Spark
# antes de ejecutar cualquier línea — error 430 TooManyRequestsForCapacity.

import requests
import pandas as pd

username = "torvalds"
url = f"https://api.github.com/users/{username}/repos"

response = requests.get(url)
repos = response.json()

columnas = ["id", "name", "description", "language",
            "stargazers_count", "forks_count",
            "created_at", "updated_at"]

df = pd.DataFrame(repos)[columnas]
print(f"Repositorios encontrados: {len(df)}")

# spark está disponible como global en cualquier Notebook de Fabric
# saveAsTable escribe la tabla en el Lakehouse conectado (visible en Tables)
df_spark = spark.createDataFrame(df)
df_spark.write.mode("overwrite").saveAsTable("repos_github")

4. Pipeline opción B — Dataflow Gen2 (funciona con trial F4)

Dataflow Gen2 es la alternativa sin Spark. Usa Power Query como motor — el mismo que hay detrás de Excel y Power BI — y tiene su propio compute independiente de la capacidad Spark.

4.1 Crear el Dataflow Gen2

Desde el workspace, hacer clic en Nuevo elemento → Flujo de datos Gen2. Nombrar la consulta de forma descriptiva — el nombre que le des a la consulta será el nombre de la tabla en el Lakehouse.

En este caso: repo_github_torvalds

4.2 Conectar a la API de GitHub

Al abrir el editor, seleccionar Obtener datos → Web API y pegar la URL:

https://api.github.com/users/torvalds/repos

Credenciales: Anónimo. La API pública de GitHub no requiere autenticación para leer repos públicos.

Dataflow carga la respuesta y muestra una tabla con 11 filas — una por repositorio — y decenas de columnas (todos los campos que devuelve la API).

4.3 Limpiar las columnas

Seleccionar solo las columnas relevantes y aplicar Quitar otras columnas:

id
name
description
language
stargazers_count
forks_count
created_at
updated_at

4.4 Configurar el destino

En el panel inferior, hacer clic en Agregar destino de datos → Lakehouse y seleccionar aprendizaje-fabric → mi_primer_lakehouse.

Modo de actualización: Reemplazar — cada vez que el Dataflow corre, sobreescribe la tabla completa.

4.5 Publicar y ejecutar

Hacer clic en Guardar y ejecutar. En segundos el Dataflow procesa la respuesta y escribe la tabla en el Lakehouse.

4.6 Verificar la tabla

Al volver al Lakehouse, la tabla repo_github_torvalds aparece bajo Tables. Desde el Punto de conexión de análisis SQL, se puede consultar directamente:

SELECT name, language, stargazers_count, forks_count
FROM repo_github_torvalds
ORDER BY stargazers_count DESC;

Resultado: 11 repos de Linus Torvalds ordenados por stars. linux encabeza la lista con 234,348 stars — el kernel del sistema operativo más usado del mundo.

Gotchas

El trial no siempre es F64 — el SKU FTL4 equivale a F4: solo 4 CUs y 8 Spark VCores. Un Notebook al arrancar consume prácticamente toda esa capacidad, causando error 430 (TooManyRequestsForCapacity) de forma casi garantizada. Verificar el tamaño real en Portal de administración → capacidad antes de asumir que se tiene F64.
El trial no tiene cola ni burst — cuando la capacidad Spark está ocupada, los jobs se rechazan directamente. En F64 de pago hay burst hasta 384 VCores y cola automática. En el trial no hay ninguno de los dos.
Fabric es un producto enterprise, no un producto para aprender — un F4 (~$527/mes) ya es limitado para aprender; un F64 cuesta ~$5,000/mes en reserva. El trial es una demo del producto, no una capa gratuita optimizada para developers individuales. BigQuery free tier está pensado para ese caso de uso; Fabric trial no.
Cualquier Notebook requiere inicializar un cluster Spark — incluso print("hola") consume VCores desde el arranque porque Fabric levanta un cluster distribuido antes de ejecutar cualquier código. No hay modo "Python ligero" en notebooks conectados al Lakehouse.
El throttling se recupera solo — si el trial queda throttled por intentos fallidos, dejarlo quieto 15-20 minutos sin abrir el Notebook suele liberar la capacidad.

Pendientes

[ ] Probar el pipeline completo (Notebook → GitHub API → tabla Delta) con capacidad F8 o F16 al terminar el trial de 60 días. Con F4 los VCores no alcanzan para arrancar un Notebook con la configuración por defecto.