После исправления данных в папке могут остаться и старые, и новые файлы. Объясняем, как табличные форматы определяют принятый состав таблицы и почему читать все файлы подряд опасно.
В папке появились две версии одних продаж
Представим условную таблицу продаж, разбитую на файлы. Команда исправила несколько заказов и подготовила новые части. Старые ещё лежат рядом. Если следующий участник просто прочитает всё содержимое папки, он может посчитать и прежнюю, и исправленную запись. Названия файлов не дают надёжного правила, что считать текущей таблицей.
Формат аналитической таблицы задаёт правила управления таким набором файлов и его изменениями. Apache Iceberg, Delta Lake и Apache Hudi — разные проекты этого класса. Здесь разберём конкретный вопрос читателя: как узнать, какие части относятся к принятой версии, когда новые сведения уже записываются, а прежние ещё сохраняются.
Устройство файла и состав таблицы
Формат файла, например Parquet, описывает размещение сведений внутри отдельного файла. Табличный уровень связывает множество частей в согласованное целое. Метаданные — сведения о составе и состоянии самой таблицы — помогают выбрать нужные файлы. Поэтому одного умения прочитать Parquet недостаточно, чтобы правильно прочитать любую таблицу поверх него.
В описании надёжности Iceberg состав файлов фиксируется в снимках. Снимок — согласованное состояние таблицы. Принятие изменения происходит атомарно: читатель получает согласованную версию вместо случайной смеси незавершённых частей. Это гарантия механизма работы с таблицей, а не подтверждение правильности цены или названия товара.
Что значит подготовить и принять исправление
В документации Delta Lake описаны подготовка файлов, проверка конфликтов и принятие новой версии. Если несколько участников меняют таблицу, нельзя считать любую завершившуюся запись файла уже принятым изменением. Важен согласованный результат всей операции и поддержка необходимых гарантий выбранным хранилищем.
Вернёмся к учебным продажам. Исправление должно заменить прежнее представление заказа, а не создать ещё одну продажу для отчёта. Предлагаем проследить четыре момента: до начала работы, во время подготовки, после успешного принятия и после неудачи. Для каждого нужно назвать версию, которую увидит обычный читатель. Эта проверка отделяет наличие файлов от состояния таблицы.
Проекты решают общую задачу разными механизмами
В Hudi изменения отслеживает временная шкала действий. Она различает запрошенную, выполняемую и завершённую работу, а также операции обслуживания. Iceberg использует снимки и связанные метаданные; Delta Lake ведёт версионную историю изменений. Эти краткие ориентиры не означают взаимозаменяемость форматов и не служат рейтингом их скорости.
Для выбора важнее собственные требования. Какой инструмент будет читать результат? Поддерживает ли он нужные возможности и версию формата? Как организованы одновременные изменения? В условном проекте предложим сначала описать одно исправление продажи и проверить его целиком. Список знакомых названий без такого сценария плохо помогает принять архитектурное решение.
Почему нельзя просто удалить старые файлы
Старое содержимое может оставаться необходимым для сохранённых версий или ещё работающих читателей. Из названия и даты файла не следует, что его безопасно удалить. Для нашего примера предлагаем использовать предусмотренные проектом правила обслуживания и хранения истории, предварительно проверив требования к восстановлению и чтению. Ручная уборка папки может разрушить ожидаемые связи.
История также не равна вечной резервной копии. Нужно отдельно выяснить, какие версии и файлы сохраняются, как долго и что произойдёт после обслуживания. Универсального срока здесь нет. Команде полезно записать, кто отвечает за эти правила и какой проверкой подтверждается возможность прочитать нужное прошлое состояние, прежде чем обещать пользователям восстановление.
С чего начать разбор своей системы
Сначала объясните путь одного исправления: какие новые части подготовлены, где отмечено принятие, каким способом читается таблица и что остаётся от предыдущего состояния. Физический способ чтения раскрывает материал о строчном и колоночном хранении. Общую ответственность за устройство системы обсуждает статья об архитекторе данных.
Изучать такие решения можно на программе Архитектор данных. Начальный результат — понятное описание того, почему два читателя выбирают одну согласованную версию и почему простое чтение всей папки не является её надёжной заменой.
