Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoNotebooks, SQL, Python y PySpark en el workspace
Trabaja con notebooks y archivos como código mantenible, reproducible y parametrizable.
01Modelo mentalNotebooks y archivos de workspace
Un notebook es útil para desarrollo interactivo cuando sus dependencias, parámetros y orden de ejecución son explícitos.
+
Notebooks y archivos de workspace
Un notebook es útil para desarrollo interactivo cuando sus dependencias, parámetros y orden de ejecución son explícitos.
Las celdas admiten SQL, Python y visualizaciones, pero el estado del proceso permite ejecutar fuera de orden. Para que otra persona reproduzca el resultado, la ejecución desde cero debe crear las mismas variables, tablas temporales y salidas.
Los archivos de workspace y módulos Python facilitan separar lógica reutilizable del relato exploratorio. Un notebook de entrada debería coordinar funciones comprobables, no concentrar transformaciones y efectos secundarios en decenas de celdas.
from commerce.transforms import clean_orders
source = spark.table("main.bronze.orders")
result = clean_orders(source)
display(result.limit(20))clean_orders puede probarse fuera del notebook con DataFrames pequeños.
¿Qué prueba rápida detecta estado oculto?
Profundiza
Un notebook es simultáneamente documento, cliente de ejecución y estado interactivo. Esa combinación acelera el aprendizaje, pero dificulta reproducibilidad cuando las celdas se ejecutan fuera de orden o dependen de variables, tablas temporales y librerías instaladas manualmente. El modelo autosuficiente separa narración de lógica: el notebook recibe parámetros, invoca funciones importables, muestra evidencia pequeña y termina con salidas gobernadas. Debe poder ejecutarse desde un estado limpio de principio a fin. Los archivos de workspace y paquetes Python guardan lógica comprobable; Jobs aporta el contrato productivo. La pregunta clave no es si una celda funcionó una vez, sino qué dependencias explican exactamente su resultado.
Variables, imports, vistas temporales y cachés que sobreviven entre comandos de una sesión activa.
Es la causa principal de notebooks que funcionan solo para su autor.Cambio observable fuera del valor devuelto, como escribir una tabla o modificar configuración.
Debe aislarse para que reintentos y pruebas sean predecibles.Capacidad de obtener la misma salida desde entradas, código, parámetros y dependencias declarados.
Es el criterio que permite promover un notebook a operación confiable.Resumen
Puntos clave
- Ejecutar desde cero revela estado oculto
- La lógica reusable pertenece a módulos
- La salida debe depender de parámetros explícitos
Evita
- Depender de una celda ejecutada horas antes
- Instalar librerías manualmente sin fijar versión
02ImplementaciónSQL frente a PySpark
SQL expresa transformaciones relacionales con claridad; PySpark facilita composición, control y pruebas en proyectos Python.
+
SQL frente a PySpark
SQL expresa transformaciones relacionales con claridad; PySpark facilita composición, control y pruebas en proyectos Python.
SQL resulta conciso para selección, agregación, joins y DDL/DML. PySpark usa el mismo optimizador para operaciones DataFrame y permite construir funciones, iterar sobre metadatos o integrar librerías Python.
La elección no debe basarse en una supuesta diferencia universal de rendimiento: muchas expresiones convergen en planes equivalentes. Conviene priorizar mantenibilidad, conocimientos del equipo y necesidad de abstracción, usando funciones nativas antes que UDF Python.
from pyspark.sql import functions as F
daily = (orders
.filter(F.col("status") == "paid")
.groupBy("order_date")
.agg(F.sum("amount").alias("revenue")))Compara daily.explain('formatted') con la consulta SQL equivalente.
¿SQL es siempre más rápido que PySpark DataFrames?
Profundiza
SQL y PySpark expresan planes sobre el mismo motor, pero ofrecen distintas herramientas cognitivas. SQL describe relaciones y resultados mediante álgebra declarativa; suele ser la forma más legible para filtros, joins, agregaciones y modelos que revisan perfiles diversos. PySpark compone la API DataFrame desde Python y facilita abstracciones, control, reutilización y pruebas. No hay premio por traducir cada consulta de una forma a otra. Primero se representa la transformación con funciones nativas que Catalyst pueda analizar; después se elige el lenguaje que hace visible la intención y reduce complejidad accidental. Una UDF Python es una frontera de optimización y debe justificarse, no un atajo habitual.
Representación declarativa de operaciones sobre relaciones antes de escoger algoritmos físicos.
Permite entender que SQL y DataFrames pueden converger en la misma ejecución.Expresión conocida por Spark y visible para análisis, optimización y generación de código.
Suele conservar mejor rendimiento y diagnósticos que una UDF opaca.Función definida por el usuario ejecutada en la frontera entre JVM y proceso Python.
Puede ser necesaria, pero introduce costes y limita optimizaciones si reemplaza funciones incorporadas.Resumen
Puntos clave
- SQL y DataFrame API comparten optimizador
- PySpark facilita modularidad Python
- Las funciones nativas suelen superar a UDF Python
Evita
- Convertir a pandas para una transformación distribuida
- Crear una UDF para una función ya disponible en Spark SQL
03OperaciónWidgets y parámetros de tareas
Los parámetros de Job y widgets convierten una ejecución en un contrato reproducible, no en una colección de valores editados a mano.
+
Widgets y parámetros de tareas
Los parámetros de Job y widgets convierten una ejecución en un contrato reproducible, no en una colección de valores editados a mano.
Un widget recibe valores de texto en un notebook y puede ser alimentado por parámetros de tarea. Conviene validar formato, rango y valores permitidos al comienzo para fallar antes de modificar datos.
Los parámetros deben representar variación de ejecución, como fecha o catálogo objetivo; secretos y credenciales no deben viajar como texto. Para compartir valores pequeños entre tareas se usan task values, mientras que datasets se publican en almacenamiento gobernado.
from datetime import date
dbutils.widgets.text("process_date", "")
raw = dbutils.widgets.get("process_date")
process_date = date.fromisoformat(raw)
if process_date > date.today():
raise ValueError("process_date no puede ser futura")El Job puede pasar process_date sin editar el notebook.
¿Qué tipo devuelve dbutils.widgets.get?
Profundiza
Un parámetro es parte del contrato de una ejecución: tiene nombre, origen, tipo esperado, valor permitido y efecto. Un widget es solo una interfaz para recibir valores en un notebook; no debe convertirse en almacenamiento de configuración ni en secreto. Los parámetros de Job se resuelven para un run y pueden transmitirse a tareas compatibles. La transformación convierte cadenas recibidas en tipos de dominio y falla pronto si son inválidas. Separar parámetros de datos evita pasar grandes payloads por la orquestación: una fecha, ruta o identificador referencia entradas persistidas; la tabla o Volume contiene el dataset. Así una ejecución puede reconstruirse leyendo run, código y valores registrados.
Valor declarado y registrado que configura una ejecución o tarea concreta.
Permite reusar código y reconstruir por qué un run procesó una entrada determinada.Control de notebook que expone un valor textual a la sesión interactiva o parametrizada.
Es una interfaz de entrada, no un sistema de tipos ni un almacén de secretos.Expresión que resuelve metadatos del run o valores producidos por tareas en tiempo de ejecución.
Conecta tareas sin valores manuales y mantiene trazabilidad del contexto.Resumen
Puntos clave
- Los widgets reciben strings
- Valida parámetros antes de escribir
- No uses task values para transportar datasets
Evita
- Leer un widget sin validar su tipo
- Incluir contraseñas directamente en parámetros del Job
04DiagnósticoLibrerías y entornos reproducibles
Databricks Connect permite ejecutar y depurar código Spark desde un IDE local contra compute de Databricks.
+
Librerías y entornos reproducibles
Databricks Connect permite ejecutar y depurar código Spark desde un IDE local contra compute de Databricks.
Databricks Connect implementa Spark Connect: el proceso local construye planes que se ejecutan remotamente. Esto permite usar depurador, tests e integración del IDE sin descargar el dataset completo al portátil.
La versión del cliente debe ser compatible con el runtime o serverless seleccionado y la autenticación debe configurarse mediante un perfil, OAuth u otro mecanismo soportado. Código que depende de APIs exclusivas del driver o del filesystem local puede necesitar adaptación.
from databricks.connect import DatabricksSession
spark = DatabricksSession.builder.profile("dev").serverless().getOrCreate()
print(spark.range(10).count())El perfil dev se configura fuera del repositorio; serverless requiere soporte en el workspace.
¿Dónde se ejecuta spark.range(10).count() con Connect?
Profundiza
Databricks Connect separa la experiencia de edición local del lugar donde Spark ejecuta. El IDE mantiene código, depurador y pruebas; una sesión remota envía planes a compute de Databricks y utiliza datos gobernados allí. No es un Spark local que copie automáticamente tablas al portátil. La compatibilidad depende de la versión de Databricks Connect, runtime y capacidades soportadas; la autenticación identifica al desarrollador o principal. El modelo mental evita dos errores: asumir que el procesamiento grande ocurre localmente o creer que depurar autoriza datos adicionales. La productividad mejora cuando lógica pura se prueba localmente y las integraciones Spark se verifican contra un entorno remoto acotado.
Arquitectura cliente-servidor usada para construir planes en un cliente y ejecutarlos en un backend Spark remoto.
Explica la separación entre IDE local y procesamiento de Databricks.Correspondencia soportada entre cliente Databricks Connect y runtime o compute remoto.
Evita errores de protocolo y funciones inexistentes durante desarrollo.Comprobación que ejercita dependencias reales como Spark remoto, catálogo y almacenamiento en un entorno controlado.
Detecta problemas que una prueba puramente local no puede representar.Resumen
Puntos clave
- El procesamiento Spark ocurre en Databricks
- Cliente y runtime deben ser compatibles
- La autenticación no se incrusta en el código
Evita
- Creer que Spark procesa los datos en el portátil
- Guardar un personal access token en el repositorio
05Decisión de diseñoColaboración, revisión y modularidad
Git folders, dependencias fijadas y paquetes separan colaboración, entorno y lógica de negocio.
+
Colaboración, revisión y modularidad
Git folders, dependencias fijadas y paquetes separan colaboración, entorno y lógica de negocio.
Un Git folder sincroniza archivos del workspace con un proveedor Git y permite ramas, commits y revisión. No sustituye un proceso de CI ni convierte automáticamente un notebook en artefacto desplegable.
Un proyecto mantenible declara dependencias en pyproject.toml, limita rangos de versión y construye un wheel cuando corresponde. Dev, test y prod deben ejecutar el mismo artefacto, cambiando configuración mediante variables y no mediante copias del código.
project:
source: src/commerce
tests: tests
artifact: dist/commerce.whl
environments: [dev, test, prod]
secrets_in_repo: falseEl bundle del módulo 11 automatizará la promoción del artefacto.
¿Qué debe cambiar entre dev y prod?
Profundiza
Un proyecto productivo necesita separar tres versiones: código, dependencias e infraestructura declarada. Git folders sincroniza archivos del workspace con un repositorio y permite ramas; un lock o especificación fija bibliotecas; un paquete Python ofrece una unidad instalable e importable; un bundle describe Jobs, pipelines y targets. Copiar un notebook para dev, test y prod rompe esa identidad porque cada copia deriva. El modelo correcto promociona el mismo commit y artefacto, mientras configuración, catálogo e identidad cambian por target. Los secretos nunca forman parte del repositorio. Esta estructura hace posible revisar diferencias, reproducir un run y revertir una versión sin reconstruir manualmente el estado del workspace.
Salida versionada e inmutable de un proceso de construcción, como una wheel de Python.
Permite desplegar exactamente lo probado en vez de reconstruir por ambiente.Carpeta del workspace conectada a un repositorio Git para editar y sincronizar código.
Facilita colaboración sin convertir el workspace en fuente única de verdad.Registro de versiones concretas resueltas para bibliotecas directas y transitivas.
Reduce diferencias de entorno y hace repetibles pruebas y ejecuciones.Resumen
Puntos clave
- Git registra código, no datos ni secretos
- pyproject.toml declara dependencias
- El mismo artefacto debe promocionarse entre entornos
Evita
- Cometer credenciales o datos sensibles
- Mantener una versión distinta del notebook por entorno