Kinesis Data Stream

> 文章作者：亚马逊云科技加油站/罗技123 Kinesis Data Streams 是一种实时数据流服务，每秒可以从数百万个源捕获和处理千兆字节的基于文本的数据，并持久存储。 数据源包括网站点击流、事件流、金融交易、社交媒体源、应用程序日志和来自物联网设备的传感器数据。 这使得分析、仪表板、异常检测和动态定价等功能能够实时发生。 让我换一种说法。 Amazon Kinesis Data Streams 是一种快速队列，每秒最多可以处理一百万个请求。 根据文档，一个流中可以有 10,000 个分片，每个分片能够处理 1,000 条记录。 那是一千万条信息。 Amazon Kinesis 旨在满足亚马逊云科技云中高速数据提取的需求。 Amazon Kinesis Data Streams 可以每秒从移动客户端、网站点击流、社交媒体源、日志和事件等源持续捕获千兆字节的数据，响应时间为毫秒。 需要介绍的词汇有：分片、data record、分区键、序列号、数据 Blob、生产者和消费者。  ### 生产者 使用 Kinesis Producer 收集各种来源的数据并对其进行格式化。 生产者（也称为生产者应用程序）将数据作为数据记录实时放入 Kinesis Data Stream 中。 将数据放入流中的过程也称为数据摄取。 **创建 Producer 应用程序的方法有多种。** - Kinesis API 和亚马逊云科技开发工具包 - Kinesis Agent、Kinesis Agent for Windows - KPL（Kinesis Producer Library）。 - 某些亚马逊云科技服务（例如 Amazon CloudWatch） Kinesis Agent 是一款适用于 Linux 的独立 Java 软件应用程序，提供了一种收集数据并将数据发送到 Kinesis Data Streams 的简单方法。 该代理持续监视一组文件并将新数据发送到您的流。 代理处理文件轮换、检查点以及失败时的重试。 它以可靠、及时且简单的方式提供数据。 适用于 Windows 的 Kinesis Agent 高效可靠地收集、解析、转换日志、事件和指标并将其流式传输到 Kinesis Data Streams。 适用于 Windows 的 Kinesis Agent 还可以与 Kinesis Data Firehose、Amazon CloudWatch 和 CloudWatch Logs 结合使用。 Kinesis Producer 库（或 KPL）是来自亚马逊云科技的一个易于使用、高度可配置的库，旨在帮助程序员了解将数据写入 Kinesis 数据流。 KPL 充当生产者应用程序和 Kinesis Data Streams API 之间的中介。 本质上，它是一个抽象层，包括错误处理、自动重试、数据聚合以及将监控数据发送到 Amazon CloudWatch。 多种亚马逊云科技服务可以将数据直接流式传输到 Kinesis Data Stream 中。 这些服务包括 Amazon CloudWatch、CloudWatch Logs、Amazon EventBridge、Amazon Database Migration Service，甚至另一个 Kinesis Data Stream。 例如，无需在 [EC2](https://aws.amazon.com/cn/ec2/?trk=cndc-detail) 实例上安装代理来将性能数据发送到 Kinesis Data Stream，而是可以将其直接从 Amazon CloudWatch 发送到流。 无论使用哪种类型的生产者，数据都会作为数据记录放入 Kinesis Data Stream 中。 每个数据记录由三部分组成。 有一个分区键、一个序列号和一个由 Base64 编码数据组成的数据 Blob。 分区键确定每个数据记录写入流内的哪个分片。  在流内部，每个单独的数据记录都被放入一个（而且只有一个）分片中。 正如我刚才提到的，分区键决定数据记录写入哪个分片。 数据记录保留在分片内直至过期。 流由一个或多个分片组成，每个分片为流提供固定量的吞吐量。 因此，流中的分片总数决定了可用吞吐量。 当需要更多吞吐量时，添加一个或多个分片。 当可用吞吐量过多时，删除分片。 在流中添加或删除分片的过程称为重新分片。 重新分片是 Kinesis Data Streams 扩展和缩小的方式。 此过程不会自动完成。 它必须以编程方式完成，并且需要持续有效且高效地进行监控。 ### 消费者 消费者（也称为消费者应用程序）访问分片以处理流数据并将其发送到目的地。 目的地包括数据湖、数据仓库、持久存储或另一个流。 在流内部，它进入单个分片。 数据记录永远不会在分片之间分割。 这既有理论上的原因，也有实践上的原因。 最大的一个是将数据记录放入分片的过程不是随机的。 更好地说，将数据记录放入分片的过程是经过深思熟虑的，并且基于分区键。 因此，相似的数据被分组到一个或多个分片中。 这使得消费者（处理流数据的应用程序）可以使用正确的数据。 我很快就会介绍消费者，但在此之前，我想更仔细地了解一下数据流。 默认情况下，数据记录会在流中保留 24 小时（就像缓冲区一样）。 该时间段可以延长，但需支付额外费用。 数据流是不可变的。 这是一个重要的概念。 一旦进入流，数据记录就无法删除或编辑，它只能过期。 这允许多个消费者应用程序使用流并根据需要重放。 这就是为什么我说流就像一个缓冲区。 生产者应用程序将数据实时放入流中。 然而流中的数据不需要实时消费。 可以是，但不一定是。 正如我所说，数据在过期之前一直可用。 然后，它就永远消失了。 回到从流中获取数据。 消费者应用程序（可以有多个）访问流来处理它。 steam中的数据并不关心它在过期之前是否已经被消耗掉。 我想这就像一个脾气暴躁的青少年在自己的房间里沉思。 一旦数据记录过期，数据就会从流中删除并永远消失。 如果尚未消耗，则不会出现错误或警告。 再见，闷闷不乐的少年。 也许更多的是禅宗的东西。 流中的数据并不关心它是否已被处理。 它只是存在于流中，直到它不存在为止。 此行为与 Amazon Simple Queue Service 中的队列不同。 SQS 队列中的记录在被访问时被标记为不可见，并在处理完成时从队列中删除。 SQS 消费者无法处理的消息将被放入死信队列中以供分析或手动处理。 这意味着，在使用 Kinesis Data Streams 时，错误处理和消息感知必须成为消费者应用程序的一部分。 流可以处于四种状态之一：CREATING、DELETING、ACTIVE、UPDATING。 正在配置处于 CREATING 状态的流。 同样，处于 DELETING 状态的流将从帐户中删除。 当处于活动状态时，流已被配置并准备好进行读写操作。 说来也怪，亚马逊云科技文档还指出，在 ACTIVE 状态下，流已准备好被删除。 现在，我在信息技术及其相关领域工作了很长时间。 有时，读到这样的东西会让我感到困惑。 UPDATING 状态表示重新分片操作正在进行中。 当流处于此状态时，读取和写入操作将继续工作。 Kinesis Data Stream 是一个或多个分片的集合。 可以通过两种主要方式来思考分片。 它是一个规模单位，也是一个并行度单位。 作为规模单位，每个分片都有固定的读写容量。 如果需要更多吞吐量，请添加更多分片。 太多了，把碎片去掉。 作为并行性的单位，可以将更多分片添加到流中以允许并发写入数据记录。 虽然流作为一个整体可以被认为是一个缓冲区，但每个分片都是流中的一种高速有序队列。 流是这些队列的集合。 当数据记录写入 Kinesis Data Stream 时，它会自动跨三个可用区复制。 这使得流具有高度可用性和持久性。 ### KDS 总结 生产者应用程序将数据作为数据记录放入流中。 数据记录由三个主要部分组成； 分区键、序列号和数据 Blob。 数据记录内的数据是 Base64 编码的文本。 数据记录根据其分区键放入分片，并按序列号排序。 一条数据记录只能进入一个分片。 分片既是规模单位也是并行单位。 单个分片可支持每秒1兆字节或1000条记录的数据写入速率； 以较大者为准。 亚马逊云科技跨 3 个可用区自动复制分片，以实现持久性和高可用性。 消费者应用程序处理存储在 Kinesis Data Streams 中的数据记录。 ### KDS 基础 一般来说，当有人提到 Amazon Kinesis Data Stream 时，他们谈论的是大量数据从一个地方高速移动到另一个地方的情况。 事实是，这是对所发生情况的概括。 流数据是一个由多个部分组成的复杂过程。 流媒体这个词是描述性的，但并不完全准确。 在某些方面，这就像将飞行描述为空中旅行。 没有人会直接登上飞机就飞走。 连飞行员也不行。 对于乘客来说，有一个涉及从购买机票、获取登机牌、前往并通过机场、处理行李和随身物品以及登机的所有流程，这些过程甚至发生在飞行部分之前 发生。 这只是乘客体验的一半。 飞机着陆和下机后，这个过程会发生相反的情况，当然，这并不完全相同，因为你处于不同的地方，而机场安全控制的重点是进入的人，而不是离开的人。 因此，流传输不仅仅是高速传输大量数据。 必须配置流。 信息必须正确收集和格式化。 数据必须放入流中，并且同样重要的是，需要检索数据。 这件事并不复杂，但却很复杂。 接下来详细介绍什么是流以及如何将数据传入和传出。Kinesis Data Streams 对开放分片和流中存储的数据记录收费。 规模较小，成本较低。 PUT 有效载荷单位的定价为每百万分四美分。 这两者均以美元计算。 因此，尝试 Kinesis Data Streams 的成本不会很高。 要记住的是，完成学习练习后，删除您创建的一个或多个流。 因为每个人都会收到亚马逊云科技的天价账单，所以其实不差这一个申诉的机会。 创建 Kinesis Data Stream 是一个相对简单的过程。 可以通过亚马逊云科技控制台、以编程方式或使用 Amazon CLI 来完成此操作。 以下是使用 Amazon CLI 创建名为 myStream 的具有 3 个分片的 Kinesis Data Stream 的命令。 Amazon CLI 命令 describe-stream 将显示流的详细信息并包括有关其可用分片的信息。 通常，我发现 JSON 很难阅读，但在这种情况下，我认为查看 JSON 中的描述流的输出将使您更容易理解流的内部结构。 这是完整的输出。 如果您要查找有关 Kinesis Data Stream 的信息，但不包含分片详细信息，则 Amazon CLI 命令是 describe-stream-summary。 首先，每个分片都有自己唯一的 ID。 接下来，请注意第一个分片的 StartingHashKey 为 0，EndingHashKey 具有以 0484 结尾的长数字。下一个分片的 StartingHashKey 范围以比第一个分片的 EndingHashKey 大 1 的长数字开始。 抱歉，我不会大声读出这个数字。 相反，我可以看到它以 0485 结尾。 同样，第三个分片的 StartingHashKey 比第二个分片的 EndingHashKey 大 1。 如果我向流中添加第四个分片，则其 StartingHashKey 将比第三个分片的 EndingHashKey 大 1。 这是一种过于详细的说法，即每个分片都有一个不重叠的唯一哈希键范围。 该哈希键在分片内具有重要作用。 当数据记录放入 Kinesis Data Stream 中时，它包含分区键（作为其负载的一部分）。 Kinesis Data Streams 处理分区键并从中创建哈希值。 正是这个哈希值决定了数据记录写入哪个分片。 因此，类似的数据（例如来自单个源或单个位置的数据）将始终出现在同一个分片中。 这听起来可能像是我在重复自己的话，但理解这一点很重要。 重申一下，生产者应用程序将数据作为一系列数据重新放入流中 绳索。 数据记录是存储在流中的信息单元，由分区键、序列号和数据 Blob 组成。 数据记录的分区键确定流中将写入数据记录的分片。 Kinesis 计算分区键的 MD5 哈希值，并根据该值决定将记录写入哪个分片。 数据记录的序列号是每个分片中唯一的标识符。 这可确保数据按照写入的顺序存储，直到过期。 每个分片的容量是有限的。 您每秒可以在一个分片中放置 1,000 条记录（最多 1 MB 的数据）。 为了最大限度地提高吞吐量，最好将数据记录分布在所有可用的分片上。 为此，亚马逊云科技建议使用创建随机分区键的逻辑。 这将有助于确保记录在流中的分片之间均匀分布。 当分配给单个分片的记录过多时，该分片会变得很热，而其他分片仍然很冷。 值得一提的是，分区键的大小不包含在单个记录有效负载的 1 MB 限制中，但它被计为吞吐量限制的一部分。 最后，数据记录的数据 Blob 是 Base64 编码字节的序列，大小最大可达 1 MB。 该 blob 对于 Kinesis Data Streams 来说既不透明又不可变。 这意味着 Kinesis 不会以任何方式检查、解释或更改数据。 正如我最近提到的，数据记录可以以每秒 1,000 条记录的最大速率放入数据流中，总计可达每秒 1 兆字节。 此限制确定每个流需要配置多少个分片。 如果需要更多吞吐量，可以向流添加更多分片。 这个过程称为重新分片。 重新分片可以通过亚马逊云科技控制台、命令行或以编程方式完成。 对于每秒传输 3,000 条数据记录的用例，需要 3 个分片。 写入 Kinesis Data Stream 时，数据记录会被放入一个分片中进行存储和处理。 它将留在那里直到过期。 一旦进入分片，数据记录就是不可变的； 它们不能被编辑或删除。 如果需要更新数据记录，可以将新记录添加到流中来替换它。 最初，默认有效期为 24 小时，最多可延长至 7 天，但需支付额外费用。 这仍然是事实，并且工作方式与更新之前相同。 存储时间超过 24 小时且最多 7 天的数据记录按每个分片小时收取额外费用。 现在，7 天后，存储在流中的数据将按每月每 GB 计费，持续一年。 保留期是在创建流时配置的，可以使用 IncreaseStreamRetentionPeriod() 和 DecreaseStreamRetentionPeriod() API 调用进行更新。 使用 GetRecords() API 调用从 Kinesis Data Stream 检索超过 7 天的数据也需要付费。 通过 SubscribeToShard() API 调用使用增强型扇出使用者时，长期数据检索不收取任何费用。 我稍后将讨论增强扇出。 数据记录被消耗后，它会保留在流中直到过期。 这允许根据需要重新处理或重播流。 这也意味着多个应用程序可以拥有处理同一流的消费者。 我想谈谈数据流的限制。 其中一些将是评论。 每个数据记录的最大大小限制为 1 MB，每个分片每秒可以接受 1,000 条记录，默认保留期为 24 小时。 数据记录的大小无法增加，但保留期可延长至 7 天（需支付额外费用），最多可延长至一年。 我想从高层次上解决生产者和消费者应用程序所具有的一些限制。 当生产者将记录放入流中时，每个分片每秒写入 1 兆字节或每个分片每秒写入 1,000 次。 如果有 5 个分片，则将有 5 MB 或 5,000 条消息的可用聚合吞吐量。 但是，超过单个分片的写入限制将返回错误：ProvisionedThroughputExceededException。 Amazon Kinesis Data Streams 有 2 种类型的使用者：原始共享吞吐量使用者和增强型扇出。 有些人将原始消费者称为经典消费者或标准消费者。 使用原始共享吞吐量Consumer，每个分片支持每秒2兆字节的读取吞吐量。  所有消费者的每个分片每秒调用 5 次 API 的次数也受到限制。 这意味着每个分片的读取吞吐量最大为每秒 10 兆字节。 与每个分片每秒 5 次 API 调用相关，每个读取请求总共最多可返回 10,000 条记录。 如果达到这些限制，接下来 5 秒内发出的后续请求将引发异常并受到限制。 想一想并算一算，这是合乎逻辑的。 如果一个请求返回 10 MB，则相当于来自分片的 5 秒数据。 Kinesis Data Streams 的优点之一是可以将多个消费者附加到同一个流。 不仅如此，这些消费者应用程序可能有所不同。 一个应用程序可以聚合数据流中的记录，对它们进行批处理，并将该批次写入 S3 以便长期保留。 第二个应用程序可以丰富记录并将其写入 Amazon DynamoDB 表中。 同时，第三个应用程序可以过滤流并将数据子集写入不同的 Kinesis Data Stream。 使用标准 Consumer，应用程序共享相同的每秒 2 MB 的读取吞吐量。 因此，最多只能有两个或三个函数可以同时有效地连接到数据流。 为了使用标准使用者在多个应用程序之间实现更大的出站吞吐量，数据必须分布在多个流中。 如果开发人员需要每秒 10 GB 的读取吞吐量来支持五种不同的应用程序，他们将需要多个包含重复数据的流。 为了解决这个问题，亚马逊云科技向 Kinesis Data Streams 添加了两项功能：增强型扇出和 HTTP/2 数据检索 API。 HTTP/2 是 HTTP 网络协议的重大修订，引入了一种在客户端和服务器之间构建和传输数据的新方法。 它是一种二进制协议，支持旨在减少延迟和提高吞吐量的新功能。 每个增强型扇出消费者每分片每秒获得 2 MB 的吞吐量。 这听起来像标准的消费者，但它是不同的。 标准 Consumer 通过发出 GetRecords()API 请求来检索数据。 数据记录正在从分片中提取。 所有标准消费者共享相同的每秒 2 兆字节的吞吐量。 通过增强型扇出，消费者应用程序将首先向 Kinesis Data Streams 注册自身。 注册后，它可以发出 SubscribeToShard() 请求，并以每秒 2 兆字节的速率将数据发送到应用程序，持续五分钟。 五分钟后，应用程序将需要发出另一个 SubscribeToShard() 请求以继续接收记录。 一旦订阅了分片，数据记录就会自动从分片推送到消费者。 每个增强型扇出消费者都能获得每秒 2 兆字节的完整吞吐量。 没有带宽共享。 这意味着 5 个消费者将获得每个分片每秒 10 兆字节的吞吐量，10 个消费者将获得每个分片每秒 20 兆字节的吞吐量，依此类推。 每个分片每秒 2MB 的限制已经消失。 它可以做到这一点，因为 Amazonc 使用 HTTP/2 将数据推送给使用者。 将数据推送给消费者还消除了每个分片每秒 5 次 API 调用的限制。 这提高了消费者应用程序的扩展能力并显着减少了延迟。 对于标准 Consumer，每个分片每秒的请求数限制为 5 个。 由于一秒为 1,000 毫秒，这意味着每个请求之间大约有 200 毫秒。 分片的第六个消费者将额外增加一秒的延迟。 这意味着，对于标准 Consumer，延迟在 200 到 1,000 毫秒之间。 具有增强型扇出功能的推送模型将此时间平均缩短至 70 毫秒。 这要快得多。 就透视而言，人眼平均眨眼时间约为 100 毫秒。 为了提高性能，成本也会增加。 请注意这一点。 此外，默认情况下，每个流可以注册 20 个消费者应用程序的软限制。 但是，可以通过使用 AWS 创建支持票证来增加此数字。 每个消费者应用程序一次只能注册一个数据流。 标准消费者和增强型扇出都有用例。 如果可以容忍 200 毫秒延迟的消费应用程序少于 5 个，请使用标准 Consumer。 另一个需要考虑的因素是标准消费者的成本也低于增强型扇出。 如果最小化成本很重要，请使用标准 Consumer。 当五到十个应用程序同时使用相同的流并且大约 70 毫秒的延迟非常重要时，请使用增强型扇出。 此外，只有当您可以承受更高的成本时，增强型扇出才有效。 我想花点时间回顾一下我在本次讲座中介绍的 Kinesis Data Stream 的元素。 可以使用亚马逊云科技控制台以编程方式创建流使用开发工具包，或通过 Amazon CLI。 一旦提供了流，费用就开始累积。 创建流时，它必须具有唯一的名称和至少一个分片。 流中的每个分片都有一个分片 ID、一个哈希键范围和一个起始序列号。 分片 ID 对于分片来说是唯一的，哈希键范围在分片之间不会重叠，并且序列号用于保持数据记录的顺序。 当生产者将数据记录写入流时，会根据分区键创建 MD5 哈希值。 该哈希键值决定数据记录写入哪个分片。 当制作者将记录放入流中时，有两个限制。 数据可以以每个分片每秒 1 兆字节的速率写入，或者每个分片每秒可以写入 1,000 次。 有两种类型的使用者可用于读取 Kinesis Data Stream； 标准消费者和增强型扇出消费者。 标准消费者使用轮询方法从流中获取数据。 对于读取，每个分片每秒最多可支持 5 次 API 调用，每秒返回最多 2 兆字节，每秒总共 10,000 条记录。 增强型扇出使用推送机制将数据发送给消费者。 最多可以有 20 个消费者应用程序注册到一个流，每个消费者每秒获得每个分片 2 兆字节的吞吐量。 如果开启这个功能是要增加收费的。  ### 分片容量和扩展  对于写入，Kinesis Data Streams 有硬限制。 每个分片支持每秒最多 1,000 条记录的写入速率，最多每秒 1 MB。 当使用标准消费者进行读取时，每个分片每秒最多可支持 5 个事务，最大读取速率为每秒 2 兆字节。 如果分片上的任一限制超出，则将返回 ProvisionedThroughputExceededException，并且流吞吐量将暂时受到限制。 热分片每秒的读写次数较多，冷分片则相反； 它们每秒的读取和写入次数很少。 热分片可能会导致整个流受到限制。 冷碎片的问题是它们浪费金钱。 碎片如何变热？ 回想一下，每个分片每秒最多可支持 1,000 次写入，最大写入量为 1 MB。 这意味着，如果每个分片平均每秒有 1,000 次写入，则数据记录大小不能大于 1 KB。 任何更大的值都会超出每秒 1 兆字节的限制。 写入流时，如果平均数据记录大小为 2 KB，为避免成为热分片和受到限制的风险，每个分片每秒的写入次数不能超过 500 次。 流的总吞吐量是其分片容量的总和。 这是一个附加过程。 增加分片数量可以提高数据流的处理速度和容量。 同样，删除分片会降低处理速度和流的容量。 如果数据吞吐量增加到超过了读取或写入的可用分片容量，请求将受到限制。 Kinesis Data Streams 可以根据需要进行扩展和收缩以避免浪费资金，但它不是自动的，也不由亚马逊云科技管理。 没有像 Amazon EC2 实例那样可用的 Auto Scaling。 向上或向下扩展 Kinesis Data Stream 涉及一个称为重新分片的过程。 要向 Kinesis Data Stream 添加更多吞吐量，请添加一个或多个分片。 这也称为分片分裂。 它将每个分片每秒增加 1 兆字节的流容量。 分片分裂可用于划分热分片。 当分片被分割时，它会被关闭，现有的数据记录将在过期时被删除。 关闭分片可以防止生产者向其中写入数据，但数据记录在过期之前仍可供消费者使用。  这就是过程的样子。 这是三个碎片。 它们的编号为 1、2 和 3。分片 2 变热，需要拆分。 拆分操作将关闭分片 2（父分片），并创建分片 4 和 5 作为子分片。 分片 4 和分片 5 取代分片 2。即使父分片（分片 2）已关闭写入，消费者仍可以访问其中的数据，直到其过期。 重新分片操作后，流向父分片的数据记录将重新路由到子分片。 与拆分分片以删除或减少分片数量相反的操作称为合并分片。 合并分片将减少可用分片的数量并删除 Kinesis Data Stream 中的容量。 利用率低的分片被称为冷分片。 合并冷碎片以降低成本。 与分片分裂一样，合并分片时有父分片和子分片。 父分片的状态更改为“已关闭”，并且本应发送到父分片的写入操作将重新路由到子分片。 数据记录可从父分片中读取，直至过期。 分片过期后，它们将被删除。 我将说明这个过程。 在我之前的分片拆分操作之后，我的流有 4 个分片。 按顺序是 1、4、5 和 3。分片 5 和 3 已经冷了，我想合并它们以节省成本。 当我执行此操作时，会创建一个新分片，即分片 6。 分片 5 和分片 3（父分片）对写入操作关闭，并且当其中包含的数据记录过期时将被删除。 分片 6（子分片）将接收用于父分片的数据记录以及它自己的数据记录。 重新分片是一个以编程方式管理的过程。 更改分片数量的 API 调用包括 UpdateShardCount、splitShard 和 mergeShards。 UpdateShardCount 是流级 API 调用，会将指定流的分片计数更新为选定的分片数量。 更新分片计数是一种异步操作，可能在主动使用流时发生。 Kinesis Data Streams 将流的状态设置为 “UPDATING”，更新完成后，Kinesis Data Streams 将流的状态设置回 “ACTIVE”。 a 当数据流处于 UPDATING 状态时，可以向数据流写入记录或从数据流中读取记录。 为了更新分片计数，Kinesis Data Streams 根据请求对各个分片执行拆分或合并。 这可能会导致创建临时碎片。 这些临时分片会计入帐户的总分片限制。 使用 UpdateShardCount 时，亚马逊云科技建议指定 25% 倍数的目标分片计数。 选择目标百分比值（例如 25%、50%、75% 或 100%），重新分片过程将比其他目标百分比更快完成。 使用 UpdateShardCount 有一些限制。 您在 24 小时内对流重新分片的次数不能超过 10 次。 扩展时，可以请求的最大分片数量是流中当前分片数量的两倍。 如果你仔细想想，这是有道理的。 分片分裂操作将一个分片变成两个分片。 同样，删除分片时，您不能将流中当前分片计数的一半以下。 此外，无法扩展超过帐户的分片限制。 这些是软限制，可以通过联系亚马逊云科技技术支持来提高。 由于 UpdateShardCount 当前的限制之一是最大分片总数为 10,000 个，因此我推断这是亚马逊云科技的硬限制。 但是，文档中并未明确说明这一点。 也就是说，亚马逊云科技在线文档列出了另一个限制，即如果一个流的分片数量超过 10,000 个，则只有在分片数量少于 10,000 个时才能缩小流的规模。 我确信 10,000 个分片是 Kinesis Data Streams 的硬限制。 思考一下这个限制； 10,000 个分片是很大的流吞吐量。 我想回到扩展操作。 如果由于分片太多或太少而需要扩大或缩小 Kinesis Data Stream，则需要对流进行重新分片。 我已经提到过，在重新分片操作之后，用于父分片的数据将重新路由到子分片。 我想仔细看看。 由于 Kinesis Data Streams 是一项实时数据流服务，因此应用程序应假设数据连续流过流中的分片。 重新分片操作之前父分片中的任何数据记录都保留在这些分片中，并且可以由消费者应用程序读取。 重新分片时，父分片会从 OPEN 状态转换为 CLOSED 状态，然后转换为 EXPIRED 状态。 在重新分片操作之前，父分片处于 OPEN 状态。 数据记录既可以添加到分片中，也可以从分片中检索。 重新分片操作后，父分片将转换为 CLOSED 状态，并且数据记录不再添加到分片中。 但是，数据记录在过期之前仍然可用。 原本应添加到父分片的数据记录现在改为添加到子分片。 一旦父流的保留期到期，父分片中包含的数据记录将无法再访问。 此时，分片本身会转换为 EXPIRED 状态。 重新分片发生后，可以立即从子分片读取数据。 但是，重新分片后保留的父分片可能包含消费者尚未处理的数据。 如果在父分片完全消耗之前从子分片读取数据，则数据可能会乱序。 这是不由亚马逊云科技管理的事情，在创建消费者应用程序时必须考虑到这一点。 重申一下，如果数据的顺序很重要，请确保在从子分片读取之前完全消耗所有父分片。 可以在活动流中拆分和合并分片。 但是，执行此操作时需要注意许多限制。 一次只能进行一次拆分或合并操作。 不可能同时运行多个重新分片操作。 每个拆分或合并请求都需要一些时间才能完成。 根据亚马逊文档，如果一个 Kinesis Data Stream 有 1,000 个分片，并且需要将容量加倍到总共 2,000 个分片，则需要 30,000 秒才能完成。 这已经是8个多小时了。 这里的教训是，如果需要大量容量，请提前配置。 自动扩展不是 Kinesis Data Streams 的功能。 它可以通过结合使用 Amazon Lambda 与 Amazon CloudWatch 和 Amazon Application Auto Scaling 以编程方式实施。 在创建流之前，您需要确定要配置的分片数量。 有许多变量需要考虑，但一般来说，有两个值决定需要配置多少个分片。 这些数字是摄取的数据量和消耗的数据量（以兆字节为单位）。 在这些数字中，较大的数字将决定分片的数量。 为了确定这些值，还需要收集其他数据。 我将同时解释并逐步完成整个过程。 首先，估计将写入数据流的数据记录的平均大小。 该值以千字节为单位，并四舍五入到最接近的千字节。 查看我的数据，平均大小约为 500 字节。 向上舍入到最接近的千字节使该值变为 1,024 字节或 1 千字节。 这是数据的平均大小（以千字节为单位）。 接下来，估计每秒写入数据流的记录数。 对于我的示例流，这是 5,000。 这是每秒的记录数。 然后，决定有多少 Kinesis 消费者应用程序将处理来自流的数据。 这些消费者同时且独立地访问流。 对于我的应用程序，我有 10 个。这是消费者的数量。 要计算流将摄取的带宽，请将每秒记录数乘以数据的平均大小（以千字节为单位）。 5,000 乘以 1 等于 5,000。 这意味着传入写入带宽（以千字节为单位）为 5,000。 这是每秒摄取的数据量。 要计算从流中消耗的数据量，请将传入写入带宽（以千字节为单位）乘以消耗者数量。 5,000 乘以 10 等于 50,000。 传出读取带宽（以千字节为单位）为 50,000。 这是消耗的数据量。 要确定所需的分片数量，请将传入写入带宽（以千字节为单位）除以 1,000，并将传出读取带宽（以千字节为单位）除以 2,000。 这两个数字中较大的一个是 25。因此，所需的分片总数是 25。 值得庆幸的是，亚马逊云科技有一个工具可以为您执行此计算。 它还提供有关成本的额外信息。 您可以使用您最喜欢的搜索引擎并输入 “kinesis data Streams 定价计算器”一词。 目前，链接为 https://aws.amazon.com/kinesis/data-streams/pricing/?trk=cndc-detail 输入我之前使用的相同信息会返回所需的信息及其计算方式。 请注意，在撰写此内容时，课程信息是准确的。 价格可以而且确实会随着时间的推移而变化。 目前，定价计算器显示我需要 24.4 个分片，四舍五入后总共需要 25 个分片。 出于计费目的，每月有 730 小时。 每月 25 个分片乘以 730 小时，得出 18,250 个分片小时。 以每个分片小时 1.5 美分的成本计算，18,250 乘以 0.015 美元等于 273.75 美元。 PUT 有效负载是使用 5,000 条大小为 1 KB 的记录计算的。 我不会大声地进行计算，但我会在这里向您展示。 将数据放入我的流中的成本为 183.96 美元。 5,000 条大小为 1 KB 的记录需要具有 25 个分片的 Kinesis Data Stream，每月费用约为 457.71 美元。 请记住，在 Kinesis Data Stream 中存储数据可能超过 7 天，并且会增加这些费用。 ### 总结 Kinesis Data Streams 吞吐量基于其拥有的分片数量。 对于每个分片的写入，限制为每秒 1,000 条记录，最多每秒 1 MB。 使用标准消费者时，每个分片每秒最多可支持 5 个事务，最大读取速率为每秒 2 兆字节。 - 热分片每秒的读写次数较多，冷分片则相反； 它们每秒的读取和写入次数很少。 - 热分片可能会导致限制。 - 冷碎片浪费钱。 - 流的总可用吞吐量是其分片容量的总和。 - Kinesis Data Streams 可以扩展，但不能实时扩展。 - 缩放过程称为重新分片。 - 添加分片是使用称为分片拆分的过程来完成的。 - 删除分片就是分片合并。 - 当分片被拆分或合并时，就会出现父分片和子分片。 父分片无法写入，但可以读取，直到过期。 - 当父分片关闭时，针对其的写入操作将重新路由到子分片。 - 通常增加或减少流中分片数量的过程是使用 UpdateShardCount API 调用完成的。 - 可以拆分或合并各个分片。 这些 API 调用分别是 splitShard 和 mergeShards。 - 分片可以处于三种状态之一：打开、关闭和过期。 - 分片分割可以在活动的流上完成。 - 但是，一次只能进行一个拆分或合并操作，并且每个操作都需要时间才能完成。 - 自动扩展不是 Kinesis Data Streams 的功能。 - 成本基于流中的分片数量和放入流中的数据量。  ### Data in a Kinesis Data Stream 一般来说，Amazon Kinesis Data Streams 是亚马逊云科技的实时数据提取服务。 但是，将 Kinesis Data Stream 描述为流存储层更为准确。 当从高层次观察流处理的工作原理时，这更有意义。 一般来说，实时数据流有五层。 包括源层、流摄取层、流存储层、流处理层和目的地。 1. 源层是从各种来源收集的数据。 蒸汽摄取层是一个应用程序层，它收集源数据并将其发布到第三个组件，即流存储层。 流处理层是一个或多个消费者读取并处理流存储层中的数据的地方。 此处理包括 ETL、聚合、异常检测或分析。 最后一层是目的地，例如数据仓库、数据湖或关系数据库。 其中，数据湖是最常见的。 1. 实际的摄取（即将数据放入 Kinesis Data Stream）是使用生产者或生产者应用程序完成的。 生产者包括 Amazon Kinesis Agent 以及使用 Amazon Kinesis Producer Library 或 Amazon SDK 构建的自定义应用程序。 数据由生产者实时收集并存储在 Kinesis Data Stream 中。 它可以在几毫秒内提供给消费者应用程序。 但是，数据将保留在 Kinesis Data Stream 中直至过期。 保留期意味着 Kinesis Data Stream 是用于流处理的存储层。 让我们更详细地看一下。 生产者是捕获数据并将其发送到 Kinesis Data Streams 进行实时处理的应用程序。 可以使用亚马逊云科技开发工具包、Amazon Kinesis Producer Library、Kinesis Agent 和第三方工具创建 Producer。 Kinesis Data Streams 和 Kinesis Data Firehose 之间的主要区别在于，Kinesis Data Streams 通常需要自定义代码才能从流中获取数据。 然而，Data Firehose 是一项完全托管的服务，包括生产者、流和消费者。 借助 Kinesis Data Streams 并将其视为存储层，可以使用多个不同的消费者应用程序访问数据流。 Kinesis Data Firehose 不具备此功能。 这是一系列的权衡。 在 Kinesis Data Streams 不自动扩展的情况下，Firehose 流会根据需要自动扩展。 此外，无法创建自定义应用程序来直接使用数据。 相反，可以使用 Amazon Lambda 函数在数据进入 Firehose 数据流之前对其进行转换。 如果您只想将数据流式传输到持久存储（例如 S3），从开发的角度来看，Firehose 会更容易，因为这就是它的设计目的。 创建自定义 Kinesis Producer 应用程序时，可以使用 Kinesis SDK 以编程方式将数据直接发送到数据流中。 还可以从亚马逊云科技命令行界面调用 API。 作为示例，以下是如何使用单个分片从 Amazon CLI 创建名为 myStream 的流。 参数 --shard-count 是必需的，因为分片是 Kinesis Data Stream 中的规模单位，并且每个数据记录都放入分片中。 分片也可以被视为数据流中的分区，但这可能会导致一些术语混淆，因为将数据放入 Kinesis Data Stream 时，所需参数之一是分区键。 Kinesis 使用 Partition Key 参数来确定存储数据时在流内使用哪个分片。 因此，可以将分片视为一个规模单位。 可用吞吐量（包括可以存储在流中的数据量）和流的成本由配置的分片数量决定。 更多分片意味着更高的吞吐量。 更多的碎片也会带来更大的成本。 使用命令行查看流的状态时，请使用 Amazon CLI 命令 describe-stream-summary。 这将提供流的状态，但不提供有关分片的任何详细信息。 例如，查看先前创建名为 myStream 的流的命令的状态。 它会返回看起来像这样的东西。 在此示例中，StreamStatus 为 ACTIVE。 虽然它在这个过程中如果正在配置，StreamStatus 为 CREATING。 当使用 Amazon CLI 并将结果通过管道传输到 jq 时，此命令将仅返回状态。将 JSON 格式的输出通过管道传输到 jq。 -r 意味着我想要原始输出。 我不想要带引号的 JSON 格式输出。 这仅是个人喜好。 单引号里面是我想要的数据。 从 StreamDiscriptionSummary 我想要 StreamStatus。 如果您打算花费大量时间使用 Amazon CLI 或开始使用 JSON，jq 将帮助您快速轻松地获取所需的信息。 另外，为了使此代码更具可读性并更好地适合屏幕，我使用了行继续字符。 在 Linux 中，行继续符是反斜杠。 使用 PowerShell 时，有两个字符充当续行符； 反引号 (`) 或竖线 (|) 符号。 Kinesis Producer Library（也称为 KPL）和命令行界面使用相同的 API 与服务交互。 我将花一些时间来浏览其中一些并展示它们是如何工作的。 其目的是说明 Kinesis Data Stream 生产者应用程序如何将数据记录放入流中，并展示消费者应用程序如何访问数据流。 有两个不同的 API 调用可用于将数据记录写入 Kinesis Data Stream：putRecord() 和 putRecords()。 putRecord() 方法将单个数据记录写入 Kinesis Data Stream。 或者，当需要写入一批记录时，请使用 putRecords()。 当同时写入多条记录时，putRecords() 支持批量最多 500 条记录或 5 MB 数据。 一般来说，putRecords() 优于使用 putRecord()。 与 putRecord() 一样，putRecords() 需要流名称和数据。 但是，分区键是与数据一起发送的。 使用 putRecords() 发送相同的三个名称（更新时间）会返回不同类型的输出。 此回复中有几件事需要注意。 FailedRecordCount 为 0。列出了 3 条记录。 从吞吐量的角度来看，Kinesis Data Streams 以与单个请求相同的方式处理批处理记录。 在批处理中，每条记录都被单独考虑，并根据分片的总体吞吐量限制进行计数。 然而，一次将一条记录放入 Kinesis Data Stream 可能会产生大量请求开销。 将记录放入批次可减少向亚马逊云科技发出的 HTTP 请求的大小和数量。 批处理记录可以提高应用程序的性能。 如果应用程序必须等待每个单独的请求完成，则大量请求将增加生产者应用程序的延迟。 作为一般规则，如果可能，首选批处理操作。 使用 API 或 SDK 创建具有多线程的消费者应用程序时； 每个线程结合使用 GetRecords() API 和 getShardIterator() API 从分片获取数据。 分片迭代器指定流中开始读取数据记录的位置。 该位置可以是序列号、时间戳、流中的第一个记录或最新记录。 每个分片以每秒 2 兆字节的速率返回数据。 这是服务的限制，无法更改。 流上可用的吞吐量是所配置分片的总和。 例如，如果有 6 个分片，则流的下游总吞吐量将为每秒 12 MB，但每个分片自身的吞吐量限制为每秒 2 MB。 GetRecords() API 调用是一种轮询操作，在单个分片上每秒只能进行 5 次。 这也是服务的限制且无法更改。 这意味着消费者从流中请求数据的最快速度是每 200 毫秒一次，因为它必须保持在 5 个请求的阈值以下每秒 sts。 如果消费者以 100 毫秒的轮询窗口调用 GetRecords()，则意味着每秒会发出 10 个请求。 其中 5 个请求将受到限制，并且 Kinesis 服务将返回异常。 然后，消费者必须处理异常，执行某种退避操作，然后重试请求。 从流请求数据时需要注意两个最大值。 单个 GetRecords()API 请求可返回的最大记录数为 10,000。 单个 GetRecords() 请求可返回的最大数据量为 10 MB。 如果请求返回这么多数据，接下来 5 秒内进行的后续调用将返回 ProvisionedThroughputExceededException。 这使吞吐量保持在每秒 2 MB。 与轮询窗口示例一样，处理 10 MB 数据记录的使用者需要具有某种类型的逻辑来处理后续请求。 这些限制是针对每个分片的。 如果多个消费者访问单个分片，他们共享每秒 2 MB 的限制和 200 毫秒的访问速率。 将其转化为整数，这意味着如果单个分片有 5 个消费者对其进行轮询，则每个消费者每秒都能够访问该分片一次。 有时我在脑海中想象这样的数学时会遇到问题。 所以，我将进一步分解它。 一秒有 1000 毫秒。 如果这一秒除以 200 毫秒的限制，1,000 除以 200 就是 5。5 个消费者每秒可以访问一个分片一次。 同样，由于分片的吞吐量限制为每秒 2 MB，因此将这一量分配给 5 个消费者意味着每个消费者每秒可以接收约 400 KB 的数据。 这里的要点是，将消费者添加到分片会降低每个消费者的可用吞吐量。 对于某些人来说，这种限制是一个问题。 值得庆幸的是，亚马逊云科技创建了一种名为增强型扇出的新型消费者来解决这个问题。 您可以在本课程第 1 部分的标题为 Kinesis Data Stream 的元素的讲座中了解有关增强扇出的更多信息。 消费者应用程序工作方式的简化版本如下所示。 它以一个循环开始。 使用 getShardIterator() 获取数据流中第一个可用数据记录的位置。 流中最古老的记录位于修剪地平线处。 事实上，从 Kinesis Data Stream 中获取数据记录有五个可能的起始位置。 AT_SEQUENCE_NUMBER 将从数据流中的特定位置开始读取。 AFTER_SEQUENCE_NUMBER 将在指定位置之后开始读取。 AT_TIMESTAMP 将在指定时间开始从数据流读取。 TRIM_HORIZON——正如我最近提到的——从分片中最旧的记录开始。 LATEST 从放入分片的最新记录开始。 getRecords() 返回几个元素。 其中之一是值 NextShardIterator。 这是分片中的下一个序列号。 将此值与 getRecords() 一起使用以获取下一个数据记录。 继续循环，直到 get 返回 null 值。 当为 null 时，分片已关闭，请求的迭代器将不再返回任何数据。 如果说我在云工作中学到了什么教训的话，那就是失败时有发生。 好吧，也许这不是确切的教训。 失败的发生更是人生的教训，这并不是云计算所独有的。 再想一想，我在将工作负载放入云中时学到的就是预测各种类型的故障并做出相应的响应。 在计算的早期——早在大型机时代——编写代码的重点更多地放在防止错误发生上。 这一点还是很重要的。 编写能够高效、经济地解决问题的高质量代码仍然至关重要。 也就是说，系统越分散，发生故障的地方就越多。 应用程序开发人员无法控制的故障。 预期失败的发生意味着我可以以一般的方式预测它们。 Amazon Kinesis Data Streams 就是如此。 如果请求由于所谓的可重试失败而失败，则亚马逊云科技开发工具包默认会重试该请求最多 3 次。 例如，由于 ServiceUnavailable 或类似的暂时性 500 级错误而导致失败。 重试使用一种称为指数退避的方法。 默认延迟为 100 毫秒，随后重试之间的时间呈指数增长。 配置流时，重试次数和基本延迟是可配置的并且可以更改。 虽然 Amazon SDK 似乎内置了故障管理，但在某些情况下事实并非如此。 如果服务可用，但由于超出了预配置的吞吐量而未处理一条或多条记录，则可能会收到 200 响应（表示请求成功）。 如果 FailedRecordCount 的值大于 0，则表示存在请求部分失败。 某些记录已成功写入流，但其中一个或多个记录失败。 批处理操作不是原子的。 原子事务是一种要么完全成功，要么完全失败的事务。 适用于 Kinesis Data Streams 的亚马逊云科技开发工具包会将部分失败视为成功，然后继续处理下一个事务。 这意味着，在使用 Amazon SDK 构建 Producer 应用程序时，依赖 200 响应代码可能会导致数据丢失。 此类故障的主要原因是超过流或单个分片的吞吐量。 即使在仔细计算吞吐量要求并适当配置流之后，由于流量峰值和网络延迟，这种情况也可能发生。 这些事情可能会导致记录不均匀地放入流中。 反过来，这会导致吞吐量激增。 要减少在 VPC 内运行的生产者应用程序的网络延迟，请始终使用接口 VPC 终端节点。 这将使 Amazon VPC 和 Kinesis Data Streams 之间的流量保持在 Amazon 网络内。 否则，从 VPC 到 Kinesis Data Streams 的流量需要通过互联网网关路由。 使用终端节点，Kinesis Data Streams 的流量保留在 VPC 内。 这可以最大程度地减少延迟并降低数据暴露在公共互联网上的风险。 当涉及到处理尖峰流量时，您可以尝试在生产者应用程序中实现某种形式的背压。 在软件开发中，背压是借鉴于流体动力学的概念。 它是对通过管道的所需气体或液体流量的阻力。 在 Kinesis 的上下文中，背压通常是指阻止数据按预期流过流的阻力。 Kinesis Data Streams 使用生产者应用程序从源获取数据，将其放入流中，然后使用消费者应用程序将其传送到目标。 背压是指通过流移动数据的过程遇到阻力。 有些东西减慢了它的速度。 这可能是由于计算资源不足、吞吐量限制或架构设计造成的。 顺便说一句，英语可能很棘手。 有人使用“背压”一词来描述可以管理数据流阻力的系统。 您可能会读到或听到有人将他们的代码描述为具有内置背压。 听起来他们在逻辑中对数据移动进行了编程抵抗。 根本不是这样的。 他们的意思是，他们的代码能够在发生背压时检测和处理背压。 结论是，对部分失败进行适当的错误处理和重试非常重要。 当 FailedRecordCount 大于 0 时，可以手动重试。 要获取正确的记录，请使用 PutRecords() 请求响应中的记录数组。 它包含与出站请求的顺序完全相同的各个记录响应。 比较两个数组并选择具有 ErrorCode 和 ErrorMessage 而不是 RecordId 的记录。 重试次数的上限很重要。 在某些时候，进程需要放弃并将请求发送到相当于 SQS 死信队列的位置。 将记录放入 Kinesis Data Stream 需要付出相当大的努力。 数据的格式必须正确，并且需要错误处理。 您自己完全可以做到这一点。 然而，在亚马逊云科技创建 Kinesis 的人们意识到这将成为一种常见且常规的需求。 为了解决数据摄取和使用的复杂性，他们创建并发布了一对库以使其变得更容易。 Kinesis Producer Library（或 KPL）是亚马逊云科技提供的库，可将数据放入 Kinesis Data Stream。 它的创建是为了简化 Kinesis 生产者应用程序的开发，并允许程序员实现 Kinesis 数据流的高写入吞吐量，同时管理异常和错误处理。 使用 SDK，putRecord() 和 putRecords() 方法会将一个或多个数据记录放入 Kinesis Data Stream 中。 当数据需要以一致的方式分区并传递到多个分片时，这些方法甚至可以处理写入正确的分片。 那么，为什么还要去 KPL 呢？ 嗯，在使用 SDK 时，有一些限制在第一次使用时并不完全明显。 Amazon Kinesis 分片按小时计费，支持每秒写入多达 1,000 条记录，最大速率为每秒 1 兆字节。 二进制和 Base10 数学混合时，可能会产生一些相当有趣的舍入错误，令人沮丧和困惑。 现在，我试图保持简单。 为了便于讨论，1,000 KB 是 1 MB。 这是在 Base10 中。 如果是 Base Base2（二进制），1,024 KB 就是 1 MB。 不同的 ce 看似很小，但影响却很大。 现在，我将使用 Base10 中的 1,000 KB 为兆字节的概念。 达到 Kinesis Data Stream 输入限制的一种方法是以每秒 1,000 条的速率写入 1 KB 大小的记录。 这大约是 1 兆字节。 在现实世界中，这是不太可能的，因为大多数流数据都是由小得多的记录组成的。 例如，考虑一个监视失败登录尝试并将每个登录尝试发送到 Kinesis Data Stream 的系统。 每个数据记录可能仅包含一个 URL、一个 IP 地址和用户名，并且其大小可能为 50-60 字节，而不是 1,000。 如果您没有充分利用分片，那么您基本上就是在向 Amazon Web Services 付费，因为您正在为未使用的吞吐量付费。 我个人的看法是AWS已经从我这里得到了足够的钱。 我不需要再给了。 我无法让你有我这样的感觉。 我所能做的就是鼓励和支持。 浪费钱万岁？！？ 就支出而言，最糟糕的情况是将单个字节写入分片并为每秒 1,000 字节的使用支付全部费用。 解决方案是在将多个记录写入 Kinesis Data Stream 之前将其放入单个数据记录中。 为了管理将多个记录放入单个数据记录中，亚马逊云科技创建了 Kinesis Producer Library（KPL）用于数据记录聚合。 它有一个姊妹库，即 Kinesis 客户端库（KCL），可以进行数据记录解聚合。 这个想法是使用尽可能多的可用吞吐量。 数据记录对 Amazon Kinesis 来说是不透明的。 该服务本身对其内部内容的可见性为零。 因此，必须在数据进入流之前和流出之后对其进行管理。 这可以手动完成。 然而，亚马逊云科技意识到有足够多的人需要此类功能，因此他们发布了这些库。 KPL 根据亚马逊软件许可证获得许可，该许可证授予… “……永久、全球性、非排他性、免版税、复制、准备衍生作品、公开展示、公开表演、再许可和分发其作品以及任何形式的衍生作品的版权许可。” 将小记录写入 Kinesis Data Stream 时，使用 KPL 可以提高吞吐量并降低成本。 KPL 旨在与 Kinesis Data Streams 配合使用，而不是与 Kinesis Data Firehose 配合使用。 KPL 只能将数据放入 Kinesis Data Stream。 Firehose 有自己的数据流生产者。 然而，有趣的是 Firehose 的可能生产者之一是 Kinesis Data Streams。 解决方法是将数据记录与 KPL 聚合并将其放入 Kinesis Data Stream 中。 然后，让 Data Firehose 使用数据流作为生产者。 Firehose 足够智能，可以识别 KPL 聚合的数据，并可以在将数据记录发送到目的地之前对其进行适当的解包。 KPL 内置了重试逻辑。 当 putRecords() 调用返回失败或异常时，KPL 将自动重试。 有完整的错误处理机制，可以在适当的时候进行重试。 使用 KPL 放入流中的记录应始终在 Kinesis Data Stream 中至少出现一次。 创建 Kinesis 客户端库是为了从由 KPL（Kinesis Producer Library）创建的 Kinesis 数据流中读取数据。 KPL 聚合记录以最大化分片和写入利用率。 KCL 反过来对记录进行分解。 然而，KCL 只是一个处理 KPL 创建的记录的应用程序框架。 KCL 负责处理与流和分布式计算相关的许多复杂任务。 KCL 可以跨多个 Consumer 应用程序实例进行负载平衡，通过检查点记录响应 Consumer 应用程序实例故障，并对重新分片操作做出反应。 基本上，它充当记录处理逻辑和 Kinesis Data Streams 之间的中介。 KCL 会自动完成大部分工作，而不是手动编写创建 Consumer 应用程序所需的所有逻辑。 KCL 与亚马逊云科技开发工具包中提供的 Kinesis Data Streams API 不同。 Kinesis Data Streams API 允许您管理 Kinesis Data Streams，包括创建流、重新分片以及放置和获取记录。 KCL 围绕所有这些常见任务提供了一个抽象层，这样您就不必在每次需要创建消费者应用程序时都构建它们。 这里值得一提的是 KCL 的几个功能。 KCL 提供了一个检查点功能，允许使用者在应用程序出现故障时恢复进度。 当应用程序重新上线时，它可以从上次中断的地方继续。 检查点使用 DynamoDB 跟踪与数据记录的序列号相关的子序列号。 在 DynamoDB 内部，每个 sh 占一行此处值得一提的原因是，通过检查点功能，可以体验与 DynamoDB 配置相关的限制。 这意味着 Kinesis Data Stream 可能已正确配置，但如果 DynamoDB 没有足够的读取容量单位或写入容量单位，吞吐量将受到限制。 解决此问题的方法是使用 DynamoDB 的按需配置。 结论是，配置不足的 DynamoDB 表可能会限制 KCL 性能。 ### 小总结 一般来说，数据流服务有五层。 源层、流摄取层、流存储层、流处理层和目的地。 虽然 Amazon Kinesis Data Streams 描述了亚马逊云科技的整个流服务，但 Kinesis Data Stream（单数）是流数据的存储层。 从 Amazon CLI 创建流使用 create-stream API 调用。 要从 Amazon CLI 查看流的状态，请使用 describe-stream 或 describe-stream-summary API 调用。 要将数据记录放入流中，API 调用为 putRecord() 和 putRecords()。 API 调用 getShardIterator() 用于确定从分片中的何处开始读取数据。 特定序列号、特定序列号之后的数据记录、时间戳、最旧的数据记录或最新的数据记录都是有效选项。 亚马逊云科技发布了 Kinesis 生产者库 (KPL) 和 Kinesis 客户端库 (KCL)，旨在快速高效地构建生产者和消费者。 KPL 聚合记录，KCL 解聚合记录。 KCL 还可以自动处理与创建 Consumer 应用程序相关的常见任务。 ### Kinesis Data Streams Security 在生产帐户中，遵循最小特权原则非常重要。 这样做的原因有很多，通常分为三类： 组织、技术和个人。 一般来说，我们是我们所关心的数据的管理者。 从组织的角度来看，为人们提供完成工作所需的最少访问权限可确保限制未经授权的访问和使用数据的风险。 从技术角度来看，构建一套模块化的数据管理控制措施可以使组织内的合规性更易于管理、遵守和执行。 考虑到个人原因和人性本质，随着时间的推移，给予人们更多特权总是比剥夺访问权更容易。 尝试取消任何内容的权限，看看会发生什么。 换句话说，您还记得有人剥夺了您的访问权限吗？ 即使你不需要它们——或者拥有它们会给你的生活带来不必要的压力——它也会对你的情感产生影响。 为您省去很多麻烦，并使用最小特权原则来保护您所关心的数据。 我将快速回顾一下身份和访问管理在亚马逊云科技中的工作原理。 现在，如果您还不熟悉 Amazon IAM 的工作原理或者只是需要一点提醒，我将花点时间来讨论一下。 一旦您在亚马逊云科技云中工作了足够的时间，您就会痛苦地意识到所有服务的默认权限都是 DENY。 也就是说，在亚马逊云科技云内部，为了能够执行任何操作，必须明确授予权限。 为此，需要创建策略文档并将其附加到需要访问服务或资源的用户、组或角色。 IAM 策略内部包含三个基本元素：效果、操作和资源。 效果是允许或拒绝。 拒绝权限不能被覆盖。 动作就像句子的动词。 它描述了可以做什么。 例如，此语句将允许执行 DescribeStreamSummary 和 ListStreams 操作。 在单词 Get 后使用星号表示允许以单词 Get 开头的任何操作。 这将包括 GetShardIterator 和 GetRecords 等语句。 资源是流的 Amazon 资源名称。 如果您不熟悉 ARN，它代表 Amazon 资源名称，它们唯一地标识亚马逊云科技内的资源。 各个字段用冒号分隔。 我将从 arn 开始遍历每个字段。 正如我已经说过的，arn 代表 Amazon 资源名称。 基本上就是自我认同。 amazon 存在于每个 ARN 中。 第三个字段是服务，在本例中为 Kinesis。 第四是区域。 第五个字段是帐号。 最后是流。 它有一个流前缀和一个正斜杠，后面跟着一个特定的流名称。 ARN 中允许使用星号，它们充当通配符。 这是一个 IAM 策略，允许用户将数据添加到帐户中的任何流。 此 IAM 策略中 PutRecord 后面的星号表示 API 调用 PutRecord() 和 PutRecords() 将起作用。 这是一份更长的政策文件。 它允许用户或组对特定流（在本例中为 stream1）执行 DescribeStreamSummary、GetShardIterator 和 GetRecords 操作，并对任何流执行 ListStreams。 请注意，在此策略中，资源是一个星号。 这意味着帐户中使用此策略的任何流。 我无法创建允许访问除我自己的帐户之外的帐户的策略。 那是荒谬的。 重申一下，在生产帐户中使用最小权限原则非常重要。 我们不拥有数据，我们是我们所管理的数据的管理者。 保护委托给我们的信息非常重要。 关于安全主题，创建 IAM 的最佳实践 使用 Kinesis Data Streams 的策略包括根据角色创建 4 种不同的策略。 应该有一个针对管理员、流重新分片、生产者进行写入以及消费者进行读取的策略。 为了说明这一点（这并不是一个详尽的列表），请考虑这个例子。 管理员需要具有 IAM 操作，例如 CreateStream、DeleteStream、AddTagsToStream 和 RemoveTagsFromStream。 对于那些需要重新分片流的 IAM 操作包括 MergeShards 和 SplitShard。 生产者需要 IAM 操作DescribeStream、PutRecord 和 PutRecords 才能写入数据记录。 同样，消费者需要 IAM 操作 GetRecords 和 GetShardIterator 才能从 Kinesis Data Stream 中读取数据。 每个角色都需要执行其他操作。 例如，我认为消费者的策略可能也可以使用 DescribeStream。 对于任何职位描述都没有单一的最佳政策。 这取决于您的组织需要哪些其他服务和操作。 请务必查阅文档以了解可能的情况并根据需要匹配适当的操作。 您可能会发现您不知道的流数据功能，或者学习管理现有流程的更好方法。 另外，我应该提到，在适当的时候以 IAM 角色的形式使用临时安全凭证是亚马逊云科技的一般最佳实践。 在需要时承担一个角色，并在完成后放手。 除了使用 IAM 策略来控制访问之外，Kinesis Data Streams 还可以使用 HTTPS 端点对传输中的数据进行加密。 使用 Amazon Key Management Service (KMS)，可以对静态数据进行加密。 使用 KMS，数据记录在写入 Kinesis 流存储层之前进行加密，并在检索后进行解密。 因此，数据记录在 Kinesis Data Streams 服务中进行静态加密，以满足法规要求并增强数据安全性。 可以在客户端加密数据。 然后数据也必须在客户端进行解密。 这是一个手动过程，比使用 KMS 更具挑战性，因为亚马逊云科技无法提供任何帮助实施客户端加密的方法。 如果您需要 FIPS 140-2 加密，可以使用 FIPS 端点。 如果您不知道 FIPS 是什么，您可能不需要使用 FIPS 端点。 不过，仅供参考，FIPS 代表联邦信息处理标准。 它是一组标准，描述了文档处理、加密算法和其他信息技术标准，供非军事政府机构以及与这些机构合作的政府承包商和供应商使用。 如果 Kinesis 应用程序位于 VPC 中，请使用 VPC 终端节点访问 Kinesis Data Streams。 Kinesis 和应用程序之间的所有网络流量都将保留在 VPC 内。 从本质上讲，VPC 终端节点允许您从 VPC 内部连接到亚马逊云科技服务，而无需访问公共 Internet。 它们消除了将 Internet 网关或 NAT 网关连接到私有子网的需要。 端点由亚马逊云科技管理，自动水平扩展且高度可用。 所发生的情况是，ENI（弹性网络接口）是使用 VPC 子网内的私有 IP 地址来配置的。 安全组用于限制对此 ENI 的访问，并用于将流量发送到所需的服务，例如 Kinesis Data Streams。 作为回顾，我介绍了与使用 Kinesis Data Streams 的安全性相关的问题。 ### 小总结 在亚马逊云科技内部配置资源时，请记住使用最小权限原则。 这在开发环境中可能不太重要，但是在生产环境中，您的个人和职业目标之一应该始终是避免创建 RBE（简历构建事件）。 Kinesis Data Streams 的最佳实践包括为管理员、流重新分片、生产者进行写入以及消费者进行读取制定单独的安全策略。 对于传输中的流数据，可以使用 HTTPS 端点。 在 Kinesis Data Stream 内部，可以使用 KMS 加密和解密数据记录。 使用 Kinesis Data Streams 和 VPC 时，使用 VPC 终端节点将网络流量保留在 VPC 内并远离公共 Internet。 ### Kinesis Data Streams Summary Kinesis Data Streams 是 Amazon Kinesis 的功能之一。 它是一种可大规模扩展且持久的实时数据流服务。 它用于从网站点击流、数据库事件流、金融交易、社交媒体源、IT 日志、位置跟踪事件和物联网设备等来源收集数据。 收集的数据可在流内几毫秒内获得，并使应用程序能够实时执行分析、仪表板、异常检测和动态定价等操作。 我想总结一下本课程两个部分的要点。 Kinesis Data Stream 由分片组成。 生产者应用程序将数据作为数据记录放入流中。 数据记录由三个主要部分组成； 分区键、序列号和数据 Blob。 数据记录内的数据是 Base64 编码的文本。 数据记录根据其分区键放入分片，并按序列号排序。 一条数据记录只能进入一个分片。 分片既是规模单位也是并行单位。 单个分片可支持每秒1兆字节或1000条记录的数据写入速率； 以较大者为准。 亚马逊云科技跨 3 个可用区自动复制分片，以实现持久性和高可用性。 可以使用亚马逊云科技控制台、使用开发工具包以编程方式或通过 Amazon CLI 创建流。 一旦提供了流，费用就开始累积。 创建流时，它必须具有唯一的名称和至少一个分片。 Kinesis Data Streams 吞吐量基于其拥有的分片数量。 分片 ID 对于分片来说是唯一的，哈希键范围在分片之间不会重叠，并且序列号用于保持数据记录的顺序。 当生产者将数据记录写入流时，会根据分区键创建 MD5 哈希值。 该哈希键值决定数据记录写入哪个分片。 有两种类型的使用者可用于读取 Kinesis Data Stream； 标准消费者和增强型扇出消费者。 标准消费者使用轮询方法从流中获取数据。 对于读取，每个分片每秒最多可支持 5 次 API 调用，每秒返回最多 2 MB，每秒总共 10,000 条记录。 增强型扇出使用推送机制将数据发送给消费者。 可以有 20 个消费者应用程序注册到一个流，每个消费者每分片每秒获得 2 兆字节的吞吐量。 这就是本课程第一部分所涵盖的内容。 在第二部分中，我们了解到热分片每秒的读写次数较多，而冷分片则相反； 它们每秒的读取和写入次数很少。 热分片可能会导致限制。 冷碎片浪费钱。 Kinesis Data Streams 可以纵向扩展和缩减，但不能实时扩展。 扩展以编程方式完成，并且不是由亚马逊云科技自动完成。 您必须监控流以确保拥有正确的吞吐量。 缩放过程称为重新分片。 添加分片是使用称为分片拆分的过程来完成的。 删除分片就是分片合并。 当分片被拆分或合并时，就会出现父分片和子分片。 父分片无法写入，但可以读取，直到过期。 当父分片关闭时，针对其的写入操作将重新路由到子分片。 一般来说，数据流服务有五层。 源层、流摄取层、流存储层、流处理层和目的地。 虽然 Amazon Kinesis Data Streams 描述了亚马逊云科技的整个流服务，但 Kinesis Data Stream（单数）是流数据的存储层。 从 Amazon CLI 创建流使用 create-stream API 调用。 要从 Amazon CLI 查看流的状态，请使用 describe-stream 或 describe-stream-summary API 调用。 要将数据记录放入流中，API 调用为 putRecord() 和 putRecords()。 API 调用 getShardIterator() 用于确定从分片中的何处开始读取数据。 有效选项有：特定序列号、特定序列号之后的数据记录、时间戳、最旧的数据记录或最新的数据记录。 亚马逊云科技发布了 Kinesis 生产者库 (KPL) 和 Kinesis 客户端库 (KCL)，旨在快速高效地构建生产者和消费者。 KPL 聚合记录，KCL 解聚合记录。 KCL 还可以自动处理与创建 Consumer 应用程序相关的常见任务。 在亚马逊云科技内部配置资源时，请记住使用最小权限原则。 这在开发环境中可能不太重要，但是在生产环境中，目标之一是避免创建 RBE（简历构建事件）。 Kinesis Data Streams 的最佳实践包括为管理员、流重新分片、生产者进行写入以及消费者进行读取制定单独的安全策略。 在 Kinesis Data Stream 内部，可以使用 KMS 加密和解密数据记录。 使用 Kinesis Data Streams 和 VPC 时，使用 VPC 终端节点将网络流量保留在 VPC 内并远离公共 Internet。 [](https://summit.amazoncloud.cn/2024/register.html?source=DSJAVfG2GS7gEk2Osm6kYXAa+8HnSEVdbCVjkuit7lE= )