Sinkronisasi data inkremental dengan checkpoint: menyelaraskan sistem secara aman

Mengapa reimport penuh terus menyebabkan masalah

Reimport penuh terasa aman karena terlihat sederhana: hapus, muat ulang, beres. Pada praktiknya, itu sering menjadi cara mudah untuk membuat sinkron lambat, tagihan membengkak, dan data berantakan.

Masalah pertama adalah waktu dan biaya. Mengambil seluruh dataset setiap kali berarti Anda mengunduh ulang catatan yang sama berkali-kali. Jika Anda menyinkronkan 500.000 pelanggan setiap malam, Anda membayar komputasi, panggilan API, dan penulisan database padahal hanya 200 catatan yang berubah.

Masalah kedua adalah kebenaran data. Reimport penuh sering menimbulkan duplikat (karena aturan pencocokan tidak sempurna), atau menimpa edit yang lebih baru dengan data lama yang kebetulan ada di ekspor. Banyak tim juga melihat total angka bergeser seiring waktu karena "hapus dan muat ulang" gagal diam-diam di tengah proses.

Gejala khasnya terlihat seperti ini:

• Jumlah tidak cocok antara sistem setelah satu run
• Catatan muncul dua kali dengan perbedaan kecil (penulisan huruf email, format telepon)
• Field yang baru saja diperbarui kembali ke nilai lama
• Sinkron kadang “selesai” tetapi melewatkan sebagian data
• Tiket dukungan melonjak setelah setiap jendela impor

Checkpoint hanyalah penanda kecil yang disimpan yang mengatakan bahwa Anda telah memproses hingga titik tertentu. Lain kali, Anda melanjutkan dari penanda itu alih-alih memulai dari awal. Penanda bisa berupa timestamp, ID record, nomor versi, atau token yang dikembalikan oleh API.

Jika tujuan Anda adalah menjaga dua sistem tetap selaras dari waktu ke waktu, sinkronisasi data inkremental dengan checkpoint biasanya adalah target yang lebih baik. Ini sangat berguna ketika data sering berubah, ekspor besar, API punya batas laju, atau Anda perlu agar sinkron bisa dilanjutkan dengan aman setelah crash (misalnya job gagal di tengah pada alat internal yang Anda bangun di platform seperti AppMaster).

Tetapkan tujuan sinkron sebelum memilih metode

Sinkronisasi data inkremental dengan checkpoint hanya bekerja baik jika Anda jelas tentang apa yang dimaksud dengan “benar”. Jika Anda melewatkan langkah ini dan langsung menuju kursor atau hash, biasanya Anda akan membongkar ulang sinkron nanti karena aturannya tidak pernah ditulis.

Mulailah dengan menamai sistem dan memutuskan siapa yang memegang kebenaran. Misalnya, CRM Anda mungkin menjadi sumber kebenaran untuk nama dan nomor telepon pelanggan, sementara tool billing adalah sumber kebenaran untuk status langganan. Jika kedua sistem dapat mengedit field yang sama, Anda tidak punya satu sumber kebenaran, dan harus merencanakan penanganan konflik.

Selanjutnya, definisikan apa arti “selaras”. Apakah Anda membutuhkan kecocokan tepat setiap saat, atau cukup jika pembaruan muncul dalam beberapa menit? Kecocokan tepat biasanya berarti penanganan urutan yang lebih ketat, jaminan checkpoint yang lebih kuat, dan perlakuan hapus yang lebih hati-hati. Konsistensi akhirnya (eventual consistency) biasanya lebih murah dan lebih toleran terhadap kegagalan sementara.

Putuskan arah sinkron. Sinkron satu arah lebih sederhana: Sistem A memberi Sistem B. Sinkron dua arah lebih sulit karena setiap pembaruan bisa menjadi konflik, dan Anda harus menghindari loop tanpa akhir di mana kedua sisi terus saling “memperbaiki”.

Pertanyaan yang harus dijawab sebelum membangun

Tulis aturan sederhana yang disepakati semua pihak:

• Sistem mana yang menjadi sumber kebenaran untuk setiap field (atau tiap tipe objek)?
• Lag yang dapat diterima berapa (detik, menit, jam)?
• Ini satu arah atau dua arah, dan event mana mengalir ke tiap arah?
• Bagaimana penanganan delete (hard delete, soft delete, tombstone)?
• Apa yang terjadi jika kedua sisi mengubah record yang sama?

