Flink 在流处理中的广泛基准测试

Question

我在我的公司使用 Flink，我正在考虑应用几个场景来查看每个案例的性能。

以下是我将处理的场景

1. 实验
   • 端到端
   • Exactly-At-Once 或 At-least-once
   • 来源：卡夫卡
   • 接收器：Mysql 和 Redis
   • 逻辑：简单的计数逻辑

   对于 Exactly-At-Once，我将使用 TwoPhaseCommitSink 来实现该案例。 在做实验之前，我想知道以下一些问题。

   1. sink 的性能速度

      如您所见，我将使用 mysql (RDB) 作为接收器。当我们将 RDB 用于 at-least-once 或exactly-at-once 时，是否有任何描述性的基准测试结果？我认为当sink使用数据库时，吞吐量会受到影响，因为连接和与数据库通信需要一些时间。但是在使用 Sink for RDB 时，我找不到任何文档或技术博客显示 Flink 基准测试的详细结果。 特别是，我还想知道Exactly-at-once 会比at-least-once 性能下降更多，并且由于处理速度慢，很难用于商业目的。 所以我的问题如下。

      1. 使用数据库接收器（mysql 或 redis）的两种语义模式（至少一次，恰好一次）是否有任何信息性结果？

      2. 使用 mysql sink 时，端到端的 Exactly-at-once 语义会很慢吗？我将应用 twophasecommitsink。

         谢谢。

Answer 1

几个反应：

• 简单、通用的 Flink 基准测试作为特定应用程序性能的预测指标毫无用处。很大程度上取决于具体的工作在做什么，还有很大的优化空间。
• Exactly-at-once with two-phase commit sinks 在延迟方面代价高昂，但在吞吐量方面并没有那么糟糕。问题是提交必须与检查点一起完成。如果您需要频繁检查点以减少延迟，那么这将更严重地损害吞吐量。
• 未对齐的检查点和更改日志状态后端可能会对某些用例产生重大影响。如果您想在测试中包含这些内容，请务必使用 Flink 1.16，它在这些方面有了显着改进。