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 State Time-To-Live (TTL) di Dokumentasi 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. Untuk informasi selengkapnya, lihat Dokumentasi Apache Beam.

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 AggregateFunctionsdigunakan, yang memungkinkan agregasi tambahan, 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 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. 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). Ini membutuhkan tiket ke tim layanan.