[ ICYMI skaitykite 1 dalį Nekeičiamų duomenų platforma ]

Daugelis duomenų platformų šiandien yra sukurtos iš apačios į viršų, pradedant renkant duomenis, kurie „gali būti naudingi vėliau“, ir palaipsniui derinant sprendimus, kai atsiranda poreikių. Toks požiūris neišvengiamai veda prie suskaidyto įgyvendinimo, didėjančių sąnaudų ir techninių skolų. Duomenų sistemos projektavimui reikia specialių žinių apie duomenų modeliavimą, paskirstytas sistemas, saugumą ir atitiktį. Daugelis kompanijų tiesiog negali sau leisti tam skirtų duomenų infrastruktūros komandų iš pradžių ir turi kurti bei pritaikyti savo duomenų sistemas, kai jos auga.

Tačiau kelias į esamų sistemų plėtrą gali būti gana sudėtingas. Komandoms dažnai tenka rinktis tarp ilgų migracijų išlaikant kelias pasikartojančias sistemas arba brangų visišką sistemos perjungimą. „Netscape“ sprendimas perrašyti savo naršyklės variklį 1997 m. kainavo jiems naršyklių verslą ir dominavimą rinkoje „Internet Explorer“, nes jie negalėjo konkuruoti su sparčiais Internet Explorer funkcijų leidimais, todėl galiausiai sumažėjo jų rinkos dalis. Daugelis įmonių pradeda nuo pritaikytų sprendimų ir augdamos pereina prie tiekėjų platformų; tačiau net ir tokiu mastu, kai įmonės gali sau leisti tiekėjų platformas, jos vis tiek gali neatitikti jų naudojimo atvejų, o vidiniai vartotojai turi prisitaikyti prie naujų darbo eigų. Daugelis kompanijų galiausiai kuria pasirinktinius sprendimus ant tiekėjų platformų ir toliau plečiasi. Vidinės infrastruktūros komandos dabar turi prižiūrėti savo originalias sistemas, eksploatuoti tiekėjų platformas ir palaikyti tinkintus diegimus ant tų platformų, taip pat mokyti vartotojus naudoti įvairius įrankius ir tvarkyti kelių sistemų saugumą bei integravimą. Dėl planavimo stokos ir organinės pažangos, kaip verslo mastu, tai, kas prasidėjo kaip pigesnis sprendimas, tampa žymiai brangesnis ir sudėtingesnis.

Sukurti duomenų platformas, kurios gali augti augant verslui, šiandien yra lengviau nei anksčiau. Per pastarąjį dešimtmetį daugelis organizacijų sukūrė aiškius duomenų naudojimo modelius – produktų komandoms reikia vartotojų elgsenos duomenų, rinkodaros komandos stebi kampanijos našumą, finansų komandos stebi pajamų metrikas, o saugos komandos analizuoja grėsmių modelius. Šie įprasti naudojimo atvejai yra gerai žinomi atsižvelgiant į tai, kokių duomenų jiems reikia ir kaip greitai jų reikia. Užuot atradus reikalavimus per brangų perkėlimą ir modifikuojant tiekėjų sprendimus, galima sukurti duomenų platformą, kuri gali tvariai padidinti sąnaudas ir veiklos efektyvumą.

Duomenų platformų projektavimas

Iš esmės duomenų platformą galima apibrėžti dviem pagrindiniais komponentais: kokių duomenų jums reikia (duomenų modeliai) ir kaip greitai jų reikia (delsavimo reikalavimai). Net ir esant laisvai apibrėžtam naudojimo atvejui, suprasdami šiuos du komponentus galime sistemingai nustatyti duomenų rinkimo mechanizmą ir infrastruktūros poreikius.

Paimkite, pavyzdžiui, sukčiavimo rizikos aptikimą. Paprastai sukčiavimo rizikai reikia trijų duomenų komponentų: tapatybės, sandorio ir atvejo valdymo.

Kiekvienas duomenų komponentas gali būti susietas su infrastruktūra, atsižvelgiant į delsos poreikius. Norint nustatyti tapatybę ir sandorius, reikia apdoroti srautą, kad būtų galima aptikti sukčiavimą realiuoju laiku, duomenų bazės apdoroja nuolatinį stebėjimą ir įspėjimus, o duomenų rinkiniai palaiko ilgalaikes užduotis, pvz., modelių analizę ir modelių mokymą.

Duomenų modeliai

Duomenų modelis apibrėžia, kaip duomenys turi būti tvarkomi ir standartizuojami. Jame nurodomas laukų rinkinys ir jų charakteristikos – kiekvieno lauko formatas, tipas ir taisyklės. Schemos leidžia aptikti duomenis, o atskirų laukų apibrėžimai nustato valdymo politiką ir atitikties reikalavimus.

