MaxCompute:Kasus diagnosis LogView

Diagnosis job yang gagal berjalan

Jika sebuah job gagal berjalan, Anda dapat melihat informasi error pada tab Result LogView. Tab Result akan ditampilkan secara otomatis saat Anda membuka LogView untuk job yang gagal.

Diagnosis 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 rencana eksekusi.

  Penyebab: Rencana eksekusi kompleks. Pengoptimal memerlukan waktu lama untuk mengoptimalkan rencana eksekusi.

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

• Pembuatan rencana eksekusi

  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 datanya tidak perlu dibaca, dan pecah job besar menjadi job-job kecil. Untuk informasi lebih lanjut tentang cara menentukan apakah partition pruning berlaku dalam pernyataan SQL dan skenario umum di mana partition pruning gagal, lihat Periksa apakah partition pruning efektif.

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

  1. Operasi yang 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 mengeksekusi pernyataan 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

  Deskripsi masalah: Task rerun muncul beberapa kali di tab SubStatusHistory, dan FAILED: ODPS-0110141:Data version exception muncul di tab Result. Dalam kasus ini, job tidak gagal. Sebaliknya, job sedang melakukan replikasi data lintas klaster.

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

  Solusi: Tunggu hingga replikasi data lintas klaster selesai seperti yang diharapkan.

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

  Solusi: Filter partisi yang berisi data lama.

Tahap eksekusi

Rencana eksekusi ditampilkan di tab Job Details LogView. Rencana eksekusi belum lengkap dan job berada dalam status Running. Jika job terjebak pada tahap eksekusi atau memerlukan waktu yang tidak terduga lama untuk diselesaikan pada tahap ini, masalah ini mungkin disebabkan oleh alasan berikut: menunggu sumber daya, data skew, eksekusi UDF yang tidak efisien, dan data bloat. Bagian ini menjelaskan karakteristik masing-masing kasus dan solusinya.

• Menunggu sumber daya

  Gejala: Sebuah instans berada dalam status Ready, atau beberapa instans berada dalam status Running sementara yang lain berada dalam status Ready. Perhatikan bahwa jika sebuah instans berada dalam status Ready tetapi memiliki entri riwayat Debug, hal ini mungkin menunjukkan retry yang dipicu oleh kegagalan instans, bukan menunggu sumber daya. Di daftar instans Fuxi, Anda dapat menggunakan SmartFilter untuk memfilter berdasarkan status. Kolom Status menunjukkan status saat ini dari setiap instans.

  Solusi:

  1. Tentukan apakah status antrian normal. Anda dapat memeriksa posisi job dalam antrian dengan melihat Queue length di LogView. Nilai Queue length tersedia di panel Basic info di sisi kiri LogView. Atau, periksa penggunaan sumber daya grup kuota yang sesuai di Konsol MaxCompute. Di Konsol MaxCompute, pilih Quota management > Resource usage dari menu sisi kiri dan lihat grafik tren metrik seperti CPU resource untuk grup kuota target. Jika penggunaan sumber daya mendekati atau melebihi kuotanya, hal ini menunjukkan bahwa grup kuota kekurangan sumber daya, dan antrian merupakan hal yang diharapkan. Urutan penjadwalan job tidak hanya bergantung pada waktu pengiriman dan prioritasnya, tetapi juga pada apakah sumber daya memori atau CPU yang dibutuhkannya dapat dipenuhi.

  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 menempati banyak sumber daya. Anda dapat menghubungi pemilik job untuk menghentikan job dan melepaskan sumber daya yang ditempati oleh job tersebut.

  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 instans dalam sebuah task telah selesai, tetapi beberapa instans "long-tail" membutuhkan waktu jauh lebih lama untuk selesai. Instans lambat ini mungkin memproses lebih banyak data daripada yang lain. Di SmartFilter, Anda dapat memeriksa jumlah Long-tails dan membandingkan latency instans di kolom Latency.

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

