Fabric — tu primer pipeline de datos: de una API pública a un reporte en Power BI

En este tutorial vas a construir tu primer pipeline de datos de punta a punta en Microsoft Fabric: partimos de una API pública de GitHub —los repositorios de una cuenta, sin autenticación— y llevamos esos datos, paso a paso, hasta un reporte en Power BI.

Importante — aquí "pipeline" es el concepto, no el item de Fabric. En este post "pipeline de datos" se refiere al recorrido que hace el dato de punta a punta (API → Flujo de datos Gen2 → Lakehouse → reporte). Fabric además tiene un elemento que se llama literalmente Data pipeline, pero ese es otra cosa: una herramienta de orquestación para encadenar y programar actividades, y no la usamos en este tutorial —el flujo lo armamos conectando las piezas directamente—. Si vienes de Azure Data Factory, es el heredero de aquellos pipelines; lo veremos en un post aparte. No lo busques en este recorrido.

El recorrido completo son cuatro pasos:

• Traer los datos desde la API de GitHub con un Flujo de datos Gen2.
• Aterrizarlos como una tabla Delta dentro de un Lakehouse.
• Modelar encima un modelo semántico (Direct Lake) — la capa que Power BI necesita para leer las tablas.
• Visualizar en un reporte de Power BI conectado a ese modelo.

Pero antes de mover un solo dato hay que entender dónde va a vivir; por eso empezamos por los dos contenedores base —el workspace y el Lakehouse— y de ahí seguimos el flujo natural del dato hasta el reporte.

Damos por sentado que ya sabes qué es una petición a una API pública. Si no, revisa primero los posts relacionados al final (introducción a las APIs y cómo extraer datos de la API de GitHub).

Y todo ese recorrido arranca siempre por el mismo punto de partida: el workspace. En Fabric no creas nada suelto —ni un Lakehouse, ni un flujo de datos, ni un reporte—; cada pieza del pipeline que vas a construir vive dentro de un workspace. Es el contenedor que lo agrupa todo, así que es justo por ahí por donde empezamos.

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.

Crear el workspace

Desde la barra lateral de Fabric → Áreas de trabajo → + Nueva área de trabajo, ponle un nombre (ej. aprendizaje-fabric) y, en las opciones avanzadas, sección Tipo de área de trabajo, elige el tipo.

Este es el paso que más importa para este tutorial: elige Prueba de Fabric (el trial gratuito de 60 días), no Power BI Pro. ¿Por qué? Porque todo lo que vas a crear —el Lakehouse y el Flujo de datos Gen2— son workloads de Fabric, y un workspace de Power BI Pro solo admite elementos de Power BI. De hecho, los "Flujos de datos" que existen en Power BI Pro son Gen1; el Gen2 que usaremos requiere capacidad Fabric (por debajo crea items de Lakehouse y Warehouse para funcionar). Si tuvieras una capacidad F-SKU de pago, el tipo Fabric también serviría.

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).

2.1 El Lakehouse vive dentro de OneLake

El Lakehouse es lo que técnicamente vas a crear en este tutorial. Pero ese Lakehouse no existe aislado: vive dentro de un mundo más grande llamado OneLake.

OneLake es el "OneDrive para datos" de Fabric. Así como tu OneDrive personal es el único lugar donde se guardan todos tus archivos, OneLake es el único lugar donde se guardan todos los datos de tu organización en Fabric. Tres características clave:

• Viene solo y es único — cada tenant de Fabric trae un OneLake automáticamente. Hay uno solo: no se crea, no se borra, no se configura.
• Todo vive ahí — lakehouses, warehouses y cualquier elemento de datos guardan su contenido físicamente en OneLake, aunque tú los manejes por separado.
• Formato abierto — por debajo es Azure Data Lake Storage (ADLS Gen2) y guarda las tablas en Delta Parquet, un estándar que cualquier herramienta puede leer.

La relación, entonces, es: OneLake es el almacén (el disco donde todo se guarda) y el Lakehouse es una vista organizada sobre una parte de ese almacén. Cuando más adelante veas tus tablas en el Lakehouse, recuerda que físicamente están en OneLake.

2.2 Crear tu Lakehouse

Ya sabes qué es; ahora créalo. Desde tu workspace:

1. Nuevo elemento → buscar y elegir Lakehouse
2. Ponle nombre (ej. mi_primer_lakehouse) → Crear

El nombre debe empezar con letra y solo admite alfanuméricos y guiones bajos — sin espacios ni caracteres especiales (por eso mi_primer_lakehouse va con guion bajo). El check "Lakehouse schemas" viene activado por defecto y organiza las tablas en grupos lógicos.

2.3 Las dos vistas dentro de un Lakehouse

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.

2.4 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.

Nota: el modelo semántico que consume Power BI no es uno de estos tres puntos. Es una capa que se construye encima del acceso al dato: él mismo lee las tablas (vía el endpoint SQL o directo desde OneLake con Direct Lake) y luego alimenta los reportes. Está río abajo de los puntos de conexión, no al mismo nivel — lo verás en la sección 4.

En este tutorial solo usaremos el punto de conexión de análisis SQL —para consultar la tabla y crear el modelo semántico—. El de Notebook requiere F8 o superior (no arranca en el trial F4), y el del centro de eventos es para datos en streaming: un flujo continuo de eventos en tiempo real. Lo nuestro es distinto — es batch: el dato se trae en cargas programadas (por ejemplo, cada hora o cada día), no en un flujo continuo. El pipeline igual fluye y se actualiza solo; lo que cambia es la cadencia: por lotes en un horario, no evento por evento en vivo.

2.5 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.

3. El pipeline: de la API a una tabla consultable

Un pipeline de datos es el camino que recorre un dato desde su origen hasta quedar listo para usarse. Aquí construirás uno real: traer información de una API pública de GitHub y dejarla como una tabla Delta consultable en tu Lakehouse.

3.1 Qué es un Flujo de datos Gen2

Con el Lakehouse abierto, la opción Obtener datos despliega varias formas de cargar información: subir archivos, empezar con datos de muestra, crear accesos directos (shortcuts) a datos externos, trabajos de copia, notebooks o secuencias de eventos, entre otras (el menú evoluciona con el tiempo). Cada una sirve para un escenario distinto.

Para lo nuestro —traer datos de una API web— la herramienta indicada es el Flujo de datos Gen2: la herramienta de ingesta y transformación de Fabric basada en Power Query, el mismo motor visual de Excel y Power BI. Te conectas a una fuente, limpias y transformas los datos con clics (sin escribir código) y defines a dónde van. (En la documentación en inglés lo verás como Dataflow Gen2 — es lo mismo.)

¿Por qué este y no otra herramienta? Porque tiene su propio compute, independiente de Spark, así que funciona incluso en el trial F4. La alternativa sería un Notebook de Spark con código, pero requiere F8 o superior; lo vemos al final.

Nota — ¿es lo mismo que Power Query? Técnicamente no, pero lleva el mismo motor dentro. Power Query es la tecnología de transformación que ya usas en Excel y Power BI Desktop; el Flujo de datos Gen2 toma ese motor y lo lleva a la nube, sumándole lo que Power Query solo no tiene: corre sobre la capacidad de Fabric, se programa para actualizarse solo y, sobre todo, escribe el resultado en un destino de la nube. Aquí ese destino es el Lakehouse, pero Gen2 también puede ingestar a un Warehouse, una Azure SQL Database, bases de datos KQL y otros.

3.2 Crear el Flujo de datos Gen2

En Obtener datos → Nuevo flujo de datos Gen2. Ponle al flujo un nombre descriptivo: dataflow-github-repos.

Torvalds es una cuenta de github de prueba, pero podrías utilizar cualquier otra cuenta de github que conozcas y quieras analizar sus datos.

3.3 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

Para explorar datos de otra cuenta de github cambia torvalds por el nombre del repositorio de github

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

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

3.4 Aplicar cambios a la tabla - 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

3.5 Renombrar la tabla

Por defecto, el Flujo de datos nombra su consulta —y por tanto la tabla que escribirá en el Lakehouse— como "Consulta". Renómbrala ahora con un nombre descriptivo, repos_github, porque ese es el nombre con el que la tabla aparecerá en el Lakehouse y el que tendrás que seleccionar al crear el modelo semántico (sección 4.2). Si la dejas como "Consulta", en ese diálogo no sabrás cuál de las tablas es la tuya.

