Starburst analitikanı necə sürətləndirir: pushdown, caching və indeksləmə

Federativ sorğu performansı dörd mexanizmdən gəlir: süzgəcləri və aqreqasiyaları mənbə sisteminə itələmək ki, az data hərəkət etsin; mənbələrdən bir bağlantı ilə yox, paralel oxumaq; təkrar sorğulananı cache-ləmək; və uyğun gələ bilməyən datanı ümumiyyətlə oxumamaq. Yavaş sorğunu sürətli edən şey bunlardan hansının işləmədiyini anlamaqdır.

Hamısının arxasındakı sual eynidir: cavabın ehtiyacı olmayan baytları şəbəkədən keçirməkdən necə yayınmaq olar?

Federativ sorğunu əslində nə yavaşladır?

Real tətbiqlərdə tezliyinə görə azalan sıra ilə dörd səbəb.

Şəbəkədən həddən artıq data keçir. Süzgəc mənbədə tətbiq olunmadığı üçün mühərrik bütöv cədvəli çəkib. Bu, üstünlük təşkil edən səbəbdir və pushdown məhz bunu həll edir.

Təkbaşına, tək saplı oxuma yolu. Mənbə datanı bir JDBC bağlantısının daşıya biləcəyindən sürətli verə bilir, ona görə darboğaz iki uc yox, borudur.

Təkrarlanan iş. Dəyişməmiş data üzərində eyni aqreqasiya hər panel yenilənməsində yenidən hesablanır.

Pis plan. Optimallaşdırıcı əsaslanacaq statistikası olmadığı üçün səhv birləşdirmə sırasını və ya strategiyasını seçib.

Yalnız dördüncüsü həqiqətən mühərriklə bağlıdır. İlk üçü datanın hərəkəti ilə bağlıdır — federativ performansın əsasən datanı hərəkət etdirməmək məşqi olmasının səbəbi də budur.

Pushdown nədir və nə itələnə bilər?

Pushdown sorğunun bir hissəsini mühərrikdə yox, mənbə sisteminin içində icra etmək deməkdir. Trino bunu konnektor üzrə həyata keçirir, Starburst isə daha da genişləndirir, çünki nəyin itələnə biləcəyi mənbənin nə edə bildiyindən asılıdır.

Predicate pushdown. WHERE şərti mənbədə icra olunur. Bir aylıq tranzaksiyaya süzən sorğu beş illik yox, bir aylıq data köçürür. Mövcud ən böyük qol budur və onun işləməməsi yavaş federativ sorğunun ən çox rast gəlinən səbəbidir.

Projection pushdown. Yalnız istənilən sütunlar oxunur. Geniş cədvəldə təkcə bu, köçürülən baytları on dəfələrlə azalda bilər — SELECT *-ın lokal bazaya nisbətən burada niyə bahalı olduğunun səbəbi də budur.

Aggregate pushdown. COUNT, SUM, GROUP BY mənbənin bacardığı yerdə mənbədə icra olunur, ona görə mühərrik xam sətirlər yox, qruplaşdırılmış nəticələr alır. Milyonlarla sətri bir neçə yüz qrupa yığan sorğuda bu, saniyələrlə dəqiqələr arasındakı fərqdir.

Join pushdown. Birləşdirmənin hər iki tərəfi eyni mənbədə yaşayırsa, birləşdirmə orada icra olunur. Mənbələrarası birləşdirmələr zəruri olaraq mühərrikdə baş verir — federasiya elə budur — amma eyni mənbədəki birləşdirmələr mənbədən heç vaxt çıxmamalıdır.

Limit və TopN pushdown. LIMIT və ORDER BY ... LIMIT mənbədə icra olunur; bu, analitiklərin daim işlətdiyi kəşfiyyat sorğuları üçün əhəmiyyətlidir.

Pushdown-u nə bloklayır — praktiki hissə budur: mənbənin dəstəkləmədiyi funksiya, konnektorun ifadə edə bilmədiyi tip çevrilməsi, xam sütun əvəzinə hesablanmış sütuna qarşı yazılmış süzgəc, ya da registr həssaslığı uyğunsuzluğu. Sorğu gözlənilmədən yavaş işləyəndə ilk diaqnostik addım predikatın həqiqətən itələnib-itələnmədiyini yoxlamaqdır və bu, sorğu planında görünür.

