TRIM_HORIZON против ПОСЛЕДНЕГО

Question

Я не могу найти в формальной документации AWS Kinesis любая явная ссылка между TRIM_HORIZON и контрольно-пропускной пункт, а также любые ссылки между LATEST и контрольно-пропускной пункт.

Можете ли вы подтвердить мою теорию:

• TRIM_HORIZON - Если имя приложения новое, тогда я прочитаю все записи, доступные в потоке. Иначе, имя приложения уже использовалось, тогда я буду читать с моей последней контрольной точки.

• LATEST - Если имя приложения новое, тогда я прочитаю все записи в потоке, которые были добавлены после того, как я подписался на поток. Иначе, имя приложения уже использовалось, я буду читать сообщения с моей последней контрольной точки.

• Разница между TRIM_HORIZON а также LATEST только в том случае, если имя приложения новое.

Answer 1

AT_TIMESTAMP

- от конкретной отметки времени

TRIM_HORIZON

- все доступные сообщения в потоке Kinesis (такие же, как самые ранние в Kafka)

САМЫЙ ПОСЛЕДНИЙ

- из последних сообщений

Answer 2

Из документации GetShardIterator (которая соответствует моему опыту использования Kinesis):

В запросе вы можете указать тип итератора шарда AT_TIMESTAMP читать записи с произвольного момента времени, TRIM_HORIZON заставить ShardIterator указывать на последнюю незарезанную запись в сегменте в системе (самая старая запись данных в сегменте), или LATEST так что вы всегда читаете самые последние данные в шарде.

В основном, разница в том, хотите ли вы начать с самой старой необработанной записи (TRIM_HORIZON) или из "прямо сейчас" (LATEST - пропуск данных между последней контрольной точкой и сейчас).

Answer 3

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

Авторитетный ответ на этот вопрос Джастина Пфифера можно найти в выпуске GitHub здесь.

Самая важная часть - это

KCL всегда будет использовать значение из таблицы аренды, если оно присутствует. Важно помнить, что сам Kinesis не отслеживает позицию потребителей. Отслеживание осуществляется по таблице аренды. Сдаёт в аренду сервер KCL двойная нагрузка. Они обеспечивают как взаимное исключение, так и отслеживание позиции. Таким образом, для взаимного исключения необходимо создать аренду, а для обеспечения отслеживания позиции необходимо выбрать начальное значение.

(Курсив добавлен мной.)

Answer 4

Я думаю, что выбор между любым из них — это компромисс между тем, хотите ли вы начать с самых последних данных или хотите начать с самых старых данных, которые не были обработаны с помощью kinesis.

Представьте себе сценарий, когда в вашей лямбда-функции есть ошибка, и она выдает исключение на первой полученной записи и возвращает ошибку обратно в kinesis, из-за которой теперь ни одна из записей в вашем kinesis не будет обрабатываться и будет оставаться там в течение 1 дня (срок хранения). Теперь, после того, как вы исправили ошибку и развернули свою лямбду, теперь ваша лямбда начнет получать все эти сообщения из буфера, который удерживал kinesis. Теперь вашему нисходящему сервису придется обрабатывать старые данные вместо самых последних данных. Это может добавить нежелательную задержку в ваше приложение, если вы выберете TRIM_HIROZON.

Но если вы использовали ПОСЛЕДНИЕ, вы можете игнорировать все эти предыдущие застрявшие сообщения, и ваша лямбда действительно начнет обрабатывать новые события/сообщения и, таким образом, улучшит задержку, которую обеспечивает ваша система.

Так что вам придется решить, что важнее для ваших клиентов. Нормально ли потерять несколько точек данных и каков ваш предел допуска, или вам всегда нужны точные результаты, такие как расчет суммы / счетчика.