對 Azure 串流分析輸出進行疑難排解
此文章會說明 Azure 串流分析輸出連線的常見問題，以及對輸出問題進行疑難排解的方式。 需要對串流分析作業啟用資源及其他診斷記錄，許多疑難排解步驟才能執行。 如果您未啟用資源記錄，請參閱使用資源記錄對 Azure 串流分析進行疑難排解。
作業不會產生輸出
對各個輸出使用 [測試連線] 按鈕，驗證輸出的連線能力。
在 [監視] 索引標籤上查看使用 Azure 入口網站監視串流分析作業。因為是彙總值，計量會延遲幾分鐘顯示。
- 如果 [輸入事件] 值大於零，作業便可以讀取輸入資料。 如果 [輸入事件] 值不大於零，便代表作業的輸入有問題。 請參閱針對輸入連線進行疑難排解以取得詳細資訊。 如果您的作業有參考資料輸入，請在查看輸入事件計量時，依邏輯名稱套用分割。 如果單單沒有來自參考資料的輸入事件，則可能表示您未正確設定此輸入來源，所以無法擷取正確的參考資料集。
- 如果 [資料轉換錯誤] 值大於零且持續上升，請參閱 Azure 串流分析資料錯誤以取得資料轉換錯誤的詳細資訊。
- 如果 [執行階段錯誤] 值大於零，便代表您作業會接收到資料，但在處理查詢時產生錯誤。 若要找出錯誤，請前往稽核記錄，並篩選 [失敗] 狀態。
- 如果 [輸入事件] 值大於零，且 [輸出事件] 值等於零，則下列其中一個陳述為 true：
- 查詢處理產生零個輸出事件。
- 事件或欄位可能格式錯誤，因此在查詢處理後導致零個輸出。
- 由於連線或驗證問題，作業無法將推送資料至輸出接收端。
除了查詢邏輯篩選掉所有事件的情況之外，作業記錄訊息會說明其他詳細資料 (包括目前所發生的事)。 如果處理多個事件會產生錯誤，則錯誤每 10 分鐘就會彙總一次。
第一個輸出已延遲
當串流分析作業開始時，系統會讀取輸入事件。 但是在某些情況下，輸出中可能會出現延遲。
時態性查詢元素中的較長時間值可能會造成輸出延遲。 若要針對較長時間範圍產生正確的輸出，串流作業會盡可能讀取最近時間的資料，以填滿時間範圍。 該資料最多可能是七天之前。 在系統讀取未處理的輸入事件之前，將不會產生任何輸出。 當系統升級串流作業時，可能會出現此問題。 進行升級時，作業會重新啟動。 這類升級通常每隔幾個月會發生一次。
在設計您的串流分析查詢時請慎重考慮。 如果您在作業的查詢語法中針對時態性元素使用較長的時間範圍，當作業啟動或重新啟動時，可能會在第一個輸出就會延遲。 超過數個小時，最多七天的時間，視為較長的時間範圍。
適用於這種第一個輸出延遲的其中一種緩解方式，便是使用分割資料之類的查詢平行處理技術。 或者，您可以加入更多串流單位來改善輸送量，直到作業趕上進度為止。 如需詳細資訊，請參閱建立串流分析作業時的考量。
這些因素會影響第一個輸出的時效性：
使用視窗型彙總，例如輪轉視窗、跳動視窗和滑動視窗的 GROUP BY 子句：
- 對於輪轉視窗或跳動視窗的彙總，會在時間範圍的結尾產生結果。
- 對於滑動視窗，當事件進入或離開滑動視窗時就會產生結果。
- 如果您打算使用較長的範圍大小 (例如超過一個小時)，最好選擇跳動視窗或滑動視窗。 這些視窗類型可讓您更頻繁地查看輸出。
使用時態性聯結，例如 JOIN 搭配 DATEDIFF：
- 當兩邊相符的事件都到達時，就會產生相符項目。
- 缺乏相符項目的資料 (例如 LEFT OUTER JOIN) 會在 DATEDIFF 時間範圍的結尾，針對左側的每個事件產生。
使用時態性分析函數，例如 ISFIRST、LAST 和 LAG 搭配 LIMIT DURATION：
- 對於分析函數，會針對每個事件產生輸出。 不會有任何延遲。
輸出落後
在作業 (Job) 的一般作業 (Operation) 期間，輸出的延遲時間可能會越來越長。 如果輸出像這樣出現落後，您可以透過檢查下列因素來找出根本原因：
- 下游接收是否已節流
- 上游來源是否已節流
- 查詢中的處理邏輯是否需要大量計算
若要查看輸出詳細資料，請在 Azure 入口網站中選取串流作業，然後選取 [工作圖表]。 針對每個輸入，每個分割區都會有待辦項目事件計量。 如果計量持續增加，則表示系統資源受到限制。 此增加可能是因為輸出接收節流，或是高 CPU 使用率。 如需詳細資訊，請參閱使用作業圖表進行資料驅動偵錯。
Azure SQL Database 輸出的索引鍵違規警告
當您設定 Azure SQL Database 作為串流分析作業的輸出時，其會將記錄大量插入至目的地資料表。 一般而言，Azure 串流分析會保證對輸出接收進行至少一次的傳遞 \(英文\)。 在 SQL 資料表已定義唯一條件約束的情況下，您仍然可以對 SQL 輸出達成剛好一次的傳遞 \(英文\)。
當您在 SQL 資料表上設定唯一索引鍵條件約束時，Azure 串流分析會移除重複的記錄。 其會將資料分割為幾個批次，並以遞迴方式插入批次，直到找到單一重複的記錄。 分割和插入程序會一次忽略一個重複項目。 針對具有許多重複資料列的串流作業，此程序既沒效率且耗時。 如果您在過去一小時內於活動記錄中看到多個索引鍵違規警告訊息，很有可能是 SQL 輸出使整個作業變慢。
若要解決此問題，請啟用 IGNORE_DUP_KEY 選項來設定造成索引鍵違規的索引。 此選項可讓 SQL 在大量插入期間忽略重複的值。 Azure SQL Database 只會產生警告訊息，而不會產生錯誤。 因此，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 輸出的串流分析作業收到第一批事件時，會發生下列步驟：
- 作業會嘗試連線到 SQL。
- 作業會擷取目的地資料表的結構描述。
- 作業會針對目的地資料表結構描述來驗證資料行名稱和類型。
- 作業會從批次中的輸出記錄準備記憶體內部資料表。
- 作業會使用 BulkCopy API 將資料表寫入到 SQL。
在這些步驟進行期間，SQL 輸出可能會遇到下列類型的錯誤：
使用指數輪詢重試策略所重試的暫時性錯誤。 最小重試間隔取決於個別的錯誤碼，但間隔通常小於 60 秒。 上限最多可以有五分鐘。
資料錯誤 (例如轉換錯誤和結構描述強制違規) 會使用輸出錯誤原則來處理。 這些錯誤會藉由重試二進位分割批次來處理，直到造成錯誤的個別記錄透過略過或重試而獲得處理為止。 一律會處理主要唯一索引鍵強制違規。
發生 SQL 服務問題或內部程式碼瑕疵時，可能會發生非暫時性的錯誤。 例如，當錯誤 (例如 Code 1132) 彈性集區達到其儲存體限制時，重試不會解決此錯誤。 在這些案例中，串流分析作業會遇到效能降低情形。
在步驟 5 的
BulkCopy期間可能會發生BulkCopy逾時。BulkCopy偶爾可能會發生作業逾時。 所設定的最小預設逾時值為 5 分鐘，連續達到時則會加倍。 逾時值一旦高於 15 分鐘，BulkCopy的最大批次大小提示便會縮減為一半，直到剩下每個批次 100 個事件為止。重要
對於非網路插入的 ASA 作業，請不要以任何方式依賴來自 ASA 之連線的來源 IP 位址。 視不時發生的服務基礎結構作業而定，它們可以是公用或私人 IP。
Azure 串流分析 (1.0) 中的資料行名稱為小寫
使用原始的相容性層級 (1.0) 時，Azure 串流分析會將資料行名稱變更為小寫。 此行為已在較新的相容性層級中修正。 若要保留大小寫，請移至相容性層級 1.1 或更新版本。 如需詳細資訊，請參閱串流分析作業的相容性層級 \(部分機器翻譯\)。
取得協助
如需進一步的協助，請嘗試 Azure 串流分析的 Microsoft 問與答頁面。