性能考虑

在准备在 Foundry 中创建流时，考虑定义流的延迟和吞吐量期望非常重要。本页面将介绍一些关于流应用案例的延迟和吞吐量性能需要考虑的问题。

延迟

延迟是流记录处理的速度。延迟是定义实时流的核心性能组件，记录通过流处理并到达目的地的速度预期可能会对现实世界产生影响。例如，流延迟决定了航空公司航班延误或需要立即采取操作的供应链问题的警报触发速度。影响延迟的因素是多方面的，但下面列出了一些最重要的考虑因素。

延迟因素

• 数据源生成数据的速度有多快？
  • Foundry 只能以数据生成的速度消费数据，因此应确保数据源能够快速生成数据。
• 数据跨越网络边界需要多长时间？
  • 将数据引入 Foundry 时，数据通常必须跨越网络边界，这可能会根据网络配置、防火墙和其他因素引入延迟。
• 您的端到端管道中有多少个阶段？
  • Foundry 流会将同一代码库或管道构建器图中定义的管道变换共同定位在相同的物理硬件上，以自动优化延迟。当管道中添加更多阶段时（例如，多个代码库或构建器管道串联在一起），我们将无法进行相同的优化，从而导致额外的延迟。
• 数据是否发送到外部系统？
  • 为了使记录以低延迟方式访问，目标系统必须能够以低延迟方式处理数据。Foundry 提供了优化的目的地，例如时间序列和 Ontology，但如果数据传输到外部系统，则该系统必须支持延迟要求。
• 您的数据一致性模型是什么？
  • 数据一致性在端到端延迟中起着重要作用。需要精确一次性保证的数据（例如，您的记录保证只会被处理一次）增加了管道的原子性开销和延迟。然而，如果您的管道可以以至少一次性保证运行（例如，每个记录保证至少被处理一次，但可能会被处理多次），系统将自动优化您的管道以使其运行更快。

流管道的端到端延迟

标准流管道可以在15秒内运行完以下阶段：

• 引入： ~1-2秒
• 变换： ~5秒（如果启用了精确一次，默认），或1秒（如果启用了至少一次）
• 同步到支持的数据存储（对象存储同步或时间序列同步）： ~5秒（如果启用了精确一次，默认），或1秒（如果启用了至少一次）

如上所述，有三个主要因素影响流管道的端到端延迟：

1. 基于变换数量的管道复杂性。
2. 基于管道是否以至少一次或精确一次模式运行的一致性模型。
3. 变换中的时间窗口和聚合。例如，如果您指定要在30秒窗口上进行聚合，则数据将隐式地增加30秒的聚合延迟。

吞吐量

吞吐量是指可以在一段时间内处理的记录数量。吞吐量通常与延迟一样重要，用于衡量低延迟管道的性能，下面列出了一些最重要的考虑因素：

• 您的源在每个时间间隔生成多少记录？
  • Foundry 的流功能开箱即具有高吞吐量水平。然而，如果您的源流以异常高的速率生成，您可以：
    • 增加流使用的分区数量以支持这些更高的容量。
    • 将现有流的流类型设置为“高吞吐量”。此配置会增加源在一个批次中发送的记录数量，如果您注意到流的“总滞后”指标大于0，建议使用此设置。请注意，此设置直接以延迟换取吞吐量。在继续之前，请检查流的“总吞吐量”指标以确认应用“高吞吐量”是否是流的正确选择。
• 管道的处理部分对 CPU 的需求有多高？
  • 吞吐量通常会受到处理延迟的限制。有许多方法可以增加处理中的吞吐量，其中大多数可以通过扩大处理集群的规模来解决。
• 目标系统接收记录的速度有多快？
  • 如果流目标系统无法以记录生成的速度接收记录，也会导致延迟。这可能会导致背压 ↗，从而降低吞吐量并增加延迟。Foundry 的流产品经过优化设计，可以应对极高的吞吐量。但是，如果您将流管道设置为写入自己的目标，您应确保目标能够跟上生成的记录量。

高级

• 对于对其数据管道有深入了解的用户，流性能的另一个潜在瓶颈是网络带宽。网络带宽不佳的症状包括非零滞后、低于预期的吞吐量和记录丢失。为了缓解这些症状，您可以对流应用数据压缩。然而，在这样做之前，请记住：
  • 数据压缩在具有重复字符串的高容量流上效果最佳。
  • 对于主要关注降低延迟的低容量流，启用数据压缩会由于以次优方式压缩数据所花费的时间而进一步增加延迟（例如，如果唯一字符串的数量较少）。