Set aturan konflik praktis sesederhana “billing menang untuk field langganan, CRM menang untuk field kontak, selain itu yang terbaru menang.” Jika Anda membangun integrasi di alat seperti AppMaster, tangkap aturan ini di Business Process agar tetap terlihat dan dapat diuji, bukan terkubur di memori seseorang.

Kursor, hash, dan token resume: blok bangunan

Sinkronisasi data inkremental dengan checkpoint biasanya bergantung pada salah satu dari tiga “posisi” yang aman untuk disimpan dan digunakan kembali. Pilihan yang tepat tergantung pada apa yang sumber bisa jamin, dan kegagalan apa yang harus Anda tahan.

Checkpoint kursor adalah yang paling sederhana. Anda menyimpan “yang terakhir saya proses” seperti ID terakhir, timestamp last_updated, atau nomor urut. Pada run berikutnya, Anda meminta record setelah titik itu. Ini bekerja baik ketika sumber mengurutkan secara konsisten dan ID atau timestamp bergerak maju dengan andal. Ia akan pecah ketika update datang terlambat, jam berbeda, atau record dapat disisipkan "di masa lalu" (misalnya data backfill).

Hash membantu mendeteksi perubahan ketika kursor saja tidak cukup. Anda bisa meng-hash tiap record (berdasarkan field yang Anda pedulikan) dan hanya sinkron saat hash berubah. Atau Anda bisa meng-hash satu batch untuk cepat mendeteksi drift lalu menelaah lebih detail. Hash per-record akurat tapi butuh penyimpanan dan komputasi lebih. Hash batch lebih murah tapi bisa menyembunyikan item yang berubah.

Resume token adalah nilai opak yang dikeluarkan sumber, sering untuk pagination atau event stream. Anda tidak menginterpretasikannya, Anda hanya menyimpannya dan mengirimkannya kembali untuk melanjutkan. Token bagus ketika API kompleks, tapi bisa kadaluarsa, menjadi invalid setelah jendela retensi, atau berperilaku berbeda antar environment.

Apa yang digunakan, dan apa yang bisa salah

• Kursor: cepat dan sederhana, tapi waspadai update yang keluar urutan.
• Hash per-record: deteksi perubahan presisi, tapi biaya lebih tinggi.
• Hash batch: sinyal drift murah, tapi tidak spesifik.
• Resume token: pagination paling aman, tapi bisa kadaluarsa atau hanya sekali pakai.
• Hybrid (kursor + hash): umum ketika "updated_at" tidak sepenuhnya tepercaya.

Jika Anda membangun sinkron di alat seperti AppMaster, checkpoint ini biasanya tinggal di tabel kecil "sync state", sehingga setiap run bisa dilanjutkan tanpa menebak.

Merancang penyimpanan checkpoint

Penyimpanan checkpoint adalah bagian kecil yang membuat sinkronisasi data inkremental dengan checkpoint dapat diandalkan. Jika sulit dibaca, mudah ditimpa, atau tidak terikat ke job tertentu, sinkron Anda akan terlihat baik sampai gagal sekali, lalu Anda hanya menebak.

Pertama, pilih tempat checkpoint disimpan. Tabel database biasanya paling aman karena mendukung transaksi, audit, dan query sederhana. Key-value store bisa bekerja jika Anda sudah menggunakannya dan mendukung update atomik. File konfigurasi hanya masuk akal untuk sinkron pengguna tunggal dengan risiko rendah, karena sulit dikunci dan mudah hilang.

Apa yang harus disimpan (dan kenapa)

Checkpoint lebih dari sekadar kursor. Simpan konteks yang cukup untuk debugging, resume, dan deteksi drift:

• Identitas job: nama job, tenant atau account id, tipe objek (misalnya customers)
• Progress: nilai kursor atau resume token, plus tipe kursor (time, id, token)
• Sinyal kesehatan: waktu run terakhir, status, jumlah record dibaca dan ditulis
• Keamanan: kursor terakhir yang sukses (bukan hanya terakhir yang dicoba), dan pesan error singkat untuk kegagalan terbaru

Jika Anda menggunakan hash deteksi perubahan, simpan juga versi metode hash. Kalau tidak, Anda bisa mengubah hash nanti dan tidak sengaja memperlakukan semuanya sebagai "berubah."

