Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. В этой статье рассмотрим, как большое количество мелких файлов влияет на производительность различных систем хранения, таких как HDFS и объектные хранилища с S3 API.

Разберём, какие технологии хранения лучше всего подходят для работы с мелкими файлами в архитектурах Data Lake и Lakehouse. Сравним производительность HDFS и объектных хранилищ с S3 API. На конкретных тестах покажем, почему именно HDFS эффективнее справляется с большим количеством небольших файлов. Обсудим также случаи, когда мелкие файлы становятся не просто нежелательной ситуацией, а неизбежной необходимостью, например в подходах типа Change Data Capture (CDC).

Хранение в Lakehouse

Часто звучит мнение, что для хранения датасетов с большим количеством мелких файлов лучше всего подходят объектные хранилища с S3 API. На практике это не всегда так. Реальные тесты показывают, что системы типа HDFS и Ozone с интерфейсом OFS в таких сценариях работают эффективнее и стабильнее.

Несмотря на ограничение HDFS по количеству файлов, связанное с хранением метаданных Name Node в памяти и особенностями работы Java GC, эта граница не является абсолютно жёсткой и может варьироваться в зависимости от настроек и сценариев использования, часто достигая сотен миллионов. Важно понимать, что это, скорее, практический предел, после превышения которого начинается существенная деградация производительности. Существуют механизмы федерализации для масштабирования, и наличие большого количества маленьких файлов всегда негативно сказывается на работе системы, поэтому их количество и время жизни должны быть строго ограничены. В связи с этим возникают ключевые вопросы: какой размер считать «маленьким» файлом и насколько критично размер файлов влияет на общую производительность Lakehouse?

Неожиданные показатели нагрузочного теста

Делаем небольшой «разведочный тест», а для имитации нагрузки будем использовать стандартный тест для оценки производительности систем TPC-DS. В качестве систем хранения возьмём HDFS, MinIO и Ozone. При этом для Ozone будем применять file system optimized (FSO) бакеты и доступ к ним по двум API OFS и S3 API.

Итак, что я сделал по шагам:

1. Сгенерировал два датасета TPC-DS 100, сохранил их в orc-формате в двух базах данных, назовём их условно tpcds-100 и tpcds-100-small. Для удобства можно использовать эти базы c датасетом 100 Гб. Они отличаются только количеством файлов, в которых лежат данные. В первой все данные лежат в 167 файлах, а во второй — в 14 тысячах.  Получается, что средний объём файла в первой 133,6 Мб, а во второй 2,3 Мб.

