Video: Big data. Ciutadans sota control 2024
En lang række undersøgelser viser, at de fleste data i et enterprise data warehouse sjældent forespørges. Databaseleverandører har reageret på sådanne observationer ved at implementere deres egne metoder til at sortere ud, hvilke data der placeres hvor.
En metode ordner dataluften til betegnelser for varmt, varmt eller koldt, hvor hot data (til tider kaldes aktiv data) bruges ofte, bruges varm data fra tid til anden, og kolde data anvendes sjældent. Den foreslåede løsning for mange leverandører er at gemme de kolde data på langsommere diske i datalagringskablerne eller at skabe klare caching-strategier for bl.a. at holde de varme data i hukommelsen.
Problemet med denne tilgang er det, selvom langsommere opbevaring er brugt, er det stadig dyrt at opbevare kolde, sjældent anvendte data i et lager. Omkostningerne her stammer fra begge hardware og software licens. Samtidig arkiveres kolde og sovende data ofte til bånd.
Denne traditionelle model for arkivering af data brydes ned, når du ønsker at søge alle kolde data på en omkostningseffektiv og forholdsvis effektiv måde - uden at skulle anmode gamle bånd med andre ord.
Hvis du ser på omkostningerne og driftsegenskaberne hos Hadoop, ser det ud til at det er meningen, at det bliver den nye backup tape. Hadoop er billig, hovedsagelig fordi Hadoop-systemer er designet til at bruge en lavere kvalitet af hardware end det, der normalt anvendes i datalagringssystemer. En anden betydelig omkostningsbesparelse er softwarelicenser.
Commercial Hadoop-distributionslicenser kræver en brøkdel af prisen på licenser til relationsdatabase-software, som er berygtede for at være dyre. Fra et operationelt perspektiv er Hadoop designet til nemt at skalere ved blot at tilføje yderligere slave noder til en eksisterende klynge. Og som slaveknude er tilføjet og datasæt vokser i volumen, har Hadops databehandlingsrammer mulighed for, at dine applikationer håndterer den øgede arbejdsbyrde problemfrit.
Hadoop repræsenterer en simpel, fleksibel og billig måde at skubbe behandling på tværs af bogstaveligt tusindvis af servere.
Med sin skalerbare og billig arkitektur synes Hadoop at være et perfekt valg til arkivering af lagerdata … bortset fra et lille spørgsmål: Det meste af IT-verdenen kører på SQL, og SQL alene spiller ikke godt med Hadoop.
Jo mere, den mere Hadoop-venlige NoSQL-bevægelse er i live og godt, men de fleste strømbrugere bruger nu SQL ved hjælp af almindelige værktøjsværktøjer, der genererer SQL-forespørgsler under emhætten - produkter som Tableau, Microsoft Excel, og IBM Cognos BI.
Det er rigtigt, at Hadoop-økosystemet indeholder Hive, men Hive understøtter kun en delmængde af SQL, og selvom resultaterne forbedres (sammen med SQL-support), er det ikke så hurtigt at svare på mindre forespørgsler, som relationelle systemer er. For nylig har der været store fremskridt omkring SQL-adgang til Hadoop, som har banet vejen for Hadoop at blive den nye destination for online-datalagringsarkiver.
Afhængigt af Hadoop-sælgeren bliver SQL-programmer (eller SQL-lignende) API'er tilgængelige, så de mere almindelige rapporterings- og analyseværktøjer til rådighed for hylde kan problemfrit udstede SQL, der udføres på data, der er gemt i Hadoop. For eksempel har IBM sin Big SQL API, Cloudera har Impala, og Hive selv, via Hortonworks Stinger-initiativet, bliver mere og mere SQL-kompatibel.
Selvom der er forskellige synspunkter (nogle har til formål at forbedre Hive, nogle, for at udvide Hive og andre, for at give et alternativ), forsøger alle disse løsninger at løse to problemer: MapReduce er en dårlig løsning til at udføre mindre forespørgsler, og SQL-adgang er - indtil nu - nøglen til at gøre det muligt for it-arbejdere at bruge deres eksisterende SQL-færdigheder til at få værdi ud af data, der er gemt i Hadoop.
