Сопровождение lakehouse на Iceberg

В этой главе рассматриваются

• Выявление и устранение проблем производительности, вызванных неоптимальными файлами данных и метаданных
• Запуск задач компактизации для оптимизации раскладки файлов и ускорения запросов
• Управление удержанием снимков ради сокращения объёма хранения и выполнения требований комплаенса
• Использование таблиц метаданных Iceberg для мониторинга состояния таблиц и планирования обслуживания

Проектирование и развёртывание lakehouse - только начало. Долгосрочная ценность появляется, когда платформа со временем остаётся производительной, управляемой и устойчивой. Apache Iceberg даёт мощные возможности организации данных, эволюции схемы и изоляции транзакций, но без упреждающего обслуживания эти сильные стороны размываются. По мере роста наборов данных, изменения шаблонов записи и потребностей бизнеса lakehouse должен адаптироваться.

Теперь мы разберём эксплуатационные практики, которые сохранят ваш lakehouse на Apache Iceberg здоровым и производительным. В отличие от традиционных хранилищ данных, где многие задачи оптимизации движок решает автоматически, lakehouse на Iceberg возлагает больше ответственности за раскладку данных и метаданных на инженеров. Без упреждающего обслуживания производительность деградирует, затраты на хранение растут без нужды, а требования управления данными становится труднее соблюдать. Мы начнём с выявления типичных проблем, вызывающих такую деградацию, - мелких файлов, разрозненных партиций и разрастания метаданных - и обсудим, почему они особенно важны в контексте табличного формата Iceberg. Затем рассмотрим приёмы компактизации, управления снимками и оптимизации ресурсов.

К концу этой главы у вас будет практическая схема сопровождения вашего lakehouse на Iceberg, помогающая избегать ловушек, выполнять SLA и поддерживать непрерывное развитие без технического долга.

10.1 Проблема: неоптимальные файлы данных

Даже самый тщательно спроектированный lakehouse на Iceberg со временем деградирует, если файлами данных не управлять должным образом. По мере приёма, обновления и удаления записей раскладка и организация файлов меняются - нередко так, что появляется неэффективность. Она может не приводить к немедленным сбоям, но существенно влияет на производительность запросов, накладные расходы на метаданные и стабильность системы.

В этом разделе перечислены самые частые проблемы раскладки данных, возникающие в промышленных таблицах Iceberg. Вы узнаете, как мелкие файлы увеличивают файловый ввод-вывод, как показано на рис. 10.1; как плохая группировка данных ведёт к неэффективным сканированиям; и как избыточное накопление метаданных нагружает каталог. Мы также рассмотрим влияние паттернов Merge-on-Read на производительность чтения по мере накопления файлов удалений. Распознавание этих проблем - первый шаг к поддержанию быстрого и экономичного lakehouse.

10.1.1 Мелкие файлы

Одна из самых частых ловушек производительности в lakehouse на Iceberg - бесконтрольное накопление мелких файлов данных. Обычно они появляются из потоковых или микропакетных конвейеров приёма, часто фиксирующих данные небольшими порциями. Iceberg обрабатывает такие записи корректно и транзакционно, но в долгосрочной перспективе таблица может состоять из огромного числа мелких файлов Parquet вместо меньшего набора хорошо сбалансированных файлов. Это состояние выявляется при изучении таблиц метаданных Iceberg, о которых пойдёт речь далее в этой главе. Например, запрос к таблице метаданных files покажет общее число файлов и распределение размеров, выделив таблицы, где гранулярность файлов работает против эффективности запросов.

Что считать «мелким файлом», сильно зависит от системы хранения. В средах на HDFS файлы значительно меньше размера блока HDFS неэффективны. В облачном объектном хранилище ситуация иная: ограничения на размер блока нет, а движки всё лучше переносят мелкие файлы. Но даже в облаке очень большое число файлов создаёт накладные расходы. Основная проблема не в «сырой» пропускной способности ввода-вывода, а в совокупной стоимости открытия файлов и координации чтений. Движкам запросов всё равно нужно перечислять файлы, делать вызовы API объектного хранилища и планировать работу, часто в частично последовательных процессах. Эти фиксированные издержки могут доминировать во времени выполнения запроса задолго до того, как узким местом станет полоса пропускания.

Помимо издержек выполнения, мелкие файлы порождают более фундаментальную и стойкую проблему - рост метаданных. Iceberg отслеживает каждый файл данных с сопутствующей статистикой, сведениями о партиции и ссылками в манифестах. По мере роста числа файлов растут манифесты и структуры метаданных. Это увеличивает время планирования, стоимость сканирования метаданных и издержки координации с каталогом. В отличие от неэффективности выполнения, рост метаданных не временный: он накапливается и требует активного управления. Улучшения в раскладке метаданных и планировании делают его менее заметным, но нижележащая стоимость никуда не исчезает.

Мелкие файлы не порочны сами по себе. Конвейерам приёма с низкой задержкой часто нужны частые коммиты и мелкие файлы, чтобы соответствовать требованиям к свежести. Проблема возникает, когда такие файлы оставляют без управления. Компактизация остаётся критически важной операцией обслуживания в lakehouse на Iceberg: она объединяет файлы, сдерживая рост метаданных и снижая издержки планирования, сохраняя при этом корректность и доступность данных. Далее в этой главе мы подробнее разберём стратегии компактизации и их компромиссы.

10.1.2 Плохо сгруппированные данные

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

Например, представьте набор данных о продажах, партиционированный по region, но часто запрашиваемый по customer_id или product_category. Поскольку столбец партиционирования не совпадает с условием фильтрации, движки запросов не могут эффективно отсекать ненужные файлы. Вместо этого им приходится читать из множества партиций, чтобы найти записи по конкретному клиенту или товару. Это увеличивает файловый ввод-вывод, потребление CPU и общую задержку запроса.

Даже внутри одной партиции плохая группировка данных ведёт к неэффективности. Принимаемые записи могут поступать в полуслучайном порядке, особенно при потоковой или распределённой записи, из-за чего теряется локальность. Это ухудшает сжатие по столбцам и мешает движку пропускать данные по статистике файлов или групп строк. Итог предсказуем: более долгие запросы, более высокие затраты и потраченные впустую ресурсы.