Ənənəvi bazalar üçün paralel oxuma niyə hər şeydən vacibdir?

İnsanların gözləmədiyi darboğaz. Bir JDBC bağlantısının ötürmə tavanı ciddi bazanın verə biləcəyindən xeyli aşağıdır; yaxşı tənzimlənmiş Oracle və ya SQL Server nüsxəsi datanı bir bağlantının daşıya biləcəyindən nəzərəçarpacaq dərəcədə tez istehsal edə bilir.

Starburst bunu mənbə başına paralel JDBC bağlantıları ilə həll edir — fərqli partition-ları və ya açar diapazonlarını eyni anda oxuyub nəticəni yenidən yığmaqla. Köhnə relyasion mənbələrin federasiyası üçün — core banking və ERP mühitlərinin çoxu belədir — bu, tez-tez açıq mənbəli Trino ilə kommersiya distribusiyası arasındakı ən böyük performans fərqidir.

Praktiki tələb ağlabatan bölmə açarıdır: partition sütunu, ədədi ilkin açar diapazonu və ya tarix. Belə açar olmadan mühərrik təhlükəsiz paralelləşdirə bilmir, ona görə sxem bilikləri birbaşa ötürmə qabiliyyətinə çevrilir.

Caching əslində nəyi cache-ləyir?

Üç fərqli şeyə caching deyilir və onları qarışdırmaq tənzimləmə söhbətlərini dolaşdırır.

Nəticə cache-i. Sorğunun nəticəsi saxlanılır və eyni sorğu təkrarlananda qaytarılır. Panellər üçün son dərəcə effektivdir, çünki eyni sorğu hər yenilənmədə hər baxan üçün işə düşür. Düzgünlük məhdudiyyəti altdakı datanın nə vaxt dəyişdiyini bilməkdir, ona görə nəticə cache-i cədvəlin yenilənmə ritminə uyğun təzəlik pəncərəsi ilə konfiqurasiya olunur.

Data cache-i. Uzaq mənbələrdən tez-tez oxunan data hesablama qatına yaxın saxlanılır, ona görə eyni kəsim üzrə təkrar sorğular mənbədən yenidən çəkilmir. Yavaş və ya uzaq mənbəni interaktiv istifadə üçün dözülən edən mexanizm budur və o, əməliyyat sistemlərinin yükünü azaldır — məhdudiyyətin sorğu gecikməsi yox, mənbəyə təsir olduğu bankda çox vaxt daha vacib fayda elə budur.

Metadata cache-i. Cədvəl və partition metadata-sı təkrar catalog müraciətlərindən yayınmaq üçün cache-lənir. İşləyəndə görünmür, işləməyəndə isə xüsusən çoxlu partition-ı olan mənbələrdə ciddi xərcdir.

Tənzimləmə prinsipi budur: yavaş dəyişən data üzərində təkrar sorğulananı cache-ləyin və cari olmalı olanı heç vaxt cache-ləməyin. Bunu təhlükəsiz istiqamətdə səhv etmək — az cache-ləmək — performansa başa gəlir; təhlükəli istiqamətdə səhv etmək isə inamla köhnəlmiş rəqəmlər doğurur, bu isə pisdir.

Materiallaşdırılmış görünüşlər nə vaxt özünü ödəyir?

Materiallaşdırılmış görünüş sorğu nəticəsini əvvəlcədən hesablayıb saxlayır və qrafiklə yeniləyir. Konkret və tanına bilən şablon üçün doğru cavabdır: altdakı data dəyişdiyindən qat-qat tez sorğulanan bahalı aqreqasiya, dəqiqələrlə köhnə nəticələrin qəbul edildiyi yerdə.

Klassik hal panellərin arxasındakı sorğulardır. Böyük fakt cədvəli üzərində gündəlik həcm aqreqasiyası — hər on beş dəqiqədən bir yenilənən və iki yüz istifadəçiyə verilən — materiallaşdırılmış görünüş kimi iki yüz dəfə yenidən hesablanmaqdan qat-qat ucuzdur.

