Big Data Suomessa - NoSQL & Cloud


2014-08-05, 11:06 Kirjoittanut Tero Keski-Valkama

Mainitsin aiemmassa artikkelissani, että NoSQL & Cloud ovat Big Datan parhaiten ymmärrettyjä osa-alueita. Tämä on tietysti totta, mutta paljon on myös tuudittauduttu uskoon, että Hadoop-klusteri ratkaisee kaikki Big Dataan liittyvät haasteet. Hadoop on käytännössä Apachen Open Source -toteutus MapReduce-alustasta. Se on rakennettu Apachen HDFS:n päälle, ja sen kanssa yhdessä käytetään usein muita Apachen Big Data -tuoteperheen sovelluksia, kuten HBase.

NoSQL-maailmaan liittyvät myös web-skaalassa replikoituva CouchDB-tietokanta, JSON NoSQL -kanta MongoDB, ja esimerkiksi graafimuotoisen datan tiimoilta SPARQL-järjestelmät kuten Jena. Ei pidä myöskään unohtaa muistinvaraisia tietokantoja, kuten Redis, jotka omalta osaltaan mahdollistavat reaaliaikaisia nopean datan sovelluksia.

Hadoop et al.

Hadoop on Big Datan perusmuuli, joka surutta tallettaa dataa hajautettuun klusteriin ja ajaa sitä vasten lineaariaikaisia Map-Reduce -ajoja. Järjestelmä perustuu tiedostoihin, ja on äärimmäisen vikasietoinen, joka mahdollistaa merkittävän skaalautuvuuden. Hadoop ei kuitenkaan ole kuin ensimmäinen pieni askel kohti Big Data -kykyä. Mukaillen vanhaa sanontaa: Jos ainoa työkalusi on Hadoop, niin kaikki ongelmasi näyttävät Map-Reducelta. Hadoop ei tarjoa mitään indeksointia, ei rakenteisuutta, ei kyselyitä, ei optimointia. Tyypillisesti Hadoopilla yhdessä Map-Reduce -ajossa puhutaan useiden minuuttien ajoajasta. Kyseessä ei missään tapauksessa ole mikään hopealuodinomainen one-size-fits-all -ratkaisu. Hadoop on suunniteltu yksinkertaiseksi eräajojärjestelmäksi, datakäyttöjärjestelmäksi, joka generoi taustalla erilaisia valmiiksi laskettuja raportteja ja indeksejä, jotka voidaan generoinnin jälkeen lukea nopeasti.

Ennen oli kaikki paremmin (vai oliko?)

Käytännön hakutarpeiden muuntaminen Map-Reduce-muotoon ei ole triviaalia, ja ei-triviaalit haut ja käsittelyt vaativat useita Map-Reduce-vaiheita. Tämän vuoksi Hadoopin päälle on luotu korkeamman tason kyselykieliä, kuten Pig Latin. Vanhat relaatiotietokantaihmiset hakeutuvat kohti SQL-tyyppisiä kieliä; tuttua ja turvallista, eikä tarvitse oppia mitään uutta. Tyypillisesti kuitenkin SQL-abstraktiot, jotka ovat yhdellä perinteisellä tietokannalla tehokkaita, ovat massiivisesti rinnakkaisella Hadoop-alustalla valtavan hitaita. Vaistonomaisesti ja ajattelematta vanha ammattilainen pyrkii normalisoimaan tietomallit ja rakenteistamaan datan relaatioiden avulla, joka johtaa suureen tuskaan Hadoop-maailmassa. Tämä aiheuttaa paljon reaktiivisia paluita perinteisiin tietokantajärjestelmiin, koska niiden skaalautuvuus- ja muut ongelmat on jo ikään kuin luonnonlakina hyväksytty, ja niitä on opittu kiertämään ajan saatossa.

NewSQL

Niin paljon kuin perinteisissä relaatiokannoissa onkin skaalautuvuusongelmia, yleiskäyttöisissä transaktioissa ja datan organisoinnissa relaatioiksi on paljon sellaisia etuja, jotka ovat tärkeitä monissa sovelluksissa. Esimerkiksi sosiaaliverkoissa on tärkeää taata, että muutettaessa sisällön oletusjulkisuusasetuksia tämä tapahtuu transaktionaalisesti ja serialisoituvasti siten, että tämän jälkeen tuotettu sisältö ei pääse vahingossa vuotamaan halutun rajatun piirin ulkopuolelle. Jotkut käyttötapaukset voidaan toteuttaa hieman miettimällä ja ovelia rakenteita käyttämällä esimerkiksi suppeiden riveittäisten transaktioiden puitteissa. Käytännössä kuitenkin nämä ovelat rakenteet asettavat Big Data -datalle epäsuoria rakenteisuusvaatimuksia, jotka täytyy etukäteen suunnitella, ja jotka syövät rakenteettoman tai laiskasti generoitavan rakenteen etuja.