Проблемы группировки часто проявляются постепенно. Таблица может начинаться с хорошего партиционирования, но объёмы данных и шаблоны доступа со временем меняются. Кроме того, обновления и удаления дополнительно фрагментируют записи, особенно если выполняются по семантике Merge-on-Read (MOR), которая добавляет файлы удалений вместо переписывания данных.

Устранение проблем группировки требует переосмысления того, как данные группируются при приёме и как раскладываются со временем. Iceberg поддерживает это через эволюцию партиционирования, позволяя командам менять стратегии партиционирования по мере изменения характеристик данных и шаблонов доступа, не переписывая исторические данные. Это позволяет вводить более подходящие схемы партиционирования по мере взросления нагрузок или изменения шаблонов запросов.

Одного партиционирования часто недостаточно. Iceberg также поддерживает порядки сортировки, определяющие физический порядок записей внутри файлов данных. При грамотном применении порядки сортировки улучшают локальность данных, группируя похожие записи внутри файлов, сокращая объём сканируемых данных для диапазонных запросов и повышая эффективность кеша. Задачи компактизации могут использовать эти порядки сортировки, переписывая множество мелких или плохо организованных файлов в меньшее число хорошо структурированных.

Помимо простой сортировки, растёт интерес к более продвинутым приёмам кластеризации, например к кривым, заполняющим пространство, для оптимизации многомерных шаблонов доступа (так, Dremio ввёл автокластеризацию для таблиц Iceberg, работающую подобно liquid clustering в Databricks для таблиц Delta). Поддержка таких подходов в Iceberg ещё развивается, но предстоящая работа, особенно в Iceberg v4, нацелена на то, чтобы упростить сбор более богатой статистики и внедрение более изощрённых стратегий кластеризации. Вместе эволюция партиционирования, порядки сортировки и компактизация дают мощный набор инструментов для улучшения группировки данных, сокращения лишних сканирований и поддержания производительности на масштабе, как показано на рис. 10.3.

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

10.1.3 Разрастание метаданных

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

Чтобы понять, как возникает разрастание метаданных, полезно сначала разобраться в том, как Apache Iceberg структурирует метаданные таблицы. Каждая таблица Iceberg ведёт последовательность снимков, и каждый снимок указывает ровно на один список манифестов. Этот список ссылается на набор файлов манифестов, а каждый манифест отслеживает группу файлов данных, включая сводки по партициям, статистику по столбцам и пути к файлам. На верхнем уровне файл metadata.json хранит историю снимков таблицы, версии схемы, спецификации партиционирования и другие метаданные уровня таблицы.

В здоровой таблице рост метаданных пропорционален росту данных. По мере добавления новых файлов данных создаются новые записи манифестов, а снимки фиксируют меняющееся состояние таблицы. Такой рост ожидаем и необходим. Проблемы возникают не из-за того, что метаданные растут, а из-за того, что они растут неэффективно. Высокочастотные задачи приёма, особенно потоковые конвейеры или конвейеры, близкие к реальному времени, часто создают множество снимков, каждый из которых фиксирует лишь небольшое число файлов данных. Поскольку большинство потоковых движков не сливают манифесты при записи, каждый коммит обычно порождает новые файлы манифестов и новую запись о снимке в metadata.json.

Со временем это приводит к двум связанным формам раздувания метаданных. Во-первых, растёт число файлов манифестов, даже если каждый описывает лишь горстку файлов данных. Во-вторых, что критичнее, удлиняется история снимков в metadata.json. Каждый запрос должен прочитать текущие метаданные таблицы, чтобы определить активный снимок, а каждый коммит - обновить и переписать этот файл. По мере роста списка снимков растут и стоимость чтения, и стоимость записи, даже если раскладка данных остаётся эффективной.

Списки манифестов и файлы манифестов Iceberg содержат сводки по партициям, позволяющие движкам пропускать нерелевантные манифесты при планировании запроса, но система всё равно несёт издержки на загрузку и обход этих метаданных. В первую очередь это сказывается на задержке планирования запросов и операциях управления снимками. Особенно затронуто истечение срока действия снимков, поскольку оно должно пройти по историческим снимкам и связанным метаданным, чтобы безопасно удалить файлы без ссылок. Откаты и эволюция схемы обычно страдают меньше - сверх базовой стоимости чтения и записи более крупных файлов метаданных.

Борьба с разрастанием метаданных требует явного управления снимками и манифестами. Одной компактизации файлов данных недостаточно. Iceberg даёт механизмы переписывания и компактизации манифестов, снижая фрагментацию и объединяя метаданные, описывающие одни и те же наборы файлов данных. Не менее важно удалять старые снимки, чтобы сдерживать рост metadata.json и ограничивать историческую поверхность, которой должен управлять каталог. Такие инструменты, как процедура RewriteManifests в Spark или процессы OPTIMIZE в Dremio, помогают держать метаданные компактными, обеспечивая эффективное развитие таблицы при росте частоты и масштаба приёма.

На рис. 10.5 показана более удачная раскладка метаданных.

10.1.4 Просадки производительности при Merge-on-Read

Merge-on-Read (MOR) - мощная возможность Apache Iceberg, обеспечивающая эффективную обработку обновлений и удалений за счёт записи изменений в виде инкрементальных файлов удалений вместо переписывания целых файлов данных. Такой подход существенно снижает усиление записи и повышает пропускную способность приёма, особенно при частых обновлениях. Но не все файлы удалений ведут себя одинаково, и понимание различий критично для управления производительностью чтения.

Iceberg поддерживает два типа файлов удалений: позиционные удаления и удаления по равенству. Позиционные удаления указывают конкретные строки к удалению по их физической позиции в файле данных, что позволяет движкам эффективно отфильтровывать удалённые строки при чтении. Удаления по равенству, напротив, задают удаление по значениям столбцов, вынуждая движки вычислять предикаты удаления по данным во время выполнения запроса. Удаления по равенству гибче и проще порождаются некоторыми конвейерами приёма, но обычно дороже в обработке при чтении и труднее поддаются эффективной компактизации.