Nə vaxt özünü ödəmir: onsuz da sürətli olan sorğular, sorğulandığı qədər tez dəyişən data və ən əsası — partition-un düzəldilməsinin əvəzi kimi. Pis partition edilmiş cədvəl üzərində materiallaşdırılmış görünüş problemi gizlədir, əvəzində isə hər ay yavaşlayan yenilənmə işi verir.

Gizli xərc ondadır ki, hər materiallaşdırılmış görünüş baxım öhdəliyidir. Yenilənmə işləri tutum yeyir, arabir sınır və yığılır. Heç kimin nəzərdən keçirmədiyi altmış materiallaşdırılmış görünüşü olan platforma daimi vergi daşıyır; ildə bir dəfə baxmaq — keyfiyyət qaydalarında olduğu kimi — bunun qarşısını alan intizamdır.

Lakehouse-da data skipping nə edir?

Lakehouse cədvəlləri üçün indeksin qarşılığı mühərrikə faylları oxumamağa imkan verən metadata-dır.

Partition pruning. Mühərrik yalnız süzgəcə uyğun gələ bilən partition-ları oxuyur. Lakehouse sorğu performansında ən böyük tək qol budur və o, yalnız partition sxemi sorğu predikatlarına uyğun gələndə işləyir — giriş şablonu yerinə gəliş sırasına görə partition etməyin niyə bu qədər bahalı səhv olduğunun səbəbi də budur; lakehouse tətbiqinin çətinlikləri məqaləsində açılıb.

Fayl səviyyəli statistika. Açıq table format-lar sütunlar üçün fayl başına minimum və maksimum dəyərləri qeyd edir. Maksimum tarixi süzgəcin başlanğıc tarixindən əvvəl olan fayl ümumiyyətlə açılmadan atlanır.

Sütun yönümlü saxlama. Parquet və ORC sütunları ayrıca saxlayır, ona görə projection pushdown sorğunun toxunmadığı sütunları anbar qatında atlayır.

Sıralama və klasterləşdirmə. Tez-tez süzülən sütuna görə fiziki sıralanmış data fayl səviyyəli statistikanı daha seçici edir. Yazarkən sıralamaq yazma sürətinə başa gəlir və hər sonrakı oxumada özünü qaytarır.

Optimallaşdırıcıya sizdən nə lazımdır?

Starburst-un xərcə əsaslanan optimallaşdırıcısı birləşdirmə sırasını, strategiyasını və paylanmasını təxmin edilən kardinallıqlara görə seçir. Dəqiq statistika ilə yaxşı seçimlər edir; onsuz təxmin edir, çoxmənbəli sorğuda səhv birləşdirmə sırası isə dəfələrlə baha başa gələ bilər.

Buradan iki praktiki öhdəlik çıxır. Lakehouse cədvəllərində statistikanı aktual saxlayın — statistikanın toplanması compaction ilə yanaşı duran qrafikli baxım işidir. Və nəzərə alın ki, federativ mənbələrdən gələn statistikanın keyfiyyəti dəyişir: bəzi konnektorlar mənbənin öz statistikasını verir, bəziləri az şey verir; az verdiyi yerdə optimallaşdırıcı birləşdirmənin həmin tərəfində kor işləyir.

Kritik sorğu pis planlaşdırılırsa və statistika bunu düzəltmirsə, sorğunun yenidən qurulması qanuni cavabdır.

Yavaş sorğunun diaqnozu necə qoyulur?

Halların çoxunu tez həll edən ardıcıllıq.

Əvvəlcə planı oxuyun. O, hansı əməliyyatların mənbələrə itələndiyini və hansının mühərrikdə işlədiyini göstərir. Mühərrikdə gözlənilməz tam skan predikatın itələnmədiyini bildirir — səbəbini tapın.

Mənbə üzrə köçürülən baytları yoxlayın. Bir neçə yüz sətir qaytaran sorğuya giqabaytlarla töhfə verən mənbə aqreqasiyanı səhv yerdə edir.

