Video: Howto install hadoop on Ubuntu 2024
En mängd studier visar att de flesta data i ett företagsdatabutik sällan är ifrågasatta. Databasleverantörer har svarat på sådana observationer genom att implementera sina egna metoder för att sortera ut vilken data som placeras där.
En metod beställer datalunet i beteckningar för hett, varmt eller kallt, var hett data (ibland kallad aktiv data) används ofta varma data används från tid till annan, och kall data används sällan. Den föreslagna lösningen för många leverantörer är att lagra kyla data på långsammare diskar i datalagerhusen eller för att skapa klara cachingstrategier för bland annat att hålla heta data i minnet.
Problemet med denna metod det är trots att långsammare lagring används, är det fortfarande dyrt att lagra kyla, sällan använda data i ett lager. Kostnaderna här härrör från båda maskin- och programvarulicens. Samtidigt arkiveras kalla och vilande data ofta till tejp.
Denna traditionella modell för arkivering av data bryts ner när du vill fråga alla kalla data på ett kostnadseffektivt och relativt effektivt sätt - utan att behöva begära gamla band, med andra ord.
Om du tittar på kostnaden och operativa egenskaperna hos Hadoop, verkar det verkligen som om det kommer att bli den nya reservbandet. Hadoop är billigt till stor del för att Hadoop-system är utformade för att använda en lägre maskinvara än vad som normalt används i datalagringssystem. En annan betydande kostnadsbesparing är programvarulicens.
Commercial Hadoop-distributionslicenser kräver en bråkdel av kostnaden för licenser för relationsdatalagringsprogramvaror, som är berömda för att vara dyra. Från ett operativt perspektiv har Hadoop utformats för att enkelt skala bara genom att lägga till ytterligare slavnoder till ett befintligt kluster. Och som slavnodder läggs till och dataseten växer i volym, möjliggör Hadops databehandlingsramar att dina applikationer hanterar den ökade arbetsbelastningen smidigt.
Hadoop representerar ett enkelt, flexibelt och billigt sätt att driva processen över bokstavligen tusentals servrar.
Med sin skalbara och billiga arkitektur skulle Hadoop vara ett perfekt val för arkivering av lagerdata … förutom en liten sak: Det mesta av IT-världen körs på SQL, och SQL i sig spelar inte bra med Hadoop.
Visst, den mer Hadoop-vänliga NoSQL-rörelsen är levande och bra, men de flesta strömanvändare använder nu SQL genom vanliga verktygshjälpmedel som genererar SQL-frågor under huven - produkter som Tableau, Microsoft Excel, och IBM Cognos BI.
Det är sant att Hadoop-ekosystemet innehåller Hive, men Hive stöder endast en delmängd av SQL, och även om prestanda förbättras (tillsammans med SQL-stöd) är det inte så snabbt att svara på mindre frågor som relationssystem är. Nyligen har det gjorts stora framsteg kring SQL-åtkomst till Hadoop, vilket har banat vägen för Hadoop att bli den nya destinationen för arkiv för online-datalager.
Beroende på Hadoop-leverantören blir SQL (eller SQL-liknande) API-apparater tillgängliga så att de vanligaste rapporterna och analysverktygen för rader kan problemfritt utfärda SQL som körs på data som lagras i Hadoop. Till exempel har IBM sitt stora SQL API, Cloudera har Impala och Hive själv, via Hortonworks Stinger-initiativet, blir alltmer SQL-kompatibelt.
Även om olika synvinklar finns (vissa syftar till att förbättra Hive, vissa, för att utvidga Hive och andra, för att ge ett alternativ), försöker alla dessa lösningar att ta itu med två problem: MapReduce är en dålig lösning för att utföra mindre frågor, och SQL-åtkomst är - för tillfället - nyckeln till att IT-anställda kan använda sina befintliga SQL-färdigheter för att få värdet av data lagrade i Hadoop.
