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
Cualquiera que haya usado Spark sabe 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 más información sobre Spark y Hadoop in time O artículos relacionados con Hbase, preste atención a la cuenta pública de WeChat: iteblog_hadoop
Como puede ver en la figura anterior, Spark automáticamente empuja el operador Filter a la fuente de datos al compilar SQL, es decir, la operación Filter es realizado antes de Scan, y day_of_week = Saque todos los datos de 'Mon', saque los otros datos que no son necesarios, de modo que los datos procesados en Spark SQL sean menores y los datos de consulta de todo el SQL se vuelvan más rápidos. este es el tiempo de compilación Por lo tanto, esto se llama Poda de particiones estáticas.
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 más información sobre Spark, Para artículos relacionados con Hadoop o Hbase, siga la cuenta pública de WeChat: iteblog_hadoop
Como se puede ver en la figura anterior, el motor de consulta ignora directamente la condición de filtro Date.day_of_week = 'Mon'. Las dos tablas se unen y luego se filtran los resultados de la unión. Esto puede dar lugar a muchos cálculos no válidos. Si Date.day_of_week = 'Mon' puede filtrar una gran cantidad de datos inútiles, lo que definitivamente puede mejorar el rendimiento de la consulta. 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 push-down del operador realizado por Spark SQL anterior ya no puede mejorar el rendimiento de las consultas? ¿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 las consultas de 60 consultas en 102 consultas se 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!