Versioning dan banyak job sinkron

Saat model data berubah, versioning checkpoint. Cara termudah adalah menambahkan field schema_version dan buat baris baru untuk versi baru, alih-alih memodifikasi data lama. Simpan baris lama untuk sementara supaya bisa rollback.

Untuk banyak job sinkron, beri namespace untuk semuanya. Kunci yang baik adalah (tenant_id, integration_id, object_name, job_version). Itu menghindari bug klasik di mana dua job berbagi satu kursor dan diam-diam melewatkan data.

Contoh konkret: jika Anda membangun sinkron sebagai alat internal di AppMaster, simpan checkpoint di PostgreSQL dengan satu baris per tenant dan objek, dan perbarui hanya setelah commit batch sukses.

Langkah demi langkah: implementasikan loop sinkron inkremental

Sinkronisasi data inkremental dengan checkpoint bekerja terbaik ketika loop Anda membosankan dan dapat diprediksi. Tujuannya sederhana: baca perubahan dalam urutan stabil, tulis dengan aman, lalu gerakkan checkpoint maju hanya ketika Anda tahu penulisan selesai.

Loop sederhana yang dapat dipercaya

Pertama, pilih pengurutan yang tak berubah untuk record yang sama. Timestamp bisa bekerja, tapi hanya jika Anda juga menyertakan tie-breaker (seperti ID) supaya dua update pada waktu yang sama tidak saling menukar posisi.

Lalu jalankan loop seperti ini:

• Tentukan kursor Anda (misalnya: last_updated + id) dan ukuran halaman.
• Ambil halaman berikutnya dari record yang lebih baru daripada checkpoint yang disimpan.
• Upsert setiap record ke target (buat jika belum ada, perbarui jika ada) dan catat kegagalan.
• Commit penulisan yang sukses, lalu simpan checkpoint baru dari record terakhir yang diproses.
• Ulangi. Jika halaman kosong, tidur sebentar, lalu coba lagi.

Pisahkan pembaruan checkpoint dari fetch. Jika Anda menyimpan checkpoint terlalu awal, crash bisa membuat data dilewatkan secara diam-diam.

Backoff dan retry tanpa duplikat

Asumsikan panggilan akan gagal. Saat fetch atau write gagal, retry dengan backoff singkat (misalnya: 1s, 2s, 5s) dan batasi jumlah retry. Buat retry aman dengan menggunakan upsert dan menulis secara idempoten (masukan sama, hasil akhir sama).

Contoh praktis kecil: jika Anda menyinkronkan pembaruan pelanggan setiap menit, Anda mungkin mengambil 200 perubahan per halaman, melakukan upsert, dan hanya lalu menyimpan (updated_at, id) pelanggan terakhir sebagai kursor baru.

Jika Anda membangun ini di AppMaster, Anda bisa memodelkan checkpoint di tabel sederhana (Data Designer) dan menjalankan loop di Business Process yang mengambil, upsert, dan memperbarui checkpoint dalam satu alur terkontrol.

Buat resume aman: idempoten dan checkpoint atomik

Jika sinkron Anda bisa dilanjutkan, itu akan dilanjutkan pada saat terburuk: setelah timeout, crash, atau deploy parsial. Tujuannya sederhana: menjalankan ulang batch yang sama tidak boleh membuat duplikat atau kehilangan update.

Idempoten adalah jaring pengaman. Anda mendapatkannya dengan menulis sedemikian rupa sehingga bisa diulang tanpa mengubah hasil akhir. Dalam praktiknya biasanya berarti upsert, bukan insert: tulis record menggunakan kunci stabil (seperti customer_id), dan perbarui baris yang ada saat sudah ada.

Kunci penulisan yang baik adalah sesuatu yang dapat Anda percaya lintas retry. Opsi umum adalah ID natural dari sistem sumber, atau kunci sintetis yang Anda simpan pertama kali melihat record. Dukung dengan constraint unik sehingga database menegakkan aturan Anda bahkan ketika dua worker berlomba.

Checkpoint atomik sama pentingnya. Jika Anda memajukan checkpoint sebelum data di-commit, crash bisa membuat Anda melewatkan record selamanya. Perlakukan update checkpoint sebagai bagian dari unit kerja yang sama dengan penulisan data Anda.