• Eksekusi UDF yang tidak efisien

  Dalam topik ini, UDF mengacu pada berbagai ekstensi yang didefinisikan pengguna, termasuk user-defined scalar functions (UDF), user-defined aggregate functions (UDAF), user-defined table-valued functions (UDTF), user-defined joins (UDJ), dan user-defined types (UDT).

  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.

  Metode troubleshooting: Jika sebuah task gagal, Anda dapat memeriksa DAG di tab Job details di LogView untuk menentukan apakah task tersebut berisi UDF. Di DAG, task yang gagal seperti R4_3 muncul dalam warna merah. Label fx pada node menunjukkan bahasa UDF, seperti ["JAVA"]. Klik ganda R4_3 untuk membuka tampilan operator, yang menunjukkan rantai operator dari atas ke bawah dan mencantumkan semua nama UDF yang digunakan dalam task tersebut. Di log StdOut task, framework UDF mencetak jumlah record input, record output, dan waktu pemrosesan. Anda dapat menggunakan data ini untuk mengidentifikasi masalah performa. Biasanya, Speed(records/s) berada dalam kisaran ratusan ribu hingga jutaan. Jika turun ke puluhan ribu, kemungkinan besar terdapat masalah performa. Log menampilkan ringkasan pemrosesan UDF dan tabel statistik untuk setiap operator (CursorId) dengan metrik seperti OutputCount, InnerTime, dan Speed(records/s).

  Solusi: Jika terjadi masalah performa, Anda dapat menggunakan metode berikut untuk melakukan 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 UDF Java dan UDF Python dalam panduan pengembangan MaxCompute Studio.

  2. Periksa apakah nama UDF sama dengan fungsi bawaan.

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

  3. Gunakan fungsi bawaan untuk menggantikan UDF.

     Jika terdapat 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 pengujian kotak putih 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 diperlukan untuk menjalankan UDF.

     Simulasikan jumlah data yang diproses oleh satu instans di mesin lokal Anda untuk menguji periode waktu yang diperlukan untuk menjalankan UDF. Kemudian, optimalkan implementasi UDF. Secara default, periode waktu maksimum yang diperlukan 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 diperlukan 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 secara manual periode timeout UDF 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 mengurutkan data dalam jumlah 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 dari 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 ditulis ulang
     SELECT * FROM t WHERE pt = udf('foo');  -- pt menunjukkan kolom kunci partisi t.
     -- Pernyataan SQL setelah ditulis ulang
     SELECT * FROM t WHERE pt = (SELECT udf('foo')); --pt menunjukkan kolom kunci partisi t.

• Data bloat

  Gejala: Jumlah data output dari sebuah task jauh lebih besar daripada jumlah data input. Misalnya, jika 1 GB data diproses dan menjadi 1 TB, performa akan berkurang secara signifikan saat satu instans memproses 1 TB data tersebut. Setelah job selesai, Anda dapat melihat volume data input dan output di I/O Records task tersebut. Jika job terjebak di tahap Join, Anda dapat memeriksa log StdOut beberapa instans Fuxi yang berada dalam status Running. Di SmartFilter, filter instans dalam status Running, lalu klik ikon StdOut sebuah instans untuk melihat log-nya. Jika log StdOut terus-menerus menunjukkan log Merge Join, hal ini menunjukkan bahwa satu worker terus-menerus melakukan Merge Join. Jika jumlah baris output dari Merge Join melebihi 143,3 miliar, hal ini menunjukkan inflasi data yang parah, dan Anda perlu memeriksa apakah kondisi JOIN dan Join Key sesuai. Log akan terus-menerus mengeluarkan catatan Merge join cursor, dan nilai bidang OutputRowCount akan terus meningkat. Anda dapat menggunakan hal ini untuk menentukan tingkat inflasi data.

  Solusi:

  • Periksa masalah berikut dalam kode: apakah kondisi JOIN benar, apakah kondisi JOIN ditulis sebagai Produk Kartesius, 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. Jumlah data hasil antara tidak besar dan kompleksitas komputasi sebagian besar aggregator rendah. Agregasi dapat diselesaikan dengan cepat meskipun jumlah datanya besar. Dalam kebanyakan kasus, data bloat tidak terjadi selama agregasi. Namun, jika Anda melakukan agregasi dalam skenario berikut, data bloat mungkin terjadi:

    • Mengaktifkan agregasi dalam pernyataan SELECT untuk melakukan operasi DISTINCT dalam dimensi yang 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 aslinya. 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 sejumlah besar data populasi. Namun, efisiensi pemrosesan tinggi karena paralelisme tinggi instans MaxCompute. Tabel kanan adalah tabel dimensi yang mencatat informasi tentang setiap jenis kelamin, seperti kebiasaan buruk yang mungkin dimiliki setiap 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 dijalankan terlebih dahulu. Hasilnya diperlukan untuk partition pruning guna mengoptimalkan jumlah partisi yang dibaca oleh kueri utama. Kedua eksekusi ini merupakan job Fuxi terpisah. LogView menampilkan setiap job Fuxi 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 tab untuk melihat status eksekusi job_1. Setelah beralih, Anda dapat melihat status saat ini dari setiap task di job_1, seperti Running atau Waiting.

