Pemecahan Masalah Kualitas Data dalam sinkronisasi offline satu tabel - DataWorks

Topik ini menjelaskan cara kerja sinkronisasi data di Data Integration. Pemahaman terhadap proses ini membantu Anda mengevaluasi hasil tugas sinkronisasi, termasuk jumlah data yang disinkronkan dan jumlah catatan akhir di tujuan. Topik ini juga menguraikan skenario umum terkait Kualitas Data untuk membantu Anda mengidentifikasi dan menyelesaikan masalah tersebut.

Prinsip sinkronisasi

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

Model eksekusi paralel (Job dan Task)

Untuk memaksimalkan throughput data, tugas sinkronisasi menerapkan struktur eksekusi dua tingkat:

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

Setiap Task 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 menghubungkan plugin Reader dan plugin Writer melalui buffer memori:

Plugin Reader: Terhubung ke penyimpanan data sumber, membaca data, dan mendorongnya ke buffer internal.
Plugin Writer: Mengonsumsi data dari buffer dan menuliskannya ke penyimpanan data tujuan.

Catatan

Plugin Reader dan Writer mengikuti protokol baca/tulis asli serta batasan data dari sumber datanya masing-masing. Batasan ini dapat mencakup tipe data dan batasan kunci utama. Hasil sinkronisasi akhir dan perilaku konsistensi data bergantung pada aturan implementasi sumber dan tujuan data.

Pemecahan masalah konsistensi data di sisi writer

Plugin Writer di Data Integration menulis data dari sumber ke tujuan. Setiap jenis sumber data tujuan memiliki plugin Writer yang sesuai. Plugin Writer menggunakan mode tulis yang dikonfigurasi, termasuk kebijakan resolusi konflik, serta memanfaatkan Java Database Connectivity (JDBC) atau kit pengembangan perangkat lunak (SDK) sumber data untuk menulis data ke tujuan.

Catatan

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

Jika Anda mengalami masalah Kualitas Data, seperti perbedaan jumlah catatan atau konten data, setelah tugas sinkronisasi selesai, tinjau skenario umum di sisi writer berikut:

Penyebab	Deskripsi	Solusi
Konfigurasi mode tulis yang tidak tepat	Plugin Writer menulis data sumber ke tujuan berdasarkan mode tulis yang dipilih. Jika terdapat konflik antara data sumber dan skema tabel tujuan karena batasan data, operasi tersebut dapat menghasilkan kegagalan insert (data kotor), insert yang diabaikan, atau insert yang diganti.	Pilih mode tulis yang sesuai dengan kebutuhan bisnis Anda. Untuk informasi selengkapnya, lihat Lampiran: Mode tulis untuk database relasional.
Ambang batas data kotor tercapai	Jumlah data kotor—yang dapat disebabkan oleh ketidakcocokan tipe data atau konten yang terlalu besar—melebihi ambang batas yang dikonfigurasi, sehingga menyebabkan tugas gagal dan sebagian data tidak ditulis ke tujuan.	Identifikasi penyebab data kotor dan selesaikan masalah tersebut. Atau, tingkatkan ambang batas jika Anda dapat mentolerir dan mengabaikan data kotor tersebut. Catatan Jika tugas Anda tidak dapat mentolerir data kotor, ubah ambang batas di Task Configuration > Channel Configuration. Untuk informasi selengkapnya tentang cara mengonfigurasi ambang batas data kotor, lihat Konfigurasi UI tanpa kode. Untuk informasi lebih lanjut mengenai definisi data kotor, lihat Istilah.
Menanyakan data terlalu dini	Anda menanyakan data sebelum tugas sinkronisasi selesai. Untuk beberapa sumber data, seperti Hive dan MaxCompute (dapat dikonfigurasi), data mungkin sebagian atau sepenuhnya tidak terlihat sebelum tugas selesai.	Selalu tanyakan dan verifikasi tabel tujuan setelah memastikan bahwa instans tugas sinkronisasi telah berhasil dijalankan.
Ketergantungan node yang hilang	Ketergantungan tidak dikonfigurasi antara tugas analisis downstream dan tugas sinkronisasi upstream, sehingga tugas downstream dimulai sebelum sinkronisasi data selesai dan membaca data yang tidak lengkap.	Di DataStudio, konfigurasikan ketergantungan parent-child node untuk tugas upstream dan downstream. Hindari penggunaan ketergantungan lemah seperti `max_pt`.
Banyak tugas sinkronisasi menulis ke tabel atau partisi yang sama secara konkuren dan menyebabkan gangguan	Eksekusi konkuren tugas sinkronisasi yang tidak tepat. Di MaxCompute atau Hologres, dua tugas menulis ke partisi data yang sama dan dikonfigurasi untuk memotong partisi sebelum sinkronisasi. Data yang ditulis oleh tugas pertama mungkin dihapus oleh tugas kedua. Untuk database relasional, jika pernyataan pre-SQL atau post-SQL dikonfigurasi, data yang ditulis oleh tugas pertama mungkin terpengaruh oleh pernyataan pre-SQL atau post-SQL dari tugas kedua.	Jika konflik disebabkan oleh banyak instans berulang dari node yang sama, konfigurasikan ketergantungan mandiri untuk node tersebut. Hal ini memastikan bahwa instans berulang berikutnya dimulai hanya setelah yang sebelumnya selesai. Hindari merancang tugas yang menulis ke tujuan yang sama secara konkuren.
Tugas tidak dikonfigurasi untuk eksekusi idempoten	Tugas tidak dirancang agar idempoten, artinya eksekusi berulang menghasilkan hasil yang berbeda. Menjalankan ulang tugas dapat menyebabkan insert duplikat atau overwrite yang salah.	1. Rancang tugas agar idempoten. Misalnya, gunakan mode `REPLACE INTO`. 2. Jika tugas tidak dapat dibuat idempoten, berhati-hatilah saat menjalankannya kembali. Konfigurasikan peringatan sukses untuk menghindari pengulangan yang tidak perlu.
Ekspresi partisi salah	Misalnya, di MaxCompute, sebagian besar tabel data adalah tabel partisi. Nilai partisi merupakan parameter penjadwalan DataWorks seperti $bizdate. Kesalahan umum meliputi: Parameter penjadwalan tidak diganti dengan benar saat waktu proses. Data ditulis ke partisi literal bernama ds=$bizdate alih-alih partisi waktu data aktual, seperti ds=20230118. Kueri downstream menggunakan data, tetapi ekspresi partisinya salah, sehingga mengambil data dari partisi yang tidak sesuai.	Periksa ekspresi variabel dalam tugas sinkronisasi data. Pastikan konfigurasi parameter penjadwalan benar. Selain itu, verifikasi apakah parameter waktu proses dari instans tugas sesuai.
Ketidakcocokan tipe data atau zona waktu	Tipe data atau pengaturan zona waktu sumber dan tujuan tidak konsisten, yang dapat menyebabkan data terpotong atau dikonversi secara salah selama penulisan, atau menghasilkan perbedaan saat perbandingan data.	Pastikan perbedaan tipe data dan zona waktu antara sumber dan tujuan. Putuskan apakah akan mempertahankan pengaturan saat ini atau mengubah parameter tipe data dan zona waktu tujuan.
Data tujuan telah berubah	Jika aplikasi lain menulis ke sumber data tujuan secara konkuren, kontennya 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: Mode tulis untuk database relasional

