Почему одинаковый объём данных обрабатывается по-разному, если разбит на множество файлов. Объясняем затраты Spark и ограничения укрупнения.
Объём одинаковый, время разное
Представьте условный архив: сто тысяч коротких писем лежат в отдельных конвертах. В другом архиве те же письма собраны в несколько папок. Прочитать содержание всё равно нужно, но в первом случае добавляется работа с каждым конвертом. Похожая ситуация возникает, когда данные для Spark разбиты на множество маленьких файлов.
Spark — система, которая распределяет обработку данных между вычислительными ресурсами. Её производительность зависит не только от общего объёма. Значение имеют количество файлов, способ хранения, формат и сама задача. Поэтому сравнение двух наборов только по числу гигабайтов часто не объясняет разницу во времени.
Работа начинается раньше чтения содержимого
Системе нужно обнаружить файлы, получить сведения о них, открыть нужные объекты и спланировать обработку. У каждого действия есть затраты. Когда полезного содержимого в файле очень мало, подготовительная работа может занимать заметную часть общего времени.
В руководстве AWS по уменьшению затрат на планирование большое количество файлов рассматривается как возможная причина проблем при подготовке задач. Это не означает, что каждый файл всегда создаёт отдельную задачу: поведение зависит от способа чтения и настроек.
Откуда берутся маленькие файлы
Условный сервис может записывать отдельный результат каждые несколько секунд, даже когда новых событий мало. Другой источник проблемы — слишком подробное разделение хранения: например, данные раскладывают по множеству небольших групп. В каждой группе остаётся совсем немного записей, но для неё всё равно появляются отдельные файлы.
Ещё один сценарий связан с параллельной обработкой. Несколько исполнителей могут записать свои части результата, и при небольшом объёме эти части окажутся маленькими. Сам по себе параллелизм полезен; проблема возникает, когда организация результата плохо соответствует тому, как его будут читать дальше.
Почему один гигантский файл тоже не цель
Интуитивное решение — собрать всё в один файл. Но это способно ограничить параллельное чтение для некоторых форматов и способов сжатия, увеличить стоимость повторной обработки и сделать отдельные операции неудобными. Нужен компромисс между количеством объектов и достаточной возможностью распределить работу.
В документации Spark по производительности учитываются затраты открытия файлов и организация частей чтения. Универсального размера, который одинаково хорош для любого хранилища и запроса, из этого не следует. Подбирать организацию файлов нужно по реальному сценарию, а не по одной цифре из чужого примера.
Как понять, действительно ли виноваты файлы
Сравните время обнаружения и подготовки данных со временем самого вычисления. Посмотрите количество файлов, распределение их размеров и число обрабатываемых частей. Проверьте, не тратится ли основное время на передачу данных между исполнителями или на одну необычно тяжёлую группу. Такие причины требуют другого решения.
Полезно взять представительный фрагмент набора и сравнить исходную организацию с более компактной в отдельной среде. Сохраните одинаковые условия чтения и один и тот же результат проверки. Ускорение одного пробного запроса ещё не доказывает, что изменение полезно для всех потребителей, особенно если они читают разные части данных.
Укрупнение тоже требует работы
Объединение небольших файлов в более крупные часто называют уплотнением. Оно расходует вычислительные ресурсы и создаёт новую организацию данных. В документации Apache Hudi о размерах файлов обсуждается баланс между эффективностью чтения и поддержанием подходящих размеров при записи.
Для команды важно определить, кто выполняет обслуживание, когда новый набор становится доступен и как проверяется его полнота. Нельзя просто удалить исходные файлы, не убедившись, что потребители могут безопасно читать результат. Хорошее решение уменьшает лишние затраты, сохраняет данные и остаётся понятным тем, кто будет сопровождать систему завтра.
Читайте также
Что изучать дальше
Если хотите разобраться в работе с данными системно, посмотрите программу «PySpark для инженеров и аналитиков данных» в NovaData. Сравните темы и требования к подготовке со своими задачами: этот пример помогает сформулировать вопросы, с которыми можно прийти на обучение.
