Galvojant apie duomenų platformas gali būti šiek tiek sunku apsvarstyti visas galimas paslaugas ir architektūrines parinktis.
Įmonės duomenų platformą dažnai sudaro duomenų saugyklos, duomenų modeliai, duomenų ežerai ir ataskaitos, kurių kiekvienas turi konkretų tikslą ir reikalingų įgūdžių rinkinį. Priešingai, per pastaruosius kelerius metus atsirado naujas dizainas, vadinamas „data Lakehouse“.
Duomenų ežerų universalumas ir duomenų saugyklos duomenų valdymas sujungtas revoliucinėje duomenų saugojimo architektūroje, pavadintoje „duomenų ežero namai“.
Šiame įraše nuodugniai išnagrinėsime „Data Lakehouse“, įskaitant jo komponentus, funkcijas, architektūrą ir kitus aspektus.
Kas yra Data Lakehouse?
Kaip rodo pavadinimas, duomenų ežero namas yra naujo tipo duomenų architektūra, sujungianti duomenų ežerą su duomenų saugykla, kad būtų pašalinami kiekvieno trūkumai.
Iš esmės Lakehouse sistema naudoja nebrangią saugyklą, kad išlaikytų didžiulius duomenų kiekius originaliomis formomis, panašiai kaip duomenų ežeruose. Pridėjus metaduomenų sluoksnį parduotuvės viršuje taip pat suteikiama duomenų struktūra ir suteikiami duomenų valdymo įrankiai, pavyzdžiui, esantys duomenų saugyklose.
Jame saugomi didžiuliai kiekiai organizuotų, pusiau struktūrizuotų ir nestruktūruotų duomenų, kuriuos jie gauna iš įvairių verslo programų, sistemų ir programėlių, naudojamų visoje jų organizacijoje.
Didžiąją laiko dalį duomenų ežerai naudoja nebrangią saugojimo infrastruktūrą su failų programų programavimo sąsaja (API), kad saugotų duomenis atvirais, bendrais failų formatais.
Tai leidžia daugeliui komandų pasiekti visus įmonės duomenis per vieną sistemą įvairioms iniciatyvoms, tokioms kaip duomenų mokslas, mašininis mokymasis, ir verslo žvalgyba.
Savybės
- Nebrangus saugojimas. Duomenų ežero namas turi turėti galimybę saugoti duomenis nebrangioje objektų saugykloje, pvz "Google Cloud Saugykla, „Azure Blob Storage“, „Amazon Simple Storage Service“ arba savaime naudojant ORC arba „Parquet“.
- Galimybė optimizuoti duomenis: duomenų išdėstymo optimizavimas, kaupimas talpykloje ir indeksavimas yra keli pavyzdžiai, kaip duomenų bazė turi sugebėti optimizuoti duomenis išlaikant pradinį duomenų formatą.
- Operacijų metaduomenų sluoksnis: be būtinos nebrangios saugyklos, tai įgalina duomenų valdymo galimybes, kurios yra labai svarbios duomenų saugyklos veikimui.
- Declarative DataFrame API palaikymas: dauguma AI įrankių gali naudoti DataFrames neapdorotiems objektų saugyklos duomenims gauti. Declarative DataFrame API palaikymas padidina galimybę dinamiškai tobulinti duomenų pateikimą ir struktūrą reaguojant į konkrečią duomenų mokslo ar AI užduotį.
- ACID operacijų palaikymas: akronimas ACID, reiškiantis atomiškumą, nuoseklumą, izoliaciją ir patvarumą, yra esminis komponentas apibrėžiant operaciją ir užtikrinant duomenų nuoseklumą bei patikimumą. Tokios operacijos anksčiau buvo įmanomos tik duomenų saugyklose, tačiau Lakehouse siūlo galimybę juos panaudoti su duomenų ežerais taip pat. Naudojant kelis duomenų vamzdynus, įskaitant tuo pačiu metu vykstantį duomenų skaitymą ir rašymą, tai išsprendžia žemos pastarųjų duomenų kokybės problemą.
„Data Lakehouse“ elementai
Duomenų ežero architektūra aukštu lygiu suskirstyta į dvi pagrindines pakopas. Saugojimo sluoksnio duomenų priėmimą valdo Lakehouse platforma (ty duomenų ežeras).
Nereikia įkelti duomenų į duomenų saugyklą arba konvertuoti jų į patentuotą formatą, apdorojimo sluoksnis gali tiesiogiai pateikti duomenų saugojimo sluoksnyje užklausą naudodamas įvairius įrankius.
Tada BI programos, taip pat AI ir ML technologijos gali naudoti duomenis. Šis dizainas suteikia duomenų ežero ekonomiką, tačiau kadangi bet kuris apdorojimo variklis gali nuskaityti šiuos duomenis, įmonės turi laisvę paruoštus duomenis padaryti prieinamus analizei įvairiose sistemose. Procesoriaus našumą ir kainą galima pagerinti naudojant šį apdorojimo ir analizės metodą.
Dėl palaikomos duomenų bazės operacijos, kurios atitinka šiuos ACID (atomumo, nuoseklumo, izoliacijos ir patvarumo) kriterijus, architektūra taip pat leidžia daugeliui šalių pasiekti ir rašyti duomenis vienu metu sistemoje:
- Atomiškumas reiškia, kad užbaigus sandorį pavyksta arba visa operacija, arba nė viena iš jos. Jei procesas nutrūksta, tai padeda išvengti duomenų praradimo ar sugadinimo.
- nuoseklumas garantijų sandoriai vyksta nuspėjamai, nuosekliai. Ji palaiko duomenų vientisumą užtikrindama, kad visi duomenys būtų teisėti pagal iš anksto nustatytas taisykles.
- Izoliacija užtikrina, kad iki jos pabaigos jokia operacija negalės paveikti jokios kitos operacijos sistemoje. Tai leidžia daugeliui šalių skaityti ir rašyti iš tos pačios sistemos vienu metu, netrukdant viena kitai.
- Ilgaamžiškumas garantuoja, kad sistemos duomenų pakeitimai išliks ir po operacijos pabaigos, net ir sistemos gedimo atveju. Bet kokie pakeitimai, padaryti dėl sandorio, saugomi byloje amžinai.
Data Lakehouse architektūra
Databricks (jų Delta Lake koncepcijos novatorius ir kūrėjas) ir AWS yra du pagrindiniai duomenų ežero namų koncepcijos šalininkai. Todėl pasikliausime jų žiniomis ir įžvalga, kad apibūdintume ežerų architektūrinį išdėstymą.
„Data Lakehouse“ sistema paprastai turi penkis sluoksnius:
- Prarijus sluoksnis
- Sandėliavimo sluoksnis
- Metaduomenų sluoksnis
- API sluoksnis
- Vartojimo sluoksnis
Prarijus sluoksnis
Pirmasis sistemos sluoksnis yra atsakingas už duomenų rinkimą iš įvairių šaltinių ir siuntimą į saugojimo sluoksnį. Sluoksnis gali naudoti kelis protokolus, kad prisijungtų prie daugybės vidinių ir išorinių šaltinių, įskaitant paketinio ir srautinio duomenų apdorojimo pajėgumų derinimą, pvz.
- NoSQL duomenų bazės,
- failų bendrinimo
- CRM programos,
- svetaines
- IoT jutikliai,
- socialinė žiniasklaida,
- Programinės įrangos kaip paslaugos (SaaS) programos ir
- reliacinės duomenų bazių valdymo sistemos ir kt.
Šiuo metu galima naudoti tokius komponentus kaip „Apache Kafka“ duomenų srautiniam perdavimui ir „Amazon Data Migration Service“ („Amazon DMS“), skirta duomenims importuoti iš RDBMS ir NoSQL duomenų bazių.
Sandėliavimo sluoksnis
Ežerų namų architektūra skirta leisti įvairių tipų duomenis saugoti kaip objektus nebrangiose objektų parduotuvėse, pvz., AWS S3. Naudodami atvirus failų formatus, kliento įrankiai gali nuskaityti šiuos elementus tiesiai iš parduotuvės.
Tai leidžia daugeliui API ir vartojimo lygmens komponentų pasiekti ir naudoti tuos pačius duomenis. Metaduomenų sluoksnyje saugomos struktūrinių ir pusiau struktūrinių duomenų rinkinių schemos, kad komponentai galėtų jas pritaikyti duomenims, kai juos nuskaito.
Pavyzdžiui, „Hadoop Distributed File System“ (HDFS) platforma gali būti naudojama kuriant debesų saugyklos paslaugas, kurios padalija skaičiavimus ir saugojimą vietoje. Lakehouse idealiai tinka šioms paslaugoms.
Metaduomenų sluoksnis
Metaduomenų sluoksnis yra pagrindinė duomenų bazės sudedamoji dalis, kuri išskiria šį dizainą. Tai vienas katalogas, kuriame pateikiami metaduomenys (informacija apie kitus duomenų gabalus) visiems ežere saugomiems elementams ir leidžia vartotojams naudotis administravimo galimybėmis, tokiomis kaip:
- Nuosekli duomenų bazės versija yra matoma atliekant tuo pačius sandorius dėl ACID operacijų;
- talpyklos kaupimas debesies objektų saugyklos failams išsaugoti;
- duomenų struktūros indeksų įtraukimas naudojant indeksavimą, siekiant pagreitinti užklausų apdorojimą;
- naudojant nulinės kopijos klonavimą duomenų objektams kopijuoti; ir
- tam, kad išsaugotumėte tam tikras duomenų versijas ir pan., naudokite duomenų versijų nustatymą.
Be to, metaduomenų sluoksnis leidžia įgyvendinti schemų valdymą, naudoti DW schemų topologijas, pvz., žvaigždžių / snaigių schemas, ir teikti duomenų valdymo bei audito galimybes tiesiogiai duomenų ežere, taip padidinant viso duomenų srauto vientisumą.
Į schemos valdymą įtrauktos schemos evoliucijos ir vykdymo funkcijos. Atmetus bet kokius įrašus, kurie neatitinka lentelės schemos, schemos vykdymas leidžia vartotojams išlaikyti duomenų vientisumą ir kokybę.
Schemos evoliucija leidžia modifikuoti esamą lentelės schemą, kad ji atitiktų kintančius duomenis. Dėl vienos administravimo sąsajos duomenų ežero viršuje taip pat yra prieigos kontrolės ir audito galimybės.
API sluoksnis
Dabar yra dar vienas svarbus architektūros sluoksnis, kuriame yra daug API, kurias visi galutiniai vartotojai gali naudoti norėdami greičiau atlikti darbus ir gauti sudėtingesnę statistiką.
Naudojant metaduomenų API lengviau identifikuoti ir pasiekti duomenų elementus, reikalingus konkrečiai programai.
Kalbant apie mašininio mokymosi bibliotekas, kai kurios iš jų, pvz., TensorFlow ir Spark MLlib, gali skaityti atvirus failų formatus, pvz., Parquet, ir tiesiogiai pasiekti metaduomenų sluoksnį.
Tuo pačiu metu „DataFrame“ API suteikia daugiau galimybių optimizuoti, todėl programuotojai gali tvarkyti ir keisti išsklaidytus duomenis.
Vartojimo sluoksnis
„Power BI“, „Tableau“ ir kiti įrankiai bei programos yra priglobti vartojimo lygmenyje. Naudojant ežero namo dizainą, visi metaduomenys ir visi ežere saugomi duomenys yra pasiekiami kliento programoms.
Ežerų nameliu gali naudotis visi įmonės naudotojai, norėdami atlikti įvairius darbus analitinės operacijos, įskaitant verslo žvalgybos informacijos suvestinių kūrimą ir SQL užklausų vykdymą bei mašininio mokymosi užduotis.
„Data Lakehouse“ pranašumai
Organizacijos gali sukurti duomenų bazę, kad suvienodintų savo dabartinę duomenų platformą ir optimizuotų visą duomenų valdymo procesą. Išmontavus siloso užtvaras, jungiančias įvairius šaltinius, duomenų bazė gali pakeisti skirtingų sprendimų poreikį.
Palyginti su kuruojamais duomenų šaltiniais, ši integracija sukuria žymiai efektyvesnę visą procedūrą. Tai turi keletą privalumų:
- Mažiau administravimo: Užuot ištraukus duomenis iš neapdorotų duomenų ir paruošus juos naudoti duomenų saugykloje, duomenų bazė leidžia bet kokiems su ja susietiems šaltiniams turėti prieinamus ir sutvarkytus duomenis.
- Padidėjęs ekonominis efektyvumas: Duomenų bazės pastatytos naudojant šiuolaikinę infrastruktūrą, padalijančią skaičiavimą ir saugojimą, todėl nesunku išplėsti saugyklą nedidinant skaičiavimo galios. Vien naudojant nebrangią duomenų saugyklą pasiekiamas mastelio keitimas, kuris yra ekonomiškas.
- Geresnis duomenų valdymas: duomenų bazės yra sukurtos naudojant standartizuotą atvirą architektūrą, leidžiančią geriau kontroliuoti saugumą, metrikas, vaidmenimis pagrįstą prieigą ir kitus svarbius valdymo komponentus. Suvienodindami išteklius ir duomenų šaltinius, jie supaprastina ir pagerina valdymą.
- Supaprastinti standartai: Kadangi ryšys buvo labai apribotas devintajame dešimtmetyje, kai pirmą kartą buvo kuriamos duomenų saugyklos, lokalizuoti schemų standartai dažnai buvo kuriami įmonėse, netgi skyriuose. Duomenų telkiniai naudojasi tuo, kad daugelio tipų duomenims dabar taikomi atviri schemos standartai, sujungiant daugybę duomenų šaltinių su persidengiančia vienoda schema, kad būtų supaprastintos procedūros.
„Data Lakehouse“ trūkumai
Nepaisant visų duomenų ežerus supančių triukšmų, svarbu nepamiršti, kad idėja vis dar labai nauja. Prieš visiškai atsiduodami šiam naujam dizainui, būtinai pasverkite trūkumus.
- Monolitinė struktūra: „Viskas įskaičiuota“ namelio dizainas turi keletą privalumų, tačiau tai taip pat kelia tam tikrų problemų. Monolitinė architektūra dažnai sukelia prastą aptarnavimą visiems vartotojams ir gali būti nelanksti bei sunkiai prižiūrima. Paprastai architektai ir dizaineriai mėgsta modulinę architektūrą, kurią jie gali pritaikyti įvairiems naudojimo atvejams.
- Technologijos dar ne visai ten: galutinis tikslas apima daug mašininio mokymosi ir dirbtinio intelekto. Kad ežerai veiktų taip, kaip numatyta, šios technologijos turi būti toliau plėtojamos.
- Nedidelė pažanga, palyginti su esamomis struktūromis: Vis dar skeptiškai vertinama, kiek daugiau vertės iš tikrųjų prisidės ežerai. Kai kurie niekintojai teigia, kad ežero sandėlio konstrukcija suporuota su atitinkama automatizuota įranga gali pasiekti panašų efektyvumą.
„Data Lakehouse“ iššūkiai
Gali būti sunku pritaikyti duomenų ežero techniką. Dėl jo sudedamųjų dalių sudėtingumo neteisinga duomenų ežerą laikyti visa apimančia idealia struktūra arba „viena platforma viskam“.
Be to, dėl vis labiau taikomų duomenų ežerų, įmonės turės perkelti savo dabartines duomenų saugyklas į jas, remdamosi tik sėkmės pažadu be jokios akivaizdžios ekonominės naudos.
Jei per perdavimo procesą kyla kokių nors delsos problemų ar dingimų, tai gali būti brangu, užtruks daug laiko ir galbūt nesaugu.
Verslo vartotojai turi naudoti labai specializuotas technologijas, kaip teigia tam tikri pardavėjai, kurie aiškiai arba netiesiogiai parduoda sprendimus kaip duomenų bazes. Jie ne visada gali veikti su kitais įrankiais, susietais su duomenų ežeru sistemos centre, todėl gali kilti problemų.
Be to, gali būti sunku teikti analizę 24 valandas per parą, 7 dienas per savaitę, kai dirbama su verslui svarbiu darbo krūviu, todėl reikalinga ekonomiškai efektyvi mastelio keitimo infrastruktūra.
Išvada
Naujausia pastarųjų metų duomenų centrų įvairovė yra duomenų ežero namas. Ji integruoja įvairias sritis, tokias kaip informacinės technologijos, atvirojo kodo programinė įranga, Debesis kompiuterija, ir paskirstytus saugojimo protokolus.
Tai leidžia įmonėms centralizuotai saugoti visų rūšių duomenis iš bet kurios vietos, supaprastinant valdymą ir analizę. Data Lakehouse yra gana intriguojanti koncepcija.
Bet kuri įmonė turėtų didelį konkurencinį pranašumą, jei turėtų prieigą prie „viskas viename“ duomenų platformos, kuri būtų tokia pat greita ir efektyvi kaip duomenų saugykla, o taip pat būtų lanksti kaip duomenų ežeras.
Idėja vis dar vystoma ir išlieka palyginti nauja. Dėl to gali prireikti šiek tiek laiko nustatyti, ar kažkas gali išplisti.
Mums visiems turėtų būti įdomu, kokia kryptimi juda Lakehouse architektūra.
Palikti atsakymą