Memantau pekerjaan AWS Glue streaming - AWS Glue

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memantau pekerjaan AWS Glue streaming

Memantau pekerjaan streaming Anda adalah bagian penting dalam membangun saluran ETL Anda. Selain menggunakan UI Spark, Anda juga dapat menggunakan Amazon CloudWatch untuk memantau metrik. Di bawah ini adalah daftar metrik streaming yang dipancarkan oleh kerangka kerja. AWS Glue Untuk daftar lengkap semua AWS Glue metrik, lihat Memantau AWS Glue menggunakan CloudWatch metrik Amazon.

AWS Gluemenggunakan kerangka kerja streaming terstruktur untuk memproses peristiwa input. Anda dapat menggunakan Spark API secara langsung dalam kode Anda atau memanfaatkan yang ForEachBatch disediakan olehGlueContext, yang menerbitkan metrik ini. Untuk memahami metrik ini, kita harus terlebih dahulu memahamiwindowSize.

WindowSize: windowSize adalah interval batch mikro yang Anda berikan. Jika Anda menentukan ukuran jendela 60 detik, pekerjaan AWS Glue streaming akan menunggu selama 60 detik (atau lebih jika batch sebelumnya belum selesai saat itu) sebelum akan membaca data dalam batch dari sumber streaming dan menerapkan transformasi yang disediakan diForEachBatch. Ini juga disebut sebagai interval pemicu.

Mari kita tinjau metrik secara lebih rinci untuk memahami karakteristik kesehatan dan kinerja.

catatan

Metrik dipancarkan setiap 30 detik. Jika Anda windowSize kurang dari 30 detik maka metrik yang dilaporkan adalah agregasi. Misalnya katakanlah Anda windowSize 10 detik dan Anda terus memproses 20 catatan per batch mikro. Dalam skenario ini, nilai metrik yang dipancarkan untuk NumRecords adalah 60.

Metrik tidak dipancarkan jika tidak ada data yang tersedia untuk itu. Juga, dalam kasus metrik lag konsumen, Anda harus mengaktifkan fitur untuk mendapatkan metrik untuk itu.

Memvisualisasikan metrik

Untuk memplot metrik visual:

  1. Buka Metrik di CloudWatch konsol Amazon dan kemudian pilih tab Browse. Kemudian pilih Glue di bawah “Ruang nama khusus”.

    Tangkapan layar menunjukkan metrik mengakses di CloudWatch konsol Amazon saat memantau pekerjaan AWS Glue streaming.
  2. Pilih Job Metrics untuk menampilkan metrik untuk semua pekerjaan Anda.

  3. Filter metrik berdasarkan JobName = Anda glue-feb-monitoring dan kemudian JobRunId = SEMUA. Anda dapat mengklik tanda “+” seperti yang ditunjukkan pada gambar di bawah ini untuk menambahkannya ke filter pencarian.

  4. Pilih kotak centang untuk metrik yang Anda minati. Pada gambar di bawah ini kami telah memilih numberAllExecutors dannumberMaxNeededExecutors.

    Tangkapan layar menunjukkan penerapan rata-rata ke metrik saat memantau pekerjaan streaming.
  5. Setelah Anda memilih metrik ini, Anda dapat pergi ke tab Metrik grafik dan menerapkan statistik Anda.

  6. Karena metrik dipancarkan setiap menit, Anda dapat menerapkan “rata-rata” selama satu menit untuk dan. batchProcessingTimeInMs maxConsumerLagInMs Untuk numRecords Anda dapat menerapkan “jumlah” setiap menit.

  7. Anda dapat menambahkan windowSize anotasi horizontal ke grafik Anda menggunakan tab Opsi.

    Tangkapan layar menunjukkan penambahan anotasi WindowSize ke grafik Anda saat memantau pekerjaan streaming.
  8. Setelah metrik dipilih, buat dasbor dan tambahkan. Berikut adalah contoh dasbor.

    Tangkapan layar menunjukkan dasbor sampel untuk memantau pekerjaan streaming.

Metrik penyelaman mendalam

Bagian ini menjelaskan masing-masing metrik dan bagaimana mereka saling berhubungan satu sama lain.

Jumlah catatan (metrik: streaming.numRecords)

Metrik ini menunjukkan berapa banyak catatan yang sedang diproses.

Tangkapan layar menunjukkan pemantauan jumlah catatan dalam pekerjaan streaming.

