Topik temu duga representatif

Temu duga kejuruteraan data: Bagaimanakah anda mengevolusikan skema peristiwa tanpa menjejaskan pengguna?

DataSederhana
Pasukan Editorial Offer.ccDiterbitkan Dikemas kini

Soalan

Satu peristiwa pesanan digunakan oleh belasan perkhidmatan dan beberapa saluran paip data. Anda mesti menambah medan fulfillment_mode yang wajib dan memecahkan nilai status lama kepada enum yang lebih terperinci. Bagaimanakah anda akan mengevolusikan skema peristiwa tanpa menyebabkan pengguna lama terhenti, merosakkan main semula sejarah, atau menjadikan pengeluar baharu dan lama tidak serasi?

Gesaan dan konteks

Soalan kejuruteraan data ini menguji evolusi kontrak peristiwa jangka panjang. Tujuannya bukanlah untuk menghafal definisi ke belakang (backward) atau ke hadapan (forward), tetapi untuk merangka pelan yang selamat daripada pembaca sebenar, penulis, format siri, data sejarah dan urutan pelancaran. Anda perlu menerangkan matlamat keserasian, semantik medan, pendaftaran dan pengujian, operasi dwi-versi, serta syarat-syarat untuk pembersihan akhir.

Perkara yang dinilai oleh penemu duga

  • Sama ada anda membezakan skema penulis (writer schema), skema pembaca (reader schema), dan kombinasi semasa penggunaan (deployment).
  • Sama ada anda memilih kekangan ke belakang (backward), ke hadapan (forward), penuh (full), atau transitif (transitive) berdasarkan urutan pelancaran pengguna (consumer).
  • Sama ada anda mengendalikan medan wajib, perubahan enum, nilai lalai, nilai yang tidak diketahui dan main semula sejarah.
  • Sama ada tadbir urus registri, ujian kontrak, pemantauan, pemulihan (rollback) dan pemilikan adalah sebahagian daripada proses keluaran.

Soalan penjelasan untuk ditanya

Senaraikan format peristiwa, topik atau jadual, setiap pengeluar dan pengguna, pelanggan luar atau rentas pasukan, serta kelajuan naik taraf setiap pengguna. Jelaskan sama ada fulfillment_mode mempunyai maksud baharu atau boleh diterbitkan tanpa kehilangan data daripada status lama, dan sama ada enum baharu membenarkan nilai yang tidak diketahui. Tanya juga sama ada peristiwa sejarah mesti dimainkan semula, sama ada data lake menyimpan muatan mentah, siapa yang memiliki dasar keserasian, dan sama ada dua versi boleh berjalan serentak secara ringkas.

Rangka jawapan 30 saat

Saya akan membina inventori pengguna dan urutan pelancaran pembaca/penulis, memilih arah keserasian dan menguatkuasakannya dalam registri. Tambah medan baharu sebagai pilihan atau dengan nilai lalai yang stabil, gunakan perwakilan enum yang boleh diperluas, dan minta pengeluar menulis kedua-dua medan lama dan baharu sementara pengguna berhijrah mengikut keupayaan. Tentukan pemetaan dan tingkah laku nilai tidak diketahui untuk main semula, kemudian sahkan dengan ujian kontrak, sampel main semula dan pemantauan masa jalan. Padamkan medan atau versi lama hanya selepas setiap pengguna telah berhijrah dan tetingkap pengekalan ditutup.

Analisis mendalam langkah demi langkah

1. Lakarkan matriks pembaca/penulis dan matlamat keserasian

Senaraikan penulis lama dengan pembaca lama, penulis lama dengan pembaca baharu, penulis baharu dengan pembaca lama, dan penulis baharu dengan pembaca baharu. Jika pengguna mungkin dinaik taraf terlebih dahulu, anda memerlukan keserasian ke hadapan; jika pengeluar dinaik taraf terlebih dahulu, anda memerlukan keserasian ke belakang; pelancaran berperingkat (rolling deployment) biasanya memerlukan kedua-duanya semasa peralihan. Main semula sejarah merentasi banyak versi juga memerlukan semakan transitif dan bukannya membandingkan dengan skema terkini sahaja.

2. Jadikan semantik medan boleh diperluas dengan selamat

Jangan jadikan medan baharu wajib serta-merta untuk setiap pembaca lama. Dengan format seperti Avro, gunakan nullable union atau nilai lalai jika sesuai; dengan JSON, tentukan perbezaan antara medan yang hilang (missing), null dan tidak diketahui (unknown). Apabila memperluaskan enum, pastikan pengguna lama mempunyai cabang tidak diketahui yang selamat dan bukannya menganggap hanya nilai hari ini yang akan tiba. Jika status lama tidak boleh dipetakan tanpa kehilangan data, tambah versi peristiwa baharu atau medan selari dan bukannya menukar makna secara senyap.

3. Gunakan registri dan ujian kontrak untuk menyekat keluaran yang tidak serasi

Daftarkan skema mengikut subjek atau jenis peristiwa dan tentukan penamaan, tahap keserasian dan pemilik. Semak skema baharu semasa binaan pengeluar. Dalam CI pengguna, nyahsiri sampel lama dan baharu yang sebenar dan sahkan tingkah laku perniagaan. Uji nilai lalai, enum yang tidak diketahui, semantik masa dan unit, null, serta tingkah laku selepas pemadaman medan, bukan sekadar kejayaan penghuraian (parsing). Semakan yang gagal akan menyekat keluaran daripada menjadi ralat pengguna dalam talian.

4. Lancarkan dengan dwi-tulis dan peringkat demi peringkat