По мере накопления файлов удалений, особенно удалений по равенству, производительность чтения деградирует, поскольку запросам приходится сливать базовые файлы данных с несколькими слоями информации об удалениях. Этот компромисс присущ самой модели MOR. Напротив, Copy-on-Write (COW) применяет изменения, переписывая затронутые файлы данных в момент записи, полностью обходясь без файлов удалений, но повышая стоимость записи. На рис. 10.6 показаны поведенческие различия MOR и COW. Выбор между этими подходами требует балансировать пропускную способность записи, производительность чтения и эксплуатационную стоимость управления файлами удалений во времени.

В таблице MOR каждая операция чтения должна просканировать базовые файлы данных, а затем применить все релевантные файлы удалений, чтобы восстановить текущее представление данных. Такое динамическое слияние усложняет запросы и замедляет выполнение, особенно когда растёт число файлов удалений на файл данных. В нагрузках с высокой оборачиваемостью - частые upsert-операции или срочные обновления - эти издержки становятся серьёзным узким местом и для чтения, и для записи.

В таблицах Iceberg v2 эта проблема со временем усугубляется, потому что файлы удалений пишутся только на добавление. У старых базовых файлов данных могут накопиться десятки и даже сотни связанных файлов удалений. Каждый такой файл нужно прочитать, разобрать и применить при выполнении запроса, что увеличивает издержки чтения и снижает эффективность проталкивания предикатов и пропуска данных. Это поведение относится именно к файлам удалений и не переносится на векторы удалений Iceberg v3, которые избегают такого неограниченного накопления.

Распространённое заблуждение - думать, что отказ от MOR в пользу COW снимет эти сложности. В режиме COW обновления и удаления переписывают целые файлы данных, устраняя потребность в файлах удалений и упрощая чтение. Но это переносит стоимость на операции записи, которые становятся дорогими для больших часто изменяемых таблиц. На практике некоторые пользователи Iceberg v2 применяли гибридные схемы: MOR для инкрементальных обновлений и периодические переписывания в стиле COW ради компактизации данных и устранения накопившихся файлов удалений. Приём эффективный, но с Iceberg v3 он в основном теряет актуальность.

Выбор между MOR и COW должен определяться характером нагрузки, а не желанием избежать обслуживания. Эмпирические исследования и промышленный опыт указывают на точку перелома по плотности обновлений: если одна операция меняет более примерно 10 процентов строк в затронутых файлах, переписывание в стиле COW обычно эффективнее в целом. Ниже этого порога MOR чаще даёт лучшую производительность записи ценой дополнительной сложности при чтении. Понимание частоты обновлений, темпов изменений на уровне строк и шаблонов запросов необходимо для выбора верной стратегии под конкретную таблицу и нагрузку.

Правильное решение для управления производительностью MOR - компактизация. Iceberg поддерживает переписывание файлов данных и файлов удалений в свежие оптимизированные базовые файлы с помощью процедур вроде RewriteDataFiles. В ходе компактизации файлы удалений применяются к соответствующим файлам данных, а результат записывается как новые базовые файлы, уже не требующие динамического слияния. Это восстанавливает производительность чтения, не отказываясь от эффективности MOR для входящих записей.

Эффективные стратегии компактизации учитывают и объём файлов удалений, и свежесть данных. Например, можно чаще компактизировать партиции с высокой активностью удалений, откладывая менее активные области ради экономии ресурсов. Такие инструменты, как Apache Spark и Dremio, позволяют нацеливать компактизацию по партиции, размеру файла или метке времени, обеспечивая постепенную очистку без нарушения активных нагрузок.

MOR обеспечивает масштабируемые, эффективные на запись таблицы, но его нужно сочетать со стратегией компактизации ради производительности чтения. Игнорирование компактизации ведёт к росту задержек и напрасной трате ресурсов. Распознавание признаков деградации MOR - замедления запросов, роста задержки планирования, увеличения числа некомпактизированных файлов удалений или быстрого разрастания таблицы - необходимо для поддержания высокопроизводительного lakehouse на Iceberg.

10.2 Решение: компактизация

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

Результат - раскладка, более эффективная для планирования и выполнения запросов: меньше файлов для открытия, лучшая группировка данных и метаданные, которые проще обрабатывать движкам и каталогам. При регулярном и продуманном применении компактизация помогает таблице Iceberg оставаться производительной и управляемой по мере её развития, как показано на рис. 10.7.

Компактизация улучшает производительность, но приносит и компромиссы. Переписывание файлов потребляет вычислительные ресурсы, может влиять на параллельные нагрузки и требует аккуратного управления ради соблюдения SLA и ограничений по пропускной способности. Выбор того, какие файлы компактизировать, какого размера делать результат и когда запускать задачи, - всё это критичные решения, влияющие на эффективность lakehouse.

В следующих разделах мы разберём ключевые параметры компактизации: как определять целевой размер файлов, выбирать файлы для переписывания и использовать фильтры и нацеливание на партиции для инкрементальных задач компактизации. Вместе эти стратегии образуют фундамент здорового, сопровождаемого развёртывания Iceberg.

10.2.1 Что такое компактизация?

По сути компактизация - процесс переписывания, оптимизирующий физическое хранение данных ради производительности чтения и снижения издержек на метаданные. В ходе компактизации Apache Iceberg может выполнить несколько улучшений: слить мелкие или чрезмерно крупные файлы в более сбалансированные сегменты, применить лучшее сжатие, отсортировать записи ради локальности данных, объединить файлы удалений в таблицах MOR и обновить статистику на уровне файлов. Эти преобразования сокращают число файлов, которые должны сканировать движки, улучшают проталкивание предикатов и снижают задержку планирования запросов, что делает компактизацию ключевой задачей обслуживания любого lakehouse на Iceberg.

Открытые библиотеки Iceberg поддерживают две основные процедуры компактизации: rewrite_data_files и rewrite_manifests. Они доступны при использовании Apache Spark со средой выполнения Iceberg для Spark. Другие движки могут реализовывать эти процедуры, как Trino, или предлагать похожие, как Dremio с OPTIMIZE. Процедура rewrite_data_files поддерживает стратегии bin-pack и sort:

