Video: Big data. Ciutadans sota control 2024
En rekke studier viser at de fleste data i et bedriftsdatavarehus sjelden blir spurt. Databaseleverandører har reagert på slike observasjoner ved å implementere egne metoder for å sortere ut hvilke data som blir plassert der.
En metode ordner datarunet til betegnelser for varmt, varmt eller kaldt, hvor varmt data (noen ganger kalt aktiv data) brukes ofte, brukes varm data fra tid til annen, og kaldt data brukes sjelden. Den foreslåtte løsningen for mange leverandører er å lagre de kalde dataene på langsommere disker i datalagringskapasitetene eller å lage klare caching-strategier for å holde de varme dataene i minnet blant annet.
Problemet med denne tilnærmingen er at selv om tregere lagring er brukt, er det fortsatt dyrt å lagre kalde, sjelden brukte data i et lager. Kostnadene her stammer fra begge maskinvare og programvare lisensiering. Samtidig arkiveres kald og sovende data ofte til tape.
Denne tradisjonelle modellen for arkiveringsdata brytes ned når du vil spørre alle kalddata på en kostnadseffektiv og relativt effektiv måte - uten å måtte be om gamle bånd, med andre ord.
Hvis du ser på kostnadene og driftskarakteristikkene til Hadoop, ser det ut til at det er satt til å bli den nye sikkerhetstape. Hadoop er billig, hovedsakelig fordi Hadoop-systemer er designet for å bruke en lavere klasse maskinvare enn det som normalt brukes i datalagringssystemer. En annen betydelig kostnadsbesparelse er programvare lisensiering.
Commercial Hadoop distribusjonslisenser krever en brøkdel av kostnaden for relasjonsdatamagasinet programvare lisenser, som er beryktet for å være dyrt. Fra et operativt perspektiv er Hadoop designet for å skalere bare ved å legge til flere slave noder til en eksisterende klynge. Og som slave noder legges til og datasettene vokser i volum, gjør Hadops databehandlingsrammer at programmene dine sømløst kan håndtere den økte arbeidsbelastningen.
Hadoop representerer en enkel, fleksibel og rimelig måte å presse behandling på tvers av tusenvis av servere.
Med sin skalerbare og rimelige arkitektur synes Hadoop å være et perfekt valg for arkivering av lagerdata … bortsett fra en liten sak: Det meste av IT-verdenen kjører på SQL, og SQL alene spiller ikke bra med Hadoop.
Visst, jo mer Hadoop-vennlig NoSQL-bevegelse er i live og bra, men de fleste strømbrukere bruker nå SQL ved hjelp av vanlige verktøy uten bruk av hylle som genererer SQL-spørringer under hetten - produkter som Tableau, Microsoft Excel, og IBM Cognos BI.
Det er sant at Hadoop-økosystemet inkluderer Hive, men Hive støtter bare en delmengde av SQL, og selv om ytelsen forbedres (sammen med SQL-støtte), er det ikke så fort til å svare på mindre spørsmål som relasjonssystemer er. Nylig har det vært stor fremgang rundt SQL-tilgangen til Hadoop, som har banet vei for Hadoop å bli det nye målet for elektroniske datalagringsarkiver.
Avhengig av Hadoop-leverandøren blir SQL (eller SQL-lignende) APIer tilgjengelige slik at de mer vanlige rapporteringsverktøyene og rapporteringsverktøyene kan sømløst utgjøre SQL som utføres på data lagret i Hadoop. For eksempel har IBM sin Big SQL API, Cloudera har Impala, og Hive selv, via Hortonworks Stinger-initiativet, blir stadig mer kompatibel med SQL.
Selv om ulike synspunkter eksisterer (noen har som mål å forbedre Hive, noen, for å utvide Hive, og andre, for å gi et alternativ), prøver alle disse løsningene å håndtere to problemer: MapReduce er en dårlig løsning for å utføre mindre spørringer, og SQL-tilgang er - for nå - nøkkelen til at IT-arbeidere kan bruke sine eksisterende SQL-ferdigheter for å få verdier ut av data lagret i Hadoop.