Jenis Protokol	Mode tulis	Perilaku (saat terjadi konflik data)	Perilaku (tidak ada konflik data)	Skenario utama
Protokol Umum/MySQL	`insert into`	Gagal dan menghasilkan data kotor.	Menyisipkan data baru secara normal.	Append penuh atau inkremental. Anda tidak ingin menimpa atau memodifikasi data yang sudah ada.
	`replace into`	Mengganti baris lama. Menghapus baris lama, lalu menyisipkan baris baru.	Menyisipkan data baru secara normal.	Skenario yang memerlukan penimpaan lengkap catatan lama dengan data terbaru.
	`insert into ... on duplicate key update`	Memperbarui baris lama. Mempertahankan baris lama dan hanya memperbarui bidang tertentu dengan data baru.	Menyisipkan data baru secara normal.	Skenario yang memerlukan pembaruan beberapa bidang catatan sambil mempertahankan bidang lainnya, seperti waktu pembuatan.
	`insert ignore into`	Mengabaikan baris baru. Tidak menulis atau melaporkan kesalahan.	Menyisipkan data baru secara normal.	Anda hanya ingin menyisipkan data baru dan tidak melakukan tindakan apa pun pada catatan yang sudah ada.
PostgreSQL	`insert on conflict do nothing`	Mengabaikan baris baru. Tidak menulis atau melaporkan kesalahan.	Menyisipkan data baru secara normal.	Anda hanya ingin menyisipkan data baru dan tidak melakukan tindakan apa pun pada catatan yang sudah ada.
	`insert on conflict do update`	Memperbarui baris lama. Menggunakan data baru untuk memperbarui bidang tertentu di baris yang bertentangan.	Menyisipkan data baru secara normal.	Memperbarui beberapa bidang catatan sambil mempertahankan bidang lainnya, seperti waktu pembuatan.
	`copy on conflict do nothing`	Membuang baris yang bertentangan. Menggunakan protokol `COPY` berkinerja-tinggi. Mengabaikan data baru saat terjadi konflik dan tidak menghasilkan data kotor.	Menyisipkan data baru secara massal secara normal.	Menambahkan data dalam jumlah besar secara efisien, memungkinkan Anda melewati catatan duplikat yang sudah ada.
	`copy on conflict do update`	Memperbarui baris yang bertentangan. Menggunakan protokol `COPY`. Menimpa data lama dengan data baru saat terjadi konflik.	Menyisipkan data baru secara massal secara normal.	Menyinkronkan data dalam jumlah besar secara efisien. Anda perlu menimpa catatan lama sepenuhnya dengan data terbaru.
