Procedimientos recomendados de eficiencia de rendimiento

En este artículo se tratan los procedimientos recomendados para la eficiencia de rendimiento organizados por principios de arquitectura enumerados en las secciones siguientes.

1. Escalado vertical, escalado horizontal y escalabilidad lineal

Antes de entrar en los procedimientos recomendados, veamos algunos conceptos de computación distribuida: escalado horizontal, escalado vertical y escalabilidad lineal.

• Escalado vertical: escale verticalmente mediante la adición o eliminación de recursos de una sola máquina, normalmente CPU, memoria o GPU. Por lo general, esto implica detener la carga de trabajo, moverla a una máquina más grande y volver a reiniciarla. Hay límites para el escalado vertical: puede que no haya una máquina más grande o que el precio de la siguiente máquina más grande sea prohibitivo.
• Escalado horizontal: escale horizontalmente mediante la adición o eliminación de nodos de un sistema distribuido. Cuando se alcanzan los límites de escalado vertical, la solución consiste en escalar horizontalmente: la computación distribuida usa sistemas con varias máquinas (denominadas clústeres) para ejecutar cargas de trabajo. Es importante comprender que, para que esto sea posible, las cargas de trabajo deben estar preparadas para la ejecución en paralelo, tal y como admiten los motores de la plataforma Data Intelligence de Databricks, Apache Spark y Photon. Esto permite combinar varias máquinas de bajo coste en un sistema informático mayor. Si se necesitan más recursos de proceso, el escalado horizontal agrega más nodos al clúster y los quita cuando ya no son necesarios. Aunque técnicamente no hay ningún límite (y el motor Spark se encarga de la parte compleja del equilibrio de carga), un gran número de nodos aumenta la complejidad de la gestión.
• Escalabilidad lineal, lo que significa que cuando se agregan más recursos a un sistema, la relación entre el rendimiento y los recursos usados es lineal. Esto solo es posible si las tareas paralelas son independientes. Si no es así, se necesitarán los resultados intermedios de un conjunto de nodos en otro conjunto de nodos del clúster para continuar con el cálculo. Este intercambio de datos entre nodos implica transportar los resultados a través de la red desde un conjunto de nodos a otro conjunto de nodos, lo que tarda mucho tiempo. En general, la computación distribuida tiene cierta sobrecarga para administrar la distribución y el intercambio de datos. Como resultado, las cargas de trabajo de conjuntos de datos pequeños que se pueden analizar en un único nodo pueden ser aún más lentas si se ejecutan en un sistema distribuido. La plataforma Data Intelligence de Databricks proporciona computación flexible (nodo único y distribuida) para satisfacer las necesidades específicas de las cargas de trabajo.

2. Usar arquitecturas sin servidor

Usar proceso sin servidor

Con el proceso sin servidor en la plataforma Data Intelligence de Databricks, la capa de proceso se ejecuta en la cuenta de Azure Databricks del cliente. Databricks administra y mejora continuamente estos servicios. Además de que los clientes solo pagan por lo que utilizan, esto redunda en una mejora de la productividad:

• Los administradores de la nube ya no necesitan administrar entornos de nube complejos, como ajustar cuotas, crear y mantener recursos de red y conectar orígenes de facturación. Pueden centrar su tiempo en proyectos de mayor valor en lugar de administrar componentes de nube de bajo nivel.
• Los usuarios se benefician de la latencia de inicio del clúster casi cero y de la simultaneidad de consultas mejorada.

Databricks proporciona servicios administrados para diferentes cargas de trabajo:

• Almacenes de SQL sin servidor para cargas de trabajo de SQL

  Los administradores del área de trabajo pueden crear almacenes de SQL sin servidor que permiten un proceso instantáneo y son administrados por Azure Databricks. Úselos con consultas de Databricks SQL tal como haría normalmente con los almacenes de SQL originales de Databricks. El proceso sin servidor tiene un tiempo de inicio muy rápido para los almacenes SQL y Databricks administra y optimiza la infraestructura.

