Starburst — açıq mənbəli paylanmış SQL mühərriki olan Trino-nun korporativ distribusiyasıdır. O, datanı artıq yerləşdiyi yerdə sorğulayır — core banking sistemləri, data warehouse, obyekt anbarı, əməliyyat bazaları — və bunların hamısını əvvəlcə mərkəzi platformaya köçürmədən, bir SQL sorğusunda birləşdirir. Yukon Labs onu datasını xarici buluda çıxara bilməyən Azərbaycan təşkilatları üçün on-premise tətbiq edir.

Məhz bu son məhdudiyyət bu məqaləni regional edir. Beynəlxalq arqument pipeline-ların azaldılması və xərc haqqındadır. Burada isə bir addım əvvəldən başlayır: nəzarət altındakı bank və ya dövlət qurumu üçün hər şeyi bulud warehouse-unda mərkəzləşdirmək arxitekturası ümumiyyətlə əlçatan deyil, ona görə federasiya optimallaşdırma yox, korporativ analitikaya gedən praktiki yoldur.

Həll etdiyi problem

Mənzərə iri Azərbaycan təşkilatlarında demək olar eynidir.

Data iş saatlarında ağır sorğulanmamalı olan core banking sistemində, iki gün köhnə seçilmiş məlumatı saxlayan warehouse-da, bir neçə departament bazasında, obyekt anbarındakı arxivdə və getdikcə artan şəkildə heç kimin planlaşdırmadığı əməliyyat sistemlərində yaşayır.

Bunların ikisini əhatə edən hər sual bir pipeline-a çevrilir. Pipeline isə data mühəndisliyi komandasına sorğudur, komandanın növbəsi var, növbə isə həftələrlə ölçülür. Qurulandan sonra pipeline daimi baxım öhdəliyinə çevrilir — mənbə sxemi dəyişəndə sınır və heç vaxt söndürülmür, çünki kimin ondan asılı olduğunu heç kim dəqiq bilmir.

Yığılan effekt budur: yeni sualın cavabının qiyməti zamanla artır, bu isə tam tərsinə olmalıdır. Nəticədə təşkilatda yüzlərlə pipeline, onları saxlamaqla tam məşğul olan data mühəndisliyi komandası və artıq soruşmamağı öyrənmiş analitiklər qalır.

Federasiya bunu necə dəyişir

Trino sualı anbardan ayırır. Bu, öz anbarı olmayan sorğu mühərrikidir: mənbələrə konnektorlar vasitəsilə qoşulur — açıq mənbəli Trino-da 30-dan çox istehsalata hazır konnektor, Starburst-da 50-dən çox — onların üzərində paylanmış sorğu planlaşdırır, hər mənbənin apara biləcəyi qədər işi aşağıya ötürür və nəticələri işçi klasterində yaddaşda birləşdirir.

Konkret olaraq, analitik oracle_core.banking.transactions cədvəlini iceberg_lake.risk.customer_profile cədvəlinə customer_id üzrə birləşdirən, tranzaksiya tarixinə görə süzən və müştəri seqmenti üzrə qruplaşdıran bir SELECT yazır — fərqli aktiv müştəriləri sayıb həcmi toplayır.

Cədvəl adlarına yenidən baxın: birincisi Oracle core banking sistemi daxilindəki sxem, ikincisi obyekt anbarındakı Apache Iceberg cədvəlidir. Bir sorğu, tamamilə fərqli iki sistem — pipeline olmadan, kopya olmadan və saxlanmalı planlı iş olmadan birləşdirilir.

Ardınca gələn sual həmişə eynidir və doğru sualdır: bu, warehouse-dan yavaş deyilmi?

Düzgün indekslənmiş warehouse-a qarşı yaxşı tənzimlənmiş tək mənbəli sorğu üçün — bəli. Qalan hər şey üçün müqayisə yanıldıcıdır, çünki alternativ sürətli sorğu deyil — pipeline üçün üç həftəlik gözləmədir. Trino-nun pushdown mexanizmi süzgəcləri, proyeksiyaları və aqreqasiyaları mümkün olan yerdə mənbə sistemində icra edir, ona görə nəticə adətən gözləniləndən qat-qat çox nativ performansa yaxın olur. Starburst təkrar-təkrar sürətli olmalı sorğular üçün caching və materiallaşdırılmış görünüşlər, həmçinin mənbə başına paralel JDBC bağlantıları əlavə edir — fərqli bölmələrdən eyni anda oxumaqla — bu isə ənənəvi relyasion bazaları federasiya edərkən ən böyük darboğazı aradan qaldırır.

