Atlas Stream Processing根据层级为每个流处理器分配资源。固定的资源分配和费用提供了可预测性，从而简化了系统设计进程。在规划部署时，使用本指南了解哪些层级最适合您的 Stream Processing 工作负载。
资源分配
每个层级都提供固定分配的处理能力、内存、带宽、并行性以及分区（对于具有Apache Kafka源的处理器）。
层级 | vCPU | RAM (GB) | 带宽 (Mbps) | 最大并行度 | 源Kafka分区限制 | 初始同步集合限制 |
|---|---|---|---|---|---|---|
SP 2 | 0.25 | 0.5 | 50 | 1 | 32 | 1 |
SP 5 | 0.5 | 1 | 125 | 2 | 64 | 1 |
SP 10 | 1 | 2 | 200 | 8 | 无限制 | 5 |
SP 30 | 2 | 8 | 750 | 16 | 无限制 | 10 |
SP 50 | 8 | 32 | 2500 | 64 | 无限制 | 50 |
并行度
并行度决定了流处理器可以使用多少线程或并发请求来读取、丰富和写入数据。您可以在各个管道阶段配置并行度，但Atlas Stream Processing会根据上表中显示的处理器层级的最大值在整个处理器中强制执行并行度。
支持并行的阶段
以下阶段接受 parallelism 值。每个默认值为 1。
阶段 | 更高值的影响 |
|---|---|
| |
增加向 | |
增加Atlas Stream Processing分发写入操作的线程数，这要求流处理器及其写入集群使用更多计算资源。 | |
增加 Sink操作符使用的内部写入线程数，从而在这些线程之间分配写入操作。对于支持 | |
增加对外部函数发出的最大并行请求数，这需要更多的计算资源。 |
并行机制在运行时的工作原理
流处理器按以下顺序移动数据：
Source -> Buffer -> Transform -> Buffer -> Sink
对于Apache Kafka源， Atlas Stream Processing会为每个源分区启动一个使用者线程，因此处理器可以同时从多个分区读取数据。管道中间的转换阶段仍然在单个线程上运行，并进程缓冲的数据。
当 parallelism 值大于 1 的阶段收到批处理时，其并行线程或请求进程该批处理。然后，该批处理进入下一阶段。
文档分发和排序
当某个阶段的 parallelism 值大于 1 时， Atlas Stream Processing会按如下方式跨线程分发文档：
如果您不指定
partitionBy， Atlas Stream Processing会按循环顺序将文档分配给线程。如果您指定
partitionBy， Atlas Stream Processing会将具有相同partitionBy值的所有文档发送到同一线程，该线程会按顺序处理这些文档。
$merge 是一个例外：它使用 on 子句中的字段作为分区键。
累积并行度
每个流处理器都有一个由其层级确定的最大累积并行度值。流处理器的累积并行度计算如下：
parallelism total - parallelized stages
其中，parallelism total 是 $source、$lookup、$merge、$emit 和 $externalFunction 阶段中所有大于 1 的 parallelism 值的总和，parallelized stages 是 parallelism 值大于 1 的这些阶段的数量。
示例，如果您的 $source 阶段将 parallelism 值设置为 4，则 $lookup 阶段未设置 parallelism 值（因此默认为 1），并且 $merge 阶段将 parallelism 值为 2，则有两个 parallelized stages，流处理器的累积并行度计算为 (4 + 2) - 2。
如果流处理器超过其层级的最大累积并行度， Atlas Stream Processing会引发错误，并建议您实现预期并行度层级所需的最低处理器层级。您必须将处理器扩展到更高层级，或降低阶段的并行度值，才能解决该错误。要学习，了解更多信息，请参阅Stream Processing。
Kafka源分区
从Apache Kafka读取的处理器也会受到其层级的源分区限制的约束。 SP2层级将处理器限制为 32 个源分区，SP5层级将处理器限制为 64。 SP10层级及更高层级没有分区限制。
监控配置的并行度
要将配置的并行度与处理器层级可用的并行度进行比较，请使用处理器统计信息返回的 stats.addedParallelism字段。仅当至少一个阶段将 parallelism 值设置为大于 1 时， Atlas Stream Processing才会返回此字段。
工作负载选择
层级资源配置不同，适用于不同阶段和规模的项目。
层级 | 用例(Use Case) |
|---|---|
SP 2 | 开发、试用部署 成本最低的选项，能够以有限的资源支持基本工作负载。 |
SP 5 | 开发、基本生产部署 一种低成本选项，适用于低吞吐量的生产任务，甚至是那些采用更复杂计算的任务。SP5 处理器可以支持基本的过滤器、投影和 Stream Processing。 |
SP 10 | 主流生产部署 生产工作负载的基线。SP10 及更高版本适用于需要更高级别并行性、无限制的Kafka分区或查询和联接等数据扩充操作的管道。 |
SP 30 | 复杂的生产部署 专为内存密集型有状态操作而设计的高性能选项。 SP30 支持使用长时间窗口、多次查找和需要大型RAM缓冲区来进行扩展数据扩充的阶段的管道。 |
SP 50 | 企业级生产 性能最高的选项，专为高吞吐量流和广泛的转换逻辑而设计。SP50 处理器适用于需要大规模并行处理或计算密集型工作流程的操作。 |
Considerations
选择适当的层级时，请考虑以下因素：
初始化激增
流处理器在初始运行期间可能比常规操作期间需要更多的资源。示例，对大型Atlas集合执行 initialSync 的处理器需要在同步期间支持大量 I/O 和计算。
为了吸收如此高的需求，请暂时选择更高的层级，并在同步完成并且处理器转换为仅使用新的变更流事件时扩展处理器。
管道逻辑
聚合管道逻辑是 CPU 和RAM消耗的主节点 (primary node in the replica set)驱动程序。
- Windows：持久的 Windows 会消耗更多RAM来保存动态
- 文档。
- 自定义逻辑：Javascript
$function阶段或复杂分组 - 逻辑会增加每条消息的计算要求。
- 自定义逻辑：Javascript
- 复合复杂性：额外的状态或计算复杂性阶段
- 引入更多潜在的资源需求变化。即使在消费高峰期间，保持剩余容量也能确保一致的吞吐量。
基础架构
每个网络或存储联系点都会增加流处理器的开销。
- 源或接收器密度：读取或写入并行化
- 源或接收器（例如Apache Kafka主题）会增加 I/O 要求。
- 数据扩充：
$lookup和$https阶段；和操作 - 要丰富针对Atlas集合的数据流，需要网络带宽和连接池化。
- 数据扩充：
- 协调：在复杂的部署中协调多个源
- 和接收器，流处理器可以提供服务集线器，在每个节点之间路由数据流。此类处理器受益于 SP30 和 SP50 层的更高吞吐量。
相反，高吞吐量 Stream Processing 工作负载可能会增加对互联资源的需求。
- 对Atlas的影响：来自流的大容量并行 I/O
处理器可能会超过Atlas源集群或接收器集群的读取或写入容量。这不仅会增加处理器的延迟，还会成为依赖这些集群的其他工作负载的瓶颈。
为确保全系统性能，请根据与之交互的处理器按比例扩展Atlas集群。
性能和延迟
即使处理逻辑非常少，性能目标也可能需要更高层级的处理器。
- 高吞吐量：更高层级的处理器可以更好地支持流
- 以高速率生成事件。
低延迟 SLA：较高层级处理器提供的高并行性有助于确保在速度至关重要时事件不会在队列中累积。特别是，SP50 处理器提供的线程是 SP30 处理器的四倍。
- 数据丰富和缓存：使用
$cachedLookup来丰富 - 包含大量静态或缓慢变化的参考数据的流，有利于更高层级的处理器提供缓存所需的RAM 。
- 数据丰富和缓存：使用
- 复杂接收器：某些接收器涉及更昂贵的
- 转换、事务和文件管理开销。对于与这些接收器交互的处理器，更高的层有助于确保一致的性能和延迟。
扩展(Scaling)
Atlas Stream Processing扩展是垂直的。您可以手动扩展处理器，也可以启用自动扩展功能，让Atlas Stream Processing为您调整层级。
要手动扩展处理器，请将其停止，选择新的层级，然后重新启动。 Atlas Stream Processing检查点确保过渡期间不会丢失数据。定期监控处理器的性能，并根据本指南中描述的因素调整其层级。
要让Atlas Stream Processing根据资源使用情况自动调整层级，启用垂直自动伸缩。使用本指南中的因素来选择 minTier和maxTier ，限制处理器可扩展的范围。