在仔細考慮之後，我們決定停止 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 應用程式時的最佳實務。
**Topics**
+ [管理應用程式](#bp-manage-apps)
+ [擴展應用程式](#bp-scale-apps)
+ [監控應用程式](#bp-monitor-apps)
+ [定義輸入結構描述](#bp-define-inputschema)
+ [連接至輸出](#bp-connect-to-outputs)
+ [撰寫應用程式碼](#bp-authoring-sqlcode)
+ [測試應用程式](#bp-testing)
## 管理應用程式
管理 Amazon Kinesis Data Analytics 應用程式時，請遵循下列最佳實務：
+ 設定 Amazon CloudWatch 警示 — 您可以使用 Kinesis Data Analytics 提供的 CloudWatch 指標來監控下列項目：
+ 輸入位元組和輸入記錄（進入應用程式的位元組和記錄數）
+ 輸出位元組和輸出記錄
+ `MillisBehindLatest` (應用程式從串流來源讀取時的差距)
針對生產中的應用程式，我們建議您在下列指標上至少設定兩個 CloudWatch 警示：
+ `MillisBehindLatest`：在大多數情況下，我們建議您將此警報的觸發條件設置為應用程式比最新資料晚 1 小時，平均為 1 分鐘。對於端對端處理需求較低的應用程式，您可以將其調整為較低的公差。此警報可確保您的應用程式讀取的是最新資料。
+ 為避免發生 `ReadProvisionedThroughputException` 例外狀況，請將讀取同一 Kinesis 資料串流的生產應用程式數量限制為兩個。
**注意**
在這種情況下，*應用程式*是指任何可以讀取串流來源的應用程式。只有 Kinesis Data Analytics 應用程式可以從 Firehose 交付串流讀取。不過，許多應用程式可以從 Kinesis 資料串流讀取，例如 Kinesis Data Analytics 應用程式或 AWS Lambda。建議的應用程式限制，指的是您設定來讀取一個串流來源的所有應用程式。
每個 Amazon Kinesis Data Analytics 應用程式每秒約讀取一次串流來源。但落後的應用程式可能會以更快的速度讀取資料來趕上進度。若要讓應用程式有足夠的輸送量來趕上進度，請限制讀取相同資料來源的應用程式數目。
+ 將從相同 Firehose 交付串流讀取的生產應用程式數量限制為一個應用程式。
Firehose 交付串流可以寫入 Amazon S3 和 Amazon Redshift 等目的地。它也可以是 Kinesis Data Analytics 應用程式的串流來源。因此，建議您不要為每個 Firehose 交付串流設定多個 Kinesis Data Analytics 應用程式。此舉能確保交付串流也可以傳遞至其他目的地。
## 擴展應用程式
透過主動增加輸入應用程式內串流預設數量 (一個)，以滿足應用程式未來的擴展需求。我們建議您根據應用程式的輸送量選擇下列語言：
+ 如果您應用程式的擴展需求超過每秒 100 MB，請針使用多個串流和 Kinesis Data Analytics for SQL 應用程式。
+ 如果您想要使用單一串流和應用程式，請選擇 [Managed Service for Apache Flink 應用程式](https://docs.aws.amazon.com/managed-flink/latest/java/what-is.html)。
**注意**
我們建議您定期檢閱應用程式的 `InputProcessing.OkBytes` 指標，以便以事先規劃使用多個 SQL 應用程式，或者在應用程式預計輸入輸送量超過每秒 100 MB 時，移轉至 Managed Service for Apache Flink 應用程式。
## 監控應用程式
我們建議您建立 `InputProcessing.OkBytes` 的 CloudWatch 警示，以便在應用程式接近輸入輸送量限制時收到通知。此舉能有效地讓您更新應用程式查詢，以權衡更高的輸送量，進而避免了分析的背壓和延遲。如需詳細資訊，請參閱[疑難排解](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/troubleshooting.html)。如果有減少上游輸送量的機制，此方式也很有用。
+ 針對單一應用程式內的串流，我們建議的最大輸送量為每秒 2 到 20 MB，視應用程式查詢的複雜程度而定。
+ 單一 Kinesis Data Analytics for SQL 應用程式可處理的最大串流輸送量約為每秒 100 MB。先決條件為您已將應用程式內串流的數目增加到上限 64，且 KPU 限制已調到 8 以上。如需詳細資訊，請參閱[限制](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/limits.html)。
**注意**
我們建議您定期檢閱應用程式的 `InputProcessing.OkBytes` 指標，以便以事先規劃使用多個 SQL 應用程式，或者在應用程式預計輸入輸送量超過每秒 100 MB 時，移轉至 Managed Service for Apache Flink 應用程式。
## 定義輸入結構描述
在主控台中設定應用程式輸入時，您必須先指定一個串流來源。然後，主控台會使用 Discovery API (請參閱[DiscoverInputSchema](API_DiscoverInputSchema.md))，透過在串流來源上取樣記錄來推斷結構描述。除此之外，在產生的應用程式內串流中，結構描述會定義資料欄的名稱和資料類型。主控台會顯示結構描述。我們建議您用此推斷結構描述進行下列動作：
+ 充分測試推斷的結構描述。探索程序只會使用串流來源上的取樣記錄來推斷結構描述。如果您的串流來源有 [許多記錄類型](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/app-tworecordtypes.html)，Discovery API 可能會錯過一個或多個記錄類型的取樣。這種情況可能會導致結構描述無法準確反映串流來源上的資料。
當您的應用程式啟動時，這些遺漏的記錄類型可能會導致剖析錯誤。Amazon Kinesis Data Analytics 會將這些記錄傳送到應用程式內錯誤串流。若要減少這些剖析錯誤，建議您在主控台中以互動方式測試推斷的結構描述，並監視應用程式內串流是否有遺漏的記錄。
+ Kinesis Data Analytics API 不支援對輸入組態中的資料欄指定 `NOT NULL` 條件限制。如果您想要 `NOT NULL` 限制應用程式內串流中的資料欄，請使用應用程式碼建立這些應用程式內串流。然後，您可以將資料從一個應用程式內串流複製到另一個，然後強制執行限制。
當欄位需要值時，任何插入 `NULL` 值的嘗試都會導致錯誤。Kinesis Data Analytics 會將這些錯誤傳送至應用程式內錯誤串流。
+ 放寬探索程序推斷的資料類型。探索程序會在串流來源上隨機抽樣記錄，並根據結果建議資料欄和資料類型。我們建議您仔細檢閱這些資料，並考慮放寬這些資料類型，以涵蓋輸入中所有可能的記錄案例。這樣可減少應用程式執行時的剖析錯誤。舉例來說，如果推論的結構描述具有 `SMALLINT` 資料欄類型，請考慮將其變更為 `INTEGER`。
+ 在應用程式碼中使用 SQL 函數來處理任何非結構化資料或資料欄。您的輸入中可能包含非結構化資料或資料欄，例如日誌資料。如需範例，請參閱 [範例：轉換 DateTime 值](app-string-datetime-manipulation.md)。處理此類資料的一種方法，是只用一個資料欄的 `VARCHAR(N)` 類型定義結構描述，其中 `N` 是您預期在串流中看到的最大可能資料列。然後，您可以在應用程式碼讀取傳入的記錄，並使用 `String` 和 `Date Time` 函數剖析原始資料並進行結構描述。
+ 請確定您已完全處理包含巢狀深度超過兩層的串流來源資料。當源數據是 JSON 時，即可能出現巢狀結構。Discovery API 會推斷結構描述，該結構描述會展平一層巢狀。針對兩個層級的巢狀，Discovery API 也會嘗試將這些層級平面化。如超過兩個巢狀層級，展平的支援就會受限。若要完全處理巢狀，您必須手動修改推斷的結構描述以符合需求。使用下列任一策略來達成此目標：
+ 使用 JSON 資料列路徑，選擇性地僅提取應用程式所需的金鑰值配對。JSON 資料列路徑會提供指標，指向您要引入應用程式的特定金鑰值配對。您可以對任何級別的巢狀執行此操作。
+ 使用 JSON 資料列路徑選擇性地提取複雜的 JSON 物件，然後在應用程式碼中，使用字串操作函式來提取所需的特定資料。
## 連接至輸出
我們建議每個應用程式至少有兩個輸出：
+ 使用第一個目的地插入 SQL 查詢的結果。
+ 使用第二個目的地插入整個錯誤串流，並透過 Firehose 交付串流將其傳送至 S3 儲存貯體。
## 撰寫應用程式碼
我們建議下列作法：
+ 在 SQL 陳述式中，請勿指定超過一小時的時間型視窗，原因如下：
+ 有時候因為您更新了應用程式，或是基於 Kinesis Data Analytics 的內部原因，應用程式需要重新啟動。重新啟動時，必須從串流資料來源再次讀取視窗中包含的所有資料。Kinesis Data Analytics 需要一段時間才能為該視窗發出輸出。
+ 在這段時間內，Kinesis Data Analytics 必須維護與應用程式狀態相關的所有內容，包括相關資料。此舉會消耗大量的 Kinesis Data Analytics 處理單元。
+ 在開發過程中，請在 SQL 陳述式中保持較小的視窗，以便更快地查看結果。將應用程式部署到生產環境時，可以視需要設定視窗大小。
+ 請考慮將其分解為多個陳述式，而不是單一複雜的 SQL 陳述式，這些陳述式會在每個步驟中儲存中繼應用程式內串流。此舉可能會加快您的偵錯速度。
+ 使用[翻轉視窗](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/tumbling-window-concepts.html)時，我們建議您開啟兩個視窗，一個用於處理時間，另一個用於邏輯時間 (擷取時間或事件時間)。如需詳細資訊，請參閱[時間戳記和 ROWTIME 欄](timestamps-rowtime-concepts.md)。
## 測試應用程式
在變更 Kinesis Data Analytics 應用程式的結構描述或應用程式碼時，我們建議您先使用測試應用程式來驗證變更，然後再將變更部署到生產環境。
### 設定測試應用程式
您可以透過主控台或使用 CloudFormation 範本設定測試應用程式。使用 CloudFormation 範本有助於確保您對測試應用程式和即時應用程式的程式碼變更一致。
設置測試應用程式時，您可以將其連接到即時資料，也可以使用要測試的模擬資料填入串流。我們建議使用兩種方法來將模擬數據填入串流：
+ 使用 [Kinesis 資料產生器 (KDG)](https://aws.amazon.com/blogs/big-data/test-your-streaming-data-solution-with-the-new-amazon-kinesis-data-generator/)。KDG 使用資料範本將隨機資料傳送至 Kinesis 串流。KDG 使用簡單，但不適合測試資料項目之間的複雜關係，例如偵測資料熱點或異常的應用程式。
+ 使用自訂 Python 應用程式將更複雜的資料傳送至 Kinesis 資料串流。Python 應用程式可以產生資料項目之間的複雜關係，例如熱點或異常。如需將資料叢集傳送到資料熱點的 Python 應用程式範例，請參閱 [範例：偵測串流上的熱點 (熱點功能)](app-hotspots-detection.md)。
執行測試應用程式時，請使用目的地 （例如 Firehose 交付串流到 Amazon Redshift 資料庫） 檢視結果，而不是在主控台上檢視應用程式內串流。主控台上顯示的數據是串流的取樣，並且不包含所有記錄。
### 測試結構描述變更
變更應用程式的輸入串流結構描述時，請使用測試應用程式來確認下列條件為真：
+ 串流中的資料會強制轉換為正確的資料類型。舉例來說，請確定日期時間資料不會以字串形式擷取到應用程式中。
+ 資料經過剖析並強制轉換為您想要的類型。如果發生剖析或強制錯誤，您可以在主控台上檢視錯誤，或將目的地指派給錯誤串流，並檢視目的地儲存區中的錯誤。
+ 字元資料的欄位長度足夠，且應用程式並未截斷字元資料。您可以檢查目的地存放區中的資料記錄，以確認應用程式資料未遭截斷。
### 測試程式碼變更
您需要具備一些應用程式的領域知識，才能測試對 SQL 代碼的變更。您必須判斷需要測試哪些輸出，以及正確的輸出應該是什麼。關於修改應用程式 SQL 程式碼時要驗證的潛在問題區域，請參閱[疑難排解 Amazon Kinesis Data Analytics for SQL 應用程式](troubleshooting.md)。