MaxCompute：Praktik Diagnostik Logview

Analisis job yang gagal

Saat sebuah job gagal, Anda dapat melihat pesan error pada tab Result di Logview. Logview membuka tab ini secara default untuk job yang gagal.

Analisis job lambat

Fase kompilasi

• Fase penjadwalan

  Gejala: Sub-status adalah Waiting for cluster resource, dan job masuk antrian untuk kompilasi.

  Penyebab: Compute cluster mengalami kekurangan resource.

  Solusi: Periksa status kluster. Tunggu hingga resource tersedia. Pelanggan subscription dapat mempertimbangkan untuk melakukan scale out resource.

• Fase optimasi

  Gejala: Sub-status adalah SQLTask is optimizing query, yang menunjukkan bahwa optimizer sedang menghasilkan execution plan.

  Penyebab: Execution plan kompleks dan memerlukan waktu lama untuk dioptimalkan.

  Solusi: Tunggu proses selesai. Biasanya memakan waktu kurang dari 10 menit.

• Fase pembuatan rencana eksekusi fisik

  Gejala: Sub-status adalah SQLTask is generating execution plan.

  Penyebab 1: Terlalu banyak partisi yang dibaca.

  Solusi: Optimalkan kueri SQL Anda agar membaca lebih sedikit partisi. Gunakan partition pruning, filter partisi yang tidak diperlukan, atau pecah job besar menjadi beberapa job kecil. Untuk informasi lebih lanjut, lihat Mengevaluasi Efektivitas Partition Pruning.

  Penyebab 2: Terlalu banyak file kecil. Hal ini sering disebabkan oleh:

  1. Operasi upload Tunnel yang tidak tepat. Misalnya, membuat upload session baru untuk setiap file yang diunggah. Untuk detailnya, lihat FAQ Perintah Tunnel.

  2. Operasi INSERT INTO pada tabel partisi yang menghasilkan file baru di direktori partition.

  Solusi:

  1. Gunakan antarmuka TunnelBufferedWriter untuk mengunggah file. Ini membantu menghindari pembuatan file kecil yang berlebihan.

  2. Gabungkan file kecil secara manual. Untuk detailnya, lihat Gabungkan file kecil.

  Catatan

  Anda dapat menggabungkan file kecil jika jumlahnya melebihi 10.000. Sistem mencoba menggabungkan file kecil setiap hari, tetapi penggabungan manual mungkin diperlukan jika penggabungan otomatis gagal.

• Fase replikasi data antar kluster

  Gejala: Daftar sub-status menampilkan beberapa entri Task rerun, dan tab Result menampilkan error FAILED: ODPS-0110141:Data version exception. Status job adalah Running. Hal ini menunjukkan bahwa replikasi data antar kluster sedang berlangsung.

  Penyebab 1: Proyek baru saja dimigrasikan ke kluster baru. Replikasi antar kluster umum terjadi selama beberapa hari pertama setelah migrasi.

  Solusi: Ini merupakan perilaku yang diharapkan. Tunggu hingga replikasi selesai.

  Penyebab 2: Proyek telah dimigrasikan, tetapi pemfilteran partisi tidak ditangani dengan benar, sehingga partisi lama ikut dibaca.

  Solusi: Filter partisi lama yang tidak perlu dibaca.

Fase eksekusi

Pada fase Eksekusi, halaman Job Details menampilkan execution plan, tetapi status job tetap Running. Penyebab umum keterlambatan meliputi antrian resource, data skew, UDF tidak efisien, dan data bloat.

• Menunggu Sumber Daya

  Karakteristik: Instans berstatus Ready, atau sebagian berstatus Running sementara yang lain masih Ready. Catatan: Jika sebuah instans berstatus Ready tetapi memiliki riwayat Debug, kemungkinan besar instans tersebut sedang mencoba ulang setelah kegagalan, bukan menunggu resource.

  Solusi:

  1. Periksa apakah antrian bersifat normal. Periksa Queue Length di Logview. Atau periksa penggunaan resource grup kuota di Konsol MaxCompute. Jika penggunaan tinggi, antrian merupakan hal yang wajar.

  2. Periksa job yang sedang berjalan di grup kuota.

     Job prioritas rendah yang besar (atau banyak job kecil) mungkin mengonsumsi resource. Hubungi pemilik job untuk menangguhkan job tersebut jika diperlukan.

  3. Gunakan proyek di grup kuota yang berbeda.

  4. Lakukan scale out resource (untuk pelanggan subscription).

• Kemiringan data

  Karakteristik: Sebagian besar instans telah selesai, tetapi beberapa instans "long tail" masih berjalan. Pada gambar, sebagian besar sudah selesai, tetapi 21 instans masih Running, kemungkinan besar memproses lebih banyak data.

  Solusi: Lihat Optimasi data skew untuk penyebab dan solusi.

