Spark
Средний уровеньПочему Spark не обрезает партиции, хотя я фильтрую по столбцу партиционирования?
Фильтр по столбцу партиционирования должен означать, что Spark пропускает неподходящие директории. Это работает только если фильтр — прямое сравнение того же типа, которое планировщик может разрешить до чтения чего бы то ни было.
Запрос, фильтрующий по точному столбцу партиционирования, всё равно может сканировать каждую партицию таблицы — и ничего в ошибке (её нет) не подскажет почему.
Что на самом деле требуется, чтобы сработал partition pruning
Фильтр должен быть прямым, литеральным сравнением на самом столбце партиционирования, в типе, совпадающем с тем, как партиция реально хранится. Планировщик должен суметь определить, какие директории партиций можно пропустить, до чтения хотя бы одного файла — всё, что требует сначала прочитать данные для оценки, это не pruning, а фильтрация постфактум.
Ловушка с несовпадением типов
Столбец партиции, хранящийся как строка ("2026-11-02"), сравниваемый с литералом типа date — или наоборот — вынуждает неявное приведение типа. Как только выражение фильтра оборачивается в этот cast, планировщик обычно уже не может протолкнуть его в partition pruning — он читает файлы каждой партиции и фильтрует потом, незаметно, без предупреждения, что pruning перестал применяться.
Производные фильтры тоже не обрезают
Фильтрация по столбцу, производному от столбца партиции — date_trunc('month', event_date) на таблице, партиционированной по event_date — не распознаётся планировщиком как тот же предикат. Реально обрезает только прямое сравнение с исходным столбцом партиции в его нативном типе.
Посмотрите, как это выглядит на вашем собственном пайплайне.
Загрузите реальный event log Spark, run_results.json от dbt или экспорт метрик Flink — и получите конкретные рекомендации, которые нужно одобрить, а не ещё одно эмпирическое правило.