Wawancara Data Engineering: Bagaimana Cara Melakukan Backfill Data Historis Skala Besar Secara Aman?

Prompt dan Konteks yang Berlaku

Sebuah pipeline data pesanan membaca 2 TB data mentah immutable dari penyimpanan objek setiap hari dan menghasilkan tabel orders_daily yang dipartisi berdasarkan business_date. Tim menemukan defect pada transformasi pajak yang memengaruhi 90 partisi. Oleh karena itu, tim harus mengomputasi ulang 180 TB dalam waktu 5 hari. Pipeline inkremental harian tidak boleh berhenti; kesegaran P95-nya harus tetap berada pada atau di bawah 45 menit. Pengembalian dana yang terlambat dan koreksi pesanan juga dapat memperbarui business key yang sama dengan yang diproses oleh backfill.

Rancang proses backfill yang repeatable, dapat dilanjutkan setelah dijeda, dapat diaudit, dan reversible. Jelaskan cara mengunci versi input dan kode, membagi dan menjadwalkan partisi, mencegah pekerjaan historis mengambil kapasitas produksi, menyelesaikan tumpang tindih antara backfill dan inkremen live, menentukan validasi pemblokir publikasi, serta memulihkan versi tepercaya terakhir setelah terjadi kegagalan.

Materi wawancara data engineering publik terkini secara eksplisit memperlakukan backfill historis, rerun yang idempoten, dan menjaga pemrosesan real-time sebagai pertanyaan keandalan pipeline. Skenario publik juga meminta kandidat untuk menangani input berskala terabita, pemrosesan ulang partisi, validasi, dan rollback. Dokumentasi resmi pipeline menampilkan eksekusi historis, kebijakan pemrosesan ulang, dan batas konkurensi terpisah. Maksud pencarian ini spesifik: kandidat membutuhkan rencana produksi yang dapat dieksekusi yang melampaui sekadar titik masuk penjadwalan seperti "jalankan ulang 90 hari terakhir di Airflow."

Hal yang Dievaluasi Pewawancara

Sinyal pertama adalah apakah kandidat mendefinisikan versi data yang dapat direproduksi. Jawaban yang kuat mengunci rentang waktu backfill, tanggal logis, snapshot sumber atau versi sumber, kode transformasi, versi dimensi yang bergantung, dan skema target. Jika dua upaya membaca input yang berbeda, atau jika kode bergantung pada now(), nilai acak, atau lookup eksternal yang mutable, "aman untuk dijalankan ulang" tidak memiliki makna yang dapat diuji.

Sinyal kedua adalah memisahkan keberhasilan orkestrasi dari kebenaran data. Sebuah orkestrator dapat membuat eksekusi untuk tanggal logis historis dan membatasi konkurensi. Namun, hal itu tidak membuat operasi penulisan bisnis menjadi idempoten, dan tidak menyelesaikan konflik penulisan antara inkremen live dan backfill historis. Kandidat harus memilih penggantian partisi, MERGE dengan stable-key, atau target berversi dan menjelaskan prasyaratnya.

Sinyal ketiga adalah kapasitas dan isolasi. Untuk menyelesaikan 180 TB dalam 5 hari, laju pembacaan data mentah rata-rata minimum adalah:

180 TB / (5 × 24 h) = 1.5 TB/h ≈ 417 MB/s

Itu adalah batas bawah untuk eksekusi berkelanjutan tanpa percobaan ulang (retry). Angka tersebut belum termasuk amplifikasi pemindaian (scan amplification), shuffle, penulisan target, validasi, dan komputasi ulang yang gagal. Jawaban yang baik melakukan tolok ukur (benchmark) pada satu partisi terlebih dahulu, mengukur throughput dan puncak sumber daya per tahap, lalu menetapkan antrean atau pool komputasi terpisah, batas konkurensi, dan prioritas produksi. Kesegaran pipeline live menjadi sinyal umpan balik yang mengurangi laju backfill.

Sinyal keempat adalah batas publikasi dan pemulihan. Sembilan puluh tugas yang berhasil tidak serta merta membuat versi baru aman bagi konsumen. Sebelum publikasi, sistem harus membuktikan kelengkapan partisi, keunikan key, invarian bisnis, rekonsiliasi sumber, dan perbedaan yang konsisten dengan defect tersebut. Publikasi harus berupa satu cutover versi yang terkontrol. Simpan versi lama selama periode observasi sehingga rollback cukup dilakukan dengan mengubah pointer, bukan mengomputasi ulang 180 TB lagi.

