流分析：如何启动和停止 TUMBLINGWINDOW 聚合作业以降低成本，同时仍然获得相同的聚合结果？
Stream Analytics: How can I start and stop a TUMBLINGWINDOW aggregation job inorder to reduce costs while still getting the same aggregation results?
上下文
我使用 Azure 门户创建了一个流式处理作业，该门户使用按天计算的 TUMBLINGWINDOW 聚合数据。在下面附上了一段代码片段，修改自 docs，它显示了类似的逻辑。
SELECT
DATEADD(day, -1, System.Timestamp()) AS WindowStart
System.Timestamp() AS WindowEnd,
TollId,
COUNT(*)
FROM Input TIMESTAMP BY EntryTime
GROUP BY TumblingWindow(day, 1), TollId
现在作业已经 运行 宁并且可以看到它产生输出我希望能够通过设置某种时间安排来理想地降低成本，以便作业可以 运行并且仍然产生相同的输出而无需一直打开。
唯一真正的限制是每个 TUMBLINGWINDOW 结束时的聚合输出必须保持不变，就像它一直 运行ning 一样（停止启动对输出没有影响）。
这就引出了我的问题。
Update: 2021-02-28
Before going into the question another thing that drove me was that through Azure portal you can manually start and stop a job. When you start/restart a job you can set a custom start time for the job/query. With this level of control say I start a job (or have a job running) and then decide to stop it for majority of the day and then turn it on at say 11:30pm each day with a custom start time of midnight of the current day then it would be able to be on for approx 30min before it would output the results (yet still to my understanding produce the same aggregation results/effect compared to if it was on the whole day up until that point). This job could then be paused again at 00:30am ( the next day for which it stays paused for the majority of the day (1380min total until 11:30pm again) upon which the same above logic is applied.
This way it remains off the majority of the day yet still can produce the same output for each day wise window (correct me if I am wrong in my thinking). The only issue with this to me seems to be the fact someone would have to manually perform this. Thus I was driven to the docs looking for a way to automate this.
问题
我如何以自动化方式启动和停止作业，以便所需的输出仍然保持不变，但作业不必一直保持（就像现在一样）？
上面链接的文档是否满足上面的上下文，如果是的话，N 分钟（打开）和 M 分钟（关闭）时间变量的一些可能安排是什么？
考虑到我想在一天 TUMBLINGWINDOW window 中聚合的场景，这是否可能（因此我希望每个 window 按照其默认值在每天的午夜开始和结束行为。)?
例如
Window 开始：2022-02-20 00:00:00 Window 结束：2022-02-21 00:00:00（执行聚合），
Window 开始：2022-02-21 00:00:00 Window 结束：2022-02-22 00:00:00（执行聚合），
Window 开始：2022-02-22 00:00:00 Window 结束：2022-02-23 00:00:00（执行聚合），
..等等
想法
我从 Microsoft 找到了关于 auto-pausing jobs using a few methods
的文档
但是遇到了一段（在下面引用），这让我怀疑它在我的特定用例中是否合理（如我的问题部分所述，翻滚 1 天 window）。
Note
There are downsides to auto-pausing a job. The main ones being the loss of the low latency /real time capabilities, and the potential risks from allowing the input event backlog to grow unsupervised while a job is paused. Auto-pausing should not be considered for most production scenarios running at scale.
这个方法可以吗
有 3 种方法可以降低成本：
- 缩减你的工作，你会有更高的延迟但成本更低，直到你的工作崩溃的程度，因为它 运行 随着时间的推移内存不足 and/or 无法捕捉处理积压的工作。在这里，您需要密切关注您的指标，以确保您可以在为时已晚之前做出反应
- 更进一步，您可以将多个查询重新组合到一个作业中。这项工作很可能不会在分区中对齐，因此它无法线性扩展（添加 SU 不能保证为您提供更好的性能）。与上面的评论相同，另外您需要记住，当您需要向上扩展时，您可能必须将该作业分解为多个作业才能再次以线性方式扩展
- 你终于可以 auto-pause 一份工作了，在你链接的 doc 中解释了一种实现方法。我写了那个文档，我所说的评论的意思是，如果它不能 运行 足够长的时间来处理积压的事件，那么你再次冒着使工作过载的风险。对于大多数生产场景来说，这是一个冒险的提议
但是，如果您知道自己在做什么，并且正在密切监视适当的指标（如文档中所述），那么这绝对是您应该探索的内容。
最后，所有这些方法，包括 auto-pause 方法，都将为您透明地处理翻滚 windows。
更新：2022-03-03 在此处关注评论
更新：2022-03-04 关注评论there
这里有3个时间维度：
- 工作运行宁与否：挂钟
- 当时间window预计每天输出结果：
Tumbling(day,1) -> 00:00AM，这是绝对的（日、时、分。 ..) 并且与下面的工作开始时间无关
- 您希望通过 job start time
从作业中产生什么输出
假设您的工作 运行 连续数月全天候 24 小时工作，并决定在 3 月 1 日中午（中午 12:00）停止工作。
它已经在 2 月的最后一天生成输出，即 00:00AM 3 月 1 日。
直到第二天 00:00AM Mar2，您才会看到输出差异，当您希望看到 Mar1 的每日 window 时，但它没有输出，因为作业已停止.
让我们在 01:00AM Mar2 挂钟时间开始作业。如果您想要缺少的时间 window，您应该选择 'when last stopped'（前一天中午）的开始时间，或者选择 23:59PM 3 月 1 日之前的任何时间的自定义时间。你驱动的是你想要的输出window。在这里你告诉 ASA 你想要从那一点开始的所有 windows。
ASA 然后将 reload all the data it needs 生成那个 window（确保事件中心有足够的保留，我们不会在作业的重新启动之间缓存数据）：Azure Stream Analytics 将自动回头查看输入源中的数据。例如，如果您“现在”开始一项工作，并且如果您的查询使用 5 分钟的 Tumbling Window，Azure 流分析将在输入中查找 5 分钟前的数据。第一个可能的输出事件将具有等于或大于当前时间的时间戳，并且 ASA 保证所有在逻辑上对输出有贡献的输入事件都已被考虑。
上下文
我使用 Azure 门户创建了一个流式处理作业，该门户使用按天计算的 TUMBLINGWINDOW 聚合数据。在下面附上了一段代码片段，修改自 docs，它显示了类似的逻辑。
SELECT
DATEADD(day, -1, System.Timestamp()) AS WindowStart
System.Timestamp() AS WindowEnd,
TollId,
COUNT(*)
FROM Input TIMESTAMP BY EntryTime
GROUP BY TumblingWindow(day, 1), TollId
现在作业已经 运行 宁并且可以看到它产生输出我希望能够通过设置某种时间安排来理想地降低成本，以便作业可以 运行并且仍然产生相同的输出而无需一直打开。
唯一真正的限制是每个 TUMBLINGWINDOW 结束时的聚合输出必须保持不变，就像它一直 运行ning 一样（停止启动对输出没有影响）。
这就引出了我的问题。
Update: 2021-02-28
Before going into the question another thing that drove me was that through Azure portal you can manually start and stop a job. When you start/restart a job you can set a custom start time for the job/query. With this level of control say I start a job (or have a job running) and then decide to stop it for majority of the day and then turn it on at say
11:30pmeach day with a custom start time of midnight of the current day then it would be able to be on for approx30minbefore it would output the results (yet still to my understanding produce the same aggregation results/effect compared to if it was on the whole day up until that point). This job could then be paused again at00:30am( the next day for which it stays paused for the majority of the day (1380mintotal until11:30pmagain) upon which the same above logic is applied. This way it remains off the majority of the day yet still can produce the same output for each day wise window (correct me if I am wrong in my thinking). The only issue with this to me seems to be the fact someone would have to manually perform this. Thus I was driven to the docs looking for a way to automate this.
问题
我如何以自动化方式启动和停止作业，以便所需的输出仍然保持不变，但作业不必一直保持（就像现在一样）？
上面链接的文档是否满足上面的上下文，如果是的话，N 分钟（打开）和 M 分钟（关闭）时间变量的一些可能安排是什么？
考虑到我想在一天 TUMBLINGWINDOW window 中聚合的场景，这是否可能（因此我希望每个 window 按照其默认值在每天的午夜开始和结束行为。)?
例如
Window 开始：2022-02-20 00:00:00 Window 结束：2022-02-21 00:00:00（执行聚合），
Window 开始：2022-02-21 00:00:00 Window 结束：2022-02-22 00:00:00（执行聚合），
Window 开始：2022-02-22 00:00:00 Window 结束：2022-02-23 00:00:00（执行聚合），
..等等
想法
我从 Microsoft 找到了关于 auto-pausing jobs using a few methods
的文档但是遇到了一段（在下面引用），这让我怀疑它在我的特定用例中是否合理（如我的问题部分所述，翻滚 1 天 window）。
Note
There are downsides to auto-pausing a job. The main ones being the loss of the low latency /real time capabilities, and the potential risks from allowing the input event backlog to grow unsupervised while a job is paused. Auto-pausing should not be considered for most production scenarios running at scale.
这个方法可以吗
有 3 种方法可以降低成本：
- 缩减你的工作，你会有更高的延迟但成本更低，直到你的工作崩溃的程度，因为它 运行 随着时间的推移内存不足 and/or 无法捕捉处理积压的工作。在这里，您需要密切关注您的指标，以确保您可以在为时已晚之前做出反应
- 更进一步，您可以将多个查询重新组合到一个作业中。这项工作很可能不会在分区中对齐，因此它无法线性扩展（添加 SU 不能保证为您提供更好的性能）。与上面的评论相同，另外您需要记住，当您需要向上扩展时，您可能必须将该作业分解为多个作业才能再次以线性方式扩展
- 你终于可以 auto-pause 一份工作了，在你链接的 doc 中解释了一种实现方法。我写了那个文档，我所说的评论的意思是，如果它不能 运行 足够长的时间来处理积压的事件，那么你再次冒着使工作过载的风险。对于大多数生产场景来说，这是一个冒险的提议
但是，如果您知道自己在做什么，并且正在密切监视适当的指标（如文档中所述），那么这绝对是您应该探索的内容。
最后，所有这些方法，包括 auto-pause 方法，都将为您透明地处理翻滚 windows。
更新：2022-03-03 在此处关注评论
更新：2022-03-04 关注评论there
这里有3个时间维度：
- 工作运行宁与否：挂钟
- 当时间window预计每天输出结果：
Tumbling(day,1)-> 00:00AM，这是绝对的（日、时、分。 ..) 并且与下面的工作开始时间无关 - 您希望通过 job start time 从作业中产生什么输出
假设您的工作 运行 连续数月全天候 24 小时工作，并决定在 3 月 1 日中午（中午 12:00）停止工作。
它已经在 2 月的最后一天生成输出，即 00:00AM 3 月 1 日。
直到第二天 00:00AM Mar2，您才会看到输出差异，当您希望看到 Mar1 的每日 window 时，但它没有输出，因为作业已停止.
让我们在 01:00AM Mar2 挂钟时间开始作业。如果您想要缺少的时间 window，您应该选择 'when last stopped'（前一天中午）的开始时间，或者选择 23:59PM 3 月 1 日之前的任何时间的自定义时间。你驱动的是你想要的输出window。在这里你告诉 ASA 你想要从那一点开始的所有 windows。
ASA 然后将 reload all the data it needs 生成那个 window（确保事件中心有足够的保留，我们不会在作业的重新启动之间缓存数据）：Azure Stream Analytics 将自动回头查看输入源中的数据。例如，如果您“现在”开始一项工作，并且如果您的查询使用 5 分钟的 Tumbling Window，Azure 流分析将在输入中查找 5 分钟前的数据。第一个可能的输出事件将具有等于或大于当前时间的时间戳，并且 ASA 保证所有在逻辑上对输出有贡献的输入事件都已被考虑。