Los 5 mejores consejos de rendimiento de los bricks: cómo acelerar sus cargas de trabajo

Los 5 mejores consejos de rendimiento de los bricks: cómo acelerar sus cargas de trabajo

  • Big Data
  • marzo 10, 2022
  • No Comment
  • 43
  • 13 minutes read


Introducción

Como arquitectos de soluciones, trabajamos en estrecha colaboración con los clientes todos los días para ayudarlos a obtener el mejor rendimiento de sus trabajos en Databricks, y a menudo terminamos dando el mismo consejo. No es raro tener una conversación con un cliente y ver el doble, el triple o incluso más rendimiento con solo unos pocos ajustes. Entonces, ¿cuál es el secreto? ¿Cómo lo haremos? Estas son las 5 cosas principales que vemos que pueden tener un gran impacto en el rendimiento que los clientes obtienen de Databricks.

Aquí hay un TLDR:

  1. Usar clústeres más grandes. Puede sonar obvio, pero ese es el mayor problema que vemos. De hecho, no es más costoso usar un clúster grande para una carga de trabajo que usar uno más pequeño. Simplemente es más rápido. Si hay algo que debe sacar de este artículo, es esto: Lea la Sección 1. En serio.
  2. Utilizar Photon, el nuevo motor de ejecución súper rápido de Databricks. Lea la Sección 2 para obtener más información. No te arrepentirás.
  3. Limpia tus configuraciones. Las configuraciones transferidas de una versión de Apache Spark™ a la siguiente pueden causar problemas masivos. ¡Limpiar! Lea la Sección 3 para obtener más información.
  4. Utilizar almacenamiento en caché delta. Es muy probable que no esté utilizando el almacenamiento en caché correctamente, si es que lo está haciendo. Consulte la Sección 4 para obtener más información.
  5. Tenga en cuenta la revisión perezosa. Si esto no significa nada para usted y está escribiendo código Spark, vaya a la sección 5.
  6. ¡Consejo de bonificación! El diseño de la mesa es súper importante. Cubriremos eso en un blog futuro, pero por ahora, consulte la Guía de mejores prácticas de Delta Lake.

1. ¡Dale potencia a tus clústeres!

Este es el error número uno que cometen los clientes. Muchos clientes crean pequeños grupos de dos trabajadores, cada uno con cuatro núcleos, y se tarda una eternidad en hacer cualquier cosa. La preocupación es siempre la misma: no desea gastar demasiado dinero en clústeres más grandes. Aquí está la cosa: En realidad, no es más costoso usar un clúster grande para una carga de trabajo que uno más pequeño. es mas rapido.

La clave es que alquila el clúster durante la duración de la carga de trabajo. Entonces, si activa este grupo de dos trabajadores y tarda una hora, paga por esos trabajadores por hora. Sin embargo, si configura un grupo de cuatro trabajadores y solo toma media hora, ¡el costo es en realidad el mismo! Y esta tendencia continuará mientras haya suficiente trabajo para el clúster.

Aquí hay un escenario hipotético que ilustra el punto:

Numero de trabajadores costos por hora Duración de la carga de trabajo (horas) costo de la carga de trabajo
1 $1 2 $2
2 $2 1 $2
4 $4 0.5 $2
8 $8 0.25 $2

Tenga en cuenta que el costo total de la carga de trabajo se mantiene igual, mientras que el tiempo real que se tarda en ejecutar el trabajo se reduce significativamente. Por lo tanto, aumente las especificaciones de su clúster de Databricks y acelere sus cargas de trabajo sin gastar más dinero. No puede ser más fácil.

2. Usa Fotón

Nuestros colegas ingenieros reescribieron el motor de ejecución Spark en C++ y lo llamaron Photon. ¡Los resultados son impresionantes!

Aceleración relativa en Databricks Runtime (DBR) 2.1 por versión de DBR.

Además de las mejoras obvias de ejecutar el motor en código nativo, también han aprovechado el rendimiento a nivel de CPU y una mejor gestión de la memoria. Además, reescribieron el escritor de Parquet en C++. ¡Esto hace que escribir en Parquet y Delta (basado en Parquet) también sea súper rápido!

Pero aclaremos también qué fotón acelera. Mejora la velocidad computacional para cualquier función u operación integrada, así como también escribe en Parquet o Delta. Entonces, ¿únete? ¡Sí! agregaciones? ¡Con seguridad! ETL? ¡Absolutamente! ¿Esa UDF (función definida por el usuario) que escribiste? Lo siento, pero eso no ayuda. ¿El trabajo que pasa la mayor parte de su tiempo leyendo de una base de datos local antigua? Desafortunadamente eso tampoco ayuda.

La buena noticia es que ayuda donde puede. Incluso si alguna parte de su trabajo no se puede acelerar, acelerará las otras partes. Además, la mayoría de los trabajos se escriben con las operaciones nativas y pasan mucho tiempo escribiendo en Delta y Photon ayuda mucho allí. Intentalo. ¡Te sorprenderán los resultados!

3. Limpia configuraciones antiguas

¿Conoces esas configuraciones de Spark que llevas de un lanzamiento a otro y ya nadie recuerda lo que hacen? No puedes ser inofensivo. Hemos visto trabajos reducidos de horas a minutos simplemente limpiando configuraciones antiguas. Puede haber una peculiaridad en una versión particular de Spark, un ajuste de rendimiento que no ha envejecido bien, o algo sacado de un blog en algún lugar que nunca tuvo sentido. Como mínimo, vale la pena verificar dos veces las configuraciones de Spark si se encuentra en esta situación. A menudo, las configuraciones predeterminadas son las mejores y siguen mejorando. Puede retener sus configuraciones.

