Stream Analytics作业需要几分钟才能将结果输出到Event Hub。
Stateless Web API Azure Service Fabric应用程序分布在 8 节点上。该应用程序非常简单，由一个Controller组成，其中包含：
JSON个对象JSON对象PartitionKey属性设置为machine-name值JSON个对象作为一批EventData个实例发布到Azure Event Hub JSON有效负载是一系列简单的IP addresses和time-stamps，如下所示：
[{
"IPAddress": "10.0.0.2",
"Time": "2016-08-17T12:00:01",
"MachineName": "MACHINE01"
}, {
"IPAddress": "10.0.0.3",
"Time": "2016-08-17T12:00:02",
"MachineName": "MACHINE01"
}]
收到Event Hub后，Stream Analytics作为Query作业的输入，执行以下SELECT
IPAddress, COUNT(*) AS Total, MachineName
INTO
Output
FROM
Input TIMESTAMP BY TIME
PARTITION BY PartitionId
GROUP BY
TUMBLINGWINDOW(MINUTE, 1), IPAddress, MachineName, PartitionId
HAVING Total >= 2
：
Query请注意，PartitionId由PartitionId分区，其中machine-name设置为原始Service Fabric应用的PartitionKeys。因此，最多 8 Service Fabric
8 个别Partitions个实例， 8 对应Event Hub分配给输入Stream Analytics。
最后，Event Hub作业将结果输出到第二个Event Hub。同样，此Stream Analytics有 8 分区。 Query machine-name保留PartitionKey，Event Hub用作输出JSON的{{1}}。输出格式为Event Hub。
对于单个HTTP请求到达输出Stream Analytics，此过程充其量只需 30-60 秒，有时几分钟。鉴于ASP.NET应用程序以亚秒时间尺度发布EventData批次，瓶颈似乎是Timestamp By工作。
修改
将自定义字段应用于Group By会在加上Timestamp By子句时增加很大程度的延迟。删除Query子句后，我已达到可接受的延迟（ 1-2秒）。
最佳SELECT
Count(*) AS Total, IPAddress
FROM
Input
Partition by PartitionId
GROUP BY TUMBLINGWINDOW(MINUTE, 1), IPAddress, PartitionId
如下：
Having但是，添加SELECT
Count(*) AS Total, IPAddress
FROM
Input
Partition by PartitionId
GROUP BY TUMBLINGWINDOW(MINUTE, 1), IPAddress, PartitionId
HAVING Total >= 10
子句会导致延迟增加到 10-20 秒：
Query如果无法及时使用Having条款在Streaming Units内聚合数据，那么似乎无法实现目的。
顺便提一下，Partitions，Input，Output和Stream Analytics按照this guide to achieving parallelism {{1}}进行了最佳配置。