Temu duga kejuruteraan data: Bagaimanakah anda mereka bentuk gate pelepasan keserasian skema untuk peristiwa?

Prompt dan skop

Satu peristiwa pesanan dihasilkan dan digunakan oleh banyak pasukan. Versi baharu menambah medan pilihan, menamakan semula satu medan dan menghentikan medan lain; pengguna tidak boleh menaik taraf secara serentak, dan mesej sejarah dimainkan semula (replayed). Reka bentuk gate daripada cadangan dan pemeriksaan keserasian sehinggalah peluncuran canary dan rollback. Terangkan cara skema writer/reader Avro, mod Schema Registry dan pemeriksaan kualiti data bekerjasama.

Ini menguji kontrak data, evolusi skema, peluncuran penstriman dan tadbir urus. Schema Registry memusatkan versi dan pemeriksaan keserasian, tetapi peraturan tepat berbeza-beza antara Avro, JSON Schema dan Protobuf.

Perkara yang diuji oleh penemu duga

• Sama ada anda membezakan keserasian backward, forward, full dan transitive dan bukannya menganggap keserasian sebagai satu nilai boolean.
• Sama ada anda memperoleh urutan peluncuran daripada tetingkap penggunaan writer/reader yang sebenar.
• Sama ada pemeriksaan pendaftaran, ID skema masa jalanan (runtime), kelambatan pengguna (consumer lag) dan kualiti data membentuk satu gate pelepasan.
• Sama ada anda mengendalikan penamaan semula, nilai lalai, pemadaman, enum dan perubahan semantik yang tidak boleh diterbalikkan dengan migrasi dan rollback.

Soalan untuk dijelaskan terlebih dahulu

1. Adakah formatnya Avro, JSON Schema atau Protobuf? Penghuraian (parsing) dan butiran keserasian berbeza.
2. Adakah pengguna beroperasi secara masa nyata, kelompok (batch), atau memainkan semula sejarah? Berapa lamakah versi writer yang paling lama mesti kekal boleh dibaca?
3. Pihak manakah yang dilancarkan dahulu, dan adakah terdapat versi long-tail merentas rantau atau pasukan?
4. Adakah subjek dikumpulkan mengikut pasukan, jenis peristiwa atau persekitaran? Adakah keserasian bersifat global atau bagi setiap subjek?
5. Adakah rollback memulihkan producer lama, menghentikan peluncuran, atau memerlukan penulisan dwi (dual-writing) medan lama dan baharu?

Kerangka jawapan 30 saat

Petakan versi ke tetingkap pengguna sebelum memilih mod: reader baharu yang menggunakan mesej lama memerlukan keserasian backward; reader lama yang menggunakan mesej baharu memerlukan keserasian forward; kedua-dua arah mencadangkan full, manakala pemeriksaan transitif merangkumi sejarah yang dikekalkan. Sahkan setiap skema dalam gate pendaftaran, kemudian lancarkan reader sebelum writer. Berikan nilai lalai kepada medan baharu, migrasikan penamaan semula dengan alias atau medan dwi, dan tunggu sehingga tetingkap pengguna tamat sebelum pemadaman. Pantau penolakan pendaftaran, ralat penyahsiri (deserialization), lag, dead letter dan kualiti medan; hentikan peluasan dan kekalkan versi lama sekiranya berlaku anomali.

Jawapan langkah demi langkah

1. Jelaskan matriks writer dan reader

Mesej membawa atau merujuk kepada skema writer; pengguna menyelesaikannya dengan skema reader mereka. Lukis gabungan producer lama/baharu berbanding pengguna lama/baharu dan tandakan kombinasi yang mesti berfungsi. Naik taraf strim secara bergulir biasanya membuatkan pengguna baharu membaca data lama sebelum producer baharu menulis data baharu.

2. Hubungkan mod dengan risiko

Backward memeriksa sama ada reader baharu boleh membaca writer lama. Forward memeriksa sama ada reader lama boleh membaca writer baharu. Full memeriksa kedua-duanya. Jika pengguna memainkan semula pelbagai versi sejarah, gunakan semantik transitif atau uji secara eksplisit set versi yang dikekalkan. Jangan sekali-kali menganggap satu nilai lalai registry adalah universal merentas semua format.

3. Tentukan peraturan perubahan

Menambah medan memerlukan nilai lalai selamat yang makna perniagaannya telah disahkan. Untuk penamaan semula, gunakan alias yang disokong format atau lakukan dual-write pada medan lama dan baharu sebelum memigrasikan reader. Padam hanya selepas pengguna tertua dan tetingkap main semula tamat tempoh. Untuk nilai enum baharu, uji cara reader lama mengendalikan nilai yang tidak diketahui; mengecilkan jenis data atau mengubah maksud mahupun unitnya ialah breaking change.

propose -> lint -> compatibility-check -> consumer-matrix-test
        -> register -> canary-producer -> observe -> expand

4. Bina gate pendaftaran dan CI/CD

Pada masa pull request, jalankan linting format, diff skema yang dinormalkan, pemeriksaan keserasian peringkat subjek dan penyahsiri terhadap sampel sejarah yang representatif. Simpan ID skema dan versi dalam registry; perkakas pengeluaran mesti menolak pendaftaran yang memintas pemeriksaan. Urus keserasian bagi setiap subjek apabila diperlukan, dengan kebenaran yang diaudit dan tiada override global tanpa semakan.

