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