Pertanyaan yang Perlu Diklarifikasi Sebelum Menjawab

• Apakah input mentah benar-benar immutable? Dapatkan versi objek, snapshot ID, atau posisi log yang dapat diputar ulang (replayable). Jika sumber mengubah data secara langsung di tempat (in place), buat versi input yang dapat direferensikan terlebih dahulu.
• Jam mana yang mendefinisikan rentang 90 hari tersebut? Selaraskan business_date, waktu peristiwa (event time), waktu penyerapan (ingestion time), dan zona waktu. Tentukan juga partisi mana yang memiliki pengembalian dana yang terlambat.
• Apa grain target dan stable key-nya? Pastikan apakah satu baris mewakili pesanan, item pesanan, atau agregat harian, serta apakah order_id, source_version, dan urutan konflik deterministik tersedia.
• Data mutable apa yang menjadi dependensi transformasi? Nilai tukar mata uang, aturan pajak, dimensi SCD, dan catatan penghapusan harus dibaca sesuai waktu peristiwa historis, bukan diganti secara diam-diam dengan nilai hari ini.
• Partisi mana yang dapat diperbarui oleh inkremen live? Jika hanya menulis pada 7 hari terakhir, backfill dapat mengambil kepemilikan partisi yang lebih lama. Jika pesanan historis mana pun dapat berubah, diperlukan pengurutan versi atau delta catch-up.
• Fitur isolasi dan publikasi atomik apa yang tersedia? Warehouse terpisah, pool sumber daya, antrean prioritas, transaksi partisi, klona tabel, cutover view, atau pointer katalog akan memengaruhi desain.
• Apakah 5 hari merupakan batas waktu mutlak atau target? Dapatkan target kesegaran P95 live, kuota pembacaan sumber, batas biaya, dan jendela cutover singkat yang diizinkan jika ada.
• Siapa yang memberikan persetujuan (sign off)? Pernyataan teknis (assertions), rekonsiliasi keuangan, sampling downstream, dan periode observasi masing-masing memerlukan penanggung jawab dan ambang batas pemblokiran.

Kerangka Jawaban 30 Detik

"Saya akan mengunci 90 tanggal bisnis, snapshot input, dan versi kode, lalu menulis setiap partisi tanggal logis ke staging terisolasi dengan sebuah manifes. Memproses 180 TB dalam 5 hari membutuhkan setidaknya sekitar 417 MB/s, jadi saya akan melakukan benchmark terlebih dahulu dan melakukan throttling saat P95 live mendekati 45 menit. Setelah mem-backfill W0, saya akan mengejar ketertinggalan melalui W1 dan melakukan cutover hanya setelah 90/90 partisi, rekonsiliasi, dan pemeriksaan bisnis terpenuhi. Versi lama tetap tersedia untuk rollback."

Pembahasan Mendalam Langkah Demi Langkah

Langkah 1: Tentukan backfill sebagai spesifikasi eksekusi yang immutable

Buat sebuah backfill_id dan catat hal-hal berikut:

Teruskan business_date ke dalam setiap eksekusi partisi. Jangan mengganti waktu logis dengan waktu jam dinding (wall-clock time) di dalam transformasi. Jika nilai tukar historis atau dimensi SCD menjadi dependensi, lakukan as-of join pada waktu peristiwa. Perubahan pada input, kode, atau versi dependensi apa pun akan membuat backfill_id baru; jangan mencampur dua versi hasil di dalam satu eksekusi.

Hasilkan rencana tanpa menulis ke target produksi. Buat daftar seluruh 90 partisi, urutan dependensi, estimasi bita input, usulan konkurensi, dan jalur tujuan. Deteksi celah (gaps), tanggal duplikat, partisi di luar retensi sumber, dan efek samping downstream. Nonaktifkan efek non-data seperti email, penagihan, dan panggilan API eksternal, atau alihkan ke mode audit, sehingga pemutaran ulang historis tidak memicu tindakan bisnis nyata kembali.

Langkah 2: Gunakan manifes partisi untuk jeda, lanjutkan, dan audit