5. Lancarkan reader sebelum writer

Lakukan canary pengguna baharu yang membaca skema lama dan perhatikan ralat penyahsiri serta lag. Kemudian lakukan dual-write atau lepaskan producer baharu. Hentikan pengguna dan medan lama hanya selepas tetingkap yang diisytiharkan tamat. Pengguna long-tail memerlukan pemilik, versi, tarikh akhir dan pelan main semula; "semua orang akan menaik taraf" bukanlah satu satah kawalan (control plane).

6. Ukur kualiti dan lakukan rollback dengan selamat

Jejak ID skema yang tidak diketahui, kegagalan penyahsiri, volum dead-letter, kadar medan hilang, anomali unit, lag pengguna, kejayaan main semula dan penolakan pendaftaran. Lakukan rollback dengan menghentikan producer baharu dan memulihkan writer yang masih serasi. Jika semantik berubah, asingkan topik baharu atau subjek berversi dan bukannya mentafsir data lama di bawah makna baharu.

Contoh jawapan berkualiti tinggi

Saya akan melakar matriks pelaksanaan writer/reader, mengenal pasti producer, pengguna dan versi main semula yang paling lama, serta memilih peraturan untuk format sebenar. Reader baharu yang membaca mesej lama ialah backward; reader lama yang membaca mesej baharu ialah forward; kedua-dua arah memerlukan full, dan sejarah yang dikekalkan mungkin memerlukan pemeriksaan transitif. Setiap perubahan melalui linting, pemeriksaan pendaftaran peringkat subjek dan penyahsiri sampel sejarah.

Urutan peluncuran adalah reader dahulu, writer kedua: canary pengguna baharu, kemudian dual-write atau tukar producer, dan padamkan medan lama hanya selepas tetingkap pengguna tamat. Tambah nilai lalai, migrasikan penamaan semula dengan alias atau medan dwi, dan uji kelakuan klien lama untuk pemadaman dan perubahan enum. Perhatikan penolakan pendaftaran, ralat penyahsiri, lag, dead letter dan kualiti medan. Sekiranya berlaku anomali, hentikan peluasan dan kekalkan skema lama, kembali kepada producer lama atau halakan ke topik berversi apabila semantik telah berubah. Keserasian mesti disahkan untuk format yang dipilih; tetapan lalai sesuatu produk bukanlah semantik yang dikongsi untuk Avro, JSON Schema dan Protobuf.

Mod kegagalan biasa

• Menyatakan "dayakan backward" tanpa menamakan reader dan writer.
• Menamakan semula atau memadam medan secara terus, mengabaikan alias, dual-write dan main semula.
• Hanya memeriksa pendaftaran, bukan mesej sejarah sebenar dan pengguna lama.
• Melancarkan producer baharu terlebih dahulu dan merosakkan pengguna lama.
• Menganggap tetapan keserasian global sebagai dasar subjek dan mengabaikan kebenaran atau hanyutan (drift).
• Hanya memerhatikan Kafka lag, sambil terlepas pandang kehilangan medan, perubahan unit, dead letter dan ralat penyahsiri.

Soalan susulan dan rujukan jawapan

Mengapakah medan yang ditambah sering memerlukan nilai lalai?

Mesej lama tidak mengandungi medan tersebut, jadi reader baharu memerlukan nilai deterministik untuk membina rekod. Nilai lalai mestilah sah dari segi semantik dan bukannya menyembunyikan kecacatan data yang diperlukan dengan null.

Patutkah medan yang dinamakan semula diubah secara terus?

Biasanya tidak. Gunakan alias atau tulis medan lama dan baharu bersama-sama, migrasikan reader, dan buang medan lama hanya selepas tetingkap main semula tamat.

Apakah perbezaan risiko antara full dan full transitive?

Full biasanya memeriksa kedua-dua arah terhadap versi bersebelahan. Full transitive memperluaskan pemeriksaan merentas versi sejarah yang dikekalkan, menjadikan gate lebih ketat dan kos naik taraf lebih tinggi.

Mengapakah skema yang didaftarkan masih boleh kehilangan data?

Keserasian merangkumi resolusi struktur, bukan unit, makna enum, kualiti medan, kebenaran (authorization) atau SQL hiliran. Tambahkan main semula sampel, peraturan kualiti dan pemerhatian masa jalanan.

Bagaimanakah anda menetapkan syarat keluar untuk pengguna long-tail?

Rekod pemilik, versi, masa terakhir digunakan dan keperluan main semula; tetapkan tarikh akhir dan amaran. Tawarkan migrasi sebelum tarikh akhir, kemudian asingkan atau tolak versi lama daripada melemahkan keserasian selama-lamanya.

Bilakah anda patut mencipta subjek atau topik baharu?

Apabila semantik, unit, kitaran hayat atau sempadan kebenaran berubah sehingga keserasian tidak dapat menyatakan peralihan tersebut. Pengasingan mengurangkan risiko salah tafsir tetapi menambah kos dual-write, main semula dan tadbir urus.