2-bob: Ma’lumotlar Modellari, Formatlari va Sifati

1-bobda siz ma’lumotlar muhandisligi shunchaki fayllarni bir joydan ikkinchi joyga ko’chirish emasligini o’rgandingiz. Bu ma’lumotlar operatsion tizimlardan tahlil, avtomatlashtirish va AI’ga o’tayotganda ma’noni saqlab qoladigan ishonchli ma’lumotlar mahsulotlarini (data products) qurish amaliyotidir. Ushbu bob ushbu fikrlash tarzini birinchi aniq dizayn mahoratiga aylantiradi: ma’lumotlar qanday ifodalanishi, saqlanishi, modellashtirilishi va sinovdan o’tkazilishi kerakligini hal qilish.

Ushbu bobning amaliy natijasi kichik, ammo real TuranMart ma’lumotlar dizayni to’plamidir. Siz elektron tijorat buyurtma ma’lumotlarini tekshirasiz, operatsion mohiyat-munosabat modelini (entity-relationship model) loyihalashtirasiz, xuddi shu biznes jarayonini tahlil uchun o’lchamli modelga (dimensional model) aylantirasiz va CSV hamda JSON manba fayllarini sifat tekshiruvlarini qo’llagan holda Parquet formatiga o’zgartiradigan daftarni ishga tushirasiz. Maqsad har bir mumkin bo’lgan fayl formati yoki modellashtirish texnikasini yodlash emas. Maqsad professional ma’lumotlar muhandislari biznes voqeligini qanday qilib ishonish, so’rov qilish va rivojlantirish oson bo’lgan tuzilmalarga aylantirishini o’rganishdir.

Kirish stsenariysi: TuranMart’ning Daromad Muammosi¶

TuranMart’ning marketing jamoasi mintaqaviy kampaniyani ishga tushirdi. Veb-sayt minglab yangi buyurtmalarni ko’rsatmoqda, to’lov provayderi boshqacha daromad raqamini xabar qilmoqda va logistika boshqaruv paneli ushbu buyurtmalarning ko’pchiligi jo’natilmaganini aytmoqda. Moliya jamoasi mintaqa, mahsulot kategoriyasi va kampaniya bo’yicha ishonchli kunlik daromad jadvalini so’raydi. Marketing konversiya ko’rsatkichlarini so’raydi. Logistika qaysi shaharlar yetkazib berish kechikishlarini keltirib chiqarayotganini so’raydi. Bosh direktor (CEO) oddiy savol beradi: “Kecha nima bo’ldi?”

Bu savol qiyinlashadi, chunki har bir manba tizimi biznesni turlicha tavsiflaydi. To’lovni rasmiylashtirish ma’lumotlar bazasi customers, orders, order_items, payments va shipments kabi normallashtirilgan jadvallarni saqlaydi. Veb-ilova har bir hodisa ichma-ich kampaniya metama’lumotlarini o’z ichiga olishi mumkin bo’lgan JSON hodisalarini chiqaradi. Moliya jamoasi ba’zan hamkorlardan CSV eksportlarini oladi. Tahlil jamoasi sana, mintaqa, mijoz segmenti, mahsulot kategoriyasi va kampaniya bo’yicha so’rov qilinishi mumkin bo’lgan tezkor jadvalni xohlaydi. Shuning uchun bitta biznes hodisasi o’z ma’nosini yo’qotmasdan bir nechta o’zgartirishlardan o’tishi kerak.

Asosiy saboq shundaki, modellashtirish, format tanlash va sifat tekshiruvlari bitta dizayn suhbatidir. Noto’g’ri sxemaga ega Parquet fayli yaxshi ma’lumotlar mahsuloti emas. Tasdiqlanmagan manba yozuvlaridan qurilgan chiroyli yulduz sxemasi ishonchli emas. Aniq tahliliy natijalarsiz normallashtirilgan ma’lumotlar bazasi har bir hisobot savoli uchun ishqalanish yaratadi. Ushbu bob sizga ushbu tanlovlarni ongli ravishda bog’lashni o’rgatadi.

