Версия сайта для слабовидящих
Недавно мы писали про главные новинки свежего релиза Apache Flink 1.15, особенно важные с точки зрения обучения разработчиков распределенных приложений и дата-инженеров. Сегодня рассмотрим подробнее, зачем в этом выпуске введены дополнительные режимы восстановления потоковых stateful-заданий из моментальных снимков, когда и какой режим использовать, а также как выбрать формат точки сохранения при ее запуске.
Предыстория: проблемы контрольных точек в Apache Flink
В последнем выпуске Apache Flink, главные новинки которого мы рассматривали здесь, были улучшены механизм точек сохранения и процесс создания моментальных снимков. Моментальные снимки дают глобальное согласованный образ состояния задания Flink, обеспечивая отказоустойчивость и строго-однократную обработку через точки сохранения и контрольные точки, разницу между которыми мы разбирали в этой статье. В Apache Flink 1.15 добавлена возможность создания точек сохранения в формате, специфичном для серверной части исходного состояния, а также уточнение прав собственности на моментальные снимки.
Впервые механизм контрольных точек был выпущен в релизе 1.13. Он включал унифицированный двоичный формат точек сохранения для всех различных бэкендов состояния, чтобы переключать их с отслеживанием состояния. В следующей версии фреймворка бала добавлена распаковка буфера, основанная на концепции автоматической корректировки объема данных в процессе обработки, которые необходимо выровнять во время моментального снимка. Также стало возможным продолжение контрольной точки, даже если в JobGraph есть завершенные задачи.
Точки сохранения могут быть дорогостоящими для получения и восстановления состояния, если они используются для очень большого состояния, хранящегося в бэкенде состояния RocksDB. До Flink 1.15 пользователи использовали внешние инкрементные контрольные точки вместо точек сохранения, чтобы воспользоваться преимуществами собственного формата RocksDB. Однако, контрольные точки и точки сохранения служат разным операционным целям. Поэтому в майском релизе 2022 стало возможным брать точки сохранения в формате, характерном для бэкенда исходного состояния, сохраняя при этом их некоторые характеристики.
Также в последнем релизе была решена еще одна проблема, связанная с внешними контрольными точками, когда их принадлежность была непрозрачна. Ранее возникал вопрос, кому принадлежат файлы контрольных точек: фреймворку или пользователю? Это особенно важно, когда речь идет об инкрементных контрольных точках RocksDB и сложно выполнить очистку их файлов, не зная точно, какие контрольные точки им принадлежат. Чтобы решить эту проблему, были добавлены явные режимы восстановления (CLAIM, NO_CLAIM и LEGACY), которые четко определяют, должен ли Flink заботиться об очистке моментальных снимков или ответственность за это должен нести пользователь. Что именно представляют собой эти режимы, мы рассмотрим далее.
3 режима восстановления состояния stateful-приложений из моментальных снимков
Режим восстановления определяет, кто становится владельцем файлов, составляющих точки сохранения или внешние контрольные точки после их восстановления. Моментальные снимки, которые в этом контексте являются контрольными точками или точками сохранения, могут принадлежать пользователю или самому Flink. Если snapshot принадлежит пользователю, Flink не удалит его файлы и не будет зависеть от их существования, поскольку они могут быть удалены самим пользователем вне контроля фреймворка. Задать режим восстановления следующим образом:
$ bin/flink run -s :savepointPath -restoreMode :mode -n [:runArgs]
Рассмотрим новые режимы восстановления более подробно:
- LEGACY — режим, с которым Flink работал до версии 1.15. В этом режиме Flink никогда не удалит начальный checkpoint. И неясно, сможет ли пользователь сделать это. Проблема здесь в том, что Flink может сразу создать дополнительную контрольную точку поверх восстановленной. Поэтому последующие контрольные точки зависят от восстановленной, а право собственности в этом режиме четко не определено.
- NO_CLAIM – режим по умолчанию, который введен в версии Apache Flink15, чтобы решить проблему права собственности на файлы моментальных снимков. В этом режиме Flink не станет владельцем моментального снимка и оставит файлы под контролем пользователя и не удалит какие-либо файлы. В этом режиме можно запускать несколько заданий из одного snapshot’а. Чтобы убедиться, что Flink не зависит ни от одного из файлов из этого моментального снимка, фреймворк сделает первую успешную контрольную точку полной, а не добавочной. Это имеет значение только для RocksDB-бэкенда (state.backend: rockdb), т.к. остальные серверные части состояния всегда берут полные контрольные точки. После завершения первой полной контрольной точки все последующие будут приняты и настроены как обычно. Поэтому пользователь после успешной проверки контрольной точки может вручную удалить исходный snapshot. Но нельзя сделать этого раньше успешного завершения проверки, т.к. без завершенных контрольных точек Flink в случае неудачи попытается восстановиться из исходного снимка.
- CLAIM – режим, в котором Flink объявляет себя владельцем моментального снимка и, по сути, рассматривает его как контрольную точку и и может удалить его, если тот больше не нужен для восстановления. Поэтому небезопасно вручную удалять моментальный снимок или запускать 2 задания из одного моментального снимка. Flink поддерживает настроенное количество контрольных точек.
Хотя каждый режим восстановления служит определенной цели, именно NO_CLAIM является достаточно приемлемым вариантом в большинстве случаев, т.к. обеспечивает разумный баланс между затратами на четкое владение snapshot-файлами с небольшой ценой за первую контрольную точку после восстановления. Поэтому в Apache Flink 1.15 именно он задан в качестве режима по умолчанию.
Форматы точки сохранения
В свежем релизе Flink можно активировать точки сохранения в собственном формате бэкендов состояния. Это обеспечивает автономность и легковесность точек сохранения и контрольных точек. Теперь у Flink есть способ создания точки сохранения в собственном двоичном формате используемого бэкенда состояния, который может использовать собственные структуры данных RocksDB на диске, обычно называемые файлами SST. Инкрементные контрольные точки использовали их и по сути представляют собой наборы этих SST-файлов с некоторыми дополнительными метаданными, которые можно быстро перезагрузить в рабочий каталог RocksDB после восстановления.
Собственные точки сохранения могут использовать тот же механизм загрузки файлов SST вместо вывода всего состояния в канонический формат Flink. Кроме того, по сравнению с простым использованием внешних инкрементных контрольных точек, собственные точки сохранения по-прежнему перемещаемы и автономны в одном каталоге, т.к. один файл SST может использоваться несколькими контрольными точками. Поэтому они помещается в общий каталог и называются инкрементными.
Разработчик Flink-приложения может выбрать формат точки сохранения при ее запуске следующим образом:
# take an intermediate savepoint $ bin/flink savepoint --type [native/canonical] :jobId [:targetDirectory] # stop the job with a savepoint $ bin/flink stop --type [native/canonical] --savepointPath [:targetDirectory] :jobId
Однако, стоит помнить, что невозможно предоставить одинаковые гарантии для всех типов моментальных снимков (канонических или собственных точек сохранения, а также контрольных точек). Основное различие между контрольными точками и точками сохранения заключается в том, что точки сохранения по-прежнему активируются и принадлежат пользователям. Flink не создает их автоматически и никогда не зависит от их существования. Их основная цель по-прежнему заключается в запланированном ручном резервном копировании, тогда как контрольные точки используются для восстановления. С точки зрения базы данных точки сохранения похожи на резервные копии, а контрольные точки — на логии восстановления.
Как применять режимы восстановления и форматы точек сохранения на практике при использовании Apache Flink для потоковой обработки событий в распределенных приложениях аналитики больших данных, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
