MaxCompute:Kasus diagnostik LogView

Mendiagnosis job yang gagal berjalan

Saat sebuah job gagal, Anda dapat melihat informasi error pada tab result di LogView. Secara default, LogView membuka tab result untuk job yang gagal.

Mendiagnosis job yang berjalan lambat

Tahap kompilasi

• Penjadwalan

  Deskripsi masalah: Sub-status job adalah Waiting for cluster resource. Job sedang menunggu untuk dikompilasi.

  Penyebab: Sumber daya klaster komputasi tidak mencukupi.

  Solusi: Periksa status klaster komputasi dan sumber daya yang dibutuhkan oleh klaster komputasi. Jika Anda menggunakan subscription cluster, Anda dapat melakukan scale out sumber daya.

• Optimasi

  Deskripsi masalah: Sub-status job adalah SQLTask is optimizing query. Pengoptimal sedang mengoptimalkan execution plan.

  Penyebab: Execution plan kompleks. Pengoptimal memerlukan waktu lama untuk mengoptimalkan execution plan.

  Solusi: Tunggu hingga pengoptimal menyelesaikan proses optimasi. Proses ini biasanya memakan waktu kurang dari 10 menit.

• Pembuatan execution plan

  Deskripsi masalah: Sub-status job adalah SQLTask is generating execution plan.

  Penyebab 1: Data dari jumlah partisi yang berlebihan dibaca.

  Solusi: Optimalkan pernyataan SQL untuk mengurangi jumlah partisi. Misalnya, lakukan partition pruning, filter partisi yang tidak perlu dibaca datanya, dan pecah job besar menjadi job kecil. Untuk informasi lebih lanjut tentang cara menentukan apakah partition pruning berjalan efektif dalam pernyataan SQL dan skenario umum kegagalan partition pruning, lihat Periksa apakah partition pruning efektif.

  Penyebab 2: File kecil berlebihan dihasilkan. File kecil dihasilkan dalam skenario berikut:

  1. Operasi salah dilakukan saat menggunakan perintah Tunnel untuk mengunggah data. Misalnya, upload session baru dibuat setiap kali satu record data diunggah. Untuk informasi lebih lanjut, lihat FAQ tentang perintah Tunnel.

  2. Saat Anda menjalankan operasi insert into pada tabel partisi, file baru dihasilkan di direktori partition.

  Solusi

  1. Gunakan antarmuka TunnelBufferedWriter untuk mengunggah data dengan cara yang lebih efisien. Hal ini mencegah terbentuknya file kecil berlebihan.

  2. Gabungkan file kecil secara manual. Untuk informasi lebih lanjut, lihat Gabungkan file kecil.

  Catatan

  Jika jumlah file kecil lebih dari 10.000, Anda dapat mengaktifkan penggabungan otomatis file kecil. Sistem akan secara otomatis menggabungkan file kecil setiap hari. Namun, jika sistem gagal menggabungkan file kecil dalam skenario khusus, Anda harus menggabungkan file kecil tersebut secara manual.

• Replikasi data lintas klaster

  Gejala: Daftar sub-status menunjukkan beberapa instance Task rerun, dan tab Result menampilkan pesan error FAILED: ODPS-0110141:Data version exception. Job tampaknya gagal tetapi sebenarnya masih berjalan, yang menunjukkan bahwa job sedang mereplikasi data lintas klaster.

  Penyebab 1: Data dimigrasikan antar klaster untuk proyek tersebut. Dalam kasus ini, sejumlah besar job yang mereplikasi data lintas klaster berjalan dalam satu atau dua hari pertama setelah migrasi selesai.

  Solusi: Tunggu hingga replikasi data lintas klaster selesai sesuai harapan.

  Penyebab 2: Data dimigrasikan antar klaster untuk proyek tersebut. Namun, partisi tidak difilter sesuai harapan. Akibatnya, data lama dibaca dari partisi tertentu.

  Solusi: Filter partisi yang berisi data lama.

Tahap eksekusi