• Bin-pack - стратегия по умолчанию. Она нацелена на объединение мелких файлов в новые файлы целевого размера, избавляя от дорогих открытий файлов и издержек на метаданные.
• Сортирующая компактизация идёт дальше, переупорядочивая записи по одному или нескольким столбцам. Это улучшает локальность и ускоряет фильтрующие запросы. Например, сортировка по event_date или Z-порядок по нескольким измерениям повышает эффективность отсечения.

Каждую процедуру компактизации можно тонко настроить такими параметрами:

• target-file-size-bytes - управляет размером выходных файлов
• min-input-files и max-file-size-bytes - определяют, какие файлы пригодны для переписывания
• where - ограничивает компактизацию конкретными партициями или отфильтрованными подмножествами данных
• remove-dangling-deletes - очищает неиспользуемые файлы удалений от прежних обновлений

Вот пример bin-pack компактизации таблицы Iceberg с помощью Spark SQL:

CALL catalog_name.system.rewrite_data_files('db.sales');

Следующий пример использует сортирующую компактизацию с Z-упорядочиванием:

CALL catalog_name.system.rewrite_data_files(
   table =>'db.sales',
   strategy =>'sort',
   sort_order =>'zorder(customer_id, product_id)'
);

В средах на Dremio компактизация доступна через SQL-команду OPTIMIZE TABLE. Эта команда поддерживает похожие параметры настройки:

OPTIMIZE TABLE demo.example_table
 REWRITE DATA USING BIN_PACK (TARGET_FILE_SIZE_MB = 512);

В обоих движках компактизация может включать и оптимизацию метаданных: добавлением REWRITE MANIFESTS в Dremio или вызовом процедуры rewrite_manifests в Spark. Компактизация необходима, но переписывать все файлы требуется не всегда. Выборочная компактизация - например, только активно запрашиваемой партиции или файлов меньше определённого размера - обеспечивает инкрементальную оптимизацию, согласованную с требованиями соглашения об уровне обслуживания (SLA) и доступной мощностью кластера:

CALL catalog_name.system.rewrite_manifests('db.sales');

При регулярном применении компактизация сохраняет ваши таблицы Iceberg компактными, удобными для запросов и экономными по ресурсам даже при росте объёма и сложности данных.

10.2.2 Целевой размер файла

Центральное решение при планировании компактизации - определение целевого размера и структуры выходных файлов, и особенно размера групп строк внутри них. Сокращение числа файлов снижает издержки планирования и ввода-вывода, но чрезмерно большие группы строк могут привести к нехватке памяти в движке или сбросу на диск, поскольку группы строк неделимы при выполнении. Сами файлы делимы, но неудачно подобранные размеры групп строк ограничивают параллелизм и увеличивают нагрузку на ресурсы. Выбор подходящих размеров файлов и групп строк напрямую влияет на производительность, масштабируемость и стабильность ваших таблиц Iceberg.

Целевой размер файла в Apache Iceberg по умолчанию - 512 МБ, задаётся свойством таблицы write.target-file-size-bytes. Для отдельных крупномасштабных нагрузок это может подходить, но многие промышленные среды получают лучшие результаты с файлами меньшего размера. Меньшие файлы снижают стоимость повторных чтений и записей при компактизации и лучше согласуются с тем, что параллелизм определяется размером групп строк, а не файла. Чрезмерно крупные файлы также замедляют компактизацию и повышают нагрузку на память при чтении. Выбор размера файла, балансирующего издержки на метаданные и эффективность переписывания, критичен для устойчивой производительности во времени.

Но это значение по умолчанию - не универсальное решение. Идеальный целевой размер файла зависит от нескольких факторов:

• Особенности движка запросов - одни движки работают с крупными файлами лучше других. Например, Dremio и Trino эффективно сканируют файлы до 1 ГБ и больше, а другим полезнее меньшие файлы, лучше помещающиеся в память.
• Сжатие - фактический размер файла на диске зависит от сжатия. Хорошо сжимаемые данные дают меньшие файлы даже при большом числе записанных строк.
• Ширина таблицы и форма данных - широким таблицам со множеством столбцов или вложенных структур могут подойти чуть меньшие файлы, чтобы избежать чрезмерного расхода памяти при выполнении запроса.
• Сортировка - в системах с ограниченной памятью исполнителей или полосой ввода-вывода меньший целевой размер файла (например, 128–256 МБ) помогает избежать узких мест и сбоев запросов.

Задать целевой размер файла для компактизации в Spark можно так:

CALL catalog_name.system.rewrite_data_files(
 table =>'db.sales',
 options =>map('target-file-size-bytes', '268435456')
);

В Dremio можно использовать следующее:

OPTIMIZE TABLE db.sales 
 REWRITE DATA USING BIN_PACK (TARGET_FILE_SIZE_MB = 256);

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

Наблюдение за поведением движка запросов - параллелизмом, пропускной способностью ввода-вывода и планами выполнения - самый действенный способ проверить, даёт ли ваша стратегия компактизации и выбранные размеры файлов реальный прирост производительности. Таблицы метаданных Iceberg покажут, сходятся ли файлы к нужному размеру, но сами по себе не подтвердят, что движок выигрывает от этих изменений. Изучение планов запросов в Spark, Trino или Dremio даёт прямое понимание того, улучшает ли раскладка файлов эффективность сканирования, сокращает ли сброс на диск и максимизирует ли параллелизм задач.

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

10.2.3 Какие файлы включать

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

Процедуры компактизации в движках вроде Spark и Dremio используют стратегию группировки файлов при планировании задач. Вместо оценки пользы от каждого файла по отдельности движок сначала перечисляет все подходящие файлы, а затем группирует их в наборы по ограничениям конфигурации вроде max-file-group-size-bytes. Эти группы становятся единицами работы компактизации и обрабатываются независимо ради параллелизма и контроля роста метаданных.

Влиять на формирование групп файлов можно такими параметрами:

• min-input-files или MIN_INPUT_FILES - задаёт минимальное число файлов, которое должно быть в группе, чтобы её компактизировали. В основном это способ управлять гранулярностью и параллелизмом задач компактизации, а не оценивать её необходимость. Фактическое решение о включении файлов принимается раньше, на этапе планирования.
• max-file-size-bytes и min-file-size-bytes - эти пороги обычно применяются на этапе отбора файлов, чтобы определить, какие из них пригодны для компактизации. Например, слишком мелкие файлы включаются ради сокращения их числа и издержек на метаданные, а очень крупные могут разбиваться ради эффективности использования памяти и параллелизма сканирования.
• rewrite-job-order - эта настройка управляет порядком компактизации групп файлов. Приоритет можно отдать самым мелким файлам, самым крупным или размеру группы (наименьшему или наибольшему числу файлов) - в зависимости от того, хотите ли вы сократить издержки на метаданные, улучшить баланс ввода-вывода или распределить стоимость компактизации по нескольким запускам.

Эти настройки дают свободу балансировать эффективность, пропускную способность и эксплуатационную стоимость при компактизации таблиц Iceberg.

Например, в Spark можно использовать такой код:

CALL catalog_name.system.rewrite_data_files(
 table =>'db.sales',
 options =>map(
   'min-file-size-bytes', '134217728',        -- 128 MB
   'max-file-size-bytes', '1073741824',       -- 1 GB
   'min-input-files', '5'
 )
);

В Dremio эквивалент будет таким:

OPTIMIZE TABLE db.sales
 REWRITE DATA USING BIN_PACK (
   MIN_FILE_SIZE_MB = 128,
   MAX_FILE_SIZE_MB = 1024,
   MIN_INPUT_FILES = 5
 );

Выбор более узкого диапазона между минимальным и максимальным размерами файлов - сравнительно высокий min-file-size и низкий max-file-size - расширяет пул файлов, пригодных для компактизации, захватывая больше файлов вне оптимальных границ. Это повышает вероятность всесторонней оптимизации, но может привести к более крупным и долгим задачам компактизации, потребляющим больше ресурсов и способным повлиять на доступность системы или нижестоящие задачи.

Напротив, более широкий диапазон, где min-file-size низкий, а max-file-size высокий, исключит из компактизации многие файлы, сосредоточившись только на самых мелких и самых крупных выбросах. Это сокращает время выполнения и потребление ресурсов, что подходит средам с узкими эксплуатационными окнами или там, где компактизация идёт параллельно с непрерывным приёмом. Но при этом часть неэффективности останется неустранённой. Найти верный баланс особенно важно в потоковых сценариях, где компактизация должна быть и результативной, и не мешающей работе.

Чтобы справиться с этим, обычно планируют инкрементальные задачи компактизации, выполняющиеся часто с более узкими порогами. Такие задачи постепенно возвращают таблицу в оптимизированное состояние, не требуя переписывания всей таблицы. В сочетании с запросами к таблицам метаданных для выявления кандидатов на компактизацию эта стратегия становится мощным механизмом поддержания производительности без нарушения SLA.

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

10.2.4 Использование фильтров для ограничения области компактизации

Задачи компактизации бывают ресурсоёмкими, особенно в больших таблицах с тысячами файлов во множестве партиций. Переписывание всех подходящих файлов сразу может быть неосуществимо в рабочие часы или на общей инфраструктуре. Для этого Iceberg поддерживает механизмы фильтрации, позволяющие нацелить компактизацию на конкретные подмножества данных - по партиции, временному окну или бизнес-логике.

И Spark, и Dremio поддерживают фильтрацию задач компактизации SQL-подобными предикатами. Это даёт стратегии инкрементальной оптимизации, локализующие эффект переписывания и сохраняющие время выполнения коротким, а вычислительные затраты - управляемыми.

Например, в Spark нацелиться на конкретную партицию можно параметром where:

CALL catalog_name.system.rewrite_data_files(
 table =>'db.sales',
 where =>"region = 'us-west'");

Эта команда ограничивает задачу компактизации переписыванием только файлов данных в партиции us-west, не трогая остальные партиции.

Можно использовать и составные фильтры:

where =>"region = 'us-west' AND sale_date >= '2024-01-01'"

Dremio предлагает похожую возможность через предложение FOR PARTITIONS:

OPTIMIZE TABLE db.sales
 REWRITE DATA USING BIN_PACK
 FOR PARTITIONS region = 'us-west'

Эти возможности фильтрации особенно полезны в следующих случаях:

• Вы хотите сосредоточить компактизацию на горячих партициях с частыми записями или обновлениями.
• Вы проводите обслуживание поэтапно, чтобы избежать долгих задач.
• Вы работаете с партиционированными таблицами и должны соблюдать SLA в критичные для бизнеса периоды.

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

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

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

10.3 Управление объёмом хранения и удержание данных

Поддержка путешествий во времени и изоляции снимков в Apache Iceberg - одна из его мощнейших возможностей, позволяющая запрашивать исторические состояния таблицы и откатывать нежелательные изменения, как показано на рис. 10.8. Но у этой функциональности есть цена: данные и метаданные сохраняются между снимками, из-за чего объём хранения таблицы со временем растёт. Логически удалённые файлы могут физически существовать, пока их явно не удалят.

В этом разделе объясняется, как Iceberg обходится с удержанием данных, какие механизмы доступны для удаления ненужных файлов и как балансировать соответствие нормативным требованиям и экономичность. Без регулярной очистки накопление старых снимков и файлов без ссылок ведёт к росту затрат на хранение и деградации производительности таблиц.

Мы начнём с истечения срока действия снимков - основного механизма очистки устаревших данных и метаданных. Затем разберём, как выбранный режим записи, Copy-on-Write (COW) или Merge-on-Read (MOR), влияет на время жизни файлов и поведение при удалении. Наконец, рассмотрим соображения соответствия нормативным требованиям, включая GDPR и другие предписания, требующие безвозвратного удаления пользовательских данных.

10.3.1 Запуск истечения срока действия снимков