• Flujos de trabajo sin servidor para flujos de trabajo eficaces y confiables

  El proceso sin servidor para flujos de trabajo permite ejecutar el trabajo de Databricks sin configurar e implementar la infraestructura. Con el proceso sin servidor, se centra en implementar las canalizaciones de procesamiento de datos y análisis, y Databricks administra eficazmente los recursos de proceso, incluida la optimización y el escalado del proceso para las cargas de trabajo. El escalado automático y Photon se habilitan automáticamente para los recursos de proceso que ejecutan el trabajo.

  Puede supervisar el costo de los trabajos que usan el proceso sin servidor para los flujos de trabajo consultando la tabla del sistema de uso facturable.

• Proceso sin servidor para cuadernos

  Si el área de trabajo está habilitada para el proceso interactivo sin servidor, todos los usuarios del área de trabajo tienen acceso al proceso sin servidor para cuadernos. No se requieren permisos adicionales.

Uso de un servicio de Model Serving de nivel empresarial

Mosaic AI Model Serving proporciona una interfaz unificada para desplegar, gobernar y consultar modelos de IA. Cada modelo que sirva está disponible como una API de REST que puede integrar en la aplicación web o cliente.

Model Serving 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 de demanda, lo que ahorra costos de infraestructura al optimizar el rendimiento de la latencia. Esta funcionalidad usa un proceso sin servidor.

3. Diseñar cargas de trabajo para el rendimiento

Comprender los patrones de ingesta y acceso de datos

Desde una perspectiva de rendimiento, los patrones de acceso a los datos, como "agregaciones frente al acceso a puntos" o "examen frente a búsqueda", se comportan de forma diferente en función del tamaño de los datos. Los archivos grandes son más eficaces para las consultas de examen, mientras que los archivos pequeños son mejores para la búsqueda, ya que hay que leer menos datos para encontrar filas específicas.

En el caso de los patrones de ingesta, es habitual usar instrucciones DML. Las instrucciones DML son más eficaces cuando los datos están agrupados, por lo que basta con aislar la sección de datos. Es importante mantener los datos agrupados y aislables en el momento de la ingesta: considere la posibilidad de mantener un criterio de ordenación en tiempo natural y aplique tantos filtros como sea posible a la tabla de destino de la ingesta. En el caso de las cargas de trabajo de ingesta de solo anexión y sobrescritura, no hay mucho que tener en cuenta, ya que se trata de una operación relativamente barata.

Los patrones de ingesta y acceso suelen apuntar a una agrupación en clústeres y un diseño de datos obvios. Si no es así, decida qué es más importante para su empresa y concéntrese en cómo alcanzar mejor ese objetivo.

Usar el cálculo paralelo cuando sea beneficioso

El tiempo para obtener valor es una dimensión importante al trabajar con datos. Mientras que muchos casos de uso pueden implementarse fácilmente en una sola máquina (datos pequeños, pocos y sencillos pasos computacionales), a menudo hay casos de uso que necesitan procesar grandes conjuntos de datos, tienen tiempos de ejecución largos debido a algoritmos complicados o necesitan repetirse cientos y miles de veces.

El entorno de clúster de la plataforma de Databricks es excelente para distribuir estas cargas de trabajo de forma eficaz. Realiza en paralelo automáticamente las consultas SQL en todos los nodos de un clúster y proporciona bibliotecas para Python y Scala para hacer lo mismo. En segundo plano, los motores de Apache Spark y Photon analizan las consultas, determinan la manera óptima de realizar la ejecución paralela y administran la ejecución distribuida de manera resistente.

De la misma manera que con las tareas por lotes, Structured Streaming distribuye los trabajos de streaming en el clúster para obtener el mejor rendimiento.

Una de las formas más fáciles de usar la computación en paralelo es con Delta Live Tables. Las tareas y dependencias de un trabajo se declaran en SQL o Python y, a continuación, Delta Live Tables se encarga del planeamiento de la ejecución, la configuración eficaz de la infraestructura, la ejecución del trabajo y la supervisión.

Para los científicos de datos, Pandas es un paquete de Python que proporciona estructuras de datos fáciles de usar y herramientas de análisis de datos para el lenguaje de programación Python. Sin embargo, Pandas no se escala horizontalmente a macrodatos. La API de Pandas en Spark subsana esta carencia, ya que proporciona API equivalentes a Pandas que funcionan en Apache Spark.

Además, la plataforma incluye algoritmos de aprendizaje automático en paralelo en la biblioteca de aprendizaje automático estándar MLlib. Admite el uso de varias GPU integradas. El aprendizaje profundo también se puede paralelizar mediante Horovod Runner, DeepSpeed Distributor o TorchDistributor.