Halaman job details di LogView menampilkan execution plan yang belum lengkap, dan status job masih Running. Selama tahap eksekusi, job mungkin tersangkut atau berjalan lebih lama dari yang diharapkan karena antrian sumber daya, data skew, eksekusi UDF yang tidak efisien, atau data bloat. Bagian berikut menjelaskan gejala dan solusi untuk setiap skenario.

• Menunggu sumber daya

  Gejala: Instance berada dalam status Ready, atau sebagian Running sementara yang lain Ready. Perhatikan bahwa jika sebuah instance berstatus Ready tetapi memiliki riwayat Debug, kemungkinan instance tersebut sedang mencoba ulang setelah kegagalan, bukan menunggu sumber daya. Di daftar instance Fuxi, Anda dapat memfilter berdasarkan status menggunakan SmartFilter. Kolom Status menunjukkan status saat ini dari setiap instance.

  Solusi:

  1. Tentukan apakah antrian normal. Anda dapat memeriksa posisi job dalam antrian dengan melihat Queue Length di panel Basic Info di sisi kiri LogView. Atau, periksa penggunaan sumber daya grup kuota yang sesuai di Konsol MaxCompute. Di panel navigasi sisi kiri Konsol MaxCompute, pilih Project Management > Quota Management > Resource Consumption untuk melihat grafik tren metrik seperti CPU Resource untuk grup kuota target. Jika penggunaan sumber daya mendekati atau melebihi kuotanya, grup kuota mengalami kekurangan sumber daya, dan antrian job merupakan hal normal. Urutan penjadwalan bergantung tidak hanya pada waktu pengiriman dan prioritas, tetapi juga pada ketersediaan sumber daya memori atau CPU yang dibutuhkan.

  2. Lihat job yang menggunakan grup kuota tersebut.

     Job besar dengan prioritas rendah mungkin telah dikirim, atau beberapa job kecil dikirim sekaligus. Job-job tersebut menduduki banyak sumber daya. Anda dapat menghubungi pemilik job untuk menghentikan job dan melepaskan sumber daya yang diduduki.

  3. Ubah grup kuota job ke grup kuota proyek lain.

  4. Lakukan scale out sumber daya. Solusi ini hanya cocok untuk pengguna yang menggunakan sumber daya subscription.

• Data skew

  Gejala: Sebagian besar instance dalam sebuah task telah selesai, tetapi beberapa instance "long-tail" masih berjalan. Instance-instance ini berjalan lambat, kemungkinan karena memproses volume data yang lebih besar. Di SmartFilter, Anda dapat memeriksa jumlah Long-Tails dan membandingkan durasi setiap instance di kolom Latency.

  Solusi: Untuk informasi lebih lanjut tentang penyebab umum data skew dan metode optimasi terkait, lihat Penyetelan data skew.