O’quv maqsadlari¶

Ushbu bobning oxiriga kelib, siz tuzilgan (structured), yarim tuzilgan (semi-structured) va tuzilmagan ma’lumotlar (unstructured data) o’rtasidagi farqni tushuntira olishingiz va har biri uchun mos formatlarni tanlay olishingiz kerak. Siz operatsion yaxlitlik uchun normallashtirilgan elektron tijorat mohiyat-munosabat modelini va tahliliy ishlash uchun o’lchamli modelni loyihalashtira olishingiz kerak. Shuningdek, siz CSV va JSON ma’lumotlarini o’qiydigan, asosiy sifat qoidalarini tasdiqlaydigan, Parquet yozadigan va natijani DuckDB bilan so’rov qiladigan kichik konvertatsiya ish oqimini ishga tushira olishingiz kerak.

Konseptual asos: Ma’lumotlar ko’lamdan oldin shaklga ega¶

Yangi boshlanuvchilarning keng tarqalgan xatosi shakl haqida o’ylashdan oldin ko’lam haqida o’ylashdir. Katta ma’lumotlar tizimlari kengayuvchan saqlash va qayta ishlash dvigatellariga muhtoj, ammo birinchi dizayn savoli ancha asosiy: bu qanday ma’lumot va u allaqachon qanchalik tuzilishga ega? Ma’lumotlar muhandislari odatda uchta keng toifa bilan ishlaydi.

Tuzilgan ma’lumotlar oldindan belgilangan sxemaga ega. Relyatsion jadval, elektron jadval yoki boshqariladigan CSV eksporti odatda qatorlar va ustunlarni o’z ichiga oladi, bu yerda har bir ustun kutilgan ma’no va turga ega. Tuzilgan ma’lumotlarni birlamchi kalitlar (primary keys), tashqi kalitlar (foreign keys), yagonalik qoidalari va tur tekshiruvlari kabi cheklovlar bilan tasdiqlash eng oson. Shuningdek, u SQL tahlili uchun tabiiy boshlang’ich nuqtadir.

Yarim tuzilgan ma’lumotlar ichki tashkilotga ega, lekin har doim ham qat’iy jadvalga mos kelmaydi. JSON va XML hujjatlari ko’pincha ichma-ich ob’ektlar, ixtiyoriy maydonlar, massivlar va o’zgaruvchan atributlarni o’z ichiga oladi. Bu yarim tuzilgan ma’lumotlarni API’lar, jurnallar, klik oqimi hodisalari va hujjat ma’lumotlar bazalari uchun foydali qiladi. Moslashuvchanlik qimmatli, ammo u ko’proq mas’uliyatni ma’lumotlar muhandisiga yuklaydi: ichma-ich maydonlar talqin qilinishi, ixtiyoriy maydonlar ko’rib chiqilishi va sxema siljishi aniqlanishi kerak.

Tuzilmagan ma’lumotlar aniq qator-ustun tuzilishiga ega emas. Mahsulot rasmlari, qo’llab-quvvatlash qo’ng’irog’i audiosi, PDF shartnomalari, chat transkriptlari va uzun hujjatlar shu yerga tegishli. Zamonaviy ma’lumotlar platformalarida tuzilmagan ma’lumotlar ko’pincha metama’lumotlarni ajratib olish, matnni tahlil qilish, vektor ifoda (embedding) yaratish, nutqni aniqlash yoki kompyuter ko’rishdan keyin foydali bo’ladi. AI va ML ma’lumotlar muhandisligi bo’yicha keyingi boblar ushbu nuqtaga qaytadi, chunki qidirish bilan kengaytirilgan generatsiya va semantik qidiruv tuzilmagan tarkibni to’g’ri tayyorlashga ko’p jihatdan bog’liq.