Metrik streaming ini memberikan visibilitas ke dalam jumlah catatan yang Anda proses di jendela. Seiring dengan jumlah catatan yang diproses, ini juga akan membantu Anda memahami perilaku lalu lintas input.

  • Indikator #1 menunjukkan contoh lalu lintas stabil tanpa semburan apapun. Biasanya ini akan menjadi aplikasi seperti sensor IoT yang mengumpulkan data secara berkala dan mengirimkannya ke sumber streaming.

  • Indikator #2 menunjukkan contoh ledakan lalu lintas yang tiba-tiba pada beban yang stabil. Ini bisa terjadi di aplikasi clickstream ketika ada acara pemasaran seperti Black Friday dan ada ledakan dalam jumlah klik

  • Indikator #3 menunjukkan contoh lalu lintas yang tidak dapat diprediksi. Lalu lintas yang tidak dapat diprediksi tidak berarti ada masalah. Itu hanya sifat dari data input. Kembali ke contoh sensor IoT, Anda dapat memikirkan ratusan sensor yang mengirimkan peristiwa perubahan cuaca ke sumber streaming. Karena perubahan cuaca tidak dapat diprediksi, begitu pula datanya. Memahami pola lalu lintas adalah kunci untuk mengukur pelaksana Anda. Jika inputnya sangat runcing, Anda dapat mempertimbangkan untuk menggunakan penskalaan otomatis (lebih lanjut tentang itu nanti).

Tangkapan layar menunjukkan pemantauan menggunakan jumlah catatan dan PutRecords metrik Kinesis dalam pekerjaan streaming.

Anda dapat menggabungkan metrik ini dengan PutRecords metrik Kinesis untuk memastikan jumlah peristiwa yang dicerna dan jumlah catatan yang dibaca hampir sama. Ini sangat berguna ketika Anda mencoba memahami lag. Saat tingkat konsumsi meningkat, begitu juga dengan numRecords membaca. AWS Glue

Waktu pemrosesan batch (metrik: streaming. batchProcessingTimeInMs)

Metrik waktu pemrosesan batch membantu Anda menentukan apakah klaster tidak tersedia atau dilebih-lebihkan.

Tangkapan layar menunjukkan pemantauan waktu pemrosesan batch dalam pekerjaan streaming.

Metrik ini menunjukkan jumlah milidetik yang diperlukan untuk memproses setiap kumpulan catatan mikro. Tujuan utama di sini adalah untuk memantau waktu ini untuk memastikannya kurang dari windowSize interval. Tidak apa-apa jika batchProcessingTimeInMs berjalan sementara selama pulih dalam interval jendela berikut. Indikator #1 menunjukkan waktu yang kurang lebih stabil yang dibutuhkan untuk memproses pekerjaan. Namun jika jumlah catatan masukan meningkat, waktu yang dibutuhkan untuk memproses pekerjaan akan meningkat serta ditunjukkan oleh indikator #2. Jika numRecords tidak naik, tetapi waktu pemrosesan naik, maka Anda perlu melihat lebih dalam pemrosesan pekerjaan pada pelaksana. Ini adalah praktik yang baik untuk menetapkan ambang batas dan alarm untuk memastikan batchProcessingTimeInMs tidak tinggal lebih dari 120% selama lebih dari 10 menit. Untuk informasi selengkapnya tentang menyetel alarm, lihat Menggunakan CloudWatch alarm Amazon.

Kelambatan konsumen (metrik: streaming. maxConsumerLagInMs)

Metrik lag konsumen membantu Anda memahami jika ada kelambatan dalam memproses peristiwa. Jika lag Anda terlalu tinggi, maka Anda bisa melewatkan pemrosesan SLA yang bergantung pada bisnis Anda, meskipun Anda memiliki WindowSize yang benar. Anda harus mengaktifkan metrik ini secara eksplisit menggunakan opsi koneksi. emitConsumerLagMetrics Untuk informasi lebih lanjut, lihat KinesisStreamingSourceOptions.

Tangkapan layar menunjukkan pemantauan lag dalam pekerjaan streaming.

Metrik turunan

Untuk mendapatkan wawasan yang lebih dalam, Anda dapat membuat metrik turunan untuk memahami lebih lanjut tentang pekerjaan streaming Anda di Amazon. CloudWatch

Tangkapan layar menunjukkan pemantauan metrik turunan dalam pekerjaan streaming.

Anda dapat membuat grafik dengan metrik turunan untuk memutuskan apakah Anda perlu menggunakan lebih banyak DPU. Meskipun penskalaan otomatis membantu Anda melakukan ini secara otomatis, Anda dapat menggunakan metrik turunan untuk menentukan apakah penskalaan otomatis bekerja secara efektif.

  • InputRecordsPerSecondmenunjukkan tingkat di mana Anda mendapatkan catatan input. Hal ini diturunkan sebagai berikut: jumlah catatan input (Glue.driver.streaming.numRecords)/. WindowSize

  • ProcessingRecordsPerSecondmenunjukkan tingkat di mana catatan Anda sedang diproses. Hal ini diturunkan sebagai berikut: jumlah catatan input (Glue.driver.streaming.numRecords)/. batchProcessingTime InMs