• Eksekusi UDF tidak efisien

  Dalam topik ini, UDF mengacu pada berbagai ekstensi yang didefinisikan pengguna, termasuk user-defined scalar functions (UDFs), user-defined aggregate functions (UDAFs), user-defined table-valued functions (UDTFs), user-defined joins (UDJs), dan user-defined types (UDTs).

  Deskripsi: Efisiensi eksekusi sebuah task rendah, dan task tersebut mencakup UDF. Pesan error berikut yang menunjukkan timeout eksekusi UDF mungkin muncul: Fuxi job failed - WorkerRestart errCode:252,errMsg:kInstanceMonitorTimeout, usually caused by bad udf performance.

  Troubleshooting: Saat sebuah task gagal, Anda dapat dengan cepat menentukan apakah task tersebut berisi UDF dengan memeriksa DAG di tab job details di LogView. Di DAG, task yang gagal berwarna merah, dan label fx seperti ["JAVA"] pada node menunjukkan bahasa UDF. Misalnya, Anda mungkin melihat bahwa task yang gagal R4_3 berisi UDF yang ditulis dalam Java. Klik ganda R4_3 untuk membuka tampilan Operator, yang mencantumkan semua UDF dalam task tersebut. Tampilan Operator menampilkan rantai operator dari atas ke bawah, dengan daftar semua UDF yang dirujuk di bagian bawah. Selain itu, log StdOut untuk task tersebut menunjukkan jumlah record input UDF, jumlah record output, dan waktu pemrosesan. Data ini membantu Anda mengidentifikasi masalah performa. Biasanya, Speed(records/s) ratusan ribu atau jutaan merupakan hal normal. Jika turun ke puluhan ribu, kemungkinan besar terjadi masalah performa. Log menampilkan ringkasan pemrosesan UDF dan tabel statistik dengan OutputCount, InnerTime, dan Speed(records/s) untuk setiap operator (CursorId).

  Solusi: Jika terjadi masalah performa, Anda dapat menggunakan metode berikut untuk troubleshooting dan mengoptimalkan performa.

  1. Periksa apakah terjadi error pada UDF.

     Dalam kasus tertentu, masalah performa disebabkan oleh nilai data tertentu. Misalnya, loop tak hingga terjadi ketika nilai tertentu muncul. MaxCompute Studio memungkinkan Anda mengunduh data sampel spesifik dari sebuah tabel dan menggunakan data tersebut di mesin lokal untuk troubleshooting. Untuk informasi lebih lanjut, lihat Java UDFs dan Python UDF dalam panduan pengembangan MaxCompute Studio.

  2. Periksa apakah nama UDF sama dengan fungsi bawaan.

     Fungsi bawaan mungkin ditimpa oleh UDF yang memiliki nama sama. Jika suatu fungsi tampak seperti fungsi bawaan, Anda harus memastikan apakah UDF dengan nama yang sama dapat menimpa fungsi bawaan tersebut.

  3. Gunakan fungsi bawaan untuk menggantikan UDF.

     Jika tersedia fungsi bawaan yang menyediakan fitur serupa, kami menyarankan agar Anda tidak menggunakan UDF. Fungsi bawaan telah diverifikasi dan digunakan dengan cara yang lebih efisien. Selain itu, pengoptimal melakukan white-box testing pada fungsi bawaan. Oleh karena itu, lebih banyak optimasi dapat dilakukan. Untuk informasi lebih lanjut tentang penggunaan fungsi bawaan, lihat Fungsi bawaan.

  4. Ganti UDF tertentu dengan fungsi bawaan yang menyediakan fitur serupa, dan pertahankan hanya UDF yang tidak dapat diimplementasikan menggunakan fungsi bawaan.

  5. Optimalkan metode evaluate UDF.

     Gunakan metode evaluate hanya untuk operasi yang berkaitan dengan parameter. Lakukan operasi inisialisasi atau perhitungan berulang di awal karena metode evaluate dijalankan berulang kali.

  6. Perkirakan periode waktu yang dibutuhkan untuk menjalankan UDF.

     Simulasikan jumlah data yang diproses oleh satu instance di mesin lokal Anda untuk menguji periode waktu yang dibutuhkan untuk menjalankan UDF. Kemudian, optimalkan implementasi UDF. Secara default, periode waktu maksimum yang dibutuhkan untuk menjalankan UDF adalah 30 menit. UDF harus mengembalikan data dalam waktu 30 menit atau menggunakan context.progress() untuk melaporkan heartbeat. Jika perkiraan periode waktu yang dibutuhkan untuk menjalankan UDF lebih dari 30 menit, Anda dapat mengonfigurasi parameter untuk menentukan periode timeout UDF.

     Nilai default: 1800. Satuan: detik. Nilai valid: 1 hingga 3600.
     -- Tentukan periode timeout UDF. Satuan: detik. Nilai default: 600.
     -- Anda dapat menyesuaikan periode timeout UDF secara manual dalam rentang [0,3600].

  7. Modifikasi parameter memori.

     Rendahnya efisiensi UDF tidak selalu disebabkan oleh kompleksitas komputasi. Kompleksitas penyimpanan juga dapat memengaruhi efisiensi UDF. Contoh:

     • Terjadi overflow memori jika UDF melakukan komputasi memori atau pengurutan pada volume data yang besar.

     • Memori tidak mencukupi menyebabkan frekuensi garbage collection (GC) tinggi.

     Anda dapat memodifikasi parameter memori untuk menangani sementara masalah di atas. Optimasi spesifik harus dilakukan berdasarkan kebutuhan bisnis Anda. Contoh:

     set odps.sql.udf.jvm.memory=
     -- Tentukan ukuran memori maksimum yang dapat digunakan untuk heap JVM UDF. Nilai default: 1024. Satuan: MB.
     -- Anda dapat mengubah nilai parameter odps.sql.udf.jvm.memory dalam rentang [256,12288].

     Catatan

     Jika UDF digunakan, partition pruning mungkin menjadi tidak valid. Anotasi UdfProperty didukung mulai MaxCompute V2.0. Saat Anda mendefinisikan UDF, Anda dapat menggunakan anotasi tersebut agar kompiler menentukan bahwa UDF bersifat deterministik. Contoh kode:

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

     Jika Anda menulis ulang pernyataan SQL untuk UDF, Anda dapat menggunakan UDF dalam filtering partisi.

     -- Pernyataan SQL sebelum penulisan ulang
     SELECT * FROM t WHERE pt = udf('foo');  -- pt menunjukkan kolom kunci partisi t.
     -- Pernyataan SQL setelah penulisan ulang
     SELECT * FROM t WHERE pt = (SELECT udf('foo')); --pt menunjukkan kolom kunci partisi t.