Amaliy qoida oddiy: xom dalillarni sodiqlik bilan saqlang, so’ngra foydalanish holatlari uchun kuratorlik qilingan tuzilmalarni yarating. Ma’lumotlar ko’li asl JSON hodisasini saqlab qolishi mumkin, chunki u nosozliklarni bartaraf etish uchun foydali. Ombor toza fact_order_line jadvalini ko’rsatishi mumkin, chunki tahlilchilar barqaror daromad ko’rsatkichlariga muhtoj. Agar har bir qatlam aniq maqsadga ega bo’lsa, ikkalasi ham to’g’ri bo’lishi mumkin.

2.1 Fayl formatlari - bu muhandislik shartnomalari¶

Fayl formati faqat saqlash tafsiloti emas. Bu ishlab chiqaruvchilar, quvurlar, so’rov dvigatellari va quyi oqim foydalanuvchilari o’rtasidagi shartnomadir. Format sxemalar qanday saqlanishi, ma’lumotlar qanchalik samarali skanerlanishi, siqish yaxshi ishlashi va nosozliklarni bartaraf etish qanchalik qiyinligiga ta’sir qiladi.

CSV mashhur, chunki u oddiy va universaldir. Deyarli har qanday vosita uni ocha oladi. Bu afzallik uning zaif tomoni hamdir. CSV sxema ma’lumotlarini ishonchli tarzda tashimaydi, shuning uchun turlar xulosa qilinishi yoki tashqi tomondan belgilanishi kerak. Raqamli bo’lib ko’rinadigan ustun bo’sh satrlar, boshlovchi nollar, mahalliy valyuta ajratgichlari yoki matn kodlarini o’z ichiga olishi mumkin. Shuning uchun CSV kichik eksportlar va o’zaro ishlash uchun foydalidir, ammo u tahliliy ma’lumotlar to’plamlari uchun mo’rt uzoq muddatli saqlash formatidir.

JSON ko’plab API’lar va veb-ilovalarning tabiiy tilidir. U ichma-ich tuzilmalarni CSV’dan ko’ra yaxshiroq ifodalaydi va odamlar uchun tekshirish oson. Biroq, JSON ko’p so’zli, chunki maydon nomlari har bir yozuvda takrorlanadi. Katta JSON to’plamlari odatda JSON Lines sifatida saqlanadi, bu yerda har bir qator bitta JSON ob’ekti bo’ladi, chunki bu oqimli va qatorma-qator qayta ishlashni osonlashtiradi. JSON xom qabul qilish va hodisalarni ushlash uchun ajoyib, ammo tahliliy tizimlar odatda uni tipli jadval formatiga aylantiradi.

Apache Avro - bu sxemalar atrofida ishlab chiqilgan ixcham ikkilik seriyalashtirish formati. Avro hujjatlari Avro’ni boy ma’lumotlar tuzilmalari, ixcham ikkilik ma’lumotlar formati, konteyner fayllari, masofaviy protsedura chaqiruvlari va sxemaga asoslangan qayta ishlashni ta’minlaydigan ma’lumotlarni seriyalashtirish tizimi sifatida tavsiflaydi.^[1] Avro oqimli quvurlarda keng tarqalgan, chunki hodisalar sxemalarni tashishi yoki ularga havola qilishi mumkin, va ishlab chiqaruvchilar hamda iste’molchilar boshqariladigan tarzda rivojlanishi mumkin.

Apache Parquet - bu tahliliy ish yuklari uchun mo’ljallangan ustunli fayl formati. Apache Parquet loyihasi ommaviy fayl formati spetsifikatsiyasini taqdim etadi va DuckDB Parquet fayllarini yuklash va qayta ishlash samarali bo’lgan siqilgan ustunli fayllar sifatida tavsiflaydi.^{[2] [3]} Ustunli saqlash muhim, chunki tahliliy so’rovlar ko’pincha ko’plab qatorlardan bir nechta ustunlarni o’qiydi. Agar so’rovga faqat order_date, region va gross_revenue kerak bo’lsa, ustunli fayl mijoz elektron pochtasi yoki jo’natmani kuzatish raqami kabi aloqador bo’lmagan ustunlarni skanerlashdan qochishi mumkin. DuckDB shuningdek Parquet fayllari uchun o’qish, yozish, sxemani tekshirish, filtrni pastga surish (predicate pushdown) va proyeksiyani pastga surishni qo’llab-quvvatlaydi.^[3]

