Apache Flink: Полная точка сохранения против Инкрементальной точки сохранения

Apache Flink — это движок обработки данных в реальном времени. Большинство приложений для обработки потоков являются «состоянием». Это означает, что состояние сохраняется и используется для дальнейшей обработки. В Apache Flink состояние управляется через настроенный бэкенд состояния. Flink поддерживает два бэкенда состояния в продакшене. Один из них — это HashMapStateBackend, а другой — EmbeddedRocksDBStateBackend.

Чтобы предотвратить потерю данных и достичь отказоустойчивости, Flink может сохранять снимки состояния в надежное хранилище. Flink можно настроить так, чтобы он снимал либо все состояние в надежное место, либо дельту с момента последнего снимка. Первое называется полным контрольным снимком, а второе известно как инкрементальный контрольный снимок.

В этой статье мы собираемся сравнить HashMapStateBackend с полным контрольным снимком и EmbeddedRocksDBStateBackend с инкрементальным контрольным снимком. Эта статья предполагает, что аудитория имеет либо практические, либо теоретические знания о Apache Flink.

Обзор бэкенда состояния Flink

Чтобы понять бэкенд состояния Flink, важно знать разницу между состоянием в процессе обработки и снимками состояния.

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

С другой стороны, снимки состояния (точки контроля или точки сохранения) хранятся в надежном удаленном месте. Эти снимки используются для восстановления состояния задачи Flink в случае сбоя задачи.

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

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

В продакшене Apache Flink поддерживает два хранилища состояния.

1. HashMapStateBackend

Это легкое хранилище состояния в Flink для управления состоянием ключа и состоянием оператора во время обработки потока. Состояние хранится в Java Heap с использованием структуры данных HashMap. Поскольку оно хранится в памяти, основным ограничением здесь является то, что максимальный размер состояния ограничен размером Java Heap. При записи в состояние или чтении из состояния сериализация не выполняется. Поэтому это подходит для приложений с низкой задержкой, высокой пропускной способностью и не слишком большим объемом состояния.

2. EmbeddedRocksDBStateBackend

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

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

Обзор состояния снимка

Снимок представляет глобальное состояние задания Flink. Это состоит из указателя на каждый источник данных и состояния всех операторов с состоянием Flink после обработки данных до этих указателей из источников. К checkpointing в Apache Flink — это механизм достижения отказоустойчивости путем периодического сохранения состояния в надежное удаленное хранилище.

В случае сбоя задания Flink восстанавливает сохраненное состояние из надежного удаленного хранилища и начинает обрабатывать потоковые данные с того места, где остановился. Flink использует асинхронное создание снимков барьеров. Это вариант алгоритма Чанди-Лампорта.

Flink поддерживает два типа создания контрольных точек.

1. Полное создание контрольных точек

Полное чекпоинтинг — это когда всё состояние задания Flink захватывается и сохраняется в надежном удаленном хранилище. В случае сбоя задания оно восстанавливается из ранее сохраненного состояния. Требования к дисковому пространству и время, затрачиваемое на чекпоинтинг, полностью зависят от состояния приложения. Полное чекпоинтинг работает как с HashMapStateBackend, так и с RocksDBStateBackend.

2. Инкрементный чекпоинтинг

Инкрементный чекпоинтинг — это оптимизированный подход. Вместо того, чтобы создавать снимок всего состояния, Flink сохраняет только «дельты», внесенные в состояние с момента последнего чекпоинта. Это уменьшает сетевые накладные расходы и, таким образом, время, необходимое для чекпоинтинга. В этом случае чекпоинтинг происходит полностью асинхронно.

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

Анализ

Детали пайплайна: Apache Beam пайплайн, работающий на движке Flink с фиксированным окном в 10 минут, а чекпоинт настроен на выполнение каждые 3 минуты. Настроенный тип сериализации — AVRO.

• Тип кластера: “m5dn.4xlarge”
• Хранилище для финального чекпоинта: S3
• Количество уникальных ключей: 2K

Как видно из приведенного выше эксперимента, продолжительность контрольного снимка уменьшается при инкрементальном контрольном снимке. Это может значительно помочь в производительности приложения.  

Резюме

Ниже приведено резюме эксперимента.