• Data bloat

  Gejala: Data output sebuah task jauh lebih besar daripada data inputnya. Misalnya, jika data 1 GB menjadi 1 TB setelah diproses, performa instance yang menangani data 1 TB akan sangat menurun. Setelah job selesai, I/O Records task tersebut menunjukkan volume data input dan output. Jika job tersangkut di tahap Join, pilih beberapa instance Running menggunakan SmartFilter dan periksa log StdOut mereka dengan mengklik ikon StdOut. Jika log StdOut terus-menerus menunjukkan catatan Merge join cursor dan nilai OutputRowCount terus meningkat, hal ini menunjukkan data bloat parah. Anda perlu memeriksa apakah kondisi JOIN dan kunci gabungan (join key) masuk akal.

  Solusi:

  • Periksa masalah berikut dalam kode: apakah kondisi JOIN benar, apakah kondisi JOIN ditulis sebagai Cartesian product, apakah UDTF normal, dan apakah data output berlebihan dihasilkan.

  • Periksa apakah data bloat disebabkan oleh agregasi.

    Sebagian besar aggregator melakukan agregasi rekursif. Saat aggregator mengagregasi data, aggregator terlebih dahulu menggabungkan hasil antara. Volume data hasil antara tidak besar dan kompleksitas komputasi sebagian besar aggregator rendah. Agregasi dapat diselesaikan dengan cepat meskipun volumenya besar. Dalam kebanyakan kasus, data bloat tidak terjadi selama agregasi. Namun, jika Anda melakukan agregasi dalam skenario berikut, data bloat mungkin terjadi:

    • Aktifkan agregasi dalam pernyataan SELECT untuk melakukan operasi DISTINCT dalam dimensi berbeda. Data mengembang setiap kali operasi DISTINCT dilakukan.

    • Jika Anda menggunakan pernyataan GROUPING SETS atau CUBE | ROLLUP, ukuran data hasil antara mungkin meningkat beberapa kali lipat dibandingkan ukuran data asli. Namun, jika Anda menggunakan pernyataan tertentu seperti COLLECT_LIST atau MEDIAN, Anda harus menyimpan semua data hasil antara. Hal ini mungkin menyebabkan masalah tertentu.

  • Cegah data bloat yang terjadi akibat operasi JOIN.

    Misalnya, Anda ingin menggabungkan dua tabel. Tabel kiri berisi volume data populasi yang besar. Namun, efisiensi pemrosesan tinggi karena paralelisme tinggi instans MaxCompute. Tabel kanan adalah tabel dimensi yang mencatat informasi tentang setiap jenis kelamin, seperti kebiasaan buruk masing-masing jenis kelamin. Tabel dimensi hanya berisi dua jenis kelamin tetapi terdapat ratusan baris yang sesuai dengan setiap jenis kelamin. Jika Anda menggabungkan tabel berdasarkan jenis kelamin, data di tabel kiri mungkin mengembang ratusan kali lipat. Untuk mencegah data bloat, Anda dapat mengagregasi baris data di tabel kanan menjadi dua baris data sebelum menggabungkan tabel.

  • Periksa apakah data bloat disebabkan oleh pernyataan GROUPING SET. Saat pernyataan GROUPING SET dieksekusi, data mengembang dan data output meningkat beberapa kali lipat dibandingkan jumlah grup. Rencana eksekusi saat ini tidak dapat beradaptasi dengan pernyataan GROUPING SET atau mengubah tingkat paralelisme task downstream. Anda dapat mengonfigurasi secara manual tingkat paralelisme task downstream. Contoh pernyataan:

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