Ради путешествий во времени и изоляции снимков Apache Iceberg сохраняет полную родословную метаданных и связанных файлов данных для всех операций с таблицей. Со временем эти исторические снимки накапливаются, потребляя и место в хранилище, и время на обработку метаданных. Такие снимки полезны для отката и аудита, но в конечном счёте их нужно очищать, чтобы поддерживать здоровую среду lakehouse. Здесь и вступает в игру истечение срока действия снимков.

Истечение срока действия снимков удаляет старые снимки таблицы, а также файлы данных и метаданных, связанные исключительно с ними, как показано на рис. 10.9. Существенно, что Iceberg гарантирует: ни один файл, нужный активному или сохраняемому снимку, не будет удалён. Это гарантирует надёжность и воспроизводимость запросов даже при усечении истории.

Истечение срока действия снимков в Spark

В Spark эту задачу решает хранимая процедура expire_snapshots. Её можно вызывать с разными параметрами, управляя тем, насколько агрессивно удаляются снимки. Самый распространённый шаблон задаёт временную границу и сохраняет минимальное число недавних снимков:

CALL catalog_name.system.expire_snapshots(
 table =>'db.sales',
 older_than =>TIMESTAMP '2024-06-01 00:00:00.000',
 retain_last =>20
);

Этот вызов удаляет все снимки старше 1 июня 2024 года, обеспечивая сохранение как минимум последних 20 снимков. В промышленных системах эту процедуру обычно настраивают на периодический запуск - по временным окнам или по сигналу от мониторинга таблиц метаданных.

Есть и дополнительные параметры:

• snapshot_ids - напрямую удалить конкретные снимки.
• clean_expired_metadata - удалить спецификации партиционирования и схемы без ссылок.
• max_concurrent_deletes - распараллелить операции удаления ради ускорения очистки.
• stream_results - передавать результаты удаления потоком, чтобы избежать проблем с памятью драйвера Spark.

Эти параметры дают эксплуатационную гибкость и позволяют истечению снимков масштабироваться вместе с размером таблицы и мощностью системы.

Истечение срока действия снимков в Dremio

В Dremio истечение снимков выполняется командой VACUUM TABLE:

VACUUM TABLE s3.sales EXPIRE SNAPSHOTS older_than '2024-06-01 00:00:00.000' retain_last 20;

Эффект тот же, что и у процедуры Spark: удаляются снимки старше указанной даты с сохранением базового числа недавних снимков. Если параметры не заданы, Dremio использует политику по умолчанию: сохранить последний снимок и удалить снимки старше пяти дней.

Результат этих операций включает число удалённых файлов данных, файлов удалений, файлов манифестов и файлов статистики, помогая командам понять эффект истечения снимков для использования хранилища.

Соображения

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

Истечение снимков влияет и на долгие запросы. Запрос привязан к снимку, актуальному на момент его старта. Если срок этого снимка истечёт, пока запрос ещё выполняется, запрос может завершиться сбоем. Поэтому интервалы истечения должны учитывать не только требования управления данными, но и поведение нагрузок. Например, если на потоковой таблице снимки истекают каждый час, ни один запрос к ней не может безопасно выполняться дольше часа. Чтобы избежать непреднамеренных сбоев, необходима аккуратная координация политик истечения и характеристик выполнения запросов.

В средах с высоким объёмом транзакций частое истечение снимков помогает предотвратить раздувание хранилища и сохраняет операции с метаданными быстрыми. Для медленно меняющихся таблиц истечение может происходить реже, но его всё равно следует включать в регулярное обслуживание. В сочетании с удалением файлов-сирот (описано далее) истечение снимков - необходимый шаг поддержания экономичного и производительного lakehouse на Iceberg.

10.3.2 COW против MOR: последствия для удержания данных

Apache Iceberg поддерживает два основных режима записи: COW и MOR. Оба обеспечивают ACID-операции и изоляцию снимков, но существенно различаются тем, как обновления и удаления физически применяются к данным. Эти различия напрямую влияют на удержание файлов и стратегии очистки хранилища.

#### Copy-on-Write

COW - режим записи по умолчанию в Apache Iceberg. В этой модели операции обновления и удаления порождают новые файлы данных, отражающие нужные изменения, - с удалёнными или изменёнными строками. Вместо переписывания существующих файлов движок пишет новые с применёнными изменениями. Затем метаданные таблицы обновляются так, чтобы ссылаться на новые файлы в новом снимке, а исходные файлы остаются в ссылках предыдущего снимка ради сохранения путешествий во времени.

Поскольку удаления физически применяются в момент записи, таблицы COW не накапливают отдельных файлов удалений, как таблицы MOR. Вместо этого у них накапливаются заменённые файлы данных: файлы, которые становятся ненужными, как только истекает срок ссылающихся на них снимков. Такая тесная связь между файлами данных и манифестами гарантирует, что сохраняются только файлы, на которые активно ссылаются метаданные.

Например, операция удаления в COW:

1. Создаст новый файл данных без удалённых строк
2. Запишет этот файл в новый манифест, на который ссылается последний снимок
3. Оставит исходный файл в ссылках предыдущего снимка, пока тот явно не истечёт

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

#### Merge-on-Read

Операции MOR лучше всего подходят нагрузкам, изменяющим лишь малую долю существующих данных, где минимизация усиления записи важнее немедленной реорганизации файлов. Типичные примеры - запросы на удаление по GDPR, исправление ограниченного набора записей или инкрементальные обновления метрик для небольшой группы сущностей вроде датчиков или профилей пользователей. Вместо переписывания целых файлов данных ради этих изменений операции в стиле MOR фиксируют обновления отдельно, откладывая реорганизацию.

В таблицах Iceberg v2 такие изменения фиксируются файлами удалений - позиционными, помечающими конкретные позиции строк внутри файла данных, или по равенству, определяющими строки к удалению по значениям столбцов. Во время запроса движки динамически применяют эти удаления, отфильтровывая затронутые строки. В Iceberg v3 похожие процессы реализуются векторами удалений, связывающими информацию об удалении напрямую с файлами данных и избегающими неограниченного накопления артефактов удаления. В обеих версиях замысел один: эффективно обрабатывать разреженные инкрементальные изменения, откладывая более тяжёлую работу по переписыванию на компактизацию или обслуживание.

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

