Lakehouse-da real vaxt analitikası xərcləri tamamilə fərqli olan üç şeydən birini bildirir: change data capture ilə dəqiqələrlə ölçülən təzəlik, stream processing ilə saniyələrlə ölçülən təzəlik, ya da ümumiyyətlə lakehouse olmayan xidmət qatı ilə saniyədən az gecikmə. Səhv pilləni seçmək bu sahədəki ən bahalı səhvdir və real vaxt kimi təsvir olunan tələblərin çoxu birinci pillə ilə ödənilir.

Ona görə mühəndislik sualı «necə daha sürətli» deyil. Sual budur: qərar əslində hansı gecikməni tələb edir və həmin gecikməni saxlamaq nəyə başa gəlir.

Praktikada «real vaxt» nə deməkdir?

Dörd pillə var və onları açıq adlandırmaq tələb seminarlarındakı mübahisələrin çoxunu bitirir.

Gündəlik. Gecə batch-i. Tənzimləyici hesabatlıq, trend təhlili və idarəetmə hesabatlarının çoxu üçün doğrudur. Dəbdə deyil, ucuzdur və analitik işin əksəriyyəti üçün adekvatdır.

Dəqiqələr. Change data capture sətir səviyyəli dəyişiklikləri lakehouse-a fasiləsiz axıdır. Əməliyyat panelləri, fırıldaq üzrə baxış növbələri və insanın bir saat içində rəqəmin əsasında hərəkət etdiyi hər şey üçün uyğundur.

Saniyələr. Pəncərəli aqreqasiya ilə stream processing. Bildiriş, real vaxtda risk qiymətləndirməsi və tranzaksiya axınlarında anomaliya aşkarlanması üçün tələb olunur.

Saniyədən az. Müştəriyə baxan tətbiqin sorğuladığı xidmət bazası — key-value və ya indekslənmiş əməliyyat anbarı. Bu, analitika deyil; sadəcə törəmə dataya xidmət edən tətbiq infrastrukturudur.

Faydalı intizam budur: rəqəmin hansı qərara xidmət etdiyini və insan ya sistemin onun əsasında nə qədər tez hərəkət etdiyini soruşun. On saniyədən bir yenilənən, amma gündə iki dəfə baxılan panel heç kimin işlətmədiyi gecikmə üçün fasiləsiz ödəniş edir. Əksinə, gecədə bir dəfə hesablanan fırıldaq qaydası fırıldaq qaydası deyil.

Niyə təkrarlanan sorğular yox, change data capture?

Datanı təzələməyin sadəlövh yolu mənbəni daha tez-tez sorğulamaqdır. Əməliyyat sistemi üçün bu, mövcud ən pis variantdır və səbəbini dəqiq demək lazımdır.

Təkrarlanan çıxarış sorğuları tranzaksiya yükü ilə eyni resurslar uğrunda rəqabət aparır. İş saatlarında sərt performans tələbləri olan core banking sistemində bu, DBA-nın illərlə serverdən uzaq saxlamağa çalışdığı yükdür. Üstəlik, silmələri etibarlı aşkarlaya bilmir və ardıcıl anlıq şəkli yalnız təsadüfən verir.

Change data capture isə bazanın tranzaksiya jurnalını oxuyur. Jurnal onsuz da davamlılıq və replikasiya üçün yazılır; CDC onu izləyir və sətir səviyyəli əlavə, yeniləmə və silmələrin sıralı axınını ötürür. Debezium əsas relyasion bazalar üçün konnektorları olan geniş yayılmış açıq mənbəli tətbiqdir.

Üç xüsusiyyət bunu korporativ mənbələr üçün doğru mexanizm edir:

Mənbəyə az təsir. Jurnalı oxumaq təkrarlanan cədvəl skanlarından qat-qat ucuzdur — analitik sorğulara ümumiyyətlə dözməyən sistemlərə qarşı cari vəziyyətə yaxın analitikanı mümkün edən də budur.

Silmələr və yeniləmələr düzgün tutulur, o cümlədən dəyişiklikdən əvvəlki görüntü; bu, auditə yararlılıq və vəziyyətin müəyyən ana bərpası üçün vacibdir.

Sıra qorunur, ona görə aşağı axındakı vəziyyət deterministik şəkildə yenidən qurula bilir.

Praktiki xərc koordinasiyadır. CDC jurnala giriş, dəstəklənən baza versiyası və adətən mənbədə konfiqurasiya dəyişikliyi tələb edir. Bankda bu, DBA komandası ilə söhbət və təhlükəsizlik baxışıdır — CDC layihələrinin vaxtının əslində getdiyi mərhələ də budur, pipeline kodu yox.

Axınlar lakehouse-a düşəndə nə sınır?

Üç şey, davamlı olaraq — və planlaşdırılsa, üçü də idarə oluna bilər.

