Schema drift — kelayotgan yoki saqlanayotgan ma’lumot tuzilishining kutilgan sxemadan vaqt o‘tishi bilan farqlanishidir. Yangi field paydo bo‘lishi, field yo‘qolishi, type o‘zgarishi, nom almashtirilishi yoki nested shaklning o‘zgarishi drift hisoblanadi. U boshqarilmagan bo‘lsa pipeline, analytics va consumerlarni buzadi.
Drift turlari
Additive drift yangi optional field qo‘shilishidir. Bu ko‘pincha eski consumerga kam zarar beradi, ammo strict parser noma’lum fieldni rad etishi mumkin. Subtractive drift mavjud field yo‘qolishidir; consumer uni required deb kutsa xato yuz beradi.
Type drift amountning integerdan stringga aylanishi kabi semantik o‘zgarishdir. Structural drift objectning arrayga yoki flat fieldning nested obyektga aylanishini anglatadi. Semantic drift esa schema o‘zgarmay, ma’no o‘zgarishidir: masalan, qiymat birliklari sekunddan millisekundga o‘tadi. Oxirgi tur texnik schema validatorida ko‘rinmasligi mumkin.
Sabablar
Producer mustaqil deploy qilinib, consumer contracti tekshirilmaganda drift yuz beradi. Semi-structured loglarda application versiyasi yangi kalit yoki boshqa format yozadi. CSV source column tartibini o‘zgartirishi, external API esa versionlanmagan javobni yangilashi mumkin.
Data lake’da turli kun partitionlari turli schema bilan yozilishi ehtimoli bor. Schema-on-read tizimi muammoni ingest paytida emas, keyingi query vaqtida ko‘rsatadi. Bir field ayrim faylda integer, boshqasida string bo‘lsa umumiy type topish qiyinlashadi.
Aniqlash
Pipeline observed schema’ni expected schema yoki registry versiyasi bilan solishtiradi. Field set, data type, null rate, cardinality va value range bo‘yicha profil tuziladi. Faqat yangi field emas, null ulushi keskin oshishi ham upstream field nomi o‘zgarganining belgisi bo‘lishi mumkin.
Drift alertida dataset, producer version, birinchi kuzatilgan vaqt va sample xavfsiz ko‘rinishda beriladi. Har yangi optional fieldni critical alert qilish signal shovqinini oshiradi. Breaking type va required field yo‘qolishi yuqori severity oladi.
Qayta ishlash siyosati
Strict mode noma’lum yoki nomos yozuvni rad etadi. Bu sifatni himoya qiladi, lekin butun ingestni to‘xtatishi mumkin. Permissive mode yangi fieldni saqlaydi yoki nomos qiymatni nullga aylantiradi; data loss yashirin qolmasligi uchun rejected yoki coerced counterlar kuzatiladi.
Quarantine oqimi nomos yozuvni raw payload va error metadata bilan alohida saqlaydi. Producer tuzatilgach replay qilinadi. Maxfiy field quarantine’da ham access control va retention talabini saqlaydi.
Evolution va moslik
Boshqariladigan schema evolution change review, compatibility testi va rollout tartibiga ega. Producer yangi optional fieldni yozishni boshlaydi, consumerlar uni qo‘llay boshlaydi, keyin eski field deprecate qilinadi. Fieldni birdan rename qilish o‘rniga bir davr ikkala nom uzatilishi mumkin.
Contract test producer sample’ini consumer parserida tekshiradi. Schema registry formal format mosligini tekshiradi, lekin biznes invariant va birlikni alohida test qilish kerak. Version field yoki content type consumerga qaysi parserni tanlash imkonini beradi.
Analytics ta’siri
Drift dashboard trendini jim o‘zgartirishi mumkin. Stringga aylangan raqam aggregationdan chiqib ketadi, timezone o‘zgargan timestamp boshqa kunga tushadi. Query ishlashda davom etsa ham natija noto‘g‘ri bo‘lishi mumkin.
Data quality test count, sum, uniqueness va referential invariantlarni kuzatadi. Historical backfill yangi schema bilan eski partitionlarni bir xil ko‘rinishga keltirishi mumkin. Transformation versiyasi va lineage saqlansa qaysi natija qaysi schema asosida yaratilgani aniqlanadi.
Bog‘liq tushunchalar
Schema evolution, Schema registry, Data quality, Contract testing, Data pipeline, Quarantine, Data lineage