本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Managed Service for Apache Flink 故障診斷
下列主題可協助您針對 Amazon Managed Service for Apache Flink 可能遇到的問題進行疑難排解。
選擇適當的主題來檢閱解決方案。
**Topics**
+ [開發疑難排解](troubleshooting-development.md)
+ [執行期疑難排解](troubleshooting-runtime.md)
# 開發疑難排解
本節包含診斷和修正 Managed Service for Apache Flink 應用程式開發問題的相關資訊。
**Topics**
+ [系統復原最佳實務](troubleshooting-system-rollback.md)
+ [Hudi 組態最佳實務](troubleshooting-hudi.md)
+ [Apache Flink 火焰圖](troubleshooting-update-flamegraphs.md)
+ [EFO 連接器 1.15.2 的登入資料提供者問題](troubleshooting-credential-provider.md)
+ [應用程式使用不支援的 Kinesis 連接器](troubleshooting-unsupported-kinesis-connectors.md)
+ [編譯錯誤：「無法解析專案的相依性」](troubleshooting-compile.md)
+ [無效的選擇：「kinesisanalyticsv2」](troubleshooting-cli-update.md)
+ [UpdateApplication 動作不會重新載入應用程式程式碼](troubleshooting-update.md)
+ [S3 StreamingFileSink FileNotFoundExceptions](troubleshooting-s3sink.md)
+ [使用儲存點停止時的 FlinkKafkaConsumer 問題](troubleshooting-FlinkKafkaConsumer.md)
+ [FLINK 1.15 非同步接收器死鎖](troubleshooting-async-deadlock.md)
+ [在重新分片期間，Amazon Kinesis 資料串流來源處理順序不正確](troubleshooting-kinesis-data-streams-processing-out-of-order.md)
+ [即時向量內嵌藍圖常見問答集和疑難排解](troubleshooting-blueprints.md)
# 系統復原最佳實務
透過 Amazon Managed Service for Apache Flink 中的自動系統復原和操作可見性功能，您可以識別和解決應用程式的問題。
## 系統轉返
如果您的應用程式更新或擴展操作因客戶錯誤而失敗，例如程式碼錯誤或許可問題，如果您已選擇使用此功能，Amazon Managed Service for Apache Flink 會自動嘗試回復至先前的執行版本。如需詳細資訊，請參閱[為您的 Managed Service for Apache Flink 應用程式啟用系統復原](how-system-rollbacks.md)。如果此自動轉返失敗，或您尚未選擇加入或退出，您的應用程式將進入 `READY` 狀態。若要更新您的應用程式，請完成下列步驟： 檢查 Amazon Managed Service for Apache Flink 主控台或使用 `DescribeApplicationOperation` API 來查看操作失敗原因的錯誤描述。 對於完整的錯誤堆疊，請使用 [Cloudwatch 日誌](https://docs.aws.amazon.com/managed-flink/latest/java/logging.html)。 常見問題是許可不足、程式碼變更不相容或基礎設施設定錯誤。解決基礎問題。 使用 `UpdateApplicaton` API 重新部署新的應用程式版本。
## 手動轉返
如果應用程式未進行且長時間處於暫時性狀態，或者應用程式成功轉換為 `Running`，但您看到下游問題，例如在成功更新的 Flink 應用程式中處理錯誤，您可以使用 `RollbackApplication` API 手動將其轉返。
1. 呼叫 `RollbackApplication` - 這將還原至先前的執行版本，並還原先前的狀態。
1. 使用 `DescribeApplicationOperation` API 監控轉返操作。
1. 如果轉返失敗，請使用先前的系統轉返步驟。
## 操作可見性
`ListApplicationOperations` API 會顯示應用程式上所有客戶和系統操作的歷史記錄。
1. 從清單中取得失敗操作的 *operationId*。
1. 呼叫`DescribeApplicationOperation`並檢查狀態和*statusDescription*。
1. 如果操作失敗，描述會指向調查的潛在錯誤。
**常見的錯誤碼錯誤：**使用復原功能來還原至上次運作的版本。解決錯誤並重試更新。
**許可問題：**使用 `DescribeApplicationOperation` 查看所需的許可。更新應用程式許可並重試。
**Amazon Managed Service for Apache Flink 服務問題：**檢查 AWS Health 儀板表 或開啟支援案例。
# Hudi 組態最佳實務
若要在 Managed Service for Apache Flink 上執行 Hudi 連接器，我們建議進行下列組態變更。
停用 `hoodie.embed.timeline.server`
Flink 上的 Hudi 連接器會在 Flink 任務管理員 (JM) 上設定內嵌時間軸 (TM) 伺服器，以快取中繼資料，以在任務平行處理很高時改善效能。我們建議您在 Managed Service for Apache Flink 上停用此內嵌伺服器，因為我們停用 JM 和 TM 之間的非 Flink 通訊。
如果啟用此伺服器，Hudi 寫入會先嘗試連接到 JM 上的內嵌伺服器，然後回到從 Amazon S3 讀取中繼資料。這表示 Hudi 發生連線逾時，延遲 Hudi 寫入，並對 Managed Service for Apache Flink 造成效能影響。
# Apache Flink 火焰圖
火焰圖在 Managed Service for Apache Flink 版本支援的應用程式上預設為啟用。如果讓火焰圖保持開啟狀態，可能會影響應用程式效能，如 [Flink 文件](https://nightlies.apache.org/flink/flink-docs-release-1.15//docs/ops/debugging/flame_graphs/)中所述。
如果要為您的應用程式停用火焰圖，請建立一個案例，以請求將其為您的應用程式 ARN 停用。如需詳細資訊，請參閱 [AWS 支援中心](https://console.aws.amazon.com/support/home#/)。
# EFO 連接器 1.15.2 的登入資料提供者問題
Kinesis Data Streams EFO 連接器截止 1.15.2 版本都存在一個[已知問題](https://issues.apache.org/jira/browse/FLINK-29205)，其中的 `FlinkKinesisConsumer` 不遵守 `Credential Provider` 組態。由於該問題，有效組態被忽略，導致使用 `AUTO` 憑證提供者。使用 EFO 連接器跨帳戶存取 Kinesis 時，這可能會導致問題。
若要解決此錯誤，請使用 EFO 連接器 1.15.3 版或更新版本。
# 應用程式使用不支援的 Kinesis 連接器
Managed Service for Apache Flink 1.15 版或更新版本會在[應用程式使用不支援的 Kinesis Connector 版本 (1.15.2 版之前） 封裝至應用程式 JAR 或封存檔 (ZIP) 時，自動拒絕應用程式啟動或更新](https://docs.aws.amazon.com/managed-flink/latest/java/flink-1-15-2.html)。 JARs
## 拒絕錯誤
透過以下方式提交建立/更新應用程式的呼叫時，將看到以下錯誤：
```
An error occurred (InvalidArgumentException) when calling the CreateApplication operation: An unsupported Kinesis connector version has been detected in the application. Please update flink-connector-kinesis to any version equal to or newer than 1.15.2.
For more information refer to connector fix: https://issues.apache.org/jira/browse/FLINK-23528
```
## 要修復的步驟
+ 更新應用程式的 `flink-connector-kinesis` 相依性 。如果使用 Maven 作為專案的建置工具，請按照 [更新 Maven 相依性](#troubleshooting-unsupported-kinesis-connectors-update-maven-dependency) 操作。如果使用 Gradle，請按照 [更新 Gradle 相依性](#troubleshooting-unsupported-kinesis-connectors-update-gradle-dependency) 操作。
+ 重新封裝應用程式。
+ 上傳至 Amazon S3 儲存貯體。
+ 使用剛上傳到 Amazon S3 儲存貯體的修訂後應用程式重新提交建立/更新應用程式的請求。
+ 如果繼續看到相同的錯誤訊息，請重新檢查應用程式相依性。如果問題仍然存在，請建立一個支援票證。
### 更新 Maven 相依性
1. 開啟專案的 `pom.xml`。
1. 尋找專案的相依性。他們看起來如下所示：
```
...
...
org.apache.flink
flink-connector-kinesis
...
...
```
1. 將 `flink-connector-kinesis` 更新至 1.15.2 或更新版本。例如：
```
...
...
org.apache.flink
flink-connector-kinesis
1.15.2
...
...
```
### 更新 Gradle 相依性
1. 開啟專案的 `build.gradle` (或針對 Kotlin 應用程式的 `build.gradle.kts`)。
1. 尋找專案的相依性。他們看起來如下所示：
```
...
dependencies {
...
implementation("org.apache.flink:flink-connector-kinesis")
...
}
...
```
1. 將 `flink-connector-kinesis` 更新至 1.15.2 或更新版本。例如：
```
...
dependencies {
...
implementation("org.apache.flink:flink-connector-kinesis:1.15.2")
...
}
...
```
# 編譯錯誤：「無法解析專案的相依性」
若要編譯 Managed Service for Apache Flink 範例應用程式，必須先下載並編譯 Apache Flink Kinesis 連接器，並將其新增至本機 Maven 儲存庫。如果連接器尚未新增至儲存庫，則會出現如下編譯錯誤：
```
Could not resolve dependencies for project your project name: Failure to find org.apache.flink:flink-connector-kinesis_2.11:jar:1.8.2 in https://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced
```
若要解決此錯誤，必須從 [https://flink.apache.org/downloads.html](https://flink.apache.org/downloads.html) 為連接器下載 Apache Flink 來源程式碼 1.8.2 版本。如需如何下載、編譯和安裝 Apache Flink 來源程式碼的相關指示，請參閱[將 Apache Flink Kinesis Streams 連接器與先前的 Apache Flink 版本搭配使用](earlier.md#how-creating-apps-building-kinesis)。
# 無效的選擇：「kinesisanalyticsv2」
若要使用 Managed Service for Apache Flink API v2，需要最新版本的 AWS Command Line Interface (AWS CLI)。
如需有關升級 的資訊 AWS CLI，請參閱*AWS Command Line Interface 《 使用者指南*》中的[安裝 AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) 。
# UpdateApplication 動作不會重新載入應用程式程式碼
如果未指定 S3 物件版本，[UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html) 動作將不會以相同的檔案名稱重新載入應用程式程式碼。若要使用相同的檔案名稱重新載入應用程式程式碼，請在 S3 儲存貯體上啟用版本控制，然後使用 `ObjectVersionUpdate` 參數指定新的物件版本。如需在 S3 儲存貯體中啟用物件版本控制的詳細資訊，請參閱[啟用和停用物件版本控制](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-versioning.html)。
# S3 StreamingFileSink FileNotFoundExceptions
如果缺少由儲存點參照的進行中分段檔案，則從快照開始時，Managed Service for Apache Flink 應用程式可能會遇到進行中的分段檔案 `FileNotFoundException`。發生此失敗模式時，Managed Service for Apache Flink 應用程式的運算子狀態通常不可復原，必須在不使用快照的情況下使用 `SKIP_RESTORE_FROM_SNAPSHOT` 重新啟動。請參閱以下範例 stacktrace：
```
java.io.FileNotFoundException: No such file or directory: s3://amzn-s3-demo-bucket/pathj/INSERT/2023/4/19/7/_part-2-1234_tmp_12345678-1234-1234-1234-123456789012
at org.apache.hadoop.fs.s3a.S3AFileSystem.s3GetFileStatus(S3AFileSystem.java:2231)
at org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2149)
at org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2088)
at org.apache.hadoop.fs.s3a.S3AFileSystem.open(S3AFileSystem.java:699)
at org.apache.hadoop.fs.FileSystem.open(FileSystem.java:950)
at org.apache.flink.fs.s3hadoop.HadoopS3AccessHelper.getObject(HadoopS3AccessHelper.java:98)
at org.apache.flink.fs.s3.common.writer.S3RecoverableMultipartUploadFactory.recoverInProgressPart(S3RecoverableMultipartUploadFactory.java:97)
...
```
Flink 會將記錄`StreamingFileSink`寫入檔案系統支援[的檔案系統](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/deployment/filesystems/overview/)。鑒於傳入串流可以無限制，資料會組織成有限大小的分段檔案，並在寫入資料時新增檔案。分段生命週期和輪替政策可決定分段檔案的時間、大小和命名。
在檢查點和儲存點 (快照) 期間，所有待處理檔案都會重新命名並遞交。但是，進行中的分段檔案不會遞交而是重新命名，且其參考會保留在還原作業時要使用的檢查點或儲存點中繼資料內。這些進行中的分段檔案最終會輪替為「待處理」狀態，由後續檢查點或儲存點重新命名或遞交。
以下是遺失進行中分段檔案的根本原因和緩解措施：
+ 用於啟動 Managed Service for Apache Flink 應用程式的快照過時 — 只有停止或更新應用程式時所拍攝的最新系統快照可用來啟動使用 Amazon S3 StreamingFileSink 的 Managed Service for Apache Flink 應用程式。若要避免這類失敗，請使用最新的系統快照。
+ 例如，當您選擇使用 `CreateSnapshot` 建立的快照，而不是在停止或更新期間系統觸發的快照時，就會發生這種情況。較舊快照的儲存點會保留對進行中分段檔案的過期參考，而該檔案已由後續檢查點或儲存點重新命名並遞交。
+ 當選取上午系統快照觸發自非最新的停止/更新事件時，也可能發生這種情況。其中一個範例是已停用系統快照但已設定 `RESTORE_FROM_LATEST_SNAPSHOT` 的應用程式。一般而言，使用 Amazon S3 StreamingFileSink 的 Managed Service for Apache Flink 應用程式應始終啟用系統快照並設定 `RESTORE_FROM_LATEST_SNAPSHOT`。
+ 移除進行中的分段檔案 — 由於進行中的分段檔案位於 S3 儲存貯體中，因此可以由其他可存取該儲存貯體的元件或參與者移除。
+ 當已停止應用程式太長時間，且 [S3 儲存貯體 MultiPartUpLoad](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpu-abort-incomplete-mpu-lifecycle-config.html) 生命週期政策移除了應用程式儲存點所參考的進行中部分檔案時，就可能會發生這種情況。若要避免此類失敗，請確保 S3 儲存貯體 MPU 生命週期政策針對您的使用案例涵蓋了足夠長的期間。
+ 當進行中的分段檔案已手動移除或由系統的其他元件移除時，也會發生這種情況。若要避免此類失敗，請確定進行中的分段檔案不會被其他參與者或元件移除。
+ 在儲存點之後觸發自動檢查點的競爭情形 — 這會影響 Managed Service for Apache Flink 1.13 及以下版本。Managed Service for Apache Flink 1.15 版已修正此問題。將您的應用程式遷移至最新版本的 Managed Service for Apache Flink，以防止重複。我們還建議您從 StreamingFileSink 移轉至 [FileSink](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/connectors/datastream/filesystem/#file-sink)。
+ 應用程式停止或更新後，Managed Service for Apache Flink 會觸發儲存點，並透過兩個步驟停止應用程式。如果在這兩個步驟之間觸發了自動檢查點，則儲存點將無法使用，因為其進行中分段檔案將會重新命名並可能遞交。
# 使用儲存點停止時的 FlinkKafkaConsumer 問題
使用舊版 FlinkKafkaConsumer 時，如果您啟用了系統快照，應用程式可能會卡在 UPDATING、STOPPING 或 SCALING 狀態。此[問題](https://issues.apache.org/jira/browse/FLINK-28758)沒有已發佈的修正程式可用，因此建議您升級至新的 [KafkaSource](https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/datastream/kafka/#kafka-source) 以緩解此問題。
如果您正在啟用快照的情況下使用 `FlinkKafkaConsumer`，Flink 作業可能會使用儲存點 API 請求處理停止，`FlinkKafkaConsumer` 可能會失敗並報告執行期錯誤 `ClosedException`。在這些情況下，Flink 應用程式會卡住，並顯示為失敗的檢查點。
# FLINK 1.15 非同步接收器死鎖
實作 AsyncSink 介面的 Apache Flink AWS 連接器存在[已知問題](https://issues.apache.org/jira/browse/FLINK-32230)。這會影響使用具有下列連接器的 Flink 1.15 的應用程式：
+ 對於 Java 應用程式：
+ KinesisStreamsSink – `org.apache.flink:flink-connector-kinesis`
+ KinesisStreamsSink – `org.apache.flink:flink-connector-aws-kinesis-streams`
+ KinesisFirehoseSink – `org.apache.flink:flink-connector-aws-kinesis-firehose`
+ DynamoDbSink – `org.apache.flink:flink-connector-dynamodb`
+ 快速 SQL/資料表 API/Python 應用程式：
+ kinesis – `org.apache.flink:flink-sql-connector-kinesis`
+ kinesis – `org.apache.flink:flink-sql-connector-aws-kinesis-streams`
+ firehose – `org.apache.flink:flink-sql-connector-aws-kinesis-firehose`
+ dynamodb – `org.apache.flink:flink-sql-connector-dynamodb`
受影響的應用程式會出現下列徵狀：
+ FLINK 作業處於 `RUNNING` 狀態，但未在處理資料；
+ 沒有作業重新啟動;
+ 檢查點逾時。
問題是由 AWS SDK 中的[錯誤](https://github.com/aws/aws-sdk-java-v2/issues/4354)所造成，導致在使用非同步 HTTP 用戶端時不會向發起人顯示特定錯誤。這會導致接收器在檢查點排清操作期間無限期等待「進行中請求」完成。
從 **2.20.144** 版開始，已在 AWS SDK 中修正此問題。
以下是如何更新受影響連接器以在應用程式中使用新版本 AWS SDK 的指示：
**Topics**
+ [更新 Java 應用程式](troubleshooting-async-deadlock-update-java-apps.md)
+ [更新 Python 應用程式](troubleshooting-async-deadlock-update-python-apps.md)
# 更新 Java 應用程式
請依照下列程序更新 Java 應用程式：
## flink-connector-kinesis
如果應用程式使用 `flink-connector-kinesis`：
Kinesis 連接器使用著色將一些相依性，包括 AWS SDK 封裝到連接器 jar 中。若要更新 AWS SDK 版本，請使用下列程序取代這些著色類別：
------
#### [ Maven ]
1. 新增 Kinesis 連接器和必要的 AWS SDK 模組做為專案相依性。
1. 設定 `maven-shade-plugin`：
1. 新增篩選條件，以在複製 Kinesis 連接器 jar 的內容時排除著色 AWS SDK 類別。
1. 新增重新定位規則，將更新的 AWS SDK 類別移至 Kinesis 連接器預期的套件。
**pom.xml**
```
...
...
org.apache.flink
flink-connector-kinesis
1.15.4
software.amazon.awssdk
kinesis
2.20.144
software.amazon.awssdk
netty-nio-client
2.20.144
software.amazon.awssdk
sts
2.20.144
...
...
...
...
org.apache.maven.plugins
maven-shade-plugin
3.1.1
package
shade
...
...
org.apache.flink:flink-connector-kinesis
org/apache/flink/kinesis/shaded/software/amazon/awssdk/**
org/apache/flink/kinesis/shaded/org/reactivestreams/**
org/apache/flink/kinesis/shaded/io/netty/**
org/apache/flink/kinesis/shaded/com/typesafe/netty/**
...
...
software.amazon.awssdk
org.apache.flink.kinesis.shaded.software.amazon.awssdk
org.reactivestreams
org.apache.flink.kinesis.shaded.org.reactivestreams
io.netty
org.apache.flink.kinesis.shaded.io.netty
com.typesafe.netty
org.apache.flink.kinesis.shaded.com.typesafe.netty
...
...
...
...
```
------
#### [ Gradle ]
1. 新增 Kinesis 連接器和必要的 AWS SDK 模組做為專案相依性。
1. 調整 shadowJar 組態：
1. 複製 Kinesis 連接器 jar 的內容時，排除著色 AWS SDK 類別。
1. 將更新的 AWS SDK 類別重新定位至 Kinesis 連接器預期的套件。
**build.gradle**
```
...
dependencies {
...
flinkShadowJar("org.apache.flink:flink-connector-kinesis:1.15.4")
flinkShadowJar("software.amazon.awssdk:kinesis:2.20.144")
flinkShadowJar("software.amazon.awssdk:sts:2.20.144")
flinkShadowJar("software.amazon.awssdk:netty-nio-client:2.20.144")
...
}
...
shadowJar {
configurations = [project.configurations.flinkShadowJar]
exclude("software/amazon/kinesis/shaded/software/amazon/awssdk/**/*")
exclude("org/apache/flink/kinesis/shaded/org/reactivestreams/**/*.class")
exclude("org/apache/flink/kinesis/shaded/io/netty/**/*.class")
exclude("org/apache/flink/kinesis/shaded/com/typesafe/netty/**/*.class")
relocate("software.amazon.awssdk", "org.apache.flink.kinesis.shaded.software.amazon.awssdk")
relocate("org.reactivestreams", "org.apache.flink.kinesis.shaded.org.reactivestreams")
relocate("io.netty", "org.apache.flink.kinesis.shaded.io.netty")
relocate("com.typesafe.netty", "org.apache.flink.kinesis.shaded.com.typesafe.netty")
}
...
```
------
## 其他受影響連接器
若應用程式使用其他受影響的連接器：
為了更新 AWS SDK 版本，應在專案建置組態中強制執行 SDK 版本。
------
#### [ Maven ]
將 AWS SDK 物料清單 (BOM) 新增至 `pom.xml` 檔案的相依性管理區段，以強制執行專案的 SDK 版本。
**pom.xml**
```
...
...
software.amazon.awssdk
bom
2.20.144
import
pom
...
...
```
------
#### [ Gradle ]
在 AWS SDK 物料清單 (BOM) 上新增平台相依性，以強制執行專案的 SDK 版本。這需要 Gradle 5.0 或更新版本：
**build.gradle**
```
...
dependencies {
...
flinkShadowJar(platform("software.amazon.awssdk:bom:2.20.144"))
...
}
...
```
------
# 更新 Python 應用程式
Python 應用程式可以透過 2 種不同的方式使用連接器：將連接器和其他 Java 相依性作封裝為單個 uber-jar 的一部分，或直接使用連接器 jar。若要修正受非同步接收器死鎖影響的應用程式：
+ 如果應用程式使用 uber jar，請依照 [更新 Java 應用程式](troubleshooting-async-deadlock-update-java-apps.md) 的指示操作。
+ 若要從來源重建連接器 jar，請使用下列步驟：
**從來源建置連接器：**
先決條件，類似於 Flink [建置需求](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/flinkdev/building/#build-flink)：
+ Java 11
+ Maven 3.2.5
## flink-sql-connector-kinesis
1. 下載 Flink 1.15.4 的來源程式碼：
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. 解壓縮來源程式碼：
```
tar -xvf flink-1.15.4-src.tgz
```
1. 導覽至 Kinesis 連接器目錄
```
cd flink-1.15.4/flink-connectors/flink-connector-kinesis/
```
1. 編譯並安裝連接器 jar，指定所需的 AWS SDK 版本。為了加快建置，使用 `-DskipTests` 跳過測試執行，並使用 `-Dfast` 跳過其他來源程式碼檢查：
```
mvn clean install -DskipTests -Dfast -Daws.sdkv2.version=2.20.144
```
1. 導覽至 Kinesis 連接器目錄
```
cd ../flink-sql-connector-kinesis
```
1. 編譯並安裝 sql 連接器 jar：
```
mvn clean install -DskipTests -Dfast
```
1. 產生的 jar 將在以下位置提供：
```
target/flink-sql-connector-kinesis-1.15.4.jar
```
## flink-sql-connector-aws-kinesis-streams
1. 下載 Flink 1.15.4 的來源程式碼：
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. 解壓縮來源程式碼：
```
tar -xvf flink-1.15.4-src.tgz
```
1. 導覽至 Kinesis 連接器目錄
```
cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-streams/
```
1. 編譯並安裝連接器 jar，指定所需的 AWS SDK 版本。為了加快建置，使用 `-DskipTests` 跳過測試執行，並使用 `-Dfast` 跳過其他來源程式碼檢查：
```
mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144
```
1. 導覽至 Kinesis 連接器目錄
```
cd ../flink-sql-connector-aws-kinesis-streams
```
1. 編譯並安裝 sql 連接器 jar：
```
mvn clean install -DskipTests -Dfast
```
1. 產生的 jar 將在以下位置提供：
```
target/flink-sql-connector-aws-kinesis-streams-1.15.4.jar
```
## flink-sql-connector-aws-kinesis-firehose
1. 下載 Flink 1.15.4 的來源程式碼：
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. 解壓縮來源程式碼：
```
tar -xvf flink-1.15.4-src.tgz
```
1. 導覽至連接器目錄
```
cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-firehose/
```
1. 編譯並安裝連接器 jar，指定所需的 AWS SDK 版本。為了加快建置，使用 `-DskipTests` 跳過測試執行，並使用 `-Dfast` 跳過其他來源程式碼檢查：
```
mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144
```
1. 導覽至 sql 連接器目錄
```
cd ../flink-sql-connector-aws-kinesis-firehose
```
1. 編譯並安裝 sql 連接器 jar：
```
mvn clean install -DskipTests -Dfast
```
1. 產生的 jar 將在以下位置提供：
```
target/flink-sql-connector-aws-kinesis-firehose-1.15.4.jar
```
## flink-sql-connector-dynamodb
1. 下載 Flink 1.15.4 的來源程式碼：
```
wget https://archive.apache.org/dist/flink/flink-connector-aws-3.0.0/flink-connector-aws-3.0.0-src.tgz
```
1. 解壓縮來源程式碼：
```
tar -xvf flink-connector-aws-3.0.0-src.tgz
```
1. 導覽至連接器目錄
```
cd flink-connector-aws-3.0.0
```
1. 編譯並安裝連接器 jar，指定所需的 AWS SDK 版本。為了加快建置，使用 `-DskipTests` 跳過測試執行，並使用 `-Dfast` 跳過其他來源程式碼檢查：
```
mvn clean install -DskipTests -Dfast -Dflink.version=1.15.4 -Daws.sdk.version=2.20.144
```
1. 產生的 jar 將在以下位置提供：
```
flink-sql-connector-dynamodb/target/flink-sql-connector-dynamodb-3.0.0.jar
```
# 在重新分片期間，Amazon Kinesis 資料串流來源處理順序不正確
目前的 FlinkKinesisConsumer 實作無法在 Kinesis 碎片之間提供強有力的排序保證。這可能會導致 Kinesis 串流重新分片期間出現不按順序處理的情況，特別是對於遇到處理延遲的 Flink 應用程式而言。在某些情況下，例如根據事件時間的 Windows 運算子，事件可能會因為產生的延遲而被捨棄。
![\[Diagram showing shards and shard consumers with time progression and trim horizon.\]](http://docs.aws.amazon.com/zh_tw/managed-flink/latest/java/images/flink-ts.png)
這是開放原始碼 Flink 中的[已知問題](https://issues.apache.org/jira/browse/FLINK-6349)。在提供連接器修正之前，請確保您的 Flink 應用程式在重新分割期間不會落後於 Kinesis 資料串流。透過確保 Flink 應用程式可以容忍處理延遲，您可以最大程度地減少錯誤處理的影響和資料遗失的風險。
# 即時向量內嵌藍圖常見問答集和疑難排解
檢閱下列常見問答集和疑難排解章節，以疑難排解即時向量內嵌藍圖問題。如需即時向量內嵌藍圖的詳細資訊，請參閱[即時向量內嵌藍圖](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html)。
如需一般 Managed Service for Apache Flink 應用程式故障診斷，請參閱 https：//[https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html)。
**Topics**
+ [即時向量內嵌藍圖 - 常見問答集](troubleshooting-blueprints-FAQ.md)
+ [即時向量內嵌藍圖 - 疑難排解](troubleshooting-blueprints-TS.md)
# 即時向量內嵌藍圖 - 常見問答集
檢閱下列有關即時向量內嵌藍圖的常見問答集。如需即時向量內嵌藍圖的詳細資訊，請參閱[即時向量內嵌藍圖](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html)。
**Topics**
+ [此藍圖會建立哪些 AWS 資源？](#troubleshooting-blueprints-1)
+ [AWS CloudFormation 堆疊部署完成後，我的動作是什麼？](#troubleshooting-blueprints-2)
+ [來源 Amazon MSK 主題 (Amazon MSK) 中的資料結構應該是什麼？](#troubleshooting-blueprints-3)
+ [我可以指定要內嵌的訊息部分嗎？](#troubleshooting-blueprints-4)
+ [我可以從多個 Amazon MSK 主題讀取資料嗎？](#troubleshooting-blueprints-5)
+ [我可以使用 regex 來設定 Amazon MSK 主題名稱嗎？](#troubleshooting-blueprints-6)
+ [可以從 Amazon MSK 主題讀取的訊息大小上限是多少？](#troubleshooting-blueprints-7)
+ [支援哪種類型的 OpenSearch？](#troubleshooting-blueprints-8)
+ [為什麼我需要在 OpenSearch Serverless colelction 中使用向量搜尋集合、向量索引和新增向量欄位？](#troubleshooting-blueprints-9)
+ [我應該將什麼設定為向量欄位的維度？](#troubleshooting-blueprints-10)
+ [在設定的 OpenSearch 索引中，輸出看起來像什麼？](#troubleshooting-blueprints-11)
+ [我可以指定中繼資料欄位以新增至儲存在 OpenSearch 索引中的文件嗎？](#troubleshooting-blueprints-12)
+ [我應該預期 OpenSearch 索引中重複的項目嗎？](#troubleshooting-blueprints-13)
+ [我可以將資料傳送至多個 OpenSearch 索引嗎？](#troubleshooting-blueprints-14)
+ [我可以在單一 中部署多個即時向量內嵌應用程式 AWS 帳戶嗎？](#troubleshooting-blueprints-15)
+ [多個即時向量內嵌應用程式是否可以使用相同的資料來源或接收器？](#troubleshooting-blueprints-16)
+ [應用程式是否支援跨帳戶連線？](#troubleshooting-blueprints-17)
+ [應用程式是否支援跨區域連線？](#troubleshooting-blueprints-18)
+ [我的 Amazon MSK 叢集和 OpenSearch 集合是否可以位於不同的 VPCs或子網路中？](#troubleshooting-blueprints-19)
+ [應用程式支援哪些內嵌模型？](#troubleshooting-blueprints-20)
+ [我可以根據工作負載微調應用程式的效能嗎？](#troubleshooting-blueprints-21)
+ [支援哪些 Amazon MSK 身分驗證類型？](#troubleshooting-blueprints-22)
+ [什麼是 `sink.os.bulkFlushIntervalMillis` 以及如何設定它？](#troubleshooting-blueprints-23)
+ [當我部署 Managed Service for Apache Flink 應用程式時，會從 Amazon MSK 主題的哪個時間點開始讀取訊息？](#troubleshooting-blueprints-24)
+ [如何使用 `source.msk.starting.offset`？](#troubleshooting-blueprints-25)
+ [支援哪些區塊策略？](#troubleshooting-blueprints-26)
+ [如何讀取向量資料存放區中的記錄？](#troubleshooting-blueprints-27)
+ [哪裡可以找到原始程式碼的新更新？](#troubleshooting-blueprints-28)
+ [我可以變更 AWS CloudFormation 範本並更新 Managed Service for Apache Flink 應用程式嗎？](#troubleshooting-blueprints-29)
+ [會代表我 AWS 監控和維護應用程式嗎？](#troubleshooting-blueprints-30)
+ [這個應用程式是否會將我的資料移動到我的 之外 AWS 帳戶？](#troubleshooting-blueprints-31)
## 此藍圖會建立哪些 AWS 資源？
若要尋找您帳戶中部署的資源，請導覽至 AWS CloudFormation 主控台，並識別以您為 Managed Service for Apache Flink 應用程式提供的名稱開頭的堆疊名稱。選擇**資源**索引標籤，以檢查在堆疊中建立的資源。以下是堆疊建立的關鍵資源：
+ 即時向量內嵌 Managed Service for Apache Flink 應用程式
+ Amazon S3 儲存貯體，用於保留即時向量內嵌應用程式的原始程式碼
+ 用於儲存日誌的 CloudWatch 日誌群組和日誌串流
+ 用於擷取和建立資源的 Lambda 函數
+ Lambdas、Managed Service for Apache Flink 應用程式以及存取 Amazon Bedrock 和 Amazon OpenSearch Service 的 IAM 角色和政策
+ Amazon OpenSearch Service 的資料存取政策
+ 用於存取 Amazon Bedrock 和 Amazon OpenSearch Service 的 VPC 端點
## AWS CloudFormation 堆疊部署完成後，我的動作是什麼？
AWS CloudFormation 堆疊部署完成後，請存取 Managed Service for Apache Flink 主控台，並尋找您的藍圖 Managed Service for Apache Flink 應用程式。選擇**設定**索引標籤，並確認所有執行期屬性都已正確設定。它們可能會溢位到下一頁。當您對設定有信心時，請選擇**執行**。應用程式將開始從您的主題擷取訊息。
若要檢查是否有新版本，請參閱 https：//[https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases)。
## 來源 Amazon MSK 主題 (Amazon MSK) 中的資料結構應該是什麼？
我們目前支援結構化和非結構化來源資料。
+ 非結構化資料在 `STRING`中由 表示`source.msk.data.type`。資料會依原樣從傳入訊息讀取。
+ 我們目前支援結構化 JSON 資料，在 `JSON`中由 表示`source.msk.data.type`。資料必須一律採用 JSON 格式。如果應用程式收到格式不正確的 JSON，應用程式將會失敗。
+ 使用 JSON 做為來源資料類型時，請確定所有來源主題中的每則訊息都是有效的 JSON。如果您訂閱的一或多個主題不包含具有此設定的 JSON 物件，應用程式將會失敗。如果一個或多個主題混合了結構化和非結構化資料，建議您在 Managed Service for Apache Flink 應用程式中將來源資料設定為非結構化。
## 我可以指定要內嵌的訊息部分嗎？
+ 對於 `source.msk.data.type`為 的非結構化輸入資料`STRING`，應用程式將一律嵌入整個訊息，並將整個訊息存放在設定的 OpenSearch 索引中。
+ 對於 `source.msk.data.type`為 的結構化輸入資料`JSON`，您可以設定 `embed.input.config.json.fieldsToEmbed`來指定應該在 JSON 物件中選取哪個欄位以進行內嵌。這僅適用於最上層 JSON 欄位，不適用於巢狀 JSONs 和包含 JSON 陣列的訊息。使用 .\$1 內嵌整個 JSON。
## 我可以從多個 Amazon MSK 主題讀取資料嗎？
可以，您可以使用此應用程式從多個 Amazon MSK 主題讀取資料。所有主題的資料都必須是相同類型 (STRING 或 JSON)，否則可能會導致應用程式失敗。來自所有主題的資料一律存放在單一 OpenSearch 索引中。
## 我可以使用 regex 來設定 Amazon MSK 主題名稱嗎？
`source.msk.topic.names` 不支援 regex 的清單。我們支援以逗號分隔的主題名稱清單或 regex `.*` 來包含所有主題。
## 可以從 Amazon MSK 主題讀取的訊息大小上限是多少？
可處理的訊息大小上限受限於目前設定為 25，000，000 的 Amazon Bedrock InvokeModel 內文限制。如需詳細資訊，請參閱 [InvokeModel](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html#API_runtime_InvokeModel_RequestBody)。
## 支援哪種類型的 OpenSearch？
我們同時支援 OpenSearch 網域和集合。如果您使用的是 OpenSearch 集合，請務必使用向量集合並建立向量索引以用於此應用程式。這可讓您使用 OpenSearch 向量資料庫功能來查詢資料。若要進一步了解，請參閱[Amazon OpenSearch Service 的向量資料庫功能說明](https://aws.amazon.com/blogs/big-data/amazon-opensearch-services-vector-database-capabilities-explained/)。
## 為什麼我需要在 OpenSearch Serverless colelction 中使用向量搜尋集合、向量索引和新增向量欄位？
OpenSearch Serverless 中的*向量搜尋*集合類型提供可擴展且高效能的相似性搜尋功能。它簡化了建置現代機器學習 (ML) 增強型搜尋體驗和生成式人工智慧 (AI) 應用程式。如需詳細資訊，請參閱[使用向量搜尋集合](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html?icmpid=docs_console_unmapped)。
## 我應該將什麼設定為向量欄位的維度？
根據您要使用的內嵌模型，設定向量欄位的維度。請參閱下表，並從個別文件中確認這些值。
**向量欄位維度**
| Amazon Bedrock 向量內嵌模型名稱 | 模型提供的輸出維度支援 |
| --- | --- |
| Amazon Titan 文字內嵌 V1 | 1,536 |
| Amazon Titan 文本嵌入 V2 | 1，024 （預設）、384、256 |
| Amazon Titan Multimodal Embeddings G1 | 1，024 （預設）、384、256 |
| Cohere Embed 英文 | 1,024 |
| Cohere Embed 多語言 | 1,024 |
## 在設定的 OpenSearch 索引中，輸出看起來像什麼？
OpenSearch 索引中的每個文件都包含下列欄位：
+ **original\$1data**：用於產生內嵌的資料。對於 STRING 類型，它是整個訊息。對於 JSON 物件，它是用於內嵌的 JSON 物件。它可以是訊息中的整個 JSON，或 JSON 中的指定欄位。例如，如果已選取要從傳入訊息內嵌的名稱，則輸出會如下所示：
```
"original_data": "{\"name\":\"John Doe\"}"
```
+ **embedded\$1data**：Amazon Bedrock 產生的內嵌向量浮點數陣列
+ **日期**：文件存放在 OpenSearch 中的 UTC 時間戳記
## 我可以指定中繼資料欄位以新增至儲存在 OpenSearch 索引中的文件嗎？
否，目前我們不支援將其他欄位新增至儲存在 OpenSearch 索引中的最終文件。
## 我應該預期 OpenSearch 索引中重複的項目嗎？
根據您設定應用程式的方式，您可能會在索引中看到重複的訊息。其中一個常見原因是應用程式重新啟動。根據預設，應用程式會設定為從來源主題中最早的訊息開始讀取。當您變更組態時，應用程式會重新啟動，並再次處理主題中的所有訊息。若要避免重新處理，請參閱有關如何使用 source.msk.starting.offset 的文件，並正確設定應用程式的起始位移。
## 我可以將資料傳送至多個 OpenSearch 索引嗎？
否，應用程式支援將資料儲存到單一 OpenSearch 索引。若要將向量化輸出設定為多個索引，您必須部署個別的 Managed Service for Apache Flink 應用程式。
## 我可以在單一 中部署多個即時向量內嵌應用程式 AWS 帳戶嗎？
可以， AWS 帳戶 如果每個應用程式都有唯一的名稱，您可以在單一 中部署多個即時向量內嵌 Managed Service for Apache Flink 應用程式。
## 多個即時向量內嵌應用程式是否可以使用相同的資料來源或接收器？
可以，您可以建立多個即時向量內嵌 Managed Service for Apache Flink 應用程式 （從相同主題讀取資料），或將資料儲存在相同索引中。
## 應用程式是否支援跨帳戶連線？
否，若要讓應用程式成功執行，Amazon MSK 叢集和 OpenSearch 集合必須位於您嘗試設定 Managed Service for Apache Flink 應用程式的相同 AWS 帳戶 位置。
## 應用程式是否支援跨區域連線？
否，應用程式只允許您在 Managed Service for Apache Flink 應用程式的相同區域中，使用 Amazon MSK 叢集和 OpenSearch 集合部署 Managed Service for Apache Flink 應用程式。
## 我的 Amazon MSK 叢集和 OpenSearch 集合是否可以位於不同的 VPCs或子網路中？
是，我們支援不同 VPCs 和子網路中的 Amazon MSK 叢集和 OpenSearch 集合，只要它們位於相同位置即可 AWS 帳戶。請參閱 （一般 MSF 疑難排解） 以確保您的設定正確。
## 應用程式支援哪些內嵌模型？
目前，應用程式支援 Bedrock 支援的所有模型。其中包含：
+ Amazon Titan Embeddings G1 - Text
+ Amazon Titan 文本嵌入 V2
+ Amazon Titan Multimodal Embeddings G1
+ Cohere Embed 英文
+ Cohere Embed 多語言
## 我可以根據工作負載微調應用程式的效能嗎？
是。應用程式輸送量取決於多種因素，所有因素都可以由客戶控制：
1. **AWS MSF KPUs**：以預設平行處理係數 2 和每個 KPU 1 的平行處理來部署應用程式，並開啟自動擴展。不過，我們建議您根據您的工作負載設定 Managed Service for Apache Flink 應用程式的擴展。如需詳細資訊，請參閱[檢閱 Managed Service for Apache Flink 應用程式資源](https://docs.aws.amazon.com/managed-flink/latest/java/how-resources.html)。
1. **Amazon Bedrock**：根據選取的 Amazon Bedrock 隨需模型，可能會套用不同的配額。檢閱 Bedrock 中的服務配額，以查看服務能夠處理的工作負載。如需詳細資訊，請參閱 [Amazon Bedrock 的配額](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html)。
1. **Amazon OpenSearch Service**：此外，在某些情況下，您可能會注意到 OpenSearch 是管道中的瓶頸。如需擴展資訊，請參閱 OpenSearch 擴展[規模調整 Amazon OpenSearch Service 網域](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/sizing-domains.html)。
## 支援哪些 Amazon MSK 身分驗證類型？
我們僅支援 IAM MSK 身分驗證類型。
## 什麼是 `sink.os.bulkFlushIntervalMillis` 以及如何設定它？
將資料傳送至 Amazon OpenSearch Service 時，大量排清間隔是執行大量請求的間隔，無論動作數目或請求大小為何。預設值設定為 1 毫秒。
設定排清間隔有助於確保資料及時編製索引，如果設定過低，也可能會導致額外負荷增加。考慮您的使用案例，以及在選擇排清間隔時及時編製索引的重要性。
## 當我部署 Managed Service for Apache Flink 應用程式時，會從 Amazon MSK 主題的哪個時間點開始讀取訊息？
應用程式將以應用程式執行時間`source.msk.starting.offset`組態中組態設定所指定的位移，開始從 Amazon MSK 主題讀取訊息。如果 `source.msk.starting.offset` 未明確設定，應用程式的預設行為是從主題中最早的可用訊息開始讀取。
## 如何使用 `source.msk.starting.offset`？
根據所需的行為，將 明確設為`ource.msk.starting.offset`下列其中一個值：
+ EARLIEST：預設設定，從分割區中最舊的位移讀取。這是一個不錯的選擇，特別是在以下情況：
+ 您已建立新的 Amazon MSK 主題和取用者應用程式。
+ 您需要重播資料，才能建置或重建狀態。這與實作事件來源模式或初始化需要完整檢視資料歷史記錄的新服務相關。
+ LATEST：Managed Service for Apache Flink 應用程式會從分割區結尾讀取訊息。如果您只關心正在產生的新訊息，而且不需要處理歷史資料，建議您使用此選項。在此設定中，消費者會忽略現有的訊息，並只讀取上游生產者發佈的新訊息。
+ COMMITTED：Managed Service for Apache Flink 應用程式將從耗用群組的遞交偏移開始耗用訊息。如果遞交的位移不存在，則會使用 EARLIEST 重設策略。
## 支援哪些區塊策略？
我們使用 [langchain](https://js.langchain.com/v0.1/docs/get_started/introduction/) 程式庫來區塊輸入。只有在輸入的長度大於選擇的 時，才會套用區塊。 `maxSegmentSizeInChars`我們支援以下五種區塊類型：
+ `SPLIT_BY_CHARACTER`：將盡可能多的字元放入每個區塊，其中每個區塊的長度不大於 maxSegmentSizeInChars。不在乎空格，因此可以截斷單字。
+ `SPLIT_BY_WORD`：將尋找要區塊的空格字元。沒有任何單字被截斷。
+ `SPLIT_BY_SENTENCE`：句子界限是使用 Apache OpenNLP 程式庫搭配英文句子模型進行偵測。
+ `SPLIT_BY_LINE`： 會尋找要區塊的新行字元。
+ `SPLIT_BY_PARAGRAPH`：將尋找要區塊的連續新行字元。
分割策略會根據上述順序回復，而較大的區塊策略如 `SPLIT_BY_PARAGRAPH` 會回復為 `SPLIT_BY_CHARACTER`。例如，使用 時`SPLIT_BY_LINE`，如果某行太長，則該行將依句子子區塊化，其中每個區塊將盡可能放入任意數量的句子中。如果有任何句子太長，則會在單字層級將其區塊化。如果單字太長，則會依字元分割。
## 如何讀取向量資料存放區中的記錄？
1. 當 `source.msk.data.type`為 時 `STRING`
+ **original\$1data**：來自 Amazon MSK 訊息的整個原始字串。
+ **embedded\$1data**：`chunk_data`如果不是空的 （套用區塊），則從 建立內嵌向量，如果未套用區塊，`original_data`則從 建立內嵌向量。
+ **chunk\$1data**：只有在原始資料被區塊化時才會出現。包含用於在 中建立內嵌的原始訊息區塊`embedded_data`。
1. 當 `source.msk.data.type`為 時 `JSON`
+ **original\$1data**：套用 JSON 金鑰篩選*後*，來自 Amazon MSK 訊息的整個原始 JSON。
+ **embedded\$1data**：`chunk_data`如果不是空的 （套用區塊），則從 建立內嵌向量，如果未套用區塊，`original_data`則從 建立內嵌向量。
+ **chunk\$1key**：只有在原始資料被區塊化時才會出現。包含區塊來自 的 JSON 金鑰`original_data`。例如，它看起來像 `jsonKey1.nestedJsonKeyA` 範例中的巢狀金鑰或*中繼資料*`original_data`。
+ **chunk\$1data**：只有在原始資料被區塊化時才存在。包含用於在 中建立內嵌的原始訊息區塊`embedded_data`。
可以，您可以使用此應用程式從多個 Amazon MSK 主題讀取資料。來自所有主題的資料必須屬於相同類型 (STRING 或 JSON)，否則可能會導致應用程式失敗。來自所有主題的資料一律存放在單一 OpenSearch 索引中。
## 哪裡可以找到原始程式碼的新更新？
前往 https：//[https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases)。
## 我可以變更 AWS CloudFormation 範本並更新 Managed Service for Apache Flink 應用程式嗎？
否，變更 AWS CloudFormation 範本並不會更新 Managed Service for Apache Flink 應用程式。中的任何新變更都 AWS CloudFormation 意味著需要部署新的堆疊。
## 會代表我 AWS 監控和維護應用程式嗎？
否， AWS 不會代表您監控、擴展、更新或修補此應用程式。
## 這個應用程式是否會將我的資料移動到我的 之外 AWS 帳戶？
Managed Service for Apache Flink 應用程式讀取和儲存的所有資料都會保留在您的 中 AWS 帳戶 ，絕不會離開您的帳戶。
# 即時向量內嵌藍圖 - 疑難排解
檢閱下列有關即時向量內嵌藍圖的疑難排解主題。如需即時向量內嵌藍圖的詳細資訊，請參閱[即時向量內嵌藍圖](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html)。
**Topics**
+ [My CloudFormation 堆疊部署失敗或已復原。我可以做什麼來修正此問題？](#troubleshooting-blueprints-deployment)
+ [我不希望我的應用程式開始從 Amazon MSK 主題開頭讀取訊息。我要怎麼做？](#troubleshooting-blueprints-beginning)
+ [如何知道我的 Managed Service for Apache Flink 應用程式是否存在問題，以及如何對其進行偵錯？](#troubleshooting-blueprints-debug)
+ [我應該為 Managed Service for Apache Flink 應用程式監控哪些關鍵指標？](#troubleshooting-blueprints-metrics)
## My CloudFormation 堆疊部署失敗或已復原。我可以做什麼來修正此問題？
+ 前往您的 CFN 堆疊，並尋找堆疊失敗的原因。它可能與缺少許可、 AWS 資源名稱衝突以及其他原因有關。修正部署失敗的根本原因。如需詳細資訊，請參閱 [ CloudWatch 疑難排解指南](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#basic-ts-guide)。
+ 【選用】 每個 VPC 每個服務只能有一個 VPC 端點。如果您部署了多個即時向量內嵌藍圖，以寫入相同 VPC 中的 Amazon OpenSearch Service 集合，則它們可能會共用 VPC 端點。這些可能已經存在於您的 VPC 帳戶中，或者第一個即時向量內嵌藍圖堆疊將為 Amazon Bedrock 和 Amazon OpenSearch Service 建立 VPC 端點，以供您帳戶中部署的所有其他堆疊使用。如果堆疊失敗，請檢查該堆疊是否已為 Amazon Bedrock 和 Amazon OpenSearch Service 建立 VPC 端點，如果您的帳戶中的其他位置未使用它們，請將其刪除。如需刪除 VPC 端點的步驟，請參閱如何安全地刪除應用程式的文件。
+ 您的帳戶中可能有使用 VPC 端點的其他服務或應用程式。刪除它可能會對其他 服務造成網路中斷。請小心刪除這些端點。
## 我不希望我的應用程式開始從 Amazon MSK 主題開頭讀取訊息。我要怎麼做？
您必須根據所需的行為，明確`source.msk.starting.offset`地將 設定為下列其中一個值：
+ **最早位移**：分割區中最舊的位移。
+ **最新偏移**：消費者將從分割區結尾讀取訊息。
+ **已遞交偏移**：從取用者在分割區中處理的最後一個訊息中讀取。
## 如何知道我的 Managed Service for Apache Flink 應用程式是否存在問題，以及如何對其進行偵錯？
使用 [Managed Service for Apache Flink 疑難排解指南](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html)，為您的應用程式偵錯 Managed Service for Apache Flink 相關問題。
## 我應該為 Managed Service for Apache Flink 應用程式監控哪些關鍵指標？
+ 適用於一般 Managed Service for Apache Flink 應用程式的所有指標都可協助您監控應用程式。如需詳細資訊，請參閱 [Managed Service for Apache Flink 中的指標和維度](https://docs.aws.amazon.com/managed-flink/latest/java/metrics-dimensions.html)。
+ 若要監控 Amazon Bedrock 指標，請參閱 [Amazon Bedrock 的 Amazon CloudWatch 指標](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html#runtime-cloudwatch-metrics)。
+ 我們已新增兩個新的指標來監控產生內嵌的效能。在 CloudWatch 中的`EmbeddingGeneration`操作名稱下尋找它們。這兩個指標為：
+ **BedrockTitanEmbeddingTokenCount**：Amazon Bedrock 的單一請求中存在的字符數量。
+ **BedrockEmbeddingGenerationLatencyMs**：報告從 Amazon Bedrock 傳送和接收回應以產生內嵌所需的時間，以毫秒為單位。
+ 對於 Amazon OpenSearch Service 無伺服器集合，您可以使用 等指標`IngestionDataRate``IngestionDocumentErrors`和其他指標。如需詳細資訊，請參閱[使用 Amazon CloudWatch 監控 OpenSearch Serverless](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/monitoring-cloudwatch.html)。
+ 如需 OpenSearch 佈建指標，請參閱[使用 Amazon CloudWatch 監控 OpenSearch 叢集指標](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-cloudwatchmetrics.html)。
# 執行期疑難排解
本節包含診斷和修正 Managed Service for Apache Flink 應用程式執行期問題的相關資訊。
**Topics**
+ [故障診斷工具](#troubleshooting-tools)
+ [應用程式問題](troubleshooting-symptoms.md)
+ [應用程式正在重新啟動](troubleshooting-rt-restarts.md)
+ [輸送量太慢](troubleshooting-rt-throughput.md)
+ [無限制狀態成長](troubleshooting-rt-stateleaks.md)
+ [I/O 綁定運算子](troubleshooting-io-bound-operators.md)
+ [Kinesis 資料串流的上游或來源限流](troubleshooting-source-throttling.md)
+ [檢查點](troubleshooting-checkpoints.md)
+ [檢查點逾時](troubleshooting-chk-timeout.md)
+ [Apache Beam 應用程式檢查點失敗](troubleshooting-chk-failure-beam.md)
+ [背壓](troubleshooting-backpressure.md)
+ [資料扭曲](troubleshooting-data-skew.md)
+ [狀態扭曲](troubleshooting-state-skew.md)
+ [與不同區域中的資源整合](troubleshooting-resources-in-different-regions.md)
## 故障診斷工具
偵測應用程式問題的主要工具是 CloudWatch 警示。您可以使用 CloudWatch 警示設定 CloudWatch 指標的閾值，以指出應用程式中的錯誤或瓶頸狀況。如需建議的 CloudWatch 警示的相關資訊，請參閱[搭配 Amazon Managed Service for Apache Flink 使用 CloudWatch 警示](monitoring-metrics-alarms.md)。
# 應用程式問題
本節包含針對 Managed Service for Apache Flink 應用程式可能會遇到的錯誤情況的解決方案。
**Topics**
+ [應用程式卡在暫時狀態](#troubleshooting-rt-stuck)
+ [快照建立失敗](#troubleshooting-rt-snapshots)
+ [無法存取 VPC 中的資源](#troubleshooting-rt-vpc)
+ [寫入 Amazon S3 儲存貯體時遺失資料](#troubleshooting-rt-s3)
+ [應用程式處於執行中狀態，但未處理資料](#troubleshooting-rt-processing)
+ [快照、應用程式更新或應用程式停止錯誤： InvalidApplicationConfigurationException](#troubleshooting-rt-appconfigexception)
+ [java.nio.file.NoSuchFileException: /usr/local/openjdk-8/lib/security/cacerts](#troubleshooting-rt-fnf)
## 應用程式卡在暫時狀態
如果應用程式已保持暫時狀態 (`STARTING`、`UPDATING`、`STOPPING` 或 `AUTOSCALING`) 一段時間，您可以使用 [StopApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_StopApplication.html) 動作停止應用程式，並將 `Force` 參數設定為 `true`。您無法強制停止 `DELETING` 狀態的應用程式。或者，如果應用程式處於 `UPDATING` 或 `AUTOSCALING` 狀態，您可以將其復原至先前執行的版本。復原應用程式時，它會從上次成功的快照載入狀態資料。如果應用程式沒有快照，Managed Service for Apache Flink 會拒絕復原請求。如需復原應用程式的詳細資訊，請參閱 [RollbackApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_RollbackApplication.html) 動作。
**注意**
強制停止應用程式可能會導致資料遺失或重複。為了防止應用程式重新啟動期間資料遺失或重複處理資料，我們建議您經常拍攝應用程式的快照。
應用程式卡住的原因如下：
+ **應用程式狀態太大：**應用程式狀態太大或過於持續，可能會導致應用程式在檢查點或快照操作期間卡住。檢查應用程式 `lastCheckpointDuration` 和 `lastCheckpointSize` 指標的值是否在穩定增加或異常高。
+ **應用程式的程式碼太大：**確認您的應用程式 JAR 檔案小於 512 MB。不支援大於 512 MB 的 JAR 檔案。
+ **應用程式快照建立失敗：**Managed Service for Apache Flink 會在 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_UpdateApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_UpdateApplication.html) 或 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_StopApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_StopApplication.html) 請求期間擷取應用程式的快照。然後，服務會使用此快照狀態，並使用更新的應用程式組態還原應用程式，以提供*恰好一次*的處理語義。如果自動建立快照失敗，請參閱下文的[快照建立失敗](#troubleshooting-rt-snapshots)。
+ **從快照還原失敗：**如果您移除或變更應用程式更新中的運算子，並嘗試從快照還原，則如果快照包含遺失運算子的狀態資料，還原預設將會失敗。此外，應用程式將卡在 `STOPPED` 或 `UPDATING` 狀態。若要變更此行為並讓還原成功，請將應用程式 [FlinkRunConfiguration](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_FlinkRunConfiguration.html) 的 *AllowNonRestoredState* 參數變更為 `true`。這將允許恢復操作跳過無法對應至新程式的狀態資料。
+ **應用程式初始化所花費的時間較長：**Managed Service for Apache Flink 在等待 Flink 作業啟動時，會使用 5 分鐘的內部逾時 (軟體設定)。如果作業無法在此逾時內啟動，您將會看到如下所示的 CloudWatch 日誌：
```
Flink job did not start within a total timeout of 5 minutes for application: %s under account: %s
```
如果遇到上述錯誤，表示在 Flink 作業 `main` 方法下定義的操作需要 5 分鐘以上的時間，從而導致建立 Flink 作業的操作在 Managed Service for Apache Flink 結束時逾時。我們建議您檢查 Flink **JobManager** 日誌以及應用程式的程式碼，查看 `main` 方法中是否預期存在此延遲。如果沒有，則需要採取措施來解決該問題，以便在 5 分鐘內完成。
您可以使用 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html) 或 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html) 動作來檢查應用程式狀態。
## 快照建立失敗
在下列情況下，Managed Service for Apache Flink 服務無法拍攝快照：
+ 應用程式超過快照限制。快照的限制為 1,000。如需詳細資訊，請參閱[使用快照管理應用程式備份](how-snapshots.md)。
+ 應用程式沒有存取其來源或接收器的許可。
+ 應用程式的程式碼無法正常運作。
+ 應用程式遇到其他組態問題。
在應用程式更新期間或停止應用程式時，如果擷取快照時發生例外狀況，請將應用程式 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ApplicationSnapshotConfiguration.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ApplicationSnapshotConfiguration.html) 的 `SnapshotsEnabled` 屬性設定為 `false`，然後重試該請求。
如果應用程式的運算子未正確佈建，快照可能會失敗。如需調整運算子效能的相關資訊，請參閱[運算子擴展](performance-improving.md#performance-improving-scaling-op)。
應用程式回到正常狀態之後，建議您將應用程式的 `SnapshotsEnabled` 屬性設定為 `true`。
## 無法存取 VPC 中的資源
如果應用程式使用在 Amazon VPC 上執行的 VPC，請執行以下操作以確認應用程式是否可以存取其資源：
+ 檢查 CloudWatch 日誌中是否有下列錯誤。此錯誤表示應用程式無法存取 VPC 中的資源：
```
org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms.
```
如果您看到此錯誤，請確認您的路由表設定正確，並且連接器具有正確的連線設定。
如需設定和分析 CloudWatch 日誌的相關資訊，請參閱[在 Amazon Managed Service for Apache Flink 中記錄和監控](monitoring-overview.md)。
## 寫入 Amazon S3 儲存貯體時遺失資料
使用 Apache Flink 1.6.2 版將輸出寫入 Amazon S3 儲存貯體時，可能會發生一些資料遺失。我們建議您在直接使用 Amazon S3 進行輸出時，使用 Apache Flink 最新支援版本。若要使用 Apache Flink 1.6.2 寫入 Amazon S3 儲存貯體，建議使用 Firehose。如需搭配使用 Firehose 與 Managed Service for Apache Flink 的詳細資訊，請參閱 [Firehose 接收器](earlier.md#get-started-exercise-fh)。
## 應用程式處於執行中狀態，但未處理資料
您可以使用 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_ListApplications.html) 或 [https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html](https://docs.aws.amazon.com/managed-service-for-apache-flink/latest/apiv2/API_DescribeApplication.html) 動作來檢查應用程式狀態。如果應用程式進入 `RUNNING` 狀態，但未在將資料寫入接收器，您可以透過將 Amazon CloudWatch 日誌串流新增至應用程式來解決該問題。如需詳細資訊，請參閱[使用應用程式 CloudWatch 記錄選項](cloudwatch-logs.md#adding_cloudwatch)。日誌串流包含可用於對應用程式問題進行疑難排解的訊息。
## 快照、應用程式更新或應用程式停止錯誤： InvalidApplicationConfigurationException
在快照操作期間或在建立快照的操作 (例如更新或停止應用程式) 期間，可能會發生如下錯誤：
```
An error occurred (InvalidApplicationConfigurationException) when calling the UpdateApplication operation:
Failed to take snapshot for the application xxxx at this moment. The application is currently experiencing downtime.
Please check the application's CloudWatch metrics or CloudWatch logs for any possible errors and retry the request.
You can also retry the request after disabling the snapshots in the Managed Service for Apache Flink console or by updating
the ApplicationSnapshotConfiguration through the AWS SDK
```
應用程式無法建立快照時，會發生此錯誤。
如果在快照操作或建立快照的操作期間遇到此錯誤，請執行下列動作：
+ 為應用程式停用快照。您可以在 Managed Service for Apache Flink 主控台中執行此操作，也可以使用 [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html) 動作的 `SnapshotsEnabledUpdate` 參數。
+ 調查無法建立快照的原因。如需詳細資訊，請參閱[應用程式卡在暫時狀態](#troubleshooting-rt-stuck)。
+ 當應用程式恢復正常狀態時，再重新啟用快照。
## java.nio.file.NoSuchFileException: /usr/local/openjdk-8/lib/security/cacerts
SSL 信任存放區的位置已在先前的部署中更新。為 `ssl.truststore.location` 參數改用下列值：
```
/usr/lib/jvm/java-11-amazon-corretto/lib/security/cacerts
```
# 應用程式正在重新啟動
如果您的應用程式運作狀況不正常，其 Apache Flink 作業就會持續失敗並重新啟動。本節說明此狀況的徵狀和疑難排解步驟。
## 徵狀
這種情況可能有下列徵狀：
+ `FullRestarts` 指標不為零。此指標代表自您啟動應用程式後，應用程式作業已重新啟動的次數。
+ `Downtime` 指標不為零。此指標代表應用程式處於 `FAILING` 或 `RESTARTING` 狀態的毫秒數。
+ 應用程式日誌包含狀態變更 (變更為 `RESTARTING` 或 `FAILED`)。您可以使用下列 CloudWatch Logs Insights 查詢，來查詢您的應用程式日誌中是否有這些狀態變更：[分析錯誤：應用程式任務相關的失敗](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps)。
## 原因和解決方案
下列情況可能會導致您的應用程式變得不穩定並重複重新啟動：
+ **運算子擲回例外狀況：**如果應用程式中運算子中的任何例外狀況未處理，應用程式會容錯移轉 （透過解譯運算子無法處理失敗）。應用程式會從最新的檢查點重新啟動，以維護「恰好一次」的處理語義。因此，`Downtime` 在這些重新啟動期間不為零。為了防止這種情況發生，我們建議您處理應用程式程式碼中的任何可重試的例外狀況。
您可以查詢應用程式日誌中是否包含從 `RUNNING` 到 `FAILED` 的應用程式狀態變更，以調查此情況的原因。如需詳細資訊，請參閱[分析錯誤：應用程式任務相關的失敗](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps)。
+ **未正確佈建 Kinesis 資料串流：**如果您應用程式的來源或目的地是 Kinesis 資料串流，請檢查串流的[指標](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html)是否有 `ReadProvisionedThroughputExceeded`或 `WriteProvisionedThroughputExceeded`錯誤。
如果看到這些錯誤，您可以增加串流的碎片數目，以增加 Kinesis 串流的可用輸送量。如需詳細資訊，請參閱[如何變更 Kinesis Data Streams 中的開放碎片數目？](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-open-shards/)
+ **其他來源或接收器未正確佈建或不可用：**確認應用程式是否正確佈建來源和接收器。檢查應用程式中使用的任何來源或接收器 （例如 AWS 其他服務，或外部來源或目的地） 是否已妥善佈建、未遇到讀取或寫入限流，或是否定期無法使用。
如果您遇到相依服務的輸送量相關問題，請增加這些服務的可用資源，或調查任何錯誤或無法使用的原因。
+ **運算子未正確佈建：**如果應用程式中其中一個運算子的執行緒上的工作負載未正確分配，則該運算子可能會超載，而應用程式可能會損毀。如需調整運算子平行處理的相關資訊，請參閱[適當管理運算子擴展](performance-improving.md#performance-improving-scaling-op)。
+ **應用程式失敗，出現 DaemonException：**如果您使用的是 1.11 之前的 Apache Flink 版本，此錯誤會出現在應用程式日誌中。您可能需要升級至更新版本的 Apache Flink，以便使用 0.14 或更新版本的 KPL。
+ **應用程式失敗，出現 TimeoutException、FlinkException 或 RemoteTransportException：**如果任務管理員損毀，這些錯誤可能會出現在應用程式日誌中。如果應用程式超載，任務管理員可能會遇到 CPU 或記憶體資源壓力，導致它們失敗。
這些錯誤可能如下所示：
+ `java.util.concurrent.TimeoutException: The heartbeat of JobManager with id xxx timed out`
+ `org.apache.flink.util.FlinkException: The assigned slot xxx was removed`
+ `org.apache.flink.runtime.io.network.netty.exception.RemoteTransportException: Connection unexpectedly closed by remote task manager`
若要疑難排解此狀況，請檢查下列各項：
+ 檢查 CloudWatch 指標以了解 CPU 或記憶體用量是否出現異常尖峰。
+ 檢查應用程式以了解是否有輸送量問題。如需詳細資訊，請參閱[對效能問題進行故障診斷](performance-troubleshooting.md)。
+ 檢查應用程式日誌以了解是否有應用程式程式碼所引發的未處理例外狀況。
+ **應用程式失敗，出現「找不到 JaxbAnnotationModule」錯誤：**如果應用程式使用 Apache Beam，但沒有正確的相依性或相依性版本，則會發生此錯誤。使用 Apache Beam 的 Managed Service for Apache Flink 應用程式必須使用以下版本的相依性：
```
2.10.2
...
com.fasterxml.jackson.module
jackson-module-jaxb-annotations
2.10.2
```
如果您未提供正確的 `jackson-module-jaxb-annotations` 版本作為明確的相依性，應用程式會從環境相依性載入該版本，而由於版本不相符，應用程式會在執行期損毀。
如需將 Apache Beam 與 Managed Service for Apache Flink 搭配使用的詳細資訊，請參閱[使用 CloudFormation使用 Apache Beam 建立應用程式](examples-beam.md)。
+ **應用程式失敗，並顯示 java.io.IOException：網路緩衝區數目不足**
當應用程式為網路緩衝區配置的記憶體不足時，就會發生這種情況。網路緩衝區可協助子任務之間的通信。它們用於在透過網路傳輸之前存儲記錄，並在將其解析為記錄並移交給子任務之前存儲傳入的資料。所需的網路緩衝區數目可直接根據作業圖表的平行處理層級和複雜度擴展。有許多方法可以緩解此問題：
+ 您可以設定較低的 `parallelismPerKpu`，以便為每個子任務和網路緩衝區配置更多記憶體。請注意，降低 `parallelismPerKpu` 會增加 KPU，因此會增加成本。為了避免這種情況，您可以按相同係數降低平行處理層級來保持相同數量的 KPU。
+ 您可以減少運算子的數目或將它們鏈結起來，以減少所需的緩衝區來簡化作業圖表。
+ 否則，您可以聯絡 https://aws.amazon.com/premiumsupport/ 進行自訂網路緩衝區組態。
# 輸送量太慢
如果應用程式處理傳入的串流資料速度不夠快，它會效能不佳且變得不穩定。本節說明此狀況的徵狀和疑難排解步驟。
## 徵狀
這種情況可能有下列徵狀：
+ 如果應用程式的資料來源是 Kinesis 串流，則串流的 `millisbehindLatest` 指標會持續增加。
+ 如果應用程式的資料來源是 Amazon MSK 叢集，則叢集的取用者延遲指標會持續增加。如需詳細資訊，請參閱 [Amazon MSK 開發人員指南](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html)中的[取用者延遲監控](https://docs.aws.amazon.com/msk/latest/developerguide/consumer-lag.html)。
+ 如果應用程式的資料來源是其他服務或來源，請檢查任何可用的取用者延遲指標或可用資料。
## 原因和解決方案
造成應用程式輸送量緩慢的原因可能有很多。如果應用程式未與輸入保持一致，請檢查以下內容：
+ 如果輸送量延遲急劇增加，然後逐漸減少，請檢查應用程式是否正在重新啟動。應用程式在重新啟動時會停止處理輸入，進而造成延遲急劇增加。如需應用程式故障的相關資訊，請參閱[應用程式正在重新啟動](troubleshooting-rt-restarts.md)。
+ 如果輸送量延遲一致，請檢查應用程式是否已進行效能最佳化。如需最佳化應用程式效能的相關資訊，請參閱[對效能問題進行故障診斷](performance-troubleshooting.md)。
+ 如果輸送量延遲未急劇增加，而是持續增加，並且應用程式已進行效能最佳化，則必須增加應用程式資源。如需增加應用程式資源的相關資訊，請參閱[實作應用程式擴展](how-scaling.md)。
+ 如果應用程式從不同區域的 Kafka 叢集讀取，並且儘管取用者延遲很高，`FlinkKafkaConsumer` 或 `KafkaSource` 大多是閒置狀態 (高 `idleTimeMsPerSecond` 或低 `CPUUtilization`)，則可以增加 `receive.buffer.byte` 的值，例如 2097152。如需詳細資訊，請參閱[自訂 MSK 組態](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html)中的「高延遲環境」一節。
如需應用程式來源中輸送量緩慢或取用者延遲增加的疑難排解步驟，請參閱[對效能問題進行故障診斷](performance-troubleshooting.md)。
# 無限制狀態成長
如果應用程式未正確處置過期的狀態資訊，這些資訊會持續累積並導致應用程式效能或穩定性問題。本節說明此狀況的徵狀和疑難排解步驟。
## 徵狀
這種情況可能有下列徵狀：
+ `lastCheckpointDuration` 指標正在逐漸增加或急劇增加。
+ `lastCheckpointSize` 指標正在逐漸增加或急劇增加。
## 原因和解決方案
下列情況可能會導致應用程式累積狀態資料：
+ 應用程式保留狀態資料的時間超過需要的時間。
+ 應用程式使用持續時間過長的視窗查詢。
+ 您尚未為狀態資料設定 TTL。如需詳細資訊，請參閱 Apache Flink 文件中的[狀態Time-To-Live(TTL)](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl)。
+ 您正在執行的應用程式相依於 Apache Beam 2.25.0 版或更高版本。您可以透過用關鍵實驗和 `use_deprecated_read` 值[擴充 BeamApplicationProperties](https://docs.aws.amazon.com/managed-flink/latest/java/examples-beam.html#examples-beam-configure)，選擇退出讀取轉換的新版本。如需詳細資訊，請參閱 [Apache Beam 文件](https://beam.apache.org/blog/beam-2.25.0/#highlights)。
應用程式有時會面臨持續擴增的狀態大小增長，從長遠來看，這是不可持續的 (畢竟 Flink 應用程式會無限期地執行)。有時，這可以追溯至存儲狀態資料且未正確地老化舊資訊的應用程式。但是有時候，使用者對 Flink 可以提供的東西抱有根本不合理的期望。應用程式可以在跨越數天甚至數週的長時段內使用彙總。除非使用允許增量彙總的 [AggregateFunctions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/#aggregatefunction)，否則 Flink 需要將整個視窗的事件保持在狀態。
此外，當使用進程函數來實作自訂運算子時，應用程式需要從業務邏輯不再需要的狀態中移除資料。在這種情況下，[狀態存活期](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl)可用於根據處理時間自動老化資料。Managed Service for Apache Flink 正在使用增量檢查點，因此狀態 TTL 基於 [RocksDB 壓縮](https://github.com/facebook/rocksdb/wiki/Compaction)。在壓縮操作發生之後，您只能觀察到狀態大小的實際縮減 (由檢查點大小表示)。特別是對於低於 200 MB 的檢查點大小，由於狀態到期，您不太可能觀察到任何檢查點大小縮小。儲存點則基於不包含舊資料之狀態的全新副本，因此您可以在 Managed Service for Apache Flink 中觸發快照，以強制移除過期狀態。
出於偵錯目的，停用增量檢查點以更快速地驗證檢查點大小是否確實減小或穩定 (並避免 RocksBS 壓縮的影響) 是可行的。但是，這需要提交票證給服務團隊。
# I/O 綁定運算子
最好避免對資料路徑上外部系統的相依性。將參考資料集保持在狀態中，而不是查詢外部系統以富集個別事件，通常效能要高很多。不過，有時候有些相依性無法輕易移至狀態，例如，如果您想要使用 Amazon Sagemaker 上託管的機器學習模型來富集事件。
透過網絡與外部系統進行互動的運算子可能會成為瓶頸並導致背壓。強烈建議使用 [AsyncIO](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/) 來實作該功能，以減少單個呼叫的等待時間並避免整個應用程式變慢。
此外，對於具有 I/O 綁定運算子的應用程式，也可以增加 Apache Flink 應用程式的 [ParallelismPerKPU](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_ParallelismConfiguration.html) 設定。此設定描述應用程式每 Kinesis 處理單元 (KPU) 可執行的平行子任務數目。藉由將值從預設值 1 增加到 4，應用程式利用相同的資源 (以相同的成本)，但可擴展至 4 倍的平行處理層級。這非常適用於 I/O 綁定的應用程式，但會給不是 I/O 綁定的應用程式造成額外開銷。
# Kinesis 資料串流的上游或來源限流
**徵狀**：應用程式遇到來自其上游來源 Kinesis 資料串流的 `LimitExceededExceptions`。
**潛在原因**：Apache Flink 程式庫 Kinesis 連接器的預設設定設定為從 Kinesis 資料串流來源讀取，且每次 `GetRecords` 呼叫擷取的最大記錄數目具有非常積極的預設設定。Apache Flink 預設設定為每次`GetRecords`呼叫擷取 10，000 個記錄 （此呼叫預設為每 200 毫秒），但每個碎片的限制只有 1，000 個記錄。
嘗試從 Kinesis 資料串流取用時，此預設行為可能會導致限流，從而影響應用程式的效能和穩定性。
您可以透過檢查 CloudWatch `ReadProvisionedThroughputExceeded` 指標並查看此指標大於零的延長或持續期間來確認這一點。
您也可以透過觀察持續的`LimitExceededException`錯誤，在 Amazon Managed Service for Apache Flink 應用程式的 CloudWatch 日誌中看到此情況。
**解決**方法：您可以執行下列兩項操作之一來解決這種情況：
+ 降低每次`GetRecords`呼叫擷取的記錄數量的預設限制
+ 在 Amazon Managed Service for Apache Flink 應用程式中啟用自適應讀取。如需適性讀取功能的詳細資訊，請參閱 [SHARD\$1USE\$1ADAPTIVE\$1READS](https://nightlies.apache.org/flink/flink-docs-release-1.10/api/java/org/apache/flink/streaming/connectors/kinesis/config/ConsumerConfigConstants.html#SHARD_USE_ADAPTIVE_READS)
# 檢查點
檢查點是 Flink 用於確保應用程式狀態具有容錯能力的機制。該機制允許 Flink 在作業失敗時恢復運算子的狀態，並為應用程式提供與無故障執行相同的語義。使用 Managed Service for Apache Flink，應用程式的狀態會儲存在 RocksDB 中，這是一個內嵌式索引鍵/值存放區，可將其工作狀態保留在磁碟上。取得檢查點時，狀態也會上傳至 Amazon S3，這樣即使磁碟遺失，也可以使用檢查點來還原應用程式狀態。
如需詳細資訊，請參閱[狀態快照如何運作](https://nightlies.apache.org/flink/flink-docs-master/docs/learn-flink/fault_tolerance/#how-does-state-snapshotting-work)。
## 檢查點階段
對於 Flink 中的檢查點運算子子任務，有 5 個主要階段：
+ 等待 [**開始延遲**]：Flink 使用插入串流的檢查點障礙，因此在此階段的時間是運算子等待檢查點障礙到達它的時間。
+ 對齊 [**對齊持續時間**]：在此階段，子任務已到達一個障礙，但它正在等待來自其他輸入串流的障礙。
+ 同步檢查點 [**同步持續時間**]：在此階段，子任務會實際拍攝運算子狀態快照，並阻止該子任務上的所有其他活動。
+ 非同步檢查點 [**非同步持續時間**]：此階段的主要操作是子任務將狀態上傳到 Amazon S3。在此階段，子任務不再被阻止，可以處理記錄。
+ 確認：這通常是一個短暫的階段，只是子任務發送確認給 JobManager 並執行任何遞交訊息 (例如，使用 Kafka 接收器)。
上述每個階段 (除了「確認」) 都對應到 Flink WebUI 中可用檢查點的持續時間指標，這可以幫助隔離長檢查點的原因。
要查看檢查點上每個可用指標的確切定義，請轉到[歷史記錄](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/#history-tab)標籤。
## 調查
調查長檢查點的持續時間時，最重要的是要確定檢查點的瓶頸，也就是說，什麼運算子和子任務正在採用最長檢查點，該子任務的哪個階段正在花費較長的時間。這可以使用作業檢查點任務下的 Flink WebUI 來確定。Flink 的 Web 介面提供了可協助調查檢查點問題的資料和資訊。如需完整明細，請參閱[監控檢查點](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/)。
首先要注意的是作業圖表中每個運算子的**端對端持續時間**，以確定哪個運算子需要較長時間才能到達檢查點，需要進一步調查。根據 Flink 文件，持續時間的定義如下：
*從觸發時間戳記到最近確認為止的持續時間 (如果尚未收到確認，則為 n/a)。完整檢查點的端對端持續時間由確認檢查點的最後一個子任務決定。此時間通常大於單個子任務對狀態實際執行檢查點需要的時間。*
檢查點的其他持續時間還提供了有關花費時間的更精細資訊。
如果**同步持續時間**很高，則表示快照過程中發生了問題。在這個階段，為實作 snapshotState 介面的類別呼叫 `snapshotState()`；這可以是使用者程式碼，所以執行緒傾印對於調查這一點會有幫助。
**非同步持續時間**長表明將狀態上傳到 Amazon S3 花費了大量時間。如果狀態很大，或者有許多狀態檔案正在上傳，就會發生這種情況。如果是這種情況，則值得調查應用程式如何使用狀態，並確保在可能的情況下使用 Flink 本機資料結構 ([使用具有索引鍵的狀態](https://nightlies.apache.org/flink/flink-docs-master/docs/dev/datastream/fault-tolerance/state/#using-keyed-state))。Managed Service for Apache Flink 會以最小化 Amazon S3 呼叫數目的方式來設定 Flink，以確保不會變得太長。下面是某個運算子的檢查點統計資料範例。它表明，與之前的運算子檢查點統計資料相比，此運算子的**非同步持續時間**相對較長。
![\[調查檢查點\]](http://docs.aws.amazon.com/zh_tw/managed-flink/latest/java/images/checkpoint.png)
**開始延遲**高將表明等待檢查點障礙到達運算子花費了大部分時間。這表明應用程式正在花時間處理記錄，意味著障礙正在緩慢流經作業圖表。如果作業受到背壓或運算子經常處於忙碌狀態，通常就會發生這種情況。以下是作業圖表範例，其中第二個 KeyedProcess 運算子處於忙碌狀態。
![\[調查檢查點\]](http://docs.aws.amazon.com/zh_tw/managed-flink/latest/java/images/checkpoint2.png)
您可以使用 Flink 火焰圖或 TaskManager 執行緒傾印來調查是什麼需要這麼長時間。一旦確定了瓶頸，就可以使用火焰圖或執行緒傾印進一步調查。
## 執行緒傾印
執行緒傾印是比火焰圖層級略低的另一種偵錯工具。執行緒傾印會在某個時間點輸出所有執行緒的執行狀態。Flink 接受 JVM 執行緒傾印，這是 Flink 處理序中所有執行緒的執行狀態。執行緒狀態由執行緒的堆疊追蹤以及一些附加資訊來表示。火焰圖實際上是使用快速連續採取的多個堆疊追蹤所建置。該圖形是由這些追蹤構成的可視化呈現，可讓您輕鬆地識別常見程式碼路徑。
```
"KeyedProcess (1/3)#0" prio=5 Id=1423 RUNNABLE
at app//scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:154)
at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(>19)
at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(:14)
at app//org.apache.flink.streaming.api.operators.KeyedProcessOperator.processElement(KeyedProcessOperator.java:83)
at app//org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:205)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.processElement(AbstractStreamTaskNetworkInput.java:134)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.emitNext(AbstractStreamTaskNetworkInput.java:105)
at app//org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:66)
...
```
以上是從 Flink UI 為單個執行緒取得的執行緒傾印的片段。第一行包含有關此執行緒的一些一般資訊，包括：
+ 執行緒名稱 *KeyedProcess (1/3)\$10*
+ 執行緒優先順序 *prio=5*
+ 唯一的執行緒 ID *Id=1423*
+ 執行緒狀態 *RUNNABLE*
執行緒名稱通常會提供執行緒一般用途的資訊。運算子執行緒可以通過其名稱來識別，因為運算子執行緒與運算子具有相同的名稱，並且會指出其相關子任務，例如，*KeyedProcess (1/3)\$10* 執行緒來自 *KeyedProcess* 運算子，並且來自第 1 個子任務 (共 3 個)。
執行緒可以是下列幾種狀態之一：
+ NEW：執行緒已建立，但尚未得到處理
+ RUNNABLE：執行緒正在 CPU 上執行
+ BLOCKED：執行緒正在等待另一個執行緒釋放其鎖定
+ WAITING：執行緒正在使用 `wait()`、`join()` 或 `park()` 方法等待
+ TIMED\$1WAITING：執行緒正在使用睡眠、等待、聯結或駐留方法等待，但等待時間最長。
**注意**
在 Flink 1.13 中，執行緒傾印中單一堆疊追蹤的最大深度限制為 8。
**注意**
執行緒傾印必須是 Flink 應用程式中偵錯效能問題的最後手段，因為它們可能難以讀取，需要擷取和手動分析多個樣本。如果有可能，最好使用火焰圖。
### Flink 中的執行緒傾印
在 Flink 中，透過選擇 Flink UI 左側導覽列上的**任務管理員**選項，選取特定任務管理員，然後瀏覽至**執行緒傾印**標籤，即可取得執行緒傾印。您可以下載執行緒傾印、複製到喜愛的文字編輯器 (或執行緒傾印分析器)，或直接在 Flink Web UI 的文字檢視中進行分析 (不過最後一個選項可能有點繁瑣)。
為了確定在選擇特定運算子後，要用來取得 **TaskManager** 選項卡執行緒傾印的任務管理員。這表明運算子正在運算子的不同子任務上執行，並且可以在不同的任務管理員上執行。
![\[使用執行緒傾印\]](http://docs.aws.amazon.com/zh_tw/managed-flink/latest/java/images/checkpoint4.png)
傾印將由多個堆疊追蹤組成。但是，在調查傾印時，與運算子關聯的傾印最重要。這些很容易找到，因為運算子執行緒與運算子具有相同的名稱，並且會指出與哪個子任務相關聯。例如，以下堆疊追蹤來自 *KeyedProcess* 運算子，並且是第 1 個子任務。
```
"KeyedProcess (1/3)#0" prio=5 Id=595 RUNNABLE
at app//scala.collection.immutable.Range.foreach$mVc$sp(Range.scala:155)
at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(:19)
at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(:14)
at app//org.apache.flink.streaming.api.operators.KeyedProcessOperator.processElement(KeyedProcessOperator.java:83)
at app//org.apache.flink.streaming.runtime.tasks.OneInputStreamTask$StreamTaskNetworkOutput.emitRecord(OneInputStreamTask.java:205)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.processElement(AbstractStreamTaskNetworkInput.java:134)
at app//org.apache.flink.streaming.runtime.io.AbstractStreamTaskNetworkInput.emitNext(AbstractStreamTaskNetworkInput.java:105)
at app//org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:66)
...
```
如果有多個運算子具有相同名稱，則可能會造成混淆，但我們可以透過命名運算子來解決這個問題。例如：
```
....
.process(new ExpensiveFunction).name("Expensive function")
```
## [火焰圖](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/debugging/flame_graphs/)
火焰圖是一款有用的偵錯工具，它可以可視化目標程式碼的堆疊追蹤，從而允許識別最常見的程式碼路徑。它們透過對堆疊追蹤進行多次取樣來建立。火焰圖的 x 軸顯示不同的堆疊設定檔，y 軸顯示堆疊深度，以及堆疊追蹤中的呼叫。火焰圖中的單個矩形顯示在堆疊框架上，框架的寬度顯示它在堆疊中出現的頻率。如需火焰圖表及其用法的詳細資訊，請參閱[火焰圖](https://www.brendangregg.com/flamegraphs.html)。
在 Flink 中，運算子的火焰圖可以透過 Web UI 存取，方法是選取運算子，然後選擇**火焰圖**標籤。一旦收集到足夠的樣本，火焰圖即會顯示。以下是花費了大量時間執行檢查點的 ProcessFunction 的火焰圖。
![\[使用火焰圖\]](http://docs.aws.amazon.com/zh_tw/managed-flink/latest/java/images/checkpoint3.png)
這是一個非常簡單的火焰圖，其中顯示了所有 CPU 時間都花費在一個 foreach 迴圈內的 ExpensiveFunction 運算子的 `processElement` 內。您還可以取得行號，以幫助確定程式碼的執行位置。
# 檢查點逾時
如果應用程式未最佳化或正確佈建，檢查點可能會失敗。本節說明此狀況的徵狀和疑難排解步驟。
## 徵狀
如果應用程式的檢查點失敗，`numberOfFailedCheckpoints` 將會大於零。
檢查點可能會因為直接失敗 (例如應用程式錯誤) 或暫時性失敗 (例如應用程式資源不足) 而失敗。檢查應用程式日誌和指標是否有下列徵狀：
+ 程式碼中有錯誤。
+ 存取應用程式相依服務時發生錯誤。
+ 序列化資料時發生錯誤。如果預設的序列化程式無法序列化應用程式資料，則應用程式將失敗。如需有關在應用程式中使用自訂序列化程式的資訊，請參閱 Apache Flink 文件中的[資料類型和序列化](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/dev/datastream/fault-tolerance/serialization/types_serialization/)。
+ 記憶體不足錯誤。
+ 以下指標急劇增加或穩定增加：
+ `heapMemoryUtilization`
+ `oldGenerationGCTime`
+ `oldGenerationGCCount`
+ `lastCheckpointSize`
+ `lastCheckpointDuration`
如需監控檢查點的詳細資訊，請參閱 Apache Flink 文件中的[監控檢查點](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/ops/monitoring/checkpoint_monitoring/)。
## 原因和解決方案
您的應用程式日誌錯誤訊息會顯示直接失敗的原因。暫時性失敗可能有下列原因：
+ 應用程式佈建的 KPU 不足。如需增加應用程式佈建的相關資訊，請參閱[實作應用程式擴展](how-scaling.md)。
+ 應用程式狀態大小太大。您可以使用 `lastCheckpointSize` 指標監控應用程式狀態大小。
+ 應用程式的狀態資料在索引鍵之間分配不平均。如果應用程式使用 `KeyBy` 運算子，請確保您的傳入資料在索引鍵之間已平均分割。如果將大部分資料指派給單一索引鍵，則會產生瓶頸，從而導致失敗。
+ 應用程式遇到記憶體背壓或垃圾回收背壓。監控應用程式的 `heapMemoryUtilization`、`oldGenerationGCTime` 以及 `oldGenerationGCCount`，看是否有值在急劇增加或穩定增加。
# Apache Beam 應用程式檢查點失敗
如果設定 Beam 應用程式時將 [shutdownSourcesAfterIdleMs](https://beam.apache.org/documentation/runners/flink/#:~:text=shutdownSourcesAfterIdleMs) 設定為 0ms，則檢查點可能無法觸發，因為任務處於「FINISHED」狀態。本節說明此狀況的徵狀和解決方案。
## 徵狀
前往 Managed Service for Apache Flink 應用程式 CloudWatch 日誌，檢查其中是否記錄了下列日誌訊息。下列日誌訊息指出檢查點無法觸發，因為某些任務已完成。
```
{
"locationInformation": "org.apache.flink.runtime.checkpoint.CheckpointCoordinator.onTriggerFailure(CheckpointCoordinator.java:888)",
"logger": "org.apache.flink.runtime.checkpoint.CheckpointCoordinator",
"message": "Failed to trigger checkpoint for job your job ID since some tasks of job your job ID has been finished, abort the checkpoint Failure reason: Not all required tasks are currently running.",
"threadName": "Checkpoint Timer",
"applicationARN": your application ARN,
"applicationVersionId": "5",
"messageSchemaVersion": "1",
"messageType": "INFO"
}
```
這也可以在 Flink 儀表板上找到，其中一些任務已進入「FINISHED」狀態，並且無法再執行檢查點。
![\[任務處於「FINISHED」狀態\]](http://docs.aws.amazon.com/zh_tw/managed-flink/latest/java/images/beam_checkpoint_failure.png)
## 原因
shutdownSourcesAfterIdleMs 是 Beam 組態變數，可關閉閒置了一段設定時間 (毫秒) 的來源。一旦來源關閉，無法再執行檢查點。這可能導致[檢查點失敗](https://issues.apache.org/jira/browse/FLINK-2491)。
任務進入「FINISHED」狀態的其中一個原因是當 shutdownSourcesAfterIdleMs 設定為 0ms 時，意味著閒置的任務將立即關閉。
## 解決方案
若要防止任務立即進入「FINISHED」狀態，請將 shutdownSourcesAfterIdleMs 設定為 Long.MAX\$1VALUE。這可以透過兩種方式進行：
+ 選項 1：如果 Beam 組態是在 Managed Service for Apache Flink 應用程式的組態頁面中設定，則可以新增一個鍵值對來設定 shutdpwnSourcesAfteridleMs，如下所示：
![\[將 shutdownSourcesAfterIdleMs 設定為 Long.MAX_VALUE\]](http://docs.aws.amazon.com/zh_tw/managed-flink/latest/java/images/beam_checkpoint_failure_solution.png)
+ 選項 2：如果 Beam 組態是在 JAR 檔案中設定，您可以按如下方式設定 shutdownSourcesAfterIdleMs：
```
FlinkPipelineOptions options = PipelineOptionsFactory.create().as(FlinkPipelineOptions.class); // Initialize Beam Options object
options.setShutdownSourcesAfterIdleMs(Long.MAX_VALUE); // set shutdownSourcesAfterIdleMs to Long.MAX_VALUE
options.setRunner(FlinkRunner.class);
Pipeline p = Pipeline.create(options); // attach specified options to Beam pipeline
```
# 背壓
Flink 使用背壓來調整個別運算子的處理速度。
由於許多原因，運算子可能難以跟上處理收到的訊息量。該操作可能需要比運算子可用資源更多的 CPU 資源，運算子可能會等待 I/O 操作完成。如果運算子無法以足夠快的速度處理事件，它會在饋送給慢速運算子的上游運算子中造成背壓。這會導致上游運算子減慢速度，從而進一步將背壓傳播到來源，並透過減慢速度來使來源適應應用程式的整體輸送量。您可以在 [Apache Flink™ 如何處理背壓](https://www.ververica.com/blog/how-flink-handles-backpressure)中找到有關背壓及其運作方式的更深入說明。
知道應用程式中的哪些運算子速度緩慢，可為您提供重要資訊來了解應用程式效能問題的根本原因。背壓資訊[透過 Flink 控制面板公開](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/)。若要識別慢速運算子，請尋找具有最接近接收器高背壓值的運算子 (以下範例中為運算子 B)。造成緩慢的運算子就是其中一個下游運算子 (範例中的運算子 C)。B 可以更快地處理事件，但由於無法將輸出轉發到實際的慢速運算子 C，因此會受到背壓。
```
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
```
一旦確定慢速運算子，試著了解它為什麼慢。可能有無數的原因，有時出了什麼問題並不明顯，可能需要數天的偵錯和分析來解決。以下是一些明顯和更常見的原因，其中一些進一步解釋如下：
+ 運算子正在執行緩慢的 I/O，例如網路呼叫 (考慮改用 AsyncIO)。
+ 存在資料扭曲，一個運算子接收的事件比其他運算子多，可查看 Flink 儀表板中單個子任務 (即同一運算子的多個執行個體) 的進/出訊息數目進行驗證。
+ 這是一個消耗資源的操作 (如果沒有資料扭曲，請考慮橫向擴展 CPU/記憶體綁定的工作或增加 I/O 綁定工作的 `ParallelismPerKPU`)
+ 運算子中存在大量記錄 (將生產應用程式的記錄減少到最低限度，或者考慮將偵錯輸出發送到資料串流)。
## 使用捨棄接收器測試輸送量
[丟棄接收器](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html)只是忽略它在仍在執行應用程式時收到的所有事件 (沒有任何接收器的應用程式無法執行)。這對於輸送量測試、分析以及驗證應用程式是否正確擴展非常有用。這也是一種非常簡潔實用的完整性檢查，可以驗證接收器是否給應用程式導致背壓 (不過直接檢查背壓指標通常更容易和更直接)。
您可以透過用捨棄的接收器取代應用程式的所有接收器，並建立可產生與生產資料類似資料的模擬來源，來衡量應用程式在特定平行處理設定時的最大輸送量。然後，您也可以增加平行處理層級，以驗證應用程式是否正確擴展，並且沒有只在較高輸送量 (例如由於資料扭曲) 時才會出現的瓶頸。
# 資料扭曲
Flink 應用程式在叢集上分散式執行。為了橫向擴展到多個節點，Flink 使用了鍵控串流的概念，這實質上意味著某個串流的事件將依據特定索引鍵 (例如客戶 ID) 進行分割，然後 Flink 可以處理不同節點上的不同分割區。許多 Flink 運算子然後會根據這些分割區評估，例如[鍵控視窗](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/)、[處理函數](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/process_function/)和[非同步 I/O](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/)。
選擇分割區索引鍵通常取決於業務邏輯。同時，許多最佳實務 (例如 [DynamoDB](https://aws.amazon.com/dynamodb/) 和 Spark) 同樣適用於 Flink，包括：
+ 確保分割區索引鍵的高基數
+ 避免分割區之間的事件量扭曲
您可以比較 Flink 儀表板中接收/發送的子任務 (即同一運算子的多個執行個體) 的記錄數來識別分割區中是否存在扭曲。此外，Managed Service for Apache Flink 監控也可設定為公開子任務層級的 `numRecordsIn/Out` 和 `numRecordsInPerSecond/OutPerSecond` 指標。
# 狀態扭曲
對於有狀態運算子，即負責維護其業務邏輯 (如視窗) 狀態的運算子，資料扭曲總是會導致狀態扭曲。由於資料扭曲，某些子任務比其他子任務收到更多的事件，因此也在狀態中保留了更多資料。但是，即使對於具有均勻平衡分割區的應用程式，在狀態中保留多少資料也可能會出現扭曲。例如，對於工作階段視窗，某些使用者和工作階段分別都可能比其他使用者和工作階段長得多。如果較長的工作階段恰好是相同分割區的一部分，則可能導致相同運算子的不同子任務所保留的狀態大小不平衡。
狀態扭曲不僅增加了個別子任務所需的記憶體和磁碟資源，還會降低應用程式的整體效能。當應用程式取得檢查點或儲存點時，運算子狀態會保留在 Amazon S3 種，以保護狀態免受節點或叢集故障影響。在此處理程序期間 (特別是在 Managed Service for Apache Flink 上預設只啟用恰好一次的語義中)，處理會從外部暫停，直到檢查點/儲存點執行完成為止。如果有資料扭曲，則完成操作的時間可能會受到已累積了特別大量的狀態之單一子任務所限制。在極端情況下，由於單個子任務無法持續保留狀態，擷取檢查點/儲存點可能會失敗。
因此，與資料扭曲類似，狀態扭曲也會大幅降低應用程式執行速度。
若要識別狀態扭曲，可以利用 Flink 儀表板。尋找最新的檢查點或儲存點，並在詳細資料中比較已針對個別子任務儲存的資料量。
# 與不同區域中的資源整合
您可以啟用 `StreamingFileSink`，透過 Flink 組態中跨區域複寫所需的設定，從 Managed Service for Apache Flink 應用程式寫入不同區域中的 Amazon S3 儲存貯體。若要這樣做，請在 [AWS 支援 中心](https://console.aws.amazon.com/support/home#/)填寫支援票證。