Data lake — katta hajmdagi strukturali, yarim strukturali va strukturasiz ma’lumotlarni asl yoki qayta ishlangan ko‘rinishda markaziy, odatda arzon va kengayuvchi storage’da saqlash arxitekturasi. U analytics, machine learning, audit va qayta ishlash workloadlari uchun turli manbalarni bir joyga yig‘adi.
Storage va compute ajratilishi
Zamonaviy data lake ko‘pincha object storage ustida quriladi. Fayllar Parquet, ORC, Avro, JSON, CSV, rasm yoki boshqa formatda bo‘lishi mumkin. Compute engine storage’dan alohida scale qilinadi: Spark, SQL query engine yoki ML platforma ayni data ustida turli ish bajaradi.
Bu ajratish resurs elastikligini beradi, ammo storage fayllari o‘z-o‘zidan database transaction va schema qoidalarini ta’minlamaydi. Metadata catalog dataset joylashuvi, schema, partition, owner va lineage’ni saqlaydi.
Zonalar
Raw yoki landing zona manbadan kelgan data’ni minimal o‘zgarish bilan saqlaydi. Clean/curated zona validatsiya, deduplication va standard formatdan o‘tgan ma’lumotni beradi. Serving yoki gold zona aniq hisobot va ML featurelar uchun tayyorlangan datasetlarni o‘z ichiga oladi.
Zona nomlari standart emas, lekin ular orasidagi sifat va access chegarasi aniq bo‘lishi kerak. Raw data’ni barcha analystlarga ochish sensitive maydon va noto‘g‘ri interpretatsiya xavfini oshiradi.
Schema va table formatlari
Schema-on-read foydalanuvchiga data’ni o‘qishda struktura berish imkonini beradi. Bu moslashuvchan, ammo bir xil ustun turli joblarda turlicha talqin qilinishi mumkin. Contract, schema registry va validation o‘zgarishni boshqaradi.
Apache Iceberg, Delta Lake va Apache Hudi kabi table formatlari object storage fayllari ustiga transactionga yaqin commit, snapshot, schema evolution va partition metadata qo‘shadi. Ular bir xil implementatsiya emas; engine compatibilitysi va concurrency semantikasi tekshiriladi.
Partition va fayl hajmi
Data sana, tenant yoki boshqa tez filtrlanadigan kalit bo‘yicha partition qilinadi. Juda mayda partitionlar metadata va listing xarajatini oshiradi, juda yirik partition esa keraksiz scan keltiradi. Yuqori cardinalityli user IDni to‘g‘ridan-to‘g‘ri partition kaliti qilish millionlab katalog yaratishi mumkin.
Small files muammosi query planning, object request va metadata overheadini oshiradi. Compaction ko‘p kichik faylni optimal kattalikdagi ustunli fayllarga birlashtiradi. Bu jarayon concurrent writer va snapshot retention bilan moslashadi.
Governance va xavfsizlik
Data lake nazoratsiz fayl omboriga aylansa “data swamp” hosil bo‘ladi. Har dataset owner, tavsif, schema, freshness, quality metric, lineage va retentionga ega bo‘ladi. Catalog qidiruvni, policy engine esa column/row-level accessni ta’minlaydi.
Encryption va IAM bilan birga sensitive data classification, masking va audit qo‘llanadi. Delete talabi barcha replica, snapshot va derived datasetlarga yetishi kerak. Faqat objectni o‘chirish catalog yoki cache’dagi izni avtomatik tozalamaydi.
Ishonchlilik va xarajat
Pipeline late-arriving, duplicate va corrupt eventlarni idempotent qayta ishlaydi. Data quality null ulushi, unique kalit, referential moslik va freshness orqali o‘lchanadi. Reprocessing eski natijani nazoratli almashtiradi.
Storage arzon bo‘lsa ham scan, egress, catalog va compute xarajati katta bo‘lishi mumkin. Columnar format, partition pruning, compression va lifecycle tiering yordam beradi. Dataset foydalanilmasa retention bo‘yicha archive yoki delete qilinadi; “keyin kerak bo‘lar” deb cheksiz saqlash compliance va xarajatni oshiradi.
Bog‘liq tushunchalar
Object storage, Data warehouse, Metadata catalog, Data lineage, Apache Iceberg, Parquet, ETL, Lakehouse