← R2 Data Catalog / r2-data-catalog
Обслуживание таблиц
Обслуживание таблиц включает набор операций, которые с течением времени сохраняют производительность и экономичность ваших таблиц Apache Iceberg. По мере записи, обновления и удаления данных в таблицах накапливаются метаданные и файлы, способные со временем снижать производительность запросов.
R2 Data Catalog автоматизирует две важные операции обслуживания:
- Компактизация: объединяет мелкие файлы данных в более крупные и эффективные файлы для повышения производительности запросов
- Истечение срока действия снимков: удаляет старые снимки таблицы и все неиспользуемые файлы данных, снижая накладные расходы на метаданные и затраты на хранение
Без регулярного обслуживания в таблицах могут возникать следующие проблемы:
- Снижение производительности запросов: чем больше файлов нужно сканировать, тем медленнее запросы и выше затраты на вычисления
- Рост расходов на хранение: накопление мелких файлов и старых снимков приводит к неоправданному расходу хранилища
- Накладные расходы на метаданные: большие файлы метаданных замедляют планирование запросов и операции с таблицей
Включив автоматическое обслуживание таблиц, вы гарантируете, что R2 Data Catalog будет поддерживать таблицы в оптимизированном состоянии без необходимости запускать этот процесс вручную.
Зачем нужна компактификация?
Каждая операция записи в Apache Iceberg ↗, независимо от объема, приводит к появлению новой партии файлов. Со временем количество файлов может расти неограниченно. Это может привести к следующему:
- Замедление запросов и увеличение операций ввода-вывода: без уплотнения движкам запросов приходится открывать и читать каждый отдельный файл, что увеличивает время выполнения запросов и затраты.
- Рост накладных расходов на метаданные: движкам запросов приходится сканировать файлы метаданных, чтобы определить, какие из них нужно прочитать. При наличии тысяч мелких файлов планирование запроса занимает больше времени ещё до того, как данные будут прочитаны.
- Снижение эффективности сжатия: файлы меньшего размера сжимаются менее эффективно, чем крупные файлы, что приводит к увеличению затрат на хранение и объема данных, передаваемых при запросах.
Автоматическое уплотнение в R2 Data Catalog
Теперь R2 Data Catalog может управление сжатием для таблиц Apache Iceberg, хранящихся в R2. Когда эта функция включена, сжатие запускается автоматически и объединяет новые файлы, которые ещё не были сжаты.
Имена уплотнённых файлов начинаются с префикса compacted- в /data/ каталог соответствующей таблицы.
Примеры
# Enable catalog-level compaction (all tables)
npx wrangler r2 bucket catalog compaction enable my-bucket \
--target-size 128 \
--token $R2_CATALOG_TOKEN
# Enable compaction for a specific table
npx wrangler r2 bucket catalog compaction enable my-bucket my-namespace my-table \
--target-size 256
# Disable catalog-level compaction
npx wrangler r2 bucket catalog compaction disable my-bucket
# Disable compaction for a specific table
npx wrangler r2 bucket catalog compaction disable my-bucket my-namespace my-tableПодробнее об управлении уплотнением см. в Управление каталогами.
Выберите подходящий целевой размер файла
Вы можете настроить целевой размер файла для компактификации. В настоящее время минимальное значение составляет 64 MB, а максимальное 512 MB.
У разных вычислительных движков разный оптимальный размер файлов, поэтому уточняйте информацию в их документации.
Компромисс между производительностью зависит от сценария использования. Например, запросы, возвращающие небольшой объем данных, могут выполняться быстрее при работе с файлами меньшего размера, поскольку крупные файлы могут привести к чтению лишних данных.
- Для нагрузок, чувствительных к задержкам, используйте файлы меньшего целевого размера (например, 64-128 МБ)
- Для потоковой загрузки данных используйте файлы среднего размера (например, 128-256 МБ)
- Для OLAP-запросов, которые сканируют большие объёмы данных, используйте файлы большего размера (например, 256-512 МБ)
Зачем нужно истечение срока действия снимков?
Любая запись в таблицу Iceberg, будь то вставка, обновление или удаление, создаёт новый снимок. Со временем количество таких снимков может расти и приводить к снижению производительности:
- Накладные расходы на метаданные: каждый снимок добавляет записи в файлы метаданных таблицы. По мере роста числа снимков файлы метаданных увеличиваются, что замедляет планирование запросов и операции с таблицей
- Рост расходов на хранение: старые снимки ссылаются на файлы данных, которые могут быть уже не нужны. Без истечения срока действия снимков эти файлы продолжают занимать лишнее место в хранилище
- Замедление операций с таблицами: со временем такие операции, как получение списка снимков или доступ к истории таблицы, становятся медленнее
Автоматическое истечение срока действия снимков в R2 Data Catalog
Настройка истечения срока действия снимков
Истечение срока действия снимков использует два параметра для определения того, какие снимки удалить:
--older-than-days: удалять снимки старше указанного количества дней (по умолчанию: 30 дней)--retain-last: всегда сохраняйте это минимальное количество последних снимков (по умолчанию: 5 снимков)
Для истечения срока действия снимка должны быть выполнены оба условия. Это гарантирует, что последние снимки всегда сохраняются, даже если они старше порогового значения возраста.
Примеры
# Enable snapshot expiration for entire catalog
# Keep minimum 10 snapshots, expire those older than 7 days
npx wrangler r2 bucket catalog snapshot-expiration enable my-bucket \
--token $R2_CATALOG_TOKEN \
--older-than-days 7 \
--retain-last 10
# Enable for specific table
# Keep minimum 5 snapshots, expire those older than 2 days
npx wrangler r2 bucket catalog snapshot-expiration enable my-bucket my-namespace my-table \
--token $R2_CATALOG_TOKEN \
--older-than-days 2 \
--retain-last 5
# Disable snapshot expiration for a catalog
npx wrangler r2 bucket catalog snapshot-expiration disable my-bucketВыберите подходящую политику хранения
Разным рабочим нагрузкам требуются разные стратегии хранения снимков:
- Таблицы для разработки и тестирования: более короткое хранение (2-7 дней, 5 снимков) для минимизации затрат на хранение
- Промышленные аналитические таблицы: среднее хранение (7-30 дней, 10-20 снимков) для отладки и анализа
- Таблицы для соответствия требованиям и аудита: более длительное хранение (30-90 дней, 50+ снимков) для соответствия нормативным требованиям
- Высокочастотная загрузка данных: более высокое минимальное количество снимков для сохранения более детальной истории
Это общие рекомендации, при использовании учитывайте следующее:
- Требования для путешествия во времени
- Требования соответствия
- Расходы на хранение
Текущие ограничения
- В настоящее время уплотнение поддерживает только файлы данных в формате parquet.
- Файлы, на которые ранее не ссылался ни один снимок, не будут удалены при очистке (файлы-сироты).
- Минимальный целевой размер файла для уплотнения составляет 64 МБ, максимальный размер составляет 512 МБ.