Analizar toda la cadena de ejecución

La mayoría de las canalizaciones o patrones de consumo usan una cadena de sistemas. Por ejemplo, en el caso de las herramientas de BI, el rendimiento se ve afectado por varios factores:

• La propia herramienta de BI.
• El conector que conecta la herramienta de BI y el motor de SQL.
• El motor de SQL donde la herramienta de BI envía la consulta.

Para lograr el mejor rendimiento posible, se debe tener en cuenta toda la cadena y seleccionarla/ajustarla para obtener el mejor rendimiento.

Dar preferencia a los clústeres más grandes

Planee clústeres más grandes, especialmente cuando la carga de trabajo se escale linealmente. En este caso, el uso de un clúster grande para una carga de trabajo no es más caro que usar un clúster más pequeño. Es simplemente más rápido. Lo importante es que el clúster se alquila por la duración de la carga de trabajo. Por lo tanto, si pone en marcha dos clústeres de trabajo y emplea una hora, pagará por esos trabajos la hora completa. De forma similar, si pone en marcha un clúster de cuatro trabajos y solo tarda media hora (aquí es donde entra en juego la escalabilidad lineal), los costos son los mismos. Si los costos son el controlador principal con un Acuerdo de Nivel de Servicio muy flexible, un clúster de escalado automático casi suele ser la opción más barata, pero no necesariamente la más rápida.

Nota:

No es necesario preferir clústeres grandes para el proceso sin servidor porque administra automáticamente los clústeres.

Usar operaciones nativas de Spark

Las funciones definidas por el usuario (UDF) son una excelente manera de ampliar la funcionalidad de Spark SQL. Sin embargo, no use las UDF de Python o Scala si existe una función nativa:

• Spark SQL
• PySpark

Motivos:

• Para transferir datos entre Python y Spark, es necesaria la serialización. Esto ralentiza significativamente las consultas.
• Mayor esfuerzo para implementar y probar la funcionalidad que ya existe en la plataforma.

Si faltan funciones nativas y deben implementarse como UDF de Python, use las UDF de Pandas. Apache Arrow garantiza que los datos se muevan de forma eficaz entre Spark y Python.

Uso de motores de plataforma nativa

Photon es el motor de Azure Databricks que proporciona un rendimiento de consultas extremadamente rápido a bajo costo, desde la ingesta de datos, ETL, streaming, ciencia de datos y consultas interactivas directamente en el lago de datos. 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.

Photon forma parte de un entorno de ejecución de alto rendimiento que ejecuta las llamadas API SQL y DataFrame existentes más rápidamente, reduciendo el coste total por carga de trabajo. Photon se utiliza por defecto en los almacenes SQL de Databricks.

Comprensión del hardware y el tipo de carga de trabajo

No todas las máquinas virtuales en la nube se crean igualmente. Las diversas familias de máquinas que ofrecen los proveedores de nube son lo suficientemente diferentes como para tenerlo en cuenta. Existen diferencias obvias, como la RAM y los núcleos, y diferencias más sutiles, como el tipo y la generación de procesadores, las garantías de ancho de banda de red y el almacenamiento de alta velocidad local frente a disco remoto. También hay diferencias en los mercados de acceso puntual. Es necesario saber todo esto antes de decidir el mejor tipo de máquina virtual para la carga de trabajo.

Nota:

Esto no es necesario para el proceso sin servidor porque el proceso sin servidor administra automáticamente los clústeres.

Usar el almacenamiento en caché

El almacenamiento en caché almacena los datos a los que se accede con frecuencia en un medio más rápido, lo que reduce el tiempo necesario para recuperarlos en comparación con el acceso al origen de datos original. Esto produce una menor latencia y tiempos de respuesta más rápidos, lo que puede mejorar significativamente el rendimiento general de una aplicación y la experiencia del usuario. Al minimizar el número de solicitudes al origen de datos original, el almacenamiento en caché ayuda a reducir el tráfico de red y los costos de transferencia de datos. Esta ganancia de eficiencia puede ser especialmente beneficiosa para las aplicaciones que dependen de API externas o bases de datos de pago por uso. Puede ayudar a distribuir la carga de forma más uniforme en todo el sistema, lo que evita cuellos de botella y un posible tiempo de inactividad.