Berikut pola sederhana untuk sinkronisasi data inkremental dengan checkpoint:

• Baca perubahan sejak checkpoint terakhir (kursor atau token).
• Upsert tiap record menggunakan kunci deduplikasi.
• Commit transaksi.
• Baru kemudian simpan checkpoint baru.

Update yang keluar urutan dan data yang datang terlambat adalah jebakan umum lainnya. Sebuah record bisa diperbarui pada 10:01 tapi tiba setelah record dari 10:02, atau API bisa mengirim perubahan lama saat retry. Lindungi diri Anda dengan menyimpan source last_modified dan menerapkan aturan "last write wins": hanya timpa ketika record masuk lebih baru daripada yang sudah ada.

Jika Anda butuh perlindungan lebih kuat, simpan overlap window kecil (misalnya, baca ulang beberapa menit terakhir) dan andalkan upsert idempoten untuk mengabaikan pengulangan. Ini menambah beban sedikit, tapi membuat resume membosankan—persis yang Anda inginkan.

Di AppMaster, ide yang sama terpetakan jelas ke dalam Business Process: lakukan logika upsert dulu, commit, lalu simpan kursor atau resume token sebagai langkah akhir.

Kesalahan umum yang memecah sinkron inkremental

Sebagian besar bug sinkron bukan soal kode. Mereka berasal dari asumsi yang terasa aman sampai data nyata muncul. Jika Anda ingin sinkronisasi data inkremental dengan checkpoint tetap andal, waspadai jebakan ini sedini mungkin.

Titik kegagalan biasa

Kesalahan umum adalah terlalu percaya pada updated_at. Beberapa sistem menulis ulang timestamp saat backfill, perbaikan zona waktu, edit massal, atau read-repair. Jika kursor Anda hanya timestamp, Anda bisa melewatkan record (timestamp mundur) atau memproses ulang rentang besar (timestamp melompat maju).

Jebakan lain adalah menganggap ID berurutan atau selalu meningkat. Import, sharding, UUID, dan row yang dihapus merusak asumsi itu. Jika Anda menggunakan "last seen ID" sebagai checkpoint, celah dan penulisan keluar urutan bisa meninggalkan record.

Bug paling merusak adalah memajukan checkpoint saat hanya berhasil sebagian. Misalnya, Anda mengambil 1.000 record, menulis 700, lalu crash, tetapi masih menyimpan "next cursor" dari fetch. Saat resume, 300 sisanya tidak pernah dicoba lagi.

Delete juga mudah diabaikan. Sumber bisa soft-delete (flag), hard-delete (baris dihapus), atau "unpublish" (perubahan status). Jika Anda hanya upsert record aktif, target akan perlahan bergeser.

Terakhir, perubahan skema bisa membuat hash lama tidak valid. Jika hash deteksi perubahan dibangun dari sekumpulan field, menambah atau mengganti nama field bisa membuat "tidak berubah" tampak seperti "berubah" (atau sebaliknya) kecuali Anda versioning logika hash.

Berikut default yang lebih aman:

• Prefer kursor monotonik (event ID, posisi log) daripada timestamp mentah bila memungkinkan.
• Perlakukan penulisan checkpoint sebagai bagian dari batas keberhasilan yang sama dengan penulisan data.
• Lacak delete secara eksplisit (tombstone, transisi status, atau rekonsiliasi periodik).
• Versioning input hash Anda dan simpan versi lama yang dapat dibaca.
• Tambahkan overlap window kecil (baca ulang N item terakhir) jika sumber bisa mengubah urutan update.

Jika Anda membangun ini di AppMaster, modelkan checkpoint sebagai tabel terpisah di Data Designer dan gabungkan langkah "tulis data + tulis checkpoint" dalam satu run Business Process, sehingga retry tidak melewatkan pekerjaan.

Monitoring dan deteksi drift tanpa menjadi berisik

Monitoring yang baik untuk sinkronisasi data inkremental dengan checkpoint lebih sedikit tentang "lebih banyak log" dan lebih pada beberapa angka yang bisa Anda percaya di setiap run. Jika Anda bisa menjawab "apa yang kita proses, berapa lama, dan dari mana kita akan melanjutkan?", Anda bisa mendebug sebagian besar masalah dalam beberapa menit.

Mulailah dengan menulis satu catatan run ringkas setiap kali sinkron dijalankan. Jaga konsistensi supaya Anda bisa membandingkan run dan melihat tren.

