Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 28 · Lección

Funciones transform puras

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lección 3 de 5

Funciones transform puras

Distribuye wheels reproducibles y fija dependencias en el nivel correcto para evitar que notebook, job y serverless resuelvan entornos distintos.

Duración
17 min aprox.
Objetivo
Distribuye wheels reproducibles y fija dependencias en el nivel correcto para evitar que notebook, job y serverless resuelvan entornos distintos.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Proyectos Python, dependencias y pruebas

Convierte notebooks en un paquete comprobable con límites claros y entornos reproducibles.

Al terminar podrás
  • Diseñar un paquete Python modular
  • Gestionar wheels y dependencias
  • Probar DataFrames y contratos
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
delivery
Dominios blueprint
Developing Code · Testing
Estado
Revisión editorial interna
Fuentes principales
Python unit testing in the workspace · What are workspace files?
Reportar un error
03
Operación

Funciones transform puras

Distribuye wheels reproducibles y fija dependencias en el nivel correcto para evitar que notebook, job y serverless resuelvan entornos distintos.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m12
Reportar un error en esta lección

Una wheel empaqueta módulos y metadatos en un artefacto versionado. Declara dependencias directas en `pyproject.toml`, crea un lock o constraints para CI y fija versiones cuando la reproducibilidad lo exija. En jobs, instala la wheel como librería de la tarea; para compute clásico puedes almacenarla en workspace files o Unity Catalog Volumes según modo de acceso y runtime.

Serverless usa entornos y no admite init scripts. Fija paquetes y prueba el environment version seleccionado. Evita `%pip install` disperso por notebooks productivos: puede reiniciar Python, cambiar precedencia y hacer que dos tareas ejecuten código distinto. La promoción debe mover el mismo hash de wheel, no reconstruirla de fuentes diferentes en cada ambiente.

Modelo mental

Una wheel es una unidad inmutable de distribución Python: contiene código y metadatos de versión, no la promesa de que cualquier entorno resolverá dependencias igual. La reproducibilidad requiere separar dependencias de ejecución, desarrollo y plataforma, fijar rangos o lock donde corresponde y construir una vez para promover el mismo artefacto. Instalar desde una celda hace que cada run resuelva el mundo de nuevo y puede producir resultados distintos entre notebook, job y serverless. Las librerías ya proporcionadas por Databricks, como PySpark, suelen declararse de forma que el desarrollo conozca su API sin empaquetarlas innecesariamente. Las dependencias nativas exigen compatibilidad con arquitectura y runtime, no sólo un nombre en pyproject.

Wheel

Formato de distribución Python construido e instalable que empaqueta código, metadatos y puntos de entrada con una versión definida.

Crea un artefacto promovible y trazable en lugar de copiar código o reinstalarlo de forma ad hoc.
Lock de dependencias

Resolución concreta y versionada de paquetes transitivos usada para reconstruir un entorno equivalente de manera deliberada.

Reduce drift entre CI y ejecución, aunque debe actualizarse con pruebas para recibir correcciones de seguridad.
Build once, promote

Práctica de construir un artefacto una vez y mover exactamente sus mismos bytes por test y producción.

Elimina diferencias introducidas por reconstrucciones y permite atribuir el comportamiento a una versión verificable.
PythonMetadatos mínimos de paquete en pyproject.toml
# pyproject.toml
[build-system]
requires = ["hatchling==1.27.0"]
build-backend = "hatchling.build"

[project]
name = "orders-pipeline"
version = "1.4.0"
requires-python = ">=3.11"
dependencies = [
  "pydantic==2.11.7",
]

[tool.pytest.ini_options]
testpaths = ["tests"]

No declares PySpark a ciegas como dependencia runtime si lo proporciona el entorno Databricks; documenta cómo lo aporta cada target de pruebas.

Puntos clave

  • Promueve el mismo artefacto inmutable entre dev, test y prod.
  • Declara dependencias directas y controla resolución transitiva.
  • Adapta la instalación a serverless, access mode y ubicación gobernada.

Evita

  • Reconstruir la wheel en prod y obtener dependencias transitivas distintas a test.
  • Usar init scripts para gestionar paquetes de serverless, donde no están soportados.

Recuerdo activo

¿Qué riesgo evita promover exactamente la misma wheel de test a prod?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

notebook-best-practices

notebook-best-practices · commit b4f55c1

notebooks/covid_eda_modular.py