Jika tingkat input lebih tinggi dari tingkat pemrosesan, maka Anda mungkin perlu menambahkan lebih banyak kapasitas untuk memproses pekerjaan Anda atau meningkatkan paralelisme.

Metrik penskalaan otomatis

Ketika lalu lintas input Anda runcing, maka Anda harus mempertimbangkan untuk mengaktifkan penskalaan otomatis dan menentukan pekerja maks. Dengan itu Anda mendapatkan dua metrik tambahan, numberAllExecutors dannumberMaxNeededExecutors.

  • numberAllExecutorsadalah jumlah pelaksana pekerjaan yang aktif menjalankan

  • numberMaxNeededPelaksana adalah jumlah pelaksana pekerjaan maksimum (aktif berjalan dan tertunda) yang diperlukan untuk memenuhi beban saat ini.

Kedua metrik ini akan membantu Anda memahami apakah penskalaan otomatis Anda berfungsi dengan benar.

Tangkapan layar menunjukkan pemantauan penskalaan otomatis dalam pekerjaan streaming.

AWS Glueakan memantau batchProcessingTimeInMs metrik melalui beberapa batch mikro dan melakukan salah satu dari dua hal. Ini akan meningkatkan skala pelaksana, jika batchProcessingTimeInMs lebih dekat ke, atau skala-di pelaksanawindowSize, jika relatif lebih rendah dari. batchProcessingTimeInMs windowSize Juga, itu akan menggunakan algoritma untuk langkah-scaling pelaksana.

  • indikator #1 menunjukkan kepada Anda bagaimana pelaksana aktif ditingkatkan untuk mengejar ketinggalan dengan eksekutor maksimal yang dibutuhkan untuk memproses beban.

  • indikator #2 menunjukkan kepada Anda bagaimana eksekutif aktif menskalakan sejak rendahbatchProcessingTimeInMs.

Anda dapat menggunakan metrik ini untuk memantau paralelisme tingkat eksekusi saat ini dan menyesuaikan jumlah pekerja maksimal dalam konfigurasi auto-scaling Anda.

Cara mendapatkan kinerja terbaik

Spark akan mencoba membuat satu tugas per pecahan, untuk dibaca dari, di aliran Amazon Kinesis. Data di setiap pecahan menjadi partisi. Ini kemudian akan mendistribusikan tugas-tugas ini di seluruh pelaksana/pekerja, tergantung dari jumlah inti pada setiap pekerja (jumlah inti per pekerja tergantung pada jenis pekerja yang Anda pilihG.025X,, G.1X dll). Namun tidak deterministik bagaimana tugas didistribusikan. Semua tugas dijalankan secara paralel pada inti masing-masing. Jika ada lebih banyak pecahan daripada jumlah inti pelaksana yang tersedia, tugas akan diantri.

Anda dapat menggunakan kombinasi metrik di atas dan jumlah pecahan, untuk menyediakan eksekutor Anda untuk beban yang stabil dengan beberapa ruang untuk semburan. Disarankan agar Anda menjalankan beberapa iterasi pekerjaan Anda untuk menentukan perkiraan jumlah pekerja. Untuk beban kerja yang tidak stabil/runcing, Anda dapat melakukan hal yang sama dengan menyiapkan penskalaan otomatis dan pekerja maks.

Tetapkan windowSize sesuai kebutuhan SLA bisnis Anda. Misalnya, jika bisnis Anda mengharuskan data yang diproses tidak boleh lebih dari 120 detik basi, maka atur windowSize ke setidaknya 60 detik sehingga kelambatan konsumen rata-rata Anda kurang dari 120 detik (lihat bagian tentang kelambatan konsumen di atas). Dari sana tergantung pada numRecords dan jumlah pecahan, rencanakan kapasitas dalam DPU untuk memastikan Anda batchProcessingTimeInMs kurang dari 70% dari windowSize sebagian besar waktu Anda.

catatan

Pecahan panas dapat menyebabkan kemiringan data yang berarti bahwa beberapa piringan/partisi jauh lebih besar daripada yang lain. Hal ini dapat menyebabkan beberapa tugas yang berjalan secara paralel membutuhkan waktu lebih lama menyebabkan tugas straggler. Akibatnya, batch berikutnya tidak dapat dimulai sampai semua tugas dari yang sebelumnya selesai, ini akan berdampak pada batchProcessingTimeInMillis dan lag maksimal.