Lakehouse tətbiqləri nadir hallarda arxitekturaya görə uğursuz olur. Onlar səkkiz əməliyyat reallığına görə sınır: sorğuları pisləşdirən kiçik fayllar, datanın gəlişinə görə seçilmiş partition-lar, catalog adlanan iki fərqli şeyin qarışdırılması, mənbələrdən gələn sxem sürüşməsi, anbar vedrəsində dayanan giriş nəzarəti, paralellik sürprizləri, heç vaxt bitməyən ikili iş rejimi və platformanın sahibinin olmaması.

Səkkizi də məlumdur, səkkizindən də yayınmaq olar və səkkizi də birinci yox, ikinci rübdə üzə çıxır — buna görə pilot yaxşı görünür, yayılma isə yox.

Pilot niyə həmişə yaxşı görünür?

Çünki pilotda bir iş yükü, bir neçə cədvəl, bir komanda və kiçik data həcmi var. Aşağıdakı hər problem miqyasın, rəngarəngliyin və ya zamanın funksiyasıdır, pilotda isə bunların heç biri yoxdur.

Bu, pilota qarşı arqument deyil. Bu, pilota arxitekturanın testi kimi baxmaq və yalnız sonra üzə çıxan əməliyyat reallıqlarını açıq planlaşdırmaq üçün arqumentdir. Bu riski məntiqli paylayan qurma ardıcıllığı müasir data platforması qurmaq məqaləsindədir.

Çətinlik 1 — kiçik fayllar problemi

Yeni lakehouse-da ən çox rast gəlinən performans uğursuzluğu və sorğular sürünməyə başlayana qədər görünmür.

Streaming ingestion, tez-tez baş verən CDC mikro-batch-ları və partition başına yazılar çoxlu kiçik fayl doğurur. Sorğu mühərrikləri hər fayla görə sabit xərc ödəyir — onu açmaq, altlığını oxumaq, ətrafında plan qurmaq — ona görə 400 min kiçik fayla bölünmüş cədvəl eyni datanın bir neçə min düzgün ölçülü faylda saxlanmasından qat-qat pis işləyir, baytlar eyni olsa da.

Həlli. Compaction-ı kimsə şikayət edəndə yox, ilk gündən qrafikə salın. Açıq table format-lar compaction və faylların yenidən yazılması əməliyyatları verir; onlar orchestrator-da qalan baxım işləri ilə birlikdə qrafikli işlər olmalıdır. Hədəf fayl ölçüsü ingestion-un təbii olaraq verdiyi kilobaytlar yox, yüzlərlə meqabayt olmalıdır.

Tələnin içindəki tələ. Compaction klaster tutumu uğrunda ingestion ilə rəqabət aparır, ona görə ona pəncərə və resurs ayrılmalıdır. Compaction-ı onun xərcini nəzərə almadan qrafikə salan komandalar hər gecə ingestion gecikməsinin böyüdüyünü kəşf edir.

Çətinlik 2 — datanın gəlişinə görə partition

İkinci ən çox rast gəlinən və düzəldilməsi daha bahalı olan.

Data tarix üzrə gəlir, deməli cədvəl tarix üzrə partition olunur. Sonra isə real sorğular müştəriyə, filiala, məhsula görə süzür — və hər sorğu bütün partition-ları skan edir. Mövcud ən böyük performans qolu olan partition pruning heç nə etmir.

Həlli. Real sorğulardakı predikatlara görə partition edin. Bu, həmin sorğuların nə olduğunu bilməyi tələb edir — anbar miqrasiyasından əvvəl federativ sorğu girişini qoyan qurma ardıcıllığının praktiki arqumenti də budur: bir rüblük real sorğu tarixçəsi necə partition edəcəyinizi deyir, təxmin isə demir.

