Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan Masalah Layanan Terkelola untuk Apache Flink
Topik berikut dapat membantu Anda memecahkan masalah yang mungkin Anda temui dengan Amazon Managed Service for Apache Flink.
Pilih topik yang sesuai untuk meninjau solusi.
**Topics**
+ [Pemecahan masalah pengembangan](troubleshooting-development.md)
+ [Pemecahan masalah runtime](troubleshooting-runtime.md)
# Pemecahan masalah pengembangan
Bagian ini berisi informasi tentang mendiagnosis dan memperbaiki masalah pengembangan dengan Layanan Terkelola untuk aplikasi Apache Flink Anda.
**Topics**
+ [Praktik terbaik rollback sistem](troubleshooting-system-rollback.md)
+ [Praktik terbaik konfigurasi Hudi](troubleshooting-hudi.md)
+ [Grafik Api Apache Flink](troubleshooting-update-flamegraphs.md)
+ [Masalah penyedia kredensi dengan konektor EFO 1.15.2](troubleshooting-credential-provider.md)
+ [Aplikasi dengan konektor Kinesis yang tidak didukung](troubleshooting-unsupported-kinesis-connectors.md)
+ [Kesalahan kompilasi: “Tidak dapat menyelesaikan dependensi untuk proyek”](troubleshooting-compile.md)
+ [Pilihan tidak valid: “kinesisanalyticsv2"](troubleshooting-cli-update.md)
+ [UpdateApplication tindakan tidak memuat ulang kode aplikasi](troubleshooting-update.md)
+ [S3 StreamingFileSink FileNotFoundExceptions](troubleshooting-s3sink.md)
+ [FlinkKafkaConsumer masalah dengan berhenti dengan savepoint](troubleshooting-FlinkKafkaConsumer.md)
+ [Flink 1.15 Kebuntuan Wastafel Async](troubleshooting-async-deadlock.md)
+ [Data Amazon Kinesis mengalirkan pemrosesan sumber yang rusak selama re-sharding](troubleshooting-kinesis-data-streams-processing-out-of-order.md)
+ [Cetak biru penyematan vektor waktu nyata FAQ dan pemecahan masalah](troubleshooting-blueprints.md)
# Praktik terbaik rollback sistem
Dengan rollback sistem otomatis dan kemampuan visibilitas operasi di Amazon Managed Service untuk Apache Flink, Anda dapat mengidentifikasi dan menyelesaikan masalah dengan aplikasi Anda.
## Rollback sistem
Jika pembaruan aplikasi atau operasi penskalaan gagal karena kesalahan pelanggan, seperti bug kode atau masalah izin, Amazon Managed Service untuk Apache Flink secara otomatis mencoba untuk memutar kembali ke versi berjalan sebelumnya jika Anda telah memilih untuk menggunakan fungsi ini. Untuk informasi selengkapnya, lihat [Aktifkan rollback sistem untuk Layanan Terkelola Anda untuk aplikasi Apache Flink](how-system-rollbacks.md). Jika autorollback ini gagal atau Anda belum memilih atau memilih keluar, aplikasi Anda akan ditempatkan ke status. `READY` Untuk memperbarui aplikasi Anda, selesaikan langkah-langkah berikut: Periksa Amazon Managed Service untuk konsol Apache Flink atau gunakan `DescribeApplicationOperation` API untuk melihat deskripsi kesalahan mengapa operasi gagal. Untuk tumpukan kesalahan penuh, gunakan log [Cloudwatch](https://docs.aws.amazon.com/managed-flink/latest/java/logging.html). Masalah umum adalah izin yang tidak memadai, perubahan kode yang tidak kompatibel, atau kesalahan konfigurasi infrastruktur. Selesaikan masalah yang mendasarinya. Gunakan `UpdateApplicaton` API untuk menerapkan ulang versi aplikasi baru Anda.
## Rollback manual
Jika aplikasi tidak berkembang dan dalam keadaan sementara untuk waktu yang lama, atau jika aplikasi berhasil dialihkan ke`Running`, tetapi Anda melihat masalah hilir seperti memproses kesalahan dalam aplikasi Flink yang berhasil diperbarui, Anda dapat memutar kembali secara manual menggunakan API. `RollbackApplication`
1. Panggilan `RollbackApplication` - ini akan kembali ke versi berjalan sebelumnya dan mengembalikan status sebelumnya.
1. Pantau operasi rollback menggunakan API. `DescribeApplicationOperation`
1. Jika rollback gagal, gunakan langkah-langkah rollback sistem sebelumnya.
## Visibilitas operasi
`ListApplicationOperations`API menunjukkan riwayat semua operasi pelanggan dan sistem pada aplikasi Anda.
1. Dapatkan *operationId* dari operasi yang gagal dari daftar.
1. Panggil `DescribeApplicationOperation` dan periksa status dan *StatusDescription*.
1. Jika operasi gagal, deskripsi menunjukkan potensi kesalahan untuk diselidiki.
**Bug kode kesalahan umum:** Gunakan kemampuan rollback untuk kembali ke versi kerja terakhir. Selesaikan bug dan coba lagi pembaruan.
**Masalah izin:** Gunakan `DescribeApplicationOperation` untuk melihat izin yang diperlukan. Perbarui izin aplikasi dan coba lagi.
**Amazon Managed Service untuk masalah layanan Apache Flink:** Periksa Dasbor AWS Health atau buka kasus dukungan.
# Praktik terbaik konfigurasi Hudi
Untuk menjalankan konektor Hudi pada Layanan Terkelola untuk Apache Flink, kami merekomendasikan perubahan konfigurasi berikut.
Menonaktifkan `hoodie.embed.timeline.server`
Konektor Hudi di Flink menyiapkan server timeline (TM) tertanam di jobmanager Flink (JM) untuk menyimpan metadata untuk meningkatkan kinerja saat paralelisme pekerjaan tinggi. Kami menyarankan Anda menonaktifkan server tertanam ini pada Layanan Terkelola untuk Apache Flink karena kami menonaktifkan komunikasi non-FLink antara JM dan TM.
Jika server ini diaktifkan, Hudi menulis pertama-tama akan mencoba untuk terhubung ke server tertanam di JM, dan kemudian kembali membaca metadata dari Amazon S3. Ini berarti bahwa Hudi menimbulkan batas waktu koneksi yang menunda penulisan Hudi dan menyebabkan dampak kinerja pada Layanan Terkelola untuk Apache Flink.
# Grafik Api Apache Flink
Grafik Flame diaktifkan secara default pada aplikasi di Managed Service untuk versi Apache Flink yang mendukungnya. Grafik Api dapat memengaruhi kinerja aplikasi jika Anda membiarkan grafik tetap terbuka, seperti yang disebutkan dalam dokumentasi [Flink](https://nightlies.apache.org/flink/flink-docs-release-1.15//docs/ops/debugging/flame_graphs/).
Jika Anda ingin menonaktifkan Flame Graphs untuk aplikasi Anda, buat case untuk memintanya dinonaktifkan untuk ARN aplikasi Anda. Untuk informasi selengkapnya, lihat [Pusat AWS Dukungan](https://console.aws.amazon.com/support/home#/).
# Masalah penyedia kredensi dengan konektor EFO 1.15.2
Ada [masalah yang diketahui](https://issues.apache.org/jira/browse/FLINK-29205) dengan versi konektor EFO Kinesis Data Streams hingga 1.15.2 `FlinkKinesisConsumer` di mana konfigurasi tidak menghormati. `Credential Provider` Konfigurasi yang valid diabaikan karena masalah, yang mengakibatkan penyedia `AUTO` kredensi digunakan. Hal ini dapat menyebabkan masalah menggunakan akses lintas akun ke Kinesis menggunakan konektor EFO.
Untuk mengatasi kesalahan ini, gunakan konektor EFO versi 1.15.3 atau lebih tinggi.
# Aplikasi dengan konektor Kinesis yang tidak didukung
Managed Service untuk Apache Flink untuk Apache Flink versi 1.15 atau yang lebih baru akan [secara otomatis menolak aplikasi dari memulai atau memperbarui](https://docs.aws.amazon.com/managed-flink/latest/java/flink-1-15-2.html) jika mereka menggunakan versi Kinesis Connector yang tidak didukung (pra-versi 1.15.2) yang dibundel ke dalam aplikasi atau arsip (ZIP). JARs
## Kesalahan penolakan
Anda akan melihat kesalahan berikut saat mengirimkan panggilan aplikasi buat/perbarui melalui:
```
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
```
## Langkah-langkah untuk memulihkan
+ Perbarui ketergantungan aplikasi pada`flink-connector-kinesis`. Jika Anda menggunakan Maven sebagai alat pembuatan proyek Anda, ikuti. [Perbarui ketergantungan Maven](#troubleshooting-unsupported-kinesis-connectors-update-maven-dependency) Jika Anda menggunakan Gradle, ikuti[Memperbarui ketergantungan Gradle](#troubleshooting-unsupported-kinesis-connectors-update-gradle-dependency).
+ Paket ulang aplikasi.
+ Unggah ke bucket Amazon S3.
+ Kirim ulang permintaan aplikasi buat/perbarui dengan aplikasi yang direvisi yang baru saja diunggah ke bucket Amazon S3.
+ Jika Anda terus melihat pesan kesalahan yang sama, periksa kembali dependensi aplikasi Anda. Jika masalah berlanjut, silakan buat tiket dukungan.
### Perbarui ketergantungan Maven
1. Buka proyek`pom.xml`.
1. Temukan dependensi proyek. Mereka terlihat seperti:
```
...
...
org.apache.flink
flink-connector-kinesis
...
...
```
1. Perbarui `flink-connector-kinesis` ke versi yang sama dengan atau lebih baru dari 1.15.2. Misalnya:
```
...
...
org.apache.flink
flink-connector-kinesis
1.15.2
...
...
```
### Memperbarui ketergantungan Gradle
1. Buka proyek `build.gradle` (atau `build.gradle.kts` untuk aplikasi Kotlin).
1. Temukan dependensi proyek. Mereka terlihat seperti:
```
...
dependencies {
...
implementation("org.apache.flink:flink-connector-kinesis")
...
}
...
```
1. Perbarui `flink-connector-kinesis` ke versi yang sama dengan atau lebih baru dari 1.15.2. Misalnya:
```
...
dependencies {
...
implementation("org.apache.flink:flink-connector-kinesis:1.15.2")
...
}
...
```
# Kesalahan kompilasi: “Tidak dapat menyelesaikan dependensi untuk proyek”
Untuk mengkompilasi Layanan Terkelola untuk aplikasi sampel Apache Flink, Anda harus terlebih dahulu mengunduh dan mengkompilasi konektor Apache Flink Kinesis dan menambahkannya ke repositori Maven lokal Anda. Jika konektor belum ditambahkan ke repositori Anda, kesalahan kompilasi yang mirip dengan berikut akan muncul:
```
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
```
Untuk mengatasi kesalahan ini, Anda harus mengunduh kode sumber Apache Flink (versi 1.8.2 dari [https://flink.apache.org/downloads.html](https://flink.apache.org/downloads.html)) untuk konektor. Untuk petunjuk tentang cara mengunduh, mengumpulkan, dan menginstal kode sumber Apache Flink, lihat [Menggunakan konektor Apache Flink Kinesis Streams dengan versi Apache Flink sebelumnya](earlier.md#how-creating-apps-building-kinesis).
# Pilihan tidak valid: “kinesisanalyticsv2"
Untuk menggunakan v2 dari Managed Service for Apache Flink API, Anda memerlukan versi terbaru dari AWS Command Line Interface ()AWS CLI.
Untuk informasi tentang memutakhirkan AWS CLI, lihat [Menginstal AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/installing.html) di *Panduan AWS Command Line Interface Pengguna*.
# UpdateApplication tindakan tidak memuat ulang kode aplikasi
[UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)Tindakan tidak akan memuat ulang kode aplikasi dengan nama file yang sama jika tidak ada versi objek S3 yang ditentukan. Untuk memuat ulang kode aplikasi dengan nama file yang sama, aktifkan versioning pada bucket S3 Anda, dan tentukan versi objek baru menggunakan parameter `ObjectVersionUpdate`. Untuk informasi selengkapnya tentang mengaktifkan versioning objek di bucket S3, lihat [Mengaktifkan dan Menonaktifkan Versioning](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-versioning.html).
# S3 StreamingFileSink FileNotFoundExceptions
Layanan Terkelola untuk aplikasi Apache Flink dapat berjalan ke file bagian dalam proses `FileNotFoundException` saat memulai dari snapshot jika file bagian dalam proses yang dirujuk oleh savepoint-nya tidak ada. Ketika mode kegagalan ini terjadi, status operator aplikasi Managed Service for Apache Flink biasanya tidak dapat dipulihkan dan harus dimulai ulang tanpa menggunakan snapshot. `SKIP_RESTORE_FROM_SNAPSHOT` Lihat contoh stacktrace berikut:
```
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` menulis catatan ke sistem file yang didukung oleh Sistem File.](https://nightlies.apache.org/flink/flink-docs-release-1.15/docs/deployment/filesystems/overview/) Mengingat bahwa aliran yang masuk dapat tidak dibatasi, data diatur ke dalam file bagian dengan ukuran terbatas dengan file baru ditambahkan saat data ditulis. Kebijakan siklus hidup dan rollover bagian menentukan waktu, ukuran, dan penamaan file bagian.
Selama checkpointing dan savepointing (snapshotting), semua file yang Tertunda diganti namanya dan dikomit. Namun, file bagian dalam proses tidak dikomit tetapi diganti namanya dan referensi mereka disimpan dalam pos pemeriksaan atau metadata savepoint untuk digunakan saat memulihkan pekerjaan. File bagian dalam proses ini pada akhirnya akan bergulir ke Pending, diganti namanya, dan dilakukan oleh pos pemeriksaan atau savepoint berikutnya.
Berikut ini adalah akar penyebab dan mitigasi untuk file bagian dalam proses yang hilang:
+ Snapshot basi digunakan untuk memulai Layanan Terkelola untuk aplikasi Apache Flink - hanya snapshot sistem terbaru yang diambil saat aplikasi dihentikan atau diperbarui yang dapat digunakan untuk memulai Layanan Terkelola untuk aplikasi Apache Flink dengan Amazon S3. StreamingFileSink Untuk menghindari kelas kegagalan ini, gunakan snapshot sistem terbaru.
+ Ini terjadi misalnya ketika Anda memilih snapshot yang dibuat menggunakan `CreateSnapshot` alih-alih Snapshot yang dipicu sistem selama berhenti atau memperbarui. Savepoint snapshot yang lebih lama menyimpan out-of-date referensi ke file bagian dalam proses yang telah diganti namanya dan dilakukan oleh pos pemeriksaan atau savepoint berikutnya.
+ Ini juga dapat terjadi ketika snapshot yang dipicu sistem dari Stop/Update acara non-terbaru dipilih. Contohnya adalah aplikasi dengan snapshot sistem dinonaktifkan tetapi telah `RESTORE_FROM_LATEST_SNAPSHOT` dikonfigurasi. Umumnya, Layanan Terkelola untuk aplikasi Apache Flink dengan Amazon StreamingFileSink S3 harus selalu mengaktifkan dan mengonfigurasi snapshot sistem. `RESTORE_FROM_LATEST_SNAPSHOT`
+ File bagian dalam proses dihapus — Karena file bagian yang sedang berlangsung terletak di bucket S3, file tersebut dapat dihapus oleh komponen atau aktor lain yang memiliki akses ke bucket.
+ Hal ini dapat terjadi jika Anda telah menghentikan aplikasi terlalu lama dan file bagian dalam proses yang dirujuk oleh savepoint aplikasi Anda telah dihapus oleh kebijakan siklus hidup bucket [S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpu-abort-incomplete-mpu-lifecycle-config.html). MultiPartUpload Untuk menghindari kelas kegagalan ini, pastikan bahwa kebijakan siklus hidup S3 Bucket MPU Anda mencakup periode yang cukup besar untuk kasus penggunaan Anda.
+ Ini juga dapat terjadi ketika file bagian dalam proses telah dihapus secara manual atau oleh salah satu komponen sistem Anda. Untuk menghindari kelas kegagalan ini, pastikan bahwa file bagian dalam proses tidak dihapus oleh aktor atau komponen lain.
+ Kondisi balapan di mana pos pemeriksaan otomatis dipicu setelah savepoint - Ini memengaruhi Layanan Terkelola untuk versi Apache Flink hingga dan termasuk 1.13. Masalah ini diperbaiki di Managed Service untuk Apache Flink versi 1.15. Migrasikan aplikasi Anda ke versi terbaru Layanan Terkelola untuk Apache Flink untuk mencegah kekambuhan. Kami juga menyarankan untuk bermigrasi dari StreamingFileSink ke [FileSink](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/connectors/datastream/filesystem/#file-sink).
+ Ketika aplikasi dihentikan atau diperbarui, Managed Service for Apache Flink memicu savepoint dan menghentikan aplikasi dalam dua langkah. Jika pos pemeriksaan otomatis terpicu di antara dua langkah, savepoint tidak akan dapat digunakan karena file bagian yang sedang berlangsung akan diganti namanya dan berpotensi dikomit.
# FlinkKafkaConsumer masalah dengan berhenti dengan savepoint
Saat menggunakan legacy FlinkKafkaConsumer ada kemungkinan aplikasi Anda mungkin macet dalam UPDATE, STOPING atau SCALING, jika Anda mengaktifkan snapshot sistem. Tidak ada perbaikan yang dipublikasikan yang tersedia untuk [masalah](https://issues.apache.org/jira/browse/FLINK-28758) ini, oleh karena itu kami sarankan Anda meningkatkan ke yang baru [KafkaSource](https://nightlies.apache.org/flink/flink-docs-master/docs/connectors/datastream/kafka/#kafka-source)untuk mengurangi masalah ini.
Jika Anda menggunakan snapshot `FlinkKafkaConsumer` with diaktifkan, ada kemungkinan saat pekerjaan Flink memproses stop dengan permintaan API savepoint, kesalahan `FlinkKafkaConsumer` dapat gagal dengan kesalahan runtime yang melaporkan file. `ClosedException` Dalam kondisi ini aplikasi Flink menjadi macet, bermanifestasi sebagai Pos Pemeriksaan Gagal.
# Flink 1.15 Kebuntuan Wastafel Async
Ada [masalah yang diketahui](https://issues.apache.org/jira/browse/FLINK-32230) dengan AWS konektor untuk antarmuka implementasi AsyncSink Apache Flink. Ini memengaruhi aplikasi yang menggunakan Flink 1.15 dengan konektor berikut:
+ Untuk aplikasi 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/TableAPI/PythonAplikasi Flink:
+ kinesis — `org.apache.flink:flink-sql-connector-kinesis`
+ kinesis — `org.apache.flink:flink-sql-connector-aws-kinesis-streams`
+ selang api — `org.apache.flink:flink-sql-connector-aws-kinesis-firehose`
+ dinamodb — `org.apache.flink:flink-sql-connector-dynamodb`
Aplikasi yang terpengaruh akan mengalami gejala berikut:
+ Pekerjaan Flink dalam `RUNNING` keadaan, tetapi tidak memproses data;
+ Tidak ada pekerjaan restart;
+ Pos pemeriksaan sudah habis waktu.
Masalah ini disebabkan oleh [bug](https://github.com/aws/aws-sdk-java-v2/issues/4354) di AWS SDK sehingga tidak memunculkan kesalahan tertentu ke pemanggil saat menggunakan klien HTTP async. Hal ini mengakibatkan wastafel menunggu tanpa batas waktu untuk “permintaan dalam penerbangan” selesai selama operasi flush pos pemeriksaan.
Masalah ini telah diperbaiki di AWS SDK mulai dari versi **2.20.144**.
Berikut adalah petunjuk tentang cara memperbarui konektor yang terpengaruh untuk menggunakan versi baru AWS SDK di aplikasi Anda:
**Topics**
+ [Perbarui aplikasi Java](troubleshooting-async-deadlock-update-java-apps.md)
+ [Perbarui aplikasi Python](troubleshooting-async-deadlock-update-python-apps.md)
# Perbarui aplikasi Java
Ikuti prosedur di bawah ini untuk memperbarui aplikasi Java:
## flink-connector-kinesis
Jika aplikasi menggunakan`flink-connector-kinesis`:
Konektor Kinesis menggunakan shading untuk mengemas beberapa dependensi, termasuk AWS SDK, ke dalam stoples konektor. Untuk memperbarui versi AWS SDK, gunakan prosedur berikut untuk mengganti kelas berbayang ini:
------
#### [ Maven ]
1. Tambahkan konektor Kinesis dan modul AWS SDK yang diperlukan sebagai dependensi proyek.
1. Konfigurasikan`maven-shade-plugin`:
1. Tambahkan filter untuk mengecualikan kelas AWS SDK yang diarsir saat menyalin konten jar konektor Kinesis.
1. Tambahkan aturan relokasi untuk memindahkan kelas AWS SDK yang diperbarui ke paket, yang diharapkan oleh konektor 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. Tambahkan konektor Kinesis dan modul AWS SDK yang diperlukan sebagai dependensi proyek.
1. Sesuaikan konfigurasi ShadowJar:
1. Kecualikan kelas AWS SDK yang diarsir saat menyalin konten jar konektor Kinesis.
1. Pindahkan kelas AWS SDK yang diperbarui ke paket yang diharapkan oleh konektor 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")
}
...
```
------
## Konektor lain yang terpengaruh
Jika aplikasi menggunakan konektor lain yang terpengaruh:
Untuk memperbarui versi AWS SDK, versi SDK harus diterapkan dalam konfigurasi build proyek.
------
#### [ Maven ]
Tambahkan AWS SDK bill of materials (BOM) ke bagian manajemen dependensi `pom.xml` file untuk menerapkan versi SDK untuk proyek.
**pom.xml**
```
...
...
software.amazon.awssdk
bom
2.20.144
import
pom
...
...
```
------
#### [ Gradle ]
Tambahkan ketergantungan platform pada bill of materials AWS SDK (BOM) untuk menerapkan versi SDK untuk proyek. Ini membutuhkan Gradle 5.0 atau yang lebih baru:
**build.gradle**
```
...
dependencies {
...
flinkShadowJar(platform("software.amazon.awssdk:bom:2.20.144"))
...
}
...
```
------
# Perbarui aplikasi Python
Aplikasi Python dapat menggunakan konektor dalam 2 cara berbeda: konektor pengemasan dan dependensi Java lainnya sebagai bagian dari tabung uber tunggal, atau menggunakan jar konektor secara langsung. Untuk memperbaiki aplikasi yang terpengaruh oleh kebuntuan Async Sink:
+ Jika aplikasi menggunakan toples uber, ikuti instruksi untuk[Perbarui aplikasi Java](troubleshooting-async-deadlock-update-java-apps.md).
+ Untuk membangun kembali stoples konektor dari sumber, gunakan langkah-langkah berikut:
**Membangun konektor dari sumber:**
[Prasyarat, mirip dengan persyaratan build 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. Unduh kode sumber untuk Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Buka kompres kode sumber:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Arahkan ke direktori konektor kinesis
```
cd flink-1.15.4/flink-connectors/flink-connector-kinesis/
```
1. Kompilasi dan instal jar konektor, tentukan versi AWS SDK yang diperlukan. Untuk mempercepat penggunaan build `-DskipTests` untuk melewati eksekusi pengujian dan `-Dfast` melewati pemeriksaan kode sumber tambahan:
```
mvn clean install -DskipTests -Dfast -Daws.sdkv2.version=2.20.144
```
1. Arahkan ke direktori konektor kinesis
```
cd ../flink-sql-connector-kinesis
```
1. Kompilasi dan pasang jar konektor sql:
```
mvn clean install -DskipTests -Dfast
```
1. Jar yang dihasilkan akan tersedia di:
```
target/flink-sql-connector-kinesis-1.15.4.jar
```
## flink-sql-connector-aws-kinesis-aliran
1. Unduh kode sumber untuk Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Buka kompres kode sumber:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Arahkan ke direktori konektor kinesis
```
cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-streams/
```
1. Kompilasi dan instal jar konektor, tentukan versi AWS SDK yang diperlukan. Untuk mempercepat penggunaan build `-DskipTests` untuk melewati eksekusi pengujian dan `-Dfast` melewati pemeriksaan kode sumber tambahan:
```
mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144
```
1. Arahkan ke direktori konektor kinesis
```
cd ../flink-sql-connector-aws-kinesis-streams
```
1. Kompilasi dan pasang jar konektor sql:
```
mvn clean install -DskipTests -Dfast
```
1. Jar yang dihasilkan akan tersedia di:
```
target/flink-sql-connector-aws-kinesis-streams-1.15.4.jar
```
## flink-sql-connector-aws-kinesis-firehose
1. Unduh kode sumber untuk Flink 1.15.4:
```
wget https://archive.apache.org/dist/flink/flink-1.15.4/flink-1.15.4-src.tgz
```
1. Buka kompres kode sumber:
```
tar -xvf flink-1.15.4-src.tgz
```
1. Arahkan ke direktori konektor
```
cd flink-1.15.4/flink-connectors/flink-connector-aws-kinesis-firehose/
```
1. Kompilasi dan instal jar konektor, tentukan versi AWS SDK yang diperlukan. Untuk mempercepat penggunaan build `-DskipTests` untuk melewati eksekusi pengujian dan `-Dfast` melewati pemeriksaan kode sumber tambahan:
```
mvn clean install -DskipTests -Dfast -Daws.sdk.version=2.20.144
```
1. Arahkan ke direktori konektor sql
```
cd ../flink-sql-connector-aws-kinesis-firehose
```
1. Kompilasi dan pasang jar konektor sql:
```
mvn clean install -DskipTests -Dfast
```
1. Jar yang dihasilkan akan tersedia di:
```
target/flink-sql-connector-aws-kinesis-firehose-1.15.4.jar
```
## flink-sql-connector-dynamodb
1. Unduh kode sumber untuk 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. Buka kompres kode sumber:
```
tar -xvf flink-connector-aws-3.0.0-src.tgz
```
1. Arahkan ke direktori konektor
```
cd flink-connector-aws-3.0.0
```
1. Kompilasi dan instal jar konektor, tentukan versi AWS SDK yang diperlukan. Untuk mempercepat penggunaan build `-DskipTests` untuk melewati eksekusi pengujian dan `-Dfast` melewati pemeriksaan kode sumber tambahan:
```
mvn clean install -DskipTests -Dfast -Dflink.version=1.15.4 -Daws.sdk.version=2.20.144
```
1. Jar yang dihasilkan akan tersedia di:
```
flink-sql-connector-dynamodb/target/flink-sql-connector-dynamodb-3.0.0.jar
```
# Data Amazon Kinesis mengalirkan pemrosesan sumber yang rusak selama re-sharding
FlinkKinesisConsumer Implementasi saat ini tidak memberikan jaminan pemesanan yang kuat antara pecahan Kinesis. Hal ini dapat menyebabkan out-of-order pemrosesan selama re-sharding Kinesis Stream, khususnya untuk aplikasi Flink yang mengalami kelambatan pemrosesan. Dalam beberapa keadaan, misalnya operator windows berdasarkan waktu acara, peristiwa mungkin dibuang karena keterlambatan yang dihasilkan.
![\[Diagram showing shards and shard consumers with time progression and trim horizon.\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/flink-ts.png)
Ini adalah [masalah yang diketahui](https://issues.apache.org/jira/browse/FLINK-6349) di Open Source Flink. Sampai perbaikan konektor tersedia, pastikan aplikasi Flink Anda tidak tertinggal di belakang Kinesis Data Streams selama partisi ulang. Dengan memastikan bahwa penundaan pemrosesan ditoleransi oleh aplikasi Flink Anda, Anda dapat meminimalkan dampak out-of-order pemrosesan dan risiko kehilangan data.
# Cetak biru penyematan vektor waktu nyata FAQ dan pemecahan masalah
Tinjau bagian FAQ dan pemecahan masalah berikut untuk memecahkan masalah cetak biru penyematan vektor waktu nyata. Untuk informasi selengkapnya tentang cetak biru penyematan vektor waktu nyata, lihat Cetak biru penyematan vektor [waktu nyata](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html).
[Untuk pemecahan masalah aplikasi Apache Flink Layanan Terkelola umum, lihat -runtime.html. https://docs.aws.amazon.com/managed-flink/ latest/java/troubleshooting](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html)
**Topics**
+ [Cetak biru penyematan vektor waktu nyata - FAQ](troubleshooting-blueprints-FAQ.md)
+ [Cetak biru penyematan vektor waktu nyata - pemecahan masalah](troubleshooting-blueprints-TS.md)
# Cetak biru penyematan vektor waktu nyata - FAQ
Tinjau FAQ berikut tentang cetak biru penyematan vektor waktu nyata. Untuk informasi selengkapnya tentang cetak biru penyematan vektor waktu nyata, lihat Cetak biru penyematan vektor [waktu nyata](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html).
**Topics**
+ [AWS Sumber daya apa yang dibuat cetak biru ini?](#troubleshooting-blueprints-1)
+ [Apa tindakan saya setelah penerapan AWS CloudFormation tumpukan selesai?](#troubleshooting-blueprints-2)
+ [Apa yang seharusnya menjadi struktur data dalam topik MSK Amazon sumber?](#troubleshooting-blueprints-3)
+ [Dapatkah saya menentukan bagian dari pesan untuk disematkan?](#troubleshooting-blueprints-4)
+ [Dapatkah saya membaca data dari beberapa topik MSK Amazon?](#troubleshooting-blueprints-5)
+ [Dapatkah saya menggunakan regex untuk mengonfigurasi nama topik MSK Amazon?](#troubleshooting-blueprints-6)
+ [Berapa ukuran maksimum pesan yang dapat dibaca dari topik MSK Amazon?](#troubleshooting-blueprints-7)
+ [Jenis apa OpenSearch yang didukung?](#troubleshooting-blueprints-8)
+ [Mengapa saya perlu menggunakan koleksi pencarian vektor, indeks vektor, dan menambahkan bidang vektor di kolelksi OpenSearch Tanpa Server saya?](#troubleshooting-blueprints-9)
+ [Apa yang harus saya tetapkan sebagai dimensi untuk bidang vektor saya?](#troubleshooting-blueprints-10)
+ [Seperti apa output dalam OpenSearch indeks yang dikonfigurasi?](#troubleshooting-blueprints-11)
+ [Dapatkah saya menentukan bidang metadata untuk ditambahkan ke dokumen yang disimpan dalam indeks? OpenSearch](#troubleshooting-blueprints-12)
+ [Haruskah saya mengharapkan entri duplikat dalam indeks? OpenSearch](#troubleshooting-blueprints-13)
+ [Dapatkah saya mengirim data ke beberapa OpenSearch indeks?](#troubleshooting-blueprints-14)
+ [Dapatkah saya menerapkan beberapa aplikasi penyematan vektor real-time dalam satu aplikasi? Akun AWS](#troubleshooting-blueprints-15)
+ [Dapatkah beberapa aplikasi penyematan vektor waktu nyata menggunakan sumber atau sink data yang sama?](#troubleshooting-blueprints-16)
+ [Apakah aplikasi mendukung konektivitas lintas akun?](#troubleshooting-blueprints-17)
+ [Apakah aplikasi mendukung konektivitas lintas wilayah?](#troubleshooting-blueprints-18)
+ [Bisakah cluster dan OpenSearch koleksi MSK Amazon saya berbeda VPCs atau subnet?](#troubleshooting-blueprints-19)
+ [Model penyematan apa yang didukung oleh aplikasi?](#troubleshooting-blueprints-20)
+ [Dapatkah saya menyempurnakan kinerja aplikasi saya berdasarkan beban kerja saya?](#troubleshooting-blueprints-21)
+ [Jenis otentikasi MSK Amazon apa yang didukung?](#troubleshooting-blueprints-22)
+ [Apa itu `sink.os.bulkFlushIntervalMillis` dan bagaimana cara mengaturnya?](#troubleshooting-blueprints-23)
+ [Ketika saya menerapkan Layanan Terkelola untuk aplikasi Apache Flink saya, dari titik mana dalam topik MSK Amazon akan mulai membaca pesan?](#troubleshooting-blueprints-24)
+ [Bagaimana cara saya menggunakan`source.msk.starting.offset`?](#troubleshooting-blueprints-25)
+ [Strategi chunking apa yang didukung?](#troubleshooting-blueprints-26)
+ [Bagaimana cara membaca catatan di datastore vektor saya?](#troubleshooting-blueprints-27)
+ [Di mana saya dapat menemukan pembaruan baru untuk kode sumber?](#troubleshooting-blueprints-28)
+ [Dapatkah saya membuat perubahan pada AWS CloudFormation template dan memperbarui Layanan Terkelola untuk aplikasi Apache Flink?](#troubleshooting-blueprints-29)
+ [Apakah akan AWS memantau dan memelihara aplikasi atas nama saya?](#troubleshooting-blueprints-30)
+ [Apakah aplikasi ini memindahkan data saya ke luar saya Akun AWS?](#troubleshooting-blueprints-31)
## AWS Sumber daya apa yang dibuat cetak biru ini?
Untuk menemukan sumber daya yang digunakan di akun Anda, navigasikan ke AWS CloudFormation konsol dan identifikasi nama tumpukan yang dimulai dengan nama yang Anda berikan untuk aplikasi Managed Service for Apache Flink. Pilih tab **Sumber Daya** untuk memeriksa sumber daya yang dibuat sebagai bagian dari tumpukan. Berikut ini adalah sumber daya utama yang dibuat oleh stack:
+ Penyematan vektor real-time Layanan Terkelola untuk aplikasi Apache Flink
+ Bucket Amazon S3 untuk menyimpan kode sumber untuk aplikasi penyematan vektor waktu nyata
+ CloudWatch grup log dan aliran log untuk menyimpan log
+ Fungsi Lambda untuk mengambil dan membuat sumber daya
+ Peran dan kebijakan IAM untuk Lambdas, Layanan Terkelola untuk aplikasi Apache Flink, dan mengakses Amazon Bedrock dan Amazon Service OpenSearch
+ Kebijakan akses data untuk Amazon OpenSearch Service
+ Titik akhir VPC untuk mengakses Amazon Bedrock dan Amazon Service OpenSearch
## Apa tindakan saya setelah penerapan AWS CloudFormation tumpukan selesai?
Setelah penyebaran AWS CloudFormation tumpukan selesai, akses Managed Service for Apache Flink console dan temukan blueprint Managed Service for Apache Flink Anda. Pilih tab **Configure** dan konfirmasikan bahwa semua properti runtime diatur dengan benar. Mereka mungkin meluap ke halaman berikutnya. Saat Anda yakin dengan pengaturannya, pilih **Jalankan**. Aplikasi akan mulai menelan pesan dari topik Anda.
Untuk memeriksa rilis baru, lihat [https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases).
## Apa yang seharusnya menjadi struktur data dalam topik MSK Amazon sumber?
Saat ini kami mendukung data sumber terstruktur dan tidak terstruktur.
+ Data tidak terstruktur dilambangkan dengan in. `STRING` `source.msk.data.type` Data dibaca apa adanya dari pesan yang masuk.
+ Saat ini kami mendukung data JSON terstruktur, dilambangkan dengan in. `JSON` `source.msk.data.type` Data harus selalu dalam format JSON. Jika aplikasi menerima JSON yang cacat, aplikasi akan gagal.
+ Saat menggunakan JSON sebagai tipe data sumber, pastikan bahwa setiap pesan di semua topik sumber adalah JSON yang valid. Jika Anda berlangganan satu atau lebih topik yang tidak berisi objek JSON dengan pengaturan ini, aplikasi akan gagal. Jika satu atau beberapa topik memiliki campuran data terstruktur dan tidak terstruktur, sebaiknya Anda mengonfigurasi data sumber sebagai tidak terstruktur dalam aplikasi Managed Service for Apache Flink.
## Dapatkah saya menentukan bagian dari pesan untuk disematkan?
+ Untuk data input yang tidak terstruktur`STRING`, aplikasi akan selalu menyematkan seluruh pesan dan menyimpan seluruh pesan dalam indeks yang dikonfigurasi OpenSearch . `source.msk.data.type`
+ Untuk data input terstruktur di `source.msk.data.type` mana`JSON`, Anda dapat mengonfigurasi `embed.input.config.json.fieldsToEmbed` untuk menentukan bidang mana di objek JSON yang harus dipilih untuk disematkan. Ini hanya berfungsi untuk bidang JSON tingkat atas dan tidak berfungsi dengan bersarang JSONs dan dengan pesan yang berisi array JSON. Gunakan .\$1 untuk menyematkan seluruh JSON.
## Dapatkah saya membaca data dari beberapa topik MSK Amazon?
Ya, Anda dapat membaca data dari beberapa topik MSK Amazon dengan aplikasi ini. Data dari semua topik harus dari jenis yang sama (baik STRING atau JSON) atau dapat menyebabkan aplikasi gagal. Data dari semua topik selalu disimpan dalam satu OpenSearch indeks.
## Dapatkah saya menggunakan regex untuk mengonfigurasi nama topik MSK Amazon?
`source.msk.topic.names`tidak mendukung daftar regex. Kami mendukung daftar nama topik atau `.*` regex yang dipisahkan koma untuk menyertakan semua topik.
## Berapa ukuran maksimum pesan yang dapat dibaca dari topik MSK Amazon?
Ukuran maksimum pesan yang dapat diproses dibatasi oleh batas InvokeModel tubuh Amazon Bedrock yang saat ini ditetapkan menjadi 25.000.000. Untuk informasi selengkapnya, lihat [InvokeModel](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html#API_runtime_InvokeModel_RequestBody).
## Jenis apa OpenSearch yang didukung?
Kami mendukung OpenSearch domain dan koleksi. Jika Anda menggunakan OpenSearch koleksi, pastikan untuk menggunakan koleksi vektor dan membuat indeks vektor untuk digunakan untuk aplikasi ini. Ini akan memungkinkan Anda menggunakan kemampuan database OpenSearch vektor untuk query data Anda. Untuk mempelajari selengkapnya, lihat [dijelaskan kapabilitas database vektor Amazon OpenSearch Service](https://aws.amazon.com/blogs/big-data/amazon-opensearch-services-vector-database-capabilities-explained/).
## Mengapa saya perlu menggunakan koleksi pencarian vektor, indeks vektor, dan menambahkan bidang vektor di kolelksi OpenSearch Tanpa Server saya?
Jenis koleksi *pencarian vektor* di OpenSearch Tanpa Server memberikan kemampuan pencarian kesamaan yang dapat diskalakan dan berkinerja tinggi. Ini merampingkan pembangunan pengalaman pencarian tambahan pembelajaran mesin (ML) modern dan aplikasi kecerdasan buatan (AI) generatif. Untuk informasi selengkapnya, lihat [Bekerja dengan koleksi pencarian vektor](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html?icmpid=docs_console_unmapped).
## Apa yang harus saya tetapkan sebagai dimensi untuk bidang vektor saya?
Atur dimensi bidang vektor berdasarkan model penyematan yang ingin Anda gunakan. Lihat tabel berikut, dan konfirmasikan nilai-nilai ini dari dokumentasi masing-masing.
**Dimensi bidang vektor**
| Nama model penyematan vektor Amazon Bedrock | Dukungan dimensi output yang ditawarkan oleh model |
| --- | --- |
| Embeddings Teks Amazon Titan V1 | 1,536 |
| Embeddings Teks Amazon Titan V2 | 1.024 (default), 384, 256 |
| Embeddings Multimodal Amazon Titan G1 | 1.024 (default), 384, 256 |
| Cohere Sematkan Bahasa Inggris | 1,024 |
| Cohere Sematkan Multilingual | 1,024 |
## Seperti apa output dalam OpenSearch indeks yang dikonfigurasi?
Setiap dokumen dalam OpenSearch indeks berisi bidang-bidang berikut:
+ **original\$1data: Data** yang digunakan untuk menghasilkan embeddings. Untuk tipe STRING, itu adalah seluruh pesan. Untuk objek JSON, itu adalah objek JSON yang digunakan untuk penyematan. Bisa jadi seluruh JSON dalam pesan atau bidang tertentu di JSON. Misalnya, jika nama dipilih untuk disematkan dari pesan masuk, output akan terlihat sebagai berikut:
```
"original_data": "{\"name\":\"John Doe\"}"
```
+ **embedded\$1data**: Array float vektor dari embeddings yang dihasilkan oleh Amazon Bedrock
+ **tanggal**: stempel waktu UTC di mana dokumen disimpan OpenSearch
## Dapatkah saya menentukan bidang metadata untuk ditambahkan ke dokumen yang disimpan dalam indeks? OpenSearch
Tidak, saat ini, kami tidak mendukung penambahan bidang tambahan ke dokumen akhir yang disimpan dalam OpenSearch indeks.
## Haruskah saya mengharapkan entri duplikat dalam indeks? OpenSearch
Bergantung pada cara Anda mengonfigurasi aplikasi, Anda mungkin melihat pesan duplikat dalam indeks. Salah satu alasan umum adalah restart aplikasi. Aplikasi ini dikonfigurasi secara default untuk mulai membaca dari pesan paling awal dalam topik sumber. Ketika Anda mengubah configuraiton, aplikasi restart, dan memproses semua pesan dalam topik lagi. Untuk menghindari pemrosesan ulang, lihat dokumentasi tentang cara menggunakan source.msk.starting.offset dan atur offset awal aplikasi Anda dengan benar.
## Dapatkah saya mengirim data ke beberapa OpenSearch indeks?
Tidak, aplikasi mendukung penyimpanan data ke OpenSearch indeks tunggal. Untuk mengatur output vektorisasi ke beberapa indeks, Anda harus menerapkan Layanan Terkelola terpisah untuk aplikasi Apache Flink.
## Dapatkah saya menerapkan beberapa aplikasi penyematan vektor real-time dalam satu aplikasi? Akun AWS
Ya, Anda dapat menerapkan beberapa penyematan vektor real-time Layanan Terkelola untuk aplikasi Apache Flink dalam satu Akun AWS jika setiap aplikasi memiliki nama yang unik.
## Dapatkah beberapa aplikasi penyematan vektor waktu nyata menggunakan sumber atau sink data yang sama?
Ya, Anda dapat membuat beberapa vektor real-time embedding Managed Service untuk aplikasi Apache Flink yang membaca data dari topik yang sama atau menyimpan data dalam indeks yang sama.
## Apakah aplikasi mendukung konektivitas lintas akun?
Tidak, agar aplikasi berjalan dengan sukses, kluster MSK Amazon dan OpenSearch koleksinya harus sama di Akun AWS mana Anda mencoba mengatur Layanan Terkelola untuk aplikasi Apache Flink Anda.
## Apakah aplikasi mendukung konektivitas lintas wilayah?
Tidak, aplikasi ini hanya memungkinkan Anda untuk menyebarkan Layanan Terkelola untuk aplikasi Apache Flink dengan cluster MSK Amazon dan OpenSearch koleksi di Wilayah yang sama dari Layanan Terkelola untuk aplikasi Apache Flink.
## Bisakah cluster dan OpenSearch koleksi MSK Amazon saya berbeda VPCs atau subnet?
Ya, kami mendukung cluster dan OpenSearch koleksi MSK Amazon di berbagai subnet VPCs dan selama keduanya sama. Akun AWS Lihat (Pemecahan masalah MSF Umum) untuk memastikan pengaturan Anda benar.
## Model penyematan apa yang didukung oleh aplikasi?
Saat ini, aplikasi mendukung semua model yang didukung oleh Bedrock. Ini termasuk:
+ Amazon Titan Embeddings G1 - Teks
+ Embeddings Teks Amazon Titan V2
+ Embeddings Multimodal Amazon Titan G1
+ Cohere Sematkan Bahasa Inggris
+ Cohere Sematkan Multilingual
## Dapatkah saya menyempurnakan kinerja aplikasi saya berdasarkan beban kerja saya?
Ya. Throughput aplikasi tergantung pada sejumlah faktor, yang semuanya dapat dikontrol oleh pelanggan:
1. **AWS MSF KPUs**: Aplikasi ini digunakan dengan faktor paralelisme default 2 dan paralelisme per KPU 1, dengan penskalaan otomatis dihidupkan. Namun, kami menyarankan Anda mengonfigurasi penskalaan untuk aplikasi Managed Service for Apache Flink sesuai dengan beban kerja Anda. Untuk informasi selengkapnya, lihat [Meninjau Layanan Terkelola untuk sumber daya aplikasi Apache Flink](https://docs.aws.amazon.com/managed-flink/latest/java/how-resources.html).
1. **Amazon Bedrock**: Berdasarkan model berdasarkan permintaan Amazon Bedrock yang dipilih, kuota yang berbeda mungkin berlaku. Tinjau kuota layanan di Bedrock untuk melihat beban kerja yang dapat ditangani oleh layanan. Untuk informasi selengkapnya, lihat [Kuota untuk Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html).
1. ** OpenSearch Layanan Amazon**: Selain itu, dalam beberapa situasi, Anda mungkin memperhatikan bahwa itu OpenSearch adalah hambatan dalam pipeline Anda. Untuk informasi penskalaan, lihat OpenSearch penskalaan [ukuran domain Layanan OpenSearch Amazon](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/sizing-domains.html).
## Jenis otentikasi MSK Amazon apa yang didukung?
Kami hanya mendukung jenis otentikasi IAM MSK.
## Apa itu `sink.os.bulkFlushIntervalMillis` dan bagaimana cara mengaturnya?
Saat mengirim data ke OpenSearch Layanan Amazon, interval flush massal adalah interval di mana permintaan massal dijalankan, terlepas dari jumlah tindakan atau ukuran permintaan. Nilai default diatur ke 1 milidetik.
Meskipun mengatur interval flush dapat membantu memastikan bahwa data diindeks tepat waktu, itu juga dapat menyebabkan peningkatan overhead jika disetel terlalu rendah. Pertimbangkan kasus penggunaan Anda dan pentingnya pengindeksan tepat waktu saat memilih interval flush.
## Ketika saya menerapkan Layanan Terkelola untuk aplikasi Apache Flink saya, dari titik mana dalam topik MSK Amazon akan mulai membaca pesan?
Aplikasi akan mulai membaca pesan dari topik MSK Amazon pada offset yang ditentukan oleh `source.msk.starting.offset` konfigurasi yang ditetapkan dalam konfigurasi runtime aplikasi. Jika tidak `source.msk.starting.offset` ditetapkan secara eksplisit, perilaku default aplikasi adalah mulai membaca dari pesan paling awal yang tersedia dalam topik.
## Bagaimana cara saya menggunakan`source.msk.starting.offset`?
Secara eksplisit mengatur s `ource.msk.starting.offset` ke salah satu nilai berikut, berdasarkan perilaku yang diinginkan:
+ EARLIEST: Pengaturan default, yang berbunyi dari offset tertua di partisi. Ini adalah pilihan yang baik terutama jika:
+ Anda telah membuat topik MSK Amazon dan aplikasi konsumen yang baru dibuat.
+ Anda perlu memutar ulang data, sehingga Anda dapat membangun atau merekonstruksi status. Ini relevan saat menerapkan pola sumber acara atau saat menginisialisasi layanan baru yang memerlukan tampilan lengkap dari riwayat data.
+ TERBARU: Layanan Terkelola untuk aplikasi Apache Flink akan membaca pesan dari akhir partisi. Kami merekomendasikan opsi ini jika Anda hanya peduli dengan pesan baru yang diproduksi dan tidak perlu memproses data historis. Dalam pengaturan ini, konsumen akan mengabaikan pesan yang ada dan hanya membaca pesan baru yang diterbitkan oleh produsen hulu.
+ BERKOMITMEN: Layanan Terkelola untuk aplikasi Apache Flink akan mulai mengkonsumsi pesan dari offset yang berkomitmen dari grup yang mengkonsumsi. Jika offset komited tidak ada, strategi reset EARLIEST akan digunakan.
## Strategi chunking apa yang didukung?
Kami menggunakan perpustakaan [langchain](https://js.langchain.com/v0.1/docs/get_started/introduction/) untuk memotong input. Chunking hanya diterapkan jika panjang input lebih besar dari yang dipilih. `maxSegmentSizeInChars` Kami mendukung lima jenis chunking berikut:
+ `SPLIT_BY_CHARACTER`: Akan muat sebanyak mungkin karakter ke dalam setiap potongan di mana setiap panjang potongan tidak lebih besar dari. maxSegmentSize InChars Tidak peduli dengan spasi putih, sehingga dapat memotong kata-kata.
+ `SPLIT_BY_WORD`: Akan menemukan karakter spasi putih untuk dipotong oleh. Tidak ada kata-kata yang terputus.
+ `SPLIT_BY_SENTENCE`: Batas kalimat terdeteksi menggunakan pustaka Apache OpenNLP dengan model kalimat bahasa Inggris.
+ `SPLIT_BY_LINE`: Akan menemukan karakter baris baru untuk dipotong.
+ `SPLIT_BY_PARAGRAPH`: Akan menemukan karakter baris baru berturut-turut untuk dipotongi.
Strategi pemisahan jatuh kembali sesuai dengan urutan sebelumnya, di mana strategi chunking yang lebih besar seperti jatuh kembali ke. `SPLIT_BY_PARAGRAPH` `SPLIT_BY_CHARACTER` Misalnya, ketika menggunakan`SPLIT_BY_LINE`, jika garis terlalu panjang maka baris akan di-sub-chunked oleh kalimat, di mana setiap potongan akan muat dalam kalimat sebanyak mungkin. Jika ada kalimat yang terlalu panjang, maka akan terpotong di tingkat kata. Jika sebuah kata terlalu panjang, maka itu akan dibagi oleh karakter.
## Bagaimana cara membaca catatan di datastore vektor saya?
1. `source.msk.data.type`Kapan `STRING`
+ **original\$1data**: Seluruh string asli dari pesan MSK Amazon.
+ **embedded\$1data**: Vektor penyematan dibuat dari `chunk_data` jika tidak kosong (chunking diterapkan) atau dibuat dari jika tidak ada chunking yang diterapkan. `original_data`
+ **chunk\$1data**: Hanya ada saat data asli terpotong. Berisi potongan pesan asli yang digunakan untuk membuat penyematan di. `embedded_data`
1. `source.msk.data.type`Kapan `JSON`
+ **original\$1data**: Seluruh JSON asli dari pesan MSK Amazon *setelah* pemfilteran kunci JSON diterapkan.
+ **embedded\$1data**: Vektor penyematan dibuat dari `chunk_data` jika tidak kosong (chunking diterapkan) atau dibuat dari jika tidak ada chunking yang diterapkan. `original_data`
+ **chunk\$1key**: Hanya ada saat data asli terpotong. Berisi kunci JSON tempat potongan itu berasal. `original_data` Misalnya, dapat terlihat seperti `jsonKey1.nestedJsonKeyA` kunci bersarang atau *metadata* dalam contoh. `original_data`
+ **chunk\$1data**: Hanya ada saat data asli terpotong. Berisi potongan pesan asli yang digunakan untuk membuat penyematan di. `embedded_data`
Ya, Anda dapat membaca data dari beberapa topik MSK Amazon dengan aplikasi ini. Data dari semua topik harus dari jenis yang sama (baik STRING atau JSON) atau dapat menyebabkan aplikasi gagal. Data dari semua topik selalu disimpan dalam satu OpenSearch indeks.
## Di mana saya dapat menemukan pembaruan baru untuk kode sumber?
Pergi ke [https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases untuk memeriksa rilis baru](https://github.com/awslabs/real-time-vectorization-of-streaming-data/releases).
## Dapatkah saya membuat perubahan pada AWS CloudFormation template dan memperbarui Layanan Terkelola untuk aplikasi Apache Flink?
Tidak, membuat perubahan pada AWS CloudFormation template tidak memperbarui Layanan Terkelola untuk aplikasi Apache Flink. Setiap perubahan baru AWS CloudFormation menyiratkan tumpukan baru perlu diterapkan.
## Apakah akan AWS memantau dan memelihara aplikasi atas nama saya?
Tidak, tidak AWS akan memantau, menskalakan, memperbarui, atau menambal aplikasi ini atas nama Anda.
## Apakah aplikasi ini memindahkan data saya ke luar saya Akun AWS?
Semua data yang dibaca dan disimpan oleh Layanan Terkelola untuk aplikasi Apache Flink tetap berada di dalam akun Anda Akun AWS dan tidak pernah meninggalkan akun Anda.
# Cetak biru penyematan vektor waktu nyata - pemecahan masalah
Tinjau topik pemecahan masalah berikut tentang cetak biru penyematan vektor waktu nyata. Untuk informasi selengkapnya tentang cetak biru penyematan vektor waktu nyata, lihat Cetak biru penyematan vektor [waktu nyata](https://docs.aws.amazon.com/msk/latest/developerguide/ai-vector-embedding-integration-learn-more.html).
**Topics**
+ [Penerapan CloudFormation tumpukan saya gagal atau dibatalkan. Apa yang bisa saya lakukan untuk memperbaikinya?](#troubleshooting-blueprints-deployment)
+ [Saya tidak ingin aplikasi saya mulai membaca pesan dari awal topik MSK Amazon. Apa yang harus saya lakukan?](#troubleshooting-blueprints-beginning)
+ [Bagaimana saya tahu jika ada masalah dengan Layanan Terkelola saya untuk aplikasi Apache Flink dan bagaimana saya bisa men-debug itu?](#troubleshooting-blueprints-debug)
+ [Apa metrik utama yang harus saya pantau untuk aplikasi Managed Service for Apache Flink saya?](#troubleshooting-blueprints-metrics)
## Penerapan CloudFormation tumpukan saya gagal atau dibatalkan. Apa yang bisa saya lakukan untuk memperbaikinya?
+ Buka tumpukan CFN Anda dan temukan alasan kegagalan tumpukan. Ini bisa terkait dengan izin yang hilang, tabrakan nama AWS sumber daya, di antara penyebab lainnya. Perbaiki akar penyebab kegagalan penerapan. Untuk informasi selengkapnya, lihat panduan [ CloudWatch pemecahan masalah](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#basic-ts-guide).
+ [Opsional] Hanya ada satu titik akhir VPC per layanan per VPC. Jika Anda menerapkan beberapa cetak biru penyematan vektor real-time untuk menulis ke koleksi OpenSearch Layanan Amazon di VPC yang sama, mereka mungkin berbagi titik akhir VPC. Ini mungkin sudah ada di akun Anda untuk VPC, atau tumpukan cetak biru penyematan vektor real-time pertama akan membuat titik akhir VPC untuk Amazon Bedrock dan OpenSearch Amazon Service yang akan digunakan oleh semua tumpukan lain yang digunakan di akun Anda. Jika tumpukan gagal, periksa apakah tumpukan itu membuat titik akhir VPC untuk Amazon Bedrock dan OpenSearch Amazon Service dan hapus jika tidak digunakan di tempat lain di akun Anda. Untuk langkah-langkah menghapus titik akhir VPC, lihat dokumentasi tentang cara menghapus aplikasi Anda dengan aman.
+ Mungkin ada layanan atau aplikasi lain di akun Anda menggunakan titik akhir VPC. Menghapusnya dapat membuat gangguan jaringan untuk layanan lain. Hati-hati dalam menghapus titik akhir ini.
## Saya tidak ingin aplikasi saya mulai membaca pesan dari awal topik MSK Amazon. Apa yang harus saya lakukan?
Anda harus secara eksplisit mengatur `source.msk.starting.offset` ke salah satu nilai berikut, tergantung pada perilaku yang diinginkan:
+ Offset **paling awal: Offset** tertua di partisi.
+ **Offset terbaru**: Konsumen akan membaca pesan dari ujung partisi.
+ **Offset komited**: Baca dari pesan terakhir yang diproses konsumen dalam partisi.
## Bagaimana saya tahu jika ada masalah dengan Layanan Terkelola saya untuk aplikasi Apache Flink dan bagaimana saya bisa men-debug itu?
Gunakan [panduan pemecahan masalah Layanan Terkelola untuk Apache Flink untuk men-debug Layanan Terkelola untuk masalah](https://docs.aws.amazon.com/managed-flink/latest/java/troubleshooting-runtime.html) terkait Apache Flink dengan aplikasi Anda.
## Apa metrik utama yang harus saya pantau untuk aplikasi Managed Service for Apache Flink saya?
+ Semua metrik yang tersedia untuk Layanan Terkelola reguler untuk aplikasi Apache Flink dapat membantu Anda memantau aplikasi Anda. Untuk informasi selengkapnya, lihat [Metrik dan dimensi dalam Layanan Terkelola untuk Apache Flink](https://docs.aws.amazon.com/managed-flink/latest/java/metrics-dimensions.html).
+ Untuk memantau metrik Amazon Bedrock, lihat metrik Amazon [ CloudWatch untuk Amazon](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring.html#runtime-cloudwatch-metrics) Bedrock.
+ Kami telah menambahkan dua metrik baru untuk memantau kinerja pembuatan embeddings. Temukan mereka di bawah nama `EmbeddingGeneration` operasi di CloudWatch. Kedua metrik tersebut adalah:
+ **BedrockTitanEmbeddingTokenCount**: Jumlah token hadir dalam satu permintaan ke Amazon Bedrock.
+ **BedrockEmbeddingGenerationLatencyMs**: Melaporkan waktu yang dibutuhkan untuk mengirim dan menerima tanggapan dari Amazon Bedrock untuk menghasilkan penyematan, dalam milidetik.
+ Untuk koleksi tanpa server Amazon OpenSearch Service, Anda dapat menggunakan metrik seperti`IngestionDataRate`, `IngestionDocumentErrors` dan lainnya. Untuk informasi selengkapnya, lihat [Memantau OpenSearch Tanpa Server dengan Amazon](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/monitoring-cloudwatch.html). CloudWatch
+ Untuk metrik OpenSearch yang disediakan, lihat [Memantau metrik OpenSearch klaster](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-cloudwatchmetrics.html) dengan Amazon. CloudWatch
# Pemecahan masalah runtime
Bagian ini berisi informasi tentang mendiagnosis dan memperbaiki masalah runtime dengan aplikasi Managed Service for Apache Flink Anda.
**Topics**
+ [Alat pemecahan masalah](#troubleshooting-tools)
+ [Masalah aplikasi](troubleshooting-symptoms.md)
+ [Aplikasi dimulai ulang](troubleshooting-rt-restarts.md)
+ [Throughput terlalu lambat](troubleshooting-rt-throughput.md)
+ [Pertumbuhan negara tak terbatas](troubleshooting-rt-stateleaks.md)
+ [Operator terikat I/O](troubleshooting-io-bound-operators.md)
+ [Pelambatan hulu atau sumber dari aliran data Kinesis](troubleshooting-source-throttling.md)
+ [Titik pemeriksaan](troubleshooting-checkpoints.md)
+ [Waktu titik checkpointing](troubleshooting-chk-timeout.md)
+ [Kegagalan pos pemeriksaan untuk aplikasi Apache Beam](troubleshooting-chk-failure-beam.md)
+ [Tekanan balik](troubleshooting-backpressure.md)
+ [Kemiringan data](troubleshooting-data-skew.md)
+ [Kemiringan negara](troubleshooting-state-skew.md)
+ [Integrasikan dengan sumber daya di berbagai Wilayah](troubleshooting-resources-in-different-regions.md)
## Alat pemecahan masalah
Alat utama untuk mendeteksi masalah aplikasi adalah CloudWatch alarm. Dengan menggunakan CloudWatch alarm, Anda dapat mengatur ambang batas untuk CloudWatch metrik yang menunjukkan kondisi kesalahan atau kemacetan dalam aplikasi Anda. Untuk informasi tentang CloudWatch alarm yang direkomendasikan, lihat[Gunakan CloudWatch Alarm dengan Amazon Managed Service untuk Apache Flink](monitoring-metrics-alarms.md).
# Masalah aplikasi
Bagian ini berisi solusi untuk kondisi kesalahan yang mungkin Anda temui dengan Layanan Terkelola untuk aplikasi Apache Flink Anda.
**Topics**
+ [Aplikasi macet dalam status sementara](#troubleshooting-rt-stuck)
+ [Pembuatan snapshot gagal](#troubleshooting-rt-snapshots)
+ [Tidak dapat mengakses sumber daya dalam VPC](#troubleshooting-rt-vpc)
+ [Data hilang saat menulis ke bucket Amazon S3](#troubleshooting-rt-s3)
+ [Aplikasi dalam status RUNNING tetapi tidak memproses data](#troubleshooting-rt-processing)
+ [Snapshot, pembaruan aplikasi, atau kesalahan penghentian aplikasi: InvalidApplicationConfigurationException](#troubleshooting-rt-appconfigexception)
+ [java.nio.file. NoSuchFileException:/usr/local/openjdk-8/lib/security/cacerts](#troubleshooting-rt-fnf)
## Aplikasi macet dalam status sementara
Jika aplikasi Anda tetap dalam status transien (`STARTING`,, `UPDATING``STOPPING`, atau`AUTOSCALING`), Anda dapat menghentikan aplikasi Anda dengan menggunakan [StopApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_StopApplication.html)tindakan dengan `Force` parameter yang disetel ke. `true` Anda tidak dapat menghentikan paksa aplikasi di status `DELETING`. Atau, jika aplikasi dalam status `UPDATING` atau `AUTOSCALING`, Anda dapat mengembalikannya ke versi berjalan sebelumnya. Ketika Anda mengembalikan aplikasi, data status dari snapshot terakhir yang berhasil akan dimuat. Jika aplikasi tidak memiliki snapshot, Managed Service for Apache Flink menolak permintaan rollback. Untuk informasi selengkapnya tentang memutar kembali aplikasi, lihat [RollbackApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_RollbackApplication.html)tindakan.
**catatan**
Menghentikan paksa aplikasi Anda dapat menyebabkan kehilangan data atau duplikasi. Untuk mencegah kehilangan data atau menduplikasi pemrosesan data selama aplikasi dimulai ulang, sebaiknya ambil snapshot yang sering dari aplikasi Anda.
Penyebab aplikasi terhenti mencakup berikut ini:
+ **Status aplikasi terlalu besar:** Memiliki status aplikasi yang terlalu besar atau terlalu persisten dapat menyebabkan aplikasi terhenti selama operasi titik pemeriksaan atau snapshot. Periksa metrik `lastCheckpointDuration` dan `lastCheckpointSize` aplikasi Anda untuk nilai yang terus meningkat atau nilai tinggi yang tidak normal.
+ **Kode aplikasi terlalu besar:** Pastikan file JAR aplikasi Anda lebih kecil dari 512 MB. File JAR yang lebih besar dari 512 MB tidak didukung.
+ **Pembuatan snapshot aplikasi gagal:** Layanan Terkelola untuk Apache Flink mengambil snapshot aplikasi selama permintaan atau permintaan. [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) Layanan selanjutnya menggunakan status snapshot ini dan mengembalikan aplikasi menggunakan konfigurasi aplikasi yang diperbarui untuk memberikan semantik pemrosesan *exactly-once*. Jika pembuatan snapshot otomatis gagal, lihat [Pembuatan snapshot gagal](#troubleshooting-rt-snapshots) di bawah ini.
+ **Memulihkan dari snapshot gagal:** Jika Anda menghapus atau mengubah operator dalam pembaruan aplikasi dan mencoba memulihkan dari snapshot, pemulihan akan gagal secara default jika snapshot berisi data status untuk operator yang hilang. Selain itu, aplikasi akan terhenti di status `STOPPED` atau `UPDATING`. Untuk mengubah perilaku ini dan memungkinkan pemulihan berhasil, ubah *AllowNonRestoredState*parameter aplikasi [FlinkRunConfiguration](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_FlinkRunConfiguration.html)menjadi`true`. Ini akan memungkinkan operasi lanjutkan melewati data status yang tidak dapat dipetakan ke program baru.
+ **Inisialisasi aplikasi memakan waktu lebih lama:** Layanan Terkelola untuk Apache Flink menggunakan batas waktu internal 5 menit (pengaturan lunak) sambil menunggu pekerjaan Flink dimulai. Jika pekerjaan Anda gagal untuk memulai dalam batas waktu ini, Anda akan melihat CloudWatch log sebagai berikut:
```
Flink job did not start within a total timeout of 5 minutes for application: %s under account: %s
```
Jika Anda mengalami kesalahan di atas, itu berarti operasi Anda yang ditentukan di bawah `main` metode pekerjaan Flink memakan waktu lebih dari 5 menit, menyebabkan pembuatan pekerjaan Flink habis pada Layanan Terkelola untuk Apache Flink berakhir. Kami sarankan Anda memeriksa **JobManager**log Flink serta kode aplikasi Anda untuk melihat apakah penundaan dalam `main` metode ini diharapkan. Jika tidak, Anda perlu mengambil langkah-langkah untuk mengatasi masalah ini sehingga selesai dalam waktu kurang dari 5 menit.
Anda dapat memeriksa status aplikasi Anda menggunakan tindakan [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) atau [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).
## Pembuatan snapshot gagal
Layanan Terkelola untuk layanan Apache Flink tidak dapat mengambil snapshot dalam keadaan berikut:
+ Aplikasi melebihi batas snapshot. Batas untuk snapshot adalah 1.000. Untuk informasi selengkapnya, lihat [Kelola cadangan aplikasi menggunakan snapshot](how-snapshots.md).
+ Aplikasi tidak memiliki izin untuk mengakses sumber atau sink.
+ Kode aplikasi tidak berfungsi dengan benar.
+ Aplikasi mengalami masalah konfigurasi lainnya.
Jika Anda mendapatkan pengecualian saat mengambil snapshot selama pembaruan aplikasi atau saat menghentikan aplikasi, atur properti `SnapshotsEnabled` dari [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) aplikasi Anda ke `false` dan coba lagi permintaan.
Snapshot dapat gagal jika operator aplikasi Anda tidak disediakan dengan benar. Untuk informasi tentang penyetelan performa operator, lihat [Penskalaan operator](performance-improving.md#performance-improving-scaling-op).
Setelah aplikasi kembali ke status sehat, sebaiknya atur properti `SnapshotsEnabled` aplikasi ke `true`.
## Tidak dapat mengakses sumber daya dalam VPC
Jika aplikasi Anda menggunakan VPC yang berjalan di Amazon VPC, lakukan hal berikut untuk memastikan aplikasi Anda memiliki akses ke sumber dayanya:
+ Periksa CloudWatch log Anda untuk kesalahan berikut. Kesalahan ini menunjukkan aplikasi Anda tidak dapat mengakses sumber daya di VPC Anda:
```
org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms.
```
Jika Anda melihat kesalahan ini, pastikan tabel rute Anda diatur dengan benar, dan konektor Anda memiliki pengaturan koneksi yang benar.
Untuk informasi tentang menyiapkan dan menganalisis CloudWatch log, lihat[Pencatatan dan pemantauan di Amazon Managed Service untuk Apache Flink](monitoring-overview.md).
## Data hilang saat menulis ke bucket Amazon S3
Beberapa kehilangan data mungkin terjadi ketika menulis output ke bucket Amazon S3 menggunakan Apache Flink versi 1.6.2. Sebaiknya gunakan versi Apache Flink terbaru yang didukung ketika menggunakan Amazon S3 untuk output langsung. Untuk menulis ke bucket Amazon S3 menggunakan Apache Flink 1.6.2, sebaiknya gunakan Firehose. Untuk informasi selengkapnya tentang penggunaan Firehose dengan Managed Service for Apache Flink, lihat. [Wastafel Firehose](earlier.md#get-started-exercise-fh)
## Aplikasi dalam status RUNNING tetapi tidak memproses data
Anda dapat memeriksa status aplikasi Anda menggunakan tindakan [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) atau [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). Jika aplikasi Anda memasukkan `RUNNING` status tetapi tidak menulis data ke wastafel Anda, Anda dapat memecahkan masalah dengan menambahkan aliran CloudWatch log Amazon ke aplikasi Anda. Untuk informasi selengkapnya, lihat [Bekerja dengan opsi CloudWatch pencatatan aplikasi](cloudwatch-logs.md#adding_cloudwatch). Aliran log berisi pesan yang dapat Anda gunakan untuk memecahkan masalah aplikasi.
## Snapshot, pembaruan aplikasi, atau kesalahan penghentian aplikasi: InvalidApplicationConfigurationException
Kesalahan yang mirip dengan berikut ini mungkin terjadi selama operasi snapshot, atau selama operasi yang membuat snapshot, seperti memperbarui atau menghentikan aplikasi:
```
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
```
Kesalahan ini terjadi ketika aplikasi tidak dapat membuat snapshot.
Jika Anda mengalami kesalahan ini selama operasi snapshot atau operasi yang membuat snapshot, lakukan hal berikut:
+ Nonaktifkan snapshot untuk aplikasi Anda. Anda dapat melakukan ini baik di Managed Service for Apache Flink console, atau dengan menggunakan `SnapshotsEnabledUpdate` parameter tindakan. [UpdateApplication](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_UpdateApplication.html)
+ Selidiki alasan snapshot tidak dapat dibuat. Untuk informasi selengkapnya, lihat [Aplikasi macet dalam status sementara](#troubleshooting-rt-stuck).
+ Aktifkan kembali snapshot ketika aplikasi kembali ke status sehat.
## java.nio.file. NoSuchFileException:/usr/local/openjdk-8/lib/security/cacerts
Lokasi truststore SSL diperbarui di deployment sebelumnya. Sebagai gantinya, gunakan nilai berikut untuk parameter `ssl.truststore.location`:
```
/usr/lib/jvm/java-11-amazon-corretto/lib/security/cacerts
```
# Aplikasi dimulai ulang
Jika aplikasi Anda tidak sehat, tugas Apache Flink terus gagal dan dimulai ulang. Bagian ini menjelaskan gejala dan langkah pemecahan masalah untuk kondisi ini.
## Gejala
Kondisi ini dapat memiliki gejala berikut:
+ Metrik `FullRestarts` tidak nol. Metrik ini menunjukkan berapa kali tugas aplikasi dimulai ulang sejak Anda memulai aplikasi.
+ Metrik `Downtime` tidak nol. Metrik ini menunjukkan jumlah milidetik ketika aplikasi berada di status `FAILING` atau `RESTARTING`.
+ Log aplikasi berisi perubahan status ke `RESTARTING` atau `FAILED`. Anda dapat menanyakan log aplikasi untuk perubahan status ini menggunakan kueri Wawasan CloudWatch Log berikut:[Menganalisis kesalahan: Kegagalan terkait tugas aplikasi](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
## Penyebab dan solusi
Kondisi berikut dapat menyebabkan aplikasi Anda menjadi tidak stabil dan dimulai ulang berulang kali:
+ **Operator melempar pengecualian:** Jika ada pengecualian dalam operator dalam aplikasi Anda tidak tertangani, aplikasi gagal selesai (dengan menafsirkan bahwa kegagalan tidak dapat ditangani oleh operator). Aplikasi dimulai ulang dari titik pemeriksaan terbaru untuk mempertahankan semantik pemrosesan "exactly-once". Akibatnya, `Downtime` tidak nol selama periode mulai ulang ini. Agar hal ini tidak terjadi, sebaiknya tangani pengecualian yang dapat dicoba lagi dalam kode aplikasi.
Anda dapat menyelidiki penyebab kondisi ini dengan mengkueri log aplikasi Anda untuk perubahan dari status aplikasi Anda dari `RUNNING` ke `FAILED`. Untuk informasi selengkapnya, lihat [Menganalisis kesalahan: Kegagalan terkait tugas aplikasi](cloudwatch-logs-reading.md#cloudwatch-logs-reading-apps).
+ **Aliran data Kinesis tidak disediakan dengan benar:** Jika sumber atau sink untuk aplikasi Anda adalah aliran data Kinesis, periksa [metrik](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html) untuk aliran atau kesalahan. `ReadProvisionedThroughputExceeded` `WriteProvisionedThroughputExceeded`
Jika Anda melihat kesalahan ini, Anda dapat meningkatkan throughput yang tersedia untuk aliran Kinesis dengan meningkatkan jumlah serpihan aliran. Untuk informasi selengkapnya, lihat [ Bagaimana cara mengubah jumlah serpihan terbuka di Kinesis Data Streams?](https://aws.amazon.com/premiumsupport/knowledge-center/kinesis-data-streams-open-shards/).
+ **Sumber atau sink lainnya tidak diberikan atau tersedia dengan benar:** Pastikan aplikasi Anda menyediakan sumber dan sink dengan benar. Periksa apakah sumber atau sink apa pun yang digunakan dalam aplikasi (seperti AWS layanan lain, atau sumber atau tujuan eksternal) disediakan dengan baik, tidak mengalami pelambatan baca atau tulis, atau secara berkala tidak tersedia.
Jika Anda mengalami masalah terkait throughput pada layanan dependen Anda, baik meningkatkan sumber daya yang tersedia untuk layanan tersebut, maupun menyelidiki penyebab kesalahan atau ketidaktersediaan apa pun.
+ **Operator tidak disediakan dengan benar:** Jika beban kerja pada utas untuk salah satu operator dalam aplikasi Anda tidak didistribusikan dengan benar, operator dapat kelebihan beban dan aplikasi dapat crash. Untuk informasi tentang penyetelan paralelisme operator, lihat [Kelola penskalaan operator dengan benar](performance-improving.md#performance-improving-scaling-op).
+ **Aplikasi gagal dengan DaemonException:** Kesalahan ini muncul di log aplikasi Anda jika Anda menggunakan versi Apache Flink sebelum 1.11. Anda mungkin perlu meng-upgrade ke versi Apache Flink yang lebih baru sehingga versi KPL 0,14 atau yang lebih baru digunakan.
+ **Aplikasi gagal dengan TimeoutException, FlinkException, atau RemoteTransportException:** Kesalahan ini mungkin muncul di log aplikasi Anda jika pengelola tugas Anda mogok. Jika aplikasi Anda kelebihan beban, manajer tugas Anda dapat mengalami tekanan sumber daya CPU atau memori, menyebabkannya gagal.
Kesalahan ini mungkin terlihat seperti berikut:
+ `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`
Untuk memecahkan masalah kondisi ini, periksa hal berikut:
+ Periksa CloudWatch metrik Anda untuk lonjakan yang tidak biasa dalam penggunaan CPU atau memori.
+ Periksa aplikasi Anda untuk masalah throughput. Untuk informasi selengkapnya, lihat [Memecahkan masalah kinerja](performance-troubleshooting.md).
+ Periksa log aplikasi Anda untuk pengecualian yang tidak tertangani yang ditimbulkan oleh kode aplikasi Anda.
+ **Aplikasi gagal dengan kesalahan JaxbAnnotationModule Tidak Ditemukan: Kesalahan** ini terjadi jika aplikasi Anda menggunakan Apache Beam, tetapi tidak memiliki dependensi atau versi dependensi yang benar. Managed Service untuk aplikasi Apache Flink yang menggunakan Apache Beam harus menggunakan versi dependensi berikut:
```
2.10.2
...
com.fasterxml.jackson.module
jackson-module-jaxb-annotations
2.10.2
```
Jika Anda tidak menyediakan versi `jackson-module-jaxb-annotations` yang benar sebagai dependensi eksplisit, aplikasi Anda memuatnya dari dependensi lingkungan, dan karena versi tidak cocok, aplikasi mengalami crash saat runtime.
Untuk informasi selengkapnya tentang penggunaan Apache Beam dengan Managed Service for Apache Flink, lihat. [Gunakan CloudFormationMembuat aplikasi menggunakan Apache Beam](examples-beam.md)
+ **Aplikasi gagal dengan java.io. IOException: Jumlah buffer jaringan tidak mencukupi**
Ini terjadi ketika aplikasi tidak memiliki cukup memori yang dialokasikan untuk buffer jaringan. Buffer jaringan memfasilitasi komunikasi antar subtugas. Mereka digunakan untuk menyimpan catatan sebelum transmisi melalui jaringan, dan untuk menyimpan data yang masuk sebelum membedahnya menjadi catatan dan menyerahkannya ke subtugas. Jumlah buffer jaringan diperlukan skala langsung dengan paralelisme dan kompleksitas grafik pekerjaan Anda. Ada sejumlah pendekatan untuk mengurangi masalah ini:
+ Anda dapat mengkonfigurasi yang lebih rendah `parallelismPerKpu` sehingga ada lebih banyak memori yang dialokasikan per subtask dan buffer jaringan. Perhatikan bahwa penurunan `parallelismPerKpu` akan meningkatkan KPU dan karenanya biaya. Untuk menghindari hal ini, Anda dapat menjaga jumlah KPU yang sama dengan menurunkan paralelisme dengan faktor yang sama.
+ Anda dapat menyederhanakan grafik pekerjaan Anda dengan mengurangi jumlah operator atau merantainya sehingga lebih sedikit buffer yang dibutuhkan.
+ Jika tidak, Anda dapat menghubungi https://aws.amazon.com/premiumsupport/ konfigurasi buffer jaringan khusus.
# Throughput terlalu lambat
Jika aplikasi Anda tidak memproses data streaming yang masuk dengan cukup cepat, aplikasi akan berperforma buruk dan menjadi tidak stabil. Bagian ini menjelaskan gejala dan langkah pemecahan masalah untuk kondisi ini.
## Gejala
Kondisi ini dapat memiliki gejala berikut:
+ Jika sumber data untuk aplikasi Anda adalah aliran Kinesis, metrik `millisbehindLatest` aliran terus meningkat.
+ Jika sumber data untuk aplikasi Anda adalah klaster Amazon MSK, metrik lag konsumen klaster terus meningkat. Untuk informasi selengkapnya, lihat [Pemantauan Lag Konsumen](https://docs.aws.amazon.com/msk/latest/developerguide/consumer-lag.html) di [ Panduan Developer Amazon MSK](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html).
+ Jika sumber data untuk aplikasi Anda adalah layanan atau sumber yang berbeda, periksa metrik atau data lag konsumen yang tersedia.
## Penyebab dan solusi
Ada banyak penyebab untuk throughput aplikasi yang lambat. Jika aplikasi Anda tidak mengikuti input, periksa hal berikut:
+ Jika lag throughput melonjak, lalu menurun, periksa apakah aplikasi dimulai ulang. Aplikasi Anda akan berhenti memproses input saat dimulai ulang, menyebabkan lonjakan lag. Untuk informasi selengkapnya tentang kegagalan aplikasi, lihat [Aplikasi dimulai ulang](troubleshooting-rt-restarts.md).
+ Jika lag throughput konsisten, periksa untuk melihat apakah performa aplikasi Anda dioptimalkan. Untuk informasi tentang mengoptimalkan performa aplikasi, lihat [Memecahkan masalah kinerja](performance-troubleshooting.md).
+ Jika lag throughput tidak melonjak, tetapi terus meningkat, dan performa aplikasi Anda dioptimalkan, Anda harus meningkatkan sumber daya aplikasi Anda. Untuk informasi tentang peningkatan sumber daya aplikasi, lihat [Menerapkan penskalaan aplikasi](how-scaling.md).
+ Jika aplikasi Anda membaca dari cluster Kafka di Wilayah yang berbeda dan `FlinkKafkaConsumer` atau `KafkaSource` sebagian besar menganggur (tinggi `idleTimeMsPerSecond` atau rendah`CPUUtilization`) meskipun kelambatan konsumen tinggi, Anda dapat meningkatkan nilainya`receive.buffer.byte`, seperti 2097152. Untuk informasi selengkapnya, lihat bagian lingkungan latensi tinggi di konfigurasi [MSK Kustom](https://docs.aws.amazon.com/msk/latest/developerguide/msk-configuration-properties.html).
Untuk langkah-langkah pemecahan masalah untuk throughput lambat atau lag konsumen yang meningkat di sumber aplikasi, lihat [Memecahkan masalah kinerja](performance-troubleshooting.md).
# Pertumbuhan negara tak terbatas
Jika aplikasi Anda tidak membuang informasi status yang tidak berlaku dengan benar, informasi akan terus diakumulasi dan menyebabkan masalah performa atau stabilitas aplikasi. Bagian ini menjelaskan gejala dan langkah pemecahan masalah untuk kondisi ini.
## Gejala
Kondisi ini dapat memiliki gejala berikut:
+ Metrik `lastCheckpointDuration` meningkat atau melonjak secara bertahap.
+ Metrik `lastCheckpointSize` meningkat atau melonjak secara bertahap.
## Penyebab dan solusi
Kondisi berikut dapat menyebabkan aplikasi Anda mengakumulasi data status:
+ Aplikasi Anda menyimpan data status lebih lama dari yang dibutuhkan.
+ Aplikasi Anda menggunakan kueri jendela dengan durasi yang terlalu lama.
+ Anda tidak menetapkan TTL untuk data status Anda. Untuk informasi selengkapnya, lihat [Status Time-To-Live (TTL) di Dokumentasi](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) Apache Flink.
+ Anda menjalankan aplikasi yang bergantung pada Apache Beam versi 2.25.0 atau yang lebih baru. Anda dapat memilih keluar dari versi baru transformasi baca dengan [memperluas eksperimen dan nilai `use_deprecated_read` utama Anda BeamApplicationProperties](https://docs.aws.amazon.com/managed-flink/latest/java/examples-beam.html#examples-beam-configure). Untuk informasi selengkapnya, lihat [Dokumentasi Apache Beam](https://beam.apache.org/blog/beam-2.25.0/#highlights).
Terkadang aplikasi menghadapi pertumbuhan ukuran negara yang terus berkembang, yang tidak berkelanjutan dalam jangka panjang (bagaimanapun juga aplikasi Flink berjalan tanpa batas waktu). Terkadang, ini dapat ditelusuri kembali ke aplikasi yang menyimpan data dalam keadaan dan tidak menua informasi lama dengan benar. Tapi terkadang hanya ada harapan yang tidak masuk akal tentang apa yang bisa diberikan Flink. Aplikasi dapat menggunakan agregasi selama jendela waktu besar yang mencakup hari atau bahkan berminggu-minggu. Kecuali [AggregateFunctions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/#aggregatefunction)digunakan, yang memungkinkan agregasi inkremental, Flink perlu menjaga peristiwa seluruh jendela dalam keadaan.
Selain itu, ketika menggunakan fungsi proses untuk mengimplementasikan operator kustom, aplikasi perlu menghapus data dari status yang tidak lagi diperlukan untuk logika bisnis. Dalam hal ini, [status time-to-live](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl) dapat digunakan untuk secara otomatis menua data berdasarkan waktu pemrosesan. [Layanan Terkelola untuk Apache Flink menggunakan pos pemeriksaan tambahan dan dengan demikian status ttl didasarkan pada pemadatan RocksDB.](https://github.com/facebook/rocksdb/wiki/Compaction) Anda hanya dapat mengamati pengurangan aktual dalam ukuran status (ditunjukkan oleh ukuran pos pemeriksaan) setelah operasi pemadatan terjadi. Khususnya untuk ukuran pos pemeriksaan di bawah 200 MB, kecil kemungkinan Anda mengamati pengurangan ukuran pos pemeriksaan sebagai akibat dari keadaan kedaluwarsa. Namun, savepoints didasarkan pada salinan bersih dari status yang tidak berisi data lama, sehingga Anda dapat memicu snapshot di Managed Service for Apache Flink untuk memaksa penghapusan status usang.
Untuk tujuan debugging, masuk akal untuk menonaktifkan pos pemeriksaan tambahan untuk memverifikasi lebih cepat bahwa ukuran pos pemeriksaan benar-benar berkurang atau stabil (dan menghindari efek pemadatan di RocksBS). Namun, ini membutuhkan tiket ke tim layanan.
# Operator terikat I/O
Yang terbaik adalah menghindari dependensi ke sistem eksternal pada jalur data. Seringkali jauh lebih berkinerja untuk menjaga kumpulan data referensi dalam keadaan daripada menanyakan sistem eksternal untuk memperkaya peristiwa individu. Namun, terkadang ada dependensi yang tidak dapat dengan mudah dipindahkan ke status, misalnya, jika Anda ingin memperkaya peristiwa dengan model pembelajaran mesin yang di-host di Amazon Sagemaker.
Operator yang berinteraksi dengan sistem eksternal melalui jaringan dapat menjadi hambatan dan menyebabkan tekanan balik. Sangat disarankan untuk menggunakan [Asyncio](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/) untuk mengimplementasikan fungsionalitas, untuk mengurangi waktu tunggu untuk panggilan individual dan menghindari seluruh aplikasi melambat.
Selain itu, untuk aplikasi dengan operator I/O terikat juga masuk akal untuk meningkatkan pengaturan [ParallelismPerKPU](https://docs.aws.amazon.com/managed-flink/latest/apiv2/API_ParallelismConfiguration.html) dari Managed Service untuk aplikasi Apache Flink. Konfigurasi ini menjelaskan jumlah subtugas paralel yang dapat dilakukan aplikasi per Kinesis Processing Unit (KPU). Dengan meningkatkan nilai dari default 1 menjadi, katakanlah, 4, aplikasi memanfaatkan sumber daya yang sama (dan memiliki biaya yang sama) tetapi dapat menskalakan hingga 4 kali paralelisme. Ini berfungsi dengan baik untuk aplikasi I/O terikat, tetapi menyebabkan overhead tambahan untuk aplikasi yang tidak I/O terikat.
# Pelambatan hulu atau sumber dari aliran data Kinesis
**Gejala**: Aplikasi ini bertemu `LimitExceededExceptions` dari aliran data Kinesis sumber hulu mereka.
**Penyebab Potensi**: Pengaturan default untuk konektor Kinesis pustaka Apache Flink diatur untuk dibaca dari sumber aliran data Kinesis dengan pengaturan default yang sangat agresif untuk jumlah maksimum catatan yang diambil per panggilan. `GetRecords` Apache Flink dikonfigurasi secara default untuk mengambil 10.000 catatan per `GetRecords` panggilan (panggilan ini dibuat secara default setiap 200 ms), meskipun batas per pecahan hanya 1.000 catatan.
Perilaku default ini dapat menyebabkan pelambatan saat mencoba mengkonsumsi dari aliran data Kinesis, yang akan memengaruhi kinerja dan stabilitas aplikasi.
Anda dapat mengonfirmasi ini dengan memeriksa CloudWatch `ReadProvisionedThroughputExceeded` metrik dan melihat periode yang berkepanjangan atau berkelanjutan di mana metrik ini lebih besar dari nol.
Anda juga dapat melihat ini di CloudWatch log untuk Amazon Managed Service untuk aplikasi Apache Flink Anda dengan mengamati kesalahan lanjutan`LimitExceededException`.
**Resolusi**: Anda dapat melakukan salah satu dari dua hal untuk menyelesaikan skenario ini:
+ Turunkan batas default untuk jumlah rekaman yang diambil per panggilan `GetRecords`
+ Aktifkan Bacaan Adaptif di Amazon Managed Service untuk aplikasi Apache Flink Anda. [Untuk informasi selengkapnya tentang fitur Bacaan Adaptif, lihat 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)
# Titik pemeriksaan
Pos pemeriksaan adalah mekanisme Flink untuk memastikan bahwa status aplikasi toleran terhadap kesalahan. Mekanisme ini memungkinkan Flink untuk memulihkan status operator jika pekerjaan gagal dan memberikan aplikasi semantik yang sama dengan eksekusi bebas kegagalan. Dengan Managed Service for Apache Flink, status aplikasi disimpan di RocksDB, key/value toko tertanam yang menjaga status kerjanya pada disk. Ketika pos pemeriksaan diambil, status juga diunggah ke Amazon S3 sehingga meskipun disk hilang maka pos pemeriksaan dapat digunakan untuk memulihkan status aplikasi.
Untuk informasi selengkapnya, lihat [Bagaimana Cara Kerja Snapshotting Status](https://nightlies.apache.org/flink/flink-docs-master/docs/learn-flink/fault_tolerance/#how-does-state-snapshotting-work)? .
## Tahapan pemeriksaan
Untuk subtugas operator checkpointing di Flink ada 5 tahap utama:
+ Waiting [**Start Delay**] - Flink menggunakan penghalang pos pemeriksaan yang dimasukkan ke dalam aliran sehingga waktu dalam tahap ini adalah waktu operator menunggu penghalang pos pemeriksaan untuk mencapainya.
+ Alignment [**Alignment Duration**] - Pada tahap ini subtugas telah mencapai satu penghalang tetapi menunggu hambatan dari aliran input lainnya.
+ Sinkronkan pos pemeriksaan [**Durasi Sinkronisasi**] — Tahap ini adalah saat subtugas benar-benar memotret status operator dan memblokir semua aktivitas lain pada subtugas.
+ Async checkpointing [**Async Duration**] — Sebagian besar tahap ini adalah subtugas yang mengunggah status ke Amazon S3. Selama tahap ini, subtugas tidak lagi diblokir dan dapat memproses catatan.
+ Mengakui — Ini biasanya merupakan tahap pendek dan hanyalah subtugas yang mengirimkan pengakuan ke JobManager dan juga melakukan pesan komit apa pun (misalnya dengan sink Kafka).
Masing-masing tahapan ini (selain dari Mengakui) memetakan ke metrik durasi untuk pos pemeriksaan yang tersedia dari WebUI Flink, yang dapat membantu mengisolasi penyebab pos pemeriksaan yang panjang.
Untuk melihat definisi yang tepat dari setiap metrik yang tersedia di pos pemeriksaan, buka Tab [Riwayat](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/#history-tab).
## Menyelidiki
Saat menyelidiki durasi pos pemeriksaan yang panjang, hal terpenting yang harus ditentukan adalah kemacetan untuk pos pemeriksaan, yaitu operator dan subtugas apa yang paling lama menuju pos pemeriksaan dan tahap mana dari subtugas itu yang membutuhkan waktu yang lama. Ini dapat ditentukan menggunakan WebUI Flink di bawah tugas pos pemeriksaan pekerjaan. Antarmuka Web Flink menyediakan data dan informasi yang membantu menyelidiki masalah pos pemeriksaan. Untuk rincian lengkap, lihat [Memantau Checkpointing](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/monitoring/checkpoint_monitoring/).
Hal pertama yang harus dilihat adalah **Durasi Akhir ke Akhir** setiap operator dalam grafik Job untuk menentukan operator mana yang membutuhkan waktu lama untuk melakukan pemeriksaan dan memerlukan penyelidikan lebih lanjut. Per dokumentasi Flink, definisi durasinya adalah:
*Durasi dari stempel waktu pemicu hingga pengakuan terbaru (atau n/a jika belum ada pengakuan yang diterima). Durasi ujung ke akhir untuk pos pemeriksaan lengkap ditentukan oleh subtugas terakhir yang mengakui pos pemeriksaan. Waktu ini biasanya lebih besar dari subtugas tunggal yang perlu benar-benar memeriksa status.*
Durasi lain untuk pos pemeriksaan juga memberikan informasi yang lebih halus tentang di mana waktu dihabiskan.
Jika **Durasi Sinkronisasi** tinggi maka ini menunjukkan sesuatu sedang terjadi selama snapshotting. Selama tahap ini `snapshotState()` dipanggil untuk kelas yang mengimplementasikan antarmuka SnapshotState; ini bisa menjadi kode pengguna sehingga thread-dump dapat berguna untuk menyelidiki ini.
**Durasi Async** yang panjang akan menyarankan bahwa banyak waktu dihabiskan untuk mengunggah status ke Amazon S3. Ini dapat terjadi jika statusnya besar atau jika ada banyak file status yang sedang diunggah. Jika ini masalahnya, perlu diselidiki bagaimana status digunakan oleh aplikasi dan memastikan bahwa struktur data asli Flink digunakan jika memungkinkan ([Menggunakan Status Keyed](https://nightlies.apache.org/flink/flink-docs-master/docs/dev/datastream/fault-tolerance/state/#using-keyed-state)). Layanan Terkelola untuk Apache Flink mengonfigurasi Flink sedemikian rupa untuk meminimalkan jumlah panggilan Amazon S3 untuk memastikan ini tidak terlalu lama. Berikut ini adalah contoh statistik checkpointing operator. Ini menunjukkan bahwa **Durasi Async** relatif panjang dibandingkan dengan statistik checkpointing operator sebelumnya.
![\[Menyelidiki pos pemeriksaan\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/checkpoint.png)
**Start Delay** yang tinggi akan menunjukkan bahwa sebagian besar waktu dihabiskan untuk menunggu penghalang pos pemeriksaan mencapai operator. Ini menunjukkan bahwa aplikasi membutuhkan waktu untuk memproses catatan, yang berarti penghalang mengalir melalui grafik pekerjaan secara perlahan. Ini biasanya terjadi jika Job mengalami backpressure atau jika operator terus-menerus sibuk. Berikut ini adalah contoh JobGraph di mana KeyedProcess operator kedua sibuk.
![\[Menyelidiki pos pemeriksaan\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/checkpoint2.png)
Anda dapat menyelidiki apa yang memakan waktu lama dengan menggunakan Flink Flame Graphs atau TaskManager thread dump. Setelah leher botol diidentifikasi, dapat diselidiki lebih lanjut menggunakan Flame-graphs atau thread-dumps.
## Pembuangan benang
Thread dump adalah alat debugging lain yang berada pada tingkat yang sedikit lebih rendah dari grafik api. Thread dump menampilkan status eksekusi semua thread pada satu titik waktu. Flink mengambil dump thread JVM, yang merupakan status eksekusi dari semua thread dalam proses Flink. Keadaan utas disajikan oleh jejak tumpukan utas serta beberapa informasi tambahan. Grafik api sebenarnya dibuat menggunakan beberapa jejak tumpukan yang diambil secara berurutan. Grafik adalah visualisasi yang dibuat dari jejak ini yang membuatnya mudah untuk mengidentifikasi jalur kode umum.
```
"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)
...
```
Di atas adalah cuplikan dump utas yang diambil dari UI Flink untuk satu utas. Baris pertama berisi beberapa informasi umum tentang utas ini termasuk:
+ Nama thread *KeyedProcess (1/3) \$10*
+ Prioritas thread *prio=5*
+ Utas unik Id *Id=1423*
+ Status utas *RUNNABLE*
Nama utas biasanya memberikan informasi tentang tujuan umum utas. Utas operator dapat diidentifikasi dengan namanya karena utas operator memiliki nama yang sama dengan operator, serta indikasi subtugas mana yang terkait dengannya, misalnya, utas *KeyedProcess (1/3) \$10* berasal dari *KeyedProcess*operator dan berasal dari subtugas pertama (dari 3).
Thread dapat berada di salah satu dari beberapa negara bagian:
+ BARU - Thread telah dibuat tetapi belum diproses
+ RUNNABLE — Thread adalah eksekusi pada CPU
+ DIBLOKIR - Utas sedang menunggu utas lain untuk melepaskan kuncinya
+ WAITING — Thread sedang menunggu dengan menggunakan`wait()`,`join()`, atau `park()` metode
+ TIMED\$1WAITING — Thread sedang menunggu dengan menggunakan metode sleep, wait, join atau park, tetapi dengan waktu tunggu maksimum.
**catatan**
Di Flink 1.13, kedalaman maksimum satu stacktrace di thread dump dibatasi hingga 8.
**catatan**
Thread dump harus menjadi pilihan terakhir untuk men-debug masalah kinerja dalam aplikasi Flink karena dapat menantang untuk dibaca, memerlukan beberapa sampel untuk diambil dan dianalisis secara manual. Jika memungkinkan, lebih baik menggunakan grafik nyala api.
### Pembuangan utas di Flink
**Di Flink, dump thread dapat diambil dengan memilih opsi **Task Manager** di bilah navigasi kiri UI Flink, memilih pengelola tugas tertentu, dan kemudian menavigasi ke tab Thread Dump.** Thread dump dapat diunduh, disalin ke editor teks favorit Anda (atau thread dump analyzer), atau dianalisis langsung di dalam tampilan teks di UI Web Flink (namun, opsi terakhir ini bisa sedikit kikuk.
Untuk menentukan Task Manager mana yang akan mengambil thread dump dari **TaskManagers**tab dapat digunakan ketika operator tertentu dipilih. Ini menunjukkan bahwa operator berjalan pada subtugas yang berbeda dari operator dan dapat berjalan pada Manajer Tugas yang berbeda.
![\[Menggunakan Thread Dump\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/checkpoint4.png)
Dump akan terdiri dari beberapa jejak tumpukan. Namun ketika menyelidiki dump yang terkait dengan operator adalah yang paling penting. Ini dapat dengan mudah ditemukan karena utas operator memiliki nama yang sama dengan operator, serta indikasi subtugas mana yang terkait dengannya. Misalnya jejak tumpukan berikut berasal dari *KeyedProcess*operator dan merupakan subtugas pertama.
```
"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)
...
```
Ini bisa menjadi membingungkan jika ada beberapa operator dengan nama yang sama tetapi kita dapat memberi nama operator untuk menyiasatinya. Contoh:
```
....
.process(new ExpensiveFunction).name("Expensive function")
```
## [Grafik api](https://nightlies.apache.org/flink/flink-docs-release-1.13/docs/ops/debugging/flame_graphs/)
Grafik api adalah alat debugging yang berguna yang memvisualisasikan jejak tumpukan kode yang ditargetkan, yang memungkinkan jalur kode yang paling sering diidentifikasi. Mereka dibuat dengan pengambilan sampel jejak tumpukan beberapa kali. Sumbu x dari grafik nyala menunjukkan profil tumpukan yang berbeda, sedangkan sumbu y menunjukkan kedalaman tumpukan, dan panggilan dalam jejak tumpukan. Sebuah persegi panjang tunggal dalam grafik nyala mewakili pada bingkai tumpukan, dan lebar bingkai menunjukkan seberapa sering muncul di tumpukan. Untuk detail selengkapnya tentang grafik api dan cara menggunakannya, lihat [Grafik Api](https://www.brendangregg.com/flamegraphs.html).
Di Flink, grafik api untuk operator dapat diakses melalui UI Web dengan memilih operator dan kemudian memilih **FlameGraph**tab. Setelah sampel yang cukup dikumpulkan, flamegraph akan ditampilkan. Berikut ini adalah FlameGraph untuk ProcessFunction yang mengambil banyak waktu untuk pos pemeriksaan.
![\[Menggunakan grafik Flame\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/checkpoint3.png)
Ini adalah grafik api yang sangat sederhana dan menunjukkan bahwa semua waktu CPU dihabiskan dalam tampilan foreach di `processElement` dalam ExpensiveFunction operator. Anda juga mendapatkan nomor baris untuk membantu menentukan di mana eksekusi kode berlangsung.
# Waktu titik checkpointing
Jika aplikasi Anda tidak dioptimalkan atau disediakan dengan benar, titik pemeriksaan bisa gagal. Bagian ini menjelaskan gejala dan langkah pemecahan masalah untuk kondisi ini.
## Gejala
Jika titik pemeriksaan gagal untuk aplikasi Anda, `numberOfFailedCheckpoints` akan lebih besar dari nol.
Titik pemeriksaan bisa gagal karena kegagalan langsung, seperti kesalahan aplikasi, atau karena kegagalan sementara, seperti kehabisan sumber daya aplikasi. Periksa log dan metrik aplikasi Anda untuk gejala berikut:
+ Kesalahan dalam kode Anda.
+ Kesalahan mengakses layanan dependen aplikasi Anda.
+ Kesalahan serialisasi data. Jika serializer default tidak dapat membuat serialisasi data aplikasi Anda, aplikasi akan gagal. Untuk informasi tentang menggunakan serializer kustom dalam aplikasi Anda, lihat [Jenis Data dan Serialisasi](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/dev/datastream/fault-tolerance/serialization/types_serialization/) di Dokumentasi Apache Flink.
+ Kesalahan Kehabisan Memori.
+ Lonjakan atau peningkatan stabil dalam metrik berikut:
+ `heapMemoryUtilization`
+ `oldGenerationGCTime`
+ `oldGenerationGCCount`
+ `lastCheckpointSize`
+ `lastCheckpointDuration`
Untuk informasi selengkapnya tentang pemantauan pos pemeriksaan, lihat [Memantau Checkpointing](https://nightlies.apache.org/flink/flink-docs-release-1.19/docs/ops/monitoring/checkpoint_monitoring/) di Dokumentasi Apache Flink.
## Penyebab dan solusi
Pesan kesalahan log aplikasi Anda menunjukkan penyebab kegagalan langsung. Kegagalan sementara dapat disebabkan hal berikut:
+ Persediaan KPU aplikasi Anda tidak cukup. Untuk informasi tentang meningkatkan persediaan aplikasi Anda, lihat [Menerapkan penskalaan aplikasi](how-scaling.md).
+ Ukuran status aplikasi Anda terlalu besar. Anda dapat memantau ukuran status aplikasi Anda menggunakan metrik `lastCheckpointSize`.
+ Data status aplikasi Anda tidak didistribusikan secara merata di antara kunci. Jika aplikasi Anda menggunakan operator `KeyBy`, pastikan data yang masuk dibagi rata di antara kunci. Jika sebagian besar data ditetapkan ke satu kunci, ini membuat hambatan yang menyebabkan kegagalan.
+ Aplikasi Anda mengalami tekanan balik memori atau pengumpulan sampah. Pantau `heapMemoryUtilization`, `oldGenerationGCTime`, dan `oldGenerationGCCount` aplikasi Anda untuk lonjakan atau nilai yang terus meningkat.
# Kegagalan pos pemeriksaan untuk aplikasi Apache Beam
Jika aplikasi Beam Anda dikonfigurasi dengan [shutdownSourcesAfterIdleMs](https://beam.apache.org/documentation/runners/flink/#:~:text=shutdownSourcesAfterIdleMs)disetel ke 0ms, pos pemeriksaan dapat gagal dipicu karena tugas dalam status “SELESAI”. Bagian ini menjelaskan gejala dan resolusi untuk kondisi ini.
## Gejala
Buka Layanan Terkelola untuk CloudWatch log aplikasi Apache Flink Anda dan periksa apakah pesan log berikut telah dicatat. Pesan log berikut menunjukkan bahwa pos pemeriksaan gagal dipicu karena beberapa tugas telah selesai.
```
{
"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"
}
```
Ini juga dapat ditemukan di dasbor Flink di mana beberapa tugas telah memasuki status “SELESAI”, dan pos pemeriksaan tidak dimungkinkan lagi.
![\[Tugas dalam keadaan “SELESAI”\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/beam_checkpoint_failure.png)
## Penyebab
shutdownSourcesAfterIdleMs adalah variabel konfigurasi Beam yang mematikan sumber yang telah menganggur selama waktu milidetik yang dikonfigurasi. Setelah sumber dimatikan, pos pemeriksaan tidak dimungkinkan lagi. Hal ini dapat menyebabkan [kegagalan pos pemeriksaan](https://issues.apache.org/jira/browse/FLINK-2491).
Salah satu penyebab tugas memasuki status “SELESAI” shutdownSourcesAfter IdleMs adalah ketika diatur ke 0ms, yang berarti bahwa tugas yang menganggur akan segera dimatikan.
## Solusi
Untuk mencegah tugas memasuki status “SELESAI” segera, setel shutdownSourcesAfter IdleMs ke long.max\$1value. Ini dapat dilakukan dengan dua cara:
+ Opsi 1: Jika konfigurasi balok Anda diatur di halaman konfigurasi aplikasi Managed Service for Apache Flink, maka Anda dapat menambahkan pasangan nilai kunci baru untuk mengatur shutdpwnSourcesAfteridle Ms sebagai berikut:
![\[Setel shutdownSourcesAfter IdleMs ke Long.MAX_Value\]](http://docs.aws.amazon.com/id_id/managed-flink/latest/java/images/beam_checkpoint_failure_solution.png)
+ Opsi 2: Jika konfigurasi balok Anda diatur dalam file JAR Anda, maka Anda dapat mengatur shutdownSourcesAfter IdleMs sebagai berikut:
```
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
```
# Tekanan balik
Flink menggunakan tekanan balik untuk menyesuaikan kecepatan pemrosesan masing-masing operator.
Operator dapat berjuang untuk terus memproses volume pesan yang diterimanya karena berbagai alasan. Operasi mungkin memerlukan lebih banyak sumber daya CPU daripada yang tersedia operator, Operator mungkin menunggu I/O operasi selesai. Jika operator tidak dapat memproses peristiwa dengan cukup cepat, itu membangun tekanan balik di operator hulu yang masuk ke operator lambat. Hal ini menyebabkan operator hulu melambat, yang selanjutnya dapat menyebarkan tekanan balik ke sumber dan menyebabkan sumber beradaptasi dengan keseluruhan throughput aplikasi dengan memperlambat juga. Anda dapat menemukan deskripsi tekanan balik yang lebih dalam dan cara kerjanya di [Bagaimana Apache Flink™](https://www.ververica.com/blog/how-flink-handles-backpressure) menangani tekanan balik.
Mengetahui operator mana dalam aplikasi yang lambat memberi Anda informasi penting untuk memahami akar penyebab masalah kinerja dalam aplikasi. Informasi tekanan balik [diekspos melalui Dasbor Flink](https://nightlies.apache.org/flink/flink-docs-stable/docs/ops/monitoring/back_pressure/). Untuk mengidentifikasi operator lambat, cari operator dengan nilai tekanan balik tinggi yang paling dekat dengan wastafel (operator B pada contoh berikut). Operator yang menyebabkan kelambatan kemudian menjadi salah satu operator hilir (operator C dalam contoh). B dapat memproses peristiwa lebih cepat, tetapi ditekan kembali karena tidak dapat meneruskan output ke operator lambat yang sebenarnya C.
```
A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)
```
Setelah Anda mengidentifikasi operator yang lambat, cobalah untuk memahami mengapa itu lambat. Mungkin ada banyak alasan dan terkadang tidak jelas apa yang salah dan dapat memerlukan berhari-hari debugging dan pembuatan profil untuk menyelesaikannya. Berikut adalah beberapa alasan yang jelas dan lebih umum, beberapa di antaranya dijelaskan lebih lanjut di bawah ini:
+ Operator melakukan I/O lambat, misalnya, panggilan jaringan (pertimbangkan untuk menggunakan AsynciO sebagai gantinya).
+ Ada kemiringan dalam data dan satu operator menerima lebih banyak peristiwa daripada yang lain (verifikasi dengan melihat jumlah pesan dari subtugas individu (yaitu, contoh in/out dari operator yang sama) di dasbor Flink.
+ Ini adalah operasi intensif sumber daya (jika tidak ada kemiringan data, pertimbangkan penskalaan untuk pekerjaan CPU/memory terikat atau meningkat `ParallelismPerKPU` untuk I/O pekerjaan terikat)
+ Logging ekstensif di operator (kurangi logging seminimal mungkin untuk aplikasi produksi atau pertimbangkan untuk mengirim output debug ke aliran data sebagai gantinya).
## Menguji throughput dengan Discarding Sink
[Discarding Sink](https://nightlies.apache.org/flink/flink-docs-stable/api/java/org/apache/flink/streaming/api/functions/sink/DiscardingSink.html) mengabaikan semua peristiwa yang diterimanya saat masih menjalankan aplikasi (aplikasi tanpa sink gagal dijalankan). Ini sangat berguna untuk pengujian throughput, pembuatan profil, dan untuk memverifikasi apakah aplikasi melakukan penskalaan dengan benar. Ini juga merupakan pemeriksaan kewarasan yang sangat pragmatis untuk memverifikasi apakah sink menyebabkan tekanan balik atau aplikasi (tetapi hanya memeriksa metrik tekanan balik seringkali lebih mudah dan lebih mudah).
Dengan mengganti semua sink aplikasi dengan wastafel pembuangan dan membuat sumber tiruan yang menghasilkan data yang r misalnya data produksi, Anda dapat mengukur throughput maksimum aplikasi untuk pengaturan paralelisme tertentu. Anda kemudian juga dapat meningkatkan paralelisme untuk memverifikasi bahwa aplikasi menskalakan dengan benar dan tidak memiliki hambatan yang hanya muncul pada throughput yang lebih tinggi (misalnya, karena kemiringan data).
# Kemiringan data
Aplikasi Flink dijalankan pada cluster dengan cara terdistribusi. Untuk skala ke beberapa node, Flink menggunakan konsep aliran yang dikunci, yang pada dasarnya berarti bahwa peristiwa aliran dipartisi sesuai dengan kunci tertentu, misalnya, id pelanggan, dan Flink kemudian dapat memproses partisi yang berbeda pada node yang berbeda. [Banyak operator Flink kemudian dievaluasi berdasarkan partisi ini, misalnya, [Keyed Windows, [Process Functions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/process_function/)](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/) dan Async I/O.](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/asyncio/)
Memilih kunci partisi sering tergantung pada logika bisnis. Pada saat yang sama, banyak praktik terbaik untuk, misalnya, [DynamoDB](https://aws.amazon.com/dynamodb/) dan Spark, sama-sama berlaku untuk Flink, termasuk:
+ memastikan kardinalitas kunci partisi yang tinggi
+ menghindari kemiringan dalam volume acara antar partisi
Anda dapat mengidentifikasi kemiringan di partisi dengan membandingkan catatan subtugas (yaitu, contoh received/sent dari operator yang sama) di dasbor Flink. Selain itu, Layanan Terkelola untuk pemantauan Apache Flink dapat dikonfigurasi untuk mengekspos metrik untuk `numRecordsIn/Out` dan `numRecordsInPerSecond/OutPerSecond` pada tingkat subtugas juga.
# Kemiringan negara
Untuk operator stateful, yaitu, operator yang mempertahankan status untuk logika bisnis mereka seperti windows, kemiringan data selalu mengarah ke kemiringan status. Beberapa subtugas menerima lebih banyak peristiwa daripada yang lain karena kemiringan data dan karenanya juga mempertahankan lebih banyak data dalam keadaan. Namun, bahkan untuk aplikasi yang memiliki partisi seimbang secara merata, mungkin ada kemiringan dalam berapa banyak data yang disimpan dalam keadaan. Misalnya, untuk jendela sesi, beberapa pengguna dan sesi masing-masing mungkin jauh lebih lama daripada yang lain. Jika sesi yang lebih panjang kebetulan menjadi bagian dari partisi yang sama, itu dapat menyebabkan ketidakseimbangan ukuran status yang disimpan oleh subtugas yang berbeda dari operator yang sama.
Kemiringan status tidak hanya meningkatkan lebih banyak memori dan sumber daya disk yang dibutuhkan oleh subtugas individu, tetapi juga dapat menurunkan kinerja aplikasi secara keseluruhan. Saat aplikasi mengambil pos pemeriksaan atau savepoint, status operator dipertahankan ke Amazon S3, untuk melindungi status terhadap kegagalan node atau cluster. Selama proses ini (terutama dengan semantik sekali yang diaktifkan secara default pada Managed Service for Apache Flink), pemrosesan berhenti dari perspektif eksternal hingga selesai. checkpoint/savepoint Jika ada kemiringan data, waktu untuk menyelesaikan operasi dapat diikat oleh satu subtugas yang telah mengumpulkan jumlah status yang sangat tinggi. Dalam kasus ekstrim, pengambilan checkpoints/savepoints dapat gagal karena satu subtugas tidak dapat bertahan.
Jadi mirip dengan kemiringan data, kemiringan status secara substansional dapat memperlambat aplikasi.
Untuk mengidentifikasi kemiringan status, Anda dapat memanfaatkan dasbor Flink. Temukan pos pemeriksaan atau savepoint terbaru dan bandingkan jumlah data yang telah disimpan untuk subtugas individual dalam detailnya.
# Integrasikan dengan sumber daya di berbagai Wilayah
Anda dapat mengaktifkan penggunaan `StreamingFileSink` untuk menulis ke bucket Amazon S3 di Wilayah yang berbeda dari aplikasi Layanan Terkelola untuk Apache Flink melalui pengaturan yang diperlukan untuk replikasi lintas Wilayah dalam konfigurasi Flink. Untuk melakukan ini, ajukan tiket dukungan di [AWS Dukungan Center](https://console.aws.amazon.com/support/home#/).