azure - 使用 Azure 流分析 HoppingWindow 函数进行事件处理(每天 1700 万个事件) - 24 小时窗口，1 分钟跳跃

Question

我们有一个需要解决的业务问题，希望社区提供一些有关我们可以用来解决该问题的 Azure 产品组合的指导。

问题:

我在一家生产在线游戏的公司工作。我们希望显示 24 小时窗口内玩特定游戏的用户数量，但我们希望该值每分钟更新一次。本质上是 Azure 流分析中的 HoppingWindow(Duration(hour, 24), Hop(min, 1)) 函数将提供的输出。

目前，每天的事件量约为 1700 万个，流分析作业似乎正在努力应对负载。到目前为止，我们尝试了以下操作；

测试完成:

1700 万个事件 -> 事件中心(32 个分区) -> ASA(42 个流单元) -> 表存储

失败:流分析作业永远不会在较长的时间范围内输出(在 8 小时停止测试)

1700 万个事件 -> 事件中心(32 个分区) -> FUNC -> 表存储(具有适当的分区/行键)

失败:表存储不支持重复计数

1700 万个事件 -> 事件中心 -> FUNC -> Cosmos DB

暂定:Cosmos DB 本身不支持非重复计数。似乎存在一些黑客行为，但不确定这就是正确的方法。

是否有任何已知的设计适合每分钟处理 1700 万个事件？

编辑:根据评论，代码。

SELECT
    GameId,
    COUNT(DISTINCT UserId) AS ActiveCount,
    DateAdd(hour, -24, System.TimeStamp()) AS StartWindowUtc,
    System.TimeStamp() AS EndWindowUtc INTO [out]
FROM
    [in] TIMESTAMP BY EventEnqueuedUtcTime
GROUP BY
    HoppingWindow(Duration(hour, 24), Hop(minute, 1)),
    GameId,
    UserId

预期输出，请注意，实际上每个 GameId 将有 1440 条记录。每分钟一个

需要明确的是，问题在于在较大的时间范围内生成预期输出，即 24 小时不会输出或至少需要 8 小时以上才能输出。较小的窗口大小有效，例如将上面的代码更改为使用 HoppingWindow(Duration(min, 10), Hop(min, 5))。

随后的测试假设 ASA 不能解决问题，因此我们尝试了不同的方法。这似乎引起了一些困惑，对此表示抱歉

Answer 1

ASA之道scales up目前，垂直方向上有 1 个节点从 1 到 6SU，然后水平方向上有 6SU 的多个节点高于该阈值。

显然，为了能够水平扩展，作业需要可并行化，这意味着流将根据分区方案分布在节点上。

现在，如果输入流、查询和输出目标在分区中对齐，则该作业称为 embarrassingly parallel这就是您能够达到最大规模的地方。每个管道从入口到输出都是独立的，每个节点只需在内存中维护与自身状态相关的数据(那些 24 小时的数据)。 这就是我们在这里寻找的:最小化每个节点的本地数据存储。

由于 EH 在大多数 SKU 上支持 32 个分区，因此 ASA 上公开可用的最大规模为 192SU (6*32)。如果分区是平衡的，这意味着每个节点在其自己的状态存储中维护的数据量最少。

然后我们需要最小化有效负载本身(单个消息的大小)，但从查询的外观来看，情况已经如此。

您可以尝试扩展到 192SU 看看会发生什么吗？

我们还在开发多个其他功能，以帮助解决这种情况。如果您对此感兴趣，请告诉我。