Bygge datavarehus og datainnsjø i AWS

Datavarehus. Datainnsjø. Hus ved sjøen. Hvis ingen av disse ordene resonerer med deg i det minste, så er jobben din tydeligvis ikke relatert til data.

Imidlertid ville det være ganske urealistisk premiss siden i dag, alt er relatert til data, virker som. Eller hvordan bedriftslederne liker å beskrive det:

• Datasentrisk og datadrevet virksomhet.
• Data hvor som helst, når som helst, uansett.

Den viktigste ressursen

Det virker som om data har blitt den mest verdifulle ressursen for flere og flere selskaper. Jeg husker store bedrifter alltid genererte mye data, terabyte med nye data hver måned. Det var fortsatt 10-15 år siden. Men nå kan du enkelt generere den mengden data i løpet av få dager. Man kan spørre om det virkelig er nødvendig, selv om det er noe innhold noen vil bruke. Og ja, det er det definitivt ikke 😃.

Ikke alt innholdet vil være til noen nytte, og noen deler ikke en gang en gang. Ofte var jeg vitne til i frontlinjen hvordan selskaper genererte en enorm mengde data bare for å bli ubrukelig etter en vellykket lasting.

Men det er ikke aktuelt lenger. Datalagring – nå i skyen – er billig, datakildene vokser eksponentielt, og i dag kan ingen forutsi hva de vil trenge ett år senere når nye tjenester er ombord på systemet. På det tidspunktet kan selv de gamle dataene bli verdifulle.

Derfor er strategien å lagre så mye data som mulig. Men også i så effektiv form som mulig. Slik at data ikke bare kan lagres effektivt, men også forespørres, gjenbrukes eller transformeres og distribueres videre.

La oss ta en titt på tre innfødte måter hvordan du kan oppnå dette i AWS:

• Athena Database – billig og effektiv, men enkel måte å lage en datainnsjø i skyen på.
• Redshift Database – en seriøs skyversjon av et datavarehus som har potensial til å erstatte flertallet av de nåværende lokale løsningene, uten å kunne ta igjen den eksponentielle veksten av data.
• Databricks – en kombinasjon av en datainnsjø og datavarehus i én enkelt løsning, med litt bonus på toppen av det hele.

Data Lake av AWS Athena

Kilde: aws.amazon.com

Datasjøen er et sted hvor du kan lagre innkommende data i ustrukturert, semistrukturert eller strukturert form på en rask måte. Samtidig forventer du ikke at disse dataene blir endret når de er lagret. I stedet vil du at de skal være så atomære og uforanderlige som mulig. Kun dette vil sikre størst potensial for gjenbruk i senere faser. Hvis du mister denne atomegenskapen til dataene rett etter den første innlastingen i en datainnsjø, er det ingen måte å få tilbake denne tapte informasjonen igjen.

AWS Athena er en database med lagring direkte på S3-bøtter og uten serverklynger som kjører i bakgrunnen. Det betyr at det er en veldig billig datainnsjø-tjeneste. Strukturerte filformater som parkett eller CSV-filer (comma-separated value) opprettholder dataorganisasjonen. S3-bøtten inneholder filene, og Athena refererer til dem hver gang prosesser velger data fra databasen.

Athena støtter ikke ulike funksjoner som ellers anses som standard, for eksempel oppdateringserklæringer. Dette er grunnen til at du må se på Athena som et veldig enkelt alternativ. På den annen side hjelper det deg med å forhindre modifikasjon av atomdatasjøen din rett og slett fordi du ikke kan 😐.

Den støtter indeksering og partisjonering, noe som gjør den brukbar for effektiv kjøring av utvalgte setninger og for å lage logisk separate databiter (for eksempel atskilt med dato eller nøkkelkolonner). Den kan også skaleres horisontalt veldig enkelt, da dette er like komplekst som å legge til nye bøtter i infrastrukturen.

Fordeler og ulemper

Fordelene å vurdere:

• Det faktum at Athena er billig (består kun av S3-bøtter og SQL-brukskostnader per bruk) gir den største fordelen. Hvis du vil bygge en rimelig datainnsjø i AWS, er dette det.
• Som en innfødt tjeneste kan Athena enkelt integreres med andre nyttige AWS-tjenester som Amazon QuickSight for datavisualisering eller AWS Glue Data Catalog for å lage vedvarende strukturerte metadata.
• Best for å kjøre ad hoc-spørringer over en stor mengde strukturerte eller ustrukturerte data uten å vedlikeholde en hel infrastruktur rundt det.

Ulempene å vurdere:

• Athena er ikke spesielt effektiv når det gjelder å returnere komplekse utvalgte spørringer raskt, spesielt hvis spørringene ikke følger datamodellens forutsetninger om hvordan du designet for å be om dataene fra datasjøen.
• Dette gjør den også mindre fleksibel med tanke på potensielle fremtidige endringer i datamodellen.
• Athena støtter ikke noen ekstra avanserte funksjoner ut av esken, og hvis du vil at noe spesifikt skal være en del av tjenesten, må du implementere det på toppen.
• Hvis du forventer datainnsjødatabruken i et mer avansert presentasjonslag, er ofte det eneste valget å kombinere det med en annen databasetjeneste som er mer egnet for det formålet, som AWS Aurora eller AWS Dynamo DB.

Formål og reell brukssak

Velg Athena hvis målet er å lage en enkel datainnsjø uten noen avanserte datavarehuslignende funksjoner. Så, for eksempel, hvis du ikke forventer seriøse høyytende analysespørringer som kjører regelmessig over datasjøen. I stedet er det å ha en pool av uforanderlige data med enkel utvidelse av datalagring prioritet.

Du trenger ikke lenger bekymre deg for mye om plassmangelen. Selv kostnadene for S3 bøttelagring kan reduseres ytterligere ved å implementere en datalivssykluspolicy. Dette betyr i utgangspunktet å flytte dataene på tvers av forskjellige typer S3-bøtter, mer rettet mot arkivformål med langsommere returtider for inntak, men lavere kostnader.

En flott funksjon med Athena er at den automatisk oppretter en fil som består av data som er en del av et resultat av SQL-spørringen din. Du kan deretter ta denne filen og bruke den til ethvert formål. Så det er et godt alternativ hvis du har mange lambdatjenester som viderebehandler dataene i flere trinn. Hvert lambda-utfall vil automatisk være resultatet i et strukturert filformat som input klar for påfølgende behandling.

Athena er et godt alternativ i situasjoner der en stor mengde rådata kommer til skyinfrastrukturen din, og du ikke trenger å behandle det ved lasting. Det betyr at alt du trenger er rask lagring i skyen i en lettfattelig struktur.

Et annet bruksområde ville være å opprette en dedikert plass for dataarkiveringsformål for en annen tjeneste. I et slikt tilfelle ville Athena DB blitt et billig sikkerhetskopieringssted for alle dataene du ikke trenger akkurat nå, men det kan endre seg i fremtiden. På dette tidspunktet vil du bare innta dataene og sende dem videre.

Data Warehouse av AWS Redshift

Kilde: aws.amazon.com

Et datavarehus er et sted hvor data lagres på en veldig strukturert måte. Enkel å laste og trekke ut. Hensikten er å kjøre et stort antall svært komplekse spørringer, og slå sammen mange tabeller via komplekse sammenføyninger. Ulike analytiske funksjoner er på plass for å beregne ulike statistikker over eksisterende data. Det endelige målet er å trekke ut fremtidige spådommer og fakta som kan utnyttes i virksomheten fremover, ved å bruke eksisterende data.

Redshift er et fullverdig datavarehussystem. Med klyngeservere for tuning og skalering – horisontalt og vertikalt og et databaselagringssystem optimert for raske tilbakevendinger av komplekse spørringer. Selv om du i dag kan kjøre Redshift i serverløs modus også. Det er ingen filer på S3 eller noe lignende. Dette er en standard databaseklyngeserver med eget lagringsformat.

Den har ytelsesovervåkingsverktøy på plass rett ut av esken, sammen med tilpassbare dashbordberegninger du kan bruke og se på for å finjustere ytelsen for ditt bruksområde. Administrasjonen er også tilgjengelig via egne dashboards. Det krever litt innsats å forstå alle mulige funksjoner og innstillinger og hvordan de påvirker klyngen. Men likevel er det ingen steder så komplisert som administrasjonen av Oracle-servere pleide å være i tilfellet med lokale løsninger.

