Wawancara Data Engineering: Bagaimana Cara Mengembangkan Kontrak Data Tanpa Merusak Konsumen?

Pertanyaan dan skenario

Ini adalah topik evolusi skema data engineering tingkat menengah hingga senior. Event ini mengisi metrik real-time dan lakehouse; konsumen menjalankan versi yang berbeda dan tidak semuanya dapat melakukan upgrade pada hari yang sama. Asumsikan pengiriman setidaknya sekali (at-least-once delivery) dan event yang dapat diputar ulang (replayable). Kontrak harus mencakup tipe field, semantik, kualitas, kesegaran (freshness), kepemilikan, dan batasan keamanan.

Apa yang sedang diuji oleh pewawancara

• Jawaban yang kuat memisahkan antara "field berhasil di-parse" dengan "makna bisnis tidak berubah."
• Dapatkah Anda membangun matriks kompatibilitas produsen-konsumen alih-alih mengatakan bahwa menambahkan field selalu aman?
• Apakah Anda menggunakan bukti lineage dan penggunaan untuk mengidentifikasi kolom, kueri, dan dasbor yang terpengaruh?
• Dapatkah Anda menegakkan kontrak di CI, gerbang rilis, dan runtime sambil tetap mempertahankan migrasi yang dapat dibatalkan (reversible)?

Pertanyaan klarifikasi untuk diajukan terlebih dahulu

Konfirmasikan format event dan registry, unit dan rentang saat ini dari amount, apakah konsumen menolak field yang tidak dikenal, apakah pesan lama diputar ulang, dan apa arti dari currency yang hilang. Perubahan unit atau pembulatan merupakan kerusakan semantik meskipun wire type dapat di-parse; field metadata opsional memiliki migrasi yang berbeda. Tanyakan juga apakah versi konsumen dapat diobservasi, apakah topik versi ganda sementara dapat diterima, serta jendela kesegaran dan backfill apa yang berlaku.

Kerangka kerja jawaban 30 detik

Saya akan mendefinisikan kontrak sebagai skema, semantik field, aturan kualitas, kesegaran, kepemilikan, dan batasan keamanan, kemudian menginventarisasi lineage dan kemampuan konsumen. Saya tidak akan mengubah amount secara diam-diam; saya akan memublikasikan versi atau field baru, menjaga proyeksi lama tetap dapat dibaca, menjalankan CI kompatibilitas dan validasi bayangan (shadow validation), serta memigrasikan konsumen secara bertahap. Validasi runtime akan menolak atau mengarantina pelanggaran dengan bukti berversi. Setelah migrasi, saya akan mempertahankan jendela depresiasi yang terukur, membangun kembali proyeksi lama dari event yang disimpan, dan membuktikan kesetaraan dengan rekonsiliasi dan pemutaran ulang.

Pembahasan mendalam langkah demi langkah

1. Tulis batasan kontrak. Catat unit, presisi, nullability, enum, kunci, waktu event, target kesegaran, label PII, pemilik, dan persetujuan untuk perubahan yang merusak (breaking changes) selain nama dan tipe. OpenMetadata memodelkan skema, semantik, SLA, keamanan, pengujian kualitas, dan kepemilikan sebagai satu objek kontrak data yang terkelola.
2. Klasifikasikan perubahan. Menambahkan field opsional sering kali kompatibel ke belakang untuk pembaca yang toleran; penghapusan, perubahan tipe, penyempitan rentang, perubahan unit, atau perubahan dari opsional ke wajib pada awalnya bersifat merusak. Mengubah sen bilangan bulat menjadi uang desimal mengubah semantik, jadi tambahkan field atau versi yang dinormalisasi alih-alih mengganti yang lama secara diam-diam.
3. Lakukan analisis dampak. Gunakan metadata OpenLineage Dataset, Job, Run, dan Schema Facet untuk menemukan job, tabel downstream, lineage kolom, dan run terbaru. Untuk seluruh 40 konsumen, catat versi parser, penggunaan field, perilaku pemutaran ulang, dan pemilik migrasi dalam matriks perubahan per konsumen.
4. Rancang migrasi. Untuk periode terbatas, publikasikan amount_minor dan amount_decimal, atau publikasikan event v2. Konsumen lama tetap membaca proyeksi lama; konsumen baru membaca bayangan (shadow-read) field baru. Publikasikan currency sebagai opsional hanya jika nilai default dapat dibuktikan tidak mengubah makna bisnis.
5. Tetapkan gerbang (gates). CI membandingkan kandidat kontrak dengan versi terdaftar untuk memeriksa perubahan tipe, kewajiban, enum, dan semantik. Kemudian jalankan pemutaran ulang sampel, pernyataan kualitas, dan pengujian kontrak konsumen. Ingress produksi memvalidasi versi event; pesan yang tidak valid masuk ke karantina beserta produsen, versi kontrak, dan alasannya.
6. Beralih dan rollback. Migrasikan konsumen secara bertahap sambil memantau kesalahan parse, hilangnya data, rekonsiliasi moneter, latensi, dan perbedaan pemutaran ulang. Jika proyeksi baru salah, hentikan penulisan versi baru dan pulihkan jalur baca lama; event yang disimpan dapat membangun kembali proyeksi lama. Jangan hapus field lama sampai konsumen terakhir dan jendela pemutaran ulang melewati batas depresiasi.
7. Jadikan dapat diatribusikan. Event run OpenLineage mendeskripsikan job, run, input, dan output; sebuah Schema Facet mencatat field dataset. Masukkan versi kontrak, revisi Git, dan hasil validasi ke dalam event lineage sehingga penyelidikan di kemudian hari dapat mengidentifikasi rilis mana yang mengubah hasil konsumen yang mana.