В таблицах Iceberg v2 базовый файл данных нельзя физически удалить, пока не истекут все снимки, ссылающиеся на любые связанные артефакты удаления - позиционные или по равенству. Удаления по равенству особенно склонны переиспользоваться между снимками, что может непреднамеренно продлевать жизнь уже устаревшим файлам данных. Даже если большинство исторических снимков истекли, одно долгоживущее удаление по равенству способно помешать очистке. Эта связанность удержания - одна из причин, по которым Iceberg v3 вводит векторы удалений, локализующие состояние удаления в отдельных файлах данных и избегающие неограниченного накопления, свойственного файлам удалений.

Например, если файл позиционных удалений, появившийся в снимке 103, всё ещё упоминается в снимке 110, истечение снимков со 101 по 105 не приведёт к очистке ни базового файла, ни файла удалений. Это ведёт к росту использования хранилища даже при идущем истечении снимков.

Чтобы смягчить это, Iceberg предоставляет процедуру rewrite_position_delete_files, которая компактизирует и перестраивает файлы удалений. Этот процесс помогает устранить «висящие» удаления - файлы удалений, которые больше не соответствуют ни одному живому файлу данных, - сокращая издержки хранения и улучшая производительность планирования.

Эксплуатационные рекомендации

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

• Согласуйте истечение снимков с поведением запросов и частотой записи.
  Регулярное истечение снимков необходимо для контроля роста метаданных, но интервалы должны отражать реальность нагрузки. Для нагрузок, где преобладают операции переписывания, обычно достаточно удалять снимки раз в сутки. Для часто изменяемых таблиц с частыми инкрементальными обновлениями обычно требуется более агрессивное истечение.
  У истечения снимков есть важное эксплуатационное ограничение: запрос не может выполняться дольше окна удержания снимка, с которого он начался. Если снимки истекают каждый час, любой запрос к этой таблице должен завершиться в течение часа, иначе рискует упасть. Поэтому критично согласовывать политики истечения не только с темпом приёма, но и со временем выполнения запросов и эксплуатационными SLA.
  Само по себе истечение снимков не сокращает объём данных и метаданных, если не сочетается с компактизацией. Истечение убирает исторические ссылки, но очистка файлов и консолидация метаданных происходят лишь тогда, когда переписанные файлы перестают быть востребованными.
• Управляйте частотой компактизации и избегайте коллизий с записью.
  Компактизация необходима для контроля артефактов удаления, числа файлов и роста метаданных, но её нужно аккуратно координировать с приёмом. Одна из самых частых эксплуатационных ловушек - коллизии задач компактизации с активными писателями, когда обе стороны пытаются переписать пересекающиеся данные одновременно.
  Чтобы смягчить это:
• Предпочитайте компактизировать закрытые или стабильные партиции - например, партиции по времени, в которые уже не пишут.
• Избегайте компактизации партиций, в которые активно идёт приём, если только движок не поддерживает безопасную координацию.
• По возможности планируйте компактизацию в предсказуемые окна с малым числом записей.
• Для часто изменяемых таблиц компактизацию может понадобиться запускать часто, но частота должна соответствовать темпу записи. Запускать компактизацию каждые 5 минут имеет смысл, только если таблица получает новые коммиты каждые несколько десятков секунд. Иначе задачи компактизации добавят издержки без ощутимой пользы.
• Следите за трендами на уровне таблиц и партиций, а не только за числом файлов.
  Эксплуатационный мониторинг должен смотреть на агрегированные тренды, а не на отдельные метрики. Артефакты удаления и число файлов естественно растут между циклами компактизации и уменьшаются после. Здоровая система обычно демонстрирует пилообразную картину, где метаданные и число файлов предсказуемо растут и падают.
  Тревожные признаки:
• Артефакты удаления только растут и никогда не сокращаются.
• Число снимков растёт быстрее, чем ожидалось.
• Файлы метаданных становятся крупными даже при стабильном объёме данных.
• Эти картины обычно указывают на рассогласованное расписание компактизации, слишком консервативное истечение снимков или более частые коммиты при приёме, чем необходимо.
• Используйте теги снимков осознанно и экономно.
  Теги и ветки снимков - мощные инструменты воспроизводимости, аудита и контролируемого отката, но они напрямую влияют на удержание. Любой снимок, защищённый тегом или веткой, не подлежит истечению, что может помешать очистке файлов данных и метаданных.
  Для быстро меняющихся таблиц лучшая практика такова:
• Ставьте теги после крупных событий компактизации, чтобы сохранённые снимки ссылались на оптимизированные раскладки.
• Избегайте тегирования снимков с большим числом мелких файлов или артефактов удаления.
• Используйте теги выборочно для чётко определённых целей вроде аудитов или дозагрузок, а не как общий механизм удержания.
• Поскольку теги и ветки - якоря удержания, их следует рассматривать как часть эксплуатационного жизненного цикла, а не как пассивные метаданные.
• Относитесь к удержанию, компактизации и приёму как к единой системе.
  Истечение снимков, компактизацию и приём нельзя настраивать по отдельности. Истечение снимков ограничивает рост метаданных, но ограничивает и время выполнения запросов. Компактизация улучшает эффективность чтения, но может конфликтовать с активными записями. Частота приёма определяет и рост числа снимков, и накопление артефактов удаления.
  Поддержание производительного lakehouse на Iceberg требует координации всех трёх. Настроенные совместно с учётом темпа записи, поведения запросов и требований к удержанию, эти механизмы сохраняют таблицы эффективными, предсказуемыми и экономичными даже при устойчиво высоких нагрузках приёма.

10.3.3 Нормативные аспекты удаления данных

По мере роста объёмов данных растут и юридические обязательства по обращению с персональной и чувствительной информацией. Такие нормы, как Общий регламент по защите данных (GDPR), Закон Калифорнии о конфиденциальности потребителей (CCPA) и другие, требуют от организаций обеспечивать безвозвратное удаление определённых пользовательских данных по запросу. Это создаёт особые сложности в системе вроде Apache Iceberg, которая спроектирована сохранять историю данных ради изоляции снимков и путешествий во времени.

