Compartir vía

Procedimientos recomendados para el proceso sin servidor

Siga estas recomendaciones para maximizar la productividad, reducir los costos y mejorar la confiabilidad al usar el proceso sin servidor para cuadernos, trabajos y canalizaciones 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.

Azure Databricks recomienda priorizar la compatibilidad de proceso sin servidor al crear nuevas cargas de trabajo. En el caso de las cargas de trabajo existentes que requieren cambios de código, migrelas de forma incremental como parte del ciclo de desarrollo y mantenimiento normales.

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

Uso de nombres únicos para vistas temporales

La computación sin servidor utiliza Spark Connect, una arquitectura cliente-servidor que evalúa las vistas temporales de forma diferida. Este comportamiento difiere de la arquitectura de Spark clásica y puede provocar errores cuando el código reutiliza el mismo nombre de vista temporal, como en un bucle.

Para evitar errores, use nombres únicos para todas las vistas temporales del código.

Redes y conectividad

La computación sin servidor no admite el peering de VPC, que es una manera común de conectar la computación clásica de Databricks a los orígenes de datos de su cuenta de nube. Como alternativa, use configuraciones de conectividad de red para administrar puntos de conexión, firewalls y conectividad a servicios externos.

Por ejemplo, puede agregar un conjunto de direcciones IP de salida estables en VPC externas a una lista de permitidos para habilitar la conectividad hacia y desde el cómputo sin servidor de Azure Databricks. Para conectarse a aplicaciones empresariales (como Salesforce) o bases de datos administradas (como MySQL), use Lakeflow Connect.

Para restringir y supervisar el tráfico saliente desde el cómputo sin servidor, configure los controles de salida para su área de trabajo. Consulte Administración de directivas de red para el control de salida sin servidor.

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 del 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 un entorno base para la carga de trabajo sin servidor, consulte Selección de un entorno base. Para más información sobre las versiones de entorno disponibles y sus características, consulte Versiones de entorno sin servidor.

Administración de dependencias

El modelo de computación sin servidor no es compatible con scripts de inicialización. En su lugar, use entornos sin servidor para instalar y administrar bibliotecas para las cargas de trabajo sin servidor. Los entornos almacenan en caché los paquetes instalados, lo que reduce la latencia de inicio de las ejecuciones posteriores.

Para usar bibliotecas de un repositorio privado, configure las direcciones URL firmadas previamente para el acceso al repositorio autenticado en la configuración del entorno.

Elegir un modo de rendimiento

El proceso sin servidor de Azure Databricks ofrece dos modos de rendimiento que permiten equilibrar la velocidad y el costo en función del tipo de carga de trabajo de la siguiente manera:

  • Modo optimizado para el rendimiento (valor predeterminado): mejor para cargas de trabajo interactivas que requieren tiempos de inicio rápidos. Azure Databricks mantiene un grupo de recursos de cálculo preparados para minimizar el tiempo de espera.
  • Modo estándar: mejor para trabajos por lotes automatizados y canalizaciones que pueden tolerar tiempos de inicio más largos de 4 a 6 minutos. El modo estándar puede reducir los costos hasta 70% en comparación con el modo optimizado para rendimiento. El modo estándar está disponible para trabajos de Lakeflow y canalizaciones declarativas de Spark de Lakeflow, pero no para cuadernos.

Elija el modo que mejor se adapte a los requisitos de la carga de trabajo. En el caso de los trabajos programados en los que la latencia de inicio no es crítica, el modo Estándar normalmente ofrece el mejor valor. Para más información sobre los precios actuales, consulte la página de precios de Databricks.

Optimización de cargas de trabajo de streaming

El proceso sin servidor admite el streaming estructurado con las siguientes consideraciones:

  • El Trigger.AvailableNow modo de desencadenador es compatible con todos los trabajos y canalizaciones sin servidor. No se admiten intervalos de desencadenador basados en tiempo.

  • Al usar Trigger.AvailableNow, cada desencadenador procesa todos los datos disponibles en el origen, lo que puede dar lugar a microprocesos más grandes que un desencadenador basado en tiempo. Para evitar errores de memoria insuficiente y mantener un rendimiento predecible, limite la cantidad de datos procesados por microproceso estableciendo maxFilesPerTrigger o maxBytesPerTrigger.

Depurar cargas de trabajo sin servidor

La interfaz de usuario de Spark no está disponible en proceso sin servidor. En su lugar, use el perfil de consulta para analizar el rendimiento de las consultas y solucionar problemas de cargas de trabajo. El perfil de consulta proporciona información de ejecución detallada y es accesible desde el historial de consultas en la interfaz de usuario de Azure Databricks.

Ingesta de datos de sistemas externos

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?
  • Para los informes ad hoc y el trabajo de prueba de concepto, Lakehouse Federation te permite consultar bases de datos externas directamente desde Azure Databricks sin mover datos, gobernados 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.

Sumideros no admitidos

Si no se admite un sistema de almacenamiento como destino de escritura directa desde la computación sin servidor, puede usar el catálogo REST de Unity Catalog para permitir que ese sistema lea directamente desde tablas de Azure Databricks. Por ejemplo, Snowflake no es un destino sin servidor compatible, pero se puede configurar como un cliente Iceberg para leer tablas administradas por Unity Catalog.

Este enfoque evita la duplicación de datos y mantiene unity Catalog como capa de gobernanza para todas las lecturas. Para conocer los pasos de configuración y los clientes admitidos, consulte Acceder a tablas de Azure Databricks desde clientes de Apache Iceberg.

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.

Supervisar el costo de la computación sin servidor

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

  • Last updated on