針對 Azure 串流分析輸出進行疑難解答

  • 發行項

本文說明 Azure 串流分析輸出連線的常見問題，以及如何針對輸出問題進行疑難解答。 許多疑難解答步驟都需要為您的串流分析作業啟用資源和其他診斷記錄。 如果您沒有啟用資源記錄，請參閱 使用資源記錄對 Azure 串流分析進行疑難解答。

作業不會產生輸出

  1. 使用每個輸出的 [測試 連線 ion] 按鈕，確認輸出的連線能力。

  2. 在 [監視] 索引標籤上查看 [監視串流分析] 作業，並 Azure 入口網站。由於匯總值，因此計量會延遲幾分鐘。

    • 如果輸入事件值大於零，作業可以讀取輸入數據。 如果輸入事件值不大於零，則作業的輸入發生問題。 如需詳細資訊，請參閱 針對輸入連線 進行疑難解答。 如果您的作業有參考數據輸入，請在查看 輸入事件 計量時，依邏輯名稱套用分割。 如果僅參考數據沒有任何輸入事件，則可能表示尚未正確設定此輸入來源來擷取正確的參考數據集。
    • 如果數據轉換錯誤值大於零並攀升，請參閱 Azure 串流分析數據錯誤，以取得資料轉換錯誤的詳細資訊。
    • 如果運行時間錯誤值大於零，則您的作業會收到數據，但在處理查詢時產生錯誤。 若要尋找錯誤，請移至 稽核記錄，然後篩選 失敗 狀態。
    • 如果 Input Events 值大於零，且 Output Events 值等於零，下列其中一個語句為 true：
      • 查詢處理會產生零個輸出事件。
      • 事件或欄位的格式可能不正確，導致查詢處理之後輸出為零。
      • 作業因連線或驗證原因而無法將數據推送至輸出接收。

    作業記錄訊息會說明其他詳細數據，包括發生的情況，但查詢邏輯會篩選掉所有事件的情況除外。 如果處理多個事件會產生錯誤，則錯誤會每隔 10 分鐘匯總一次。

第一個輸出延遲

串流分析作業啟動時，會讀取輸入事件。 但是，在某些情況下，輸出可能會有延遲。

時態查詢元素中的大型時間值可能會造成輸出延遲。 若要在大型時間範圍中產生正確的輸出，串流作業會從可能填滿時間範圍的最新時間讀取數據。 數據最多可以超過七天。 在讀取未完成的輸入事件之前，不會產生任何輸出。 當系統升級串流作業時，這個問題可能會浮出水面。 升級發生時，作業會重新啟動。 這類升級通常會每隔幾個月進行一次。

設計串流分析查詢時，請使用自由裁量權。 如果您針對作業查詢語法中的時態專案使用大型時間範圍，當作業啟動時或重新啟動時，可能會導致第一個輸出出現延遲。 超過幾個小時，最多七天，被認為是一個很大的時間範圍。

這種第一個輸出延遲的其中一個緩和措施是使用查詢平行處理技術，例如分割數據。 或者，您可以新增更多串流單位來改善輸送量，直到作業趕上為止。 如需詳細資訊，請參閱 建立串流分析作業時的考慮。

這些因素會影響第一個輸出的時間軸：

  • 使用視窗匯總，例如輪轉、跳躍和滑動視窗的 GROUP BY 子句：

    • 針對輪轉或跳動視窗匯總，結果會在窗口時間範圍結尾產生。
    • 對於滑動視窗，當事件進入或結束滑動視窗時，會產生結果。
    • 如果您打算使用大型視窗大小，例如一個多小時，最好選擇跳動或滑動視窗。 這些視窗類型可讓您更頻繁地查看輸出。

  • 使用時態性聯結，例如 JOIN 與 DATEDIFF：

    • 相符專案會在相符事件的兩端送達時立即產生。
    • 缺少相符項目的數據，例如 LEFT OUTER JOIN，會在 DATEDIFF 視窗結尾針對左側的每個事件產生。

  • 使用時態分析函式，例如ISFIRST、LAST和LAG與 LIMIT DURATION：

    • 針對分析函式，會針對每個事件產生輸出。 沒有延遲。

輸出落後

在作業的正常作業期間，輸出可能會有較長且較長的延遲期間。 如果輸出落後，您可以檢查下列因素來找出根本原因：

  • 下游接收是否受到節流
  • 上游來源是否受到節流
  • 查詢中的處理邏輯是否需要大量計算

