Как часто выполняется состояние оператора де / сериализации Flink? За получение / обновление или на основе контрольных точек? Имеет ли значение государственный бэкэнд?
Я подозреваю, что в случае ключевого потока с разнообразным ключом (миллионы) и тысячами событий в секунду для каждого ключа де / сериализация может стать большой проблемой. Я прав?
Ваше предположение верно. Это зависит от состояния серверной части.
Бэкэнды, которые хранят состояние в куче JVM (MemoryStateBackend и FSStateBackend), не сериализуют состояние для обычных операций чтения / записи, а сохраняют его как объекты в куче. Хотя это приводит к очень быстрому доступу, очевидно, что вы привязаны к размеру кучи JVM, а также можете столкнуться с проблемами сборки мусора. При взятии контрольной точки объекты сериализуются и сохраняются, чтобы обеспечить восстановление в случае сбоя.
Напротив, RocksDBStateBackend хранит все состояния в виде байтовых массивов во встроенных экземплярах RocksDB. Следовательно, он де / сериализует состояние ключа для каждого доступа для чтения / записи. Вы можете контролировать, "насколько" состояние сериализуется, выбирая соответствующий примитив состояния, то есть ValueState, ListState, MapState и т. Д.
Например, ValueState всегда де / сериализуется как целое, тогда как MapState.get(key) только сериализует ключ (для поиска) и десериализует возвращаемое значение для ключа. Следовательно, вы должны использовать MapState<String, String> вместо ValueState<HashMap<String, String>>. Аналогичные соображения применимы и к другим примитивам состояния.
RocksDBStateBackend контрольные точки проверяют свое состояние, копируя свои файлы в постоянную файловую систему. Следовательно, при взятии контрольной точки не требуется дополнительной сериализации.
