Video: Hops - Hadoop Open Platform-As-a-Service – RISE SICS 2025
Den rimelige kostnaden for lagring for Hadoop pluss muligheten til å spørre Hadoop-data med SQL, gjør Hadoop til det primære målet for arkivdata. Dette brukstilfellet har liten innvirkning på organisasjonen din, fordi du kan begynne å bygge Hadoop ferdighetssett på data som ikke er lagret på ytelses-kritiske systemer.
Dessuten trenger du ikke å jobbe hardt for å få tilgang til dataene. (Siden arkiverte data normalt lagres på systemer med lav bruk, er det lettere å komme seg enn data som er i "rampelyset" på ytelses-kritiske systemer, for eksempel datalager.) Hvis du allerede bruker Hadoop som landing sonen, du har grunnlaget for ditt arkiv! Du behold bare hva du vil arkivere og slette det du ikke gjør.
Hvis du tenker på Hadops landingsson, utvider forespørselsarkivet som vist i figuren, verdien av Hadoop og begynner å integrere brikker som sannsynligvis allerede finnes i bedriften. Det er et godt eksempel på å finne stordriftsfordeler og kostnadsuttaksmuligheter ved hjelp av Hadoop.
Her kobler arkivkomponenten landingssonen og datalageret. Dataene som arkiveres kommer fra lageret og lagres deretter i Hadoop-klyngen, som også sørger for landingssonen. Kort sagt, du kan bruke den samme Hadoop-klyngen til å arkivere data og fungere som landingssone.
Nøkkelen Hadoop-teknologi du vil bruke til å utføre arkiveringen, er Sqoop, som kan flytte dataene som skal arkiveres fra datalageret til Hadoop. Du må vurdere hvilken form du vil ha dataene til å ta i Hadoop-klyngen din. Generelt er komprimerte Hive-filer et godt valg.
Du kan selvsagt omforme dataene fra lagerstrukturen til en annen form (for eksempel en normalisert form for å redusere redundans), men dette er generelt ikke en god ide. Å holde dataene i samme struktur som det som er i lageret, vil gjøre det mye enklere å utføre et fullstendig datasett på tvers av de arkiverte dataene i Hadoop og de aktive dataene som finnes i lageret.
Konseptet med å spørre både de aktive og arkiverte datasettene gir en annen vurdering: Hvor mye data skal du arkivere? Det er virkelig to vanlige valg: arkiver alt ettersom data er lagt til og endret i datalageret, eller arkiver bare dataene du anser for å være kalde.
Arkivering av alt har den fordel at du enkelt kan utstede spørringer fra ett enkelt grensesnitt på tvers av hele datasettet - uten et fullt arkiv, må du finne ut en føderert spørringsløsning der du må forene resultatene fra arkivet og det aktive datalageret.
Men ulempen her er at regelmessige oppdateringer av datalagerets varme data vil føre til hodepine for Hadoop-baserte arkiver. Dette skyldes at eventuelle endringer i data i individuelle rader og kolonner ville kreve engros sletning og re-katalogisering av eksisterende datasett.
Nå som arkivdata lagres i Hadoop-baserte landingssonen din (forutsatt at du bruker et alternativ som de komprimerte Hive-filene nevnt tidligere), kan du spørre det. Dette er hvor SQL på Hadoop-løsninger kan bli interessant.
Et utmerket eksempel på hva som er mulig er for analyseverktøyene (til høyre i figuren) å direkte utføre rapporter eller analyser på arkiverte data lagret i Hadoop. Dette er ikke å erstatte datalageret - Hadoop ville trods alt ikke kunne matche lagerets ytelsesegenskaper for å støtte hundrevis eller flere samtidige brukere som stillte komplekse spørsmål.
Poenget her er at du kan bruke rapporteringsverktøy mot Hadoop til å eksperimentere og komme opp med nye spørsmål for å svare på et dedikert varehus eller mart.
Når du starter ditt første Hadoop-baserte prosjekt for arkivering av lagerdata, må du ikke bryte de nåværende prosessene før du har testet dem fullt ut på den nye Hadoop-løsningen. Med andre ord, hvis din nåværende lagringsstrategi er å arkivere til tape, hold den prosessen på plass, og dobbelt arkiver dataene i Hadoop og tape til du har testet scenariet fullt ut (som vanligvis vil inkludere gjenoppretting av lagerdataene i tilfelle av et lagerfeil).
Selv om du opprettholder (på kort sikt) to arkivbeholdere, har du en robust infrastruktur på plass og testet før du avviker en prøvd og sann prosess. Denne prosessen kan sikre at du forblir ansatt - med din nåværende arbeidsgiver.
Denne brukstilfelle er enkel fordi det ikke er noen endring i eksisterende lager. Bedriftsmålet er fortsatt det samme: Billigere lagrings- og lisensieringskostnader ved å overføre sjelden brukte data til et arkiv. Forskjellen i dette tilfellet er at teknologien bak arkivet er Hadoop istedenfor offline lagring, som tape.
I tillegg har ulike arkivleverandører begynt å inkorporere Hadoop i sine løsninger (for eksempel å la deres proprietære arkivfiler ligge på HDFS), så forvent evner i dette området å utvides snart.
Når du utvikler Hadoop-ferdigheter (som å utveksle data mellom Hadoop og relationsdatabaser og spørre data i HDFS), kan du bruke dem til å takle større problemer, for eksempel analyseprosjekter, som kan gi ytterligere verdi for organisasjonens Hadoop-investering.
