

在仔細考慮之後，我們決定停止 Amazon Kinesis Data Analytics for SQL 應用程式：

1. 從 **2025 年 9 月 1 日起，**我們不會為 Amazon Kinesis Data Analytics for SQL 應用程式提供任何錯誤修正，因為考慮到即將終止，我們將對其提供有限的支援。

2. 從 **2025 年 10 月 15 日起，**您將無法建立新的 Kinesis Data Analytics for SQL 應用程式。

3. 我們將自 **2026 年 1 月 27** 日起刪除您的應用程式。您將無法啟動或操作 Amazon Kinesis Data Analytics for SQL 應用程式。從那時起，Amazon Kinesis Data Analytics for SQL 將不再提供支援。如需詳細資訊，請參閱[Amazon Kinesis Data Analytics for SQL 應用程式終止](discontinuation.md)。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 疑難排解 Amazon Kinesis Data Analytics for SQL 應用程式
<a name="troubleshooting"></a>

以下內容可協助您對Amazon Kinesis Data Analytics for SQL 應用程式中可能遇到的問題進行疑難排解。

**Topics**
+ [停止的應用程式](#idle-applications)
+ [無法執行 SQL 程式碼](#sql-statement)
+ [無法偵測或探索我的結構描述](#detect-schema)
+ [參考資料已過期](#reference-reload)
+ [應用程式未寫入目的地](#output)
+ [要監控的重要應用程式運作狀態參數](#parameters)
+ [運行應用程序時代碼錯誤無效](#invalid-code)
+ [應用程式正在將錯誤寫入錯誤資料流](#error-stream)
+ [輸送量不足或高 MillisBehindLatest](#insufficient-throughput)

## 停止的應用程式
<a name="idle-applications"></a>
+ **什麼是停止的 Amazon Kinesis Data Analytics for SQL 應用程式？**

  停止的應用程式，是我們觀察到至少三個月未處理任何記錄的應用程式。這表示客戶需要為未使用的 SQL 資源支付 Kinesis Data Analytics 費用。
+ **何時會 AWS 開始停止閒置的應用程式？**

  AWS 將於 2023 年 11 月 14 日開始停止閒置的應用程式，並於 2023 年 11 月 21 日之前完成。我們將在該地區的辦公時間時區停止閒置的應用程式。
+ **停止的 Kinesis Data Analytics for SQL 應用程式是否可重新啟動？**

  是。如果需要重新啟動應用程式，可以如常操作。沒有必要提交支援票證。
+ **當 AWS 停止閒置應用程式時，我的任何查詢結果也會遭到刪除嗎？**

  不會。首先，由於您的應用程式處於空閒狀態，因此不處理查詢。其次，您的查詢結果不會儲存在 Kinesis Data Analytics for SQL 中。您會為 Kinesis Data Analytics for SQL 應用程式設定接收目的地，計算的結果會傳送到該處 (如 Amazon S3 或其他資料串流)。因此，您保留資料的完整擁有權，並且在該儲存服務條款下，資料仍可擷取。
+ **如果我不想停止應用程式，該怎麼辦？**

  您可以寄送電子郵件給服務團隊 (kda-sql-questions@amazon.com)，要求不要在 2023 年 11 月 10 日之前停止應用程式。該電子郵件應包括您的帳戶 ID 和應用程式 ARN。

## 無法執行 SQL 程式碼
<a name="sql-statement"></a>

如果您需要弄清楚如何讓特定 SQL 陳述式正常運作，Kinesis Data Analytics 有數種可用的不同資源：
+ 如需有關 SQL 陳述式的詳細資訊，請參閱 [Kinesis Data Analytics for SQL 範例](examples.md)。本節提供您可以使用的許多 SQL 範例。
+ [《Amazon Kinesis Data Analytics SQL 參考》](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sqlrf_Preface.html)**提供編寫串流 SQL 陳述式的詳細指南。
+ 如果您仍然遇到問題，我們建議您在 [Kinesis Data Analytics 論壇](https://forums.aws.amazon.com/ann.jspa?annID=4153)上提出問題。

## 無法偵測或探索我的結構描述
<a name="detect-schema"></a>

在某些情況下，Kinesis Data Analytics 無法偵測或探索結構描述。在許多情況下，您仍然可以使用 Kinesis Data Analytics。

假設您的 UTF-8 編碼資料不使用分隔符號，或使用逗號分隔值 (CSV) 以外的格式的資料，或探索 API 未探索您的結構描述。在這些情況下，您可以手動定義結構描述，或使用字串操作函數來建構資料。

為了探索串流的結構描述，Kinesis Data Analytics 會隨機抽樣串流中的最新資料。如果您並未持續地將資料傳送至串流，Kinesis Data Analytics 可能無法擷取範例並偵測結構描述。如需詳細資訊，請參閱[在串流資料上使用結構描述探索功能](sch-dis.md)。

## 參考資料已過期
<a name="reference-reload"></a>

啟動或更新應用程式時，或在服務問題造成的應用程式中斷期間，參考資料會從 Amazon Simple Storage Service (Amazon S3) 物件載入到應用程式。

對基礎 Amazon S3 物件進行更新時，不會將參考資料載入應用程式。

如果應用程式中的參考資料不是最新的，您可以按照下列步驟重新載入資料：

1. 前往 Kinesis Data Analytics 主控台，在清單中選擇應用程式名稱，然後選擇**應用程式詳細資訊**。

1. 選擇**至 SQL 編輯器**以開啟應用程式的**即時分析**頁面。

1. 在**來源資料**檢視中，選擇您的參考資料表名稱。

1. 選擇**動作**，**同步化參考資料表**。

## 應用程式未寫入目的地
<a name="output"></a>

如果未將資料寫入目的地，請檢查以下項目：
+ 確認應用程式的角色具有足夠的許可來存取目的地。如需詳細資訊，請參閱 [寫入 Kinesis Stream 的許可政策](iam-role.md#iam-role-permissions-policy-ak-stream) 或 [寫入 Firehose Delivery Stream 的許可政策](iam-role.md#iam-role-permissions-policy-af-delivery-stream)。
+ 確認應用程式目的地設定正確，以及應用程式使用的輸出串流名稱正確。
+ 檢查輸出串流的 Amazon CloudWatch 指標，看看是否正在寫入資料。如需使用 CloudWatch 指標的相關資訊，請參閱 [使用 Amazon CloudWatch 監控](monitoring-cloudwatch.md)。
+ 使用 [AddApplicationCloudWatchLoggingOption](API_AddApplicationCloudWatchLoggingOption.md) 新增 CloudWatch 日誌串流。您的應用程式會將設定錯誤寫入日誌串流。

如果角色和目的地組態看起來正確，請嘗試重新啟動應用程式，並在 [InputStartingPositionConfiguration](API_InputStartingPositionConfiguration.md) 指定 `LAST_STOPPED_POINT`。

## 要監控的重要應用程式運作狀態參數
<a name="parameters"></a>

為了確保您的應用程序正常運行，我們建議您監控某些重要參數。

要監控的最重要參數是 Amazon CloudWatch 指標 `MillisBehindLatest`。此指標表示您從串流讀取落後於目前的時間。此指標可協助您判斷處理來源串流記錄的速度是否不夠快。

一般而言，您應該設定 CloudWatch 警示，以便在落後超過一小時時觸發。但是，時間會依使用案例而定。您可以根據需要進行調整。

如需詳細資訊，請參閱[最佳實務](best-practices.md)。

## 運行應用程序時代碼錯誤無效
<a name="invalid-code"></a>

如您無法儲存並執行 Amazon Kinesis Data Analytics 應用程式的 SQL 程式碼，下列是常見的原因：
+ **串流已在 SQL 程式碼中重新定義**：建立串流與相關的幫浦後，您無法在程式碼中重新定義相同的串流。如需如何建立串流的資訊，請參閱《Amazon Kinesis Data Analytics SQL 參考》**中的[建立串流](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sql-reference-create-stream.html)。如需建立幫浦的詳細資訊，請參閱[建立幫浦](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sql-reference-create-pump.html)。
+ **GROUP BY 子句使用多個 ROWTIME 資料欄**：您只能在 GROUP BY 子句中指定一個 ROWTIME 資料行。如需詳細資訊，請參閱《Amazon Kinesis Data Analytics SQL 參考》**中的 [GROUP BY](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sql-reference-group-by-clause.html) 和 [ROWTIME](https://docs.aws.amazon.com/kinesisanalytics/latest/sqlref/sql-reference-rowtime.html)。
+ **一個或多個數據類型具有無效的轉換**：在這種情況下，您的程式碼具有無效的隱含轉換。例如，您可能會在程式碼中將 `timestamp` 轉換為 `bigint`。
+ 串流與服務保留串流的名稱相同****：串流與服務保留串流 `error_stream` 不能有相同的名稱。

## 應用程式正在將錯誤寫入錯誤資料流
<a name="error-stream"></a>

如果應用程式正在將錯誤寫入應用程式內錯誤串流，您可以使用標準程式庫在 `DATA_ROW` 欄位中解碼該值。關於錯誤串流的詳細資訊，請查看 [錯誤處理](error-handling.md)。

## 輸送量不足或高 MillisBehindLatest
<a name="insufficient-throughput"></a>

如果應用程式的 [MillisBehindLatest](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) 指標穩定增加或持續超過 1000 (一秒)，可能是下列原因所致：
+ 檢查您應用程式的 [InputBytes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) CloudWatch 指標。如果你攝入超過每秒 4 MB, 這可能會導致 `MillisBehindLatest` 增加。若要改善應用程式的輸送量，請增加 `InputParallelism` 參數的值。如需詳細資訊，請參閱[平行化輸入串流以提高輸送量](input-parallelism.md)。
+ 檢查應用程式的輸出交付[成功](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html)指標，以瞭解交付至目的地時是否失敗。請確認您已正確設定輸出，且輸出串流有足夠的容量。
+ 如果您的應用程式使用 AWS Lambda 函數進行預先處理或作為輸出，請檢查應用程式的 [InputProcessing.Duration](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) 或 [LambdaDelivery.Duration](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aka-metricscollected.html) CloudWatch 指標。如果 Lambda 函數調用持續時間超過 5 秒，請考慮執行下列動作：
  + 增加 Lambda 函數的**記憶體**配置。您可以在 AWS Lambda 主控台**組態**頁面的**基本設定**中執行此動作。如需詳細資訊，請參閱《AWS Lambda 開發人員指南》**中的[設定 Lambda 函數](https://docs.aws.amazon.com/lambda/latest/dg/resource-model.html)。
  + 增加應用程式輸入串流中的碎片數。此舉會增加應用程式將調用的平行函數數目，也可能會增加輸送量。
  + 確認函數沒有進行會影響效能的封鎖呼叫，例如對外部資源的同步請求。
  + 檢查您的 AWS Lambda 函數，以查看是否有其他可以改善效能的領域。檢查應用程式 Lambda 函數的 CloudWatch Logs。如需詳細資訊，請參閱《AWS Lambda 開發人員指南》**中的[存取 Amazon CloudWatch 指標](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html)。
+ 確認您的應用程式未達到 Kinesis 處理單元 (KPU) 的預設限制。如果應用程式達到此限制，您可以要求提高限制。如需詳細資訊，請參閱[自動擴展應用程式以增加輸送量](how-it-works-autoscaling.md)。
+ 如果您的應用程式在 KPU 限制增加後仍有問題，請檢查應用程式的輸入輸送量是否不超過每秒 100MB。如果超過每秒 100 MB，我們建議您實施變更以減少整體輸送量來穩定應用程式，例如減少傳送至 Kinesis Data Analytics SQL 應用程式讀取資料來源的資料量。我們也建議使用其他方法，包括增加應用程式的平行處理能力、縮短運算的時間週期、將單欄資料類型從 VARCHAR 變更為較小的資料類型 (例如 INTEGER、LONG 等)、以及減少透過取樣或篩選處理的資料。
**注意**  
我們建議您定期檢閱應用程式的 `InputProcessing.OkBytes` 指標，以便在應用程式的預計輸入輸送量超過每秒 100 MB 時，事先規劃使用多個 SQL 應用程式，或移轉至 managed-flink/latest/java/。