ORC - bu Hadoop va Hive ekotizimining qismlarida kuchli bo’lgan yana bir ustunli format. Yangi ochiq manbali ko’l-ombor (lakehouse) loyihalarida Parquet ko’pincha keng tarqalgan, chunki u Spark, DuckDB, Trino, pandas, Polars, Delta Lake, Iceberg va ko’plab bulutli so’rov dvigatellari bo’ylab keng qo’llab-quvvatlanadi. Muhim tamoyil bitta format abadiy g’alaba qozonishida emas. Tamoyil formatni ish yuki bilan moslashtirishdir.

Dizayn qoidasi: Odamlar kichik fayllarni tekshirishi yoki almashishi kerak bo’lganda inson o’qiy oladigan formatlardan foydalaning. Mashinalar katta yoki takrorlanadigan ma’lumotlar to’plamlarini ishonchli tarzda qayta ishlashi kerak bo’lganda sxemadan xabardor ikkilik formatlardan foydalaning.

2.2 Qatorga yo’naltirilgan va Ustunga yo’naltirilgan fikrlash¶

Qatorga yo’naltirilgan (row-oriented storage) va ustunga yo’naltirilgan saqlash (columnar storage) o’rtasidagi farq ma’lumotlar muhandisligidagi eng foydali aqliy modellardan biridir. Qatorga yo’naltirilgan saqlashda bitta yozuv uchun qiymatlar birgalikda saqlanadi. Ilova bitta mijoz hisobi yoki bitta buyurtma kabi to’liq biznes ob’ektini o’qiganda yoki yangilaganda bu samarali bo’ladi. Operatsion ma’lumotlar bazalari odatda ushbu namunani afzal ko’radi, chunki tranzaksiyalar kam sonli to’liq yozuvlarga tegadi.

Ustunga yo’naltirilgan saqlashda bir xil ustundagi qiymatlar birgalikda saqlanadi. Tahliliy so’rov ko’plab qatorlarni, lekin faqat bir nechta ustunlarni skanerlaganda bu samarali bo’ladi. Ustunga yo’naltirilgan tartiblar ham yaxshi siqiladi, chunki qo’shni qiymatlar ko’pincha bir xil tur va o’xshash naqshlarni baham ko’radi. Masalan, region qiymatlarini o’z ichiga olgan ustun bir xil bir nechta shahar yoki mintaqa nomlarini ko’p marta takrorlashi mumkin.

Professional platforma ko’pincha bir vaqtning o’zida bir nechta tartiblardan foydalanadi. TuranMart buyurtma tranzaksiyalari uchun PostgreSQL, veb hodisalar uchun JSON, oqimli hodisalar uchun Avro, ko’l-ombor uchun Parquet va BI uchun o’lchamli sxemadan foydalanishi mumkin. Bu mos kelmaslik emas; bu maqsadli ixtisoslashuv.

2.3 Operatsion modellashtirish: Mohiyat-munosabat ko’rinishi¶

Operatsion tizimlar yaxlitlikka muhtoj. Mijoz buyurtma berganda, tizim buyurtma haqiqiy mijozga tegishli ekanligini, har bir buyurtma elementi haqiqiy mahsulotga ishora qilishini, to’lov holati izchil qayd etilishini va jo’natma yangilanishlari qarama-qarshi holatlarni yaratmasligini ta’minlashi kerak. Bu mohiyat-munosabat modellashtirish dunyosi.

