使用 Azure 流分析跳跃 Window 函数的事件处理（1700 万 Events/day）- 24 小时 Window，1 分钟跳跃
Event Processing (17 Million Events/day) using Azure Stream Analytics HoppingWindow Function - 24H Window, 1 Minute Hops
我们有一个业务问题需要解决，希望社区提供一些关于我们可以用来解决它的 Azure 产品组合的指导。
问题：
我在一家生产网络游戏的公司工作。我们想显示 24 小时内玩特定游戏的用户数量 Window，但我们希望该值每分钟更新一次。本质上是 Azure 流分析中的 HoppingWindow(Duration(hour, 24), Hop(minute, 1)) 函数将提供的输出。
目前，每天的事件量约为 1700 万，流分析作业似乎正在与负载作斗争。到目前为止，我们尝试了以下方法；
已完成的测试：
1700 万个事件 -> 事件中心（32 个分区）-> ASA（42 个流单元）-> Table 存储
失败： 流分析作业从不在大时间范围内输出（在 8 小时停止测试）
1700 万个事件 -> 事件中心（32 个分区）-> FUNC -> Table 存储（使用适当的 Partition/Row 密钥）
失败：Table存储不支持不同计数
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 小时以上才能输出。较小的 window 大小有效，例如将上面的代码更改为使用 HoppingWindow(Duration(minute, 10), Hop(minute, 5)).
随后的测试假设 ASA 不是问题的答案，我们尝试了不同的方法。这似乎引起了一些混乱，对此感到抱歉
目前 ASA scales up 的方式是从 1 到 6SU 垂直放置 1 个节点，然后水平放置 6SU 的多个节点高于该阈值。
显然，为了能够水平扩展作业需要可并行化，这意味着流将根据分区方案跨节点分布。
现在，如果输入流、查询和输出目标在分区中对齐，则作业称为 embarrassingly parallel，这就是您能够达到最大规模的地方。每个管道，从入口到输出，都是独立的，每个节点只需要在内存中维护与其自身状态相关的数据（那 24 小时的数据）。 这就是我们在这里寻找的：最小化每个节点的本地数据存储。
EH在大多数SKU上支持32个分区，ASA上公开的最大规模是192SU（6*32）。如果分区是平衡的，这意味着每个节点将在其自己的状态存储中维护最少的数据量。
然后我们需要最小化负载本身（单个消息的大小），但从查询的外观来看已经是这样了。
您能否尝试扩展到 192SU，看看会发生什么？
我们还在研究可能有助于解决该情况的多个其他功能。如果您对此感兴趣，请告诉我。
我们有一个业务问题需要解决，希望社区提供一些关于我们可以用来解决它的 Azure 产品组合的指导。
问题：
我在一家生产网络游戏的公司工作。我们想显示 24 小时内玩特定游戏的用户数量 Window，但我们希望该值每分钟更新一次。本质上是 Azure 流分析中的 HoppingWindow(Duration(hour, 24), Hop(minute, 1)) 函数将提供的输出。
目前，每天的事件量约为 1700 万，流分析作业似乎正在与负载作斗争。到目前为止，我们尝试了以下方法；
已完成的测试：
1700 万个事件 -> 事件中心（32 个分区）-> ASA（42 个流单元）-> Table 存储
失败： 流分析作业从不在大时间范围内输出（在 8 小时停止测试）
1700 万个事件 -> 事件中心（32 个分区）-> FUNC -> Table 存储（使用适当的 Partition/Row 密钥）
失败：Table存储不支持不同计数
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 小时以上才能输出。较小的 window 大小有效，例如将上面的代码更改为使用 HoppingWindow(Duration(minute, 10), Hop(minute, 5)).
随后的测试假设 ASA 不是问题的答案，我们尝试了不同的方法。这似乎引起了一些混乱，对此感到抱歉
目前 ASA scales up 的方式是从 1 到 6SU 垂直放置 1 个节点，然后水平放置 6SU 的多个节点高于该阈值。
显然，为了能够水平扩展作业需要可并行化，这意味着流将根据分区方案跨节点分布。
现在，如果输入流、查询和输出目标在分区中对齐，则作业称为 embarrassingly parallel，这就是您能够达到最大规模的地方。每个管道，从入口到输出，都是独立的，每个节点只需要在内存中维护与其自身状态相关的数据（那 24 小时的数据）。 这就是我们在这里寻找的：最小化每个节点的本地数据存储。
EH在大多数SKU上支持32个分区，ASA上公开的最大规模是192SU（6*32）。如果分区是平衡的，这意味着每个节点将在其自己的状态存储中维护最少的数据量。
然后我们需要最小化负载本身（单个消息的大小），但从查询的外观来看已经是这样了。
您能否尝试扩展到 192SU，看看会发生什么？
我们还在研究可能有助于解决该情况的多个其他功能。如果您对此感兴趣，请告诉我。