Как работают контрольные точки Kinesis искровой потоковой приемник

Question

Мы используем Spark Streaming, подключенный к потоку AWS Kinesis, чтобы агрегировать (в минуту) показатели, которые мы получаем, и записывать агрегаты в infuxdb, чтобы сделать их доступными для панель управления в реальном времени.

Все работает нормально, но теперь мы рассматриваем вопрос о том, как мы должны управлять приостановками развертывания и возможными сбоями системы.

Документы говорят, что библиотека интеграции Kinesis уже подготовлена ​​к сбоям, контрольно-пропускным пунктам и т. Д., Но я хотел бы уточнить, как там работает контрольная точка.

Ресивер Kinesis создает входной сигнал DStream с использованием клиентской библиотеки Kinesis (KCL), предоставляемой Amazon в соответствии с лицензией на программное обеспечение Amazon Software License (ASL). KCL построен поверх Apache 2.0, лицензированного AWS Java SDK, и обеспечивает балансировку нагрузки, отказоустойчивость, контрольную точку через концепции рабочих, контрольно-пропускных пунктов и договоров об аренде.

Мы можем определить интервал контрольной точки для кинези, но насколько я понимаю, это просто используется для обозначения того, до какой точки потока мы потребляем метрики. Итак, нам все еще нужно использовать функцию контрольной точки от искрового потока, верно?

Поскольку мы собираем данные в минуту, наш пакетный интервал составляет 60 секунд, но за эти 60 секунд мы непрерывно получаем данные из потока.

Вот мои вопросы:

• Когда я исполняю JavaStreamingContext.stop (...) (для того, чтобы развернуть новую версию работы), приемник будет остановлен и контрольно-пропускной пункт будет обновляться в конце?
• Когда произойдет контрольная точка с искровым потоком? После каждого выполнения задания? До?
• Предполагая, что у нас есть оба контрольно-пропускных пункта, как мы можем гарантировать согласованность в случае отказа? Кажется, что каждый раз, когда происходит потоковая контрольная точка, необходимо одновременно проверять контрольную точку на кинезис, иначе мы снова можем снова прочитать одни и те же данные. Как мы можем справиться с этим?
• Если базовая услуга (в данном случае притока) не работает, что мне делать? Реализовать механизм повтора? Если это так, ему нужно прекратить повторную попытку через некоторое время, иначе у нас будет нехватка памяти.

Заранее благодарен!

Answer 1

Не на сто процентов уверен, что это будет полный ответ на ваш вопрос, поскольку решение контрольно-пропускного пункта является довольно сложным компонентом, и для каждого подзапроса может потребоваться отдельный вопрос в SO. Тем не менее, может быть, это даст некоторое представление о процессе:

• чекпойнтинг работает на уровне DStream, так что это означает, что вы можете выполнять контрольно-пропускные пункты на разных этапах своего трубопровода. Это может быть тот момент, когда Spark создает ваш первый RDD из блоков, сгенерированных приемником, или это может быть ваш преобразованный RDD, который вы можете получить на более поздних этапах после того, как вы рассчитали свои показатели.Поэтому, когда вы вызываете стоп (если вы остановите его изящно), у вас будет состояние вашей контрольной точки с последним RDD, обработанным после того, как ваши приемники были остановлены в том месте, которое вы выбрали в своем конвейере.

• контрольная точка запускается Искры компонент, называемый JobGenerator. Перед запуском задания он будет генерировать DStreams, который будет вычислять RDD. На этом шаге, если вы настроили контрольную точку, каждый RDD этого DStream дополнительно создаст метаданные контрольной точки, а RDD будет отмечен как тот, который требует контрольной проверки. Затем SparkContext будет запускать сгенерированные задания, и в конце он вызовет метод doCheckpoint, который будет сохранять данные контрольной точки в настроенное местоположение. JobGenerator создаст для этого отдельное задание, поэтому вы ожидаете некоторую задержку между фактическим заполнением задания и сохранением контрольной точки.

• каждый раз, когда Spark запускает ваше приложение, оно создаст контекст потока из ваших данных контрольной точки. Поэтому давайте скажем, если у вас есть ваши показатели в состоянии 7, например, при последнем отключении Spark после того, как приемники Kenesis были остановлены, тогда, когда ваш потоковый контекст будет восстановлен, он снова будет в состоянии 7, и только следующая партия будет генерироваться из новых данных кенезирования разместит его в штате 8

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