Temu Duga Kejuruteraan Data: Bagaimanakah Cara Anda Mengembangkan Skema Apache Iceberg dengan Selamat?

Gesaan dan konteks

Sebuah jadual fakta Apache Iceberg menyimpan pesanan selama 18 bulan sementara kerja kelompok Spark, penstriman Flink dan pertanyaan Trino berjalan secara serentak. Pasukan ingin membahagikan customer_name kepada first_name dan last_name serta menukar penyekatan daripada harian kepada bulanan. Fail sejarah tidak boleh ditulis semula kesemuanya, pertanyaan lama mesti terus berfungsi, penulisan penstriman tidak boleh berhenti, dan peluncuran yang gagal mesti boleh diundur balik.

Temu duga ini menguji sama ada calon memisahkan antara keserasian skema, identiti medan, reka letak sekatan, komit syot kilat, dan peningkatan pembaca/penulis. Iceberg mendokumentasikan ID medan yang stabil serta evolusi skema dan sekatan yang bebas; jawapan yang mantap mengubah jaminan tersebut menjadi migrasi berperingkat dan bukannya sekadar mengatakan “ubah jadual dan buat pengisian semula (backfill).”

Perkara yang dinilai oleh penemu duga

Mencari perbezaan antara nama dan identiti medan, antara evolusi skema dan pengisian semula sejarah, serta antara spesifikasi sekatan baharu dan pemindahan fail lama secara fizikal. Calon harus menerangkan keatoman syot kilat, keserasian enjin dan bukti undur balik, termasuk perkara yang berlaku apabila penulis bersaing (race condition) dengan migrasi.

Soalan penjelasan

• Versi Spark, Flink, Trino, katalog dan Iceberg manakah yang membaca dan menulis jadual tersebut?
• Bolehkah customer_name dihuraikan (parsed) dengan andal merentasi pelbagai bahasa, nama tunggal dan sekatan privasi?
• Adakah klien lama bergantung pada kedudukan, SELECT *, atau skema bersiri?
• Bolehkah pembaca mencampurkan spesifikasi sekatan dan masih menggunakan tolak ke bawah predikat tarikh (date predicate pushdown)?
• Bagaimanakah titik pemeriksaan penstriman dan versi skema diselaraskan?
• Adakah katalog menyokong komit atomik, pengekalan syot kilat dan undur balik mengikut ID?

Jawapan 30 saat

“Saya akan menginventori keserasian enjin dan penggunaan lajur, menambah lajur baharu menggunakan ID medan Iceberg, dan mengekalkan lajur lama semasa tempoh pemerhatian. Evolusi sekatan adalah berasingan: fail baharu menggunakan transformasi bulanan sementara fail lama kekal boleh dibaca. Saya akan melancarkan pembaca yang serasi, kemudian penulis, kemudian pengguna, mengesahkan pertanyaan, titik pemeriksaan dan komit serentak, serta mengekalkan syot kilat sebelumnya untuk undur balik. Pengisian semula sejarah ialah tugas yang mempunyai versi, bukan perubahan skema tersirat.”

Penyelesaian langkah demi langkah

Langkah 1: Tentukan matriks keserasian dan kontrak perubahan

Rekodkan skema, ID medan, spesifikasi sekatan semasa, pengekalan syot kilat, versi penulis dan versi pembaca. Kekalkan kontrak berasingan untuk semantik lajur dan reka letak sekatan supaya penghuraian, penamaan semula dan penulisan semula fizikal tidak menjadi satu komit legap.

Anggap pembahagian itu sebagai penambahan dahulu: tambah first_name dan last_name, kekalkan customer_name, dan tentukan peraturan untuk ruang putih, mononim, nama berbilang bahasa dan kegagalan huraian. Jangan sesekali memberikan makna baharu secara senyap kepada lajur lama. Rancang penyingkiran hanya selepas setiap pengguna selesai bermigrasi.

