Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLecció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.
17 min aprox.
03OperaciónFunciones transform puras
Distribuye wheels reproducibles y fija dependencias en el nivel correcto para evitar que notebook, job y serverless resuelvan entornos distintos.
+
Funciones transform puras
Distribuye wheels reproducibles y fija dependencias en el nivel correcto para evitar que notebook, job y serverless resuelvan entornos distintos.
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.
# 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.
¿Qué riesgo evita promover exactamente la misma wheel de test a prod?
Profundiza
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.
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.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.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.Resumen
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.