Compartir a través de

Procedimientos recomendados para la optimización de costos

  • Artículo

En este artículo se tratan los procedimientos recomendados que respaldan los principios de optimización de costos, organizados por principio.

1. Elegir recursos óptimos

Uso de formatos de datos optimizados para rendimiento

Para sacar el máximo partido a Databricks Data Intelligence Platform, debe usar Delta Lake como marco de almacenamiento. Ayuda a crear canalizaciones de ETL más sencillas y confiables, y viene con muchas mejoras de rendimiento que pueden acelerar significativamente las cargas de trabajo en comparación con el uso de Parquet, ORC y JSON. Consulte Recomendaciones de optimización en Azure Databricks. Si la carga de trabajo también se ejecuta en un proceso de trabajo, esto se traduce directamente en un tiempo de actividad más corto de los recursos de proceso, lo que conduce a menores costos.

Uso del proceso de trabajo

Un trabajo es una manera de ejecutar código no interactivo en una instancia de proceso de Databricks. Por ejemplo, puede ejecutar una carga de trabajo de extracción, transformación y carga (ETL) de forma interactiva o programada. Claro, también puede ejecutar trabajos de forma interactiva en la interfaz de usuario del cuaderno. Sin embargo, en los clústeres de trabajos, las cargas de trabajo no interactivas costarán significativamente menos que en clústeres de uso completo. Consulte la información general de los precios para comparar Proceso de trabajos y Proceso multiuso.

Una ventaja adicional para algunos trabajos es que cada trabajo o flujo de trabajo se puede ejecutar en una nueva instancia de proceso, aislando las cargas de trabajo entre sí. Sin embargo, los flujos de trabajo de varias tareas también pueden reutilizar los recursos de proceso para todas las tareas, por lo que el tiempo de inicio del proceso solo se produce una vez por flujo de trabajo. Consulte Configure compute for jobs (Configuración del proceso de trabajos).

Uso de Almacén de SQL para cargas de trabajo de SQL

En el caso de las cargas de trabajo de SQL interactivas, el almacén de Databricks SQL es el motor más rentable. Consulte la información general de los precios. Todos los almacenes SQL incluyen Photon de forma predeterminada, lo que acelera las llamadas a la API de SQL y DataFrame existentes y reduce el costo total por carga de trabajo.

Además, los almacenes SQL sin servidor son compatibles con la administración inteligente de la carga de trabajo (IWM), un conjunto de características que mejora la capacidad de Databricks SQL sin servidor para procesar un gran número de consultas de forma rápida y rentable.

Uso de entornos de ejecución actualizados para las cargas de trabajo

La plataforma Azure Databricks proporciona diferentes entornos de ejecución optimizados para tareas de ingeniería de datos (Databricks Runtime) o de aprendizaje automático (Databricks Runtime para Machine Learning). Los entornos de ejecución se compilan para proporcionar la mejor selección de bibliotecas para las tareas, y para asegurar que todas las bibliotecas proporcionadas están actualizadas y funcionan juntas de forma óptima. Los entornos de ejecución de Databricks se publican con una cadencia regular, lo que proporciona mejoras de rendimiento entre las versiones principales. Estas mejoras de rendimiento suelen dar lugar a ahorros de costos debido al uso más eficaz de los recursos de proceso.

Usar solo GPU para las cargas de trabajo adecuadas

Las máquinas virtuales con GPU pueden acelerar considerablemente los cálculos para el aprendizaje profundo, pero son significativamente más caras que las máquinas solo de CPU. Use instancias de GPU solo para cargas de trabajo que tengan bibliotecas aceleradas por GPU.

La mayoría de las cargas de trabajo que no usan bibliotecas aceleradas por GPU no se benefician de las instancias habilitadas para GPU. Los administradores del área de trabajo pueden restringir las máquinas de GPU y los recursos de proceso para evitar el uso innecesario. Consulte la entrada de blog "¿Las GPU son realmente costosas? Pruebas comparativas de GPU para inferencia en clústeres de Databricks".