İki rəqib giriş şablonu olan cədvəllər üçün Iceberg-in gizli partition-ı və partition təkamülü səhv etməyin qiymətini azaldır, çünki partition sxemi hər sorğunu yenidən yazmadan dəyişə bilir. Bu çeviklik formatı seçmək üçün səbəbdir, təhlili atlamaq üçün yox.

Nə etməməli: həddən artıq partition. Müştəri və gün üzrə partition milyonlarla xırda partition doğurur, bu isə kiçik fayllar problemini üstünə metadata partlayışı da əlavə edərək yenidən yaradır.

Çətinlik 3 — catalog adlanan iki fərqli şey

Planlaşdırma görüşlərində real qarışıqlıq mənbəyidir və açıq ayrılmağa dəyər, çünki hər ikisi lazımdır və bir-birini əvəz etmirlər.

Texniki catalog — Iceberg və ya Hive metastore, ya da ekvivalenti — mühərriklərə hansı cədvəllərin mövcud olduğunu, fayllarının harada durduğunu və cari snapshot-un nə olduğunu deyir. Bu, infrastrukturdur. Onsuz mühərrik cədvəli oxuya bilmir.

Biznes catalog — governance mənasında data catalog — cədvəlin nə demək olduğunu, sahibinin kim olduğunu, necə təsnifləndiyini və necə axdığını saxlayır. Bu, operating model alətidir. Onsuz platforma sənədsizdir.

«Bizdə onsuz da catalog var» deyib metastore-u nəzərdə tutan komandalar sonda texniki cəhətdən işləyən, amma heç kimin naviqasiya edə bilmədiyi lakehouse ilə qalır. Fərq və biznes qatının nə verdiyi data catalog nədir məqaləsindədir; bu layihələrdə onu verən komponent isə OvalEdge-dir.

Çətinlik 4 — mənbələrdən gələn sxem sürüşməsi

Lakehouse cədvəlinin sxemi var. Mənbə sistemi isə heç kimə demədən öz sxemini dəyişir, çünki mənbə komandasının analitik qatın mövcudluğundan xəbər tutmaq üçün heç bir səbəbi yoxdur.

Açıq table format-lar sxem təkamülünü səliqəylə həll edir — sütun əlavə etmək, tipi genişləndirmək — bu, həqiqətən dəyərlidir. Həll edə bilmədikləri semantik sürüşmədir: mənası dəyişmiş status kodu, fərqli doldurulmağa başlayan sahə, konvensiyasını səssizcə dəyişmiş valyuta sütunu. Pipeline uğurla bitir, rəqəmlər səhv olur və bir rüb ərzində heç kim görmür.

Həlli üç hissədən ibarətdir.

İnterfeysi razılaşdırın. Mənbə komandası hansı sahələrin aşağı axında istehlak olunduğunu bilməlidir. Bu, texnologiya yox, söhbətdir və mövcud ən yüksək dəyərli söhbətdir.

Sürüşməni avtomatik aşkarlayın. Kritik sütunlarda paylanma yoxlamaları sxem yoxlamalarının buraxdığı semantik dəyişikliyi tutur — yeni dəyəri olan status kodu, null nisbəti sıçrayan sahə, diapazonu sürüşən ədədi sütun.

Dəyişikliyi təsir təhlilindən keçirin. Sütun səviyyəli lineage mənbə dəyişikliyini sonra yox, çıxmazdan əvvəl təsirlənən hesabatların görünən siyahısına çevirir — tənzimlənən sahələr üçün governance təcrübələri məqaləsində təsvir olunan mexanizm budur.

Çətinlik 5 — vedrədə dayanan giriş nəzarəti

Obyekt anbarı icazələri kobuddur: subyekt vedrəni və ya prefiksi oxuya bilir. Analitik giriş nəzarəti isə incə olmalıdır: bu istifadəçi bu sətirləri görə bilər, bu sütun isə maskalanır.

