Konteks dan instruksi
Ini adalah pertanyaan desain sistem platform data. Reverse ETL mengirimkan model data warehouse yang tepercaya ke alat CRM, pemasaran, atau produk. Dokumentasi Hightouch menggambarkan alur ini sebagai source → model → sync → destination, sedangkan panduan Census membingkai pengiriman dari data warehouse ke platform bisnis sebagai analitik operasional. Wawancara ini menguji pemrosesan batch dan inkremental, batasan API tujuan, serta tata kelola data secara bersamaan.
Apa yang dinilai oleh pewawancara
- Dapatkah Anda memisahkan snapshot model, deteksi perubahan, penjadwalan, antrean, dan adaptor tujuan?
- Dapatkah Anda melindungi tujuan dengan kunci idempotensi dan versi ketika pengiriman sumber bersifat at-least-once?
- Dapatkah Anda mengubah penghapusan, penarikan izin privasi, pergeseran skema, dan isolasi tenant menjadi kontrak yang eksplisit?
- Dapatkah Anda membuktikan keandalan dengan metrik kesegaran data, keberhasilan, backlog, dan rekonsiliasi daripada hanya menggambar diagram alur data?
Pertanyaan klarifikasi
- Apakah SLO 10 menit hanya berlaku untuk kohort prioritas tinggi atau untuk setiap rekaman?
- Apakah sistem tujuan mendukung batch upsert, penghapusan, kunci idempotensi, dan kursor sisi server?
- Apakah model mengekspos kunci yang stabil, waktu pembaruan, dan tombstone penghapusan? Berapa lama snapshot disimpan?
- Apakah kuota tenant bersifat independen, dan dapatkah satu tenant besar menghabiskan seluruh throughput global?
- Seberapa cepat penarikan izin privasi harus berlaku, dan apakah sinkronisasi baru harus diblokir saat penghapusan mengalami kegagalan?
“Saya akan membagi sistem menjadi model berversi, detektor perubahan, antrean per tenant, adaptor tujuan, dan tugas rekonsiliasi. Setiap rekaman membawa tenantid, kunci bisnis yang stabil, versi model, rowversion, dan status penghapusan. High-water mark atau CDC membuat tugas at-least-once. Adaptor melakukan batching pada upsert sesuai batas tujuan dan menggunakan tenant, tujuan, recordid, dan rowversion sebagai kunci idempotensi. Percobaan ulang tidak boleh menurunkan versi; penghapusan dan penarikan izin menulis pembatas (fence) yang tidak dapat dilewati. Saya akan memantau kelambatan kesegaran (freshness lag), backlog, pembatasan laju (throttling), klasifikasi kegagalan, kesenjangan rekonsiliasi, dan latensi penghapusan pada tujuan.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Tentukan model sumber dan versi
Perlakukan model data warehouse sebagai input sinkronisasi; jangan biarkan worker menggabungkan beberapa database operasional secara ad hoc. Keluarkan record_id, tenant_id yang stabil, bidang bisnis, row_version, updated_at, consent_state, dan deleted_at. Setiap eksekusi model mendapatkan model_run_id. Saat rekaman dihapus, keluarkan tombstone alih-alih menghilangkannya secara diam-diam, sehingga worker dapat membedakan antara “belum dipindai” dan “hapus secara eksplisit di downstream.”
Langkah 2: Deteksi perubahan dan jadwalkan pekerjaan
Prioritaskan kolom pembaruan model atau high-water mark CDC. Simpan checkpoint dan gunakan jendela tumpang tindih agar stempel waktu yang sama tidak menyebabkan baris terlewat. Tulis batch perubahan yang tidak dapat diubah (immutable), lalu biarkan penjadwal membaginya berdasarkan prioritas tenant. Hitung keterlambatan yang diizinkan untuk SLO 10 menit dari usia antrean; pekerjaan berprioritas lebih rendah mengalah untuk memberikan kapasitas saat dibutuhkan, tetapi tidak dapat melewati antrean penarikan izin.
Langkah 3: Buat upsert menjadi idempoten
Pengiriman at-least-once berarti skenario “worker mengalami crash setelah berhasil mengirim” harus aman untuk diputar ulang. Jika tujuan mendukung idempotensi, gunakan tenant_id + destination + record_id + row_version; terima hanya versi yang tidak lebih rendah dari versi saat ini. Tanpa idempotensi tujuan, simpan fingerprint permintaan dan respons, batasi konkurensi, dan lakukan rekonsiliasi dengan membaca data tujuan. Jangan mengklaim bahwa transaksi lintas sistem menyediakan exactly-once. Klasifikasikan percobaan ulang berdasarkan error yang dapat diulang, exponential backoff, dan jumlah percobaan maksimum.
Langkah 4: Isolasi throttling dan beban berlebih
Pertahankan token bucket atau kuota yang dilaporkan tujuan per tenant, ditambah batas atas konkurensi global. Antrean tenant, penjadwalan yang adil (fair scheduling), dan dead-letter queue mencegah satu tenant besar menghabiskan sumber daya tenant lainnya. Ulangi error 429, 5xx, dan batas waktu jaringan dengan jeda; arahkan error 4xx terkait skema atau otorisasi ke penanganan manual. Berikan peringatan saat backlog mendekati batas SLO dan izinkan backfill prioritas rendah untuk dijeda.
Langkah 5: Tangani penghapusan dan penarikan izin privasi
Tulis setiap penarikan izin ke pembatas penghapusan (deletion fence) independen dengan tenant, record_id, dan versi peristiwa. Worker memeriksa fence tepat sebelum melakukan upsert; rekaman yang izinnya ditarik hanya boleh mengirim perintah hapus sampai tata kelola data secara eksplisit membersihkannya. Simpan bukti penerimaan penghapusan tujuan dan stempel waktu. Rekonsiliasi harus mencari rekaman terlarang yang masih ada di downstream; keberhasilan permintaan saja tidak cukup.
Langkah 6: Kelola pergeseran skema dan rollback
Buat versi skema model dan validasi pemetaan bidang sebelum deployment. Terapkan rilis bertahap (gray-release) untuk bidang opsional tambahan; blokir perubahan tipe yang tidak kompatibel atau penghapusan bidang dengan laporan alih-alih merusak semua tenant. Pertahankan mapping_version pada setiap tugas adaptor, coba ulang batch yang gagal dengan pemetaan lamanya, dan lakukan rollback ke versi yang tervalidasi daripada menimpa migrasi parsial dengan keberhasilan terbaru.
Langkah 7: Observasi dan rekonsiliasi
Catat source_run, status tugas, jumlah percobaan, versi sukses terakhir, latensi API, throttle, usia antrean, dan latensi penghapusan berdasarkan tenant dan tujuan. Metrik intinya adalah p95 kelambatan kesegaran prioritas tinggi, tingkat keberhasilan, dead letters, tingkat kesalahan skema, selisih jumlah rekaman sumber versus tujuan, dan selisih hash bidang yang disampel. Jalankan rekonsiliasi penuh setiap hari atau setelah rilis, perbaiki pemutaran ulang yang aman secara otomatis, dan arahkan kesenjangan yang tidak dapat direkonsiliasi ke tim operasi.
Pertimbangan kompromi dan batasan
Snapshot, inkremental, atau CDC
Snapshot sederhana tetapi memindai ulang seluruh data. Peningkatan berbasis stempel waktu lebih hemat biaya tetapi bergantung pada jam yang stabil dan kolom pembaruan. CDC merepresentasikan penghapusan, tetapi lapisan sumber atau pemodelan harus mempertahankan fakta perubahan. Jelaskan bahwa pilihan tergantung pada frekuensi pembaruan model, semantik penghapusan, dan kapasitas tujuan; pertahankan rekonsiliasi penuh berkala sebagai pengaman terhadap baris yang terlewat.
Penempatan antrean dan konsistensi
Partisi tenant meningkatkan isolasi dan pengurutan. Antrean global menggunakan kapasitas secara efisien tetapi membutuhkan penjadwalan yang adil. Anda dapat menjamin visibilitas monotonik untuk satu versi rekaman, tetapi bukan atomic commit lintas data warehouse dan tujuan. Penulisan bersyarat versi, replay, dan rekonsiliasi memberikan konsistensi akhir (eventual consistency) yang dapat dijelaskan.
Backfill versus pembaruan langsung
Beri backfill anggaran prioritas rendah independen, kursor yang dapat dijeda, dan kesadaran terhadap throttling; kirim pembaruan langsung ke antrean prioritas tinggi. Jika keduanya bersaing untuk satu rekaman, row_version yang lebih tinggi menang, dan penulisan bersyarat tujuan harus menolak versi yang lebih lama.
Contoh jawaban model
“Saya akan memperlakukan model data warehouse sebagai sumber berversi, membuat batch perubahan yang immutable dengan high-water mark atau CDC, dan mengantrekannya berdasarkan tenant dan tujuan. Rekaman membawa kunci yang stabil, row_version, versi model, dan versi pemetaan. Upsert menggunakan idempotensi tujuan atau fingerprint permintaan; percobaan ulang dengan exponential-backoff tidak dapat menimpa versi yang lebih baru. Token bucket per tenant dan batas atas konkurensi global menangani throttling. Penghapusan dan penarikan izin menulis pembatas (fence) yang diperiksa tepat sebelum pengiriman, dan tanda terima penghapusan disimpan. Saya akan memvalidasi kelambatan kesegaran, usia antrean, dead letters, kesalahan skema, rekonsiliasi hash bidang, dan residu rekaman terlarang. Kontraknya adalah pengiriman at-least-once dengan konsistensi akhir, bukan exactly-once lintas sistem.”
Kesalahan umum
- Menyebut Reverse ETL sebagai replikasi database real-time sambil mengabaikan pembaruan model dan pemetaan bidang.
- Mengatakan “antrean menjamin exactly-once” tanpa menangani duplikasi permintaan tujuan.
- Menggunakan satu batas laju global alih-alih isolasi tenant, sehingga membiarkan tenant besar menghabiskan seluruh kapasitas.
- Memperlakukan hilangnya data dari model saat ini sebagai penghapusan tanpa tombstone, pembatas izin privasi, dan rekonsiliasi downstream.
- Menyiarkan perubahan skema tanpa mencatat versi pemetaan mana yang digunakan oleh setiap batch.
Pertanyaan lanjutan
Bagaimana Anda membuktikan SLO kesegaran data 10 menit?
Ukur dari waktu commit model atau waktu peristiwa perubahan hingga tujuan mengonfirmasi keterbacaan data, lalu laporkan p95 dan tingkat batas waktu (timeout) untuk rekaman prioritas tinggi. Waktu mulai worker dan rata-rata tidaklah cukup.
Bagaimana jika tujuan hanya mendukung penggantian seluruh koleksi?
Bangun snapshot berversi per tenant dengan model_run_id, unggah koleksi sementara, validasi jumlah dan hash, lalu alihkan versi secara atomik. Penghapusan dan penarikan izin tetap membutuhkan pembatas terpisah; pemuatan penuh berikutnya tidak dapat diasumsikan menghapus data terlarang secara aman.
Bagaimana jika tujuan berhasil tetapi tanda terima hilang?
Putar ulang permintaan idempoten yang sama atau lakukan rekonsiliasi menggunakan fingerprint permintaan dan pembacaan data tujuan. Jika kunci idempotensi maupun pembacaan tidak tersedia, masukkan hasil yang tidak pasti ke peninjauan manual alih-alih menandainya berhasil tanpa bukti.
Kapan sistem ini harus menjadi platform sinkronisasi khusus?
Pisahkan menjadi layanan tugas yang tahan lama (durable) dan lapisan adaptor ketika jumlah tujuan, kuota tenant, versi pemetaan, batasan tata kelola, dan rekonsiliasi melebihi batas pemeliharaan satu DAG. Pengaturan kecil dengan satu tujuan dapat dimulai dengan orkestrator dan skrip idempoten, tetapi tetap membutuhkan kontrak penghapusan dan percobaan ulang.