performance - joins - spark jdbc

¿Cómo unir grandes marcos de datos en Spark SQL?(mejores prácticas, estabilidad, rendimiento)

Question

Recibo el mismo error que Faltar una ubicación de salida para mezclar al unir grandes marcos de datos en Spark SQL. La recomendación allí es establecer MEMORY_AND_DISK y / o spark.shuffle.memoryFraction 0 . Sin embargo, spark.shuffle.memoryFraction está en desuso en Spark> = 1.6.0 y configurar MEMORY_AND_DISK no debería ser útil si no estoy almacenando en caché ningún RDD o Dataframe, ¿verdad? También obtengo muchos otros registros de WARN y reintentos de tareas que me llevan a pensar que el trabajo no es estable.

Por lo tanto, mi pregunta es:

• ¿Cuáles son las mejores prácticas para unir enormes marcos de datos en Spark SQL> = 1.6.0?

Las preguntas más específicas son:

• ¿Cómo ajustar el número de ejecutores y las particiones spark.sql.shuffle.para lograr una mejor estabilidad / rendimiento?
• ¿Cómo encontrar el equilibrio correcto entre el nivel de paralelismo (número de ejecutores / núcleos) y el número de particiones ? Descubrí que aumentar el número de ejecutores no siempre es la solución, ya que puede generar excepciones de tiempo de espera de lectura / E / S debido al tráfico de la red.
• ¿Hay algún otro parámetro relevante que se ajuste para este propósito?
• Según tengo entendido, la unión de datos almacenados como ORC o Parquet ofrece un mejor rendimiento que el texto o Avro para operaciones de unión. ¿Hay una diferencia significativa entre Parquet y ORC?
• ¿Existe una ventaja de SQLContext vs HiveContext en relación con la estabilidad / el rendimiento para las operaciones de unión?
• ¿Hay alguna diferencia con respecto al rendimiento / estabilidad cuando los marcos de datos involucrados en la combinación son previamente registerTempTable () o saveAsTable () ?

Hasta ahora estoy usando esta es la respuesta y este capítulo como punto de partida. Y hay algunas páginas de stackoverflow más relacionadas con este tema. Sin embargo, no he encontrado una respuesta completa a este popular tema.

Gracias por adelantado.

Answer 1

Eso son muchas preguntas. Permíteme responder estos uno por uno:

Su número de ejecutores es la mayor parte del tiempo variable en un entorno de producción. Esto depende de los recursos disponibles. El número de particiones es importante cuando está realizando mezclas. Suponiendo que sus datos ahora están sesgados, puede reducir la carga por tarea aumentando el número de particiones. Una tarea ideal debería tomar un par de menos. Si la tarea lleva demasiado tiempo, es posible que su contenedor se anule y el trabajo se pierda. Si la tarea solo lleva unos pocos milisegundos, la sobrecarga de comenzar la tarea se vuelve dominante.

El nivel de paralelismo y el ajuste de los tamaños de sus ejecutores, me gustaría referirme a la excelente guía de Cloudera: https://blog.cloudera.com/blog/2015/03/how-to-tune-your-apache-spark- jobs-part-2 /

ORC y Parquet solo codifican los datos en reposo. Al hacer la unión real, los datos están en el formato en memoria de Spark. El parquet se está volviendo más popular desde que Netflix y Facebook lo adoptaron y pusieron mucho esfuerzo en él. Parquet le permite almacenar datos de manera más eficiente y tiene algunas optimizaciones (pushdown de predicados) que Spark usa.

Debe usar SQLContext en lugar de HiveContext, ya que HiveContext está en desuso. El SQLContext es más general y no solo funciona con Hive.

Al realizar la función registerTempTable , los datos se almacenan dentro de SparkSession. Esto no afecta la ejecución de la unión. Lo que almacena es solo el plan de ejecución que se invoca cuando se realiza una acción (por ejemplo, saveAsTable ). Al ejecutar un saveAsTable los datos se almacenan en el sistema de archivos distribuido.

Espero que esto ayude. También sugeriría que veamos nuestra charla en Spark Summit sobre cómo hacer uniones: https://www.youtube.com/watch?v=6zg7NTw-kTQ . Esto podría proporcionarle algunas ideas.

Saludos, Fokko