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 target="none">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.

target="none">Case study: How redBus uses BigQuery to Master Big Data

Apache har satt igang et open source prosjekt, href="http://incubator.apache.org/drill/" target="none">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.2022.

Se flere innlegg