Cara melakukan troubleshooting masalah kualitas data dalam sinkronisasi batch tabel tunggal - DataWorks

Dokumen ini menjelaskan cara kerja sinkronisasi data di Data Integration dan membantu Anda mengevaluasi hasil task, seperti volume data dan jumlah record tujuan. Dokumen ini juga menyajikan skenario umum terkait kualitas data serta memberikan solusi untuk melakukan troubleshooting.

Cara kerja

DataWorks Data Integration menggunakan arsitektur berbasis plugin dan pemrosesan paralel untuk mencapai sinkronisasi data yang efisien dan stabil.

Model eksekusi paralel (job dan task)

Untuk memaksimalkan throughput data, sebuah task sinkronisasi menggunakan struktur eksekusi dua tingkat:

Job: Instans yang sedang berjalan dari sebuah task sinkronisasi.
Task: Unit eksekusi terkecil dari sebuah job. Sebuah job dibagi menjadi beberapa task yang dapat berjalan secara konkuren pada satu atau lebih mesin.

Setiap task bertanggung jawab untuk memproses shard data yang independen. Mekanisme pemrosesan paralel ini secara signifikan meningkatkan efisiensi keseluruhan sinkronisasi data.

Aliran data berbasis plugin (reader dan writer)

Di dalam setiap task, aliran data diatur oleh reader plugin dan writer plugin yang dihubungkan melalui buffer in-memory:

reader plugin: Terhubung ke sumber data, membaca data, lalu mendorongnya ke buffer internal.
writer plugin: Mengonsumsi data dari buffer dan menuliskannya ke penyimpanan data tujuan.

Catatan

Reader plugin dan writer plugin secara ketat mengikuti protokol asli dan batasan masing-masing sumber data, seperti tipe data dan pembatasan primary key. Oleh karena itu, perilaku sinkronisasi akhir dan konsistensi data bergantung pada implementasi sistem sumber dan target.

Lakukan troubleshooting konsistensi data di sisi writer

Writer plugin Data Integration menulis data dari sumber ke tujuan. Setiap jenis sumber data tujuan memiliki writer plugin yang sesuai. Writer plugin mengirimkan data ke tujuan menggunakan JDBC atau SDK sumber data berdasarkan mode tulis yang dikonfigurasi, termasuk strategi penyelesaian konflik.

Catatan

Hasil penulisan aktual dan konten data di tujuan bergantung pada mode tulis dan batasan tabel tujuan.

Jika Anda mengalami masalah kualitas data, seperti jumlah record atau konten data, setelah task sinkronisasi selesai, tinjau masalah umum berikut di sisi writer.