-	`merge into`	Tidak didukung.

Pemecahan masalah konsistensi data di sisi reader

Plugin Reader di Data Integration terhubung ke penyimpanan data sumber, mengekstraksi data yang akan disinkronkan, dan mengirimkannya ke plugin Writer. Setiap kelas penyimpanan memiliki plugin Reader yang sesuai. Plugin Reader menggunakan mode ekstraksi data yang dikonfigurasi—termasuk kondisi filter, tabel, partisi, dan kolom—serta memanfaatkan JDBC atau SDK sumber data untuk mengekstraksi data.

Catatan

Hasil baca aktual bergantung pada mekanisme sinkronisasi data, perubahan pada data sumber, dan konfigurasi tugas.

Jika Anda mengalami masalah Kualitas Data, seperti perbedaan jumlah catatan atau konten data, setelah tugas sinkronisasi selesai, tinjau skenario umum di sisi reader berikut:

Masalah	Deskripsi	Solusi
Perubahan konkuren pada data sumber	Saat membaca data, aplikasi eksternal mungkin masih memodifikasi data sumber. Tugas sinkronisasi menangkap snapshot data pada saat membaca, bukan data terbaru mutlak. Untuk mencapai pembacaan paralel, Job sinkronisasi dibagi menjadi beberapa Task, yang merupakan kueri database independen. Karena isolasi transaksi database, setiap Task mendapatkan snapshot data dari titik waktu yang berbeda. Artinya, tugas tidak dapat menangkap perubahan data yang terjadi setelah semua Task dimulai.	Terima perilaku ini sebagai hal normal untuk sinkronisasi data ber-throughput tinggi. Menjalankan tugas beberapa kali dapat menghasilkan hasil yang berbeda karena perubahan real-time pada data sumber.
Kondisi kueri salah	Misalnya, di MySQL, Anda dapat mengonfigurasi klausa `WHERE` untuk memfilter data yang diekstraksi. Jika klausa `WHERE` berisi variabel parameter penjadwalan, seperti `gmt_modify >= ${bizdate}`, kesalahan umum adalah parameter penjadwalan tidak diganti dengan benar. Misalnya, Anda mungkin membutuhkan data dari dua hari terakhir tetapi hanya memfilter data satu hari. Misalnya, di MaxCompute, saat membaca tabel partisi, Anda sering mengonfigurasi ekspresi variabel untuk parameter partisi, seperti `pt=${bizdate}`. Parameter partisi juga mudah dikonfigurasi salah atau gagal diganti.	Periksa ekspresi variabel penjadwalan tugas sinkronisasi data. Pastikan konfigurasi parameter penjadwalan sesuai harapan dan parameter diganti dengan nilai yang diharapkan selama penjadwalan.
Data kotor di sisi reader	Penguraian gagal saat membaca data sumber. Hal ini jarang terjadi di database terstruktur. Namun, di sumber data semi-terstruktur seperti file CSV atau JSON di OSS atau Sistem File Terdistribusi Hadoop (HDFS), kesalahan format dapat mencegah sebagian data dibaca.	Periksa log jalannya tugas untuk kesalahan penguraian atau pengecualian format, dan perbaiki file data sumber. Sesuaikan konfigurasi toleransi data kotor.

Pemecahan masalah konteks lingkungan

Masalah	Solusi
Pemilihan sumber data, tabel, atau partisi yang salah untuk kueri	Di ruang kerja DataWorks dalam mode standar, sumber data diisolasi antara lingkungan pengembangan dan produksi. Tugas sinkronisasi satu tabel offline menggunakan sumber data pengembangan saat dijalankan di lingkungan pengembangan. Tugas tersebut menggunakan sumber data produksi saat dijalankan di lingkungan produksi. Saat membandingkan jumlah dan konten data, pastikan lingkungan sumber data yang Anda gunakan untuk menghindari ketidakkonsistenan antara kueri pengembangan dan produksi. Di produksi, online store sering memiliki lingkungan pra-rilis atau pengujian yang sesuai. Database produksi yang digunakan oleh tugas sinkronisasi berbeda dari database pra-rilis atau pengujian. Periksa perbedaan lingkungan saat membandingkan data. Saat menyinkronkan data semi-terstruktur, sering kali melibatkan banyak file. Pastikan koleksi file untuk membaca dan menulis lengkap.
Output dependensi belum siap	Jika data dihasilkan secara berkala, misalnya, oleh tugas sinkronisasi data berulang atau tugas penggabungan data penuh/inkremental berulang, periksa bahwa tugas generasi data dependensi telah dijalankan dan selesai dengan sukses.

Catatan

Untuk pemecahan masalah umum saat mengalami masalah Kualitas Data, Anda dapat menjalankan tugas beberapa kali untuk mengamati dan membandingkan hasil sinkronisasi. Anda juga dapat mengganti sumber data atau tujuan untuk pengujian perbandingan. Menjalankan beberapa pengujian perbandingan dapat membantu mempersempit cakupan masalah.