Perlakukan setiap business_date sebagai unit kerja yang terikat. Manifes setidaknya harus mencatat:

backfill_id, business_date, input_snapshot, code_sha,
state, attempt, input_rows, output_rows, output_checksum,
staging_location, published_version, started_at, completed_at

Model status yang berguna adalah PENDING → RUNNING → VALIDATED → PUBLISHED, dengan kegagalan masuk ke FAILED. Klaim unit melalui pembaruan kondisional atau lease sehingga partisi hanya memiliki satu pemilik aktif. Lease yang kedaluwarsa dapat diambil kembali. Coba ulang hanya partisi yang gagal dan tulis upaya staging terisolasi lainnya untuk partisi tersebut; jangan pernah menambahkan (append) data secara membabi buta ke tabel akhir.

Jika partisi tanggal telah ditutup sepenuhnya, penulisan idempoten yang paling sederhana adalah membangun partisi secara lengkap lalu mengganti partisi tersebut secara transaksional. Jika pesanan dapat dikoreksi lintas tanggal, gunakan business key yang stabil dan versi sumber dalam MERGE. Tentukan pemenang secara eksplisit, seperti source_updated_at diikuti oleh source_sequence yang monotonik jika terjadi kesamaan. Sebuah MERGE mencegah catatan historis lama menimpa koreksi baru hanya jika primary key, versi, dan semantik penghapusan semuanya dapat diandalkan.

Langkah 3: Turunkan konkurensi dari pengukuran alih-alih menebak jumlah thread

Persyaratan 180 TB/5 hari menghasilkan batas bawah pembacaan mentah sekitar 417 MB/s. Jalankan canary pada 1 partisi representatif dan ukur bita, durasi, CPU, memori, waktu antrean warehouse, dan ruang sementara untuk membaca, dekompresi, shuffle, transformasi, penulisan, dan validasi. Jika satu partisi menghasilkan r MB/s throughput efektif, batas bawah konkurensi teoretis adalah sekitar ceil(417/r). Kuota sumber, puncak shuffle, kapasitas commit target, dan batas biaya akan membatasi nilai riil lebih lanjut.

Berikan pool komputasi atau antrean terpisah untuk backfill dengan prioritas lebih rendah daripada inkremen harian. Batasi konkurensi penjadwal, pembacaan sumber, penulisan target, dan total biaya secara bersamaan; membatasi salah satu saja biasanya tidak cukup. Sebuah pengendali memantau kesegaran P95 pipeline live, antrean warehouse, dan throttling sumber. Saat kesegaran mendekati 45 menit, pengendali akan berhenti mengklaim partisi baru atau menurunkan konkurensi. Pengendali akan meningkatkannya secara bertahap hanya setelah pipeline live kembali ke batas aman. Jangan mematikan secara paksa partisi yang sedang melakukan commit dan meninggalkan output parsial. Sinyal pembatalan harus mencegah klaim baru dan membiarkan pekerjaan yang sedang aktif selesai atau melakukan rollback staging dengan aman.

Setelah canary lolos, lakukan peningkatan skala secara bertahap: misalnya, pertama 1 partisi, lalu 3, kemudian konkurensi aman yang telah diukur. Amati siklus inkremental live secara penuh pada setiap tingkat. Jika kapasitas tidak dapat memenuhi tenggat waktu, ubah tenggat waktu, kapasitas sementara, atau cakupan sejak dini. Jangan menyembunyikan kesalahan estimasi dengan mengorbankan kesegaran data live.

Langkah 4: Tentukan kepemilikan penulisan antara pipeline historis dan live

Pertama, komputasi ulang rentang historis dari snapshot sumber atau log watermark W0 ke dalam versi baru. Jika pipeline live hanya mengoreksi 7 hari terakhir, biarkan backfill secara eksklusif memiliki 83 hari yang lebih lama. Pertahankan 7 hari terakhir di bawah kepemilikan live, lalu komputasi ulang atau gabungkan jendela tumpang tindih tersebut ke dalam versi baru di akhir.

Jika koreksi live dapat menyentuh pesanan historis mana pun, gunakan alur snapshot-plus-delta-catch-up:

1. Catat W0; backfill hanya membaca input deterministik tidak lebih dari W0.
2. Pipeline live terus melayani versi lama, sementara perubahan setelah W0 tetap berada dalam log yang dapat diputar ulang.
3. Setelah seluruh 90 partisi historis tervalidasi, catat W1 dan terapkan perubahan pada (W0, W1] ke versi baru dengan aturan versi yang sama.
4. Setelah jeda (lag) berada dalam batas anggaran cutover, bekukan pointer publikasi secara singkat atau dapatkan write fence dan terapkan delta akhir.
5. Pindahkan konsumen secara atomik ke versi baru, lalu jadikan versi tersebut sebagai target penulisan pipeline live.

Desain ini membutuhkan log perubahan yang lengkap, pengurutan yang stabil, dan primitif cutover yang benar-benar atomik. Jika platform tidak memiliki fitur perubahan view atau katalog yang atomik, gunakan maintenance window eksplisit atau penggantian partisi transaksional dengan cadangan partisi lama. Dokumentasikan status perantara yang terlihat; jangan menjanjikan cutover tanpa gangguan secara lisan saja.

Langkah 5: Validasi berlapis dan terapkan gerbang ketat sebelum publikasi

Jalankan tiga lapisan pemeriksaan setelah setiap partisi staging selesai:

• Struktur dan kelengkapan: skema yang kompatibel, bidang wajib terisi, business key unik, batas tanggal yang benar, serta tidak ada partisi yang hilang atau duplikat di antara 90 partisi tersebut.
• Rekonsiliasi sumber: bandingkan jumlah baris input dan output, pesanan unik, jumlah sebelum pajak, pajak, dan jumlah bersih berdasarkan tanggal, wilayah, mata uang, dan status. Untuk agregat, pertahankan perbedaan tingkat rekaman yang dapat diselidiki.
• Aturan bisnis dan perbedaan: kekekalan nilai (amount conservation), pengembalian dana dalam batas jumlah yang dapat dikembalikan, dan transisi status yang valid. Perbedaan antara versi baru dan lama harus terkonsentrasi pada pesanan yang terpengaruh oleh defect; bagian yang tidak terpengaruh tidak boleh bergeser tanpa penjelasan.

Jumlah baris yang sama adalah bukti yang lemah: operasi join yang buruk dapat menambah dan menghilangkan baris pada saat yang bersamaan. Hitung juga bucketed checksum berdasarkan stable key, ambil sampel defect yang diketahui, tanggal batas, koreksi terlambat, dan penghapusan, serta minta pemilik produk data atau keuangan mengonfirmasi arah koreksi tersebut. Berikan versi pada kueri validasi dan simpan ambang batas, nilai aktual, serta hasilnya.

Gerbang publikasi global setidaknya harus mensyaratkan: 90/90 VALIDATED dalam manifes; tidak ada partisi yang aktif atau gagal; snapshot input, kode, dan versi dependensi yang konsisten; catch-up hingga W1; semua pernyataan mutlak (hard assertions) lolos; pipeline harian mempertahankan kesegaran P95 45 menit selama backfill; dan persetujuan pemilik. Kegagalan apa pun akan membuat versi lama tetap terlihat.

Langkah 6: Lakukan cutover sekali, amati terus-menerus, dan lakukan rollback dengan cepat

Simpan pointer baca dan versi output yang lama sebelum publikasi. Cutover hanya mengubah view yang stabil atau pointer katalog; proses ini tidak memindahkan 180 TB selama cutover. Segera jalankan serangkaian kueri konsumen terhadap dasbor penting dan pekerjaan downstream, serta periksa latensi kueri dan penulisan inkremental terbaru. Lanjutkan membandingkan metrik penting antara versi lama dan baru selama periode observasi.

Jika keunikan key, rekonsiliasi jumlah, kesegaran live, atau kueri konsumen gagal, hentikan publikasi ke versi baru dan kembalikan pointer ke versi lama. Simpan versi yang gagal, manifes, dan bukti validasi untuk penyelidikan; jangan mengeditnya langsung di tempat dan menyajikannya sebagai versi yang sama. Setelah memperbaiki input atau kode, buat spesifikasi eksekusi yang baru. Gunakan kembali partisi yang terbukti tepercaya dan kompatibel versinya; komputasi ulang partisi yang versinya berbeda.

