Video: Hops - Hadoop Open Platform-As-a-Service – RISE SICS 2025
Den billige pris for lagring til Hadoop plus muligheden for at forespørge Hadoop-data med SQL gør Hadoop til den primære destination for arkivdata. Denne brugs sag har en lille indflydelse på din organisation, fordi du kan begynde at opbygge din Hadoop-færdighed på data, der ikke er gemt på ydeevne-missionskritiske systemer.
Desuden behøver du ikke arbejde hårdt for at få adgang til dataene. (Da arkiverede data normalt gemmes på systemer med lav brug, er det lettere at komme videre end data, der er i "rampelyset" på ydeevne-kritiske systemer, som datalagre.) Hvis du allerede bruger Hadoop som landing zone, du har grundlaget for dit arkiv! Du behold blot hvad du vil arkivere og slette, hvad du ikke gør.
Hvis du tænker på Hadops landingszone, udvider forespørgselsarkivet, som vist i figuren, værdien af Hadoop og begynder at integrere stykker, der sandsynligvis allerede findes i din virksomhed. Det er et godt eksempel på at finde stordriftsfordele og omkostningsmuligheder ved at bruge Hadoop.
Her forbinder arkivkomponenten landingsområdet og datalageret. De data, der arkiveres, stammer fra lageret og opbevares derefter i Hadoop-klyngen, som også forsyner landingsområdet. Kort sagt, du kan bruge samme Hadoop-klynge til at arkivere data og fungere som din landingszone.
Den vigtigste Hadoop-teknologi, du vil bruge til at udføre arkiveringen, er Sqoop, som kan flytte dataene, der skal arkiveres fra datalageret til Hadoop. Du skal overveje, hvilken form du vil have dataene til at tage i din Hadoop-klynge. Generelt er komprimerede Hive-filer et godt valg.
Du kan selvfølgelig omdanne dataene fra lagerstrukturerne til en anden form (for eksempel en normaliseret form for at reducere redundans), men det er generelt ikke en god idé. Ved at holde dataene i samme struktur som i lageret bliver det meget nemmere at udføre en komplet datasæt forespørgsel på tværs af de arkiverede data i Hadoop og de aktive data, der er på lageret.
Begrebet spørger både de aktive og arkiverede datasæt giver en anden overvejelse: Hvor mange data skal du arkivere? Der er virkelig to fælles valg: arkiver alt som data tilføjes og ændres i datalageret, eller arkiver kun de data, du anser for at være kolde.
Arkivering af alt har den fordel, at du nemt kan udstede forespørgsler fra en enkelt grænseflade på tværs af hele datasættet - uden et fuldt arkiv, skal du finde ud af en fødereret forespørgselsløsning, hvor du skal forene resultaterne fra arkivet og det aktive datalager.
Men ulempen her er, at regelmæssige opdateringer af dit datalagers varme data ville medføre hovedpine for Hadoop-baserede arkiver. Dette skyldes, at eventuelle ændringer i data i individuelle rækker og kolonner kræver grove sletning og re-katalogisering af eksisterende datasæt.
Nu er arkivdata gemt i din Hadoop-baserede landingszone (forudsat at du bruger en indstilling som de komprimerede Hive-filer, der er nævnt tidligere), kan du spørge det. Det er her, hvor SQL på Hadoop-løsninger kan blive interessante.
Et glimrende eksempel på, hvad der er muligt, er, at analyseværktøjerne (til højre i figuren) direkte kan udføre rapporter eller analyser på de arkiverede data, der er gemt i Hadoop. Dette er ikke at erstatte data warehouse - Hadoop ville trods alt ikke kunne matche lagerets præstationsegenskaber til at understøtte hundredvis af eller flere samtidige brugere, der stillede komplekse spørgsmål.
Pointen her er, at du kan bruge rapporteringsværktøjer mod Hadoop til at eksperimentere og komme med nye spørgsmål til at svare i et dedikeret lager eller mart.
Når du starter dit første Hadoop-baserede projekt til arkivering af lagerdata, må du ikke bryde de nuværende processer, før du har testet dem fuldt ud på din nye Hadoop-løsning. Med andre ord, hvis din nuværende lagerstrategi er at arkivere til bånd, skal du holde denne proces på plads og dobbelt arkivere dataene i Hadoop og tape, indtil du har testet scenariet fuldt ud (hvilket typisk vil omfatte genopretning af lagerdataene i tilfælde af et lagerfejl).
Selv om du opretholder (på kort sigt) to arkivbeholdninger, har du en robust infrastruktur på plads og testet, før du frigiver en forsøgt og sand proces. Denne proces kan sikre, at du forbliver ansat - hos din nuværende arbejdsgiver.
Denne brugssag er enkel, fordi der ikke er nogen ændring i det eksisterende lager. Forretningsmålet er stadig det samme: Billigere lager- og licensomkostninger ved at overføre sjældent brugte data til et arkiv. Forskellen i dette tilfælde er, at teknologien bag arkivet er Hadoop snarere end offline-opbevaring, som tape.
Derudover er forskellige arkivleverandører begyndt at indarbejde Hadoop i deres løsninger (for eksempel at lade deres proprietære arkivfiler opholde sig på HDFS), så forvent kapaciteterne på dette område at udvides snart.
Når du udvikler Hadoop-færdigheder (som udveksling af data mellem Hadoop og relationsdatabaser og forespørgselsdata i HDFS) kan du bruge dem til at løse større problemer, såsom analyseprojekter, som kunne give yderligere værdi for din organisations Hadoop-investering.