Uso de servicios sin servidor para las cargas de trabajo

Casos de uso de BI

Las cargas de trabajo de BI suelen consumir datos en ráfagas y generar varias consultas simultáneas. Por ejemplo, alguien que use una herramienta de BI podría actualizar un panel o escribir una consulta y, a continuación, simplemente analizar los resultados sin interactuar con la plataforma. En este escenario, la plataforma de datos:

  • Finaliza los recursos de proceso inactivos para ahorrar costos.
  • Proporciona rápidamente los recursos de proceso cuando el usuario solicita datos nuevos o actualizados con la herramienta de BI.

Los almacenes SQL de Azure Databricks sin servidor tienen un tiempo de inicio de minutos, por lo que muchos usuarios tienden a aceptar el mayor costo y no los finalizan durante períodos de inactividad. Por otro lado, los almacenes SQL sin servidor se inician y escalan en segundos, por lo que se puede conseguir tanto una disponibilidad instantánea como una terminación en reposo. Esto da como resultado una excelente experiencia del usuario y un ahorro general de costos.

Además, los almacenes SQL sin servidor se reducen verticalmente antes que los almacenes sin servidor, de nuevo, lo que da lugar a costos más bajos.

Servicio de modelos de aprendizaje automático e inteligencia artificial

La mayoría de los modelos se sirven como una API de REST para su integración en su aplicación web o de cliente; el servicio que sirve los modelos recibe cargas variables de solicitudes a lo largo del tiempo, y una plataforma que sirve modelos debería proporcionar siempre recursos suficientes, pero solo los que realmente se necesitan (ampliación y reducción).

Mosaic AI Model Serving usa un proceso sin servidor y proporciona un servicio de alta disponibilidad y baja latencia para implementar modelos. El servicio se escala o reduce verticalmente automáticamente para satisfacer los cambios en la demanda, lo que reduce los costos de infraestructura al optimizar el rendimiento de la latencia.

Uso del tipo de instancia correcto

El uso de la última generación de tipos de instancias en la nube casi siempre proporciona ventajas de rendimiento, ya que ofrecen el mejor rendimiento y las características más recientes.

En función de las cargas de trabajo, también es importante elegir la familia de instancias adecuada para obtener la mejor relación entre rendimiento y precio. Algunas reglas simples son:

  • Optimizada para memoria para cargas de trabajo de ML, orden aleatorio intensivo y desbordamiento
  • Optimizado para proceso para cargas de trabajo de streaming estructurado y trabajos de mantenimiento (como optimización y vaciado)
  • Optimizada para almacenamiento para cargas de trabajo que se benefician del almacenamiento en caché, como el análisis de datos ad hoc e interactivo
  • GPU optimizada para cargas de trabajo específicas de ML y DL
  • Uso general en ausencia de requisitos específicos

Elección del tamaño de proceso más eficaz

Azure Databricks ejecuta un ejecutor por cada nodo de trabajo. Por lo tanto, los términos ejecutor y nodo de trabajo se usan indistintamente en el contexto de la arquitectura de Azure Databricks. Las personas suelen pensar en el tamaño del clúster en términos del número de nodos de trabajo, pero hay otros factores importantes que se deben tener en cuenta:

  • Totalidad de núcleos de ejecutores (proceso): número total de núcleos en todos los ejecutores. Esto determina el paralelismo máximo de una instancia de proceso.
  • Memoria total de los ejecutores: cantidad total de RAM en todos los ejecutores. Determina cuántos datos se pueden almacenar en la memoria antes de volcarlos en el disco.
  • Almacenamiento local del ejecutor: el tipo y la cantidad de almacenamiento en el disco local. El disco local se usa principalmente en el caso de desbordamientos durante los ordenes aleatorios y el almacenamiento en caché.

Entre las consideraciones adicionales se incluyen el tamaño y el tipo de instancia de trabajo, que también influyen en los factores anteriores. Al cambiar el tamaño del proceso, tenga en cuenta lo siguiente:

  • ¿Cuántos datos consumirá la carga de trabajo?
  • ¿Cuál es la complejidad computacional de la carga de trabajo?
  • ¿Desde dónde se leen los datos?
  • ¿Cómo se realiza la partición de los datos en el almacenamiento externo?
  • ¿Cuánto paralelismo se necesita?