若要查看輸出詳細數據，請選取 Azure 入口網站 中的串流作業，然後選取 [作業圖表]。 針對每個輸入，每個分割區都有待辦專案事件計量。 如果計量持續增加，表示系統資源受到限制。 增加可能是因為輸出接收節流或高 CPU 使用量。 如需詳細資訊，請參閱 使用作業圖表進行數據驅動偵錯。

Azure SQL 資料庫 輸出的金鑰違規警告

當您將 Azure SQL 資料庫設定為串流分析作業的輸出時，它會將記錄大量插入目的地數據表。 一般而言，Azure 串流分析保證 至少一次傳遞 至輸出接收。 當 SQL 資料表已定義唯一條件約束時，您仍然可以 完全一次地傳遞 至 SQL 輸出。

當您在 SQL 資料表上設定唯一索引鍵條件約束時，Azure 串流分析會移除重複的記錄。 它會將數據分割成批次，並以遞歸方式插入批次，直到找到單一重複的記錄為止。 分割和插入程式會一次忽略重複專案。 對於具有許多重複數據列的串流作業，程式效率低下且耗時。 如果您在活動記錄中看到前一個小時的多個密鑰違規警告訊息，您的 SQL 輸出可能會讓整個作業變慢。

若要解決此問題， 請啟用 [IGNORE_DUP_KEY] 選項，以設定造成密鑰違規的索引 。 此選項可讓 SQL 在大量插入期間忽略重複的值。 Azure SQL 資料庫 只會產生警告訊息，而不是錯誤。 因此，Azure 串流分析不再產生主要密鑰違規錯誤。

針對數種類型的索引設定IGNORE_DUP_KEY時，請注意下列觀察：

  • 您無法在主鍵或使用 ALTER INDEX 的唯一條件約束上設定IGNORE_DUP_KEY。 您需要卸除索引並重新建立它。
  • 您可以針對唯一索引使用 ALTER INDEX 來設定IGNORE_DUP_KEY。 這個實例與 PRIMARY KEY/UNIQUE 條件約束不同，並使用 CREATE INDEX 或 INDEX 定義來建立。
  • IGNORE_DUP_KEY選項不適用於數據行存放區索引，因為您無法對其強制執行唯一性。

SQL 輸出重試邏輯

當具有 SQL 輸出的串流分析作業收到第一批事件時，會發生下列步驟：

  1. 作業會嘗試連線到 SQL。
  2. 作業會擷取目的地數據表的架構。
  3. 作業會根據目的地數據表架構來驗證數據行名稱和類型。
  4. 作業會從批次中的輸出記錄準備記憶體內部數據表。
  5. 作業會使用 BulkCopy API 將數據表寫入 SQL。

在這些步驟期間，SQL 輸出可能會遇到下列類型的錯誤：

  • 使用指數輪詢重試策略重試的暫時性 錯誤 。 最小重試間隔取決於個別的錯誤碼，但間隔通常小於 60 秒。 上限最多可以有五分鐘。

    登入失敗 和 防火牆問題 會在前一次嘗試後至少重試 5 分鐘，並重試，直到成功為止。

  • 數據錯誤，例如轉換錯誤和架構條件約束違規，會使用輸出錯誤原則來處理。 這些錯誤會藉由重試二進位分割批次來處理，直到造成錯誤的個別記錄被略過或重試處理為止。 主要唯一索引鍵條件約束違規一 律會處理。

  • 發生 SQL 服務問題或內部程式代碼缺失時，可能會發生非暫時性錯誤。 例如，當 [程序代碼 1132] 等彈性集區達到其儲存限制時，重試不會解決錯誤。 在這些案例中，串流分析作業會降低。

  • BulkCopy 在步驟 5 期間 BulkCopy 可能會發生逾時。 BulkCopy 偶爾會遇到作業逾時。 默認的最小設定逾時為五分鐘，且在連續點擊時會加倍。 逾時超過 15 分鐘後，每個批次的最大批次大小提示 BulkCopy 會縮減為一半，直到每個批次有 100 個事件為止。

    重要

    對於非網路插入的 ASA 作業，請不要以任何方式依賴來自 ASA 之連線的來源 IP 位址。 視不時發生的服務基礎結構作業而定，它們可以是公用或私人IP。

Azure 串流分析中的數據行名稱小寫 （1.0）

使用原始相容性層級 （1.0） 時，Azure 串流分析會將數據行名稱變更為小寫。 此行為在稍後的相容性層級中已修正。 若要保留大小寫，請移至相容性層級 1.1 或更新版本。 如需詳細資訊，請參閱 串流分析作業的相容性層級。

取得說明

如需進一步的協助，請嘗試 Azure 串流分析的 Microsoft Q&A 問題頁面。

下一步