Langkah 2: Gunakan ID medan, bukan kedudukan lajur

Iceberg mengikat medan mengikut ID yang stabil. Rekod perubahan boleh kelihatan seperti ini:

old: id=7 customer_name:string
new: id=21 first_name:string, id=22 last_name:string
old id=7 remains until consumers migrate

Jangan sekali-kali menggunakan semula ID 7 untuk makna yang berbeza selepas pemadaman. Periksa juga ID anak bagi struct, map dan list bersarang. CI harus membandingkan peta ID sebelum/selepas; penamaan semula nama sahaja bukan bukti evolusi yang selamat.

Langkah 3: Asingkan pengisian semula daripada penulisan dalam talian

Biarkan penulis kelompok dan penstriman mengisi lajur baharu dahulu dan menerbitkan metrik kualiti huraian. Buat pengisian semula fail sejarah bagi setiap sekatan kemudian. Baca syot kilat atau tera air (watermark) tetap, dan rekodkan syot kilat input, versi kod, kiraan baris, kegagalan huraian dan checksum dalam manifes. Jika komit Iceberg serentak berkonflik, baca semula syot kilat terkini dan cuba lagi; jangan sekali-kali menulis ganti komit penulis lain.

Jika nama sejarah tidak dapat dihuraikan dengan andal, kekalkan null berserta name_parse_status daripada mereka-reka data identiti. Pengisian semula ialah pengiraan berversi yang berasingan, bukan keperluan daripada perintah skema itu sendiri.

Langkah 4: Kembangkan spesifikasi sekatan secara bebas

Tambah spesifikasi sekatan menggunakan transformasi bulan untuk data baharu sementara fail lama mengekalkan spesifikasi hari. Perancang harus mengenal pasti spesifikasi setiap fail dan mencantasnya (prune) dengan betul.

spec-0: day(ts)      -> existing files
spec-1: month(ts)    -> new files

Uji volum imbasan, pencantasan dan kelakuan fail kecil dalam jadual bayang (shadow table). Pengguna harus membaca metadata melalui katalog dan bukannya membina laluan storan objek daripada nama direktori.

Langkah 5: Peringkatkan keluaran pembaca dan penulis

Sebarkan pembaca yang bertoleransi dengan kedua-dua lajur terlebih dahulu, kemudian penulis yang mengisi lajur baharu, dan hanya selepas itu pengguna yang memerlukan medan baharu tersebut. Sahkan pemulihan titik pemeriksaan penstriman terhadap kedua-dua syot kilat. Rekodkan sokongan khusus enjin untuk penamaan semula, jenis bersarang, promosi jenis, transformasi dan spesifikasi bercampur; gunakan pandangan (view) atau peningkatan enjin jika sokongan tiada.

Jadikan setiap perubahan sebagai syot kilat kecil dan rekodkan penulis, katalog, peta ID dan spesifikasi sekatan. Elakkan menggabungkan pemadaman lajur, perubahan jenis dan penulisan semula yang besar dalam tetingkap pemerhatian yang sama.

Langkah 6: Kawal pintu komit dan kekalkan undur balik

Jalankan pemeriksaan struktur pada ID, jenis dan spesifikasi; pemeriksaan data pada kiraan baris, kadar null, kegagalan huraian, agregat dan hirisan tarikh; serta pemeriksaan tingkah laku pada SQL lama/baharu, pemulihan titik pemeriksaan, konflik komit dan pencantasan. Simpan sampel yang tidak dihuraikan untuk semakan.

Simpan previous_snapshot_id dan new_snapshot_id sebelum keluaran. Jika pintu kawalan gagal, halakan katalog kembali kepada syot kilat lama, kekalkan fail baharu dan bukti, jedakan pengguna yang memerlukan lajur baharu, dan jalankan semula sekatan yang terjejas daripada input tetap.

Jawapan model