Puede encontrar detalles y ejemplos en Consideraciones de ajuste de tamaño de proceso.

Evaluación de los motores de consultas optimizados para el rendimiento

Photon es un motor de consultas vectorizado nativo de Databricks de alto rendimiento que acelera las cargas de trabajo de SQL y las llamadas a la API DataFrame (para la ingesta de datos, ETL, streaming, ciencia de datos y consultas interactivas). Photon es compatible con las API de Apache Spark, por lo que para empezar solo basta activarlo, sin cambios en el código y sin bloqueos.

La velocidad observada puede dar lugar a un ahorro significativo de costos, y los trabajos que se ejecutan regularmente deben evaluarse para ver si no solo son más rápidos, sino también más baratos con Photon.

2. Asignar recursos dinámicamente

Uso del proceso de escalado automático

Con el escalado automático, Databricks reasigna de forma dinámica los trabajos para que tengan en cuenta las características de su trabajo. Algunas partes de la canalización pueden ser más exigentes computacionalmente que otras, y Databricks agrega automáticamente trabajos adicionales durante estas fases del trabajo (y los quita cuando ya no son necesarios). El escalado automático puede reducir los costos generales en comparación con una instancia de proceso de tamaño estático.

El escalado automático de proceso tiene limitaciones al reducir verticalmente el tamaño del clúster para cargas de trabajo de streaming estructurado. Databricks recomienda usar Delta Live Tables con escalado automático mejorado para cargas de trabajo de streaming.

Uso de la finalización automática

Azure Databricks proporciona una serie de características para ayudar a controlar los costos al reducir los recursos inactivos y controlar cuándo se pueden implementar los recursos de proceso.

  • Configure la terminación automática para todos los recursos de proceso interactivos. Después de un tiempo de inactividad especificado, el recurso de proceso se cierra. Finalización automática.
  • En los casos de uso en los que el proceso solo es necesario durante el horario comercial, los recursos de proceso se pueden configurar con terminación automática y un proceso programado puede reiniciar el proceso (y, posiblemente, preconfigurar los datos si es necesario) por la mañana antes de que los usuarios vuelvan a sus escritorios. Consulte CACHE SELECT.
  • Si los tiempos de inicio de los procesos son demasiado largos, considere la posibilidad de usar agrupaciones de clústeres, consulte Procedimientos recomendados para agrupaciones. Los grupos de Azure Databricks son un conjunto de instancias inactivas y listas para usar. Cuando se crean nodos de clúster mediante las instancias inactivas, se reducen los tiempos de inicio y escalado automático del clúster. Si los grupos no tienen instancias inactivas, los grupos se expanden asignando una nueva instancia del proveedor de instancias para poder atender la solicitud del clúster.

Azure Databricks no cobra Unidades de Databricks (DBU) mientras las instancias están inactivas en el grupo, lo que supone un ahorro de costes. Tiene validez la facturación del proveedor de instancias.

Uso de directivas de proceso para controlar los costos

Las directivas de proceso pueden aplicar muchas restricciones específicas del costo para los recursos de proceso. Consulte Excelencia operativa: uso de directivas de proceso. Por ejemplo:

3. Supervisar y controlar los costos

Supervisión de costos

Use Azure Cost Manager para analizar los costos de Azure Databricks. Las etiquetas de proceso y área de trabajo también se entregan a Azure Cost Manager. Consulte Etiquetado de clústeres para la atribución de costos.

Etiquetado de clústeres para la atribución de costos

Para supervisar los costos en general y atribuir con precisión el uso de Azure Databricks a las unidades de negocio y equipos de su organización a efectos de devolución de cargos, puede etiquetar clústeres, almacenes SQL y grupos. Estas etiquetas se propagan a las Unidades de Databricks (DBU) detalladas y a la utilización de las máquinas virtuales y el almacenamiento en blob del proveedor de la nube para el análisis de costos.