Hay varios tipos de almacenamiento en caché disponibles en Azure Databricks. Estas son las características de cada tipo:

• Uso de caché de disco

  La caché de disco (anteriormente conocida como "caché Delta") almacena copias de datos remotos en los discos locales (por ejemplo, SSD) de las máquinas virtuales. Puede mejorar el rendimiento de una amplia gama de consultas, pero no se puede usar para almacenar resultados de subconsultas arbitrarias. La caché de disco detecta automáticamente cuándo se crean o eliminan archivos de datos y actualiza su contenido en consecuencia. La manera recomendada (y más sencilla) de usar el almacenamiento en caché de disco es elegir un tipo de trabajo con volúmenes SSD al configurar el clúster. Estos trabajados se habilitan y se configuran para el almacenamiento en caché de disco.

• Evitar el almacenamiento en caché de Spark

  La caché de Spark, mediante el uso de .persist() y .unpersist(), puede almacenar el resultado de cualquier dato de subconsultas y datos almacenados en formatos distintos de Parquet (como CSV, JSON y ORC). Sin embargo, si se usa en las ubicaciones incorrectas de una consulta, puede consumir toda la memoria e incluso ralentizar las consultas significativamente. Como regla general, evite el almacenamiento en caché de Spark a menos que sepa exactamente el impacto.

• Caché de resultados de consulta

  Almacenamiento en caché de los resultados de consulta por clúster para todas las consultas mediante almacenes de SQL. Para beneficiarse del almacenamiento en caché de resultados de la consulta, céntrese en consultas deterministas que, por ejemplo, no usen predicados como = NOW(). Cuando una consulta es determinista y los datos subyacentes están en formato Delta y sin cambios, los almacenes de SQL devolverán el resultado directamente desde la caché de resultados de la consulta.

• Almacenamiento en caché de la interfaz de usuario de SQL de Databricks

  El almacenamiento en caché por usuario de todos los resultados de las consultas y del panel heredado da como resultado la IU de SQL de Databricks.

Usar la compactación

Delta Lake de Azure Databricks puede mejorar la velocidad de las consultas de lectura de una tabla. Una manera es fusionar archivos pequeños en archivos más grandes. Para desencadenar la compactación, ejecute el comando OPTIMIZE. Consulte Optimización del diseño del archivo de datos.

Delta Lake proporciona opciones para configurar automáticamente el tamaño del archivo de destino para las escrituras y para las operaciones OPTIMIZE. Databricks ajusta automáticamente muchas de estas opciones de configuración y habilita características que mejoran automáticamente el rendimiento de las tablas mediante la búsqueda de archivos de tamaño correcto:

• La compactación automática combina archivos pequeños dentro de las particiones de tabla Delta para reducir automáticamente los problemas de archivos pequeños. La compactación automática se produce después de que una escritura en una tabla se haya realizado correctamente y se ejecute sincrónicamente en el clúster que ha realizado la escritura. La compactación automática solo compacta los archivos que no se han compactado anteriormente.
• Las escrituras optimizadas mejoran el tamaño de archivo a medida que se escriben los datos y benefician las lecturas posteriores en la tabla. Las escrituras optimizadas son más eficaces para las tablas con particiones, ya que reducen el número de archivos pequeños escritos en cada partición.

Para obtener más información, consulte Configuración de Delta Lake para controlar el tamaño del archivo de datos.

Usar la omisión de datos

La omisión de datos puede mejorar significativamente el rendimiento de las consultas omitiendo los datos que no cumplen los criterios de consulta. Esto reduce la cantidad de datos que hay que leer y procesar, lo que acelera la ejecución de las consultas.

Para ello, la información de omisión de datos se recopila automáticamente al escribir datos en una tabla Delta (de forma predeterminada, Delta Lake de Azure Databricks recopila estadísticas en las primeras 32 columnas definidas en el esquema de tabla). Delta Lake en Azure Databricks usa esta información (valores mínimos y máximos) en tiempo de consulta para ofrecer consultas más rápidas. Consulte Omisión de datos para Delta Lake.

Para obtener los mejores resultados, use la ordenación Z, una técnica para colocar información relacionada en el mismo conjunto de archivos. Los algoritmos de omisión de datos de Delta Lake de Azure Databricks usan esta coubicación automáticamente. Este comportamiento reduce significativamente la cantidad de datos que debe leer Delta Lake.