В Iceberg операции удаления не убирают файлы из хранилища немедленно. Вместо этого они обновляют метаданные таблицы, исключая определённые записи или файлы из будущих снимков. Физическое удаление данных происходит только после истечения соответствующих снимков и компактизации файлов данных. Такая модель отложенного удаления полезна для производительности и проверяемости, но усложняет соблюдение норм, требующих своевременного и безвозвратного стирания.

Согласование истечения снимков с нормативными требованиями

Чтобы соответствовать нормам об удалении данных вроде GDPR или CCPA, недостаточно логически пометить данные как удалённые; нужно также убедиться, что удалены все физические ссылки на эти данные. В Apache Iceberg это требует нескольких шагов:

• Удалить снимки, ссылающиеся на записи субъекта данных. Снимки сохраняют ссылки на файлы данных, поэтому пока существует снимок, данные, на которые он ссылается, остаются доступными.
• Часто компактизировать, особенно в таблицах MOR. Файлы удалений в режиме MOR содержат указатели на строки в базовых файлах данных, а не сами данные, поэтому нужна компактизация, чтобы физически переписать эти базовые файлы без удалённых строк.
• Убедиться, что ни один сохраняемый снимок не ссылается на старые файлы. Даже если компактизация переписала файл, он не будет удалён, пока не истекут все снимки, ссылающиеся на исходную версию.
• Запустить очистку файлов-сирот после истечения снимков и компактизации, чтобы удалить из хранилища файлы без ссылок.

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

Соображения для таблиц Merge-on-Read

В таблицах MOR операции удаления порождают отдельные файлы удалений, а не изменяют базовые файлы данных напрямую. Эти файлы удалений могут сохраняться во множестве снимков, из-за чего удалённые записи оказываются долговечнее, чем предполагалось, если не запускать процедуры очистки. Ради соответствия нормативным требованиям, особенно по запросам на удаление данных, важно делать следующее:

• Запускать встроенные процедуры Iceberg (такие как rewrite_position_delete_files и expire_snapshots), чтобы удалить устаревшие записи об удалении и ссылки на них.
• Убедиться, что компактизация переписала базовые файлы, так что удалённые строки удалены физически, а не просто отфильтрованы логически при запросе.
• Подтвердить, что ни один из сохраняемых файлов данных больше не содержит удалённых строк и что все соответствующие снимки истекли.

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

Ветки, теги и удержание снимков

Ветки и теги в Iceberg позволяют пользователям сохранять альтернативные представления таблицы - например, для аудита или отката. Но снимки, на которые ссылаются ветки или теги, по умолчанию не истекают. Это может непреднамеренно сохранить данные далеко за пределами предполагаемого срока хранения.

Чтобы обеспечить соответствие требованиям:

• Регулярно проверяйте пользовательские ветки и теги и управляйте ими.
• Используйте свойство history.expire.max-ref-age-ms, чтобы задать автоматические политики истечения для веток и тегов там, где это уместно.

Рекомендуемые практики

• Автоматизируйте процессы истечения снимков, содержащих регулируемые данные.
• Избегайте долгоживущих веток для данных, связанных с персональной или чувствительной информацией.
• Интегрируйте системы управления запросами субъектов данных с инструментарием вашего lakehouse, чтобы оркестровать удаление в метаданных и хранилище.
• Отслеживайте и журналируйте события истечения, чтобы подтверждать соответствие при аудитах.

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

10.4 Изучение таблиц метаданных Apache Iceberg

Apache Iceberg собирает подробные метаданные для поддержки транзакционной модели, эволюции схемы, партиционирования и путешествий во времени на основе снимков. Помимо внутренней работы таблицы, эти метаданные доступны пользователям через набор таблиц метаданных. Эти особые таблицы дают прозрачный взгляд на внутреннее состояние таблицы Iceberg и доступны обычными SQL-запросами в движках вроде Spark, Trino, Flink и Dremio.

Таблицы метаданных Iceberg охватывают ряд эксплуатационных измерений, которые помогут лучше понять ваши таблицы:

• Сведения на уровне файлов - понять, как файлы данных распределены по партициям, каковы их размеры и связанная статистика.
• Видимость манифестов и снимков - изучить, как файлы данных группируются и версионируются между снимками.
• Отслеживание файлов удалений - следить за накоплением файлов удалений в таблицах MOR и определять, когда нужна компактизация.
• Эволюция и раскладка партиций - аудировать структуры партиций и выявлять фрагментацию или перекос.
• История и родословная снимков - отслеживать, как и когда менялись данные, поддерживая управление, аудит и откат.

Эти таблицы метаданных - мощный инструмент упреждающего обслуживания. Они позволяют инженерам обнаруживать накопление мелких файлов, отслеживать рост числа снимков, выявлять неоптимизированные партиции и запускать корректирующие действия вроде компактизации или истечения снимков. Встроив запросы к таблицам метаданных в конвейеры мониторинга или задачи по расписанию, вы автоматизируете значительную часть эксплуатационного ухода, необходимого для эффективного lakehouse.

Полный справочник по всем таблицам метаданных Iceberg, включая схемы и примеры использования, см. в приложении A.

В следующей главе мы выйдем за пределы базовых возможностей платформы и рассмотрим такие темы, как растущая экосистема Python для Iceberg и другие эксплуатационные и архитектурные соображения, дополняющие современное развёртывание Iceberg.

Итоги

• Iceberg управляет физическими файлами через структурированные связанные файлы метаданных, что делает обслуживание критически важной операцией.
• Компактизация необходима для управления издержками на метаданные, слияния изменений, удаления вычеркнутых строк и повышения производительности чтения, особенно в таблицах Merge-on-Read (MOR).
• Истечение срока действия снимков и сборка мусора предотвращают неограниченный рост метаданных и объёма хранимых файлов.
• Эффективные стратегии подбора размеров файлов и кластеризации помогают оптимизировать производительность запросов и снизить стоимость сканирования.