#amazon-kinesis #amazon-dynamodb-streams #amazon-kcl
#amazon-kinesis #amazon-dynamodb-streams #amazon-kcl
Вопрос:
Мы создаем сервис на основе потоков Kinesis / DynamoDB, и у нас есть следующий вопрос о поведении контрольных точек.
У нас есть рабочий файл, который начинается со следующей конфигурации withInitialPositionInStream (InitialPositionInStream.LATEST) , и имя приложения KCL всегда одно и то же.
Что мы наблюдали, выключая и снова включая worker, так это то, что он не начинает потреблять с конца потока, поскольку у нас есть показатель задержки, и мы видим, что при включении worker задержка потребления составляет часы, когда мы ожидаем, что она будет меньше 1 секунды с моментаэто сообщения, которые мы создаем в данный момент.
- Это ожидаемое поведение?
- Мы неправильно интерпретируем, как
LATESTэто работает?
Большое вам спасибо.
Комментарии:
1. Не могли бы вы уточнить, какую версию библиотеки kinesis вы используете? Кроме того, вы устанавливаете контрольную точку вручную или нет? Спасибо.
2. Привет, Николай, я использую версию 2.2.11 KCL на Java, мы выполняем контрольные точки вручную,
processRecordsно я думаю, что KCL выполняет контрольные точки автоматически послеprocessRecords.3. Как правило, ПОСЛЕДНЯЯ учитывается только при первоначальном запуске, когда нет таблицы аренды. Если вы перезапустите приложение с тем же идентификатором приложения, kcl возобновит работу с последним установленным номером для каждого фрагмента. Насколько я знаю, он не выполняет автоматическую контрольную точку, в отличие, например, от kafka consumer. Вы должны установить контрольную точку вручную.
Ответ №1:
В качестве документации для InitialPositionInStream состояний,
Используется для указания позиции в потоке, с которой должно начинаться новое приложение. Это используется во время начальной начальной загрузки приложения (когда контрольная точка не существует для фрагмента или его родителей).
Таким образом, он используется только во время начальной загрузки нового приложения и в случае LATEST , он запускается после самой последней записи данных. Но только тогда, когда контрольная точка не существует для фрагмента или его родителей.
Итак, если вы выключите свой рабочий, а затем снова включите его, ожидается LATEST , что он больше не будет запускаться, но вместо этого он начинается с последнего порядкового номера контрольной точки для фрагмента.
KCL не проверяет контрольную точку автоматически, и поэтому, если ваш рабочий запускается с задержкой в несколько часов, это означает, что, вероятно, вы слишком редко проверяете контрольную точку.