Mohiyat o’z shaxsiyatiga loyiq bo’lgan biznes ob’ekti yoki tushunchasidir. Munosabat mohiyatlar qanday bog’lanishini tasvirlaydi. Kardinallik munosabatda qancha yozuv ishtirok etishi mumkinligini tasvirlaydi. TuranMart’da bitta mijoz ko’p buyurtma berishi mumkin, bitta buyurtma ko’p buyurtma elementlarini o’z ichiga olishi mumkin, bitta mahsulot ko’p buyurtma elementlarida paydo bo’lishi mumkin va bitta buyurtma bitta joriy jo’natmaga ega bo’lishi mumkin. Figure 2 dagi ERD soddalashtirilgan operatsion modelni ko’rsatadi.

Yaxshi ER modellashtirish bezak emas. U ishlab chiqarish tizimlarini noaniqlikdan himoya qiladi. Agar orders.customer_id tashqi kalit bo’lsa, buyurtma jimgina mavjud bo’lmagan mijozga ishora qila olmaydi. Agar products.sku yagona bo’lsa, biznes bir xil zaxira saqlash birligiga ega ikkita mahsulot qatoridan qochadi. Agar order_items orders dan ajratilgan bo’lsa, bitta buyurtma mijoz ma’lumotlarini takrorlamasdan ko’plab mahsulotlarni o’z ichiga olishi mumkin.

Normalizatsiya (normalization) operatsion modellarda keraksiz takrorlanishni kamaytirish intizomidir. Normallashtirilgan dizayn har bir faktni bitta mantiqiy joyda saqlaydi. Mijoz elektron pochtasi customers ga tegishli, har bir buyurtmaga ko’chirilmaydi. Mahsulot kategoriyasi products yoki categories ga tegishli, har bir buyurtma elementida qo’lda takrorlanmaydi. Ko’pgina operatsion tizimlar uchun uchinchi normal shaklga yaqin dizayn yaxshi standart hisoblanadi, chunki u yangilash anomaliyalarini kamaytiradi va izchillikni himoya qiladi.

Normalizatsiya bepul emas. Yuqori darajada normallashtirilgan sxemalar bo’yicha tahliliy so’rovlar ko’plab birlashtirishlarni talab qilishi mumkin. Shuning uchun bir xil biznes jarayoni ko’pincha tahlil uchun ikkinchi modelga muhtoj.

2.4 Tahliliy modellashtirish: O’lchamli ko’rinish¶

Tahliliy tizimlar tushunarlilik va so’rov ishlashiga muhtoj. Agar biznes foydalanuvchisi kampaniya va mintaqa bo’yicha daromadni ko’rishni xohlasa, ular beshta jadvalli birlashtirish haqida o’ylamasliklari kerak. Bu o’lchamli modellashtirish dunyosi bo’lib, u ma’lumotlarni biznes jarayonlariga (faktlar) va tavsiflovchi kontekstga (o’lchamlar) ajratadi.^[4]

Faktlar jadvali (fact table) miqdoriy o’lchovlarni saqlaydi. TuranMart’da fact_order_line har bir sotilgan element uchun quantity, gross_revenue va discount_amount ni yozib oladi. O’lchamlar jadvali (dimension table) bu faktlarni filtrlash va guruhlash uchun ishlatiladigan tavsiflovchi atributlarni saqlaydi. dim_customer jadvali segment va region kabi ustunlarni taqdim etadi. O’lchamlar va faktlarni birlashtirish yulduz sxemasini yaratadi.

O’lchamli dizayndagi eng muhim qadam donni aniqlashdir. Don faktlar jadvalidagi bitta qator aynan nimani anglatishini belgilaydi. Agar fact_order_line ning doni “sotilgan bitta mahsulot qatori” bo’lsa, har bir qator aniq bitta miqdor va daromadga ega. Agar don “bitta buyurtma” bo’lsa, unda qator bir nechta mahsulotlarning jami bo’lishi kerak. Ikkala donni bitta faktlar jadvaliga aralashtirish ikki tomonlama hisoblash xatolariga olib keladi. Don jumlasi o’lchovlarni xavfsiz agregatsiya qilish mumkinligini isbotlaydi.

