Data virtualization datanı əvvəlcə mərkəzi anbara köçürmədən, bir SQL ifadəsi ilə, bir neçə sistem üzrə olduğu yerdə sorğulamaqdır. Federated engine sorğunu götürür, hər mənbə sistemin hansı hissəni icra edə biləcəyini müəyyən edir, həmin hissələri aşağı itələyir və nəticələri birləşdirir.

Alternativ — və otuz ilin defolt yanaşması — əvvəlcə hər şeyi anbara köçürməkdir. O da işləyir və konkret xərclər dəsti daşıyır: qurulacaq və saxlanacaq pipeline-lar, iki dəfə ödənilən storage, sonuncu yükləmə qədər təzə olan data, və hər nüsxə ilə böyüyən idarəetmə problemi — çünki hər nüsxə şəxsi məlumatın yaşadığı yeni yer və təsnif ediləcək yeni obyektdir.

Virtualization həmin modeli əvəz etmir. Onu tamamlayır, faydalı bacarıq isə hansı sualın hansı yanaşmaya aid olduğunu bilməkdir.

Necə işləyir

Dörd addım, mühəndislik isə üçüncüdədir.

Kataloq. Engine hər qoşulmuş mənbə haqqında metadata saxlayır: sxemlər, cədvəllər, sütunlar və mənbənin nə edə bildiyi. Yetkin engine üçün əlli və daha çox konnektor standartdır — Trino relyasion bazaları, obyekt storage-ı, NoSQL və mesaj sistemlərini əhatə edən 30-dan çox istehsalat səviyyəli konnektorla gəlir.

Parse və plan. Üç sistemdəki cədvəllərə istinad edən tək SQL ifadəsi paylanmış plana parçalanır.

Pushdown. Engine hər mənbəyə həmin mənbənin nativ icra edə biləcəyi ən böyük fraqmenti göndərir — filtrlər, proyeksiyalar, aqreqasiyalar, bəzən join-lər. Bütün performans hekayəsi budur. Filtri Oracle-a aşağı itələyən sorğu min sətir ötürür; pushdown-suz eyni sorğu on milyon sətir ötürür və onları engine-də filtrləyir. Pushdown keyfiyyəti konnektordan konnektora kəskin dəyişir və yoxlanmalı olan şey də elə odur.

İcra və birləşdirmə. Qalan join və aqreqasiyalar engine-in öz paylanmış worker-lərində baş verir və nəticə bir bazadan gəlmiş kimi qayıdır.

Mənbə sistemlər dəyişmir. Agent yoxdur, sxem dəyişikliyi yoxdur, replikasiya yoxdur. Bu xassə heç kimin core banking sistemini dəyişməyə icazəsi olmayan estate-də virtualization-ı ilk sistemlərarası cavaba ən sürətli yol edir.

Harada həqiqətən qazanır

Bu bazarda yayğın olan beş vəziyyət.

Heç kimin pipeline qurmadığı sistemlərarası suallar. Core banking-i, CRM-i və kredit sistemini əhatə edən və risk tərəfindən bir dəfə verilən sual pipeline-a dəymir. Sorğuya dəyər.

Köçürülə bilməyən data. Tənzimləyici və ya müqavilə məhdudiyyətləri dataseti mərkəzi anbara köçürməyə imkan vermir. Federation onu yerində oxuyur, bu isə bəzən yeganə qanuni variantdır.

Öhdəlikdən əvvəl kəşfiyyat. Pipeline qurmazdan əvvəl join-in ümumiyyətlə faydalı olub-olmadığını öyrənin. Təklif edilən pipeline-ların böyük hissəsi bu addımdan sağ çıxmır — bu, uğursuzluq yox, qənaətdir.

Batch yükləmənin ödəyə bilmədiyi təzəlik tələbləri. Federated sorğu mənbəni saat 02:00-dakı halında yox, indiki halında görür.

İdarəetmə səbəbilə nüsxələrin azaldılması. Hər nüsxə təsnif ediləcək, qorunacaq və hesabatı veriləcək daha bir aktivdir. Az nüsxə Azərbaycanın şəxsi məlumat rejimi altında əhəmiyyətli dərəcədə sadə uyğunluq mövqeyidir və nəzarətçiyə performans arqumentindən daha etibarlı çatan arqumentdir.

Harada uduzur — bu daha vacibdir

Burada konkret olmaq uğurlu tətbiqi məyus tətbiqdən ayıran şeydir.

Sistemlərarası böyük join-lər. Oracle-dakı yüz milyon sətirlik cədvəli Postgres-dəki əlli milyon sətirlik cədvəllə birləşdirmək planner nə qədər yaxşı olsa da, şəbəkə üzərindən data hərəkəti deməkdir. Bu, tuning problemi yox, fizikadır. Materiallaşdırın.

Əməliyyat sistemlərinə yük. Federated sorğu sizin istehsalat core banking bazanızda icra olunur. Analitiklər təbii olaraq nəzakətli SQL yazmır və əksər federation tətbiqində ilk ciddi insident analitik sorğunun tranzaksiya sistemini zəiflətməsidir. Əməliyyat konnektorlarında resurs limitləri və eyni vaxtlılıq həddi seçim deyil — üstəlik JDBC bağlantı darboğazı o deməkdir ki, tək mənbə bağlantısı sizin öz sorğu performansınızın da məhdudlaşdırıcısına çevrilə bilər.

Təkrarlanan ağır sorğular. Hər beş dəqiqədə eyni bahalı federated sorğunu işlədən panel materiallaşdırılmış cədvəldən oxumalıdır. Federation nadir hallarda verilən suallar, yaxud cavabı mütləq cari olmalı olan suallar üçündür.

