針對 Azure 串流分析查詢進行疑難解答
本文說明開發串流分析查詢的常見問題，以及如何進行疑難解答。
本文說明開發 Azure 串流分析查詢的常見問題、如何針對查詢問題進行疑難解答，以及如何修正問題。 許多疑難解答步驟都需要為您的串流分析作業啟用資源記錄。 如果您沒有啟用資源記錄，請參閱 使用資源記錄對 Azure 串流分析進行疑難解答。
查詢未產生預期的輸出
藉由在本機測試來檢查錯誤：
- 在 [Azure 入口網站] 的 [查詢] 索引標籤上，選取 [測試]。 使用下載的範例數據來 測試查詢。 檢查任何錯誤，並嘗試更正錯誤。
- 您也可以使用適用於 Visual Studio 或 Visual Studio Code 的 Azure 串流分析工具在本機測試查詢。
使用適用於 Visual Studio Code 的 Azure 串流分析工具中的作業圖表 ，逐步對查詢進行偵錯。 作業圖表顯示數據如何從輸入來源（事件中樞、IoT 中樞 等）流經多個查詢步驟，最後流向輸出接收。 每個查詢步驟都會對應至使用WITH語句在腳本中定義的暫存結果集。 您可以在每個中繼結果集中檢視數據以及計量，以尋找問題的來源。
如果您使用 Timestamp By，請確認事件具有大於作業開始時間的時間戳。
消除常見的陷阱，例如：
- 查詢中的 WHERE 子句會篩選掉所有事件，以防止產生任何輸出。
- CAST 函式失敗，導致作業失敗。 若要避免類型轉換失敗，請改用 TRY_CAST 。
- 當您使用視窗函式時，請等候整個視窗持續時間來查看查詢的輸出。
- 事件的時間戳在作業開始時間和事件卸除之前。
- JOIN 條件不符。 如果沒有相符專案，則輸出將會是零。
確定已如預期設定事件排序原則。 移至 [設定]，然後選取 [事件排序]。 當您使用 [測試] 按鈕來測試查詢時，不會套用原則。 此結果是在瀏覽器中測試與在生產環境中執行作業之間的差異。
使用活動與資源記錄偵錯：
資源使用率很高
請確定您在 Azure 串流分析中利用平行處理。 您可以藉由設定輸入分割區及調整分析查詢定義，瞭解如何 使用串流分析作業的查詢平行化 來調整規模。
如果資源使用率持續超過 80%，水位線延遲就會上升，且積壓事件的數目正在上升，請考慮增加串流單位。 高使用率表示作業使用接近已配置資源上限。
以漸進方式對查詢偵錯
在實時數據處理中，瞭解查詢中間的數據看起來會很有説明。 您可以使用 Visual Studio 中的作業圖表來查看此專案。 如果您沒有 Visual Studio，您可以採取其他步驟來輸出中繼數據。
由於 Azure 串流分析作業的輸入或步驟可以多次讀取，因此您可以撰寫額外的 SELECT INTO 語句。 這樣做會將元數據輸出到記憶體，並可讓您檢查數據的正確性，就像偵錯程式時監看變數一樣。
Azure 串流分析作業中的下列範例查詢有一個數據流輸入、兩個參考數據輸入，以及 Azure 數據表的輸出 儲存體。 查詢會聯結事件中樞和兩個參考 Blob 的數據，以取得名稱和類別資訊：
請注意，作業正在執行，但輸出中不會產生任何事件。 在此處顯示的 [監視] 圖格上，您可以看到輸入正在產生數據，但您不知道 JOIN 的哪個步驟會導致卸除所有事件。
在此情況下，您可以將一些額外的 SELECT INTO 語句新增至「記錄」中繼 JOIN 結果，以及從輸入讀取的數據。
在此範例中，我們已新增兩個新的「暫存輸出」。它們可以是您想要的任何接收。 我們在這裡使用 Azure 儲存體 作為範例：
然後，您可以重新撰寫如下的查詢：
現在再次啟動作業，並讓它執行幾分鐘。 然後使用 Visual Studio Cloud Explorer 查詢 temp1 和 temp2，以產生下列數據表：
temp1 數據表
temp2 數據表
如您所見，temp1 和 temp2 都有數據，且 name 數據行會在 temp2 中正確填入。 不過，由於輸出中仍有數據，因此發生錯誤：
藉由取樣數據，您幾乎可以確定問題與第二個 JOIN。 您可以從 Blob 下載參考資料，並查看：
如您所見，此參考數據中的 GUID 格式與 temp2 中 [from] 資料行的格式不同。 這就是為什麼數據未如預期般抵達 output1。
您可以修正資料格式、將它上傳至參考 Blob，然後再試一次：
這次，輸出中的數據會格式化並如預期填入。
取得說明
如需進一步的協助，請嘗試 Azure 串流分析的 Microsoft Q&A 問題頁面。