Apache Flink: зачем выбирать MemoryStateBackend вместо FsStateBackend? - PullRequest
0 голосов
/ 23 января 2019

Флинк имеет MemoryStateBackend и FsStateBackendRocksDBStateBackend).Кажется, что оба расширяют HeapKeyedStateBackend, т. Е. Механизм хранения текущего рабочего состояния полностью одинаков.

Этот SO ответ говорит, что основное отличие заключается в сохранении MemoryStateBackendкопия контрольных точек в памяти JobManager.(Я не смог собрать никаких доказательств этого из исходного кода.) MemoryStateBackend также ограничивает максимальный размер состояния для подзадачи.

Теперь я задаюсь вопросом: почему вы когда-нибудь захотите использовать MemoryStateBackend * * 1014

1 Ответ

0 голосов
/ 23 января 2019

Как вы сказали, MemoryStateBackend и FSStateBackend основаны на HeapKeyedStateBackend.Это означает, что оба бэкэнда состояния поддерживают состояние оператора как обычные объекты в куче JVM TaskManager, то есть к состоянию всегда осуществляется доступ в памяти.

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

FSStateBackend хранит контрольную точку в файловой системе, обычно HDFS, S3 или NFS, котораямонтируется на всех рабочих узлах.MemoryStateBackend сохраняет состояние в JVM JobManager.Это имеет следующие плюсы и минусы:

Плюсы:

  • Нет необходимости настраивать (распределенную) файловую систему.
  • Нет необходимости настраивать расположение хранилища.

Минусы:

  • Состояние теряется, если процесс JobManager умирает.
  • Размер состояния связан с размером памяти JobManager.

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

...