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.

Migrar cargas de trabajo a computación sin servidor

Para obtener instrucciones paso a paso sobre cómo migrar de proceso clásico a sin servidor, incluidos los requisitos previos, los cambios de código necesarios, las estrategias de prueba y un plan de implementación por fases, consulte Migración de proceso clásico a proceso sin servidor.

Especificar versiones de paquete 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 VPN externas a una lista de permitidos para habilitar la conectividad con y desde Azure Databricks proceso sin servidor. 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 sigue siendo compatible, mientras que 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

Azure Databricks proceso sin servidor 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 computación cálidos listos 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

Computación sin servidor admite el streaming estructurado con Trigger.AvailableNow. No se admiten intervalos de desencadenador basados en tiempo. Para más información sobre los desencadenadores, ejemplos de código y alternativas admitidos para el streaming continuo, consulte la sección streaming de la guía de migración.

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, la federación de Lakehouse permite consultar bases de datos externas directamente desde Azure Databricks sin necesidad de 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 receptor como destino de escritura directa desde un proceso 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 obtener información sobre los clientes admitidos y los pasos de configuración, consulte Acceder a las 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