Azure Stream 分析處理事件的時間太長

Question

我正在嘗試配置 Azure Stream 分析作業，但性能一直很差。 我從將數據推送到事件中心的客戶端系統接收到數據。 ASA 將其查詢到 Azure SQL 數據庫中。

幾天前，我注意到它生成了大量的 InputEventLateBeyondThreshold 錯誤。 這是 ASA 的示例。 Timestamp 元素由客戶端系統設置。

{
    "Tag": "MANG_POWER_5",
    "Value": 1.08411181,
    "ValueType": "Analogue",
    "Timestamp": "2022-02-01T09:00:00.0000000Z",
    "EventProcessedUtcTime": "2022-02-01T09:36:05.1482308Z",
    "PartitionId": 0,
    "EventEnqueuedUtcTime": "2022-02-01T09:00:00.8980000Z"
}

您可以看到事件很快到達，但處理時間超過 30 分鍾。 為了盡量避免 InputEventLateBeyondThreshold 錯誤，我增加了延遲事件閾值。 這可能會導致處理時間增加，但它太低也會增加 InputEventLateBeyondThreshold 錯誤的數量。

水印延遲一直很高，但 SU 使用率約為 5%。 對於此查詢，我已將 SU 增加到盡可能高的水平。

我試圖弄清楚，為什么一旦事件到達就需要這么長時間來處理它們。

這是我正在使用的查詢：

WITH PIDataSet AS (SELECT * FROM [<event-hub>] TIMESTAMP BY timestamp)

--Write data to SQL joining with a lookup
SELECT   
    i.Timestamp as timestamp,
    i.Value as value,
INTO [<sql-database>]
FROM PIDataSet as i
INNER JOIN [tagmapping-ref-alias] tm ON tm.sourcename = i.Tag

----Write data to AzureTable joining with a lookup
SELECT
    DATEDIFF(second,CAST('1970-01-01' as DateTime), I1.Timestamp) As Rowkey,
    I2.TagId as PartitionKey,
    I1.Value as Value,
    UDF.formatTime(I1.Timestamp) as DeviceTimeStamp
    into [<azure-table>]
FROM PIDataSet as I1
    JOIN [tagmapping-ref-alias] as I2 on I2.Sourcename = I1.Tag

--Get an hourly count into a SQL Table.
SELECT
    I2.TagId,
    System.Timestamp() as WindowEndTime, COUNT(I2.TagId) AS InputCount
    into [tagmeta-ref-alias]
FROM PIDataSet as I1
    JOIN [tagmapping-ref-alias] as I2 on I2.Sourcename = I1.Tag
    GROUP BY I2.TagId, TumblingWindow(Duration(hour, 1))

Answer 1

當您設置 59 分鍾的無序 window時，您所做的就是為該輸入設置一個 59 分鍾的緩沖區。 當記錄落入該緩沖區時，它們將等待 59 分鍾，直到它們出來。 您得到的交換是，我們有機會重新排列這些事件，以便它們按順序查找工作。

在 1 小時使用它是一種極端設置，根據定義，它會自動為您提供 59 分鍾的水印。 這非常令人驚訝，我想知道為什么您需要這么高的價值。

編輯

現在看遲到政策。

您正在使用事件時間 ( TIMESTAMP BY timestamp )，這意味着您的事件現在可能會延遲，請參閱此文檔和此文檔。

這意味着當記錄晚於 1 小時（因此時間戳比我們服務器上的掛鍾早 1 小時 - 在 UTC 中）時，我們將其時間戳調整為我們的掛鍾減 1 小時，並將其發送到查詢。 這也意味着您的翻滾 window 總是必須再等一個小時才能確保它不會丟失那些遲到的記錄。

這里我要做的是恢復默認設置（無亂序、5 秒延遲事件、調整事件）。 然后，當您獲得InputEventLateBeyondThreshold時，這意味着該作業收到的timestamp過去晚於 5 秒。 您不會丟失數據，我們正在將其system.timestamp為更新的值（但不是時間戳字段，我們不會更改它）。

那么我們需要了解的是為什么你的pipeline中一條記錄到go從生產到消費需要5秒以上的時間。 是因為你的攝取管道有很大的延遲，還是因為你的生產者時鍾有時間偏差？ 你知道嗎？