Faktlar jadvallari operatsion tizim kalitlaridan (masalan, order_id) foydalanishi mumkin bo’lsa-da, ular ko’pincha o’zlarining identifikatorlarini, ya’ni surrogat kalitlarni (surrogate keys) yaratadilar. Surrogat kalit - bu ombor tomonidan yaratilgan butun son yoki UUID. U faktlarni o’lchamlarga bog’laydi va tahliliy tizimni operatsion kalit o’zgarishlaridan himoya qiladi. Agar manba tizimi ma’lumotlar bazalarini o’zgartirsa va ID formatlarini o’zgartirsa, ombor surrogat kalitlarni o’zgartirmasdan yangi qatorlarni qo’shishi mumkin. Asl order_id faktlar jadvalida degenerat o’lcham (degenerate dimension) sifatida qoladi - guruhlash uchun foydali bo’lgan, lekin o’z o’lchamlar jadvaliga muhtoj bo’lmagan ID.

2.5 Ma’lumotlar sifati: Modelni isbotlash¶

Ma’lumotlar modeli faqat uni tasdiqlovchi testlar kabi yaxshi. Operatsion ma’lumotlar bazalari sifatni qabul qilish paytida cheklovlar orqali ta’minlaydi. Biroq, ma’lumotlar ko’llari va tahliliy quvurlar ko’pincha tashqi fayllarni o’qiydi yoki oqimlarni iste’mol qiladi, bu yerda cheklovlar bajarilmaydi. Ushbu muhitlarda ma’lumotlar muhandisi o’zgartirishdan oldin sifatni isbotlovchi kod yozishi kerak.

Ma’lumotlar sifati bitta “to’g’ri yoki noto’g’ri” o’lchovi emas. U turli jihatlar bo’ylab baholanadi:^[5]

• Ma’lumotlar to’liqligi: Barcha kutilgan yozuvlar keldimi va barcha majburiy maydonlar to’ldirilganmi? (order_id null emasligini tekshirish).

• Ma’lumotlar yagonaligi: Asossiz takrorlanishlar bormi? (Faktlar jadvalida takroriy order_item_id yo’qligini tekshirish).

• Ma’lumotlar to’g’riligi: Qiymatlar to’g’ri tur, format va ruxsat etilgan diapazonga mos keladimi? (order_status “tugallangan”, “qaytarilgan” yoki “bekor qilingan” ekanligini tekshirish).

• Ma’lumotlar izchilligi: Tegishli yozuvlar bir-biriga mos keladimi? (fact_order_line dagi jami daromad payments dagi jami summaga mos kelishini tekshirish).

• Ma’lumotlar o’z vaqtida yetkazilishi: Ma’lumotlar tahlilchilar kutgan vaqtda yetib keldimi? (Eng so’nggi order_ts so’nggi 24 soat ichida ekanligini tekshirish).

Quvurlar odatda sifat tekshiruvlarini uch bosqichda qo’llaydi, bu ko’pincha bronza-kumush-oltin yoki medalyon arxitekturasi deb ataladi.

1. Bronza (Xom): Ma’lumotlar o’zgarishsiz, asl formatida (CSV, JSON) saqlanadi. Bu audit va quvurni qayta ishga tushirish uchun to’liq kelib chiqishini ta’minlaydi.

2. Kumush (Tozalangan): Ma’lumotlar tipli ustunlarga aylantiriladi, takrorlanishlar olib tashlanadi va yaroqsiz qatorlar karantinga olinadi. Ushbu qatlam ishonchli domen ma’lumotlarini taqdim etadi.

3. Oltin (Biznes): Ma’lumotlar iste’mol qilish uchun yulduz sxemalari, hisobot jadvallari yoki ML belgilari sifatida modellashtiriladi.

Great Expectations yoki dbt testlari kabi ramkalar ushbu tekshiruvlarni ijro etiladigan kod sifatida yozish imkonini beradi.^[6] Yaxshi ma’lumotlar muhandisi qaysi tekshiruv muvaffaqiyatsiz bo’lsa quvurni to’xtatishi kerakligini (masalan, yetishmayotgan daromad) va qaysi tekshiruv shunchaki ogohlantirishi kerakligini (masalan, noodatiy chegirma miqdori) biladi.

