Saattaa olla hieman vaikeaa ottaa huomioon kaikkia saatavilla olevia palveluita ja arkkitehtonisia vaihtoehtoja, kun ajatellaan tietoalustoja.
Yritystietoalusta koostuu usein tietovarastoista, tietomalleista, datajärvistä ja raporteista, joilla jokaisella on tietty tarkoitus ja tarvittavat taidot. Sitä vastoin uusi muotoilu nimeltä data Lakehouse on ilmaantunut muutaman viime vuoden aikana.
Datajärvien monipuolisuus ja tietovaraston tiedonhallinta yhdistyvät vallankumouksellisessa tiedontallennusarkkitehtuurissa, jota kutsutaan nimellä "data Lakehouse".
Tutkimme data Lakehousea perusteellisesti tässä viestissä, mukaan lukien sen komponentit, ominaisuudet, arkkitehtuuri ja muut näkökohdat.
Mikä Data Lakehouse on?
Kuten nimestä voi päätellä, datajärvi on uudenlainen tietoarkkitehtuuri, joka yhdistää datajärven tietovarastoon ratkaisemaan kunkin puutteet erikseen.
Pohjimmiltaan Lakehouse-järjestelmä käyttää edullista tallennustilaa valtavien tietomäärien säilyttämiseen alkuperäisessä muodossaan, aivan kuten datajärvet. Metatietokerroksen lisääminen myymälän päälle antaa myös tietorakenteen ja mahdollistaa tiedonhallintatyökalut, kuten tietovarastoissa olevat.
Se tallentaa valtavat määrät organisoitua, osittain jäsenneltyä ja jäsentämätöntä dataa, jonka he saavat eri liiketoimintasovelluksista, järjestelmistä ja gadgeteista, joita he käyttävät koko organisaatiossaan.
Suurimman osan ajasta datajärvet käyttävät edullista tallennusinfrastruktuuria tiedostosovellusohjelmointirajapinnalla (API) tietojen tallentamiseen avoimissa, yleisissä tiedostomuodoissa.
Tämä mahdollistaa sen, että monet tiimit pääsevät käsiksi kaikkiin yrityksen tietoihin yhden järjestelmän kautta erilaisiin aloitteisiin, kuten datatieteeseen, koneoppiminen, ja business intelligence.
Ominaisuudet
- Edullinen säilytystila. Data Lakehousen on kyettävä tallentamaan tietoja edulliseen objektivarastointiin, kuten esim Google Cloud Tallennus, Azure Blob Storage, Amazon Simple Storage Service tai alkuperäisesti ORC:n tai Parquetin avulla.
- Tietojen optimointimahdollisuus: Tietojen asettelun optimointi, välimuisti ja indeksointi ovat muutamia esimerkkejä siitä, kuinka datajärven on kyettävä optimoimaan tiedot säilyttäen samalla tietojen alkuperäinen muoto.
- Tapahtumien metatietojen kerros: välttämättömän edullisen tallennustilan lisäksi tämä mahdollistaa tietovaraston suorituskyvyn kannalta ratkaisevan tärkeät tiedonhallintaominaisuudet.
- Tuki Declarative DataFrame API:lle: Suurin osa tekoälytyökaluista voi käyttää DataFrame-kehyksiä raa'an objektivaraston tietojen hakemiseen. Declarative DataFrame API:n tuki lisää kykyä parantaa dynaamisesti datan esitystapaa ja rakennetta vasteena tiettyyn datatieteen tai tekoälytehtävään.
- ACID-tapahtumien tuki: Lyhenne ACID, joka tarkoittaa atomiteettia, johdonmukaisuutta, eristyneisyyttä ja kestävyyttä, on kriittinen komponentti tapahtuman määrittelyssä ja tietojen johdonmukaisuuden ja luotettavuuden varmistamisessa. Tällaiset tapahtumat olivat aiemmin mahdollisia vain tietovarastoissa, mutta lakehouse tarjoaa mahdollisuuden hyödyntää niitä datajärvien kanssa yhtä hyvin. Useat dataputket, mukaan lukien samanaikainen datan luku ja kirjoitus, ratkaisee jälkimmäisen datan heikon laadun ongelman.
Data Lakehousen elementit
Data Lakehousen arkkitehtuuri on jaettu korkealla tasolla kahteen päätasoon. Tallennuskerroksen tiedonottoa ohjaa Lakehouse-alusta (eli datajärvi).
Ilman, että tietoja tarvitsee ladata tietovarastoon tai muuntaa niitä omaan muotoon, käsittelykerros pystyy sitten tiedustelemaan tallennuskerroksen tietoja suoraan käyttämällä erilaisia työkaluja.
Sitten BI-sovellukset sekä tekoäly- ja ML-tekniikat voivat käyttää tietoja. Tämä suunnittelu tarjoaa datajärven taloudellisuuden, mutta koska mikä tahansa prosessointikone pystyy lukemaan nämä tiedot, yrityksillä on vapaus saattaa valmistetut tiedot analysoitaviksi useiden järjestelmien avulla. Prosessorin suorituskykyä ja kustannuksia voidaan parantaa käyttämällä tätä menetelmää käsittelyyn ja analysointiin.
Koska arkkitehtuuri tukee tietokantatapahtumia, jotka noudattavat seuraavia ACID-kriteerejä (atomisuus, johdonmukaisuus, eristäminen ja kestävyys), arkkitehtuuri mahdollistaa myös sen, että monet osapuolet voivat käyttää ja kirjoittaa tietoja samanaikaisesti järjestelmän sisällä:
- atomisuuden viittaa siihen, että joko koko tapahtuma tai ei mikään siitä onnistuu tapahtuman suorittamisen aikana. Jos prosessi keskeytyy, tämä auttaa välttämään tietojen katoamisen tai korruption.
- Johdonmukaisuus takaa, että liiketoimet tapahtuvat ennustettavasti ja johdonmukaisesti. Se ylläpitää tietojen eheyttä varmistamalla, että kaikki tiedot ovat laillisia ennalta määritettyjen sääntöjen mukaisesti.
- Eristäminen varmistaa, että ennen kuin se on valmis, mikään muu tapahtuma ei voi vaikuttaa järjestelmän sisällä. Näin useat osapuolet voivat lukea ja kirjoittaa samasta järjestelmästä samanaikaisesti häiritsemättä toisiaan.
- Kestävyys takaa, että järjestelmän tietoihin tehdyt muutokset jatkuvat tapahtuman päätyttyä, jopa järjestelmävian sattuessa. Kaikki tapahtuman aiheuttamat muutokset säilytetään arkistossa ikuisesti.
Data Lakehouse -arkkitehtuuri
Databricks (heidän Delta Lake -konseptinsa keksijä ja suunnittelija) ja AWS ovat kaksi pääasiallista datajärvirakennuksen kannattajaa. Luotamme siis heidän tietoihinsa ja näkemyksiinsä kuvaillessamme järvitalojen arkkitehtonista asettelua.
Data Lakehouse -järjestelmässä on yleensä viisi kerrosta:
- Nielemiskerros
- Säilytyskerros
- Metatietokerros
- API-taso
- Kulutuskerros
Nielemiskerros
Järjestelmän ensimmäinen kerros vastaa tietojen keräämisestä eri lähteistä ja lähettämisestä tallennuskerrokseen. Kerros voi käyttää useita protokollia muodostaakseen yhteyden lukuisiin sisäisiin ja ulkoisiin lähteisiin, mukaan lukien erä- ja suoratoistotietojen käsittelyominaisuuksien yhdistäminen, kuten esim.
- NoSQL-tietokannat,
- tiedostojen osuudet
- CRM-sovellukset,
- sivustot,
- IoT-anturit,
- sosiaalinen media,
- Software as a Service (SaaS) -sovellukset ja
- relaatiotietokannan hallintajärjestelmät jne.
Tässä vaiheessa voidaan käyttää komponentteja, kuten Apache Kafka tietojen suoratoistoon ja Amazon Data Migration Service (Amazon DMS) tietojen tuomiseen RDBMS- ja NoSQL-tietokannoista.
Säilytyskerros
Lakehouse-arkkitehtuurin on tarkoitus mahdollistaa erityyppisten tietojen tallentaminen kohteina edullisiin esinevarastoihin, kuten AWS S3. Avoimia tiedostomuotoja käyttämällä asiakastyökalut voivat sitten lukea nämä kohteet suoraan kaupasta.
Tämä mahdollistaa useiden sovellusliittymien ja kulutuskerroksen komponenttien pääsyn ja hyödyntämisen samoja tietoja. Metatietokerros tallentaa strukturoitujen ja puolirakenteisten tietojoukkojen skeemat, jotta komponentit voivat soveltaa niitä tietoihin lukeessaan niitä.
Esimerkiksi Hadoop Distributed File System (HDFS) -alustaa voidaan käyttää pilvivarastopalveluiden rakentamiseen, jotka jakavat tietojenkäsittelyn ja tallennustilan paikan päällä. Lakehouse sopii mainiosti näihin palveluihin.
Metatietokerros
Metatietokerros on datajärven peruskomponentti, joka erottaa tämän suunnittelun. Se on yksittäinen luettelo, joka tarjoaa metadataa (tietoa muista tietopaloista) kaikista järveen tallennetuista kohteista ja antaa käyttäjille mahdollisuuden käyttää hallintaominaisuuksia, kuten:
- Samanaikaiset tapahtumat näkevät tietokannan johdonmukaisen version ACID-tapahtumien ansiosta;
- välimuisti pilviobjektien tallennustiedostojen tallentamiseksi;
- tietorakenneindeksien lisääminen indeksoinnin avulla kyselyn käsittelyn nopeuttamiseksi;
- nollakopion kloonauksen käyttäminen dataobjektien monistamiseen; ja
- tallentaaksesi tietyt versiot tiedosta jne. käytä tietojen versiointia.
Lisäksi metatietokerros mahdollistaa skeemanhallinnan toteutuksen, DW-skeematopologioiden, kuten tähti/lumihiutale-skeemojen, käytön sekä tietojen hallinnan ja auditointikyvyn tarjoamisen suoraan datajärvelle, mikä parantaa koko dataputken eheyttä.
Kaavan hallintaan sisältyy ominaisuuksia skeeman kehittämiseen ja täytäntöönpanoon. Hylkäämällä kaikki kirjoitukset, jotka eivät täytä taulukon skeemaa, skeeman valvonta antaa käyttäjille mahdollisuuden säilyttää tietojen eheys ja laatu.
Kaavion evoluutio mahdollistaa taulukon nykyisen kaavion muokkaamisen muuttuvien tietojen mukaiseksi. Datajärven päällä olevan yhden hallintaliittymän ansiosta myös kulunvalvonta- ja auditointimahdollisuudet ovat mahdollisia.
API-taso
Toinen tärkeä arkkitehtuurin kerros on nyt läsnä, ja se isännöi useita sovellusliittymiä, joita kaikki loppukäyttäjät voivat käyttää töiden suorittamiseen nopeammin ja kehittyneempien tilastojen saamiseksi.
Metatietojen sovellusliittymien käyttö helpottaa tietyn sovelluksen tarvitsemien tietokohteiden tunnistamista ja käyttöä.
Koneoppimiskirjastojen osalta jotkut niistä, kuten TensorFlow ja Spark MLlib, voivat lukea avoimia tiedostomuotoja, kuten Parquet, ja käyttää suoraan metatietokerrosta.
Samaan aikaan DataFrame API:t tarjoavat paremmat mahdollisuudet optimointiin, jolloin ohjelmoijat voivat järjestää ja muuttaa hajallaan olevaa dataa.
Kulutuskerros
Power BI, Tableau ja muut työkalut ja sovellukset sijaitsevat kulutuskerroksen alla. Lakehouse-suunnittelun ansiosta kaikki järvessä säilytettävät metatiedot ja tiedot ovat asiakassovellusten käytettävissä.
Järvitaloa voivat käyttää kaikki yrityksen käyttäjät kaikenlaisten töiden suorittamiseen analytiikkatoiminnot, mukaan lukien liiketoimintatiedon hallintapaneelien luominen sekä SQL-kyselyjen ja koneoppimistehtävien suorittaminen.
Data Lakehousen edut
Organisaatiot voivat luoda datajärven yhtenäistääkseen nykyisen tietoalustan ja optimoidakseen koko tiedonhallintaprosessinsa. Purkamalla eri lähteitä yhdistävät siilon esteet, datajärvi voi korvata erillisen ratkaisun tarpeen.
Verrattuna kuratoituihin tietolähteisiin tämä integrointi tuottaa huomattavasti tehokkaamman päästä päähän -menettelyn. Tällä on useita etuja:
- Vähemmän hallintoa: Sen sijaan, että poimittaisiin dataa raakatiedoista ja valmistettaisiin niitä käytettäväksi tietovarastossa, datajärvi mahdollistaa sen, että kaikki siihen linkitetyt lähteet voivat saada tietonsa käyttöön ja järjestettyinä käytettäväksi.
- Lisääntynyt kustannustehokkuus: Data Lakehouses on rakennettu käyttämällä nykyaikaista infrastruktuuria, joka jakaa laskennan ja tallennuksen, mikä tekee tallennustilan laajentamisesta helppoa laskentatehoa lisäämättä. Pelkästään edullisen tiedontallennustilan käyttö johtaa skaalautumiseen, joka on kustannustehokasta.
- Parempi tiedonhallinta: Data Lakehouses on rakennettu standardoidulla avoimella arkkitehtuurilla, mikä mahdollistaa paremman hallinnan turvallisuudesta, mittareista, roolipohjaisesta pääsystä ja muista tärkeistä hallintakomponenteista. Yhdistämällä resurssit ja tietolähteet ne yksinkertaistavat ja parantavat hallintoa.
- Yksinkertaistetut standardit: Koska yhteys oli erittäin rajoitettu 1980-luvulla, jolloin tietovarastot kehitettiin ensimmäisen kerran, paikallisia mallistandardeja kehitettiin usein yritysten sisällä, jopa osastojen sisällä. Data Lakehouses hyödyntää sitä tosiasiaa, että monen tyyppisillä tiedoilla on nyt avoimet skeeman standardit, ja ne käyttävät useita tietolähteitä päällekkäisen yhtenäisen skeeman kanssa prosessien virtaviivaistamiseksi.
Data Lakehousen haitat
Huolimatta kaikesta datajärvitaloja ympäröivästä huhusta, on tärkeää pitää mielessä, että idea on vielä hyvin uusi. Muista punnita haitat ennen kuin sitoudut täysin tähän uuteen malliin.
- Monoliittinen rakenne: Lakehousen all-inclusive-suunnittelu tarjoaa useita etuja, mutta se aiheuttaa myös joitain ongelmia. Monoliittinen arkkitehtuuri johtaa usein huonoon palveluun kaikille käyttäjille ja voi olla jäykkää ja vaikeasti ylläpidettävää. Tyypillisesti arkkitehdit ja suunnittelijat pitävät modulaarisemmasta arkkitehtuurista, jota he voivat muokata erilaisiin käyttötarkoituksiin.
- Tekniikka ei ole vielä aivan perillä: lopullinen tavoite sisältää huomattavan määrän koneoppimista ja tekoälyä. Ennen kuin järvitalot voivat toimia odotetulla tavalla, näitä teknologioita on kehitettävä edelleen.
- Ei merkittävää edistystä olemassa oleviin rakenteisiin verrattuna: On edelleen huomattavaa skeptisyyttä sen suhteen, kuinka paljon arvokkaampia järvitalot todella antavat. Jotkut arvostelijat väittävät, että järvivaraston suunnittelu yhdistettynä asianmukaisiin automatisoituihin laitteisiin voi saavuttaa vertailukelpoisen tehokkuuden.
Data Lakehousen haasteet
Data Lakehouse -tekniikan käyttöönotto voi olla vaikeaa. Sen komponenttien monimutkaisuuden vuoksi on väärin pitää datajärvitaloa kaiken kattavana ihanteellisena rakenteena tai "yksi alustana kaikelle".
Lisäksi datajärvien yleistyvän käytön vuoksi yritysten on siirrettävä nykyiset tietovarastonsa niille luottaen vain lupaukseen menestymisestä ilman todistettavaa taloudellista hyötyä.
Jos siirtoprosessin aikana ilmenee latenssiongelmia tai katkoksia, se saattaa olla kallista, aikaa vievää ja ehkä vaarallista.
Yrityskäyttäjien on omaksuttava pitkälle erikoistuneita tekniikoita tiettyjen toimittajien mukaan, jotka nimenomaisesti tai epäsuorasti markkinoivat ratkaisuja datajärvitaloina. Nämä eivät välttämättä aina toimi muiden työkalujen kanssa, jotka on linkitetty järjestelmän keskellä olevaan datajärveen, mikä lisää ongelmia.
Lisäksi voi olla vaikeaa tarjota 24/7-analytiikkaa liiketoimintakriittisten työkuormien aikana, mikä edellyttää infrastruktuuria, jossa on kustannustehokas skaalautuvuus.
Yhteenveto
Viime vuosien uusin palvelinkeskusten valikoima on data Lakehouse. Se yhdistää useita aloja, kuten tietotekniikkaa, avoimen lähdekoodin ohjelmistoja, cloud computing, ja hajautetut tallennusprotokollat.
Sen avulla yritykset voivat keskitetysti tallentaa kaikenlaisia tietoja mistä tahansa, mikä yksinkertaistaa hallintaa ja analysointia. Data Lakehouse on melko kiehtova käsite.
Jokaisella yrityksellä olisi merkittävä kilpailuetu, jos se saisi käyttöönsä all-in-one-tietoalustan, joka on yhtä nopea ja tehokas kuin tietovarasto, mutta samalla joustava kuin datajärvi.
Idea on edelleen kehitteillä ja on suhteellisen uusi. Tämän seurauksena voi kestää jonkin aikaa sen selvittämiseen, voiko jokin levitä laajalle vai ei.
Meidän kaikkien pitäisi olla uteliaita siitä, mihin suuntaan Lakehouse-arkkitehtuuri on menossa.
Jätä vastaus