Përmbajtje[Fshih][Shfaqje]
Mund të jetë pak e vështirë të merren parasysh të gjitha shërbimet e disponueshme dhe opsionet arkitekturore kur mendoni për platformat e të dhënave.
Një platformë e të dhënave të ndërmarrjes shpesh përbëhet nga depo të dhënash, modele të dhënash, liqene të dhënash dhe raporte, secila me një qëllim të veçantë dhe grup aftësish të nevojshme. Në të kundërt, një dizajn i ri i quajtur data lakehouse është shfaqur gjatë viteve të fundit.
Shkathtësia e liqeneve të të dhënave dhe menaxhimi i të dhënave të magazinës së të dhënave kombinohen në një arkitekturë revolucionare të ruajtjes së të dhënave të quajtur "shtëpia e liqenit të të dhënave".
Ne do të shqyrtojmë në thellësi të dhënat e lakehouse në këtë postim, duke përfshirë përbërësit e tij, veçoritë, arkitekturën dhe aspekte të tjera.
Çfarë është Data Lakehouse?
Siç nënkupton edhe emri, një shtëpi liqenore e të dhënave është një lloj i ri i arkitekturës së të dhënave që kombinon një liqen të dhënash me një depo të dhënash për të zgjidhur mangësitë e secilit veç e veç.
Në thelb, sistemi lakehouse përdor ruajtje të lirë për të mbajtur sasi masive të të dhënave në format e tyre origjinale, njësoj si liqenet e të dhënave. Shtimi i shtresës së meta të dhënave në krye të dyqanit gjithashtu jep strukturën e të dhënave dhe fuqizon mjetet e menaxhimit të të dhënave si ato që gjenden në magazinat e të dhënave.
Ai ruan vëllimet e mëdha të të dhënave të organizuara, gjysmë të strukturuara dhe të pastrukturuara që ata marrin nga aplikacionet, sistemet dhe pajisjet e ndryshme të biznesit të përdorura në të gjithë organizatën e tyre.
Në shumicën e rasteve, liqenet e të dhënave përdorin infrastrukturën e ruajtjes me kosto të ulët me një ndërfaqe programimi të aplikacionit të skedarëve (API) për të ruajtur të dhënat në formate të hapura, gjenerike të skedarëve.
Kjo bën të mundur që shumë ekipe të kenë akses në të gjitha të dhënat e kompanisë përmes një sistemi të vetëm për një sërë iniciativash, të tilla si shkenca e të dhënave, Mësimi makinë, dhe inteligjencën e biznesit.
karakteristika
- Ruajtje me kosto të ulët. Një shtëpi liqenore e të dhënave duhet të jetë në gjendje të ruajë të dhëna në ruajtjen e objekteve të lira, si p.sh Google Cloud Magazinimi, Ruajtja Azure Blob, Shërbimi i ruajtjes së thjeshtë të Amazon, ose duke përdorur në mënyrë origjinale ORC ose parket.
- Aftësia për optimizimin e të dhënave: Optimizimi i paraqitjes së të dhënave, ruajtja në memorie dhe indeksimi janë disa shembuj se si një shtëpi liqenore e të dhënave duhet të jetë në gjendje të optimizojë të dhënat duke ruajtur formatin origjinal të të dhënave.
- Një shtresë e meta të dhënave transaksionale: Përveç ruajtjes thelbësore me kosto të ulët, kjo mundëson aftësitë e menaxhimit të të dhënave thelbësore për performancën e magazinës së të dhënave.
- Mbështetje për API-në Deklarative DataFrame: Shumica e mjeteve të AI mund të përdorin DataFrames për të tërhequr të dhënat e ruajtjes së objekteve të papërpunuara. Mbështetja për API Deklarative DataFrame rrit aftësinë për të përmirësuar në mënyrë dinamike paraqitjen dhe strukturën e të dhënave në përgjigje të shkencës së caktuar të të dhënave ose detyrës së AI.
- Mbështetje për transaksionet ACID: Akronimi ACID, i cili qëndron për atomicitetin, qëndrueshmërinë, izolimin dhe qëndrueshmërinë, është një komponent kritik në përcaktimin e një transaksioni dhe sigurimin e qëndrueshmërisë dhe besueshmërisë së të dhënave. Transaksione të tilla më parë ishin të mundshme vetëm në depot e të dhënave, por lakehouse ofron mundësinë për t'i përdorur ato me liqene të dhënash gjithashtu. Me disa tubacione të dhënash duke përfshirë leximin dhe shkrimin e të dhënave të njëkohshme, kjo zgjidh problemin e cilësisë së ulët të të dhënave të këtyre të fundit.
Elementet e Data Lakehouse
Arkitektura e shtëpisë së liqenit të të dhënave është e ndarë në dy nivele kryesore në një nivel të lartë. Marrja e të dhënave të shtresës së ruajtjes kontrollohet nga platforma Lakehouse (dmth. liqeni i të dhënave).
Pa pasur nevojë të ngarkojë të dhënat në një depo të dhënash ose t'i konvertojë ato në një format të pronarit, shtresa e përpunimit është më pas në gjendje të kërkojë të dhënat në shtresën e ruajtjes drejtpërdrejt duke përdorur një sërë mjetesh.
Më pas, aplikacionet BI, si dhe teknologjitë AI dhe ML, mund të përdorin të dhënat. Ekonomia e një liqeni të dhënash sigurohet nga ky dizajn, por për shkak se çdo motor përpunues mund t'i lexojë këto të dhëna, bizneset kanë lirinë t'i bëjnë të dhënat e përgatitura të aksesueshme për analiza nga një sërë sistemesh. Performanca dhe kostoja e procesorit mund të përmirësohen duke përdorur këtë metodë për përpunim dhe analizë.
Për shkak të mbështetjes së saj për transaksionet e bazës së të dhënave që i përmbahen kritereve të mëposhtme ACID (atomiciteti, konsistenca, izolimi dhe qëndrueshmëria), arkitektura gjithashtu u mundëson shumë palëve të aksesojnë dhe të shkruajnë të dhëna njëkohësisht brenda sistemit:
- Atomiciteti i referohet faktit që ose transaksioni i plotë ose asnjë prej tij, ka sukses gjatë kryerjes së një transaksioni. Në rast se një proces ndërpritet, kjo ndihmon në shmangien e humbjes ose korrupsionit të të dhënave.
- konsistencë garanton që transaksionet të ndodhin në një mënyrë të parashikueshme dhe të qëndrueshme. Ai ruan integritetin e të dhënave duke siguruar që çdo e dhënë është legjitime në përputhje me rregullat e paracaktuara.
- Izolim siguron që, deri sa të përfundojë, asnjë transaksion nuk mund të ndikohet nga ndonjë transaksion tjetër brenda sistemit. Kjo lejon shumë palë të lexojnë dhe shkruajnë nga i njëjti sistem njëkohësisht pa ndërhyrë me njëra-tjetrën.
- Qëndrueshmëri garanton që ndryshimet në të dhënat në një sistem vazhdojnë të ekzistojnë pas përfundimit të një transaksioni, edhe në rast të një dështimi të sistemit. Çdo ndryshim i shkaktuar nga një transaksion mbahet në dosje përgjithmonë.
Arkitektura e Data Lakehouse
Databricks (novatori dhe projektuesi i konceptit të tyre Delta Lake) dhe AWS janë dy avokatët kryesorë për konceptin e një shtëpie liqenore të dhënash. Kështu, ne do të mbështetemi në njohuritë dhe njohuritë e tyre për të përshkruar paraqitjen arkitekturore të shtëpive të liqenit.
Një sistem i të dhënave lakehouse zakonisht do të ketë pesë shtresa:
- Shtresa e gëlltitjes
- Shtresa e ruajtjes
- Shtresa e meta të dhënave
- Shtresa API
- Shtresa e konsumit
Shtresa e gëlltitjes
Shtresa e parë e sistemit është përgjegjëse për mbledhjen e të dhënave nga burime të ndryshme dhe dërgimin e tyre në shtresën e ruajtjes. Shtresa mund të përdorë disa protokolle për t'u lidhur me burime të shumta të brendshme dhe të jashtme, duke përfshirë kombinimin e aftësive të përpunimit të të dhënave në grup dhe transmetim, si p.sh.
- Bazat e të dhënave NoSQL,
- ndarjet e skedarëve
- aplikacionet CRM,
- faqet e internetit,
- Sensorët IoT,
- mediat sociale,
- Aplikacionet Softuer si shërbim (SaaS) dhe
- sistemet e menaxhimit të bazës së të dhënave relacionale etj.
Në këtë pikë, mund të përdoren komponentë si Apache Kafka për transmetimin e të dhënave dhe Shërbimi i Migrimit të të Dhënave të Amazon (Amazon DMS) për importimin e të dhënave nga bazat e të dhënave RDBMS dhe NoSQL.
Shtresa e ruajtjes
Arkitektura lakehouse ka për qëllim të mundësojë ruajtjen e llojeve të ndryshme të të dhënave si objekte në dyqane objektesh të lira, si AWS S3. Duke përdorur formatet e skedarëve të hapur, mjetet e klientit mund t'i lexojnë më pas këto artikuj direkt nga dyqani.
Kjo bën të mundur që shumë API dhe komponentë të shtresës së konsumit të kenë akses dhe të përdorin të njëjtat të dhëna. Shtresa e meta të dhënave ruan skemat për grupe të dhënash të strukturuara dhe gjysmë të strukturuara në mënyrë që komponentët t'i zbatojnë ato në të dhënat ndërsa i lexojnë.
Platforma Hadoop Distributed File System (HDFS), për shembull, mund të përdoret për të ndërtuar shërbime të ruajtjes së reve kompjuterike që ndajnë llogaritjen dhe ruajtjen brenda ambienteve. Lakehouse është i përshtatshëm në mënyrë ideale për këto shërbime.
Shtresa e meta të dhënave
Shtresa e meta të dhënave është komponenti themelor i një shtëpie liqenore të të dhënave që e dallon këtë dizajn. Është një katalog i vetëm që ofron meta të dhëna (informacione rreth pjesëve të tjera të të dhënave) për të gjithë artikujt e ruajtur në liqen dhe i lejon përdoruesit të përdorin aftësi administruese si:
- Një version i qëndrueshëm i bazës së të dhënave shihet nga transaksionet e njëkohshme falë transaksioneve ACID;
- caching për të ruajtur skedarët e ruajtjes së objekteve cloud;
- shtimi i indekseve të strukturës së të dhënave duke përdorur indeksimin për të shpejtuar përpunimin e pyetjeve;
- duke përdorur klonimin me zero kopje për të kopjuar objektet e të dhënave; dhe
- për të ruajtur disa versione të të dhënave, etj., përdorni versionimin e të dhënave.
Për më tepër, shtresa e meta të dhënave mundëson zbatimin e menaxhimit të skemave, përdorimin e topologjive të skemave DW si skemat yje/flokë dëbore dhe ofrimin e qeverisjes së të dhënave dhe aftësisë audituese direkt në liqenin e të dhënave, duke rritur integritetin e të gjithë tubacionit të të dhënave.
Karakteristikat për evoluimin dhe zbatimin e skemës përfshihen në menaxhimin e skemës. Duke refuzuar çdo shkrim që nuk plotëson skemën e tabelës, zbatimi i skemës u mundëson përdoruesve të ruajnë integritetin dhe cilësinë e të dhënave.
Evolucioni i skemës lejon që skema aktuale e tabelës të modifikohet për të akomoduar ndryshimin e të dhënave. Për shkak të një ndërfaqe të vetme administrimi në majë të liqenit të të dhënave, ka gjithashtu mundësi kontrolli dhe auditimi të aksesit.
Shtresa API
Një tjetër shtresë thelbësore e arkitekturës është tani e pranishme, duke pritur një numër të API-ve që të gjithë përdoruesit përfundimtarë mund t'i përdorin për të kryer punë më shpejt dhe për të marrë statistika më të sofistikuara.
Përdorimi i API-ve të meta të dhënave e bën më të lehtë identifikimin dhe aksesin e artikujve të të dhënave të nevojshme për një aplikacion të caktuar.
Për sa i përket bibliotekave të mësimit të makinerive, disa prej tyre, si TensorFlow dhe Spark MLlib, mund të lexojnë formate të hapura skedarësh si Parquet dhe të hyjnë drejtpërdrejt në shtresën e meta të dhënave.
Në të njëjtën kohë, DataFrame API ofrojnë shanse më të mëdha për optimizim, duke u mundësuar programuesve të organizojnë dhe ndryshojnë të dhënat e shpërndara.
Shtresa e konsumit
Power BI, Tableau dhe mjete dhe aplikacione të tjera janë të vendosura nën shtresën e konsumit. Me dizajnin e lakehouse, të gjitha meta të dhënat dhe të gjitha të dhënat që mbahen në një liqen janë të aksesueshme për aplikacionet e klientit.
Shtëpia e liqenit mund të përdoret nga të gjithë përdoruesit brenda një kompanie për të kryer të gjitha llojet e operacionet analitike, duke përfshirë krijimin e paneleve të inteligjencës së biznesit dhe ekzekutimin e pyetjeve SQL dhe detyrave të mësimit të makinerive.
Avantazhet e Data Lakehouse
Organizatat mund të krijojnë një shtëpi liqeni të dhënash për të unifikuar platformën e tyre aktuale të të dhënave dhe për të optimizuar të gjithë procesin e tyre të menaxhimit të të dhënave. Duke çmontuar barrierat e silosit që lidhin burime të ndryshme, një shtëpi liqenore e të dhënave mund të zëvendësojë nevojën për zgjidhje të dallueshme.
Krahasuar me burimet e të dhënave të kuruara, ky integrim prodhon një procedurë dukshëm më efektive nga fundi në fund. Kjo ka disa përparësi:
- Më pak administrim: Në vend që të nxjerrin të dhëna nga të dhënat e papërpunuara dhe t'i përgatisin ato për përdorim brenda një magazine të dhënash, një lakehouse e të dhënave lejon që çdo burim i lidhur me të të ketë të dhënat e tyre të disponueshme dhe të organizuara për t'u përdorur.
- Rritja e efektivitetit të kostos: Shtëpitë e liqeneve të të dhënave janë ndërtuar duke përdorur infrastrukturën bashkëkohore që ndan llogaritjen dhe ruajtjen, duke e bërë të thjeshtë zgjerimin e ruajtjes pa rritur fuqinë llogaritëse. Vetëm përdorimi i ruajtjes së lirë të të dhënave rezulton në shkallëzueshmëri që është me kosto efektive.
- Qeverisje më e mirë e të dhënave: Shtëpitë e liqeneve të të dhënave janë ndërtuar me arkitekturë të hapur të standardizuar, duke lejuar më shumë kontroll mbi sigurinë, metrikat, aksesin e bazuar në role dhe komponentë të tjerë të rëndësishëm të menaxhimit. Duke unifikuar burimet dhe burimet e të dhënave, ato thjeshtojnë dhe përmirësojnë qeverisjen.
- Standarde të thjeshtuara: Meqenëse lidhja ishte shumë e kufizuar në vitet 1980, kur u zhvilluan për herë të parë magazinat e të dhënave, standardet e lokalizuara të skemave u zhvilluan shpesh brenda bizneseve, madje edhe departamenteve. Shtëpitë e liqeneve të të dhënave përdorin faktin se shumë lloje të dhënash tani kanë standarde të hapura për skemën duke gëlltitur burime të shumta të dhënash me skemën uniforme të mbivendosur për të thjeshtuar procedurat.
Disavantazhet e Data Lakehouse
Pavarësisht nga të gjitha rrëmujët që rrethojnë shtëpitë e liqeneve të të dhënave, është e rëndësishme të mbani në mend se ideja është ende shumë e re. Sigurohuni që të peshoni disavantazhet përpara se të angazhoheni plotësisht në këtë dizajn të ri.
- Struktura monolitike: Dizajni gjithëpërfshirës i një shtëpie liqeni ofron disa përparësi, por gjithashtu ngre disa probleme. Arkitektura monolitike shpesh çon në shërbim të dobët për të gjithë përdoruesit dhe mund të jetë e ngurtë dhe e vështirë për t'u mirëmbajtur. Në mënyrë tipike, arkitektët dhe projektuesit pëlqejnë një arkitekturë më modulare që mund ta personalizojnë për raste të ndryshme përdorimi.
- Teknologjia nuk është ende atje: qëllimi përfundimtar përfshin një sasi të konsiderueshme të mësimit të makinerive dhe inteligjencës artificiale. Përpara se shtëpitë e liqenit të mund të funksionojnë siç është parashikuar, këto teknologji duhet të zhvillohen më tej.
- Jo një përparim domethënës mbi strukturat ekzistuese: Ka ende një skepticizëm të konsiderueshëm se sa më shumë vlerë do të kontribuojnë në fakt shtëpitë e liqenit. Disa kundërshtarë pretendojnë se një dizajn i magazinës së liqenit i shoqëruar me pajisjet e duhura të automatizuara mund të arrijë efikasitet të krahasueshëm.
Sfidat e Data Lakehouse
Mund të jetë e vështirë të adoptohet teknika e të dhënave lakehouse. Për shkak të ndërlikimit të pjesëve përbërëse të tij, është e gabuar të shihet shtëpia e liqenit të të dhënave si një strukturë ideale gjithëpërfshirëse ose "një platformë për gjithçka", për një.
Për më tepër, për shkak të adoptimit në rritje të liqeneve të të dhënave, bizneset do të duhet të zhvendosin magazinat e tyre aktuale të të dhënave në to, duke u mbështetur vetëm në një premtim suksesi pa përfitime të dukshme ekonomike.
Nëse ka ndonjë problem vonesë ose ndërprerje gjatë gjithë procesit të transferimit, kjo mund të përfundojë duke qenë e shtrenjtë, kërkon kohë dhe ndoshta e pasigurt.
Përdoruesit e biznesit duhet të përqafojnë teknologji shumë të specializuara, sipas shitësve të caktuar që tregtojnë shprehimisht ose në mënyrë implicite zgjidhjet si shtëpi liqene të dhënash. Këto mund të mos funksionojnë gjithmonë me mjete të tjera të lidhura me liqenin e të dhënave në qendër të sistemit, duke shtuar problemet.
Për më tepër, mund të jetë e vështirë të ofrohen analiza 24/7 gjatë ekzekutimit të ngarkesave kritike për biznesin, gjë që kërkon infrastrukturë me shkallëzim me kosto efektive.
Përfundim
Shumëllojshmëria më e re e qendrave të të dhënave në vitet e fundit është data lakehouse. Ai integron një sërë fushash, të tilla si teknologjia e informacionit, softueri me burim të hapur, cloud informatikë, dhe protokollet e ruajtjes së shpërndarë.
Ai u mundëson bizneseve të ruajnë në mënyrë qendrore të gjitha llojet e të dhënave nga çdo vend, duke thjeshtuar menaxhimin dhe analizën. Data Lakehouse është një koncept mjaft intrigues.
Çdo firmë do të kishte një avantazh të konsiderueshëm konkurrues nëse do të kishte akses në një platformë të dhënash gjithëpërfshirëse që do të ishte po aq e shpejtë dhe efikase sa një depo e të dhënave, ndërkohë që do të ishte po aq fleksibël sa një liqen të dhënash.
Ideja është ende në zhvillim dhe mbetet relativisht e re. Si rezultat, mund të duhet pak kohë për të përcaktuar nëse diçka mund të përhapet apo jo.
Ne të gjithë duhet të jemi kurioz për drejtimin që po shkon arkitektura e Lakehouse.
Lini një Përgjigju