Penyebab	Deskripsi	Solusi
Konfigurasi write mode yang tidak tepat	Writer plugin menulis data sumber ke tujuan menggunakan write mode yang dipilih. Jika data sumber bertentangan dengan batasan tabel tujuan, hal ini dapat menyebabkan gagal insert (dirty data), pengabaian diam-diam, atau penggantian record.	Pilih write mode yang sesuai untuk kasus penggunaan Anda. Untuk informasi selengkapnya, lihat Lampiran: Write modes untuk database relasional.
Ambang batas dirty data tercapai	Jumlah dirty data, yang disebabkan oleh masalah seperti ketidaksesuaian tipe data atau konten yang terlalu besar, melebihi ambang batas yang dikonfigurasi, sehingga menyebabkan task gagal dan mencegah sebagian data ditulis.	Identifikasi penyebab dirty data dan selesaikan masalah tersebut. Atau, tentukan apakah dirty data tersebut dapat ditoleransi dan diabaikan. Catatan Jika task Anda tidak dapat mentoleransi dirty data, Anda dapat mengubah ambang batas dirty data di Task Configuration > Channel Configuration. Untuk informasi selengkapnya tentang cara mengonfigurasi ambang batas dirty data, lihat konfigurasi antarmuka tanpa kode. Untuk informasi selengkapnya tentang apa yang termasuk dirty data, lihat Data Integration.
Menanyakan data terlalu dini	Data ditanyakan sebelum task sinkronisasi selesai. Untuk beberapa sumber data, seperti Hive dan MaxCompute (dapat dikonfigurasi), data mungkin sebagian atau sepenuhnya tidak tersedia hingga task selesai.	Selalu verifikasi data di tabel target setelah Anda memastikan bahwa instans task sinkronisasi telah berhasil dijalankan.
Dependensi node tidak ada	Jika tidak ada dependensi Directed Acyclic Graph (DAG) eksplisit yang dikonfigurasi antara task analisis downstream dan task sinkronisasi upstream, task downstream mungkin dimulai terlalu dini dan membaca data yang belum lengkap.	Di DataStudio, konfigurasikan dependensi parent-child node eksplisit antara task upstream dan downstream. Hindari penggunaan dependensi lemah, seperti `max_pt`.
Beberapa task sinkronisasi menulis ke tabel atau partisi yang sama secara konkuren, sehingga saling mengganggu.	Eksekusi konkuren task sinkronisasi yang tidak aman. Untuk MaxCompute dan Hologres, jika dua task menulis ke partisi yang sama dan dikonfigurasi untuk memotong partisi sebelum menulis, task kedua dapat menghapus data yang ditulis oleh task pertama. Untuk database relasional, jika pernyataan pre-SQL atau post-SQL dikonfigurasi, pernyataan SQL dari task kedua dapat mengganggu data yang ditulis oleh task pertama.	Jika konflik disebabkan oleh beberapa instans periodik dari node yang sama, Anda dapat mengonfigurasi self-dependency untuk memastikan instans berikutnya hanya dimulai setelah instans sebelumnya selesai. Hindari merancang task yang menulis ke tujuan yang sama secara konkuren.
Task tidak dikonfigurasi untuk eksekusi idempoten	Task tidak idempoten, artinya eksekusi berulang menghasilkan hasil yang berbeda. Menjalankan ulang task dapat menyebabkan data duplikat dimasukkan atau data ditimpa secara salah.	1. Jika memungkinkan, rancang task agar bersifat idempoten. Misalnya, gunakan mode `REPLACE INTO`. 2. Jika Anda tidak dapat membuat task idempoten, berhati-hatilah saat menjalankannya kembali dan konfigurasikan alert sukses untuk mencegah retry yang tidak perlu.
Ekspresi partisi salah	Di MaxCompute, sebagian besar tabel data dipartisi, dan nilai partisi sering kali merupakan parameter penjadwalan DataWorks seperti $bizdate. Kesalahan umum meliputi: Parameter penjadwalan tidak diganti dengan benar. Akibatnya, data ditulis ke partisi dengan nama literal seperti ds=$bizdate alih-alih tanggal bisnis aktual, misalnya ds=20230118. Kueri downstream menggunakan ekspresi partisi yang tidak dievaluasi dengan benar, sehingga kueri membaca data dari partisi yang salah.	Periksa ekspresi variabel dalam task sinkronisasi data. Verifikasi bahwa konfigurasi scheduling parameter benar dan bahwa runtime parameters dalam instans task dievaluasi ke nilai yang diharapkan.
Ketidaksesuaian tipe data atau zona waktu	Ketidakkonsistenan tipe data atau pengaturan zona waktu antara sumber dan tujuan dapat menyebabkan data terpotong, dikonversi secara salah, atau menghasilkan perbedaan saat dilakukan perbandingan.	Konfirmasi perbedaan tipe data dan zona waktu antara sumber dan tujuan. Tentukan apakah akan menerima kondisi saat ini atau memodifikasi parameter tipe data dan zona waktu di tujuan.
Data tujuan diubah oleh proses lain	Jika aplikasi lain memodifikasi sumber data tujuan secara konkuren, kontennya mungkin menjadi tidak konsisten dengan data sumber.	Pastikan tidak ada proses lain yang menulis ke tabel tujuan selama jendela sinkronisasi. Jika penulisan konkuren merupakan perilaku yang diharapkan, Anda harus menerima perbedaan data yang dihasilkan.

Lampiran: Write modes untuk database relasional

Jenis protokol	Write mode	Perilaku saat terjadi konflik	Perilaku tanpa konflik	Kapan digunakan
Protokol Umum/MySQL	`insert into`	Insert gagal dan menghasilkan dirty data.	Memasukkan data baru.	Menambahkan data untuk sinkronisasi penuh atau inkremental tanpa menimpa atau memodifikasi record yang sudah ada.
	`replace into`	Mengganti baris lama dengan menghapusnya terlebih dahulu lalu memasukkan baris baru.	Memasukkan data baru.	Menimpa sepenuhnya record lama dengan data terbaru.
	`insert into ... on duplicate key update`	Memperbarui baris lama dengan memperbarui hanya bidang tertentu menggunakan data baru.	Memasukkan data baru.	Memperbarui bidang tertentu dalam record sambil mempertahankan bidang lain, seperti timestamp pembuatan.
	`insert ignore into`	Mengabaikan baris baru tanpa menuliskannya atau menghasilkan error.	Memasukkan data baru.	Hanya memasukkan data yang belum ada dan tidak melakukan tindakan apa pun terhadap record yang sudah ada.
PostgreSQL	`insert on conflict do nothing`	Mengabaikan baris baru tanpa menuliskannya atau menghasilkan error.	Memasukkan data baru.	Hanya memasukkan data yang belum ada dan tidak melakukan tindakan apa pun terhadap record yang sudah ada.
	`insert on conflict do update`	Memperbarui baris lama dengan memperbarui bidang tertentu dalam baris yang bertentangan menggunakan data baru.	Memasukkan data baru.	Memperbarui bidang tertentu dalam record sambil mempertahankan bidang lain, seperti timestamp pembuatan.
	`copy on conflict do nothing`	Membuang baris yang bertentangan. Menggunakan protokol `COPY` berkinerja-tinggi dan mengabaikan data baru saat terjadi konflik tanpa menghasilkan dirty data.	Memasukkan data baru secara massal.	Menambahkan data batch besar secara efisien sambil mengizinkan record duplikat dilewati.
	`copy on conflict do update`	Memperbarui baris yang bertentangan. Menggunakan protokol `COPY` dan menimpa data lama dengan data baru saat terjadi konflik.	Memasukkan data baru secara massal.	Menyinkronkan data batch besar secara efisien, menimpa record lama dengan data terbaru.
