Для отчёта часто нужна лишь часть исходной таблицы. Объясняем перенос фильтра к источнику, выбор столбцов и причины, по которым экономия не гарантирована.
Не вся исходная таблица нужна следующему шагу
Представим условную сеть пунктов проката. В исходной системе хранятся поездки за несколько лет и множество подробностей о каждой аренде. Для сегодняшнего отчёта нужны только завершённые поездки за один месяц, дата и стоимость. Можно сначала перенести большую таблицу в обработку, а затем убрать лишнее. Другой путь — попросить источник сразу подготовить подходящую часть.
Spark — инструмент распределённой обработки данных. При чтении он может передать часть работы поддерживающему её источнику. Перенос условия отбора называют проталкиванием фильтра. Например, обработке нужны только сведения за согласованный период. Это не гарантия ускорения и не изменение правил доступа: отбор работает внутри уже разрешённого подключения.
Фильтр можно выполнить до передачи записей
В документации Spark о чтении из баз через JDBC описана передача поддерживаемых условий источнику. JDBC — способ подключения к базам данных через соответствующий драйвер. Если нужное условие обработано самой базой, Spark может получить меньше лишних строк. Часть работы при этом выполняется на стороне исходной системы.
Для нашего проката предложим сравнивать два места нагрузки: источник и последующую обработку. Сокращение передаваемого набора не означает, что базе стало легче. Если для отбора ей приходится просматривать огромную таблицу, время может остаться значительным. Поэтому обсуждать полезность механизма нужно вместе с владельцем источника, а не только по размеру полученного файла.
Выбор столбцов решает другую часть задачи
Отбор строк отвечает на вопрос «какие поездки нужны», а выбор столбцов — «какие сведения об этих поездках нужны». В описании интерфейса источников Spark предусмотрено чтение только требуемых полей. Поддержка может быть частичной, в том числе для вложенных данных. Наличие такой возможности в Spark ещё не означает одинаковую реализацию во всех подключениях.
В нашем условном отчёте не нужны комментарии и подробные технические признаки поездки. Предложим явно определить необходимые поля до обсуждения чтения. Если на следующем этапе неожиданно требуется исключённый признак, придётся пересмотреть план. Сначала полезно записать смысл итогового отчёта, затем перечислить сведения, без которых его нельзя проверить.
Поддерживается не любое условие
Источники различаются, а условие может включать действие, которое конкретное подключение не умеет передавать. Тогда часть отбора остаётся внутри Spark. Для учебного обсуждения представим проверку сложного текстового описания поездки: нельзя заранее считать, что любая база выполнит её точно так же. Нужно проверить фактическое поведение выбранного подключения и результат.
Отдельно уточним границы периода и смысл статуса «завершена». Если одно представление учитывает местное время, а другое — иной момент отсечения, более быстрое чтение всё равно даст спорный отчёт. Прежде чем сравнивать длительность, предложим проверить одинаковые идентификаторы поездок и контрольные итоги. Иначе сравнение скорости замаскирует различие в данных.
Проверять объём и результат, а не название оптимизации
Для нашего примера предложим наблюдать время чтения, переданный объём и нагрузку источника, сохраняя одинаковые условия проверки. Не стоит обещать пропорционального ускорения по доле оставшихся строк. На результат влияют работа базы, передача и последующие действия. Такой разбор показывает, где действительно удалось сократить ненужную работу и где она просто переместилась.
Это отдельный вопрос от устройства формата Parquet: здесь важен договор между обработкой и конкретным источником. Представление об общей схеме работы даёт статья о распределённой обработке Spark. Для дальнейшего изучения посмотрите программу «PySpark для инженеров и аналитиков данных» и сопоставьте темы со своими источниками.