Tampilan pemantauan harus menunjukkan TB yang telah diproses dan yang tersisa, jumlah partisi berdasarkan status, throughput, estimasi waktu penyelesaian, percobaan ulang dan kegagalan validasi, throttling sumber, antrean pool komputasi, latensi commit target, dan kesegaran P50/P95 pipeline live. Peringatan harus mencakup backfill_id, partisi, versi kode, gerbang yang gagal, dan penanggung jawab sehingga operator dapat memutuskan apakah akan mengurangi konkurensi, mencoba ulang partisi, atau menghentikan seluruh publikasi.

Contoh Jawaban Berkualitas Tinggi

"Pertama-tama saya akan membekukan backfill ini sebagai eksekusi berversi: 90 nilai business_date, snapshot mentah dan watermark W0, SHA kode, versi dimensi pajak, versi tabel target, dan ambang batas penerimaan. Setiap hari adalah satu tugas yang menulis output staging terisolasi. Sebuah manifes mencatat PENDING/RUNNING/VALIDATED/PUBLISHED dan setiap percobaan. Transformasi hanya menggunakan waktu logis. Partisi yang tertutup dibangun dan diganti secara menyeluruh; pesanan yang dapat menerima koreksi terlambat menggunakan primary key yang stabil dan versi sumber dalam MERGE, sehingga versi lama tidak dapat menimpa versi yang lebih baru."

"Memproses 180 TB dalam 5 hari membutuhkan setidaknya rata-rata pembacaan mentah sekitar 417 MB/s, sebelum memperhitungkan percobaan ulang dan validasi. Saya akan melakukan benchmark pada satu partisi representatif, mengukur throughput end-to-end dan puncak setiap tahap, lalu meningkatkan konkurensi secara bertahap. Backfill mendapatkan pool sumber daya terisolasi berprioritas rendah dengan batas pada pembacaan sumber, penulisan target, dan konkurensi penjadwal. Pengendali melindungi kesegaran P95 live: ia berhenti mengklaim partisi baru saat lag mendekati 45 menit dan kembali naik secara perlahan setelah pulih."

"Untuk kebenaran konkuren, saya membangun versi baru dari snapshot W0 sementara pipeline live terus melayani versi lama. Setelah partisi historis selesai, saya mencatat W1, memutar ulang koreksi (W0, W1] ke dalam versi baru, lalu menggunakan fence singkat untuk catch-up akhir dan memindahkan pointer secara atomik. Publikasi membutuhkan 90/90 partisi, key yang unik, rekonsiliasi jumlah sumber, invarian bisnis, perbedaan lama/baru yang dapat dijelaskan, dan kesegaran produksi yang sehat. Saya mempertahankan versi lama selama masa observasi. Gerbang mutlak atau kueri konsumen yang gagal akan mengembalikan pointer dan mempertahankan versi yang gagal untuk penyelidikan."

Kesalahan Umum

• Mengatur konkurensi penjadwal ke batas maksimum → Sumber, shuffle, commit target, atau pekerjaan harian menjadi bottleneck sebenarnya → Turunkan konkurensi dari benchmark satu partisi, batas bawah throughput, dan SLO produksi, lalu lakukan throttling secara dinamis.
• Menganggap retry tugas sebagai idempotensi → Orkestrator hanya menjalankan kembali tugas tersebut; penambahan data secara membabi buta tetap menduplikasi data → Gunakan input deterministik dan waktu logis, lalu ganti partisi atau lakukan penggabungan (merge) berdasarkan stable key dan versi.
• Membiarkan pekerjaan historis dan live menulis ke partisi yang sama → Komputasi lama yang selesai terlambat dapat menimpa koreksi baru → Tetapkan kepemilikan partisi atau gunakan delta catch-up W0/W1 dan pengurutan versi yang eksplisit.
• Mempublikasikan setelah 90 tugas berhasil → Status berhasil tidak membuktikan kelengkapan rekaman, kebenaran jumlah, atau perbedaan yang masuk akal → Terapkan gerbang pada pemeriksaan partisi, sumber, bisnis, perbedaan, dan konsumen.
• Menimpa tabel online sebelum validasi → Validasi yang gagal menyisakan komputasi ulang besar lainnya sebagai jalur pemulihan → Tulis output berversi, validasi, lakukan cutover sekali, dan pertahankan pointer lama.
• Hanya membandingkan total jumlah baris → Duplikasi dan data yang hilang dapat saling menghilangkan perbedaan → Bandingkan juga key unik, bucketed checksum, jumlah nilai, distribusi status, dan perbedaan rekaman.
• Memanggil now() dalam transformasi historis → Dua upaya akan menghasilkan semantik partisi yang berbeda → Teruskan tanggal logis, snapshot input, dan versi dependensi sebagai parameter eksekusi.
• Menjalankan ulang seluruh 180 TB setelah terjadi kegagalan → Ini meningkatkan biaya dan risiko serta membuang progres yang telah tervalidasi → Lanjutkan unit yang gagal dari manifes partisi; komputasi ulang partisi yang terpengaruh hanya jika ada versi yang berubah.