Zəif pushdown konnektorları. Konnektor aqreqasiyanı aşağı itələyə bilmirsə, engine xam sətirləri çəkir və işi özü görür. Performans engine problemi kimi görünən, əslində isə konnektor problemi olan şəkildə çökür.

Sorğu interfeysi olmayan legacy mənbələr. Mainframe ixracları və sabit enli fayllar federasiya olunmur. Onlar əvvəlcə yerə enir, sonra iştirak edir.

Buradan çıxan dizayn qaydası: əhatə üçün federasiya edin, təkrar üçün materiallaşdırın. Hər ikisi eyni arxitekturaya aiddir.

Virtualization və lakehouse

İkisi tez-tez rəqib kimi təqdim olunur, halbuki tamamlayıcıdır.

Lakehouse mərkəzləşdirməyə qərar verdiyiniz datanı açıq table format-da, anbar səviyyəli tranzaksiya davranışı ilə saxlayır. Federated engine isə həm həmin lakehouse-u, həm də mərkəzləşdirmədiyiniz hər şeyi — core banking sistemi, regional legacy tətbiq, SaaS platforma — bir ifadədə sorğulayır.

Mərhələli miqrasiyanı mümkün edən məhz bu kombinasiyadır. Kimsə cavab almazdan əvvəl hər şeyi köçürmək üçün iki illik proqram əvəzinə engine-i qaldırırsınız, mövcud olanı federasiya edirsiniz və səbəb yarananda dataset-ləri lakehouse-a köçürürsünüz. Səbəb adətən sorğu həcmi və ya join ölçüsüdür və bu qərarı sübut yaranana qədər təxirə sala bilərsiniz.

Çətin hissə idarəetmədir

Az qiymətləndirilməsi asan olan imkan: federation siyasətin heç vaxt birləşdirilməsini nəzərdə tutmadığı datanı birləşdirməyi mümkün edir.

İstifadəçiyə ayrı-ayrılıqda icazə verilmiş iki dataset yenidən eyniləşdirməyə aparan join istehsal edə bilər. Nüsxə əsaslı arxitekturada həmin kombinasiya pipeline, deməli baxış tələb edirdi. Federated arxitekturada isə bir SQL ifadəsi tələb edir.

Üç nəzarət bunu həll edir. Kimliyin mənbəyə ötürülməsi — sorğu ortaq servis hesabı ilə deyil, sorğu verən istifadəçinin hüquqları ilə icra olunsun; hər orkestrasiya dizaynında əhəmiyyət daşıyan eyni nəzarətdir. Engine-də sütun səviyyəli siyasət — maskalanma və sətir filtrasiyası hər mənbədə ayrıca yox, mərkəzi tətbiq olunsun. Və sorğu auditi — çünki federated arxitekturada kimin nəyi birləşdirdiyinin tam mənzərəsi yalnız engine-in query log-unda mövcuddur.

Bunların heç biri avtomatik deyil. Onlarsız federation tətbiqi giriş nəzarətlərinizi keçmək üçün yaxşı mühəndislik edilmiş üsuldur.

İlk tətbiqin ölçüsü

Altı həftə, bu ardıcıllıqla.

Birinci və ikinci həftə: üç mənbə qoşun — biri müasir, biri legacy, biri əhəmiyyət daşıyan — və hər birində pushdown davranışını real sorğu ilə təsdiqləyin. Yalnız keçən vaxtı yox, ötürülən sətir sayını ölçün; pushdown-ın işlədiyini deyən göstərici odur.

Üçüncü və dördüncü həftə: hər hansı analitik giriş almazdan əvvəl kimlik ötürülməsini və sütun səviyyəli siyasəti tətbiq edin. Sonradan əlavə etmək burada da AI retrieval-dakı qədər ağrılıdır.

Beşinci və altıncı həftə: əməliyyat konnektorlarında eyni vaxtlılıq limitləri ilə kiçik analitik qrupuna açın və nə soruşduqlarına baxın. Yazdıqları sorğular hansı dataset-lərin materiallaşdırılmağa layiq olduğunu deyəcək — bu isə pipeline backlog-u üçün tələblər seminarından xeyli yaxşı əsasdır.

Sonra hər dataset üzrə qərar verin: federated qalır, yoxsa lakehouse-a keçir. Bu qərarın arxasında artıq sübut var.

Əsas məqamlar

  • Virtualization datanı sistemlər üzrə yerində sorğulayır; bütün performans hekayəsi pushdown keyfiyyətidir və konnektordan konnektora kəskin dəyişir.
  • Sistemlərarası suallarda, köçürülə bilməyən datada, pipeline öhdəliyindən əvvəl kəşfiyyatda, təzəlikdə və idarəetmə üçün nüsxə azaltmaqda qazanır.
  • Sistemlərarası böyük join-lərdə, təkrarlanan ağır sorğularda və zəif pushdown konnektorlarında uduzur. Əhatə üçün federasiya, təkrar üçün materiallaşdırma.
  • Federated sorğular istehsalat sistemlərində icra olunur. Əməliyyat konnektorlarında eyni vaxtlılıq və resurs limitləri standart ilk insidentin qarşısını alır.
  • Çətin hissə idarəetmədir: federation siyasətin baxmadığı join-ləri mümkün edir. Kimlik ötürülməsi, mərkəzi sütun siyasəti və sorğu auditi seçim deyil, tələbdir.
  • Virtualization və lakehouse tamamlayıcıdır və birlikdə mərhələli miqrasiyanı mümkün edir.

Azərbaycan institutlarında federated analitika üçün Starburst — Trino-nun müəssisə distributivi — tətbiq edirik. Əlaqəli oxu: Azərbaycanda Starburst və Trino və data lakehouse arxitekturası.