Güzəşt belədir: sorğuların çoxunda warehouse-a yaxın performans, dərhal — bəzi sorğularda warehouse performansı, bir rübdən sonra.

Starburst Trino-ya nə əlavə edir

Trino açıq mənbəlidir və özü də istehsalata yararlıdır. Bir sıra təşkilatlar onu birbaşa işlədir, bu da tam əsaslı seçimdir.

Starburst kommersiya distribusiyasıdır və əlavə etdikləri ən çox tənzimlənən qurumlar üçün əhəmiyyət daşıyır:

  • İncə dənəvərlikli giriş nəzarəti — sətir və sütun səviyyəsində siyasətlər hər federativ mənbədə ardıcıl tətbiq olunur, hətta öz təhlükəsizlik modeli bunu ifadə edə bilməyən mənbələrdə də. Bank üçün ən dəyərli əlavə məhz budur.
  • Daha geniş, dəstəklənən konnektor dəsti — açıq mənbəli konnektorların zəif əhatə etdiyi korporativ mənbələr də daxil olmaqla.
  • Paralel mənbə oxuma, caching və materiallaşdırılmış görünüşlər — təkrarlanan sorğu şablonları və JDBC ilə məhdudlaşan mənbələr üçün.
  • Sorğu performansının tənzimlənməsi — açıq mənbəli baza ilə müqayisədə təkmilləşdirilmiş, xərcə əsaslanan optimallaşdırıcı.
  • Klaster idarəetməsi və avtoskalalanma, bu da əməliyyat yükünü nəzərəçarpacaq dərəcədə azaldır.
  • Kommersiya dəstəyi, texniki üstünlüklərdən asılı olmayaraq bankın satınalma prosesində adətən həlledici amil olur.

Dürüst yekun: güclü platforma mühəndisliyiniz və sadə giriş nəzarəti tələbləriniz varsa, açıq mənbəli Trino işlədin. Korporativ giriş nəzarəti, geniş konnektor dəstəyi və ya uyğunluq səbəbindən dəstəklənən məhsul lazımdırsa, Starburst işlədin — burada nəzarət altındakı qurumların çoxu məhz bu təsvirə düşür.

Bu bazarda tətbiq

On-premise istisna deyil, normadır. Starburst öz data mərkəzinizdə Kubernetes üzərində işləyir. Koordinator və işçilər konteynerlərdir; obyekt anbarı qatı ictimai bulud xidməti yox, MinIO və ya Ceph ola bilər. Arxitekturada iş vaxtı internet bağlantısı tələb edən heç nə yoxdur.

Datanızı yerindən tərpətmir. Bunu təhlükəsizlik baxışlarında açıq demək lazımdır, çünki birinci qalxan narahatlıq budur. Trino mənbələrdən sorğu anında oxuyur və nəticəni qaytarır. Mühərrikin içində mənbə datasının davamlı kopyası yoxdur. Data rezidentliyi baxımından federasiyanı müdafiə etmək mərkəzləşdirməni müdafiə etməkdən xeyli asandır, çünki heç nə yerdəyişmir — bu isə birbaşa Azərbaycanda data rezidentliyi və şəxsi məlumat qanunu məqaləsində müzakirə olunan sərhədlərarası ötürmə qaydalarına toxunur.

Core sistemin yükünü azaldır. Tez-tez səslənən etiraz federativ sorğuların core banking sisteminə düşəcəyidir. Praktikada pushdown, caching və analitik sorğuların replikalara yönləndirilməsi core sistemin yükü üzərində indiki vəziyyətdən daha çox nəzarət verir — indi isə hər ad-hoc çıxarış kiminsə yazdığı fərdi skriptdir.

Nəzarət mövqeyinə uyğun gəlir. Mərkəzi Bankın Banklarda informasiya təhlükəsizliyinin idarə edilməsi haqqında Qaydalar sənədi — 2022-ci ilin aprelindən qüvvədədir və ISO/IEC 27000 seriyası üzərində qurulub — təsnifata bağlı giriş nəzarəti gözləyir. Hər mənbədə eyni sətir və sütun səviyyəli siyasəti tətbiq edən federasiya qatını sübuta yetirmək altı sistemdə fərqli-fərqli təkrar qurulmuş eyni qaydalardan asandır.

