DataWorks:FAQ pengisian ulang data

Cara kerja pengisian ulang data

Mengapa paralelisme gagal untuk node per jam dan per menit

• Gejala

  Untuk node yang dijadwalkan per jam atau per menit, instans tidak berjalan secara paralel meskipun Anda mengaktifkan paralelisme untuk pengisian ulang data.

• Penyebab

  Pengaturan paralelisme untuk pengisian ulang data menentukan apakah instans untuk rentang waktu data tertentu—dengan granularitas harian—berjalan secara konkuren. Pengaturan ini tidak mengontrol konkurensi instans dalam satu hari yang sama untuk node per jam atau per menit. Konkurensi intra-hari untuk node tersebut bergantung pada apakah dependensi internal (self-dependency) dikonfigurasi. Untuk informasi lebih lanjut, lihat Skenario 2: Mengonfigurasi dependensi pada siklus sebelumnya.

• Resolusi

  • Jika Anda menonaktifkan paralelisme, instans untuk waktu data yang berbeda berjalan secara serial. Instans untuk waktu data berikutnya baru dimulai setelah instans sebelumnya selesai.

  • Jika Anda mengaktifkan paralelisme, Anda dapat mengatur jumlah instans konkuren (misalnya, 2, 3, 4, atau 5) untuk menjalankan instans pengisian ulang data untuk beberapa waktu data secara paralel.

  Contoh skenario: Misalnya, Anda perlu mengisi ulang data selama satu minggu untuk node per jam atau per menit.

  • Jika node memiliki self-dependency, instans untuk minggu tersebut berjalan secara berurutan sesuai kronologi.

  • Jika node tidak memiliki self-dependency, semua instans untuk setiap hari berjalan secara paralel.

Mengapa instans masuk ke status Pending (Schedule)

• Gejala

  Setelah Anda menentukan waktu data untuk mengisi ulang data, instans tidak berjalan. Instans tetap berada dalam status Pending (Schedule) dan disorot dengan warna kuning.

• Penyebab

  Hal ini terjadi jika waktu eksekusi terjadwal untuk waktu data yang Anda pilih berada di masa depan.

• Resolusi

  Untuk menjalankan instans tersebut segera, pilih opsi Run Retroactive Instances Scheduled to Run after the Current Time di kotak dialog Backfill Data.

  Catatan

  • Jika Anda memilih waktu data yang sesuai dengan waktu eksekusi di masa depan dan tidak mencentang kotak ini, instans akan masuk ke status Pending (Schedule).

  • Jika Anda memilih waktu data yang sesuai dengan waktu eksekusi di masa depan dan mencentang kotak ini, instans akan berjalan segera.

Mengapa pengisian ulang terbaru berada dalam status pending?

• Gejala

  Saat Anda mengisi ulang data untuk waktu data kemarin atau hari ini, instans masuk ke status Pending (Schedule).

• Penyebab

  Penjadwalan platform biasanya mengikuti model T+1, artinya data dengan waktu data kemarin diproses oleh eksekusi yang dijadwalkan hari ini. Saat Anda mengisi ulang data untuk waktu data tertentu, Anda sebenarnya menjalankan ulang instans siklus untuk tanggal tersebut.

  Untuk menemukan instans siklus yang dijadwalkan berjalan hari ini, Anda perlu memfilter berdasarkan waktu data kemarin. Di halaman Cycle Instance pada Operation Center > Cycle Task O&M, atur filter Data Timestamp ke Yesterday untuk melihat instans siklus yang sesuai beserta statusnya.

Mengapa pengisian ulang menghasilkan beberapa instans

• Gejala

  Mengisi ulang data untuk rentang waktu seperti 00:00 hingga 01:00 menghasilkan beberapa instans.

• Penyebab

  Jumlah instans yang dihasilkan bergantung pada konfigurasi penjadwalan node tersebut.

  • Sebagai contoh, jika node per jam dijadwalkan berjalan setiap jam dari 00:00 hingga 23:59, mengisi ulang data untuk rentang waktu 00:00 hingga 01:00 menghasilkan dua instans dengan waktu eksekusi terjadwal pada 00:00 dan 01:00.

  • Demikian pula, jika node dijadwalkan berjalan setiap 30 menit, mengisi ulang data untuk rentang waktu 00:00 hingga 01:00 menghasilkan tiga instans dengan waktu eksekusi terjadwal pada 00:00, 00:30, dan 01:00.

Mengapa pengisian ulang skala besar menunggu sumber daya