O bien, use la agrupación en clústeres líquidos más reciente, que simplifica las decisiones de diseño de datos y optimiza el rendimiento de las consultas. Reemplazará la creación de particiones y la ordenación Z con el tiempo. Databricks recomienda la agrupación en clústeres líquidos para todas las tablas Delta nuevas. La agrupación en clústeres líquidos proporciona flexibilidad para redefinir las claves de agrupación en clústeres sin tener que volver a escribir los datos existentes, lo que permite que el diseño de los datos evolucione junto con las necesidades analíticas a lo largo del tiempo. Databricks recomienda la agrupación en clústeres líquidos para todas las tablas Delta nuevas.

Las tablas con las siguientes características se benefician de la agrupación en clústeres líquidos:

• Filtrado por columnas con cardinalidad alta.
• Con una distribución de datos sesgada significativamente.
• Que crecen rápidamente y requieren un trabajo de mantenimiento y ajuste.
• Con solicitudes de escritura simultáneas.
• Con patrones de acceso que cambian con el tiempo.
• Donde una clave de partición típica podría dejar la tabla con demasiadas particiones o muy pocas.

Para más información y técnicas, consulte la Guía completa para optimizar las cargas de trabajo de Databricks, Spark y Delta Lake.

Habilitación de la optimización predictiva de para Delta Lake

La optimización predictiva elimina la necesidad de administrar manualmente las operaciones de mantenimiento de las tablas Delta en Databricks. Con la optimización predictiva habilitada, Databricks identifica automáticamente las tablas que se beneficiarían de las operaciones de mantenimiento y las ejecuta por el usuario. Las operaciones de mantenimiento solo se ejecutan según es necesario, lo que elimina las ejecuciones innecesarias de operaciones de mantenimiento y la carga asociada al seguimiento y la solución de problemas de rendimiento.

Evitar un exceso de particiones

En el pasado, la creación de particiones era la manera más común de omitir los datos. Sin embargo, la creación de particiones es estática y se manifiesta como una jerarquía del sistema de archivos. No hay ninguna manera fácil de cambiar las particiones si los patrones de acceso cambian con el tiempo. A menudo, la creación de particiones conduce a la creación de particiones excesivas, es decir, demasiadas particiones con archivos demasiado pequeños, lo que da lugar a un rendimiento deficiente de las consultas.

Databricks recomienda que no cree particiones de tablas por debajo de 1 TB de tamaño y que solo cree particiones por una columna si espera que los datos de cada partición tengan al menos 1 GB.

Mientras tanto, una mejor opción que la creación de particiones es la ordenación Z o la nueva agrupación en clústeres líquidos (consulte más arriba).

Optimización del rendimiento de las combinaciones

• Considere la optimización de la combinación de intervalos.

  Una combinación de intervalos se produce cuando se unen dos relaciones mediante una condición de intervalo de punto o de superposición de intervalos. La compatibilidad con la optimización de la combinación de intervalos de Databricks Runtime puede aportar una mejora de los órdenes de magnitud en el rendimiento de las consultas, pero requiere un ajuste manual preciso.

• Use la ejecución de consultas adaptables.

  La ejecución de consultas adaptables (AQE) es la reoptimización de consultas que se produce durante la ejecución de consultas. Tiene cuatro características principales:

  • Cambia dinámicamente la fusión mediante combinación de ordenación a combinación de hash de difusión.
  • Combina dinámicamente particiones después del intercambio aleatorio.
  • Controla dinámicamente la asimetría en las combinaciones de combinación de ordenación y en las combinaciones hash aleatorias.
  • Detecta y propaga dinámicamente relaciones vacías.

  Se recomienda mantener habilitado AQE. Las distintas características se pueden configurar por separado.

Para más información, consulte la guía completa para optimizar las cargas de trabajo de Databricks, Spark y Delta Lake.

Ejecutar analyze table para recopilar estadísticas de tabla

La instrucción ANALYZE TABLE recopila estadísticas sobre tablas en un esquema especificado. El optimizador de consultas usa estas estadísticas para generar un plan de consulta óptimo, seleccionar el tipo de combinación correcto, seleccionar el lado de compilación correcto en una combinación hash o calibrar el orden de combinación en varias vías.