• Start cursor (atau resume token) dan end cursor
• Record diambil, record ditulis, record dilewati
• Durasi run dan waktu rata-rata per record (atau per halaman)
• Jumlah error dengan alasan error terbanyak
• Status penulisan checkpoint (sukses/gagal)

Deteksi drift adalah lapisan berikutnya: memberi tahu ketika kedua sistem "kedua-duanya bekerja" tetapi perlahan menyimpang. Total saja bisa menyesatkan, jadi gabungkan pengecekan total ringan dengan spot check kecil. Misalnya, sekali sehari bandingkan total pelanggan aktif di kedua sistem, lalu ambil sampel 20 ID pelanggan acak dan konfirmasi beberapa field cocok (status, updated_at, email). Jika total berbeda tapi sampel cocok, mungkin Anda kehilangan deletes atau filter. Jika sampel berbeda, kemungkinan besar hash deteksi perubahan atau mapping field salah.

Alert harus jarang dan dapat ditindaklanjuti. Aturan sederhana: hanya alert ketika manusia harus bertindak sekarang.

• Kursor macet (end cursor tidak bergerak selama N run)
• Tingkat error naik (misalnya, 1% -> 5% dalam satu jam)
• Run menjadi lebih lambat (durasi di atas ambang normal)
• Backlog tumbuh (perubahan baru datang lebih cepat daripada kemampuan sinkron Anda)
• Drift terkonfirmasi (total mismatch dua kali berturut-turut)

Setelah kegagalan, jalankan ulang tanpa pembersihan manual dengan memutar ulang secara aman. Pendekatan termudah adalah melanjutkan dari checkpoint yang terakhir di-commit, bukan dari record terakhir yang "terlihat". Jika Anda menggunakan overlap window kecil (baca ulang halaman terakhir), buat penulisan idempoten: upsert berdasarkan ID stabil, dan hanya majukan checkpoint setelah penulisan berhasil. Di AppMaster, tim sering mengimplementasikan pengecekan ini dalam Business Process dan mengirim alert lewat modul email/SMS atau Telegram agar kegagalan terlihat tanpa harus terus memantau dashboard.

Daftar periksa cepat sebelum produksi

Sebelum mengaktifkan sinkronisasi data inkremental dengan checkpoint di produksi, lakukan pemeriksaan cepat pada beberapa detail yang biasanya menyebabkan kejutan terlambat. Pemeriksaan ini butuh menit, tapi mencegah hari-hari debugging "kenapa kita melewatkan record?".

Berikut daftar periksa praktis pra-rilis:

• Pastikan field yang Anda gunakan untuk pengurutan (timestamp, sequence, ID) benar-benar stabil dan memiliki index di sisi sumber. Jika bisa berubah setelah fakta, kursor Anda akan drift.
• Konfirmasi kunci upsert Anda benar-benar unik, dan kedua sistem memperlakukannya sama (sensitif huruf besar/kecil, trimming, formatting). Jika satu sistem menyimpan "ABC" dan yang lain "abc", Anda akan mendapatkan duplikat.
• Simpan checkpoint terpisah untuk setiap job dan setiap dataset. "Global last cursor" terdengar sederhana, tapi rusak begitu Anda menyinkronkan dua tabel, dua tenant, atau dua filter.
• Jika sumber bersifat eventually consistent, tambahkan overlap window kecil. Misalnya, saat melanjutkan dari "last_updated = 10:00:00", mulai lagi dari 09:59:30 dan andalkan upsert idempoten untuk mengabaikan pengulangan.
• Rencanakan rekonsiliasi ringan: jadwalkan sampel kecil (misalnya 100 record acak) dan bandingkan field kunci untuk menangkap drift.

Tes realitas cepat: jeda sinkron di tengah run, restart, dan verifikasi hasilnya sama. Jika me-restart mengubah jumlah atau membuat baris ekstra, perbaiki sebelum launch.

Jika Anda membangun sinkron di AppMaster, jaga data checkpoint tiap integrasi terkait process dan dataset spesifik, bukan dibagikan di automasi yang tidak terkait.

Contoh: menyinkronkan record pelanggan antar dua aplikasi