Üçdilli metadata kataloq məsələsidir, mühərrik məsələsi deyil. Trino rus adlı cədvəli azərbaycan adlı cədvələ məmnuniyyətlə birləşdirəcək. Onların eyni anlayışı təsvir etdiyini bilmək biznes kataloqunun işidir — bax Azərbaycanda data idarəetməsi.

İlk tətbiq necə görünür

İlk layihə üçün tipik əhatə, altı-on həftə:

1–2-ci həftələr. Mənbələrin inventarı və konnektorların yoxlanması. Hansı sistemlər, hansı versiyalar, giriş yolu nədir, təhlükəsizlik baxışı nə tələb edir. Bu mərhələ sürprizləri üzə çıxarır və onlar həmişə olur — dəstəklənməyən baza versiyası, marşrutu olmayan şəbəkə seqmenti, sahibinin əhatəyə düşdüyündən xəbərsiz olduğu sistem.

3–4-cü həftələr. Kubernetes üzərində klasterin qurulması, konnektorların konfiqurasiyası, autentifikasiya üçün mövcud kataloq xidməti ilə inteqrasiya.

5–6-cı həftələr. Giriş nəzarəti siyasəti. Mövcud rollara uyğunlaşdırılmış sətir və sütun səviyyəli qaydalar. Bankda ən uzun çəkən və ən vacib mərhələ budur, çünki analitiklərə ümumiyyətlə birbaşa giriş verməyə imkan verən məhz odur.

7–8-ci həftələr. Sorğuya keçid — BI alətlərinin qoşulması, mövcud hesabatların bir hissəsinin federativ işləməyə köçürülməsi və fərqin ölçülməsi.

9–10-cu həftələr. Performansın tənzimlənməsi, təkrarlanan sorğular üçün caching strategiyası və təhvil.

Başlanğıcda müəyyən edilməli ölçülə bilən nəticə adətən eynidir: hazırda pipeline tələb edən hesabatlar dəsti onlarsız işləyir, azad olunan mühəndislik vaxtı isə rəqəm kimi göstərilir.

Harada səhv seçimdir

Tək mənbəli, yüksək paralellikli xidmət yükü. Min nəfər eyni anda bir bazanı saniyənin altında cavab tələbi ilə sorğulayırsa, bu, düzgün indekslənmiş bazanın işidir, federasiya mühərrikinin yox.

Ağır paket çevrilmələri. Trino interaktiv sorğu mühərrikidir. Geniş miqyaslı ETL Spark-ın sahəsidir və ikisi rəqabət aparmır, eyni arxitekturada yan-yana yaşayır.

Platforma imkanı ümumiyyətlə olmayan təşkilatlar. Starburst xam Trino ilə müqayisədə əməliyyat yükünü azaldır, amma paylanmış klasterin yenə də sahibi olmalıdır.

Əsl problem datanın etibar qazanmaması olanda. Federasiya pis datanı daha tez əlçatan edir. Təriflər mübahisəlidirsə və lineage bilinmirsə, əvvəlcə idarəetmə gəlir.

Əsas məqamlar

  • Trino datanı yerləşdiyi yerdə sorğulayır və sistemlər arasında bir SQL sorğusunda birləşdirir. Starburst onun korporativ distribusiyasıdır, 50-dən çox dəstəklənən konnektorla.
  • Buradakı nəzarət altındakı qurumlar üçün federasiya optimallaşdırma deyil — xarici buludda mərkəzləşdirmə mümkün olmayanda işləyən arxitektura budur.
  • Heç nə kopyalanmır. Data rezidentliyi baxımından bunu müdafiə etmək mərkəzləşdirməni müdafiə etməkdən asandır.
  • Starburst-un banklar üçün həlledici əlavəsi hər federativ mənbədə ardıcıl sətir və sütun səviyyəli giriş nəzarətidir.
  • Köhnə relyasion mənbələrin federasiyasını məqbul sürətdə işlədən şey paralel JDBC oxumasıdır.
  • Tək mənbəli yüksək paralellikli xidmət, ağır paket ETL və ya idarəetmənin əvəzi kimi — səhv seçimdir.

Yukon Labs Starburst həllini Azərbaycanda on-premise tətbiq edir və eyni mühitə idarə olunan biznes kataloqu da lazım olduqda OvalEdge ilə yanaşı işləyir. Arxitektura fonu üçün data lakehouse arxitekturası ilə başlayın.