Siete optimizaciones de rendimiento de SQL imprescindibles en Spark 3.0
Big Data de memoria pasada Big Data de memoria pasada
Este artículo proviene del intercambio del tema "Mejoras de rendimiento de SQL de un vistazo en Apache Spark 3.0" por el Dr. Kazuaki Ishizaki, técnico senior de IBM Tokyo Research Institute, en Spark Summit North America 2020. Para el video de este artículo, consulte el tercer artículo del tweet de hoy. PPT Preste atención al big data de la memoria pasada y responda a sparksql3 en segundo plano para obtenerlo.
La versión oficial de Spark 3.0 se lanzó el mes pasado y se han actualizado muchas funciones. La versión oficial de Apache Spark 3.0.0, que recuerda el big data en el pasado, finalmente se lanza y las características importantes se analizan por completo. Este artículo presentará la optimización de Spark 3.0 en SQL. 
La optimización de SQL incluye principalmente cuatro direcciones:
- Para la interacción del desarrollador;
- Optimización dinámica;
- Mejoras del catalizador;
- Renovación de infraestructura.
¡También mencionamos en el artículo anterior que Spark 3.0 procesó un total de 3464 PROBLEMAS! Es difícil para nosotros pasar por tantos PROBLEMAS uno por uno, por lo que en esta sesión, el Dr. Kazuaki Ishizaki nos brindó una mejora en SQL. 
La mejora en SQL incluye principalmente siete aspectos:
- EXPLICAR nuevo formato;
- All Join admite sugerencias;
- Ejecución adaptativa de consultas;
- Corte de partición dinámico;
- Mejore el recorte y el empuje hacia abajo de columnas anidadas;
- Generación de código mejorada para agregación;
- Soporte para nuevas versiones de Scala y Java.
EXPLICAR nuevo formato
Si queremos mejorar el rendimiento de las consultas, debemos comprender cómo se optimiza una consulta. Primero, debemos comprender el plan de consultas. Supongamos que tenemos una consulta de la siguiente manera:
SELECT key, Max(val)
FROM temp
WHERE key > 0
GROUP BY key
HAVING max(val) > 0Echemos un vistazo a los planes de consulta de Spark 2.4 y Spark 3.0 para este SQL. 
Si usa EXLPAIN en Spark 2.4 para ver el plan de consulta, puede ver que la salida es demasiado larga. ! Porque hay muchos atributos innecesarios en cada fila. Es difícil para nosotros ver de un vistazo para qué sirve. 
Spark 3.0 agrega el soporte de FORMATTED sobre la base de EXPLAIN, y muestra información detallada en un formato muy conciso Esta salida consta principalmente de dos partes.
La primera parte es principalmente una serie de operadores; la
segunda parte es una serie de atributos
A partir de la salida anterior, podemos ver cómo Spark SQL maneja esta consulta de un vistazo. Si desea ver información más detallada, como la salida, puede ver el Atributo en la segunda parte.
All Join admite sugerencias
La segunda optimización de SQL es Join Type Hint.
En Spark 2.4, solo podemos dar pistas Hint a Broadcast, y no se admiten otros tipos de Join. En Spark 3.0, las sugerencias de sugerencias son compatibles con todos los tipos de combinación. Podemos usar hint directamente en SQL o en DSL. Esta estrategia de unión elegida en Spark es muy útil cuando no la queremos.
Ejecución de consultas adaptables
La tercera optimización es la optimización adaptativa de consultas.
- A través de las estadísticas de ejecución, se optimizan tres aspectos:
- Establezca automáticamente un número razonable de Reducir;
- Elija una mejor estrategia de unión para mejorar el rendimiento;
- Optimice los datos en Tilt Join.
Estas optimizaciones no necesitan ser ajustadas manualmente en absoluto. En la consulta Q77 de TPC-DS, el rendimiento se mejora 8 veces.
Lo anterior es el estado de operación de SQL en 2.4. Si hay 5 procesos de reducción para 5 particiones, puede ver que Reducir 0 se puede completar muy rápidamente porque hay pocos datos; el segundo es Reducir 4; el más lento es Reducir 3, que, como resultado, el consumo de tiempo de esta consulta SQL se gasta principalmente en Reducir 3, mientras que otras CPU están inactivas.
En Spark 3.0, se seleccionará automáticamente el número apropiado de Reducciones, de modo que ninguna Redue quede inactiva.
Spark 2.4 selecciona la estrategia de combinación en función de las estadísticas estáticas. Por ejemplo, las estadísticas estáticas de table1 y table2 anteriores son 100 GB y 80 GB respectivamente, por lo que la combinación anterior utiliza la combinación de combinación de ordenación.
Spark 3.0 sabe que esta combinación debe elegir la combinación de transmisión en función de las estadísticas en tiempo de ejecución.
El tiempo de unión de las dos tablas depende del tiempo de la partición más grande. Entonces, si hay datos sesgados en una partición durante el proceso de unión, se puede imaginar el tiempo de procesamiento. 
La ejecución adaptativa de Spark 3.0 puede dividir particiones sesgadas. Para lograr un tiempo de ejecución relativamente considerable. Para la ejecución adaptativa de Spark 3.0, consulte la introducción a Spark 3.0 Adaptive Query Optimization para Memory Big Data en el pasado, y este artículo acelera el rendimiento de ejecución de Spark SQL en tiempo de ejecución.
Recorte dinámico de particiones
La cuarta optimización es la poda dinámica de particiones. Esto se puede ver en el artículo Comprensión de la eliminación de particiones dinámicas de Apache Spark 3.0 y en el artículo Comprensión del uso de la eliminación de particiones dinámicas de Apache Spark 3.0. No lo presentaré aquí. El siguiente es un ejemplo de corte dinámico de particiones.
Recorte y empuje hacia abajo mejorados de columnas anidadas
La quinta optimización es la optimización de columnas anidadas.
Spark 2.4 admite la optimización de columnas anidadas en Parquet y solo lee la parte requerida, pero esta función es muy limitada. Por ejemplo, la Repartición no admite el recorte de columnas anidadas. Necesita reparticionar toda la columna antes de seleccionar la parte requerida.
Spark 3.0 optimiza esta parte, de modo que la adaptación de columnas anidadas admita todos los operadores, incluido el reparto anterior, lo que reduce considerablemente la IO porque reducimos la lectura de datos. El siguiente es un ejemplo de recorte de columnas anidadas:
Spark 2.4 no admite la inserción de columnas anidadas (Parquet y ORC). Debe leer todos los datos y luego realizar la operación de filtro.
Spark ha optimizado esta parte y ahora admite el filtrado de pushdown para columnas anidadas Parquet y ORC.
Generación de código mejorada para agregación
La sexta optimización es mejorar la generación de código para la agregación.
La compleja agregación de Spark 2.4 es muy lenta, debido a que las consultas complejas de Spark 2.4 no se compilan en el código local. Entonces, cuando ejecute TPC-DS, encontrará que Q66 es muy lento.
En Spark, Catalyst es responsable de traducir las consultas al código Java. El compilador HotSpot en OpenJDK es responsable de traducir el código Java al código local.
Pero cuando las instrucciones del método superan los 8000 bytes de código Java, el compilador HotSpot deja de traducir el código Java al código local. 
Catalyst of Spark 3.0 divide la lógica agregada en varios métodos más pequeños para que el compilador HotSpot pueda convertirlo en código local, por lo que el rendimiento de la consulta es mucho más rápido que el 2.4. El siguiente es un ejemplo; 
la parte superior de la figura anterior usa Spark 3.0, puede ver que el tamaño de método más grande es menor que 8000, y la siguiente figura es para desactivar esta función, el tamaño de método más grande ha excedido 8000.
Soporte para nuevas versiones de Scala y Java
