Spark
Nivel medio¿Por qué Spark no está podando particiones aunque filtré por la columna de partición?
Filtrar por la columna de partición debería significar que Spark salta los directorios que no pueden coincidir. Solo funciona si el filtro es una comparación directa, del mismo tipo, que el planificador pueda resolver antes de leer nada.
Una consulta que filtra exactamente por la columna de partición todavía puede escanear cada partición de la tabla - y nada en el error (no hay ninguno) le dice por qué.
Qué requiere realmente el partition pruning para activarse
El filtro tiene que ser una comparación directa y literal sobre la columna de partición misma, en un tipo que coincida con cómo está almacenada realmente la partición. El planificador necesita poder resolver qué directorios de partición se pueden saltar antes de leer un solo archivo - cualquier cosa que requiera leer datos primero para evaluarse no es pruning, es filtrar después del hecho.
La trampa del desajuste de tipos
Una columna de partición almacenada como string ("2026-11-02") comparada contra un literal de tipo date - o viceversa - fuerza un cast implícito. Una vez que la expresión del filtro queda envuelta en ese cast, el planificador generalmente ya no puede empujarla hacia partition pruning; lee los archivos de cada partición y filtra después, en silencio, sin ninguna advertencia de que el pruning dejó de aplicarse.
Los filtros derivados tampoco podan
Filtrar por una columna derivada de la columna de partición - date_trunc('month', event_date) en una tabla particionada por event_date - el planificador no lo reconoce como el mismo predicado. Solo una comparación directa contra la columna de partición cruda, en su tipo nativo, realmente poda.
Vea cómo se ve esto en su propio pipeline.
Suba un event log real de Spark, un run_results.json de dbt o una exportación de métricas de Flink y obtenga recomendaciones concretas, que debe aprobar antes de aplicar - no otra regla general.