“Mula-mula saya akan menginventori sokongan Spark, Flink, Trino dan katalog untuk ID medan, kemudian menambah dua lajur baharu sambil mengekalkan customer_name. Penghurai deterministik dan name_parse_status mengukur kualiti; pengisian semula sejarah menggunakan syot kilat tetap, versi kod dan manifes. Fail baharu menggunakan month(ts) manakala fail lama menggunakan day(ts); metadata jadual mengendalikan kedua-duanya.”

“Saya akan meningkatkan pembaca yang serasi, kemudian penulis, kemudian pengguna. Sebelum keluaran, saya akan mengesahkan ID, null, agregat, pertanyaan lama dan baharu, pemulihan penstriman dan komit serentak. Saya akan mengekalkan syot kilat sebelumnya dan mengundur balik penunjuk katalog jika mana-mana pintu kawalan ketat (hard gate) gagal.”

Kesilapan lazim

• Menggunakan kedudukan lajur sebagai identiti → bait lama salah dibaca → sahkan ID medan yang stabil.
• Menganggap penamaan semula sebagai lajur semantik baharu → nilai lama memperoleh makna baharu → tambah, henti guna (deprecate), kemudian padam.
• Memindahkan setiap fail lama selepas menukar spesifikasi → komit yang terlalu besar dan undur balik yang lemah → biarkan spesifikasi wujud bersama dan tulis semula secara terpilih.
• Meningkatkan pembaca lajur-baharu-sahaja terlebih dahulu → penulis lama mengeluarkan null → pembaca serasi, penulis, kemudian pengguna.
• Hanya menguji perintah skema → pertanyaan atau pemulihan penstriman masih gagal → jalankan pintu kawalan struktur, data dan tingkah laku.
• Mengisi semula secara terus ke dalam syot kilat langsung → tiada titik pemulihan yang bersih → gunakan output berversi dan ID syot kilat.

Soalan susulan dan jawapan

Soalan susulan 1: Mengapakah ID medan yang dipadam tidak boleh digunakan semula?

Fail data lama masih mengandungi ID asal. Menggunakannya semula menyebabkan pembaca mentafsirkan bait lama sebagai medan semantik baharu, jadi peruntukkan ID baharu dan kekalkan medan lama sehingga pengguna dan main semula sejarah selesai bermigrasi.

Soalan susulan 2: Bolehkah spesifikasi sekatan lama dan baharu wujud bersama dengan selamat?

Ya, jika metadata merekodkan spesifikasi setiap fail dan enjin sebenar menggunakan transformasi serta predikat dengan betul. Sahkan pencantasan, kelakuan zon masa dan kiraan fail kecil dengan pertanyaan seperti pengeluaran dan bukannya membuat kesimpulan kelakuan daripada nama direktori.

Soalan susulan 3: Bagaimanakah anda pulih daripada konflik komit serentak?

Baca syot kilat terkini, sahkan input kekal sah, kira semula sekatan yang terjejas sahaja, dan hantar semula. Jangan sekali-kali memaksa fail metadata lama mengatasi syot kilat penulis lain; konflik yang berulang memerlukan keserantakan yang lebih rendah atau hirisan yang lebih kecil.

Soalan susulan 4: Bilakah lajur lama boleh digugurkan?

Selepas pembaca, penulis, main semula, audit dan eksport telah bermigrasi, tempoh pemerhatian stabil, dan syot kilat yang dikekalkan meliputi tetingkap undur balik. Inventori pengguna tersembunyi sebelum menyerahkan pemadaman.

Soalan susulan 5: Apakah yang sepatutnya berlaku kepada nama yang tidak boleh dihuraikan?

Tulis null berserta sebab dan rujukan terkawal kepada nilai asal, pantau mengikut bahasa dan format, serta elakkan meletakkan tekaan ke dalam medan identiti. Betulkannya dalam versi terkemudian atau aliran kerja semakan manusia.