Komandalar bunu tez-tez gec kəşf edir — anbar səviyyəli icazələr üstəgəl sorğu mühərrikinin giriş nəzarətinə bərabər olduğunu güman edərək. Əldə etdikləri isə bütöv cədvəllərə «ya hamısı, ya heç nə» girişidir, keçici həll — istifadəçi qrupu üzrə süzülmüş kopyalar yaratmaq — isə lakehouse-un aradan qaldırmalı olduğu təkrarlanmanı yenidən gətirir.

Həlli. Giriş nəzarətini sorğu mühərrikində tətbiq edin — sətir və sütun səviyyəli siyasətin ifadə olunub həm lakehouse cədvəllərində, həm federativ mənbələrdə ardıcıl tətbiq olunduğu yerdə. Tənzimlənən qurumlar üçün Starburst-un açıq mənbəli Trino üzərinə həlledici əlavəsi budur; bu, Starburst və Trino Azərbaycanda məqaləsində açılıb. Anbar icazələri isə istifadəçiyə baxan nəzarət yox, mühərrikin xidmət kimliyi üçün kobud müdafiə olur.

Yanaşı tələ: birbaşa anbar girişi. İstifadəçilər Spark-ı vedrəyə yönəldə bilirsə, mühərriki və onun siyasətlərini keçirlər. Bu yolun mövcud olub-olmaması arxitektura qərarıdır və kəşf edilmək yox, şüurlu verilmək lazımdır.

Çətinlik 6 — paralellik və pilota görə ölçülmüş klaster

Pilotda beş istifadəçi var. İstehsalatda iki yüz, yarısı isə hər panel yenilənməsində onlarla sorğu göndərən BI aləti işlədir.

Sorğu mühərrikləri birləşdirmə və aqreqasiyalarda yaddaşla məhdudlaşır və paralellik təzyiqi altında uğursuzluq mülayim pisləşmə deyil — yaddaş bitəndə sorğuların birbaşa sınmasıdır. Klasteri pilot yükünə görə ölçən komandalar bunu maliyyə departamenti qoşulan gün kəşf edir.

Həlli. Bir klasteri böyütmək əvəzinə işləri ayırın: interaktiv sorğular, qrafikli hesabatlıq və ağır ad-hoc təhlil üçün resurs qrupları və ya ayrı klasterlər — beləliklə bir analitikin dekart birləşməsi səhər panel yükünü yıxa bilmir. Təkrarlanan sorğu şablonlarını cache-ləyin; BI yüklərində bunlar sorğuların çoxudur. Və pik paralelliyə görə ölçün — praktikada bu, iş gününün başlamasından sonrakı on beş dəqiqədir.

Çətinlik 7 — heç vaxt bitməyən miqrasiya

Nəzərdə tutulan ardıcıllıq belədir: yeni qatı qur, yükləri köçür, köhnə warehouse-u söndür. Müşahidə olunan ardıcıllıq isə budur: yeni qatı qur, asan yükləri köçür, ikisini müddətsiz işlət.

İkili iş rejiminin real qiyməti var — iki platforma, iki dəst pipeline, iki giriş modeli və hansı sistemin səlahiyyətli olduğuna dair daimi sual. Bu ona görə baş verir ki, yüklərin son 20 faizi çətinləridir, onların köçürülməsinin sahibi yoxdur və köhnə platforma işləməkdə davam edir.

Həlli təşkilatidir. Köçürüləcək yükləri əvvəldən adbaad sadalayın, hər birinə sahib və tarix təyin edin. Köhnə platforma üçün söndürmə tarixi qoyun və nəticə kimi yeni platformanı yox, məhz onu götürün. Ən çətin yükü isə sona yox, üçüncü-dördüncü köçürün — sona saxlamaq onun son tarix təzyiqi altında və artıq heç bir həvəs qalmadan cəhd ediləcəyinə zəmanət verir.

Çətinlik 8 — platformanın sahibi yoxdur

Lakehouse idarə olunan warehouse-dan çox komponentdir: obyekt anbarı, table format, metastore, sorğu mühərriki, orchestrator, catalog. Hər biri sadədir; cəminin sahibi lazımdır.