Kiçik fayllar. Fasiləsiz yazan axın çoxlu kiçik fayl doğurur, sorğu mühərrikləri isə hər fayla görə sabit xərc ödəyir. Compaction olmadan sorğu performansı kimsə araşdırana qədər sabit şəkildə pisləşir. Azaldıcı tədbir öz qrafiki və resurs ayrılması olan compaction işidir — lakehouse tətbiqinin çətinlikləri məqaləsində açılıb.

Altdakı güzəşt birbaşadır: daha tez-tez yazın — gecikmə azalır, kiçik fayllar artır; yazıları böyük commit-lərə yığın — sorğu performansı yaxşılaşır, gecikmə artır. Bu güzəştdən yayınan konfiqurasiya yoxdur — yalnız cədvəl üzrə, həmin cədvəlin real ehtiyacı olan gecikmə pilləsinə görə şüurlu nöqtə seçimi var.

Yeniləmələrdə merge xərci. CDC yalnız əlavə yox, yeniləmə və silmə də doğurur. Onları cədvələ tətbiq etmək merge əməliyyatı deməkdir, bu isə əlavədən bahadır. Açıq table format-lar bunu düzgün həll edir və optimallaşdırma üsulları formatdan formata dəyişir — CDC ağırlıqlı yüklər üçün bir formatı digərindən üstün tutmağın əsas texniki səbəbi budur, çünki format spesifikasiyaları məhz bu əməliyyatlar üzərində inkişaf etməkdə davam edir.

Gec və sırasız gələn data. Hadisələr gec gəlir; mənbələr kəsintidən sonra yenidən ötürür. Gəliş sırasını güman edən cədvəl səhv aqreqat verəcək. Müəyyən edilmiş gecikmə pəncərəsi ilə hadisə vaxtına görə emal və sabit identifikatora bağlanmış idempotent yazılar standart cavablardır — hər ikisini əvvəlcədən dizayn etmək sonradan geydirməkdən qat-qat ucuzdur.

Streaming platforması lazımdır, yoxsa CDC kifayətdir?

Faydalı fərqdir, çünki komandalar tez-tez tək CDC ilə ödənən tələb üçün tam streaming dəsti alır.

Lakehouse-a CDC kifayətdir — tələb daha təzə cədvəllərdirsə. Pipeline belədir: mənbə jurnalı, CDC konnektoru, cədvəl yazıcısı, compaction. Nə stream processing, nə pəncərəli vəziyyət, nə ayrıca xidmət qatı. Müəssisələrdəki «bizə real vaxt hesabatlıq lazımdır» tələblərinin əksəriyyətini bu örtür.

Stream processing tələb olunur — hesablamanın özü fasiləsiz olanda: pəncərəli aqreqasiyalar, iki hadisə axını arasında birləşdirmələr, vəziyyət saxlayan şablon aşkarlanması. Tranzaksiya axınında fırıldaq qiymətləndirməsinə lazımdır; bugünkü tranzaksiya həcmi panelinə yox.

Ayrıca xidmət anbarı tələb olunur — gecikmə büdcəsi saniyədən az və paralellik yüksək olanda: müştəriyə göstərilən qalıq, analitikin paneli yox.

Bunlar arasındakı xərc fərqi böyükdür və əsasən lisenziya yox, əməliyyat fərqidir: vəziyyət saxlayan işləri olan stream processing platforması daimi əməliyyat öhdəliyidir, on-premise-də isə bu öhdəlik sizindir.

Fasiləsiz dəyişən cədvəllərə sorğular necə verilir?

İki mexanizm var və onlar birləşir.

Lakehouse-u birbaşa sorğulayın — mühərrik vasitəsilə. Açıq table format-lar yazıcılar commit edərkən oxuyuculara ardıcıl snapshot verir, ona görə analitiklər yarımçıq yazılmış yox, bütöv mənzərə görür. Dəqiqələr pilləsi üçün adətən təkbaşına kifayətdir.

Son metr üçün mənbəyə federasiya edin. Sorğuya CDC pipeline-ının verdiyindən təzə data lazım olanda mühərrik əməliyyat sistemini birbaşa sorğulayıb nəticəni lakehouse tarixçəsi ilə birləşdirə bilər. Bu, həqiqətən faydalı şablondur: tarixçə ucuz olduğu yerdən — lakehouse-dan, cari quyruq isə kiçik olduğu yerdən — mənbədən. Starburst bunu hər ikisi üzərində bir ifadədə edir; bu, Starburst və Trino Azərbaycanda məqaləsindəki eyni federasiya imkanının rezidentlik yox, gecikmə probleminə tətbiqidir.

Onda caching batch yüklərində olduğundan çox əhəmiyyət daşıyır, çünki panellər eyni aqreqasiyaları daim yenidən icra edir. Pushdown, caching və paralel oxumanın mexanikası Starburst analitikanı necə sürətləndirir məqaləsindədir.