• Eksekusi UDF yang Tidak Efisien

  Ini mencakup UDF, UDAF, UDTF, UDJ, dan UDT.

  Karakteristik: Task tidak efisien dan mengandung ekstensi yang didefinisikan pengguna. Error seperti Fuxi job failed - WorkerRestart errCode:252,errMsg:kInstanceMonitorTimeout dapat terjadi.

  Pemecahan Masalah: Periksa DAG pada tab Job Details untuk menemukan UDF. Misalnya, task R4_3 pada gambar menggunakan Java UDF. Perluas tampilan Operator untuk melihat nama UDF. Periksa StdOut untuk kecepatan pemrosesan. Kecepatan di bawah puluhan ribu record/detik biasanya menunjukkan masalah performa.

  Solusi:

  1. Periksa UDF terhadap error.

     Error bisa bergantung pada data (misalnya, loop tak terbatas). Unduh data sampel melalui MaxCompute Studio untuk debugging lokal. Lihat Java UDF dan Python UDF.

  2. Periksa konflik penamaan dengan fungsi bawaan.

     Pastikan UDF Anda tidak secara tidak sengaja menggantikan fungsi bawaan.

  3. Gunakan fungsi bawaan.

     Fungsi bawaan lebih efisien dan telah dioptimalkan. Lihat Fungsi bawaan.

  4. Pecah UDF. Gunakan fungsi bawaan untuk bagian yang didukung dan hanya gunakan UDF di tempat yang benar-benar diperlukan.

  5. Optimalkan metode `evaluate` pada UDF.

     Lakukan inisialisasi sekali pakai di luar metode `evaluate` untuk menghindari pengulangan.

  6. Perkirakan waktu eksekusi UDF.

     Simulasikan secara lokal untuk memperkirakan waktu proses. Batas default adalah 30 menit. UDF harus mengembalikan data atau melaporkan `context.progress()` dalam waktu tersebut. Anda dapat memperpanjang timeout jika diperlukan:

     -- Setel timeout UDF dalam detik (default 600, rentang 0-3600)
     set odps.sql.udf.timeout = 1800;

  7. Sesuaikan parameter memori.

     Ketidakefisienan dapat berasal dari masalah memori (misalnya, sorting data besar di memori, GC yang sering terjadi).

     Sesuaikan memori JVM jika diperlukan, tetapi atasi akar masalah dalam logika bisnis.

     -- Setel maksimum heap memory JVM dalam MB (default 1024, rentang 256-12288)
     set odps.sql.udf.jvm.memory = 2048;

     Catatan

     Untuk mengizinkan partition pruning saat menggunakan UDF, gunakan anotasi UdfProperty untuk menandai fungsi sebagai deterministik:

     @com.aliyun.odps.udf.annotation.UdfProperty(isDeterministic = true)
     public class AnnotatedUdf extends com.aliyun.odps.udf.UDF {
         public String evaluate(String x) {
             return x;
         }
     }

     Tulis ulang SQL agar menggunakan UDF dalam pemfilteran partisi:

     -- Asli
     SELECT * FROM t WHERE pt = udf('foo');
     -- Ditulis ulang
     SELECT * FROM t WHERE pt = (SELECT udf('foo'));

• Pembengkakan Data

  Karakteristik: Volume output jauh lebih besar daripada volume input (misalnya, 1 GB menjadi 1 TB). Periksa I/O Records. Jika terjebak di fase Join, periksa StdOut untuk log Merge Join. Jumlah record output yang berlebihan menunjukkan adanya data bloat.

  Solusi:

  • Periksa kesalahan kode: Kondisi JOIN yang salah, Produk Kartesius, atau error UDTF.

  • Periksa data bloat akibat agregasi:

    Masalah muncul ketika:

    • Menggunakan `DISTINCT` dengan agregasi pada dimensi yang berbeda.

    • Menggunakan GROUPING SETS, CUBE, atau ROLLUP, atau fungsi seperti COLLECT_LIST dan MEDIAN yang menyimpan data antara.

  • Hindari data bloat akibat join.

    Agregasi tabel dimensi sebelum melakukan join untuk menghindari ekspansi baris.

  • Kelola data bloat akibat Grouping Set. Atur paralelisme secara manual untuk task downstream:

    set odps.stage.reducer.num = xxx;
    set odps.stage.joiner.num = xxx;

Fase akhir

• Eksekusi multi-tahap subquery

  Beberapa subquery (misalnya, SELECT DISTINCT yang digunakan dalam klausa IN) dieksekusi secara terpisah terlebih dahulu.

  SELECT product, sum(price) FROM sales
  WHERE ds in (SELECT DISTINCT ds FROM t_ds_set)
  GROUP BY product;

  Periksa tab Logview. Tab pertama mungkin sudah selesai sementara tab kedua masih berjalan.

• Terlalu banyak file kecil

  File kecil yang berlebihan memengaruhi penyimpanan (tekanan Pangu) dan komputasi (efisiensi rendah).

• Solusi: Periksa apakah ada tab Merge Task terpisah di Logview. Task ini menggabungkan file kecil untuk meningkatkan performa downstream.

  Hindari penggunaan pernyataan SELECT yang menghasilkan banyak file kecil. Gunakan perintah Tunnel sebagai gantinya. Pastikan ambang batas penggabungan file kecil dikonfigurasi dengan benar. Lihat Gabungkan file kecil.

• Pembaruan metadata partisi dinamis

  Gejala: Pembaruan metadata untuk banyak partisi dinamis bisa berjalan lambat. Logview menampilkan SQLTask is updating meta information.

• Ukuran file output meningkat

  Gejala: Ukuran file output jauh lebih besar daripada input, meskipun jumlah record-nya mirip.

  Solusi: Distribusi data memengaruhi kompresi. Pengurutan data meningkatkan kompresi. Pada operasi JOIN, pastikan kolom pengurutan (Join Key) mengelompokkan data yang mirip. Misalnya, ubah:

  on t1.query = t2.query and t1.item_id = t2.item_id

  menjadi:

  on t1.item_id = t2.item_id and t1.query = t2.query

  jika `item_id` memiliki karakteristik pengelompokan yang lebih baik.

  Sebagai alternatif, gunakan pengurutan Z-order atau DISTRIBUTE BY ... SORT BY untuk meningkatkan kompresi, meskipun ini meningkatkan biaya komputasi.