Para aprovechar correctamente estas optimizaciones de consulta, el comando ANALYZE TABLE debe ejecutarse periódicamente (preferiblemente una vez al día o cuando los datos hayan mutado en más del 10 %, lo que ocurra primero).

4. Ejecución de pruebas de rendimiento en el ámbito del desarrollo

Realizar pruebas en datos representativos de los datos de producción

Ejecute pruebas de rendimiento en los datos de producción (solo lectura) o datos similares. Al usar datos similares, determinadas características, como el volumen, el diseño de archivos y los sesgos de datos, deben ser similares a los datos de producción, ya que esto tiene un impacto significativo en el rendimiento.

Consideración de los recursos de preparación

Independientemente del formato de la consulta y los datos, la primera consulta de un clúster siempre será más lenta que las consultas posteriores. Esto se debe a que todos los subsistemas diferentes están iniciando y leyendo todos los datos que necesitan. La preparación tiene un impacto significativo en los resultados de las pruebas de rendimiento:

• Preparación de clústeres: los recursos de clúster deben inicializarse en varias capas. Es posible preparar los clústeres: los grupos de 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.
• Preparación de memorias caché: cuando el almacenamiento en caché forma parte de la configuración, la primera ejecución garantiza que los datos estén en la memoria caché, lo que acelera los trabajos posteriores. Las memorias caché se pueden preparar mediante la ejecución de consultas específicas para inicializar cachés (por ejemplo, después de reiniciar un clúster). Esto puede mejorar significativamente el rendimiento de las primeras consultas.

Por lo tanto, para comprender el comportamiento de los diferentes escenarios, pruebe el rendimiento de la primera ejecución (con y sin preparación) y las ejecuciones posteriores.

Identificar los cuellos de botella

Los cuellos de botella son áreas de la carga de trabajo que pueden empeorar el rendimiento general cuando aumenta la carga en producción. Identificarlos en tiempo de diseño y probarlos con cargas de trabajo más altas permitirá mantener las cargas de trabajo estables en producción.

5. Supervisión del rendimiento

Supervisión del rendimiento de las consultas

La supervisión del rendimiento de las consultas le ayuda a comprender cómo se usan los recursos por diferentes consultas. Puede identificar consultas que se ejecutan lentamente, lo que le permite identificar cuellos de botella de rendimiento en el sistema. También puede identificar consultas que consumen recursos significativos del sistema, lo que puede provocar inestabilidad o tiempo de inactividad. Esta información le ayuda a optimizar la asignación de recursos, reducir los residuos y asegurarse de que los recursos se usan de forma eficaz.

La plataforma Data Intelligence de Databricks tiene varias funcionalidades de supervisión (consulte Excelencia operativa: configuración de supervisión, alertas y registro), algunas de las cuales se pueden usar para la supervisión del rendimiento:

• Perfilde consulta: use la característica de perfil de consulta para solucionar problemas de cuellos de botella de rendimiento durante la ejecución de la consulta. Proporciona visualización de cada tarea de consulta y métricas relacionadas, como el tiempo invertido, el número de filas procesadas y la memoria empleada.
• Supervisión de almacén de SQL: supervise los almacenes de SQL mediante la visualización de estadísticas dinámicas, gráficos de recuento máximo de consultas, gráficos de clústeres en ejecución y tabla de historial de consultas.

Supervisión de cargas de trabajo de streaming

La supervisión de streaming permite analizar datos y detectar problemas a medida que se producen, lo que proporciona información en tiempo real sobre el rendimiento y el comportamiento del sistema. Al analizar los datos de streaming, puede identificar tendencias, patrones y oportunidades de optimización. Esto puede ayudarle a ajustar el sistema, mejorar el uso de los recursos y reducir los costos.

En el caso de las consultas de streaming, use la supervisión de Structured Streaming integrada en la interfaz de usuario de Spark o inserte métricas en servicios externos mediante la interfaz del agente de escucha de consultas de streaming de Apache Spark.

Supervisión del rendimiento del trabajo

La supervisión del trabajo le ayuda a identificar y solucionar problemas en los trabajos de Databricks, como errores, retrasos o cuellos de botella de rendimiento. La supervisión del trabajo proporciona información sobre el rendimiento del trabajo, lo que le permite optimizar el uso de los recursos, reducir el desperdicio y mejorar la eficiencia general.