Pienissä ja keskisuurissa sovelluksissa perinteiset SQL-tietokannat ovat edelleen ihan hyviä datalle, joka vaatii vahvoja konsistenttius- ja transaktionaalisuusvaatimuksia, mutta mitä tehdään suurissa sovelluksissa, jotka kuitenkin käsittelevät sovellusspesifistä rakenteista dataa? Tähän tarpeeseen on syntynyt vastaamaan ns. NewSQL -ajattelu. Relaatiotietokantojen skaalautuvuusongelmia voidaan lieventää merkittävästi globaaleissa sovelluksissa käyttämällä synkronisia kelloja, kuten esimerkiksi Googlen Spanner:issa. Näissä ratkaisuissa saavutetaan globaalin mittaluokan skaalautuvuus, mutta järjestelmän tehokkuus rajoittuu käytettyjen kellojen tarkkuuteen ja kellonajan virherajoihin. Näitä järjestelmiä varten konesaleihin asennetaan atomikelloja ja GPS-aikavastaanottimia, ja käytetään aikarajapintana TrueTime-tyyppisiä rajapintoja, jotka tarjoavat takuut kellonajasta ja sen virhemarginaaleista. Tällaisten järjestelmien toteuttamiseen liittyy kuitenkin paljon monimutkaisia fyysisiä haasteita.

Cloud

Big Data asettaa paljon uusia vaatimuksia palvelinsaleille ja Cloud-infrastruktuurille. Useat Big Data -ratkaisut, kuten Hadoop, olettavat että noodit käyttävät keskenään erillisiä levyjä siten, että levyrikon sattuessa ei menetetä jaettujen levyjen vuoksi usean näennäisesti replikoidun noodin dataa. Tarvittavat kapasiteetit Big Data -kontekstissa ovat suuria sekä levyn koossa mitattuna, että muistin määrässä. Myös muistia suuremmat flash-levyt ovat hyödyllisiä joissakin sovelluksissa niiden tarjoaman olemattoman hakuajan vuoksi.

Cybercom Cloud tukee Volume Management API:a, jonka avulla palvelimiin voidaan tuskatta liittää ulkoisia, tarvittaessa jaettuja levyjä. Näistä voidaan myös varmuuskopioida snapshotit automatisoitavien rajapintojen kautta. Cybercomilla on käynnissä kehitysprojekti, jossa koeistetaan Cybercom Cloudia erilaisten Big Data -kuormien ja -sovellusten avulla, ja luodaan muun muassa uusia PaaS-komponentteja Big Data -kykyä tarvitsevien asiakkaiden tarpeisiin.

Alustojen ja ekosysteemin tulevaisuuden kehitys

Big Data -ekosysteemi ei ole valmis, eikä kaikki ongelmat ratkaisevia hopealuoteja ole tarjolla. Kehitys on edelleen hyvin nopeaa, ja uudenlaisia paradigmoja ja tapoja ajatella skaalautuvia datajärjestelmiä syntyy jatkuvasti. Uudenlaiset sovellusideat ja vaatimukset työntävät innovaatioita eteenpäin, ja joitain yleisiä suunnittelumalleja, kuten Lambda Arkkitehtuuri, on vakiintumassa. Yksi kurssi ei riitä Big Data -kompetenssin rakentamiseksi, eivätkä ohjelmistoratkaisuiden markkinointiesitteet anna realistista kuvaa niiden kyvyistä. Paitsi sovelluskehittäjiltä, myös yritysten johdolta, ja sovellusten ostajilta vaaditaan uutta ja modernia ymmärrystä uusista mahdollisuuksista. Isoihin ja perustavanlaatuisiin trendeihin liittyen on itse kunkin jaksettava aina uudelleen palata avoimin mielin koulunpenkille, ja vaikka ei välttämättä unohtaa kaikkea aiemmin tietämäänsä, niin ainakin ymmärtää paremmin syyt kehitykseen ja laajempi konteksti aiemmin hankitulle ammattitaidolle.


comments powered by Disqus