Selv om det er forskjellige AWS-grenser i Redshift som setter noen grenser for hvordan den skal brukes på daglig basis (for eksempel harde grenser for antall samtidige aktive brukere eller økter i en databaseklynge), er det faktum at operasjoner er utført veldig raskt hjelper til en viss grad å omgå disse grensene.

Fordeler og ulemper

Fordelene å vurdere:

• Native AWS skydatavarehustjeneste som er enkel å integrere med andre tjenester.
• Et sentralt sted for lagring, overvåking og inntak av ulike typer datakilder fra svært forskjellige kildesystemer.
• Hvis du noen gang ønsket å ha et serverløst datavarehus uten infrastruktur for å vedlikeholde det, kan du nå det.
• Optimalisert for analyser og rapportering med høy ytelse. I motsetning til en datainnsjø-løsning, er det en sterk relasjonsdatamodell for lagring av alle innkommende data.
• Redshift databasemotor har sin opprinnelse i PostgreSQL, som sikrer høy kompatibilitet med andre databasesystemer.
• Veldig nyttige COPY- og UNLOAD-setninger for å laste og losse data fra og til S3-bøtter.

Ulempene å vurdere:

• Redshift støtter ikke en stor mengde samtidige aktive økter. Øktene vil bli satt på vent og behandlet sekvensielt. Selv om det kanskje ikke er et problem i de fleste tilfeller, siden operasjonene er veldig raske, er det en begrensende faktor i systemer med mange aktive brukere.
• Selv om Redshift støtter mange funksjoner tidligere kjent fra modne Oracle-systemer, er det fortsatt ikke på samme nivå. Noen av de forventede funksjonene er kanskje ikke der (som DB-utløsere). Eller Redshift støtter dem i ganske begrenset form (som materialiserte visninger).
• Når du trenger en mer avansert tilpasset databehandlingsjobb, må du lage den fra bunnen av. Mesteparten av tiden, bruk Python eller Javascript-kodespråk. Det er ikke så naturlig som PL/SQL i tilfellet med Oracle-systemet, der selv funksjonen og prosedyrene bruker et språk som ligner veldig på SQL-spørringer.

Formål og reell brukssak

Redshift kan være din sentrale lagringsplass for alle de forskjellige datakildene som tidligere bodde utenfor skyen. Det er en gyldig erstatning for tidligere Oracles datavarehusløsninger. Siden det også er en relasjonsdatabase, er migreringen fra Oracle til og med en ganske enkel operasjon.

Hvis du har eksisterende datavarehusløsninger mange steder som egentlig ikke er enhetlige når det gjelder tilnærming, struktur eller et forhåndsdefinert sett med vanlige prosesser som skal kjøres over dataene, er Redshift et godt valg.

Det vil bare gi deg en mulighet til å slå sammen alle de forskjellige datavarehussystemene fra forskjellige steder og land under ett tak. Du kan fortsatt skille dem per land slik at dataene forblir sikre og tilgjengelige kun for de som trenger dem. Men samtidig vil det tillate deg å bygge en enhetlig lagerløsning som dekker alle bedriftsdata.

Et annet tilfelle kan være hvis målet er å bygge en datavarehusplattform med omfattende støtte fra selvbetjening. Du kan forstå det som et sett med prosessering som individuelle systembrukere kan bygge. Men samtidig er de aldri en del av den felles plattformløsningen. Det betyr at slike tjenester vil forbli tilgjengelige bare for skaperen eller gruppen av personer som er definert av den opprettede. De vil ikke påvirke resten av brukerne på noen måte.

Sjekk vår sammenligning mellom Datalake og Datawarehouse.

Lakehouse av Databricks på AWS

Kilde: databricks.com

Lakehouse er et begrep som virkelig er bundet til Databricks-tjenesten. Selv om det ikke er en innfødt AWS-tjeneste, lever og opererer den i AWS-økosystemet veldig bra og gir forskjellige alternativer for hvordan du kobler til og integrerer med andre AWS-tjenester.

Databricks har som mål å koble sammen (tidligere) svært forskjellige områder:

• En løsning for datainnsjølagring av ustrukturerte, semistrukturerte og strukturerte data.
• En løsning for datavarehusstrukturerte og raskt tilgjengelige spørringsdata (også kalt Delta Lake).
• En løsning som støtter analyse og maskinlæring over datainnsjøen.
• Datastyring for alle områdene ovenfor med sentralisert administrasjon og ferdige verktøy for å støtte produktiviteten for ulike typer utviklere og brukere.

Det er en vanlig plattform som dataingeniører, SQL-utviklere og maskinlæringsdataforskere kan bruke samtidig. Hver av gruppene har også et sett med verktøy som de kan bruke for å utføre oppgavene sine.

Så Databricks tar sikte på en universalløsning, og prøver å kombinere fordelene med datainnsjøen og datavarehuset til én enkelt løsning. På toppen av det gir den verktøyene for å teste og kjøre maskinlæringsmodeller direkte over allerede bygde datalagre.

Fordeler og ulemper

Fordelene å vurdere:

• Databricks er en svært skalerbar dataplattform. Den skaleres avhengig av arbeidsbelastningens størrelse, og den gjør det til og med automatisk.
• Det er et samarbeidsmiljø for dataforskere, dataingeniører og forretningsanalytikere. Å ha muligheten til å gjøre alt dette på samme plass og sammen er en stor fordel. Ikke bare fra et organisatorisk perspektiv, men det bidrar også til å spare en annen kostnad som ellers er nødvendig for separate miljøer.
• AWS Databricks integreres sømløst med andre AWS-tjenester, som Amazon S3, Amazon Redshift og Amazon EMR. Dette lar brukere enkelt overføre data mellom tjenester og dra nytte av hele spekteret av AWS-skytjenester.

Ulempene å vurdere:

• Databricks kan være kompliserte å sette opp og administrere, spesielt for brukere som er nye innen stordatabehandling. Det krever et betydelig nivå av teknisk ekspertise for å få mest mulig ut av plattformen.
• Selv om Databricks er kostnadseffektivt i forhold til sin betal-som-du-gå-prismodell, kan det fortsatt være dyrt for store databehandlingsprosjekter. Kostnadene ved å bruke plattformen kan raskt øke, spesielt hvis brukere trenger å skalere opp ressursene sine.
• Databricks tilbyr en rekke forhåndsbygde verktøy og maler, men dette kan også være en begrensning for brukere som trenger flere tilpasningsmuligheter. Plattformen er kanskje ikke egnet for brukere som krever mer fleksibilitet og kontroll over arbeidsflytene for big data-behandling.

Formål og reell brukssak

AWS Databricks er best egnet for store selskaper med svært store datamengder. Her kan det dekke kravet om å laste og kontekstualisere ulike datakilder fra ulike eksterne systemer.

Ofte er kravet å levere data i sanntid. Dette betyr fra det tidspunktet dataene vises i kildesystemet, at prosessene skal plukkes opp umiddelbart og behandle og lagre dataene i Databricks umiddelbart eller med bare minimal forsinkelse. Hvis forsinkelsen er noe over ett minutt, regnes det som nesten sanntidsbehandling. I alle fall er begge scenariene ofte oppnåelige med Databricks-plattformen. Dette er hovedsakelig på grunn av den omfattende mengden adaptere og sanntidsgrensesnitt som kobles til forskjellige andre AWS-native tjenester.

Databricks kan også enkelt integreres med Informatica ETL-systemer. Når organisasjonssystemet allerede bruker Informatica-økosystemet mye, ser Databricks ut som et godt kompatibelt tillegg til plattformen.

Siste ord

Ettersom datavolumet fortsetter å vokse eksponentielt, er det godt å vite at det finnes løsninger som kan takle det effektivt. Det som en gang var et mareritt å administrere og vedlikeholde krever nå svært lite administrasjonsarbeid. Teamet kan fokusere på å skape verdi ut av dataene.

Avhengig av dine behov, velg bare tjenesten som kan håndtere det. Mens AWS Databricks er noe du sannsynligvis må holde deg til etter at avgjørelsen er tatt, er de andre alternativene ganske mer fleksible, selv om de er mindre kapable, spesielt deres serverløse moduser. Det er ganske enkelt å migrere til en annen løsning senere.