Amazon Managed Service untuk Apache Flink sebelumnya dikenal sebagai Amazon Kinesis Data Analytics untuk Apache Flink.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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 operasi I/O 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ā¢
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
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 masuk/keluar dari subtugas individu (yaitu, contoh dari operator yang sama) di dasbor Flink.
Ini adalah operasi intensif sumber daya (jika tidak ada kemiringan data, pertimbangkan penskalaan untuk pekerjaan terikat CPU/memori atau peningkatan untuk pekerjaan terikat I/O)
ParallelismPerKPU
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
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).