Video: Webinar: „Enterprise Readiness mit Hadoop - Infrastrukturen für Big Data“ 2024
De goedkope kosten van opslag voor Hadoop plus de mogelijkheid om Hadoop-gegevens met SQL te ondervragen, maakt Hadoop tot de belangrijkste bestemming voor archiefgegevens. Deze gebruikscasus heeft een lage impact op uw organisatie omdat u uw Hadoop-vaardigheidsset kunt bouwen op gegevens die niet zijn opgeslagen op systemen die de prestaties van een bedrijf dekken.
Bovendien hoeft u niet hard te werken om bij de gegevens te komen. (Omdat gearchiveerde gegevens normaal worden opgeslagen op systemen met een laag gebruik, is het eenvoudiger om dat te bereiken dan gegevens die 'in de schijnwerpers staan' op systemen die prestatiemissies kritisch zijn, zoals datawarehouses.) Als u Hadoop al als landing gebruikt zone, je hebt de basis voor je archief! U bewaart gewoon wat u wilt archiveren en verwijdert wat u niet wilt.
Als je denkt aan de landingszone van de Hadoop, breidt het doorzoekbare archief, weergegeven in de figuur, de waarde van Hadoop uit en begint stukken te integreren die waarschijnlijk al in je onderneming voorkomen. Het is een geweldig voorbeeld van het vinden van schaalvoordelen en het afhalen van kosten met Hadoop.
Hier verbindt de archiefcomponent de bestemmingszone en het datawarehouse. De gegevens die worden gearchiveerd, zijn afkomstig uit het magazijn en worden vervolgens opgeslagen in het Hadoop-cluster, dat ook de bestemmingszone verzorgt. Kortom, u kunt dezelfde Hadoop-cluster gebruiken om gegevens te archiveren en als uw landingszone te fungeren.
De belangrijkste Hadoop-technologie die u zou gebruiken om de archivering uit te voeren, is Sqoop, die de te archiveren gegevens uit het datawarehouse naar Hadoop kan verplaatsen. U moet overwegen welk formulier u wilt dat de gegevens in uw Hadoop-cluster opnemen. Over het algemeen zijn gecomprimeerde Hive-bestanden een goede keuze.
U kunt de gegevens van de magazijnstructuren natuurlijk in een andere vorm transformeren (bijvoorbeeld een genormaliseerde vorm om overtolligheid te verminderen), maar dit is over het algemeen geen goed idee. Door de gegevens in dezelfde structuur te houden als in het magazijn, wordt het veel eenvoudiger om een volledige datasetquery uit te voeren in de gearchiveerde gegevens in Hadoop en de actieve gegevens in het magazijn.
Het concept van het bevragen van zowel de actieve als gearchiveerde gegevenssets brengt nog een andere overweging naar voren: hoeveel gegevens moet u archiveren? Er zijn echt twee veelvoorkomende keuzes: archiveer alles terwijl gegevens worden toegevoegd en gewijzigd in het datawarehouse of archiveer alleen de gegevens die u als koud beschouwt.
Alles archiveren heeft het voordeel dat u eenvoudig query's vanuit één interface in de hele dataset kunt uitvoeren - zonder een volledig archief moet u een federatieve queryoplossing bedenken waarbij u de resultaten van het archief en het actieve datawarehouse.
Maar het nadeel is dat regelmatige updates van de hot data van uw datawarehouse hoofdpijn zouden veroorzaken voor het op Hadoop gebaseerde archief. De reden hiervoor is dat voor het wijzigen van gegevens in afzonderlijke rijen en kolommen het verwijderen en opnieuw catalogiseren van bestaande gegevenssets in de groothandel is vereist.
Nu archiveringsgegevens zijn opgeslagen in uw op Hadoop gebaseerde landingszone (aangenomen dat u een optie gebruikt zoals de eerder gecomprimeerde Hive-bestanden), kunt u hiernaar vragen. Dit is waar de SQL op Hadoop-oplossingen interessant kan worden.
Een uitstekend voorbeeld van wat mogelijk is, is dat de analysetools (rechts in de figuur) direct rapporten of analyses uitvoeren op de gearchiveerde gegevens die zijn opgeslagen in Hadoop. Dit is niet ter vervanging van het datawarehouse - Hadoop zou immers niet in staat zijn om de prestatiekenmerken van het magazijn te evenaren voor het ondersteunen van honderden of meer gelijktijdige gebruikers die complexe vragen stellen.
Het gaat er hier om dat u rapportagetools tegen Hadoop kunt gebruiken om te experimenteren en nieuwe vragen kunt stellen om te beantwoorden in een speciaal magazijn of op een speciale markt.
Wanneer u uw eerste op Hadoop gebaseerde project voor het archiveren van magazijngegevens start, breek de huidige processen dan niet totdat u ze volledig hebt getest op uw nieuwe Hadoop-oplossing. Met andere woorden, als uw huidige warehousingstrategie is om naar tape te archiveren, moet u dat proces op zijn plaats houden en de gegevens dubbel archiveren in Hadoop en tape totdat u het scenario volledig hebt getest (wat doorgaans het herstel van de magazijngegevens zou omvatten in geval van een magazijnstoring).
Hoewel u (op korte termijn) twee archiefrepository's onderhoudt, beschikt u over een robuuste infrastructuur die is getest en getest voordat u een beproefd en waar proces ontmantelt. Dit proces kan ervoor zorgen dat u in loondienst blijft - bij uw huidige werkgever.
Deze gebruikssituatie is eenvoudig omdat het bestaande magazijn niet wordt gewijzigd. Het bedrijfsdoel blijft hetzelfde: lagere opslag- en licentiekosten door zelden gebruikte gegevens naar een archief te migreren. Het verschil in dit geval is dat de technologie achter het archief Hadoop is in plaats van offline opslag, zoals tape.
Daarnaast zijn verschillende archiefleveranciers gestart met het opnemen van Hadoop in hun oplossingen (bijvoorbeeld door hun eigen archiefbestanden op HDFS te laten staan), dus verwacht dat de mogelijkheden op dit gebied snel uitbreiden.
Als u Hadoop-vaardigheden ontwikkelt (zoals het uitwisselen van gegevens tussen Hadoop en relationele databases en het opvragen van gegevens in HDFS), kunt u deze gebruiken om grotere problemen aan te pakken, zoals analyseprojecten, die extra waarde kunnen bieden voor de Hadoop-investering van uw organisatie.