• Gejala

  Selama operasi pengisian ulang data skala besar, beberapa instans masuk ke status Pending (Resources) dan disorot dengan warna kuning.

• Penyebab

  Setiap kelompok sumber daya memiliki batas konkurensi maksimum untuk menjalankan node. Jika jumlah node yang berjalan secara konkuren melebihi batas ini, instans baru akan masuk antrian dalam status Pending (Resources).

  Catatan

  Untuk mengatasi masalah ini, lihat Waiting for resources.

Mengapa terjadi kesalahan "run time out of range"?

• Gejala

  Kesalahan dapat terjadi selama pengisian ulang data, yang menyatakan bahwa waktu eksekusi node yang dipicu berada di luar rentang waktu yang dipilih.

• Penyebab

  Kesalahan ini terjadi karena waktu eksekusi terjadwal aktual node berada di luar rentang waktu yang Anda tentukan. Untuk node per jam dan per menit, Anda harus menentukan jendela waktu eksekusi untuk pengisian ulang data. Misalnya, di kotak dialog Backfill Data, jika Anda mengatur Select a run time window menjadi 00:00 ~ 01:00 tetapi node yang dipicu dijadwalkan berjalan pada waktu yang berbeda, operasi pengisian ulang akan gagal. Untuk mengatasinya, sesuaikan jendela waktu eksekusi agar mencakup waktu eksekusi terjadwal node tersebut.

Mengapa tidak ada instans pengisian ulang yang dihasilkan?

• Gejala

  Anda telah memulai operasi pengisian ulang data untuk sebuah node, tetapi tidak ada instans pengisian ulang yang dihasilkan.

• Penyebab

  Instans tidak dihasilkan jika waktu data berada di luar rentang tanggal efektif node tersebut. Pastikan waktu data untuk pengisian ulang berada dalam rentang tanggal efektif node. Di panel scheduling configuration node, Anda dapat melihat pengaturan seperti berikut: Time attribute diatur ke Normal scheduling, Rerun attribute tidak dipilih, Auto rerun on error tidak dipilih, effective date range adalah 1999-09-09 hingga 1999-10-22 (penjadwalan hanya berlaku dalam rentang ini), Suspend scheduling tidak dipilih, scheduling cycle adalah Daily, dan waktu terjadwal adalah 00:19. Jika waktu data untuk pengisian ulang berada di luar effective date range, tidak ada instans pengisian ulang yang dihasilkan.

Mengisi ulang node mingguan dan bulanan

• Deskripsi: Saat mengisi ulang data untuk node mingguan atau bulanan, Anda harus mengatur waktu data ke satu hari sebelum waktu eksekusi terjadwal. Node yang dijadwalkan berjalan pada hari tertentu dalam seminggu atau sebulan hanya dieksekusi pada hari yang ditentukan tersebut. Pada hari lain, instans dry-run dihasilkan, tetapi node tidak benar-benar berjalan. Status instans tersebut menunjukkan siklus dry-run mingguan atau bulanan. Untuk informasi lebih lanjut, lihat Skenario 1: Dry run untuk siklus mingguan/bulanan.

  Catatan

  • Waktu data untuk pengisian ulang dihitung sebagai: waktu data = Tanggal eksekusi terjadwal - 1 hari.

  • Untuk informasi lebih lanjut tentang hubungan antara parameter penjadwalan, waktu data, waktu terjadwal, dan waktu eksekusi aktual, lihat Supported formats for scheduling parameters.

• Contoh: Mengisi ulang data untuk node bulanan

  Untuk node yang dijadwalkan berjalan pada pukul 00:00 di hari pertama setiap bulan, Anda harus mengatur waktu data ke hari terakhir bulan sebelumnya. Untuk node bulanan dengan scheduling cycle diatur ke Monthly dan waktu eksekusinya adalah 00 00 00 1 * ?, atur tanggal mulai dan akhir untuk Data Timestamp di kotak dialog Backfill Data menjadi 2022-11-30 untuk memproses data November 2022, lalu klik OK.

Bagaimana batas instans paralel memengaruhi pengisian ulang

• Saat pengaturan maximum parallel instances diaktifkan untuk sebuah node, batas ini berlaku baik untuk instans pengisian ulang data maupun instans siklus reguler. Keduanya berbagi kuota konkurensi yang sama.

• Saat konkurensi instans melebihi batas, sistem terutama membatasi instans pengisian ulang data historis, yaitu instans untuk waktu data sebelum hari ini.

