AWS Kinesis ShardIteratorType 的预期行为 TRIM_HORIZON
Expected behavior for AWS Kinesis ShardIteratorType TRIM_HORIZON
Context：我不一定指的是基于 KCL 的应用程序，只是纯粹的 Kinesis API 调用。
使用 TRIM_HORIZON 分片迭代器类型会立即为您提供流中最早发布的记录（即 Kinesis 内置的 24 小时 window 中最早可用的记录），还是只是一个 iterator/cursor 长达 24 小时前的某个时间段，然后您必须使用它沿着流前进，直到您达到最早发布的记录？
换句话说，如果不是很清楚....
当使用 TRIM_HORIZON 的分片迭代器类型时，预期的行为是它将从返回 24 小时前可用的记录开始，但如果零条记录恰好在 24 小时前发布，而是仅 3 小时前，您的应用程序需要迭代轮询前 21 小时才能到达 3 小时前发布的记录？
时间轴示例：
- 9 月 29 日 5:00 上午 - 使用 1 个分片
创建流 "foo"
- 9 月 29 日 5:02 上午 - 将单个记录 "Item=A" 发布到 "foo" 流
- 9 月 29 日 5:03 上午 - 使用
TRIM_HORIZON 作为您的分片迭代器类型发出 GetShardIterator 调用，然后使用该分片迭代器发出 GetRecords 调用并接收记录 "Item=A"
- 9 月 30 日 7:02 上午 - 将第二条记录 "Item=B" 发布到 "foo" 流
- 9 月 30 日 7:03 上午 - 使用
TRIM_HORIZON 作为您的分片迭代器类型发出 GetShardIterator 调用，然后使用该分片迭代器发出 GetRecords 调用。 此调用的结果应该是什么？ （注意：我们没有 remember/re-use 第 3 步中的分片迭代器）
对于上述第 5 步，"Item=A" 消息在流中发布已经超过 24 小时，而 "Item=B" 发布仅一分钟。带有 TRIM_HORIZON 的新分片迭代器会立即为您提供最早的可用记录，还是您需要继续迭代直到遇到某个时间段已发布的内容？
我一直在试验 Kinesis，昨天或两天前一切正常（即我发布和消费时没有任何问题）。我对我的代码做了一些额外的修改，今天又开始发布了。当我启动我的消费者时，即使在 运行 几分钟后也没有任何结果。我尝试同时发布和消费，但仍然一无所获。在手动使用 AFTER_SEQUENCE_NUMBER 迭代器类型并使用几天前我的消费者日志中的一些序列号之后，我能够访问我最近发布的消息。但是如果我返回使用 TRIM_HORIZON 类型，我根本看不到任何消息。
我看了docs, but most of docs I found assume you are using the KCL (I actually was using KCL initially, but when it started failing I dropped down to raw API calls) and mention that you must have an application name and that DynamoDB tables are used for tracking state. Which as best I can tell is not true if you're using pure Kinesis API calls or the Kinesis CLI, both of which I eventually tried. I finally wrote a pure API script to start with TRIM_HORIZON and poll infinitely and eventually it hit new records (took ~600 iterations; started out 14hrs behind "now" and found records at about 5 hours behind "now"). If this is expected behavior, it seems like the wording in the docs一点点confusing/misleading:
TRIM_HORIZON - Start reading at the last untrimmed record in the shard
in the system, which is the oldest data record in the shard.
我假设（现在看来不正确）术语 "oldest data record" 表示我已发布到流中的记录，而不仅仅是流中的时间段。
如果有人可以帮助 confirm/explain 我所看到的行为，那就太好了。
谢谢！
它位于 TRIM HORIZON，或者流 TRIMming 发生的 HORIZON。
分片迭代器在调用时可能会获得 0 条记录，因此您需要不断迭代以到达最旧记录所在的区域（如果您不经常推送到流或有时间间隔）。 getRecords 将为您提供下一个可用于迭代的分片迭代器。
来自文档：
http://docs.aws.amazon.com/kinesis/latest/APIReference/API_GetRecords.html
If there are no records available in the portion of the shard that the
iterator points to, GetRecords returns an empty list. Note that it
might take multiple calls to get to a portion of the shard that
contains records.
TRIM_HORIZON 给出流中最早的记录。
只是有时将 TRIM_HORIZON 作为 shard_iterator_type :-
Suppose the value of "millis_behind_latest" in the kinesis response is ~86399000 & your stream retention period is 24 hours(86400000)
当您使用 shard_iterator 检索记录时，由于已超过记录的保留期限，该记录已不在流中。因此你得到一个空的结果，因为最旧的记录已经过期并且不再存在于数据流中。所以 shard_iterator 现在指向磁盘中的空 space。
当发生这种情况时，取"next_shard_iterator"的值并使用get_records再次获取运动数据记录。
还有一件事是我们并不完全了解 AWS 是如何管理数据流中的每个分片的。如何擦除和添加数据。也许数据没有存储在 concurrent/contiguous 内存块中，因此我们在数据检索之间得到空结果。
继续取 "next_shard_iterator" 的值并使用 get_records 直到 "millis_behind_latest".
的值为 0
希望这个回答对您有所帮助。 :)
Context：我不一定指的是基于 KCL 的应用程序，只是纯粹的 Kinesis API 调用。
使用 TRIM_HORIZON 分片迭代器类型会立即为您提供流中最早发布的记录（即 Kinesis 内置的 24 小时 window 中最早可用的记录），还是只是一个 iterator/cursor 长达 24 小时前的某个时间段，然后您必须使用它沿着流前进，直到您达到最早发布的记录？
换句话说，如果不是很清楚....
当使用 TRIM_HORIZON 的分片迭代器类型时，预期的行为是它将从返回 24 小时前可用的记录开始，但如果零条记录恰好在 24 小时前发布，而是仅 3 小时前，您的应用程序需要迭代轮询前 21 小时才能到达 3 小时前发布的记录？
时间轴示例：
- 9 月 29 日 5:00 上午 - 使用 1 个分片 创建流 "foo"
- 9 月 29 日 5:02 上午 - 将单个记录 "Item=A" 发布到 "foo" 流
- 9 月 29 日 5:03 上午 - 使用
TRIM_HORIZON作为您的分片迭代器类型发出GetShardIterator调用，然后使用该分片迭代器发出GetRecords调用并接收记录 "Item=A" - 9 月 30 日 7:02 上午 - 将第二条记录 "Item=B" 发布到 "foo" 流
- 9 月 30 日 7:03 上午 - 使用
TRIM_HORIZON作为您的分片迭代器类型发出GetShardIterator调用，然后使用该分片迭代器发出GetRecords调用。 此调用的结果应该是什么？ （注意：我们没有 remember/re-use 第 3 步中的分片迭代器）
对于上述第 5 步，"Item=A" 消息在流中发布已经超过 24 小时，而 "Item=B" 发布仅一分钟。带有 TRIM_HORIZON 的新分片迭代器会立即为您提供最早的可用记录，还是您需要继续迭代直到遇到某个时间段已发布的内容？
我一直在试验 Kinesis，昨天或两天前一切正常（即我发布和消费时没有任何问题）。我对我的代码做了一些额外的修改，今天又开始发布了。当我启动我的消费者时，即使在 运行 几分钟后也没有任何结果。我尝试同时发布和消费，但仍然一无所获。在手动使用 AFTER_SEQUENCE_NUMBER 迭代器类型并使用几天前我的消费者日志中的一些序列号之后，我能够访问我最近发布的消息。但是如果我返回使用 TRIM_HORIZON 类型，我根本看不到任何消息。
我看了docs, but most of docs I found assume you are using the KCL (I actually was using KCL initially, but when it started failing I dropped down to raw API calls) and mention that you must have an application name and that DynamoDB tables are used for tracking state. Which as best I can tell is not true if you're using pure Kinesis API calls or the Kinesis CLI, both of which I eventually tried. I finally wrote a pure API script to start with TRIM_HORIZON and poll infinitely and eventually it hit new records (took ~600 iterations; started out 14hrs behind "now" and found records at about 5 hours behind "now"). If this is expected behavior, it seems like the wording in the docs一点点confusing/misleading:
TRIM_HORIZON - Start reading at the last untrimmed record in the shard in the system, which is the oldest data record in the shard.
我假设（现在看来不正确）术语 "oldest data record" 表示我已发布到流中的记录，而不仅仅是流中的时间段。
如果有人可以帮助 confirm/explain 我所看到的行为，那就太好了。
谢谢！
它位于 TRIM HORIZON，或者流 TRIMming 发生的 HORIZON。
分片迭代器在调用时可能会获得 0 条记录，因此您需要不断迭代以到达最旧记录所在的区域（如果您不经常推送到流或有时间间隔）。 getRecords 将为您提供下一个可用于迭代的分片迭代器。
来自文档： http://docs.aws.amazon.com/kinesis/latest/APIReference/API_GetRecords.html
If there are no records available in the portion of the shard that the iterator points to, GetRecords returns an empty list. Note that it might take multiple calls to get to a portion of the shard that contains records.
TRIM_HORIZON 给出流中最早的记录。
只是有时将 TRIM_HORIZON 作为 shard_iterator_type :-
Suppose the value of "millis_behind_latest" in the kinesis response is ~86399000 & your stream retention period is 24 hours(86400000)
当您使用 shard_iterator 检索记录时，由于已超过记录的保留期限，该记录已不在流中。因此你得到一个空的结果，因为最旧的记录已经过期并且不再存在于数据流中。所以 shard_iterator 现在指向磁盘中的空 space。
当发生这种情况时，取"next_shard_iterator"的值并使用get_records再次获取运动数据记录。
还有一件事是我们并不完全了解 AWS 是如何管理数据流中的每个分片的。如何擦除和添加数据。也许数据没有存储在 concurrent/contiguous 内存块中，因此我们在数据检索之间得到空结果。
继续取 "next_shard_iterator" 的值并使用 get_records 直到 "millis_behind_latest".
的值为 0希望这个回答对您有所帮助。 :)