0

这是我的流分析拓扑

EventHubSource => Job A (HoppingWindow every second) => EventHubA
EventHubSource => Job B (HoppingWindow every second) => EventHubB
  • 每个作业在 EventHubSource 中都有不同的使用者组。
  • 每个作业都尴尬地并行，只消耗 14% 的 SU 资源。

在测试 JobA 和 JobC 时，windowEnd 和原始 Event Time 之间的差异只有几毫秒（~300），这是可以的（我的生产者的延迟 + eventthub + 流分析处理时间）。

但是当我像这样在一个新的 Job C 中加入两个流时：

EventHubA 
          \
            => Job C (Join Datediff = 0 and timestamp by windowEnd)
          /
EventHubB

这会产生一些输出，但问题就在这里：

真实事件即使被 Job A 和 B 同时推送，也相隔数分钟（相同的 windowEnd）

当我检查来自 EventHub A 和 B 的数据时，windowEnd 和真实事件时间戳之间的差异在 39 到 44 分钟之间，对于所有这些。但是当像上面提到的那样进行测试时，它只有 300 毫秒。

这里最糟糕的是，当我在 prod 中运行它时，它只会发出几十个事件并停止，即使输入计数仍然是数千。

我已经为此工作了几周，每次我处理来自 ASA 的一些神秘行为时，我的拓扑非常简单，我只使用 1s 跳跃的简单跳跃窗口，这不应该需要几周的调整和试验错误甚至不了解发生了什么。

对于使用 ASA 和 AWS Kinesis 分析的人，您是否发现 Kinesis 分析更易于使用？在 ASA 中让我烦恼的是不可预测的行为和没有错误消息的问题（我激活了日志分析并且没有错误存在......）

4

1 回答 1

1

得知您在使用 ASA 时遇到了一些问题，我们深感抱歉。我看到你有一个 1 秒的跳跃窗口，但是窗口的总大小是多少，你的近似吞吐量是多少？

关于延迟：看是你的问题，我认为你的 ASA 作业可能没有足够的 CPU 资源，然后事件处理被延迟。不幸的是，这在当前的 SU% 指标中不可见，但我们计划在未来显示 CPU 和内存的指标。要确认这是根本原因，您可以检查作业图中积压事件的数量。如果有很多事件积压，您可能需要增加此作业的 SU 数量。

您还提到在十几个输出后作业停止，您是否在日志中看到错误消息？

于 2018-05-30T20:32:46.033 回答