• Batas maximum parallel instances hanya berlaku untuk instans yang dihasilkan setelah pengaturan diaktifkan. Instans yang sudah berjalan atau dalam antrian tidak terpengaruh.

• Nilai maximum parallel instances dapat berkisar dari 1 hingga 10.000, dengan nilai default 1.

Apa yang harus saya lakukan jika pengisian ulang data paralel melalui OpenAPI melaporkan Can't update ObjectId BeginTs less than lastCommitTs atau "ODPS-0429311 metadata transaction conflict"?

• Penyebab

  Selama pengisian ulang data paralel, tugas untuk waktu data yang berbeda berjalan secara bersamaan dan melibatkan operasi DDL tabel, seperti pernyataan ALTER TABLE konkuren, tabrakan antara penggabungan otomatis dan operasi DDL manual, atau jadwal yang tumpang tindih. Hal ini menyebabkan konflik transaksi metadata MaxCompute atau konflik DDL.

• Resolusi

  Atur parameter Parallelism pada API pengisian ulang data menjadi false sehingga tugas berjalan secara serial dan tidak memodifikasi metadata secara konkuren. Jika konflik hanya terjadi sesekali, mencoba ulang biasanya dapat mengatasinya.

• Informasi tambahan

  Setelah Anda mengatur Parallelism menjadi false, alur kerja pengisian ulang data untuk beberapa waktu data berjalan secara serial ketat: instans untuk waktu data berikutnya baru dimulai setelah semua instans untuk waktu data sebelumnya berhasil. Jika tugas untuk waktu data hulu gagal, instans pengisian ulang data untuk waktu data hilir tetap berada dalam status Not Running (ditampilkan sebagai Creating di versi API sebelumnya). Saat ini, tidak tersedia API untuk menanyakan status tugas secara keseluruhan secara langsung. Anda hanya dapat menanyakan status instans berdasarkan waktu data.

Bagaimana cara mengatasi tugas pengisian ulang data yang berjalan lambat?

• Periksa beban kelompok sumber daya

  Periksa penggunaan kelompok sumber daya. Jika penggunaannya tinggi, kelompok sumber daya telah penuh dan tugas masuk antrian. Kurangi jumlah tugas konkuren atau tingkatkan kapasitas kelompok sumber daya.

• Analisis log pekerjaan MaxCompute (Logview)

  Jika kelompok sumber daya tidak penuh tetapi tugas tetap lambat, peroleh URL Logview dan analisis efisiensi eksekusi SQL. Periksa apakah terjadi pembengkakan data, misalnya operasi JOIN yang output-nya jauh lebih besar daripada input-nya. Gunakan informasi Input untuk menemukan node SQL spesifik dan tabel yang terlibat, seperti tabel dimensi yang digabungkan dengan tabel fakta di mana distribusi nilai kunci gabungan yang tidak merata menyebabkan Produk Kartesius. Rujuk dokumentasi resmi MaxCompute untuk optimasi SQL.

Bagaimana cara mengatasi ketidaksesuaian antara hasil pengisian ulang data dan hasil menjalankan pernyataan SQL secara lokal?

• Periksa konsistensi lingkungan

  Periksa apakah sumber data yang terhubung ke lingkungan produksi Anda di DataWorks persis sama dengan yang Anda hubungkan secara lokal. Bedakan antara database uji dan database produksi.

• Periksa nilai partisi

  Konfirmasi bahwa nilai partisi yang digunakan dalam tugas pengisian ulang data (misalnya, ds='20260212') sesuai dengan nilai partisi yang digunakan dalam kueri lokal. Periksa logika yang menetapkan bidang partisi dan format waktu data dalam pernyataan SQL.

• Samakan konfigurasi zona waktu

  Tambahkan SET odps.sql.timezone = <zona waktu>; (misalnya, SET odps.sql.timezone = America/Cancun;) di awal kueri lokal untuk memastikan bidang waktu diurai dengan cara yang sama seperti dalam tugas pengisian ulang data. Hal ini menghindari perbedaan perhitungan pada fungsi seperti TO_CHAR dan DATEADD.

• Reproduksi logika SQL lengkap

  Jalankan pernyataan SQL lengkap dari log eksekusi DataWorks secara lokal, termasuk semua logika JOIN dan CASE serta parameter SET, bukan hanya menghitung jumlah baris di tabel tujuan.

• Verifikasi di konsol

  Jalankan pernyataan SQL yang sama langsung di konsol DataWorks untuk menghilangkan gangguan dari lingkungan lokal Anda.