Pertanyaan dan kapan ini berlaku
Pewawancara mungkin bertanya, “Bagaimana Anda akan mengembangkan skema event OpenLineage tanpa merusak consumer downstream?” Ini cocok untuk peran data-platform, data-infrastructure, dan sistem lineage. Pertanyaan ini menguji apakah Anda dapat mengubah JSON Schema, ekstensi Facet, client yang dihasilkan, versi event, dan kompatibilitas consumer menjadi sebuah proses rilis.
Apa yang dinilai oleh pewawancara
Kuncinya bukanlah menghafal nama-nama field; melainkan mengenali batasan perubahan. OpenLineage mendokumentasikan spesifikasinya sebagai JSON Schema dan memerlukan peningkatan versi (version bump) saat file JSON yang ada berubah; client Java dan Python dihasilkan darinya. Pewawancara juga mengharapkan Anda untuk membedakan RunEvent, JobEvent, dan DatasetEvent, serta mengetahui bahwa Facet kustom memerlukan prefiks unik dan URL skema berversi yang tidak dapat diubah (immutable).
Pertanyaan klarifikasi untuk diri sendiri
Perjelas apakah perubahan tersebut memengaruhi objek inti, Facet yang ada, atau Facet kustom baru. Producer mana yang memancarkan event dan consumer mana yang mem-parsing-nya? Apakah ada client lama, tugas replay, atau SDK lintas bahasa? Apakah tujuan kompatibilitasnya adalah membaca event lama, penulisan ganda (dual-writing) versi, atau peralihan sekaligus (one-time cutover)? Tanyakan juga apakah suatu field bersifat wajib, opsional, atau mengubah makna, serta bagaimana penanganan event yang gagal.
Kerangka jawaban 30 detik
Gunakan lima langkah:
- Inventarisasi producer, consumer, tipe event, dan versi skema saat ini.
- Lebih utamakan field opsional atau Facet baru daripada mengubah semantik yang sudah ada.
- Naikkan versi, perbarui contoh dan client yang dihasilkan, serta buat matriks kompatibilitas.
- Validasi dengan replay dan traffic shadow, lalu lakukan canary pada producer sambil memantau kegagalan parsing dan field yang hilang.
- Tetapkan jendela depresiasi, jalur rollback, dan kriteria keluar untuk migrasi consumer.
Jawaban mendalam langkah demi langkah
1. Petakan batasan event dan dependensi
Model objek OpenLineage berisi Jobs, Runs, dan Datasets. RunEvent mewakili status runtime, sedangkan JobEvent dan DatasetEvent mewakili metadata design-time. Konfirmasikan event, Facet, dan client mana yang terpengaruh. Petakan repositori skema, kode yang dihasilkan, message bus, indeks, dan API kueri sehingga perubahan tidak terbatas hanya pada producer.
2. Pilih evolusi yang kompatibel
Menambahkan field opsional biasanya lebih aman daripada menghapus, mengubah tipe, atau mendefinisikan ulang field yang ada. Jika maknanya berubah, tambahkan field atau Facet baru dan lakukan dual-write untuk sementara waktu. Gunakan prefiks khusus proyek untuk Facet kustom guna menghindari tabrakan; Facet dengan nama yang sama menggantikan instance sebelumnya pada suatu entitas, sehingga nama dan versi harus tetap stabil.
3. Ubah versi dengan pembuatan kode
OpenLineage memerlukan peningkatan versi file saat JSON Schema yang ada berubah, dan URL versi harus mengarah ke versi yang immutable. Hasilkan client Java dan Python, jalankan pengujiannya, dan verifikasi bahwa setiap producer dan consumer dikunci ke versi yang dituju. Jangan hanya memperbarui dokumentasi atau menyalin tipe secara manual.
4. Buat matriks kompatibilitas secara eksplisit
Minimal uji producer baru dengan consumer lama, producer lama dengan consumer baru, dan kedua versi terhadap data yang di-replay. Untuk setiap field, catat apakah field tersebut boleh hilang, apakah field yang tidak dikenal diabaikan, apakah nilai enum baru aman, dan apakah konversi bersifat reversibel. Jika consumer lama menolak field yang tidak dikenal, jangan langsung memperluas traffic produksi.
5. Validasi dengan contoh, replay, dan traffic shadow
Simpan contoh minimal, lengkap, dan tidak valid untuk setiap Facet. Replay event historis melalui parser baru dan bandingkan output terstruktur serta indeks kueri. Kemudian salin event dari producer baru ke topik shadow tanpa mengubah graf lineage aktif. Pantau kegagalan parsing, Facet yang tidak dikenal, distribusi versi, dan latensi end-to-end; hentikan canary jika ada anomali.
6. Rancang depresiasi dan rollback
Publikasikan batas akhir versi lama, pemilik migrasi, dan daftar consumer. Producer dapat melakukan dual-write terlebih dahulu dan menghentikan field lama setelah consumer ditingkatkan. Rollback harus mempertahankan skema lama, client, dan kemampuan replay; menghapus event versi lama akan memulihkan kode tetapi tidak memulihkan kemampuan untuk menginterpretasikan data.
Contoh jawaban berkualitas tinggi
Jawaban fiktif ini harus diganti dengan tipe event dan kendala organisasi Anda:
Saya akan menginventarisasi producer, consumer, versi client, dan tugas replay untuk RunEvent, JobEvent, dan DatasetEvent, lalu mengidentifikasi apakah perubahan ada di skema inti atau Facet kustom. Saya lebih memilih field opsional yang kompatibel ke belakang; jika maknanya berubah, saya akan menambahkan field atau Facet dengan prefiks khusus proyek. Saya akan menaikkan versi JSON Schema, menghasilkan client Java dan Python, serta memperbarui contoh minimal, lengkap, dan tidak valid. Validasi akan mencakup producer baru dengan consumer lama, producer lama dengan consumer baru, dan replay historis, diikuti oleh canary traffic shadow. Saya akan memantau kegagalan parsing, Facet yang tidak dikenal, distribusi versi, dan latensi. Setelah consumer memenuhi kriteria migrasi, saya akan mengakhiri dual-writing selama jendela depresiasi yang terdokumentasi. Skema lama, client, dan jalur replay tetap tersedia sehingga rollback tidak menghapus makna event.
Kesalahan umum
Mengatakan bahwa menambahkan field selalu kompatibel
Sifat opsional, perilaku terhadap field yang tidak dikenal, dan pembaruan client yang dihasilkan dapat mengubah hasilnya. Berikan matriks kompatibilitas dan perlengkapan pengujian (fixtures) yang konkret.
Mengubah skema tanpa menaikkan versinya
URL versi memungkinkan consumer mengidentifikasi semantik. Melewatkan peningkatan versi dapat merusak pembuatan kode atau membuat consumer yang berbeda mengasumsikan definisi lama.
Memperlakukan Facet kustom sebagai JSON arbitrer
Facet kustom memerlukan prefiks unik dan URL skema berversi yang immutable. Tabrakan penamaan dapat secara diam-diam menggantikan instance Facet entitas sebelumnya.
Hanya menguji event baru, bukan replay
Sistem lineage sering me-replay riwayat data. Tanpa pengujian replay, field yang hilang, versi yang bercampur, dan migrasi indeks akan tetap tersembunyi.
Pertanyaan lanjutan dan latihan tingkat lanjut
Consumer lama gagal saat menerima Facet yang tidak dikenal. Bagaimana cara Anda merilisnya?
Pertama, buat consumer mengabaikan Facet yang tidak dikenal atau rutekan Facet baru ke traffic shadow. Lakukan canary pada producer hanya setelah perilaku parser dan metrik aman; jangan pernah berasumsi bahwa setiap consumer JSON bersifat permisif.
Kapan Anda akan menggunakan Facet baru alih-alih field inti?
Gunakan Facet untuk konteks yang dapat berkembang secara independen. Pertimbangkan perubahan skema inti hanya jika informasi tersebut mengubah identitas atau siklus hidup Job, Run, atau Dataset. Jelaskan mengapa batasan kueri dan kepemilikan lebih penting daripada jumlah field.
Pembuatan kode Java berhasil tetapi Python gagal. Apa yang Anda lakukan?
Jeda rilis, bandingkan bagaimana generator menangani field opsional, enum, dan properti yang tidak dikenal, lalu perbaiki skema atau template dan jalankan kedua rangkaian pengujian client. Berhasilnya satu bahasa bukan merupakan kriteria keluar migrasi.
Producer lama masih ada setelah jendela migrasi berakhir. Bagaimana cara menanganinya?
Buat daftar sumber yang tersisa berdasarkan producer dan tim, batasi penulisan versi lama, dan sediakan jalur error atau penurunan performa (degradation) yang eksplisit. Jika penghentian total akan menghilangkan lineage penting, perpanjang jendela dengan mencatat risikonya; jangan menghapus event atau skema lama.