BIG DATA: Filsystemer og databaser for massive datamengder

Big Data er et av de siste moteordene i IT-bransjen. Upresise beskrivelser sammen med store ord har en tendens til å tåkelegge i vår bransje. Hva sitter vi igjen med når støvet har lagt seg? Og hvor går utviklingen?

Behovet som har drevet Big Data-teknologien, er enorme mengder data som krever spesielle metoder for parallell prosessering og feiltolleranse. Håndtering av store online datamengder uten tape-arkivering er også viktig. I slike miljøer er det snakk om tusenvis av servere som jobber i parallell i timer og dager på analyseoppgaver. Maskinvarefeil på én prosessor må ikke føre til at en hel batch-jobb må startes på nytt. Typiske datamengder er på tosifrede terabytes.

Det er i første rekke internett-selskapene (Google, Yahoo og Facebook etc.) som har hatt slike datamengder, men teknologien har nå blitt åpen og kan brukes av alle. Den nye arkitekturen bruker vanlige, masseproduserte servere som er rimeligere enn tradisjonell teknologi. I mange tilfeller er den nye arkitekturen også raskere selv om man ikke har datamengder som man i utgangspunktet forbinder med Big Data. Teknologien er i ferd med å bli moden. Den nye arkitekturen forutsetter et nytt tankesett for å bli brukt riktig (Map Reduce). Allikevel bør man ta utgangspunkt i behov og ikke tilgjengelig teknologi og metoder.

Grunnlaget innen Big Data er distribuerte filsystemer og er som regel assosiert med Google File System (GFS) og Hadoop Distributed File System (HDFS). GFS er proprietært hos Google, mens HDFS med opprinnelse fra Yahoo har blitt fritt tilgjengelig som open source.

