Gesaan dan skop
Anggap ini sebagai soalan reka bentuk kejuruteraan data. Andaikan 2,000 peristiwa pesanan sesaat pada waktu puncak, sasaran kesegaran 15 minit, dan sasaran kelengkapan 99.5% untuk medan yang diperlukan. Kontrak mesti merangkumi struktur, makna, kualiti, tahap perkhidmatan, pemilikan, tag privasi dan proses untuk mengubah sebarang janji.
Sempadan yang berguna ialah produk data antara pengeluar huluan dan pengguna hiliran. Definisi jadual pangkalan data sahaja terlalu sempit: ia tidak dapat menyatakan sama ada total_amount merangkumi cukai, siapa yang memiliki suapan tersebut, atau apa yang berlaku apabila sasaran kesegaran terlepas.
Perkara yang diuji oleh penemu duga
Penemu duga ingin mendengar tentang kontrak yang boleh dilaksanakan, berversi dan dimiliki. Jawapan yang lemah hanya menyenaraikan Avro atau JSON Schema. Jawapan yang kukuh memisahkan keserasian daripada ketepatan semantik, meletakkan pemeriksaan pada sempadan pengeluar, dan memberikan pengguna laluan pelanggaran dan migrasi yang boleh diramal.
Anda harus menghubungkan setiap medan dengan keputusan pengguna: tolak, kuarantin, transformasi, maklumkan atau teruskan dengan keadaan terdegradasi yang jelas. Anda juga harus menerangkan bagaimana kontrak mengelak daripada menjadi barisan kelulusan yang tidak didokumenkan.
Penjelasan yang mengubah reka bentuk
- Adakah sumbernya strim peristiwa tambah sahaja (append-only), jadual boleh ubah (mutable), atau kedua-duanya? Syot kilat boleh ubah memerlukan kunci, semantik kemas kini dan peraturan pemadaman.
- Jaminan manakah yang merupakan pintu pelancaran ketat (hard launch gates)? Peristiwa pembayaran mungkin ditolak pada mata wang yang tidak sah, manakala label pemasaran pilihan mungkin dikuarantin.
- Bolehkah pengguna ketinggalan satu versi? Jika ya, terbitkan tetingkap keserasian dan transformasi; jika tidak, wajibkan peralihan yang diselaraskan.
- Adakah peristiwa boleh dimainkan semula (replayable) dan adakah ia mengandungi data peribadi? Kebolehan main semula mempengaruhi pengekalan, dan tag privasi mempengaruhi penyamaran, akses dan pengendalian pemadaman.
Rangka kerja jawapan 30 saat
"Saya akan bermula dengan kes penggunaan pengguna dan menulis kontrak berversi yang boleh dibaca mesin. Ia akan menentukan skema dan semantik, pemeriksaan medan wajib dan domain, SLO kesegaran dan kelengkapan, pemilikan, tag privasi serta dasar evolusi. Pengeluar membuat pengesahan sebelum menerbitkan; registri menyemak keserasian dalam CI; pemeriksaan masa jalan mengkuarantin rekod yang rosak dan mendedahkan metrik. Versi baharu adalah secara penambahan (additive) mengikut lalai, dengan tetingkap penerbitan dwi atau transformasi untuk perubahan semantik yang memecahkan keserasian. Setiap pelanggaran mempunyai pemilik, laluan main semula dan status yang dapat dilihat oleh pengguna."
Reka bentuk langkah demi langkah
1. Tentukan objek kontrak
Berikan set data pengecam dan versi. Bagi setiap medan, rekodkan jenis, kebolehan bernilai nol (nullability), unit, makna perniagaan, nilai yang dibenarkan, sensitiviti dan sama ada medan yang tidak diketahui dibenarkan. Untuk peristiwa pesanan, nyatakan sama ada occurred_at ialah masa peristiwa, sama ada jumlah adalah unit kecil integer, dan sama ada pesanan yang dibatalkan kekal kelihatan.
Tambah pemilikan, kenalan sokongan, pengekalan, kesegaran, kekerapan penghantaran dan ketersediaan. Tahap perkhidmatan boleh diukur: kesegaran boleh menjadi usia rekaman terkini yang diterima, manakala kelengkapan boleh menjadi nisbah medan wajib bukan nol dalam satu tetingkap.
2. Asingkan pemeriksaan mengikut mod kegagalan
Pemeriksaan skema mengesan medan yang hilang dan jenis yang tidak serasi. Pemeriksaan domain mengesan jumlah di bawah sifar atau mata wang yang tidak disokong. Pemeriksaan hubungan mengesan ID peristiwa pendua atau peralihan pesanan yang melangkau keadaan yang diperlukan. Pemeriksaan kesegaran dan volum mengesan pengeluar yang terhenti atau sekatan separa.
Simpan keputusan ujian bersama versi kontrak, binaan pengeluar, sekatan, tetingkap sampel dan peraturan yang gagal. Bukti tersebut membolehkan pengguna memutuskan sama ada untuk menjeda, mengisi semula (backfill) atau menerima degradasi yang terhad.
3. Kuat kuasakan sebelum dan selepas penerbitan
Dalam CI, bandingkan skema yang dicadangkan dengan versi yang didaftarkan dan jalankan ujian kontrak yang representatif. Pada masa jalan, sahkan pada sempadan pengeluar sebelum peristiwa memasuki strim yang dikongsi. Hantar rekod yang tidak sah ke strim kuarantin bersama muatan asal, kegagalan peraturan, versi kontrak dan kunci main semula.
Pengguna masih perlu mengesahkan invarian kritikal pada sempadan mereka. Penguatkuasaan pengeluar menghalang banyak insiden; pemeriksaan pengguna melindungi daripada laluan yang salah dikonfigurasikan, pengeluar lama dan pepijat transformasi.
4. Jadikan evolusi eksplisit
Anggap penambahan medan pilihan sebagai perubahan yang mengekalkan keserasian hanya apabila pengguna lama bertolak ansur dengan medan yang tidak diketahui. Penamaan semula adalah memecahkan keserasian kerana makna atau nama medan berubah. Utamakan kaedah tambah-dan-usangkan (add-and-deprecate): terbitkan medan baharu, tulis dwi atau transformasi, migrasikan pengguna, ukur pembacaan medan lama, kemudian hentikannya selepas tetingkap yang dinyatakan.
Untuk perubahan semantik seperti menukar total_amount daripada termasuk cukai kepada tidak termasuk cukai, versi baharu dan medan baharu adalah lebih selamat daripada menggunakan semula nama tersebut. Jika pengguna mesti kekal pada paparan lama, gunakan transformasi berversi dan labelkan nilai yang ditukar.
5. Tentukan pengendalian pelanggaran
Gunakan peringkat keterukan. Peristiwa pembayaran yang salah bentuk ditolak dan dikuarantin. Pelanggaran kesegaran menghantar panggilan amaran (page) kepada pemilik dan menandakan produk data sebagai lapuk (stale). Kegagalan perihalan yang tidak kritikal boleh diteruskan dengan metrik. Kontrak harus menyatakan siapa yang boleh mengatasi sekatan (override gate), untuk berapa lama, dan bukti yang diperlukan.
Jangan gugurkan rekod secara senyap. Jejaki bilangan yang diterima, ditolak, dikuarantin, dimainkan semula dan pendua mengikut pengeluar dan versi kontrak. Main semula mestilah idempoten, jadi sink menggunakan ID peristiwa dan versi kontrak untuk mengelakkan daripada mencipta kesan perniagaan kali kedua.
6. Sahkan model operasi
Jalankan ujian kontrak pada data lekapan (fixture), ujian keserasian pada setiap versi yang dicadangkan, dan pengesahan kenari pada sekatan pengeluaran sampel. Uji peristiwa lewat, ID pendua, nilai enum yang tidak diketahui, medan wajib bernilai nol, kesilapan zon masa dan pengeluar yang berhenti menghantar.
Papan pemuka yang berguna menggabungkan kadar pelanggaran, usia kesegaran, kelengkapan, kelengahan pengguna, kedalaman kuarantin, kejayaan main semula dan masa untuk pengakuan pemilik. Pemeriksaan skema berwarna hijau dengan suapan yang lapuk masih merupakan produk data yang gagal.
Contoh jawapan berkualiti tinggi
"Saya akan menganggap strim pesanan sebagai produk data berversi. Mula-mula saya akan menyenaraikan pengguna dan menentukan semantik peristiwa: masa peristiwa, unit jumlah, mata wang, identiti dan peralihan keadaan. Kontrak tersebut kemudiannya akan mengandungi skema, peraturan domain dan hubungan, SLO kesegaran dan kelengkapan, pemilikan, pengekalan serta tag privasi.
"Registri akan menolak perubahan yang tidak serasi dalam CI. Pengeluar akan mengesahkan sebelum menerbitkan, manakala pengesah masa jalan menghantar rekod yang rosak ke kuarantin bersama peraturan yang gagal dan versi kontrak. Pengguna mengekalkan set kecil pemeriksaan kritikal kerana penghalaan atau transformasi masih boleh menjadi salah.
"Saya akan menjadikan evolusi secara penambahan mengikut lalai. Untuk penamaan semula atau perubahan semantik, saya akan menambah medan atau versi baharu, menerbitkan dwi, memigrasikan pengguna, mengukur pembacaan medan lama dan hanya menghentikan versi lama selepas tetingkap keserasian. Pelanggaran kesegaran dan kualiti mempunyai keterukan, pemilik, makluman dan prosedur main semula yang jelas. Saya akan mengesahkan reka bentuk dengan lekapan, kenari, peristiwa lewat dan pendua, serta metrik untuk kesegaran, kelengkapan, kedalaman kuarantin dan ketepatan main semula."
Kesilapan biasa
- Kesilapan → Kegagalan → Pembetulan: Memanggil skema sebagai keseluruhan kontrak → perubahan semantik dan pemilikan kekal tersirat → dokumentasikan makna, SLO, pemilik dan dasar perubahan.
- Kesilapan → Kegagalan → Pembetulan: Menolak setiap rekod yang tidak sah secara segerak → satu peristiwa buruk boleh menyekat keseluruhan sekatan → kuarantin dengan tekanan balik terhad dan kunci main semula.
- Kesilapan → Kegagalan → Pembetulan: Mendakwa medan penambahan sentiasa selamat → pengguna yang ketat mungkin gagal pada medan yang tidak diketahui → sahkan keserasian pengguna sebelum membenarkan perubahan.
- Kesilapan → Kegagalan → Pembetulan: Memberi amaran hanya pada ketidakpadanan skema → data lapuk atau tidak lengkap masih boleh melepasi pemeriksaan skema → pantau kesegaran, volum, kelengkapan dan invarian perniagaan.
- Kesilapan → Kegagalan → Pembetulan: Menggunakan semula nama medan selepas menukar maknanya → nilai sejarah dan nilai baharu menjadi tidak dapat dibandingkan → cipta versi baharu atau medan yang ditransformasikan secara jelas.
Soalan susulan dan jawapan
Bagaimana jika semua pengeluar tidak boleh menaik taraf secara serentak?
Kekalkan kontrak lama aktif, tambah medan atau versi baharu, dan terima kedua-duanya semasa tetingkap yang diukur. Penyesuai keserasian boleh menterjemah input lama, tetapi ia mesti mendedahkan kehilangan penukaran dan tarikh persaraan dan bukannya menyembunyikan perbezaan tersebut.
Bagaimana jika ujian kontrak lulus tetapi metrik masih salah?
Itu adalah hanyutan semantik. Tambah invarian peringkat perniagaan atau pemeriksaan penyelarasan, bandingkan dengan sumber bebas, dan rekodkan definisi yang dipertikaikan dalam kontrak. Keserasian struktur tidak dapat membuktikan bahawa pengeluar telah menggunakan peraturan perniagaan yang betul.
Bagaimanakah anda menghalang kuarantin daripada menjadi tanah perkuburan data?
Berikan setiap peraturan seorang pemilik dan sasaran luput, kekalkan muatan asal dan versi kontrak, serta ukur usia barisan gilir dan kejayaan main semula. Semakan harian harus mengklasifikasikan kegagalan sebagai pepijat pengeluar, kecacatan kontrak atau pengecualian yang dijangkakan.
Bilakah anda akan mengelak daripada menggunakan data contract?
Bagi jadual peribadi jangka pendek dengan seorang pemilik dan tiada komitmen hiliran, skema ringan dan ujian mungkin lebih murah. Perkenalkan kontrak yang lebih lengkap apabila berbilang pasukan, main semula, medan terkawal atau komitmen kesegaran menjadikan andaian tersirat berisiko.