Un Notebook en Microsoft Fabric es un entorno interactivo de código (Python o PySpark) para transformar datos que superan lo que Power Query puede resolver: exploración, reglas complejas, consumo de APIs y ciencia de datos. Sirve para descubrir la solución y procesar volúmenes altos, pero no es un pipeline de producción hasta que tiene parámetros, salida definida, ejecución repetible, observabilidad y responsable.
Qué es un Notebook dentro de la arquitectura de datos
Un Notebook es uno de los motores de transformación de Fabric, dentro del área de Data Engineering. Su lugar está en la capa donde el dato deja de estar como llegó y empieza a convertirse en algo útil para el negocio. En el método que enseñamos, esa capa se ordena con la arquitectura medallion: Bronze preserva el dato como llega (trazabilidad, recuperación, auditoría), Silver limpia, une, estandariza, deduplica y corrige problemas conocidos, y Gold organiza los datos para consumo analítico, informes, Excel y agentes.
El Notebook es el motor que ejecuta la lógica de esas transformaciones cuando el problema pide código. Corre sobre Spark y trabaja contra un Lakehouse, así que puede leer y escribir directamente sobre las tablas del proyecto. No compite con Power BI ni reemplaza el modelo semántico: es la herramienta que prepara los datos antes de que lleguen a esa capa de consumo.
Para qué sirve un Notebook en Fabric
El Notebook encaja cuando la transformación excede a las herramientas de bajo código. Casos concretos:
- Exploración de datos: entender un origen nuevo, revisar calidad, probar hipótesis antes de construir nada estable.
- Reglas complejas: lógica condicional, cálculos por etapas o limpiezas que serían frágiles o ilegibles en Power Query.
- Consumo de APIs: traer datos de servicios externos que no tienen un conector directo.
- Ciencia de datos: preparación de features, entrenamiento y evaluación de modelos.
- Volumen alto: procesamiento que supera la capacidad práctica de Dataflow Gen2, aprovechando PySpark para escalar.
La ventaja del Notebook es el control total: todo el paso queda escrito, se puede versionar y no esconde lógica crítica dentro de una interfaz. La contrapartida es que exige criterio de ingeniería. Por eso la regla del método es usar la opción más simple que pueda probarse, versionarse y operarse. Si Power Query o SQL resuelven el caso, no hace falta un Notebook.
Cuándo NO conviene elegir un Notebook
Elegir el motor por moda es un error caro. Un Notebook mal ubicado agrega mantenimiento, dependencias y una superficie de fallo que un Dataflow no tendría. Antes de abrir uno, conviene descartar las alternativas más simples según lógica, volumen y capacidad del equipo. Si la duda es justamente entre bajo código y código, este análisis de qué motor de transformación conviene entre Dataflow Gen2 y Notebook ayuda a decidir con criterio.
| Motor | Mejor encaje | Qué controlar |
|---|---|---|
| Dataflow Gen2 | Preparación tabular, lógica Power Query, equipos de bajo código | Consultas legibles, destino explícito, esquema de salida estable |
| SQL | Uniones, agregaciones y modelos relacionales en Lakehouse o Warehouse | Scripts versionados, pruebas de reconciliación, grano documentado |
| Notebook | Python o PySpark para exploración, reglas complejas, APIs, ciencia de datos | Código reproducible, parámetros, salida persistente, registros |
| Spark Job Definition | Procesos Spark de producción, por lotes o streaming, programados | Archivo principal, argumentos, lakehouse asociado, agenda, monitoreo |
| Environment | Notebooks y trabajos que necesitan las mismas librerías y configuración | Versiones de dependencias, configuración compartida, promoción controlada |
La lectura de la tabla es directa: si el problema es tabular y de bajo código, Dataflow Gen2; si es relacional, SQL; el Notebook entra cuando el trabajo supera a ambos.
La regla que separa un experimento de un producto de datos
Aquí está el punto que más confusión genera. Un Notebook interactivo puede ayudar a descubrir la solución, pero eso no lo convierte en un pipeline de producción. Descubrir y operar son dos cosas distintas.
Un Notebook pasa a ser un producto de datos operable solo cuando cumple seis condiciones:
- Parámetros: no valores fijos escritos a mano, sino entradas que se pueden cambiar sin editar el código.
- Dependencias controladas: las mismas librerías y configuración en cada ejecución, algo que en Fabric se fija con un Environment.
- Salida definida: un destino explícito y un esquema de salida estable, no un resultado que solo vive en la pantalla.
- Ejecución repetible: que corra igual hoy y en tres meses, idealmente programado.
- Observabilidad: registros que permitan ver qué pasó y detectar cuándo algo falló.
- Responsable: una persona que responde por ese proceso.
Sin esas seis, un Notebook es un experimento útil, no un proceso del que pueda depender una decisión de negocio. Cuando el proceso ya es estable y necesita correr como trabajo programado de producción, el motor adecuado suele ser un Spark Job Definition, no el Notebook interactivo. Si nunca configuraste ese motor, esta guía sobre cómo implementar Spark en Microsoft Fabric paso a paso recorre el proceso completo. Conviene mantener separado el experimento de la producción.
Notebook, Environment y Pipeline: cómo se reparten el trabajo
Tres piezas se confunden seguido, y distinguirlas evita arquitecturas frágiles.
- El Notebook transforma: contiene la lógica.
- El Environment fija las condiciones: versiones de dependencias, configuración de Spark y recursos compartidos entre Notebooks y trabajos, para que todos corran sobre la misma base reproducible.
- El Pipeline coordina: orquesta el orden, las dependencias entre pasos y la programación.
La frase que resume el reparto: el Pipeline coordina, el motor transforma. Un Notebook no debería orquestarse a sí mismo con parches internos; esa responsabilidad es del Pipeline. Y no debería depender de librerías instaladas a mano en cada corrida; esa responsabilidad es del Environment. Respetar esa separación es lo que mantiene el sistema legible y operable con el tiempo.
Cómo decidir en la práctica
Una secuencia simple para elegir bien:
- Define primero la métrica y la decisión que el dato debe alimentar. La herramienta viene después, no antes.
- Pregunta si Dataflow Gen2 o SQL resuelven el caso. Si la respuesta es sí, quédate ahí.
- Usa un Notebook solo si el problema es de exploración, reglas complejas, APIs, ciencia de datos o volumen que supera lo anterior.
- Si el Notebook va a operar en producción, dale parámetros, Environment, salida definida, programación como Spark Job Definition, observabilidad y responsable.
Este criterio evita el patrón más común: un Notebook interactivo que alguien deja corriendo a mano cada semana y que se rompe en silencio cuando esa persona se va o cambia una dependencia.
Criterio antes que herramienta
El Notebook es potente, pero su valor depende del criterio con el que se elige y se opera. Un motor mal ubicado no mejora el sistema: multiplica su fragilidad y su costo de mantenimiento. Si quieres ver cómo se aplican estos criterios sobre un caso real, con la arquitectura completa desde el dato crudo hasta la decisión de negocio, mira la demo gratuita.
Preguntas relacionadas
¿Qué es un Notebook en Microsoft Fabric?
Es un entorno interactivo de código, en Python o PySpark, dentro del área de Data Engineering de Fabric. Ejecuta transformaciones de datos que superan lo que Power Query puede resolver y trabaja directamente contra un Lakehouse sobre Spark.
¿Para qué sirve un Notebook en Fabric?
Sirve para exploración de datos, reglas complejas, consumo de APIs, ciencia de datos y procesamiento de volúmenes altos. Es el motor que aplica lógica en las capas Silver y Gold de la arquitectura medallion cuando el bajo código se queda corto.
¿Cuándo debo usar un Notebook en lugar de Dataflow Gen2 o SQL?
Usa Dataflow Gen2 para preparación tabular de bajo código y SQL para uniones y agregaciones relacionales. Elige un Notebook solo cuando el problema exige Python o PySpark: reglas complejas, APIs, ciencia de datos o volúmenes que superan a las otras dos opciones.
¿Un Notebook interactivo es un pipeline de producción?
No por sí solo. Un Notebook interactivo ayuda a descubrir la solución, pero solo pasa a producción cuando tiene parámetros, dependencias controladas, salida definida, ejecución repetible, observabilidad y un responsable. Para trabajos programados suele convenir un Spark Job Definition.
¿Cuál es la diferencia entre un Notebook, un Environment y un Pipeline?
El Notebook transforma los datos con su lógica, el Environment fija las dependencias y la configuración compartida para que la ejecución sea reproducible, y el Pipeline coordina el orden y la programación de los pasos. La regla es que el Pipeline coordina y el motor transforma.