Tahap terminasi

• Eksekusi subkueri pada beberapa tahap

  Dalam kebanyakan kasus, subkueri SQL MaxCompute dikompilasi ke dalam DAG Fuxi yang sama. Oleh karena itu, semua subkueri dan kueri utama diselesaikan oleh satu job Fuxi. Namun, subkueri khusus tertentu perlu dijalankan secara terpisah sebelum kueri utama. Contoh kode:

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

  Subkueri SELECT DISTINCT ds FROM t_ds_set dieksekusi terlebih dahulu, dan hasilnya diperlukan untuk partition pruning guna mengoptimalkan jumlah partisi yang dibaca oleh kueri utama. Kedua eksekusi ini merupakan job Fuxi terpisah. Di LogView, setiap job Fuxi muncul di tab terpisah, seperti SQL_0_0_0_job_0 dan SQL_0_0_1_job_1. DAG juga menunjukkan dependensi antara beberapa node JOB. Cukup klik tab kedua tab untuk melihat status eksekusi job_1. Setelah beralih, Anda dapat melihat status saat ini (seperti Running atau Waiting) dari setiap task di job_1.

• File kecil berlebihan

  File kecil berlebihan terutama memengaruhi performa penyimpanan dan komputasi.

  • Penyimpanan: File kecil berlebihan meningkatkan beban kerja pada Apsara Distributed File System. Hal ini memengaruhi penggunaan penyimpanan.

  • Komputasi: Performa pemrosesan keseluruhan terpengaruh karena efisiensi pemrosesan MaxCompute pada satu file besar lebih tinggi daripada efisiensi pemrosesan pada beberapa file kecil. Oleh karena itu, saat job SQL selesai, operasi penggabungan file kecil secara otomatis dipicu jika kondisi tertentu terpenuhi. Hal ini membantu mencegah sistem menghasilkan file kecil berlebihan.

• Solusi: Anda dapat memeriksa di LogView apakah job memicu penggabungan otomatis file kecil. Mirip dengan eksekusi subkueri multi-tahap, job penggabungan muncul di tab terpisah. Nama tab job penggabungan mungkin seperti SQL_0_0_0_merge dan menunjukkan progres MergeTask. Meskipun hal ini menambah total waktu eksekusi job, hasilnya adalah jumlah dan ukuran file yang lebih masuk akal di tabel output. Hal ini mencegah tekanan berlebihan pada sistem file dan meningkatkan performa baca untuk job berikutnya yang menggunakan tabel tersebut.

  Jika file kecil berlebihan ada, pernyataan SELECT mungkin dieksekusi dalam waktu lama saat job berada di tahap terminasi. Saat sistem menghasilkan dan menampilkan hasil eksekusi pernyataan SELECT, sistem perlu membuka banyak file kecil untuk membaca data dari file-file tersebut. Proses ini memakan waktu. Untuk mencegah sistem menghasilkan banyak hasil eksekusi, kami menyarankan agar Anda tidak menggunakan pernyataan SELECT. Anda dapat menggunakan perintah Tunnel untuk mengunduh data. Jika jumlah hasil eksekusi tidak besar tetapi jumlah file sangat besar, kami menyarankan agar Anda memeriksa apakah parameter odps.merge.smallfile.filesize.threshold dikonfigurasi dengan tepat. Untuk informasi lebih lanjut tentang cara menggabungkan file kecil, lihat Gabungkan file kecil.