Contoh jawaban berkualitas tinggi

Saya tidak akan menganggap ini sebagai penambahan field biasa. Pertama, saya akan memasukkan unit, presisi, dan aturan pembulatan untuk amount ke dalam kontrak, kemudian memeriksa lineage untuk mengetahui apakah 40 konsumen menggunakannya sebagai sen bilangan bulat, nilai tampilan, atau kunci agregasi. Model kontrak data OpenMetadata mencakup skema, semantik, SLA, keamanan, pengujian kualitas, dan kepemilikan, yang mencegah pemeriksaan "parser menerimanya" disalahartikan sebagai jaminan bisnis.

Saya akan mendaftarkan versi v2 atau versi dual-field yang kompatibel: mempertahankan amount_minor, menambahkan amount_decimal dengan presisi eksplisit, dan menambahkan currency opsional. CI akan menjalankan pemeriksaan kompatibilitas; pengujian kontrak konsumen akan mencakup field yang tidak dikenal, hilangnya mata uang, pemutaran ulang pesan lama, dan batas presisi. Saya akan menghitung proyeksi baru secara bayangan, memigrasikan konsumen secara bertahap, dan menolak event tanpa versi kontrak yang valid di ingress, mengarantina kegagalan dengan peringatan.

Selama peralihan, saya akan memantau rekonsiliasi moneter, hilangnya field, kesalahan parse, latensi, dan perbedaan pemutaran ulang. Setiap ketidaksesuaian akan menghentikan penulisan versi baru, memulihkan jalur baca lama, dan membangun kembali dari event yang disimpan. Hanya setelah setiap konsumen bermigrasi, jendela pemutaran ulang ditutup, dan metrik depresiasi mencapai nol, saya akan menghapus field lama. Metadata OpenLineage Job, Run, Dataset, dan Schema Facet akan memuat versi kontrak dan hasil validasi sehingga analisis dampak dan audit tetap dapat direproduksi.

Kesalahan umum

• Hanya memeriksa apakah JSON dapat di-parse → memperlakukan kompatibilitas tipe sebagai kompatibilitas semantik → masukkan unit, presisi, nullability, dan rentang ke dalam kontrak dan tinjau secara terpisah.
• Memublikasikan karena itu "hanya field baru" → parser yang ketat atau pemeriksaan field wajib gagal → inventarisasi konsumen dan gunakan versi atau dual field saat diperlukan.
• Hanya memantau log setelah produksi → data yang rusak sudah sulit dipulihkan → pasang gerbang di CI, putar ulang sampel, dan karantina saat runtime.
• Menghapus field lama secara langsung → konsumen yang memutar ulang atau tertinggal kehilangan jalur baca mereka → tetapkan jendela depresiasi yang mencakup konsumen dan pemutaran ulang.
• Memperlakukan lineage sebagai katalog statis → Anda tidak dapat menjawab run mana yang terpengaruh → hubungkan Job, Run, Dataset, Schema Facet, versi, dan bukti validasi.

Pertanyaan lanjutan dan tanggapan

Bagaimana jika konsumen lama tidak dapat melakukan upgrade?

Pertahankan proyeksi lama yang kompatibel atau translation layer sehingga event baru juga menghasilkan tampilan lama. Berikan pemilik, tenggat waktu, dan anggaran kesalahan (error budget) kepada konsumen tersebut. Jangan membekukan kontrak selamanya atau membiarkan translator mengubah makna moneter secara diam-diam.

Bagaimana jika currency hilang dan tidak dapat disimpulkan dengan aman?

Perlakukan ini sebagai pelanggaran kontrak atau status tidak diketahui yang eksplisit; jangan mengarang nilai default yang tampaknya masuk akal. Karantina event dan beri tahu produsen. Jika bisnis mengizinkannya, publikasikan nilai "unspecified currency" yang eksplisit dan kecualikan atau kelompokkan dalam metrik downstream.

Bagaimana Anda membuktikan bahwa rollback tidak menghitung ganda uang?

Gunakan ID event, versi kontrak, dan versi proyeksi sebagai kunci idempotensi (idempotency keys). Putar ulang kedua proyeksi dan bandingkan agregat berdasarkan pesanan dan mata uang. Simpan sampel perbedaan, aturan pembulatan, dan snapshot input; lanjutkan penulisan versi baru hanya setelah rekonsiliasi berhasil.