hdfs dfs -count -h /apps/hive/hdd/*

25          167             21.8 G /…/[каталог с tpcds-100].db

25       14.0 K             31.2 G /…/[каталог с tpcds-100-small].db

2. Скопируем их на MinIO и Ozone, накинем внешние таблицы. Подсчитаем статистику.

3. Для нагрузки возьмём 72 тестовых запроса, которые исполняются в Impala. Будем использовать однопоточный режим, это несколько отличается от методики TPC. Необходимо оценить деградацию при работе с файлами, отличающимися от эталонного значения в меньшую сторону. Кстати, я призываю вас не сравнивать абсолютные значения производительности HDFS, MinIO и Ozone. Во-первых, аппаратное обеспечение отличалось, хоть и немного, во-вторых, это не цель данной статьи.

Ниже в таблице коротко представлены характеристики используемого тестового стенда.

Запускаем нагрузочные запросы, результаты представлены в таблице ниже.

Результат с MinIO удивил: мы ожидали падения производительности на мелких файлах, но не такого сильного. Для MinIO решили попробовать рекомендованный в различных статьях тюнинг, например, но не помогло.

Ozone и HDFS в тестах стабильно показывали хорошие результаты с минимальными отклонениями. Дополнительно аналогичные тесты провели в Trino. Результаты подтвердили тот же тренд: при работе с мелкими файлами производительность падает значительно.

Какой можно сделать из этого вывод? Похоже, что HDFS гораздо лучше справляется с обработкой маленьких файлов. Кроме того, Apache Ozone с OFS также показал лучшее значение, чем MinIO, что согласовывается с исследованием компании Cloudera.

Давайте отойдём от экспериментов и дадим этим наблюдениям теоретическое обоснование. Исследований на эту тему довольно много, но я приведу два, которые более релевантны и интересны, на мой взгляд.

Теоретические подтверждения неожиданных показателей

Результаты тестов заставили обратиться к существующим исследованиям и экспертам, чтобы разобраться в причинах. Главная причина разницы производительности — фундаментальные архитектурные различия между HDFS и S3.

HDFS оптимизирована для работы именно с большим количеством файлов, что обеспечивается централизованным управлением метаданными и пакетной обработкой операций. В свою очередь, объектные хранилища с S3 API изначально предназначены для объектного хранения и плохо подходят для аналитических сценариев с частым доступом к большому числу мелких файлов. Их основные проблемы — высокие накладные расходы на метаданные и значительные задержки при работе через HTTP-протокол.

Ожидаемо! Основная причина такой деградации производительности связана с эффектом «малых файлов» и накладными расходами на метаданные и сетевые запросы, особенно в объектных хранилищах.

Рассмотрим сравнение производительности операций с метаданными файловых систем HDFS, S3 и JuiceFS, таких как создание, открытие, переименование и удаление. Исследования показали кратное преимущество HDFS — от 10 до 20 раз в зависимости от параллельности нагрузки перед S3, а также значительно меньшую задержку. На графике выше показана задержка выполнения каждой операции при 20 одновременных операциях (не при полной нагрузке), и вы можете видеть, что S3 работает очень медленно.

Кроме этого, в статье сделаны выводы что HDFS в отличие от S3, который начинает проседать, показывает линейный рост производительности при увеличении числа параллельных операций. Пропускная способность (количество операций в секунду при высокой нагрузке) у S3 в 10–100 раз ниже, чем у HDFS. S3 требует больше ресурсов для достижения производительности, сопоставимой с HDFS. Если важна производительность операций с метаданными (например, при большом числе мелких файлов), HDFS будет намного предпочтительнее.

Сравним два решения: HBase и Phoenix, операционная база данных Cloudera (COD) с использованием в качестве слоя хранения двух вариантов HDFS или облачного хранилища. И облачное хранилище на графиках выглядит очень привлекательно по производительности. Для поддержки S3 используется высокопроизводительный кэш, а когда S3 используется без кэша, то производительность в разы меньше. Такие статьи нам не подходят, по ним невозможно оценить производительность самого объектного хранилища. Зачем тогда это всё? Продвижение технологии S3 очень выгодно определённому количеству производителей ПО, и часто они расставляют акценты так, что у невнимательного читателя происходит подмена понятий, как, например, здесь, когда производительность системы кэш и S3 выдают за производительность S3.

В исследовании представлена методология и набор инструментов для анализа производительности S3 API, а также возможности использования Minio для задач High Performance Computing (HPC). В нём выявлены интересные для нашего материала закономерности. Обработка мелких файлов через S3 API приводит к значительным потерям производительности из-за высоких накладных расходов на протокол HTTP и метаданные. Крупные файлы (от 1 МБ и выше) обрабатываются заметно быстрее, чем мелкие. Это подтверждается как в тестах MinIO, так и при анализе облачных решений. Для файлов размером 32 МБ и более производительность близка к теоретической пропускной способности сети, особенно в оптимизированных сценариях (S3Embedded).

Маленькие файлы (до 64 КБ) демонстрируют значительное падение производительности, особенно при работе через REST API и в стандартных S3-совместимых системах.

Как видно из приведённых изображений, полученные в статье результаты полностью согласуются с теми, что мы наблюдали в экспериментах. Напомню, получена хорошая производительность при размере файлов более 13 Мб и сильная деградация производительности при значении близком к 1 Мб.

Однако здесь также заметна явная зависимость между такими показателями, как Throughput (пропускная способность) и Ops/s (операций в секунду). Вопрос, который появляется, когда мы видим эту зависимость: «А как ведёт себя S3, если идёт речь не о большом количестве маленьких файлов, а о большом количестве файлов в датасете?»  

Провести этот эксперимент достаточно дорого и существенно сложнее. Возможно, если будет интерес к теме и необходимость, сделаем более глубокое исследование. Могу только дать спойлер: статистически значимая зависимость имеется.

Требующий особого внимания побочный эффект большого количества файлов в датасете — это стоимость операций PUT, HEAD, LIST, POST и особенно GET. За небольшое время в течение суток и не слишком большое количество запросов счёт за эти операции превысил счёт за хранение в три раза.

Маленькие файлы в современных архитектурах загрузки и повседневной жизни производственного озера данных

Многие хорошо настроенные производственные системы стремятся избегать большого количества мелких файлов, но полностью устранить эту проблему невозможно. На практике можно выделить три типичных ситуации.

Первая — неизбежная действительность больших систем. Исследование B. Уэлча и Г. Ноера показало, что в реальных установках от 25% до 90% файлов имеют размер 64 КБ или меньше. При этом они занимают незначительный объём (обычно до 3%, иногда до 15%), но создают существенную нагрузку на файловую систему. Схожие результаты получили также исследователи Королевского технологического института вместе с Oracle и Spotify: около четверти файлов в производственных средах HDFS занимают менее 16 КБ, а на них приходится до 42% всех файловых операций.

Вторая ситуация связана с параллельной обработкой данных (MPP и MapReduce). Чем выше параллельность записи, тем больше одновременно создаваемых файлов, в том числе очень мелких.

Третий случай — это потоковая обработка данных, в частности архитектура Change Data Capture (CDC), и открытые табличные форматы вроде Iceberg или Hudi. Рассмотрим его детальнее.

Маленькие файлы в CDC-архитектуре

На изображении ниже схематически представлен процесс непрерывной обработки и загрузки в Iceberg-таблицу CDC-логов PostgreSQL в Debezium-формате. Она происходит с использованием микробатчей Spark Structuring Streaming с триггером срабатывания 50 сек. Для формирования таблицы в формате Iceberg на приёмнике используется механизм отслеживания изменений SCD1 (Slowly Changing Dimensions).

На приёмнике существует точная, самая актуальная копия таблицы, к которой задействуется затирание. Данные в таблице полностью заменяются на новые (самые актуальные). Для «накатки» актуальных данных я использовал SQL-выражение MERGE INTO. 

Эта модель загрузки предполагает существование сотен и тысяч файлов в определённый момент времени до того, как вы будете осуществлять операции обслуживания, например следующие: rewrite_data_files, rewrite_manifests. Эти операции не бесплатные, они потребляют ресурсы. Ниже на изображении показан пример операции обслуживания файловой системы — оптимизация, когда из множества промежуточных файлов данных и метаданных создаётся один большой файл данных (merge) и несколько оптимизированных файлов метаданных.

Далее «устаревшие» файлы со временем нужно удалить.  

Рассмотрим результаты дополнительного теста, в котором замерили время выполнения операций «MERGE INTO» и «rewrite_data_files».

Сначала проверили, как зависит время выполнения SQL-команды «MERGE INTO» от количества файлов. Время росло линейно, но по-разному: на HDFS зависимость была слабой, а объектное хранилище MinIO демонстрировало гораздо более заметное увеличение времени обработки.

Целью теста было сравнить динамику изменения производительности MinIO и HDFS при равных начальных условиях и аналогичных ресурсах. В начале эксперимента скорость операции MERGE INTO была сопоставима: 6 секунд у HDFS и 8,5 секунд у MinIO. Но с ростом количества файлов MinIO сильно замедлился — в 9,3 раза, а HDFS всего в 3,2 раза. Из-за этого MinIO перестал укладываться в заданное окно триггера в 50 секунд, которое пришлось увеличить до 90 секунд.

Операция «rewrite_data_files» также показала похожую картину:

• HDFS: 17 секунд при 3 тысячах файлов и 29 секунд при 9 тысячах (замедление в 1,7 раза).

• MinIO: 81 секунда при 3 тысячах файлов и 162 секунды при 9 тысячах (замедление в 2 раза).

Абсолютные значения также важны: MinIO изначально был намного медленнее, и разница только увеличивалась по мере роста нагрузки.

Что делать?

Отказываться от объектных хранилищ с протоколом S3 не нужно. Такие системы отлично работают, когда речь идёт о точечной выборке небольшого числа объектов по ключу. Но в аналитических сценариях или задачах High Performance Computing, где происходит активная работа с большим числом мелких файлов, у S3 возникают существенные ограничения.

Если вы рассматриваете миграцию с HDFS на S3, обязательно проведите предварительный анализ распределения файлов по размерам. Если в вашей системе много файлов менее 10 Мб, миграция может привести к существенному падению производительности и росту стоимости. Именно поэтому крупные компании («экзабайтный клуб») не торопятся переходить на объектные хранилища полностью.

Для обеспечения стабильной работы Lakehouse нужно непрерывно контролировать состояние хранилища. Такой подход требует значительных ресурсов и опыта. Поэтому в некоторых случаях логичнее остаться на HDFS, используя механизмы агрегации файлов, например Hadoop Archive (HAR). HAR позволяет хранить и обрабатывать множество мелких файлов как единый архив без потерь в производительности. Кстати, для продвижения этой технологии руку приложил и наш разработчик Тигран (pull).

Кроме того, кажется вполне оправданным в некоторых случаях гибридный подход, где вы имеете «под ногами» как HDFS, так и объектное хранилище, например Ozone. В ADH это возможно!

Ну и наконец, решения класса «классическое MPP хранилище данных с проприетарным и жёстко связанным слоем хранения», например Greenplum, не имеют, очевидно, подобных проблем.