Gerai apibrėžti duomenų modeliai įgalina standartizuotą duomenų rinkimą ir apdorojimą visoje organizacijoje. Paimkite vartotojų duomenis kaip pavyzdį – rinkodarai jų reikia kampanijai sekti, klientų aptarnavimui atvejams valdyti, produktų komandoms elgsenos analizei ir rizikos komandoms sukčiavimo aptikimui. Neturėdama bendro naudotojo duomenų modelio, kiekviena komanda kuria savo vartotojo profilių ir stebėjimo logikos versiją. Komandos galiausiai sukuria sudėtingas integracijas, kad išspręstų ir suderintų vartotojų duomenis tarp sistemų. Bendras duomenų modelis, veikiantis kaip vienas tiesos šaltinis, supaprastina duomenų rinkimą ir įgyvendinimą, o nuoseklūs standartai leidžia daug lengviau valdyti saugumą ir atitiktį.

Apibrėžti išsamius duomenų modelius atskiroms komandoms dažnai sunku, nes jos paprastai sutelkia dėmesį į savo tiesioginius poreikius. Rinkodaros komandos daugiausia dėmesio skiria su kampanija susijusioms sritims, o rizikos grupės – tapatybės patvirtinimo atributams. Neturėdamos holistinio požiūrio į tai, kaip tie patys duomenys atlieka skirtingas funkcijas, komandos dažnai sukuria neišsamius arba siaurai sufokusuotus duomenų modelius, kuriems reikia tolesnio apdorojimo ir sistemų integravimo.

Laiko reikalavimai

Laiko reikalavimai apibrėžia, kaip greitai duomenys turi būti apdoroti ir prieinami. Apdorojimo langai svyruoja nuo realiojo laiko (sekundėmis), kad būtų galima priimti neatidėliotinus sprendimus, iki beveik realiojo laiko (minutės) stebėjimui, iki paketinio apdorojimo (valandomis) analizei ir AI/ML programoms. Šie laiko reikalavimai atitinka konkrečius infrastruktūros pasirinkimus – srautinį perdavimą realiuoju laiku, duomenų bazes beveik realiuoju laiku ir duomenų rinkinius paketiniam apdorojimui.

Be sistemos, produktų komandos dažnai kuria perteklinę infrastruktūrą panašiems poreikiams – viena komanda gali naudoti „Kafka“, o kita – MSK srautiniam perdavimui, arba viena komanda gali pasirinkti „DynamoDB“, o kita – „Cassandra“ duomenų bazėms. Tai sukuria nereikalingą sudėtingumą, nes komandos prižiūri kelias sistemas su pasikartojančiais saugos valdikliais ir integracijomis.

Standartizavus infrastruktūros komponentus, produktų komandoms nebereikia diegti savo infrastruktūros, o platformų komandos gali sumažinti veiklos sąnaudas, prižiūrėdamos mažiau sistemų. Šis standartizavimas taip pat įgalina geresnę saugos kontrolę, supaprastintą integravimą, supaprastintą stebėjimą ir optimizuojančias išlaidas.

Bendroji duomenų platforma

Duomenų platformos architektūros struktūra leidžia mums sistemingai nustatyti duomenų rinkimo specifikacijas, infrastruktūros reikalavimus, saugos kontrolę ir integravimo galimybes. Tai tiesiogiai sprendžia sudėtingumo ir išlaidų spiralę, su kuria šiandien susiduria daugelis organizacijų. Užuot komandos kuriančios atskiras sistemas, kurias platformų komandos stengiasi palaikyti, nuosekli sistema supaprastina saugumą, atitiktį, integravimą ir sąnaudų valdymą visoje organizacijoje.

Be nuoseklaus diegimo, platformų komandos nuolat prašomos pasirinkti, ar išlaikyti esamas sistemas, atlikti brangias migracijas ar kurti naujas funkcijas. Platformų komandos didžiąją laiko dalį praleidžia prižiūrėdamos skirtingas sistemas ir tvarkydamos migracijas, užuot suteikusios svarbias verslui galimybes. Sistema pagrįstas metodas leidžia organizacijoms išplėsti savo duomenų platformas be trikdančios migracijos. Mažesnės organizacijos gali pradėti nuo būtinų komponentų ir plėstis augdamos, o didesnės organizacijos gali vieną kartą standartizuoti esamas sistemas be nuolatinio perrašymo.

Kitas

3 serijos „One Off to One Data Platform“ dalyje aptarsime, kaip šią sistemą galima įgyvendinti praktiškai. Išnagrinėsime, kaip įprastus duomenų platformos komponentus, tokius kaip srautinis perdavimas, duomenų bazės, duomenų saugykla ir duomenų ežeras, galima surinkti, kad būtų palaikomi įvairūs verslo naudojimo atvejai, naudojant nuoseklias saugos ir atitikties kontroles. Augant organizacijoms, šis modulinis metodas leidžia komandoms savarankiškai keisti atskirų komponentų mastelį, kartu išlaikant standartizuotas sąsajas ir valdiklius, todėl nereikia nuolatinės migracijos. Naudodamos aiškią duomenų platformos architektūros sistemą, organizacijos gali kurti duomenų programas, kurios auga kartu su jų verslu, o ne jį riboja.