Video: Analyzing Big Data with Open Source R and Hadoop 2024
Den billiga kostnaden för lagring för Hadoop plus möjligheten att fråga Hadoop-data med SQL gör Hadoop till huvuddestinationen för arkivdata. Det här användarfallet har en liten inverkan på din organisation eftersom du kan börja bygga din Hadoop-färdighet på data som inte lagras på prestationsmissionskritiska system.
Dessutom behöver du inte jobba hårt för att få tillgång till data. (Eftersom arkiverade data normalt lagras på system med låg användning, är det lättare att komma vidare än data som ligger i "rampljuset" på prestationsmissionskritiska system, som datalager.) Om du redan använder Hadoop som landning zon, du har grunden för ditt arkiv! Du behåll bara vad du vill arkivera och ta bort vad du inte gör.
Om du tänker på Hadops landningszon, utökar det frågeteiska arkivet som visas i figuren värdet på Hadoop och börjar integrera bitar som sannolikt redan finns i ditt företag. Det är ett bra exempel på att hitta stordriftsfördelar och kostnader för uttag av kostnader genom att använda Hadoop.
Här kopplar arkivkomponenten landningszonen och datalagret. Data som arkiveras härstammar i lageret och lagras sedan i Hadoop-klustret, vilket också tillhandahåller landningszonen. Kort sagt, du kan använda samma Hadoop-kluster för att arkivera data och fungera som din landningszon.
Den viktigaste Hadoop-tekniken som du skulle använda för att utföra arkiveringen är Sqoop, som kan flytta data som ska arkiveras från datalageret till Hadoop. Du måste överväga vilken form du vill att uppgifterna ska ta i ditt Hadoop-kluster. I allmänhet är komprimerade Hive-filer ett bra val.
Du kan självklart omvandla data från lagerstrukturerna till någon annan form (till exempel en normaliserad form för att minska redundans), men det är i allmänhet inte en bra idé. Att hålla uppgifterna i samma struktur som i lageret gör det mycket lättare att utföra en fullständig datasökningsfråga över de arkiverade data i Hadoop och de aktiva data som finns i lagret.
Begreppet frågar både de aktiva och arkiverade dataseten ger ett annat övervägande: hur mycket data ska du arkivera? Det finns egentligen två vanliga val: arkivera allt eftersom data läggs till och ändras i datalagret, eller arkivera bara de data du anser vara kalla.
Arkivering av allt har fördelen att du enkelt kan utfärda frågor från ett enda gränssnitt över hela datasatsen - utan ett fullständigt arkiv måste du ta reda på en federerad söklösning där du måste facka resultaten från arkivet och det aktiva datalageret.
Men nackdelen här är att regelbundna uppdateringar av ditt datalagrings heta data skulle orsaka huvudvärk för Hadoop-baserade arkiv. Detta beror på att eventuella ändringar av data i enskilda rader och kolumner skulle kräva gross borttagning och omkatalogering av befintliga datamängder.
Nu sparas arkivdata i din Hadoop-baserade landningszon (förutsatt att du använder ett alternativ som de komprimerade Hive-filerna som nämns tidigare), du kan fråga det. Det är här SQL-lösningen på Hadoop-lösningar kan bli intressant.
Ett utmärkt exempel på vad som är möjligt är att analysverktygen (till höger i figuren) direkt kör rapporter eller analyser på de arkiverade data som lagrats i Hadoop. Detta ska inte ersätta datalagret. Hadoop skulle trots allt inte kunna matcha lagerets prestandaegenskaper för att stödja hundratals eller fler samtidiga användare som ställde komplexa frågor.
Poängen här är att du kan använda rapporteringsverktyg mot Hadoop för att experimentera och komma med nya frågor att svara i ett dedikerat lager eller mart.
När du startar ditt första Hadoop-baserade projekt för arkivering av lagerdata, bryta inte upp de aktuella processerna tills du har testat dem fullständigt på din nya Hadoop-lösning. Med andra ord, om din nuvarande lagringsstrategi är att arkivera till tejp, behåll den processen på plats och dubbel arkivera data i Hadoop och tejp tills du har testat scenariot fullt ut (vilket typiskt skulle innefatta återställning av lagerdata i fallet av ett lagerfel).
Även om du bibehåller (på kort sikt) två arkivförråd, har du en robust infrastruktur på plats och testad innan du avvecklar en provad och sann process. Denna process kan säkerställa att du är anställd - hos din nuvarande arbetsgivare.
Detta användarfall är enkelt eftersom det inte finns någon förändring i det befintliga lagret. Affärsmålet är fortfarande detsamma: billigare lagrings- och licenskostnader genom att migrera sällan använda data till ett arkiv. Skillnaden i det här fallet är att tekniken bakom arkivet är Hadoop istället för offline lagring, som tejp.
Dessutom har olika arkivleverantörer börjat integrera Hadoop i sina lösningar (till exempel att låta deras proprietära arkivfiler ligga på HDFS), så förvänta sig att kapaciteten inom detta område ska expandera snart.
När du utvecklar Hadoop-färdigheter (som utbyte av data mellan Hadoop och relationsdatabaser och frågande data i HDFS) kan du använda dem för att ta itu med större problem, t.ex. analysprojekt, vilket skulle kunna ge ytterligare värde för organisationens Hadoop-investering.