-	`merge into`	Tidak didukung.

Lakukan troubleshooting konsistensi data di sisi reader

Reader plugin Data Integration terhubung ke penyimpanan data sumber, mengekstraksi data, lalu mengirimkannya ke writer plugin. Setiap jenis sumber data memiliki reader plugin yang sesuai. Plugin ini menggunakan JDBC atau SDK sumber data untuk mengekstraksi data berdasarkan mode ekstraksi yang dikonfigurasi, yang dapat mencakup filter, tabel, partisi, dan kolom.

Catatan

Hasil pembacaan aktual bergantung pada mekanisme sinkronisasi data, perubahan pada data sumber, dan konfigurasi task.

Jika Anda mengalami masalah kualitas data, seperti jumlah record atau konten data, setelah task sinkronisasi selesai, tinjau masalah umum berikut di sisi reader.

Penyebab	Deskripsi	Solusi
Perubahan konkuren pada data sumber	Aplikasi eksternal mungkin masih memodifikasi data sumber selama operasi pembacaan. Oleh karena itu, task sinkronisasi menangkap snapshot data pada saat pembacaan, bukan kondisi data terbaru mutlak. Untuk mengaktifkan pembacaan paralel, sebuah job sinkronisasi dibagi menjadi beberapa task yang mengeluarkan kueri database independen. Karena isolasi transaksi database, setiap task mengambil snapshot data dari titik waktu yang berbeda. Akibatnya, job tidak dapat menangkap perubahan data yang terjadi setelah semua task-nya dimulai.	Terima perilaku ini sebagai hasil yang diharapkan dari sinkronisasi data ber-throughput tinggi. Menjalankan ulang task mungkin menghasilkan hasil yang berbeda karena perubahan real-time pada data sumber.
Kondisi filter salah	Untuk MySQL, Anda dapat mengonfigurasi klausa `WHERE` untuk memfilter data yang diekstraksi. Jika klausa tersebut berisi parameter penjadwalan, seperti pada `gmt_modify >= ${bizdate}`, kesalahan umum adalah penggantian parameter yang salah. Misalnya, task mungkin hanya memfilter data satu hari padahal dua hari diperlukan. Untuk MaxCompute, saat membaca data dari tabel partisi, ekspresi variabel sering dikonfigurasi untuk parameter partisi, seperti `pt=${bizdate}`. Parameter ini mudah dikonfigurasi salah atau gagal diganti.	Periksa ekspresi variabel penjadwalan dalam task sinkronisasi data. Verifikasi bahwa konfigurasi scheduling parameter benar dan bahwa nilai parameter diganti sesuai harapan saat runtime.
Dirty data di sisi reader	Terjadi kegagalan parsing saat membaca data sumber. Hal ini jarang terjadi pada database terstruktur tetapi dapat terjadi pada sumber data semi-terstruktur, seperti file CSV atau JSON di OSS. Kesalahan format dapat menyebabkan beberapa record dilewati.	Periksa log eksekusi task untuk error parsing atau exception format, lalu perbaiki file data sumber. Atur konfigurasi toleransi dirty data.

Lakukan troubleshooting masalah lingkungan

Penyebab	Solusi
Menanyakan sumber data, tabel, atau partisi yang salah	Di ruang kerja DataWorks dalam mode standar, isolasi lingkungan pengembangan dan produksi diberlakukan. Task sinkronisasi batch tabel tunggal menggunakan sumber data pengembangan di lingkungan pengembangan dan sumber data produksi di lingkungan produksi. Saat membandingkan jumlah dan konten data, pastikan lingkungan sumber data yang Anda tanyakan untuk menghindari perbedaan. Di produksi, sumber data online sering memiliki lingkungan staging atau testing yang sesuai. Database yang digunakan oleh task sinkronisasi mungkin berbeda dari database staging atau testing. Saat memverifikasi data, periksa perbedaan lingkungan ini. Saat menyinkronkan data semi-terstruktur, sering kali melibatkan beberapa file. Pastikan Anda membaca dari dan menulis ke seluruh set file yang lengkap.
Dependensi upstream tidak terpenuhi	Jika data dihasilkan secara periodik, seperti oleh task sinkronisasi data berulang atau task merge, pastikan task upstream yang menghasilkan data tersebut telah dijalankan dan selesai dengan sukses.

Catatan

Sebagai langkah troubleshooting umum, Anda dapat menjalankan task beberapa kali untuk mengamati dan membandingkan hasil sinkronisasi. Anda juga dapat mencoba mengganti sumber data atau tujuan untuk pengujian komparatif. Pengujian ini dapat membantu mempersempit masalah.