使用 Azure 流分析 HoppingWindow 函数的事件处理1700 万个事件/天 - 24 小时窗口，1 分钟跃点

如何解决使用 Azure 流分析 HoppingWindow 函数的事件处理1700 万个事件/天 - 24 小时窗口，1 分钟跃点

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

问题：

我在一家制作在线游戏的公司工作。我们希望在 24 小时窗口中显示玩特定游戏的用户数量，但我们希望该值每分钟更新一次。本质上是 Azure 流分析中的 HoppingWindow(Duration(hour,24),Hop(minute,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,1)),GameId,UserId

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

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

随后的测试假设 ASA 不是问题的答案，我们尝试了不同的方法。这似乎引起了一些混乱，抱歉

解决方法

目前 ASA scales up 的方式是从 1 到 6SU 垂直使用 1 个节点，然后在该阈值之上水平使用 6SU 的多个节点。

显然，要能够横向扩展，作业需要可并行化，这意味着流将根据分区方案分布在节点之间。

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

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

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

您能否尝试扩展到 192SU，看看会发生什么？

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