Oxumanın paralelləşdiyini yoxlayın. Böyük cədvələ qarşı tək split bölmə açarının olmadığını və ya konfiqurasiya edilmədiyini bildirir.

Vaxtın paylanmasına baxın. Bir yavaş mənbəni gözləməyə sərf olunan vaxt mühərrik yox, mənbə problemidir və mühərrikə tutum əlavə etmək kömək etməyəcək.

Yalnız bundan sonra klaster resurslarını düşünün. Resurs çatışmazlığı realdır, amma ən sonda diaqnoz qoyulur, çünki ən bahalı və ən az doğru çıxan cavabdır.

Praktikada tənzimləmə necə gedir?

Buradakı layihələrdə tənzimləmə sabit ardıcıllıqla gedir və gəlir tez azalır.

Birinci, ümumi icra vaxtına görə ilk iyirmi sorğuda pushdown-u düzəldin. Bunlar demək olar həmişə panel və hesabat sorğularıdır. Bu yükdə Pareto paylanması kəskindir — bir neçə sorğu klaster vaxtının böyük hissəsini tutur.

İkinci, relyasion mənbələrdə paralel oxumanı konfiqurasiya edin. Böyük cədvəllərdə bölmə açarları, DBA-nın qəbul edəcəyi həddə ölçülmüş bağlantı sayı.

Üçüncü, panel qatını cache-ləyin. Hər cədvəlin yenilənmə ritminə uyğun təzəlik pəncərəsi ilə nəticə cache-i.

Dördüncü, bahalı qalan iki-üç aqreqasiyanı materiallaşdırın. Yığılmamaları üçün qrafikli baxışla birlikdə.

Beşinci, ən böyük lakehouse cədvəllərində partition-a yenidən baxın — güman yox, real sorğu tarixçəsi əsasında.

Klasterin ölçülməsi bunların hamısından sonra gəlir, çünki resursu çatmayan görünən klasterlərin çoxu lazımsız iş görür. Federasiyanın arxitektura kimi geniş arqumenti, o cümlədən dürüst məhdudiyyətləri Starburst və Trino Azərbaycanda, digər mühərriklərlə müqayisə isə Starburst, Dremio və Databricks SQL məqaləsindədir.

Əsas məqamlar

• Federativ performans əsasən datanı hərəkət etdirməməkdir. Pushdown, paralel oxuma, caching və skipping köçürmədən yayınmağın dörd yoludur.
• Predicate, projection və aggregate pushdown ən böyük qollardır. Sorğu yavaşdırsa, pushdown-un həqiqətən baş verib-vermədiyini görmək üçün əvvəlcə plana baxın.
• Köhnə relyasion mənbələr üçün ən böyük fərq tez-tez paralel JDBC oxumadır və ona ağlabatan bölmə açarı lazımdır.
• Nəticə, data və metadata cache-lərini ayırın. Yavaş dəyişən data üzərində təkrar sorğulananı cache-ləyin; cari olmalı olanı heç vaxt.
• Materiallaşdırılmış görünüşlər data dəyişdiyindən tez sorğulanan bahalı aqreqasiyalar üçün özünü ödəyir — partition-un düzəldilməsinin əvəzi kimi yox.
• Partition pruning ən böyük lakehouse qoludur və yalnız partition-lar sorğu predikatlarına uyğun gələndə işləyir.
• Statistikanı aktual saxlayın; onsuz xərcə əsaslanan optimallaşdırıcı təxmin edir, federativ mənbələr isə nə açdıqlarına görə fərqlənir.
• Ardıcıllıqla tənzimləyin: pushdown, paralellik, caching, materiallaşdırma, partition. Klasteri ən sonda ölçün.

Yukon Labs Starburst-u Azərbaycanda on-premise quraşdırır və tənzimləyir — giriş nəzarətinin konfiqurasiyası və sorğu performansı işi daxil olmaqla; eyni mühitə idarə olunan catalog lazım olanda yanında OvalEdge dayanır. Ətrafındakı arxitektura üçün müasir data platforması qurmaq və lakehouse üzrə ən yaxşı təcrübələr məqaləsinə baxın.