I GFS og HDFS er de enorme filene delt i chunks på 64 megabytes hver. (Sammenlign dette med fil-blokker på vanlige PC'er som har størrelser på 0,5 til 8 kilobytes). Chunks blir fordelt på distribuerte Chunk Servers (GFS) og Data Nodes (HDFS). Disse er replikert på tre forskjellige servere som er plassert i forskjellige racks og subnets for å ta høyde for alle mulige feilsituasjoner.

Lesing kan skje med random access. Skriving foregår derimot best som append. Random skriving kan håndteres, men det reduserer konsistens mellom replicas og er ikke så effektivt som bulk-skriving på slutten av filene.

Slike distribuerte og parallelle filsystem for bulk-lesing og skriving er primært ment som støtte for det distribuerte programmerings-paradigmet map-reduce og distribuerte databaser for massive datamengder. Det vil ikke fungere som et vanlig filsystem med random access lesing/skriving.

I løpet av de siste 40 årene har relasjonsdatabaser vært arbeidhesten i de fleste ERP og analysesystemer. Slike databaser passer for alle med datamengder opp til hundrer av gigabytes. Hele rader av data blir holdt samlet på samme blokker på disken. Forskjellige brukere kan jobbe samtidig og oppdatere samme tabell. Transaksjonene er helt isolert fra hverandre. I tillegg kan spørrespråket SQL aksessere data. Indekser, som peker direkte til blokker på disken, gjør spørringer raske og effektive. Databasene håndterer selv disklesing med pre-fetch o.l.

Etter hvert som datamengden har økt til terabytes og bredden på radene har blitt større, er henting av hele rader blitt ineffektivt både med hensyn til aksesstid og lagringsplass. Kolonneorienterte databasser har derfor blitt utviklet de siste ti årene for datavarehus. Spørringer blir da prioritert på bekostning av transaksjoner (innsetting og oppdatering). Datarader blir splittet på forskjellige disk-blokker der kolonner med data fra mange rader holdes samlet. Kolonnelagring blir typisk brukt for Online Analytical Processing (OLAP). Spørringer henter da fram kun noen få felter (kolonner) fra en mengde datarader til en krysstabell. Eksempel er en rapporttabell med salg pr. produktkategori. Med kolonnedatabaser blir antall disklesinger sterkt redusert for OLAP-spørringer på store datamengder. Opplasting i bulk er det mest vanlige.

Transaksjonshåndtering med ACID (atomicity, consistency, isolation, durability) og SQL (queries og indexing) er nødvendig i forretningssystemer, men ikke i OLAP-analyse. Relasjonsdatabaser kan dog bli brukt til OLAP. Det kan være fordel å slippe å flytte data ut av transaksjonssystemet.

Parallelle databaser har eksistert lenge med «Delt minne», «Delt disk» eller «Ingenting delt». I «Ingenting delt»-arkitekturen kommuniserer prosessorene kun via nettverket. Denne arkitekturen kan skalere, men har ikke feiltoleranse. Man behøvde ikke bekymre seg for at noen prosessorer kunne feile før internett-alderen. Datamengden var ganske liten. Det bare var snakk om noen få dusin prosessorer, og SQL-spørringene tok noen få sekunder eller minutter. Replikering med fullstendig hot standby er mulig med den tradisjonelle arkitekturen, men flere kopier av alt er dyrt.

Utvikling av database foregår nå i to retninger. Distribuerte noSQL-databaser støtter ikke ACID-transaksjoner. De bruker «sharded indexing» der data er splittet på forskjellige chunk servers, og de støtter kolonnelagring hvis nødvendig. Datamengden er typisk tosifrede terabytes.

Den andre retningen er in-memory-databaser som støtter sanntidstransaksjoner, variasjon av indexer og kompliserte joins. Disse passer for databaser på gigabytes. Dette er ikke Big Data.

En av de første noSQL-databasen var Google's big-table som ble beskrevet for tre til fire år siden. Antagelig er denne opphavet til ordet Big Data. Den bygger på Google File System. HBase er tilsvarende for Hadoop-distribusjonen. Tabeller er delt opp på forskjellige servere, først etter rader og deretter etter kolonner for disse radene. Hver slik «kolonnefamilie» (chunk) er lagret i GFS / HDFS-filer. Det er mulig å ha ulike kolonner for forskjellige rader og flere versjoner av data i big-table. Dette er en stor fordel i forhold til relasjonsdatabaser.

Fordi big-table og HBase bygger på distribuerte filsystemer kan parallell skriving av store datamengder foregå effektivt, til og med på den samme tabellen. Likeså er lesing av alle radene for en kolonnefamilie, kanskje for å summere dem, effektivt på samme måte som for kolonnedatabaser. For tradisjonelle spørringer er derimot disse databasene ikke effektive uten å opprette ekstra indexer. De er mest beregnet for batch-prosessering.

NoSQL-databaser som MongoDB har blitt populære fordi de har utvidet støtte for indekser, til og med inverterte indekser for tekst. Som HBase er dette en distribuert database der «shards» kan ligge på forskjellige prosessorer. Databasen holder styr på replicas på egen hånd og kan kjøre på vanlige filsystemer som Linux. MongoDB har effektive funksjoner for skriving av små datamenger på random plasseringer med «inventual consistency» for replicas. Alle replicas må ikke være oppdatert før klienten får beskjed om at skriving gikk ok, men klienten må selv holde styr på verdier dersom det skulle oppstå inkonsistens mellom replikerte objekter i databasen.

Eventual consistency blir også brukt i andre noSQL-databaser som Amazon Simple DB, CouchDB, Casandra om mange flere. Ideen ble opprinnelig beskrevet av Lamport, L. (1978) «Time, clocks, and the ordering of events in a distributed system» i Communications of the ACM.

MongoDB har map-reduce via JavaScript. Denne databasen støtter ikke SQL og vil ikke fungere med open source OLAP-servere som Mondrian. Denne databasen kan bli brukt på store datamengder sammen med enkle rapporteringsverktøy i JasperSoft og Pentaho.

Google har i det siste introdusert Dremel. Databasene ovenfor er ok med terabytes av data, men når det etter hvert har blitt snakk om petabytes av data, har det for stor kostnad å produsere nye petabytes hver gang man skal berøre og analysere alle dataene. Dremel er kraftstasjonen i Google's «BigQuery» som kunder kan aksessere via web. Man kan opprette ekstremt store tabeller og utføre raske søk. Det er to innovasjoner i Dremel som ble publisert i 2010. Databasen har kolonneorientert lagring med nestede (hierarkiske), ikke-unike feltnavn. Den andre innovasjonen er et tre av query servers som leverer mellomliggende resultat av spørringer fra distribuerte servere oppover til klienten. Resultatet er «orders of magnitude» bedre ytelse enn Map Reduce på petabytes av data både når det gjelder hastighet og lagringsplass.

Case study: How redBus uses BigQuery to Master Big Data

Apache har satt igang et open source prosjekt, Drill, for å utvikle en database tilsvarende Dremel.

Det meste av teksten ovenfor er utdrag fra kurset Web Intelligence and Big Data på coursera.org. Detaljer knyttet til OLAP er lagt til av undertegnede.

Se også What Does 'Big Data' Mean? av professor Michael Stonebraker publisert på acm.org.

Skrevet av Birger Baksaas 10.11.2012.

Se flere innlegg