Dar prieš kokius dešimt metų dauguma sistemų dirbo pagal principą „surink duomenis, palauk iki nakties, tada paleisk ataskaitą”. Šiandien tokia logika daugeliui verslų tiesiog nebeveikia. Jei internetinė parduotuvė sužino apie sutrikusią mokėjimų sistemą tik ryte peržiūrėjusi vakarykščius skaičius, ji jau prarado tūkstančius eurų ir dalį klientų pasitikėjimo. Būtent dėl to realaus laiko duomenų analitika iš nišinės technologijos tapo būtinybe daugumai IT infrastruktūrų.
Šiame straipsnyje pažvelgsime, kas iš tikrųjų slypi po šia sąvoka, kokie įrankiai naudojami, su kokiomis kliūtimis susiduria komandos ir kaip praktiškai pradėti diegti tokią sistemą, neišleidžiant biudžeto per keletą mėnesių.
Kas iš tiesų yra „realus laikas”
Terminas skamba paprastai, bet praktikoje jis dažnai suprantamas skirtingai. Vieniems realus laikas reiškia milisekundes, kitiems – priimtina, jei duomenys pasiekia analitinę sistemą per kelias sekundes ar net minutę. Iš tikrųjų svarbu ne pati skaičiaus vertė, o tai, ar delsimas atitinka verslo poreikį.
Bankinėje sistemoje, tikrinančioje sukčiavimo požymius, kelių sekundžių delsa jau gali reikšti finansinius nuostolius. O gamybos linijos sensorių monitoringui kartais pakanka atnaujinimo kas 5–10 sekundžių. Todėl pirmas žingsnis prieš renkantis technologijas – atsakyti sau į klausimą: kiek iš tikrųjų kainuoja mums vėlavimas ir koks delsos lygis dar yra priimtinas.
Yra dar viena sąvoka, kurią verta atskirti – near real-time (beveik realus laikas). Daugelis sistemų, kurias rinkodara vadina „real-time”, iš tikrųjų veikia su keliolikos sekundžių ar minutės atsilikimu. Ir tai visiškai normalu – ne kiekvienam atvejui reikia tikro streamingo su milisekundžių tikslumu.
Architektūra: kaip duomenys keliauja nuo įvykio iki dashboard’o
Tipinė realaus laiko analitikos sistema susideda iš kelių sluoksnių, ir kiekvienas jų turi savo specifiką bei potencialias problemų vietas.
Duomenų šaltiniai – tai gali būti IoT sensoriai, aplikacijų logai, vartotojų veiksmai svetainėje, mokėjimų sistemos ar tinklo įrenginiai. Svarbu suprasti, kad kiekvienas šaltinis generuoja duomenis skirtingu greičiu ir formatu, todėl reikia unifikuoto būdo juos priimti.
Pranešimų sistema (message broker) – čia scena priklauso tokiems įrankiams kaip Apache Kafka, Amazon Kinesis ar Google Pub/Sub. Jų užduotis – priimti milžinišką srautą įvykių ir garantuoti, kad jie pasieks tolimesnius apdorojimo mazgus be praradimų, net jei sistema laikinai perkraunama.
Srautinio apdorojimo variklis – čia duomenys transformuojami, filtruojami, agreguojami. Populiariausi variantai šiandien – Apache Flink, Kafka Streams, Apache Spark Structured Streaming. Kiekvienas turi savo stipriąsias puses: Flink puikus žemos latencijos scenarijams, Spark – patogesnis, jei komanda jau naudoja batch apdorojimą ir nori vieningos ekosistemos.
Saugykla – realaus laiko duomenims dažnai naudojamos specializuotos duombazės kaip ClickHouse, Apache Druid ar TimescaleDB, kurios optimizuotos greitam skaitymui ir rašymui vienu metu, net kai srautas siekia milijonus įrašų per sekundę.
Vizualizacijos sluoksnis – galiausiai visa tai turi kažkur atsispindėti: dashboard’uose, perspėjimuose, automatizuotose reakcijose. Grafana, Superset ar savos gamybos sprendimai čia atlieka paskutinį žingsnį.
Kafka, Flink ir kiti – kodėl tiek daug įrankių
Pradedantiems komandoms dažnai kyla klausimas, kodėl reikia tiek daug atskirų komponentų, kai atrodytų, galima viską sudėti į vieną duombazę. Atsakymas paprastas – kiekvienas komponentas sprendžia skirtingą problemą, ir bandymas viską suversti į vieną sistemą greitai atsimuša į skalės ribas.
Kafka, pavyzdžiui, nėra duombazė – tai transportavimo sluoksnis, garantuojantis pranešimų pristatymą tvarka ir be praradimų net esant sistemos gedimams. Jis puikiai veikia kaip buferis tarp greitai generuojamų įvykių ir lėčiau juos apdorojančių sistemų.
Flink savo ruožtu specializuojasi ties sudėtingu srautų apdorojimu – langų (windowing) skaičiavimais, būsenos (state) valdymu, sudėtingų agregacijų vykdymu realiu laiku. Jis leidžia, pavyzdžiui, apskaičiuoti „kiek unikalių vartotojų per paskutines 5 minutes atliko pirkimą” – ir tai daryti nuolat atnaujinant rezultatą, nelaukiant, kol langas užsidarys.
Verta paminėti ir naujesnius žaidėjus – RisingWave ar Materialize, kurie bando suteikti SQL sąsają srautiniam apdorojimui, taip sumažindami įėjimo barjerą komandoms, neturinčioms gilios patirties su tradiciniais stream processing frameworkais. Tai gera žinia mažesnėms komandoms, kurioms Flink klasteris atrodo per didelė investicija.
Dažniausios klaidos diegiant tokias sistemas
Praktikoje matau, kad daugelis komandų susiduria su panašiomis problemomis, nepriklausomai nuo pasirinktų technologijų.
Pirma klaida – bandymas iš karto padaryti „idealią” architektūrą su visais įmanomais komponentais. Realybėje geriau pradėti nuo paprasto sprendimo – galbūt net su Kafka ir paprastu consumeriu, rašančiu į PostgreSQL – ir tik vėliau, kai atsiranda realus poreikis, pridėti sudėtingesnius sluoksnius.
Antra – duomenų kokybės ignoravimas. Realaus laiko sistemoje klaidingi duomenys plinta greitai ir jų poveikis matomas iš karto. Jei batch sistemoje galima nakties metu perskaičiuoti ir ištaisyti klaidą, streaming sistemoje jau spėjai priimti sprendimus pagal blogus skaičius.
Trečia – late arriving data, arba pavėluotai atkeliaujantys duomenys, ignoravimas. Tinklo trikčių metu įvykiai gali pasiekti sistemą su vėlavimu, ir jei architektūra to nenumato (pavyzdžiui, naudojant watermarks Flink’e), skaičiavimai taps neteisingi be jokio aiškaus signalo, kad kažkas negerai.
Ketvirta – nepakankamas dėmesys monitoringui pačiai analitikos sistemai. Ironiška, bet daugelis komandų, kuriančių real-time monitoringą klientams, patys neturi aiškaus vaizdo, ar jų pačių Kafka klasteris ar Flink darbas veikia sklandžiai.
Kur tai iš tikrųjų naudojama gyvenime
Teorija gerai, bet verta pažiūrėti į konkrečius atvejus, kur realaus laiko analitika keičia žaidimo taisykles.
E-komercijos platformos naudoja ją kainodaros optimizavimui – stebint konkurentų kainas ir paklausą, kainos gali keistis kelis kartus per valandą, reaguojant į realų pirkėjų elgesį. Taip pat rekomendacijų sistemos, kurios atnaujina siūlomus produktus atsižvelgdamos į tai, ką vartotojas peržiūrėjo prieš kelias sekundes, o ne vakar.
Finansų sektoriuje – sukčiavimo aptikimas yra klasikinis pavyzdys, kur kiekviena sekundė delsimo gali reikšti papildomus nuostolius. Sistemos analizuoja transakcijų srautą ir ieško anomalijų modelių realiu laiku, blokuodamos įtartinas operacijas dar prieš joms įvykstant.
Gamybos sektoriuje – predictive maintenance, kai sensoriai stebi įrangos vibraciją, temperatūrą ar kitus parametrus, ir sistema signalizuoja apie galimą gedimą prieš jam iš tikrųjų atsitinkant, taip išvengiant brangaus prastovos laiko.
Logistikos kompanijos naudoja realaus laiko duomenis maršrutų optimizavimui – sekant transporto priemonių padėtį ir eismo sąlygas, maršrutai gali būti perskaičiuojami kelionės metu, o ne planuojami tik prieš išvykstant.
Ką pasirinkti debesyje ir kiek tai kainuoja
Vienas dažniausių klausimų – ar geriau statyti savo infrastruktūrą, ar naudoti debesijos paslaugas. Atsakymas priklauso nuo komandos brandos ir apimčių.
AWS siūlo Kinesis Data Streams ir Kinesis Analytics, Google turi Pub/Sub kartu su Dataflow, Azure – Event Hubs su Stream Analytics. Šie sprendimai geri tuo, kad nereikia patiems valdyti infrastruktūros, tačiau kainodara gali tapti netikėtai brangi, kai duomenų srautas išauga.
Savarankiškas Kafka ir Flink diegimas Kubernetes klasteryje suteikia daugiau kontrolės ir dažnai ilgainiui pigesnis dideliems srautams, bet reikalauja rimtos DevOps ekspertizės. Tai nėra sprendimas, kurį galima palikti be priežiūros – reikia žmonių, kurie supranta partition’ų valdymą, replikacijos strategijas, resource tuning’ą.
Vidutinio dydžio komandoms dažnai racionaliausia pradėti nuo valdomo sprendimo (managed service), o savo infrastruktūrą statyti tik tada, kai kaštai ar specifiniai reikalavimai to reikalauja. Confluent Cloud, pavyzdžiui, siūlo valdomą Kafka be poreikio patiems tvarkyti klasterius, kas gali būti gera pradžia, kol komanda auga.
Praktiniai patarimai ir kaip tai visą reikalą pradėti be chaoso
Užuot rašius standartinę išvadų dalį, verčiau pasidalinsiu keliais praktiniais dalykais, kuriuos verta žinoti prieš metant komandą į realaus laiko analitikos projektą.
Pirmiausia – nepradėkite nuo technologijų, pradėkite nuo klausimo. Kokį konkretų sprendimą jūsų verslas turi priimti greičiau, nei dabar gali? Jei atsakymas neaiškus, greičiausiai realaus laiko analitika dar nėra jums prioritetas, ir laikas geriau investuoti į kitus dalykus.
Antra – testuokite mažai, iteruokite greitai. Paleiskite vieną srautą, vieną use case, ir stebėkite, kaip sistema elgiasi realiomis apkrovomis. Sintetiniai testai retai atskleidžia tikras problemas, kurios išryškėja tik su realiais duomenimis.
Trečia – investuokite į stebėseną nuo pat pradžių. Metrikos apie latenciją, throughput, klaidų procentą turi būti matomos komandai kasdien, o ne tik tada, kai kažkas jau sugedo. Prometheus kartu su Grafana čia yra pakankamai standartinis ir patikimas derinys.
Ketvirta – neignoruokite duomenų schemos valdymo. Kai srautas auga ir prisijungia nauji šaltiniai, schemos pasikeitimai gali sugriauti visą downstream apdorojimą. Schema Registry, naudojamas kartu su Kafka, padeda išvengti tokių netikėtumų.
Ir galiausiai – atminkite, kad realaus laiko analitika nėra tikslas savaime. Tai priemonė greičiau reaguoti į tai, kas vyksta jūsų verslui svarbiuose procesuose. Jei po visų investicijų į infrastruktūrą niekas iš tikrųjų nesinaudoja gauta informacija sprendimams priimti sekundžių ar minučių tikslumu, visa sistema tampa brangiu, bet beprasmiu techniniu žaislu. Todėl prieš pradedant bet kokį tokio pobūdžio projektą, verta sėdėti su verslo pusės žmonėmis ir aiškiai susitarti – ką jie darys su duomenimis, kai jie pasieks juos per tris sekundes, o ne per tris valandas. Jei atsakymas aiškus ir konkretus, tuomet verta investuoti laiką, pinigus ir komandos energiją į šią, be abejo, įdomią, bet reiklią technologinę kryptį.