Amaliy laboratoriya¶

Xom fayllardan tasdiqlangan Parquet’gacha¶

Ushbu laboratoriyada siz Python, Pandas va DuckDB yordamida kichik konvertatsiya quvurini ishga tushirasiz. Siz TuranMart uchun xom CSV va JSON fayllarini o’qiysiz, turlarni tasdiqlaysiz, sifat tekshiruvlarini qo’llaysiz va so’rov qilinadigan Parquet to’plamini yozasiz.

Sizning vazifalaringiz:

1. Daftarni o’rnating va xom ma’lumotlarni yuklang.

2. Turlarni belgilang va etishmayotgan qiymatlarni ishlating.

3. Asosiy sifat tekshiruvlarini bajaring.

4. Natijalarni Parquet formatida yozing.

5. DuckDB yordamida natijani so’rov qiling.

1-qadam: Xom ma’lumotlarni yuklash¶

Birinchidan, shared/labs/ch02_data_models_formats_quality/input/ dan xom buyurtmalar va hodisalarni o’qiymiz.

import pandas as pd
import json
from pathlib import Path

# Fayl yo'llari
input_dir = Path("../../shared/labs/ch02_data_models_formats_quality/input")
orders_path = input_dir / "csv/orders.csv"
events_path = input_dir / "json/events.jsonl"

# CSV o'qish (Barcha turlar satr sifatida xulosa qilinadi)
df_orders_raw = pd.read_csv(orders_path)
print(f"Loaded {len(df_orders_raw)} raw orders.")

# JSON Lines o'qish
events_data = []
with open(events_path, 'r') as f:
    for line in f:
        events_data.append(json.loads(line))
df_events_raw = pd.DataFrame(events_data)
print(f"Loaded {len(df_events_raw)} raw events.")

2-qadam: Turlarni belgilash va tozalash¶

CSV faylida sanalar matn sifatida mavjud. Biz ularni to’g’ri sana-vaqt ob’ektlariga aylantirishimiz kerak.

# Kumush qatlam o'zgarishlari
df_orders_silver = df_orders_raw.copy()

# Satrlarni vaqt belgilariga o'zgartirish
df_orders_silver['order_ts'] = pd.to_datetime(df_orders_silver['order_ts'])

# Sifat qoidasi: Faqat joriy holatlarni saqlash
valid_statuses = ['completed', 'pending', 'cancelled']
df_orders_silver = df_orders_silver[df_orders_silver['order_status'].isin(valid_statuses)]

print(f"Silver orders after type conversion and filtering: {len(df_orders_silver)}")

3-qadam: Sifat tekshiruvlari¶

Yozishdan oldin, bizning tozalangan ma’lumotlarimiz kutganlarimizga mos kelishini isbotlaymiz.

# Yagonalik tekshiruvi
duplicate_orders = df_orders_silver['order_id'].duplicated().sum()
assert duplicate_orders == 0, f"Quality failure: Found {duplicate_orders} duplicate orders!"

# Null tekshiruvi
null_customers = df_orders_silver['customer_id'].isna().sum()
assert null_customers == 0, f"Quality failure: Found {null_customers} orders without customers!"

print("Quality checks passed. Data is valid.")

4-qadam: Parquet formatida yozish¶

Endi ma’lumotlar tipli va sinovdan o’tgan, biz ularni kelajakdagi tahlil uchun siqilgan Parquet fayllari sifatida yozamiz.

output_dir = Path("../../shared/labs/ch02_data_models_formats_quality/output/parquet")
output_dir.mkdir(parents=True, exist_ok=True)

# Parquet yozish (snappy siqishni sukut bo'yicha ishlatadi)
orders_out = output_dir / "orders_silver.parquet"
df_orders_silver.to_parquet(orders_out, index=False)

