Titik pemeriksaan - Layanan Terkelola untuk Apache Flink

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.

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, penyimpanan kunci/nilai 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? .

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 Sejarah.

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.

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 snapshotState antarmuka; 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). 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

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

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 JVM thread, 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(<console>>19) at $line33.$read$$iw$$iw$ExpensiveFunction.processElement(<console>: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 utas KeyedProcess (1/3) #0

  • 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) #0 berasal dari KeyedProcessoperator dan berasal dari subtugas pertama (dari 3).

Thread dapat berada di salah satu dari beberapa negara bagian:

  • NEW— Thread telah dibuat tetapi belum diproses

  • RUNNABLE— Thread adalah eksekusi pada CPU

  • BLOCKED— Utas sedang menunggu utas lain untuk melepaskan kuncinya

  • WAITING— Thread sedang menunggu dengan menggunakanwait(),join(), atau park() metode

  • TIMED_ WAITING — Utas 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.

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 TaskManagerstab 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

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 KeyedProcessoperator 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(<console>:19) at $line360.$read$$iw$$iw$ExpensiveFunction.processElement(<console>: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. Sebagai contoh:

.... .process(new ExpensiveFunction).name("Expensive function")

Grafik api

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.

Di Flink, grafik api untuk operator dapat diakses melalui UI Web dengan memilih operator dan kemudian memilih FlameGraphtab. Setelah sampel yang cukup dikumpulkan, flamegraph akan ditampilkan. Berikut ini adalah FlameGraph untuk ProcessFunction yang mengambil banyak waktu untuk pos pemeriksaan.

Menggunakan grafik Flame

Ini adalah grafik api yang sangat sederhana dan menunjukkan bahwa semua CPU waktu dihabiskan dalam tampilan foreach di processElement dalam ExpensiveFunction operator. Anda juga mendapatkan nomor baris untuk membantu menentukan di mana eksekusi kode berlangsung.