Bayangkan setup sederhana: CRM Anda adalah sumber kebenaran untuk kontak, dan Anda ingin orang yang sama ada di tool support (supaya tiket terkait ke pelanggan nyata) atau di portal pelanggan (supaya pengguna bisa login dan melihat akun mereka).

Pada run pertama, lakukan import satu kali. Tarik kontak dalam urutan stabil, misalnya berdasarkan updated_at ditambah id sebagai tie-breaker. Setelah menulis tiap batch ke destinasi, simpan checkpoint seperti: last_updated_at dan last_id. Checkpoint itu adalah garis start Anda untuk setiap run berikutnya.

Untuk run berkelanjutan, ambil hanya record yang lebih baru dari checkpoint. Update sederhana: jika kontak CRM sudah ada, perbarui record destinasi; jika belum, buat baru. Merges adalah bagian rumit. CRM sering menggabungkan duplikat dan mempertahankan satu kontak "pemenang". Perlakukan itu sebagai update yang juga "mencabut" kontak yang kalah dengan menandainya tidak aktif (atau memetakan ke pemenang) sehingga Anda tidak memiliki dua pengguna portal untuk satu orang.

Delete jarang muncul di query "updated since", jadi rencanakan untuk itu. Opsi umum adalah flag soft-delete di sumber, feed "deleted contacts" terpisah, atau rekonsiliasi periodik ringan yang memeriksa ID yang hilang.

Sekarang kasus kegagalan: sinkron crash di tengah. Jika Anda hanya menyimpan checkpoint di akhir, Anda akan memproses ulang potongan besar. Sebagai gantinya, gunakan resume token per batch.

• Mulai run dan buat sebuah run_id (token resume)
• Proses satu batch, tulis perubahan destinasi, lalu secara atomik simpan checkpoint yang terikat ke run_id
• Saat restart, deteksi checkpoint terakhir yang tersimpan untuk run_id itu dan lanjutkan dari sana

Sukses terlihat membosankan: jumlah stabil hari ke hari, runtime dapat diprediksi, dan menjalankan ulang window yang sama tidak menghasilkan perubahan tak terduga.

Langkah berikutnya: pilih pola dan bangun dengan lebih sedikit pengerjaan ulang

Setelah loop inkremental pertama bekerja, cara tercepat menghindari pengerjaan ulang adalah menuliskan aturan sinkron. Jaga ringkas: record mana yang masuk cakupan, field mana yang menang saat konflik, dan apa arti "selesai" setelah tiap run.

Mulai kecil. Pilih satu dataset (misalnya customers) dan jalankan end to end: import awal, pembaruan inkremental, delete, dan resume setelah kegagalan yang disengaja. Lebih mudah memperbaiki asumsi sekarang daripada setelah menambah lima tabel lagi.

Rebuild penuh kadang masih pilihan yang tepat. Lakukan ketika state checkpoint korup, saat Anda mengubah identifier, atau saat perubahan skema merusak deteksi perubahan (misalnya Anda memakai hash dan arti field berubah). Jika Anda rebuild, perlakukan itu sebagai operasi terkontrol, bukan tombol darurat.

Berikut cara aman melakukan reimport tanpa downtime:

• Impor ke tabel bayangan atau dataset paralel, biarkan yang sekarang live.
• Validasi jumlah dan cek sampel, termasuk edge case (null, record yang digabung).
• Backfill relasi, lalu alihkan pembaca ke dataset baru dalam satu cutover yang direncanakan.
• Simpan dataset lama untuk jendela rollback singkat, lalu bersihkan.

Jika Anda ingin membangun ini tanpa menulis kode, AppMaster bisa membantu menjaga bagian-bagiannya dalam satu tempat: modelkan data di PostgreSQL dengan Data Designer, definisikan aturan sinkron di Business Process Editor, dan jalankan job terjadwal yang menarik, mentransformasi, dan meng-upsert record. Karena AppMaster meregenerasi kode bersih saat kebutuhan berubah, menambahkan satu field lagi menjadi risiko yang lebih kecil.

Sebelum memperluas ke dataset lain, dokumentasikan kontrak sinkron Anda, pilih satu pola (kursor, resume token, atau hash), dan jadikan satu sinkron benar-benar andal. Lalu ulangi struktur yang sama untuk dataset berikutnya. Jika ingin mencoba cepat, buat aplikasi di AppMaster dan jalankan job sinkron kecil terjadwal terlebih dahulu.