4. Delta Cache es tu amigo

Esto puede parecer obvio, pero le sorprendería saber cuántas personas no usan Delta Cache, que carga datos del almacenamiento en la nube (S3, ADLS) y los almacena en los SSD de los empleados para un acceso más rápido.

Si usa Databricks SQL Endpoints, tiene suerte. Estos tienen el almacenamiento en caché habilitado de forma predeterminada. De hecho, recomendamos usar la tabla CACHE SELECT * FROM para precargar sus tablas «activas» al iniciar un punto final. Esto garantiza velocidades ultrarrápidas para todas las consultas en estas tablas.

Si usa clústeres regulares, asegúrese de usar la serie i3 en Amazon Web Services (AWS), la serie L o la serie E en Azure Databricks o n2 en GCP. Todos estos tienen SSD rápidos y almacenamiento en caché habilitado de forma predeterminada.

Por supuesto, su kilometraje puede variar. Si ejecuta BI que lee las mismas tablas una y otra vez, el almacenamiento en caché brinda un impulso increíble. Sin embargo, si solo lee una hoja de cálculo una vez y anota los resultados como algunos trabajos de ETL, es posible que no le sirva de mucho. Conoces tu trabajo mejor que nadie. Sal y conquista.

Lectura desde Cloud Storage vs. Delta Cache.

5. Tenga cuidado con la revisión perezosa

Si es un analista de datos o un científico de datos que usa solo SQL o ejecuta BI, puede omitir esta sección. Sin embargo, si se dedica a la ingeniería de datos y escribe canalizaciones o procesa con Databricks/Spark, siga leyendo.

Cuando escribe código Spark como select, groupBy, filter, etc., realmente crea un plan de ejecución. Encontrará que el código regresa casi inmediatamente cuando ejecuta estas funciones. Eso es porque en realidad no hace ningún cálculo. Incluso si tiene petabytes de datos, se devolverán en menos de un segundo.

Sin embargo, una vez que anote sus resultados, encontrará que lleva más tiempo. Esto se debe a una revisión perezosa. Solo cuando intente ver o escribir resultados, su plan de ejecución se ejecutará realmente.


—--------
# Build an execution plan.
# This returns in less than a second but does no work
df2 = (df
  .join(...)
  .select(...)
  .filter(...)
         )

# Now run the execution plan to get results
df2.display()
—------

Sin embargo, hay una trampa aquí. Cada vez que intenta ver o escribir resultados, el plan de ejecución se vuelve a ejecutar. Veamos el mismo bloque de código, pero amplíelo y realice algunas operaciones más.


—--------
# Build an execution plan.
# This returns in less than a second but does no work
df2 = (df
  .join(...)
  .select(...)
  .filter(...)
         )

# Now run the execution plan to get results
df2.display()

# Unfortunately this will run the plan again, including filtering, joining, etc
df2.display()

# So will this…
df2.count()
—------

El desarrollador de este código bien puede pensar que solo está imprimiendo los resultados tres veces, pero lo que realmente está haciendo es iniciar el mismo procesamiento tres veces. UPS. Eso es mucho trabajo extra. Este es un error muy común con el que nos encontramos. Entonces, ¿por qué hay una evaluación perezosa y qué estamos haciendo al respecto?

En resumen, el procesamiento con Lazy Evaluation es mucho más rápido que sin ella. Databricks/Spark analiza el plan de ejecución completo y encuentra oportunidades de optimización que pueden reducir el tiempo de procesamiento en órdenes de magnitud. Eso es genial, pero ¿cómo evitamos el cálculo adicional? La respuesta es bastante simple: almacene los resultados calculados que luego reutilizará.

Veamos de nuevo el mismo bloque de código, pero esta vez evitaremos el recálculo:


# Build an execution plan.
# This returns in less than a second but does no work
df2 = (df
  .join(...)
  .select(...)
  .filter(...)
         )

# save it
df2.write.save(path)

# load it back in
df3 = spark.read.load(path)

# now use it
df3.display()

# this is not doing any extra computation anymore.  No joins, filtering, etc.  It’s already done and saved.
df3.display()

# nor is this
df3.count()

Esto funciona particularmente bien cuando el almacenamiento en caché delta está habilitado. En resumen, se beneficia enormemente de la revisión perezosa, pero muchos clientes tropiezan con ella. Así que tenga en cuenta su existencia y guarde los resultados que reutilice para evitar cálculos innecesarios.

Próximo blog: ¡Diseña bien tus mesas!

Este es un tema increíblemente importante, pero necesita su propio blog. Manténganse al tanto. Mientras tanto, consulte esta guía de mejores prácticas de Delta Lake.



Related post

TD moderniza el entorno de datos con Databricks para aumentar el valor para sus clientes

TD moderniza el entorno de datos con Databricks para…

Desde 1955, la misión de TD Bank Group ha sido brindarles a los clientes y las comunidades la confianza para prosperar…
Cómo obtener el mejor rendimiento de las bases de datos Delta Lake Star Schema

Cómo obtener el mejor rendimiento de las bases de…

La mayoría de los desarrolladores de almacenes de datos están muy familiarizados con el omnipresente esquema en estrella. Un esquema en…
La división Reality Labs ahora representa el 21% de todos los empleados de Meta

La división Reality Labs ahora representa el 21% de…

Un nuevo informe de The Verge afirma que la división Reality Labs de Meta está compuesta por más de 17,000 personas.…

Leave a Reply

Tu dirección de correo electrónico no será publicada.