Data quality — ma’lumotning belgilangan foydalanish maqsadiga qanchalik yaroqli ekanini ifodalovchi xususiyatlar majmuasidir. “Sifatli” tushunchasi mutlaq emas: billing uchun sent aniqligidagi summa talab qilinishi mumkin, marketing trendi uchun esa kechikkan, lekin agregat ma’lumot yetarli bo‘lishi mumkin. Sifat qoidalari biznes ta’rifi, texnik o‘lchov, egasi va buzilishdagi amal bilan birga belgilanadi.
Asosiy o‘lchamlar
Accuracy qiymatning real holatga mosligini, completeness zarur maydon va recordlarning mavjudligini bildiradi. Consistency bir qiymat turli tizim yoki jadvallarda ziddiyat qilmasligini tekshiradi. Timeliness ma’lumot kerakli vaqtgacha yangilanganini, validity esa schema, format va diapazon qoidalariga mosligini ko‘rsatadi. Uniqueness bir obyektning keraksiz dublikatlarini baholaydi.
Har o‘lcham aniq formula talab qiladi. “Email to‘liqligi” majburiy mijozlarda bo‘sh bo‘lmagan email ulushi bo‘lishi mumkin; sintaktik mavjudlik uning yetkazilishini isbotlamaydi. “Kunlik yangilik” oxirgi event va pipeline qabul vaqti orasidagi p95 kechikish bilan o‘lchanishi mumkin.
Tekshiruv qatlamlari
Schema validation tur, majburiy ustun va formatni tekshiradi. Column check minimum, maksimum, regex, accepted values va null ulushini nazorat qiladi. Table check primary key uniqueness yoki satrlar soni kutilishini ko‘radi. Cross-table check foreign key, balans yig‘indisi va jadvallararo invariantni tekshiradi.
Distribution check o‘rtacha, kvantil, cardinality va kategoriyalar ulushidagi kutilmagan siljishni topadi. Bu har doim xato emas; biznesdagi real hodisa ham taqsimotni o‘zgartiradi. Anomaliya avtomatik o‘chirilmasdan, manba egasi bilan tekshiriladi. Freshness check pipeline muvaffaqiyatli ko‘ringan bo‘lsa ham eski snapshot qayta yuklanganini aniqlashi mumkin.
Pipeline boshqaruvi
Sifat tekshiruvi imkon qadar manbaga yaqin qo‘yiladi. Yaroqsiz record quarantine hududiga yuborilib, sabab kodi va asl nusxasi saqlanadi. Barcha xatoni jim drop qilish downstream ko‘rsatkichni pasaytiradi; barcha pipeline ni bitta kichik xatoda to‘xtatish esa mavjudlikka zarar beradi. Criticality va xato budjeti bo‘yicha qaror qilinadi.
Reconciliation manbadagi record va summa bilan targetdagi natijani solishtiradi. Idempotent qayta ishlash dublikat yaratmasligi kerak. Data contract producer va consumer orasida schema, semantika, SLA hamda compatibilityni belgilaydi. Schema o‘zgarishi oldindan e’lon qilinib, lineage orqali ta’sir qiladigan dashboardlar topiladi.
Tashkiliy mas’uliyat
Dashboarddagi qizil indikatorning o‘zi muammoni hal qilmaydi. Har dataset uchun owner, steward, alert oluvchi va tuzatish muddati aniqlanadi. Incidentda qachondan buzilgani, qaysi mahsulotlarga tarqalgani va backfill zarurligi tekshiriladi. Root cause dasturiy kod, noto‘g‘ri biznes ta’rifi yoki manba jarayoni bo‘lishi mumkin.
Sifatni yaxshilash cheksiz tozalash emas. Eng muhim qarorlarga ta’sir qiluvchi qoidalar ustuvor qilinadi. Trendlar, qayta buzilishlar va iste’molchi shikoyatlari kuzatiladi. Ma’lumot kelib chiqishi noma’lum bo‘lsa, aniq formatning o‘zi ishonch bermaydi; provenance va lineage sifat bahosining kontekstini beradi.
SLO va incident
Kritik dataset uchun “soat 08:00gacha 99,5 foiz kunlarda yangilanadi” yoki “primary key dublikati nol” kabi data SLO belgilanadi. Alert faqat buzilish foydalanuvchiga ta’sir qilishidan oldin amal qilish imkonini bersa foydali. Incident davomida noto‘g‘ri dashboard belgilanishi, iste’molchilarga xabar berilishi va tuzatilgan partition qayta nashr etilishi mumkin.
Tarixiy sifat
Joriy batch to‘g‘ri bo‘lsa ham oldingi davrlar xato qolishi mumkin. Backfilldan so‘ng faqat pipeline success emas, tarixiy partitionlar bo‘yicha qoida qayta ishlatiladi. Sifat natijasining o‘zi versiyalanib, qaysi qoida va kod bilan o‘lchangani saqlanadi; aks holda trenddagi o‘zgarish ma’lumotdanmi yoki testdanmi aniqlash qiyinlashadi.
Bog‘liq tushunchalar
Data validation, Data contract, Data profiling, Data lineage, Data governance, Reconciliation, Schema evolution