Как контрольные точки flink помогают в восстановлении после сбоя

Question

Мое задание по быстрому чтению читает потребитель kafka, используя FlinkKafkaConsumer010, и записывает в hdfs, используя CustomBucketingSink. У нас есть ряд преобразований kafka -> flatmaps (2-3 преобразования) -> keyBy -> tumblingWindow (5 минут) -> Aggregation -> hdfsSink. У нас есть ввод кафки в среднем 3 миллиона событий в минуту и ​​около 20 миллионов событий в минуту в пиковое время. Продолжительность контрольной точки и минимальная пауза между двумя контрольными точками - 3 минуты, и я использую FsStateBackend.

Вот мои предположения:

Flink потребляет фиксированное количество событий от kafka (несколько смещений из нескольких разделов в один раз) и ждет, пока он достигнет тонуть, а затем контрольно-пропускные пункты. В случае успеха он фиксирует смещение разделов kafka, которые он читает, и поддерживает некоторое состояние, связанное с файлом hdfs, который он записывал. Хотя после передачи событий kafka другим операторам происходило несколько преобразований, потребитель kafka бездействует, пока не получит подтверждение успешности отправленных им событий. Таким образом, мы можем сказать, что в то время как сток записывает данные в hdf, все предыдущие операторы бездействовали. В случае сбоя flink переходит в предыдущее состояние контрольной точки и указывает на зафиксированное смещение последнего раздела kafka и указывает на файл hdfs offest, на который он должен начать запись.

Вот мои сомнения, основанные на вышеуказанных предположениях:

1) Выше предположение правильно. 2) Имеет ли смысл переворачивать окно в состояние, так как в случае сбоя мы все равно начинаем с последнего смещения, зафиксированного разделом kafka. 3) В случае переворачивания окна сделать состояние, когда оно будет использоваться Flink. 4) Почему размеры контрольной точки и точки сохранения различаются. 5) В случае любого сбоя мигание всегда начинается с оператора sorce. Правильно?

Answer 1

Ваши предположения неверны.

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

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

(3) Ни один из операторов никогда не бездействует, как вы описали , Контрольная точка не останавливает конвейер.

Лучший способ понять, как работает контрольная точка, - это go через игровую площадку Flink, особенно раздел Наблюдение за отказом и восстановлением . Это даст вам более четкое понимание этой темы c, потому что вы сможете точно наблюдать за происходящим.

Я также могу порекомендовать прочитать https://training.ververica.com/snapshots.html и следовать ссылки, содержащиеся там.

Но чтобы узнать, как работает контрольная точка в вашем приложении, вот основные шаги c:

(1) Когда координатор контрольной точки (часть менеджера заданий) ) решает, что пришло время инициировать другую контрольную точку, он информирует каждого менеджера задач о запуске контрольной точки n .

(2) Все исходные экземпляры контрольной точки имеют свое собственное состояние и вставляют барьер контрольной точки n в свои исходящие потоки. В вашем случае источники являются потребителями Kafka, и они проверяют текущее смещение для каждого раздела.

(3) Всякий раз, когда барьер контрольных точек достигает заголовка входной очереди в операторе с состоянием, этот оператор проверяет свое состояние и продвигает барьер. Эта часть имеет некоторую сложность, но в основном состояние хранится в многоверсионной карте ha sh, управляемой параллелизмом. Оператор создает новую версию n + 1 состояния, которое может быть изменено событиями за барьером контрольной точки, и создает новый поток для асинхронного снимка всего состояния в версии n .

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

(4) Мойки используют прибытие барьера для гриппа sh любого вывода в очереди и фиксируют ожидающие транзакции. Опять же, здесь есть некоторая сложность, так как транзакционные приемники используют протокол двухфазной фиксации.

В вашем приложении, если интервал контрольных точек намного меньше продолжительности окна, то приемник завершит множество контрольных точек, прежде чем когда-либо получит какие-либо выходные данные из окна.

(5) Когда контрольная точка от каждой задачи координатор получал ответ, что контрольная точка завершена, он завершает метаданные контрольной точки.

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

Примечание: Для оставьте это достаточно простым, я замял некоторые детали. Кроме того, FLIP-76 представит новый подход к контрольным точкам.