Real vaxt nə vaxt dəyməz?

Dürüst cavabın batch-də qalmaq olduğu dörd hal.

Heç kim rəqəmin əsasında gündəlikdən tez hərəkət etmir. Ən çox rast gəlinən hal, xeyli fərqlə. Hesabata hər səhər baxılırsa, gecə yenilənməsi doğru dizayndır.

Mənbə CDC-ni dəstəkləmir və keçici həll aqressiv yoxlamadır. Kövrək sistemə qarşı tez-tez çıxarış sorğuları marginal təzəlik qazancı üçün real əməliyyat riski verir.

Data quality nəzarətləri batch-də işləyir. Datanı lakehouse-a doğrulana biləcəyindən tez axıtmaq doğrulanmamış rəqəmləri daha tez dərc etmək deməkdir. Keyfiyyət qaydaları qeydlərarası yoxlama tələb edəndə doğrulama ritmi faydalı təzəliyə döşəmə qoyur — arxasındakı operating model data quality governance proqramında harada dayanır məqaləsindədir.

Pipeline-ın sahibi olmayacaq. Streaming infrastrukturu batch-dən fərqli sınır: dayanmır, pisləşir və gecikmə səssizcə böyüyür. Monitorinq və sahib olmadan streaming pipeline-ı inamla köhnəlmiş data mənbəyinə çevrilir — bu isə görünən şəkildə sınmış batch işindən pisdir.

Buradakı bankda bu necə görünür?

Yukon Labs-ın nəzarət altındakı qurumlarda ən çox tətbiq etdiyi şablon şüurlu şəkildə mühafizəkardır və onu hədəf arxitektura yox, mənbə sistemləri formalaşdırır.

Core banking dəqiqələr pilləsində CDC-də qalır — jurnal əsaslı yanaşma məhz ona görə seçilir ki, analitik tələb heç vaxt tranzaksiya yükünə toxunmasın. Jurnala girişin təsdiqi təhlükəsizlik baxışıdır və qrafikə belə salınır.

Departament sistemləri batch-də qalır — onları daha təzə tələb edən qərar olmasa. Çoxunda belə qərar yoxdur.

Federasiya son metri örtür — həqiqətən cari rəqəm lazım olanda, hər mənbəni aşağı gecikmə pilləsinə itələmək əvəzinə.

Streaming fasiləsiz hesablaması olan hallar üçün saxlanılır — tranzaksiya monitorinqi, bildiriş — defolt arxitektura kimi qəbul edilmir.

Mühafizəkarlığın səbəbi odur ki, on-premise tutum məhduddur və satınalma yavaşdır. Öhdəlik götürdüyünüz hər gecikmə pilləsi daimi saxladığınız tutumdur; sahibi olduğunuz data mərkəzində isə işlədilməyən təzəlik üçün artıq tutum aylıq hesabdakı sətir yox, davamlı xərcdir. Bunun platformanın bütövünə necə oturduğu müasir data platforması qurmaq məqaləsindədir.

Əsas məqamlar

  • Gecikmə pilləsini açıq adlandırın: gündəlik, dəqiqələr, saniyələr, saniyədən az. Real vaxt kimi təsvir olunan tələblərin çoxu dəqiqələr pilləsində ödənilir.
  • Təkrarlanan çıxarış sorğuları yox, jurnal əsaslı CDC işlədin. Mənbəyə yüngül düşür, silmələri düzgün tutur və sıranı qoruyur.
  • CDC layihəsinin real xərci pipeline kodu yox, jurnala girişin təsdiqi və mənbə konfiqurasiyasıdır.
  • Lakehouse-a streaming kiçik fayllar doğurur. Öz qrafiki və resursu olan compaction könüllü deyil, məcburidir.
  • Gec və sırasız hadisələr üçün hadisə vaxtına görə emal və idempotent yazılarla dizayn edin; sonradan geydirmək bahalıdır.
  • Daha təzə cədvəllər üçün tək CDC kifayətdir. Stream processing yalnız hesablamanın özü fasiləsiz olanda lazımdır.
  • Hər pipeline-ı aşağı gecikmə pilləsinə itələmək əvəzinə son metr üçün mənbəyə federasiya edin.
  • Heç kim gündəlikdən tez hərəkət etmirsə, mənbə CDC-ni dəstəkləmirsə, doğrulama batch-də işləyirsə və ya pipeline-ın sahibi olmayacaqsa — real vaxtdan imtina edin.

Yukon Labs CDC və federativ xidməti on-premise tətbiq edir — sorğu qatında Starburst, streaming yolu üzrə lineage izləmək üçün isə OvalEdge. Arxitektura konteksti üçün data lakehouse arxitekturası və lakehouse üzrə ən yaxşı təcrübələr məqaləsinə baxın.