• Pembaruan metadata dalam partisi dinamis

  Deskripsi masalah: Setelah job Fuxi selesai, Anda mungkin perlu melakukan operasi tertentu yang terkait dengan metadata. Misalnya, jika Anda ingin memindahkan data hasil ke direktori tertentu dan memperbarui metadata tabel, sejumlah besar partisi mungkin dihasilkan dalam tabel selama partisi dinamis. Akibatnya, proses ini memakan waktu lama. Misalnya, pernyataan insert into ... values dieksekusi untuk tabel partisi sales untuk menambahkan 2.000 partisi. Contoh pernyataan:

  INSERT INTO TABLE sales partition (ds)(ds, product, price)
  VALUES ('20170101','a',1),('20170102','b',2),('20170103','c',3), ...;

  Setelah job Fuxi selesai, masih diperlukan waktu untuk memperbarui metadata tabel. SubStatusHistory LogView menunjukkan bahwa job tersangkut di SQLTask is updating meta information. Hal ini sesuai dengan kode status 1260, dan Anda dapat memeriksa nilai Latency-nya untuk melihat berapa lama waktu yang dibutuhkan untuk pembaruan metadata.

• Peningkatan ukuran file output

  Gejala: Data mungkin mengembang beberapa kali lipat meskipun jumlah record input dan output serupa. Di kolom IO Bytes Fuxi Jobs, Anda dapat membandingkan ukuran data Input dan Output setiap Task untuk mengidentifikasi tahap di mana ekspansi data terjadi.

  Solusi: Salah satu penyebabnya adalah perubahan distribusi data, yang memengaruhi kompresi. Selama proses penulisan data ke tabel, data dikompresi. Algoritma kompresi mencapai rasio kompresi tertinggi pada data berulang. Oleh karena itu, jika data identik dikelompokkan bersama selama proses penulisan, rasio kompresi tinggi dapat dicapai. Distribusi data sangat bergantung pada cara data di-shuffle dan diurutkan selama tahap penulisan (R12 di Fuxi Jobs). Dalam contoh ini, operasi SQL terakhir adalah JOIN, dengan kunci gabungan berikut:

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

  Karakteristik data menunjukkan bahwa sebagian besar kolom adalah atribut item. Dalam kasus ini, semua kolom untuk item yang memiliki item_id yang sama identik. Oleh karena itu, semua item dalam kueri diurutkan dalam urutan acak. Hal ini menyebabkan rasio kompresi rendah. Contoh kode berikut memberikan contoh cara memodifikasi urutan gabungan. Setelah modifikasi, ukuran data berkurang menjadi sepertiga dari ukuran data asli.

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

  Setelah modifikasi, ukuran data berkurang menjadi sepertiga dari ukuran data asli.

  Dalam kasus lain, operasi shuffle yang dihasilkan oleh JOIN atau GROUP BY tidak berisi kolom pengurutan yang paling sesuai untuk kompresi. Dalam kasus ini, Anda dapat menggunakan klausa ZORDER BY untuk mengurutkan item di mesin lokal Anda. Dengan cara ini, Anda dapat memperoleh rasio kompresi tinggi dengan biaya lebih rendah. Anda juga dapat mengeksekusi pernyataan DISTRIBUTED BY SORT BY untuk mengatur ulang distribusi data secara manual. Metode ini memerlukan waktu lama untuk perhitungan data dan utilisasi CPU tinggi.