Uğursuzluq forması istismara verildikdən sonra dağılan layihə komandasının qurduğu platformadır. Altı ay sonra heç kim compaction işlətməyib, metastore sağlamlığını itirib, heç nə yenilənməyib və sorğu performansı istifadəçilərin yenidən çıxarışlara qayıtdığı həddə düşüb.

Həlli. Platforma məqsədlərində yazılmış iki adlı platforma mühəndisi, compaction-ı, snapshot müddətini, metastore baxımını və yeniləmələri əhatə edən sənədləşdirilmiş əməliyyat runbook-u və istifadəçilər fərqinə varmadan xəbər verən monitorinq. Bu, istinad arxitekturasının ən çox əskik olduğunu qeyd etdiyi altıncı roldur.

On-premise-də nə fərqlidir?

Yukon Labs-ın burada apardığı tətbiqlərdə üç əlavə reallıq var.

Tutum məhduddur və satınalma yavaşdır. Bulud komandaları pis partition strategiyasını miqyası artırmaqla udur. On-premise-də zəif sorğu səmərəliliyi dərhal hiss olunur, avadanlıq əlavə etmək isə satınalma dövrüdür. Bu, partition və compaction-ı erkən düzgün etməyin gəlirini artırır.

Obyekt anbarını siz işlədirsiniz. İdarə olunan xidmət yox, MinIO və ya Ceph — yəni erasure coding, yenidən balanslaşdırma və disk sıradan çıxmasının idarəsi sizin əməliyyat məsuliyyətinizdir.

Yeniləmələr nəzarətli prosesdir. Air-gapped mühitdə mühərrik və konnektor yenilikləri proqram təminatı üçün onsuz da mövcud olan nəzarətli yoldan artefakt kimi gəlir. Həmin yolu əvvəldən razılaşdırın; təhlükəsizlik yaması ilk dəfə lazım olan an onu dizayn etmək üçün ən pis andır.

Bunların heç biri on-premise-ə qarşı arqument deyil — buradakı nəzarət altındakı qurumların çoxu üçün bu, üstünlük yox, məhdudiyyətdir və mühakiməsi suveren AI məqaləsindədir. Bunlar əməliyyat tərəfini arxitektura ilə eyni ciddiliklə planlaşdırmaq üçün arqumentdir.

Əsas məqamlar

  • Buradakı hər problem miqyasın, rəngarəngliyin və ya zamanın funksiyasıdır, ona görə heç biri pilotda görünmür.
  • Compaction-ı ilk gündən, öz pəncərəsi və resurs ayrılması ilə qrafikə salın.
  • Real sorğu predikatlarına görə partition edin. Onların nə olduğunu miqrasiyadan əvvəlki federativ sorğu girişi deyir.
  • Texniki metastore ilə biznes catalog-u ayırın. Hər ikisi lazımdır və biri digərini əvəz etmir.
  • Semantik sxem sürüşməsini paylanma yoxlamaları ilə tutun; sxem yoxlamaları onu tamamilə buraxır.
  • İncə giriş nəzarətini sorğu mühərrikində tətbiq edin və birbaşa anbar girişinin mövcudluğunu şüurlu qərara alın.
  • Paralellik məsələni məcbur etməzdən əvvəl interaktiv, qrafikli və ad-hoc yükləri ayırın.
  • Köhnə platforma üçün söndürmə tarixi qoyun və ən çətin yükü sona yox, erkən köçürün.

Yukon Labs Azərbaycanda lakehouse platformalarını on-premise tətbiq edir — sorğu qatında Starburst, governance üçün OvalEdge, əməliyyat runbook-u daxil olmaqla. Arxitekturanın özü üçün data lakehouse arxitekturası və müasir data platforması qurmaq; keçidi doğuran səbəblər üçün isə müəssisələr niyə lakehouse-a keçir məqaləsinə baxın.