Comparteix via

Procedimientos recomendados para el proceso sin servidor

En este artículo se presentan las recomendaciones de procedimientos recomendados para usar el proceso sin servidor en los cuadernos y trabajos.

Siguiendo estas recomendaciones, mejorará la productividad, la rentabilidad y la confiabilidad de las cargas de trabajo en Azure Databricks.

Migración de cargas de trabajo a proceso sin servidor

Para garantizar el aislamiento del código de usuario en el entorno de proceso sin servidor compartido, Azure Databricks utiliza Lakeguard para aislar el código de usuario del motor de Spark y de otros usuarios.

Debido a esto, algunas tareas requieren cambios de código para poder seguir funcionando en la computación sin servidor. Para ver una lista de limitaciones, consulte Limitaciones de los procesos sin servidor.

Algunas cargas de trabajo son más fáciles de migrar que otras. Las cargas de trabajo que cumplen los siguientes requisitos serán las más fáciles de migrar:

  • Los datos a los que se accede deben almacenarse en el catálogo de Unity.
  • La carga de trabajo debe ser compatible con el proceso estándar.
  • La carga de trabajo debe ser compatible con Databricks Runtime 14.3 o superior.

Para probar si una carga de trabajo funcionará en un proceso sin servidor, ejecútelo en un recurso de proceso clásico con el modo de acceso estándar y un entorno de ejecución de Databricks de 14.3 o superior. Si la ejecución se ejecuta correctamente, la carga de trabajo está lista para la migración.

Muchas cargas de trabajo anteriores no se migrarán sin problemas. En lugar de recodificar todo, Azure Databricks recomienda priorizar la compatibilidad de proceso sin servidor a medida que se crean nuevas cargas de trabajo.

Especificación de versiones de paquetes de Python

Al migrar al proceso sin servidor, ancle los paquetes de Python a versiones específicas para garantizar entornos reproducibles. Si no especifica una versión, el paquete puede resolverse en una versión diferente basada en la versión del entorno sin servidor, lo que puede aumentar la latencia a medida que se deben instalar nuevos paquetes.

Por ejemplo, el requirements.txt archivo debe incluir versiones de paquete específicas, como esta:

numpy==2.2.2
pandas==2.2.3

Versiones de entorno sin servidor

El proceso sin servidor usa versiones de entorno en lugar de versiones tradicionales de Databricks Runtime. Esto representa un cambio en la forma de administrar la compatibilidad con la carga de trabajo:

  • Enfoque de Databricks Runtime: seleccione una versión específica de Databricks Runtime para la carga de trabajo y administre las actualizaciones manualmente para mantener la compatibilidad.
  • Enfoque sin servidor: escribe código en una versión de entorno y Azure Databricks actualiza de forma independiente el servidor subyacente.

Las versiones de entorno proporcionan una API de cliente estable que garantiza que la carga de trabajo siga siendo compatible mientras Azure Databricks ofrece de forma independiente mejoras de rendimiento, mejoras de seguridad y correcciones de errores sin necesidad de cambios de código en las cargas de trabajo.

Cada versión del entorno incluye bibliotecas de sistema actualizadas, características y correcciones de errores, al tiempo que mantiene la compatibilidad con versiones anteriores para las cargas de trabajo. Azure Databricks admite cada versión de entorno durante tres años a partir de su fecha de lanzamiento, lo que proporciona un ciclo de vida predecible para planear las actualizaciones.

Para seleccionar una versión de entorno para la carga de trabajo sin servidor, consulte Selección de una versión de entorno. Para más información sobre las versiones de entorno disponibles y sus características, consulte Versiones de entorno sin servidor.

Ingesta de datos de sistemas externos

Dado que el proceso sin servidor no admite la instalación de archivos JAR, no puede usar un controlador JDBC o ODBC para ingerir datos de un origen de datos externo.

Entre las estrategias alternativas que puede usar para la ingesta se incluyen:

Alternativas de ingesta

Al usar el proceso sin servidor, también puede usar las siguientes características para consultar los datos sin moverlos.

  • Si desea limitar la duplicación de datos o garantizar que está consultando los datos más recientes posibles, Databricks recomienda usar Delta Sharing. Consulte ¿Qué es Delta Sharing?
  • Si desea realizar informes ad hoc y trabajos de prueba de concepto, Databricks recomienda probar la opción adecuada, que podría ser Lakehouse Federation. Lakehouse Federation permite sincronizar bases de datos enteras con Azure Databricks desde sistemas externos y se rige por Unity Catalog. Consulte ¿Qué es la Federación Lakehouse?

Pruebe una o ambas características y compruebe si cumplen los requisitos de rendimiento de las consultas.

Configuraciones de Spark admitidas

Para automatizar la configuración de Spark en un proceso sin servidor, Azure Databricks ha quitado la compatibilidad para establecer manualmente la mayoría de las configuraciones de Spark. Para ver una lista de los parámetros de configuración de Spark admitidos, consulte Configuración de propiedades de Spark para cuadernos y trabajos sin servidor.

Las ejecuciones de tareas en computación serverless fallarán si establece una configuración de Spark no compatible.

Supervisión del costo del proceso sin servidor

Hay varias características que puede usar para ayudarle a supervisar el coste del proceso sin servidor:

  • Last updated on