Azure Stream Analytics 中的時間處理是一組機制，決定串流事件如何根據發生時間與抵達時間來排序和處理。 本文說明如何做出設計選擇，以解決 Azure Stream Analytics 工作中實際時間管理的問題。 時間處理設計決策與事件順序因素有密切的關聯。
背景時間概念
為了建構討論基礎，我們將定義一些背景概念：
事件時間：原始事件發生的時間點。 例如，當行駛於高速公路的車輛接近收費站時。
處理時間：事件到達處理系統且被發現的時間。 例如，當收費站感應器發現車輛，且電腦系統花一些時間處理資料時。
浮水印：一個事件時間標記，顯示串流處理器已接收事件的時間點。 浮水印可讓系統明確顯示事件擷取進度。 依據串流的特質，內送事件資料永遠不會停止，因此浮水印可指出串流中某個時間點的進度。
浮水印是重要的概念。 浮水印讓 Azure Stream Analytics 能判斷系統何時能產出完整、正確且可重複的結果，且無需撤回。 此處理可透過可預測且可重複的方式完成。 例如，若因某些錯誤處理情況而需要重新計數，浮水印將是安全的起始點和結束點。
如需此主題的相關資源，請參閱 Tyler Akidau 的部落格文章串流 101 \(英文\) 和串流 102 \(英文\)。
選擇最理想的開始時間
Azure Stream Analytics 提供兩個選擇事件時間的選項：抵達時間和申請時間。
抵達時間
事件到達來源時，系統會為輸入來源指派抵達時間。 您可以針對事件中樞輸入使用 EventEnqueuedUtcTime 屬性、針對 IoT 中樞輸入使用 IoTHub.EnqueuedTime 屬性，以及針對 Blob 輸入使用 BlobProperties.LastModified 屬性來存取抵達時間。
系統預設會使用抵達時間，且其最適合用於不需要時態性邏輯的資料封存案例。
應用時間 (也稱為事件時間)
產生事件時會指派應用時間，且會成為事件承載的一部分。 若要按照應用時間處理事件，請在 SELECT 查詢中使用 Timestamp by 子句。 如果 Timestamp by 不存在，將按照抵達時間處理事件。
請務必在涉及時態性邏輯的情況下於承載中使用時間戳記，以將來源系統或網路中的延遲納入考量。 指派給事件的時間會在 SYSTEM.TIMESTAMP \(英文\) 中提供。
Azure 串流分析中的時間行進方式
當您使用應用程式時間時，時間推進會以傳入事件為基礎。 串流處理系統難以確定是否有事件，或事件是否延遲。 因此，針對每個輸入分割區，Azure 串流分析會透過下列方式產生啟發式浮水印：
只要有任何傳入事件，浮水印就是 Azure 串流分析目前所見最大事件時間，減去亂序容錯時間範圍大小後的值。
當沒有輸入事件時，時間戳為當前預估抵達時間減去延遲容忍窗口。 預估抵達時間是系統上次看到輸入事件的時間之後所經過的時間，加上該輸入事件的抵達時間。
抵達時間只能被估計，因為實際抵達時間是在輸入事件代理（如事件中心或物聯網中心）產生，而非在處理事件的 Azure Stream Analytics 虛擬機上產生。
除了產生浮水印以外，此設計還能提供兩個額外的用途：
無論是否有內送事件，系統都會及時產生結果。
您可以控制顯示輸出結果的及時程度。 在 Azure 入口網站中，您可以在串流分析作業的 [事件順序] 頁面上設定 [順序不正確的事件] 設定。 當您配置該設置時，請考量時效性與容忍事件流中無序事件之間的取捨。
即使沒有傳入事件，晚到容錯時間範圍仍是持續產生浮水印的必要條件。 有時候可能會有一段時間內沒有輸入事件，例如當事件輸入流非常稀疏時。 如果在輸入事件訊息代理程式中使用了多個分割區，這個問題會更嚴重。
當輸入稀疏且使用多個分割區時，沒有延遲抵達容錯視窗的串流數據處理系統可能會遭受延遲輸出。
系統行為必須是可重複的。 可重複性是串流資料處理系統的重要屬性。
浮水印衍生自抵達時間和應用時間。 這兩者都會保存在事件訊息代理程式中，因此可重複使用。 當在沒有事件的情況下估算到達時間時，Azure 串流分析會記錄估算的到達時間，以便在重新播放進行失敗復原時保持可重複性。
當你選擇以 到達時間 作為事件時間時，就不需要設定亂序容差和延遲到達容差。 由於輸入事件代理的 到達時間 必然會增加，Azure Stream Analytics 忽略了這些設定。
延遲抵達事件
根據延遲抵達容錯時間範圍的定義，針對每個內送事件，Azure 串流分析會將事件時間與抵達時間比較。 如果事件時間超出容差範圍，你可以設定系統丟棄事件或調整事件時間使其在容差範圍內。
在浮水印產生後，服務有可能收到事件時間低於浮水印的事件。 您可以將服務設定成會卸除那些事件，或將事件的時間調整為浮水印值。
在調整期間，事件的 System.Timestamp 會設定為新的值，但 事件時間 欄位本身不會變更。 這項調整是唯一會使事件的 System.Timestamp 與事件時間欄位中的值不同，且可能導致生成非預期結果的情況。
使用子資料流處理時間變異
啟發式浮水印產生機制——Azure Stream Analytics 利用最大觀察時間戳記減去容差視窗來追蹤事件時間進度——在大多數情況下運作良好，因為時間大部分時間在不同事件發送者間同步。 但在實際情況下，尤其是許多 IoT 案例中，系統幾乎無法控制事件傳送端的時鐘。 事件傳送者可能是現場的各種物聯網設備，並且可能使用不同版本的設備硬體和韌體。
與其使用一個適用於輸入分割中所有事件的全域浮水印，Azure Stream Analytics 有另一種機制稱為 子串流（substreams)。 你可以在工作中使用子流，方法是寫一個使用 TIMESTAMP BY 子句和關鍵字 OVER 的工作查詢。 若要指定子資料流，請在 OVER 關鍵字後面提供索引鍵資料行名稱 (例如 deviceid)，使系統依據該資料行套用時間原則。 每個子串流都會取得其獨立的水印。 在處理事件傳送端之間的時鐘誤差較大或網路延遲的問題時，此機制將有助於及時的輸出產生。
當你使用子串流時，Azure Stream Analytics 會套用延遲到達容忍度視窗來處理進來事件。 延遲抵達容忍度決定了不同子串流相互分離的最大範圍。 例如，若裝置 1 位於時間戳 1，裝置 2 位於時間戳 2，則最大延遲到達容忍度為時間戳 2 減去時間戳 1。 預設的遲到容忍度設定為 5 秒，對於時間戳分差的物聯網裝置來說，這可能太小。 從5分鐘開始，根據你裝置的時鐘偏斜模式調整。
提早到達的事件
提前到達時間窗口是一個固定的 5 分鐘容差，用於決定事件相對於其事件時間可以提前多長時間到達，否則 Azure Stream Analytics 會刪除該事件。 此窗口與晚到容忍窗口有不同的用途。
由於 Azure 串流分析保證完整結果，因此您只能將作業開始時間指定為作業的第一個輸出時間，而非輸入時間。 工作開始時間是為了讓系統處理整個視窗，而非僅從視窗中間開始。
Azure Stream Analytics 是根據查詢規格推導起始時間。 不過，由於輸入事件的訊息代理程式僅會依據抵達時間編製索引，因此系統必須將開始事件時間轉譯為抵達時間。 系統可以從輸入事件訊息代理程式中的那個時間點開始處理事件。 在有提早抵達時間範圍限制的情況下，轉譯會很簡單：開始事件時間減去 5 分鐘的提早抵達時間範圍。 此計算同時表示，系統會捨棄所有被視為事件時間比到達時間早 5 分鐘的事件。 早期輸入事件度量在事件被丟棄時會遞增。
這個概念確保無論你從哪裡開始輸出，處理過程都能重複進行。 如果沒有這種機制，就不可能保證可重複性，因為許多其他串流系統都聲稱它們這樣做。
事件順序時間容錯的副作用
Azure Stream Analytics 的職缺有多種 事件排序 選項。 其中有兩個可在 Azure 入口網站中設定：「順序錯亂事件」設定 (順序錯亂容錯)，和「延遲抵達的事件」設定 (延遲抵達容錯)。 提前到達容錯限制是固定的，無法調整。 Azure Stream Analytics 利用這些時間政策提供強而有力的保障。 不過，這些設定有時候會一些非預期的影響：
意外傳送過早的事件。
早期事件通常不應該被輸出。 如果發送端時鐘跑得太快，早期事件可能會被送到輸出端。 所有提早抵達的事件都會遭到捨棄，因此您不會從輸出中看到任何事件。
將舊事件傳送至事件中樞給 Azure 串流分析處理。
雖然舊事件起初看似無害，但由於延遲容忍的應用，舊事件可能會被丟棄。 如果事件太舊，在事件擷取期間將會更改 System.Timestamp 值。 基於此特性，Azure Stream Analytics 更適合近即時事件處理情境，而非歷史事件處理情境。 在某些情況下，您可以將「延遲抵達的事件」時間設為最大可能值 (20 天)，以因應此問題。
輸出似乎有延遲的現象。
第一個浮水印會在計算出的時間產生：也就是系統目前觀察到的最大事件時間，減去亂序容錯時間範圍大小。 根據預設，順序錯亂容錯會設定為零 (00 分 00 秒)。 當您將它設為較高的非零時間值時，串流工作第一次輸出會因計算出的第一個浮水印時間而延遲該時間值 (或更久)。
輸入是稀疏的。
當指定分區中沒有輸入時，水印時間被計算為 抵達時間 減去延遲抵達容忍窗口。 因此，如果輸入事件不頻繁且疏鬆，輸出可能會延遲達該時間量。 「延遲抵達的事件」的預設值為 5 秒。 舉例來說，在逐一傳送輸入事件時，您應該會發現某種程度的延遲。 如果您將「延遲抵達的事件」時間範圍設為較大的值，延遲可能會更嚴重。
System.Timestamp 值與 [事件時間] 欄位中的時間不同。
如前所述，系統就會依據順序錯亂容錯或延遲抵達容錯時間範圍來調整事件時間。 事件的 System.Timestamp 值有調整，但 事件時間 欄位沒有被調整。 你可以用這個來辨識哪些事件的時間戳被調整過。 如果系統因為其中一個公差改變了時間戳，通常時間戳是一樣的。
可觀察的計量
您可透過 Azure 串流分析作業計量來觀察許多事件排序時間容錯效果。 相關計量如下：
| 計量 | 描述 |
|---|---|
| 順序錯亂事件 | 指出收到的亂序事件數，其中這些事件不是遭到捨棄，就是被指派了調整後的時間戳記。 此計量會直接受到 Azure 入口網站中，工作之事件排序頁面上亂序事件設定組態的影響。 |
| 延遲輸入事件 | 指出從來源延遲抵達的事件數目。 此指標包含被刪除或時間戳調整的事件。 此計量會直接受到 Azure 入口網站中，工作之事件排序頁面上事件晚到設定組態的影響。 |
| 早期輸入事件 | 指出從來源提早到達的事件數，其中這些事件不是遭到捨棄，就是在早於 5 分鐘以上時被調整了時間戳記。 |
| 浮水印延遲 | 指出串流資料處理作業的延遲。 如需詳細資訊，請參閱下列章節。 |
水印延遲詳細資料
Azure Stream Analytics 會將 浮水印延遲 指標計算為處理節點的壁時鐘時間減去迄今為止最大浮水印。 欲了解更多資訊，請參閱 浮水印延遲。
在正常作業下，此計量的值大於 0 的可能原因包括：
串流管線既有的處理延遲。 此延遲通常是額定的。
亂序容錯時間範圍會引入延遲，因為浮水印會因容錯時間範圍大小而降低。
晚到容錯時間範圍會引入延遲，因為浮水印會因容錯時間範圍大小而降低。
產生計量的處理節點有時鐘誤差。
還有其他資源限制可能導致串流管線變慢。 浮水印延遲指標可能因下列狀況而上升：
Azure Stream Analytics 的處理資源不足以處理大量輸入事件。 若要擴大資源，請參閱了解和調整串流單位。
輸入事件代理程式的吞吐量不足，因此受到限制。 如需可能的解決方案，請參閱自動擴大 Azure 事件中樞輸送量單位。
輸出接收器（例如 Azure SQL Database、Blob Storage 或 Power BI）未配置足夠的容量，因此會被限速。 可能的解決方案會因所使用的輸出服務而有很大差異。
輸出事件頻率
Azure 串流分析以浮水印進度作為唯一的觸發機制來產生輸出事件。 由於浮水印是從輸入資料衍生，因此在故障復原及使用者主動重新處理時，浮水印是可重複使用的。 使用視窗彙總時，服務只會在視窗結束時產生輸出。 在某些情況下，你可能會想看到從窗口產生的部分聚合結果。 Azure Stream Analytics 目前不支援部分聚合。
在其他串流解決方案中，輸出事件可根據外部條件在不同觸發點實現。 在某些解中，某個時間窗的輸出事件可以多次生成。 隨著輸入值的調整，彙總結果會變得更精確。 事件一開始可以被推測，並隨時間修正。 例如，當一個裝置未連接網路時，系統可能會使用預估值。 其後，該裝置連上了網路。 此時，就可將實際的事件資料包含在輸入資料流中。 處理該時間範圍的輸出結果會產生更精確的輸出。
水印示例圖解
以下影像說明浮水印在不同的環境中的進程。
下表顯示後續圖表中的範例資料。 請注意，事件時間和抵達時間不盡相同，有時相符，有時則否。
| 事件時間 | 抵達時間 | DeviceId |
|---|---|---|
| 12:07 | 12:07 | 裝置 1 |
| 12:08 | 12:08 | 裝置 2 |
| 12:17 | 12:11 | 裝置 1 |
| 12:08 | 12:13 | 裝置 3 |
| 12:19 | 12:16 | 裝置 1 |
| 12:12 | 12:17 | 裝置 3 |
| 12:17 | 12:18 | 裝置 2 |
| 12:20 | 12:19 | 裝置 2 |
| 12:16 | 12:21 | 裝置 3 |
| 12:23 | 12:22 | 裝置 2 |
| 12:22 | 12:24 | 裝置 2 |
| 12:21 | 12:27 | 裝置 3 |
在此圖中，使用了以下公差：
- 提前抵達時間為5分鐘
- 延遲抵達時間範圍為 5 分鐘
- 重新排序時間範圍為 2 分鐘
下圖顯示水印在這些事件中的演進過程：
上圖中值得注意的程序為：
第一個事件 (device1) 和第二個事件 (device2) 的時間一致，未經調整即完成處理。 浮水印會隨每個事件推進。
處理第三個事件 (device1) 時，抵達時間 (12:11) 在事件時間 (12:17) 之前。 該事件提早到達 6 分鐘，因此因超過 5 分鐘的提早到達容錯範圍而遭捨棄。
在這個提早事件的情況下，浮水印不會推進。
第四個事件 (device3) 和第五個事件 (device1) 的時間一致，未經調整即完成處理。 浮水印隨著每個事件而發展。
處理第六個事件 (device3) 時，到達時間 (12:17) 和事件時間 (12:12) 都低於浮水印層級。 事件時間會調整為浮水印層級 (12:17)。
處理第十二個事件 (device3) 時，抵達時間 (12:27) 比事件時間 (12:21) 早了 6 分鐘。 此時適用延遲抵達原則。 事件時間調整為 (12:22) 而高於浮水印 (12:21)，因此無需進一步調整。
第二張說明圖：未使用提早到達原則時的浮水印推進：
此範例未套用早期抵達原則。 提早到達的離群事件會大幅提高浮水印。 請注意，在此案例中，第三個事件 (time 12:11 的 deviceId1) 不會遭到捨棄，且浮水印會提高到 12:15。 第四個事件的時間因此往後調整了 7 分鐘 (12:08 到 12:15)。
在最後一張說明圖中，系統使用了子資料流 (OVER DeviceId)。 系統追蹤多個浮水印，每個資料流各一個。 因此被調整時間的事件數變少了。