Pertanyaan Lanjutan dan Tanggapan

Pertanyaan lanjutan 1: Bagaimana backfill dapat diulang (repeatable) jika sumber tidak memiliki snapshot yang immutable?

Prioritaskan ekspor historis berversi yang dibuat sebelum eksekusi, atau catat posisi snapshot basis data, posisi log CDC, dan ID versi objek. Jika satu-satunya sumber adalah tabel yang mutable, catat waktu baca, watermark, dan checksum per partisi di dalam manifes serta tangkap perubahan secara terus-menerus selama eksekusi untuk catch-up nanti. Jika input asli tidak dapat direkonstruksi, ungkapkan celah reproduksibilitas tersebut; jangan mengklaim dua percobaan pasti identik.

Pertanyaan lanjutan 2: Dimensi SCD yang telah dikoreksi mengalir ke tabel fakta. Mana yang harus di-backfill terlebih dahulu?

Bangun subgraf lineage yang terpengaruh dan proses dalam urutan topologis. Buat versi dimensi baru terlebih dahulu, lalu gabungkan tabel fakta ke versi tersebut sesuai waktu peristiwa, dan terakhir bangun kembali agregat serta data mart. Setiap lapisan berbagi satu pengidentifikasi versi backfill; jangan memublikasikan dimensi lama dengan tabel fakta baru. Validasi business key dimensi, rentang efektif yang tidak tumpang tindih, tingkat kecocokan foreign key fakta, dan agregat penting.

Pertanyaan lanjutan 3: Bagaimana cara mempublikasikan jika platform tidak memiliki pertukaran tabel atomik (atomic table swap)?

Prioritaskan penulisan tabel versi independen dan arahkan konsumen melalui view yang stabil. Jika definisi view dapat diganti secara atomik, cukup alihkan view tersebut. Jika itu pun tidak tersedia, gunakan penggantian batch kecil transaksional dengan cadangan partisi lama atau maintenance window eksplisit yang menjeda pembacaan dan penulisan terkait untuk cutover dan penerimaan. Nyatakan status perantara yang terlihat dan waktu rollback; jangan mendeskripsikan penimpaan multi-langkah sebagai tindakan atomik.

Pertanyaan lanjutan 4: Versi lama dan baru memiliki jumlah baris dan total nilai yang sama. Apa lagi yang harus diperiksa?

Hitung bucketed checksum berdasarkan business key yang stabil dan periksa perbedaan rekaman. Bandingkan distribusi berdasarkan wilayah, mata uang, status pesanan, kelompok pajak, dan tanggal batas. Konfirmasikan bahwa contoh data rusak yang diketahui telah berubah dan contoh yang tidak terpengaruh tidak berubah. Periksa primary key, integritas referensial, transisi status, dan batas atas pengembalian dana. Total yang sama dapat menyembunyikan kelebihan hitung yang menutupi data yang hilang.

Pertanyaan lanjutan 5: Haruskah eksekusi dimulai dari tanggal tertua atau terbaru?

Hal ini bergantung pada dependensi dan nilai bisnis. Jika partisi yang lebih baru bergantung pada status dari partisi sebelumnya, jalankan secara maju (dari yang terlama). Jika partisi bersifat independen dan laporan terbaru memiliki urgensi lebih tinggi, urutan terbalik dapat membantu. Dalam kedua kasus, gerbang publikasi tetap mencakup seluruh rentang waktu kecuali jika pemilik produk secara eksplisit menyetujui publikasi bertahap dengan versi terpisah, cakupan konsumen, dan batas rollback untuk setiap fase.