Un artículo sobre la eliminación de particiones dinámicas de Apache Spark 3.0 (eliminación de particiones dinámicas)
Big Data de memoria pasada Big Data de memoria pasada
Poda de partición estática
Quienes han usado Spark saben que Spark SQL admite el corte de particiones al realizar consultas. Por ejemplo, si tenemos la siguiente consulta:
SELECT * FROM Sales_iteblog WHERE day_of_week = 'Mon'Spark realizará automáticamente las siguientes optimizaciones: 
Si desea obtener información sobre los artículos relacionados con Spark, Hadoop o Hbase a tiempo, preste atención a la cuenta pública de WeChat: iteblog_hadoop
Como puede ver en la figura anterior, Spark presiona automáticamente el operador Filtro hasta los datos al compilar SQL La fuente, es decir, la operación de Filtro se realiza antes del Escaneo, y se sacan todos los datos de day_of_week = 'Mon', y se sacan los demás datos, de modo que los datos procesados en Spark SQL se vuelve menos y todos los datos de la consulta SQL se volverán más rápidos. Todo esto se hace durante el tiempo de compilación, por lo que esto se llama Pruning de partición estática.
La consulta SQL anterior ha sido empujada hacia abajo por el operador en Spark, y ha podido cumplir con la mejora del rendimiento de nuestra consulta. Pero la consulta de datos del mundo real no es tan simple. Echemos un vistazo a la siguiente declaración de consulta:
SELECT * FROM Sales JOIN Date WHERE Date.day_of_week = 'Mon'El motor de consulta más pobre hace esto: 
si desea obtener información sobre Spark, Hadoop o artículos relacionados con Hbase a tiempo, siga la cuenta pública de WeChat: iteblog_hadoop
Como se puede ver en la figura anterior, el motor de consulta ignora directamente Date.day_of_week = 'Mon'. La condición del filtro es unir las dos tablas y luego filtrar los resultados de la combinación. Esto puede llevar a muchos cálculos no válidos. Si Date.day_of_week = 'Mon', una gran cantidad de datos inútiles pueden ser filtrado y el rendimiento de las consultas definitivamente se puede mejorar. Esta situación se puede manejar bien en Spark SQL. Impulsará la condición de filtro Date.day_of_week = 'Mon' antes del escaneo de la tabla de fecha: 
si desea obtener información sobre los artículos relacionados con Spark, Hadoop o Hbase, preste atención a WeChat public account: iteblog_hadoop Eliminación de
particiones dinámicas ( Eliminación de particiones dinámicas) ¿
El empuje hacia abajo del operador realizado por Spark SQL anterior ya no puede mejorar el rendimiento de la consulta? ¿Existe una mejor manera de filtrar aún más algunos datos inútiles? Esta es la adaptación dinámica de particiones que presentará este artículo. La función de recorte dinámico de particiones se introdujo en Spark 3.0; consulte SPARK-11150 y SPARK-28888 para obtener más detalles.
¿Qué es el recorte dinámico de particiones? El llamado corte de partición dinámico se basa en la información inferida en tiempo de ejecución (tiempo de ejecución) para un posterior corte de partición. Por ejemplo, tenemos la siguiente consulta:
SELECT * FROM dim_iteblog
JOIN fact_iteblog
ON (dim_iteblog.partcol = fact_iteblog.partcol)
WHERE dim_iteblog.othercol > 10El plan de ejecución de la consulta dinámica es el siguiente: 
si desea obtener información sobre Spark, Hadoop o artículos relacionados con Hbase a tiempo, preste atención a la cuenta pública de WeChat: iteblog_hadoop
Como puede ver en lo anterior, con la adaptación dinámica de particiones , Spark puede verificar primero el partcol de la tabla fact_iteblog cuando se está ejecutando. Después de filtrar una vez y luego unirse a la tabla dim_iteblog, es posible que este rendimiento generalmente mejore, especialmente cuando la tabla fact_iteblog tiene una gran cantidad de datos inútiles La mejora del rendimiento será muy grande.
Databricks realizó una prueba TPC-DS en 10 clústeres configurados como i3.xlarge y concluyó que el rendimiento de 60 consultas en 102 consultas mejoró de 2 a 18 veces en comparación con Spark 2.4.
En la consulta de la Consulta 98, ¡el rendimiento se ha mejorado 100 veces!