• File kecil berlebihan

  File kecil berlebihan terutama memengaruhi performa penyimpanan dan performa komputasi.

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

  • Komputasi: Performa pemrosesan secara 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 menggunakan LogView untuk memeriksa apakah job telah memicu penggabungan otomatis file kecil. Mirip dengan eksekusi multi-tahap subkueri, job Merge juga ditampilkan sebagai tab terpisah. Meskipun MergeTask tambahan untuk penggabungan otomatis file kecil meningkatkan waktu eksekusi keseluruhan job, hal ini mengoptimalkan jumlah dan ukuran file yang dihasilkan di tabel hasil setelah penggabungan. Dengan demikian, tekanan berlebihan pada sistem file dapat dihindari dan performa baca ditingkatkan saat tabel digunakan oleh job berikutnya. Nama tab job Merge biasanya berupa SQL_0_0_0_merge, yang menampilkan kemajuan eksekusi MergeTask.

  Jika terdapat terlalu banyak file kecil, pernyataan SELECT mungkin memerlukan waktu lama untuk dieksekusi saat job berada di tahap terminasi. Hal ini terjadi karena sistem perlu membuka banyak file kecil untuk membaca data saat menghasilkan dan menampilkan hasil eksekusi pernyataan SELECT—proses yang cukup memakan waktu. Untuk menghindari pembuatan terlalu banyak file hasil eksekusi, sebaiknya hindari penggunaan pernyataan SELECT dan gunakan perintah Tunnel untuk mengunduh data. Jika volume data hasil eksekusi tidak besar tetapi jumlah file sangat banyak, pastikan parameter odps.merge.smallfile.filesize.threshold telah dikonfigurasi dengan benar. Untuk informasi lebih lanjut tentang cara menggabungkan file kecil, lihat Gabungkan file kecil.

• Pembaruan metadata di partisi dinamis

  Deskripsi masalah: Setelah job Fuxi selesai, Anda mungkin perlu melakukan operasi tertentu yang berkaitan dengan metadata. Misalnya, jika Anda ingin memindahkan data hasil ke direktori tertentu dan memperbarui metadata tabel, sejumlah besar partisi mungkin dihasilkan di tabel selama partisi dinamis. Akibatnya, proses ini memakan waktu. 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 terjebak di SQLTask is updating meta information. Kode status yang sesuai adalah 1260, dan nilai Latency-nya menunjukkan berapa lama pembaruan metadata berlangsung.

• Peningkatan ukuran file output

  Gejala: Jumlah record input dan output mirip, tetapi ukuran output beberapa kali lebih besar. Di Fuxi Jobs, periksa kolom IO bytes untuk membandingkan ukuran data Input dan Output untuk setiap task. Hal ini membantu mengidentifikasi tahap di mana inflasi ukuran terjadi.

  Solusi: Salah satu alasannya adalah perubahan distribusi data. Saat menulis data ke tabel, data dikompresi. Algoritma kompresi paling efektif pada data yang berulang. Oleh karena itu, jika data identik disusun bersama selama proses penulisan, rasio kompresi tinggi dapat dicapai. Distribusi data bergantung pada cara data di-shuffle dan diurutkan selama tahap penulisan (tahap R12 di Fuxi Jobs). Dalam contoh ini, operasi SQL terakhir adalah JOIN, dengan kunci JOIN:

  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 join. Setelah modifikasi, ukuran data berkurang menjadi sepertiga dari ukuran data aslinya.

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

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

  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.