print(f"Successfully wrote {orders_out.stat().st_size / 1024:.1f} KB to Parquet.")

5-qadam: DuckDB bilan tasdiqlash¶

Nihoyat, biz natijalarni tahlil qilish uchun Parquet fayllarini to’g’ridan-to’g’ri SQL yordamida o’qiydigan tezkor qator ichidagi tahliliy ma’lumotlar bazasi DuckDB’dan foydalanamiz.

import duckdb

# DuckDB xotiradagi ulanishi
con = duckdb.connect(database=':memory:')

# To'g'ridan-to'g'ri Parquet faylini so'rov qilish
query = f"""
    SELECT 
        order_status,
        COUNT(*) as order_count,
        MIN(order_ts) as earliest_order,
        MAX(order_ts) as latest_order
    FROM '{orders_out}'
    GROUP BY order_status
    ORDER BY order_count DESC;
"""

result = con.execute(query).df()
print("\nDuckDB Query Results:")
print(result)

Kutilayotgan natija: Siz CSV xom matni Parquet faylidagi ustunli turlarga aylanganini ko’rishingiz kerak va DuckDB ma’lumotlarni oldindan yuklamasdan bevosita fayldan agregatsiya qila oladi.

Muhandislik anti-naqshlari¶

Operatsion saboq shundaki, eng erta modellashtirish qarorlari keyingi saqlash, qayta ishlash, orkestratsiya, kuzatuvchilik, boshqaruv va AI ishlari uchun asos bo’ladi. Zaif model zaif quvurlarni yaratadi. Sinovdan o’tmagan kuchli model baribir xavf tug’diradi. Noto’g’ri formatdagi sinovdan o’tgan model ishlash va xarajat muammolarini yaratadi. Professional ma’lumotlar muhandisligi uchalasini ham talab qiladi: ma’no, tuzilma va isbot.

Laboratoriya materiallari¶

Mashqlar¶

Quyidagi mashqlar boshqariladigan laboratoriyani kengaytiradi. Ular bitta to’g’ri javobni ko’chirishdan ko’ra, muhandislik mulohazangizni mashq qilishingiz uchun mo’ljallangan.

Takrorlash savollari¶

Ushbu savollar o’z-o’zini baholash, sinf muhokamasi yoki o’qituvchi ko’rib chiqishi uchun mo’ljallangan. Kuchli javob nafaqat vositani nomlashi, balki mulohazani tushuntirishi kerak.

Xulosa¶

Ushbu bob ma’lumotlar muhandisligining birinchi dizayn lug’atini taqdim etdi. Siz ma’lumotlar ko’lamdan oldin tuzilishga ega ekanligini va tuzilgan, yarim tuzilgan hamda tuzilmagan ma’lumotlar turli xil ishlashni talab qilishini o’rgandingiz. Siz CSV, JSON, Avro, Parquet va ORC’ni ajratilgan fayl kengaytmalari sifatida emas, balki muhandislik shartnomalari sifatida taqqosladingiz. Siz operatsion yaxlitlik uchun normallashtirilgan ERD va tahliliy foydalanish qulayligi uchun o’lchamli yulduz sxemasini loyihalashtirdingiz. Nihoyat, siz ushbu g’oyalarni sifat tekshiruvlari va xom fayllarni tasdiqlangan Parquet’ga aylantiradigan boshqariladigan laboratoriya bilan bog’ladingiz.

Keyingi bob ma’lumotlar dizaynidan kengroq ochiq manbali ekotizimga o’tadi. Siz ma’lumotlar bazalari, ob’ektli saqlash, qayta ishlash dvigatellari, orkestratsiya vositalari, sifat ramkalari, kataloglar va daftarlar qanday qilib amaliy platformaga birlashishini o’rganasiz. 2-bob sizga oldinga olib borish uchun asosiy savolni beradi: ma’lumotlar qanday ma’noni saqlab qolishi kerak va tizim uni saqlab qolganini qanday isbotlaydi?

Adabiyotlar¶