Keluarkan pengguna yang boleh membaca kedua-dua format terlebih dahulu. Kemudian minta pengeluar mengisi medan baharu sambil mengekalkan medan lama. Pantau versi pengguna, ralat penghuraian, penggunaan nilai lalai dan kelengahan (lag) peristiwa; saluran paip data juga mesti mengesahkan jenis jadual, sekatan (partitions) dan isian semula (backfills). Bagi enum atau struktur yang tidak serasi, cipta jenis peristiwa atau topik baharu, gunakan jambatan (bridge) untuk menerbitkan kedua-duanya, dan berikan pemilik serta tarikh persaraan bagi setiap laluan.

5. Tentukan syarat main semula, pemulihan dan pembersihan

Huraikan peristiwa sejarah dengan skema penulisnya, kemudian gunakan pemetaan berversi yang jelas untuk mencipta model semasa. Jangan gunakan nilai lalai hari ini secara senyap pada fakta semalam. Kekalkan skema lama dan baharu, kod penukaran dan snapshot sampel. Semasa pemulihan (rollback) pengeluar, sahkan bahawa versi lama boleh membaca peristiwa yang telah ditulis. Padamkan medan lama atau topik jambatan hanya selepas semua pengguna berhijrah, bacaan medan lama mencecah sifar, semakan main semula dan kualiti lulus, serta tetingkap pemberitahuan ditutup.

Contoh jawapan yang mantap

Saya akan menginventori belasan pengguna dan beberapa saluran paip data, melakarkan empat kombinasi pembaca/penulis semasa pelancaran berperingkat, dan menentukan sama ada fulfillment_mode diterbitkan tanpa kehilangan data daripada status lama atau merupakan fakta baharu. Jika ia boleh diterbitkan, saya akan menjadikan medan itu pilihan dengan nilai lalai yang stabil dan mengekalkan status lama; enum akan merangkumi cabang tidak diketahui yang selamat. Saya akan mengeluarkan pengguna yang membaca kedua-dua format, kemudian meminta pengeluar melakukan dwi-tulis sementara registri menguatkuasakan keserasian. CI akan menguji peristiwa lama dan baharu, medan yang hilang, enum yang tidak diketahui dan main semula sejarah, manakala pemantauan pengeluaran menjejaki kegagalan penghuraian, penggunaan nilai lalai, versi pengguna dan kualiti jadual. Jika strukturnya benar-benar tidak serasi, saya akan mencipta versi peristiwa baharu dan menjambatani kedua-dua laluan. Hanya selepas setiap pengguna berhijrah, bacaan medan lama mencecah sifar, pengesahan main semula lulus dan tetingkap pemulihan ditutup, barulah saya memadamkan medan lama dan jambatan.

Kesilapan biasa

  • Menyatakan "dayakan keserasian ke belakang" tanpa menyenaraikan urutan pelancaran pengeluar dan pengguna.
  • Menambah medan wajib tanpa nilai lalai, peraturan medan hilang, atau laluan selamat untuk pembaca lama.
  • Memperluaskan enum sehingga pengguna lama melontarkan pengecualian (exception) atau menganggap nilai yang tidak diketahui sebagai keadaan perniagaan yang salah.
  • Hanya menyemak sama ada skema boleh didaftarkan dan bukannya menguji sampel lama yang sebenar, main semula, jenis jadual dan hasil perniagaan.
  • Menimpa makna medan sehingga main semula sejarah ditafsirkan secara salah.
  • Mengekalkan dwi-tulis dan kod jambatan selama-lamanya tanpa pemilik, pemantauan, tarikh persaraan, atau syarat pemulihan.

Soalan susulan dan jawapan

Bagaimanakah anda memilih keserasian ke belakang, ke hadapan, atau penuh?

Gunakan urutan pelancaran dan tingkah laku penggunaan. Pelancaran pengeluar dahulu memerlukan pembaca lama membaca data baharu, jadi utamakan keserasian ke belakang (backward). Pelancaran pengguna dahulu memerlukan pembaca baharu membaca data lama, jadi utamakan keserasian ke hadapan (forward). Jika urutan tidak terkawal atau kedua-dua arah mesti berfungsi, gunakan penuh (full). Bagi semua versi sejarah, gunakan transitif (transitive) dan sahkan peraturan sebenar format tersebut.

Mengapakah medan baharu biasanya perlu mempunyai nilai lalai?

Peristiwa lama tidak mengandungi medan tersebut, jadi membaca data lama memerlukan tingkah laku yang jelas. Nilai lalai membolehkan pembaca menghuraikannya, tetapi ia mesti bermaksud tidak diketahui atau tidak disediakan dan bukannya berpura-pura menjadi fakta sejarah. Tanpa nilai lalai yang bermakna, gunakan jenis nullable, versi peristiwa baharu, atau isian semula (backfill) yang jelas.

Bagaimanakah anda mengendalikan enum baharu semasa main semula sejarah?

Kekalkan skema penulis, huraikan semantik asal terlebih dahulu, dan petakan ke dalam model semasa dengan penukaran berversi. Halakan nilai yang tidak boleh dipetakan kepada kuarantin atau pengendalian manual berserta sebab; jangan gugurkan peristiwa atau menggunakan keadaan lalai semasa secara senyap.

Bilakah anda boleh memadamkan medan lama?

Selepas setiap pengeluar dan pengguna berhijrah, bacaan dan penulisan medan lama adalah sifar, ujian main semula, kualiti dan kontrak lulus, tetingkap notis pelanggan atau pelanggan luar ditutup, dan bahan pemulihan serta audit kekal tersedia. Padamkannya secara berperingkat.

Sumber awam

Soalan berkaitan