En Power Query, la consulta se renombra en el panel izquierdo: clic derecho sobre la consulta → Cambiar nombre.

3.6 Configurar el destino

Como creaste el Flujo de datos desde el Lakehouse, este ya viene como destino predeterminado — no hace falta configurarlo a mano (lo confirmas pasando el cursor sobre el ícono del destino, que aparece etiquetado como Destino predeterminado). (Si lo hubieras creado desde el workspace, ahí sí tendrías que agregarlo: Agregar destino de datos → Lakehouse.)

Lo único que conviene revisar es el modo de actualización: déjalo en Reemplazar — cada vez que el flujo corre, sobreescribe la tabla completa. Y si alguna vez quieres apuntar a otro destino, borra el actual y elige uno nuevo.

3.7 Publicar y ejecutar

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

Una distinción clave antes de seguir: el Flujo de datos Gen2 es solo el procesador —literalmente Power Query—. Trae los datos y los transforma, pero no los almacena. Los datos viajan a través del flujo y aterrizan en el Lakehouse, que es el destino. Por eso, para comprobar que llegaron, no miras el flujo: vas al Lakehouse.

3.8 Verificar la tabla

Para comprobar que los datos llegaron, ve a Áreas de trabajo y abre el objeto Lakehouse (mi_primer_lakehouse). La tabla repos_github aparece bajo Tables. Para consultarla, cambia al Punto de conexión de análisis SQL (el desplegable de arriba a la derecha) y ejecuta SQL directamente:

SELECT name, language, stargazers_count, forks_count
FROM repos_github
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.

3.9 Programar la actualización

Hasta aquí el Flujo de datos corre solo cuando le das Guardar y ejecutar a mano. Para que se actualice solo, desde el workspace, en los tres puntos del Flujo de datos Gen2 → Programar actualización. Se define frecuencia (horaria, diaria, semanal), hora exacta y zona horaria — idéntico al scheduler de Power BI Service.

Aquí hay una diferencia conceptual importante 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 flujo de datos

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 (modelo semántico, notebook, warehouse, otro flujo de datos) recibe los datos frescos automáticamente, sin configurar nada más en cada reporte.

3.10 La alternativa con código: Notebook de Spark

Si tuvieras una capacidad F8 o superior, podrías construir este mismo pipeline con un Notebook de Spark en unas pocas líneas de Python: llamar a la API, convertir la respuesta en un DataFrame y escribirlo como tabla Delta. Es más flexible para transformaciones complejas, pero pesa más — cada Notebook levanta un cluster Spark al arrancar, y por eso en el trial F4 ni siquiera inicia la sesión (no le alcanzan los VCores). Lo dejamos anotado como referencia para cuando subas de capacidad.

---

4. Del Lakehouse a un reporte

Tener la tabla en el Lakehouse es la mitad del trabajo. El pago final de un pipeline es ver los datos. Y aquí aparece una decisión de arquitectura: ¿por qué visualizar desde la tabla del Lakehouse y no conectar el reporte directo a la API?

Porque la tabla del Lakehouse es una fuente reutilizable y única: una sola ingesta alimenta el endpoint SQL, los notebooks y todos los reportes que quieras, sin volver a pegarle a la API en cada actualización. El reporte se vuelve un consumidor más de esa tabla — exactamente el flujo que dibuja el diagrama de la sección 3.

4.1 La capa intermedia obligatoria: el modelo semántico

Un reporte de Power BI nunca lee las tablas Delta directamente. Siempre se apoya en un modelo semántico: la capa de modelado con relaciones, medidas (DAX) y formatos. El reporte visualiza el modelo, no la tabla cruda.

Tabla Delta (Lakehouse) → Modelo semántico (Direct Lake) → Reporte

Un dato de contexto: hasta el 5 de septiembre de 2025, Fabric creaba un modelo semántico "por defecto" automáticamente al crear el Lakehouse. Desde esa fecha ya no — hay que crearlo a mano. Es mejor así: el modelo por defecto traía limitaciones, y ahora controlas qué tablas incluir.

4.2 Crear el modelo semántico

El modelo se crea desde el objeto Lakehouse, no desde el endpoint SQL:

1. Abrir el Lakehouse (mi_primer_lakehouse)
2. En la cinta → Nuevo modelo semántico
3. Se abre el diálogo Nuevo modelo semántico, que pide solo tres cosas:
4. Nombre — ponle modelo-github-repos.
5. Área de trabajo — viene preseleccionada (aprendizaje-fabric).
6. Seleccionar las tablas — marca tu tabla bajo el esquema dbo (repos_github) y pulsa Confirmar (el botón se habilita al marcar al menos una).

Nota del diálogo: no puedes seleccionar vistas SQL para Direct Lake en OneLake, solo tablas. Las tablas basadas en vistas SQL se pueden agregar después al modelo usando otros modos de almacenamiento.

4.3 La otra variante: Direct Lake en OneLake vs. en SQL

Como creaste el modelo desde el Lakehouse, Fabric lo puso en Direct Lake en OneLake sin preguntarte nada. Pero existe una segunda variante —Direct Lake en SQL— que solo aparece como opción a elegir cuando creas el modelo desde el Punto de conexión de análisis SQL. La diferencia:

	Direct Lake en OneLake	Direct Lake en SQL
Lee de	Tablas Delta directo en OneLake	A través del endpoint SQL
Fallback a DirectQuery	No	Sí
Estado	El moderno, recomendado	El anterior

Para modelos nuevos se recomienda Direct Lake en OneLake —el que ya tienes—; no hay razón para usar el otro salvo casos puntuales (por ejemplo, seguridad a nivel de fila o columna definida en el endpoint SQL).

4.4 Qué es Direct Lake (y por qué importa)

Direct Lake es un modo de almacenamiento exclusivo de Fabric: el modelo semántico lee las tablas Delta directo desde OneLake a memoria, procesadas por el motor VertiPaq — tan rápido como el modo Import, pero sin importar ni duplicar el dato y sin programar refrescos. Cuando el Flujo de datos Gen2 actualiza la tabla, el reporte ve el dato fresco solo.

Si vienes de Power BI Desktop ya conoces dos modos de almacenamiento; Direct Lake es un tercero que combina lo mejor de ambos:

Modo	¿Copia los datos?	Frescura	Velocidad
Import (el clásico en local)	Sí, al modelo	Una foto: hay que refrescar	Rápida (en memoria)
DirectQuery	No, consulta la fuente en vivo	En tiempo real	Más lenta
Direct Lake (lo nuestro)	No, lee Delta de OneLake	Auto-fresco	Rápida (en memoria)

Es la velocidad de Import con la frescura de DirectQuery, sin las desventajas de ninguno.

Consecuencia práctica: como el modelo es Direct Lake, la única programación de actualización que necesitas es la del Flujo de datos Gen2 (la de la sección 3.9). El modelo semántico se sincroniza solo, no lleva su propio refresh. Si fuera modo Import, tendrías que programar además el refresh del modelo — dos programaciones en vez de una.

4.5 Construir el reporte

Con el modelo semántico listo:

1. Abrir el modelo semántico (modelo-github-repos)
2. En la cinta → Nuevo reporte
3. Se abre el lienzo de Power BI ya conectado a las tablas → arrastrar campos (name, language, stargazers_count…) y crear las visualizaciones. Guarda el informe con un nombre descriptivo: informe-bi-github-repos

Con esto el pipeline queda completo de punta a punta:

API GitHub → Flujo de datos Gen2 → tabla Delta (Lakehouse) → modelo semántico (Direct Lake) → reporte Power BI

---

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.
• El modelo semántico ya no se autocrea — desde el 5 de septiembre de 2025, Fabric dejó de generar el modelo semántico "por defecto" al crear un Lakehouse. Hay que crearlo manualmente desde el objeto Lakehouse (Nuevo modelo semántico), que lo crea directamente en Direct Lake en OneLake.
• Desde dónde lo creas define el modo — si creas el modelo desde el objeto Lakehouse, nace en Direct Lake en OneLake sin preguntarte. Solo si lo creas desde el Punto de conexión de análisis SQL te aparece el diálogo para elegir entre Direct Lake en OneLake y Direct Lake en SQL.
• No se pueden seleccionar vistas SQL para Direct Lake en OneLake — en el diálogo del modelo solo aparecen tablas, no vistas. Las tablas basadas en vistas SQL se agregan después usando otros modos de almacenamiento.

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.