Asegúrese de que el control de costes y la atribución se tienen en cuenta a la hora de establecer las áreas de trabajo y los clústeres para los equipos y los casos de uso. Esto simplifica el etiquetado y mejora la precisión de las atribuciones de costos.

Los costes totales incluyen la máquina virtual de DBU, el disco y cualquier coste de red asociado. En el caso de los almacenes SQL sin servidor, el costo de DBU ya incluye los costos de disco y máquina virtual.

Las etiquetas de los recursos de Azure Databricks pueden usarse en las herramientas de análisis de costos de Azure Portal

Implementación de la observabilidad para realizar el seguimiento y el costo de contracargo

Cuando se trabaja con ecosistemas técnicos complejos, la comprensión proactiva de las incógnitas es clave para mantener la estabilidad de la plataforma y controlar los costos. La observabilidad proporciona una manera de analizar y optimizar sistemas en función de los datos que generan. Esto es diferente de la supervisión, que se centra en identificar nuevos patrones en lugar de realizar un seguimiento de problemas conocidos.

Databricks proporciona grandes capacidades de observabilidad usando Tablas del sistema que son almacenes analíticos alojados en Databricks de los datos operativos de una cuenta de cliente que se encuentran en el catálogo del sistema. Proporcionan observabilidad histórica en toda la cuenta e incluyen información tabular fácil de usar sobre la telemetría de la plataforma.

Consulte Blog: Equilibrio inteligente de optimización de costos y confiabilidad en Databricks

Compartir informes de costos con regularidad

Genere informes de costos mensuales para realizar un seguimiento del crecimiento del consumo y las anomalías. Comparta estos informes por casos de uso o equipos con los equipos que poseen las cargas de trabajo usando etiquetado de clústeres. Esto elimina las sorpresas y permite a los equipos ajustar proactivamente sus cargas de trabajo si los costos se vuelven demasiado altos.

Supervisión y administración de los costos de salida de Delta Sharing

A diferencia de otras plataformas de uso compartido de datos, Delta Sharing no requiere replicación de datos. Este modelo tiene muchas ventajas, pero significa que el proveedor de la nube puede cobrar tarifas de salida de datos al compartir datos entre nubes o regiones. Consulte Supervisión y administración de los costos de salida de Delta Sharing (para proveedores) para supervisar y administrar los costos de salida.

4. Diseño de cargas de trabajo rentables

Equilibrio de streaming siempre activado y desencadenado

Tradicionalmente, cuando las personas piensan en streaming, los términos como "en tiempo real", "24/7" o "siempre activados" vienen a la mente. Si la ingesta de datos se produce en tiempo real, los recursos de proceso subyacentes deben ejecutarse 24/7, incurriendo en costos cada hora del día.

Sin embargo, no todos los casos de uso que se basan en un flujo continuo de eventos requieren que esos eventos se agreguen inmediatamente al conjunto de datos de análisis. Si el requisito empresarial del caso de uso solo requiere datos nuevos cada pocas horas o cada día, ese requisito se puede cumplir con solo unas pocas ejecuciones al día, lo que da lugar a una reducción significativa del costo de la carga de trabajo. Databricks recomienda usar Structured Streaming con el desencadenador AvailableNow para cargas de trabajo incrementales que no tengan requisitos de baja latencia. Consulte Configuración del procesamiento por lotes incremental.

Equilibrio entre instancias de exceso de capacidad y a petición

Las instancias de acceso puntual aprovechan el exceso de recursos de máquinas virtuales en la nube que están disponibles a un precio más bajo. Para ahorrar costos, Azure Databricks admite la creación de clústeres mediante instancias de acceso puntual. Databricks recomienda que la primera instancia (el controlador de Spark) sea siempre una máquina virtual a petición. Las instancias de acceso puntual son una buena opción para cargas de trabajo en las que es aceptable tardar más porque una o más instancias de acceso puntual han sido desalojadas por el proveedor de la nube.