Hyppää pääsisältöön

Timo Aho: Miltä näyttää Ylen big data?

Timo Aho kuvassa.
Timo Aho kuvassa. Yle,timo aho

Keräämme Ylellä tietoa eri palveluiden käytöstä, jotta voimme tehdä suomalaisille parempia sisältöjä ja kehittää palveluiden käyttökokemusta. Tästä tiedosta selvästi suurin osa koostuu verkkosivujen käytöstä, jota käsittelemme big data -pilvipalvelussa. Millainen on verkkodatan käsittelyyn toteutettu big data -alusta? Mitä teknologioita ja komponentteja on käytössä ja millaisia haasteita alustan toteutukseen liittyy?

Alustaamme kerätään dataa Ylen verkko- ja mobiilipalvelujen käytöstä. Alkuvuodesta 2018 palveluistamme saapui päivittäin keskimäärin noin 120 miljoonaa yksittäistä verkkotapahtumaa. Dataa syntyy noin 300 gigatavua päivässä, mikä vastaa kolmasosaa tyypillisen nykykoneen kovalevytilasta. Keräämme dataa kaikkien Ylen verkkosivujen avauksesta sekä niiden lukemisajasta. Yle Areenan käytöstä tiedämme, mitä kohtia mediasta on katsottu tai kuunneltu. Näiden pääkategorioiden lisäksi voimme halutessamme kerätä tietoja erityistapahtumista, kuten datajournalististen sisältöjen ilmestymisestä näkyviin.

Alustamme on toteutettu pilvipalveluna ja tähän on muutamia syitä. Ensinnäkin eri pilvipalvelutoimittajat tarjoavat valmiita työkaluja, vaikka myös avoimen lähdekoodin vaihtoehtoja löytyisi. Toiseksi pilvipalvelussa järjestelmä skaalautuu nopeasti, jos verkkopalveluissa on kävijäpiikki. Esimerkiksi itsenäisyyspäivän vastaanotto ja olympialaiset lisäävät merkittävästi Ylen järjestelmien kuormitusta. Yksi suurimmista piikeistä saavutettiin 21.2. klo 10–12 olympialaisten hiihdon parisprintin karsinnassa, jolloin liikennettä syntyi 16 miljoonaa tapahtumaa tunnissa. Kaikkien aikojen huipputunti, 22 miljoonaa verkkotapahtumaa, tuli 12.8. Kiira-myrskystä kertovien iltauutisten aikaan. Tyypillinen vaihtelu on aamuneljän miljoonan ja iltauutisten kymmenen miljoonan välillä.

Alustamme on toteutettu lähinnä Amazon Web Services (AWS) -pilvipalveluun. Muita vaihtoehtoja olisivat esimerkiksi Microsoft Azure sekä Googlen korkeamman tason analytiikkapalvelut, mutta AWS on markkinajohtajana kilpailijoitaan jonkin verran kypsempi. Lisäksi eroa on työkalujen tyypissä: Google tarjoaa erityisesti valmiita ohjelmistoratkaisuja, kun taas AWS:llä ja Azurella on suurempi valikoima työkalukomponentteja, joiden päälle ratkaisua voi rakentaa. Valmiit ohjelmistot helpottavat aloittamista, mutta rajoittavat myöhemmin muokattavuutta.

Big data -alustan tekninen arkkitehtuuri

Tekninen arkkitehtuurimme on melko tyypillinen verkkodatan keräykseen käytetty ratkaisu. Ensimmäisenä verkkotapahtuman ottaa vastaan kevyeen esikäsittelyyn tarkoitettu erittäin skaalautuva esikäsittelijäkomponentti. Tämä löytyy arkkitehtuurikuvan (alla) vasemmasta reunasta nimellä Proxy. Komponentin tehtävänä on lajitella tapahtumat ja ohjata ne muutamaan eri kohteeseen. Kuhunkin kohteeseen lähetetään vain juuri sen tarvitsemaa tietoa. Tällä hetkellä komponentti on toteutettu Elastic Beanstalk -työkalulla, mutta pohdimme sen korvaamista muokattavammalla vaihtoehdolla. Esikäsittelijäkomponentti on ehkä toteutuksemme kriittisin osa, koska sen kautta kulkee data kaikkiin järjestelmiimme.

Arkkitehtuurin havainnekuva.
Arkkitehtuurin havainnekuva. arkkitehtuuri (rakenne)

Proxy-komponentti ohjaa datan eri datavirtoihin, jotka on nekin merkitty arkkitehtuurikuvaan. Tekniseltä kannalta virrat on toteutettu Kinesis Streams- ja Kinesis Firehose -teknologioilla. Syy jakoon on komponenttityyppien eri tehtävissä:

Kaikki data kulkee varmuuden vuoksi Kinesis Streams -virtaan, jossa se säilyy muutamia päiviä jatkokäsittelyä varten. Näin tasoitetaan erilaiset piikit eikä myöhemmän käsittelyn tarvitse kohtuuttomasti mukautua liikenteen määrään. Virran kautta tiedot tallennetaan Lambda-laskentakomponentin välityksellä S3-tallennustilaan. Lambda on helppokäyttöinen ohjelmisto- tai alustapalvelu, jolle voi antaa suoritettavan koodin välittämättä laskentaresursseista. S3-tallennustilan voi ajatella hajautettuna verkkoasemana. Tilankäytöltään se on hyvin joustava: meillä pakattua dataa on hieman alle 100 teratavua, mutta periaatteessa datamäärällä ei ole ylärajaa.

Kinesis Firehose -virrat kirjoittavat datan suoraan kuvassa olevaan Redshift-relaatiotietokantaan. Redshift on käytön näkökulmasta perinteinen tietokanta tukien esimerkiksi laajasti käytössä olevaa SQL-kyselykieltä. Redshift-kanta on datakäsittelymme keskiössä. Jatkuvasti päivittyvät raportointinäkymät tehdään sen päälle ja myös ohjelmointitaitoiset data scientistimme käyttävät enimmäkseen sitä. Alunperin tarkoituksena oli tallentaa Redshift-kantaan vain yhdisteltyä ja esikäsiteltyä tietoa, jolloin datan määrä olisi ollut paljon pienempi. Positiivinen yllätys kuitenkin oli, että kannan resurssit riittivät myös huomattavasti suuremman käsittelemättömän datamäärän pyörittämiseen. Tämä helpotti alkua, mutta toi myöhemmin ongelmia joihin palaan lopuksi.

Tallennamme Redshiftiin vain toistuvasti tarvitsemamme tiedot. Loput löytyvät S3-järjestelmästä, johon teemme suurempia erähakuja tarpeen mukaan. Tähän AWS tarjoaa yhä enemmän ohjelmistopalvelutasoisia työkaluja, kuten SQL-kyselymoottori Athenan. Kuten alussa mainitsin, tämän tyyppisissä palveluissa ei tarvitse huolehtia alla olevasta laskentakapasiteetista. Helppokäyttöiset ohjelmistopalvelut eivät kuitenkaan aina riitä, vaan välillä turvaudumme muihin työkaluihin kuten Apache Sparkiin. Arkkitehtuurikuvassa nämä palvelut on merkitty AWS:n käyttämällä tuotenimellä EMR.

S3-prosessointiin liittyy kuitenkin omat haasteensa. Käsittely on tehokkainta sarakemuotoisella tallennuksella kuten Parquet. Näin jo yhden sarakkeen perusteella on mahdollista päätellä mikä osa tiedostosta käydään läpi. Esimerkiksi halutessamme tarkastella yhtä viikkoa, voimme ohittaa tiedoston muut ajankohdat. Tämä säästää rahaa ja nopeuttaa prosessointia. Datamme saapuu kuitenkin tapahtuma tapahtumalta rivimuodossa, jolloin tiedostomuoto olisi jossain vaiheessa muutettava sarakemuotoiseksi. Tähän tarkoitukseen on äskettäin julkaistu Glue-niminen työkalu, mutta näyttää siltä että data on joka tapauksessa tallennettava useampaan kertaan. Tämä lisää taas kustannuksia ja hallinnointityötä.

Arkkitehtuurikuvassa ei ensi silmäyksellä ole mainintaa reaaliaika-analytiikasta. Sillä tarkoitetaan käytännössä analytiikan tuottamista esimerkiksi minuutin tai kymmenen sekunnin viiveellä. Meillä on tämän toteuttamiseen kuitenkin muutamia tapoja.

Ensinnäkin osa tiedoista on saatavilla Redshift-kannassa jo minuutin sisällä. Redshift on ensisijaisesti tarkoitettu harvempiin, isoihin kyselyihin, joten nopeampaan käyttöön se ei ole sopiva. Sen sijaan meillä on käytössä Athena-pohjainen S3-kysely, jolloin data on käytettävissä sekunneissa. Lisäksi AWS on jokin aika sitten julkaissut uuden Kinesis Analytics -työkalun, joka mahdollistaa analytiikan suoraan datavirrasta. Periaatteessa tämä ratkaisu olisi täydellinen, mutta kyselykieli ei ole aivan yksinkertainen. Suosittelen kuitenkin kokeilemaan, jos etsit tämän tyyppistä ratkaisua.

Alustan teknisiä haasteita

On muutamia asioita, joita vielä haluaisimme big data -ratkaisussa parantaa.

Kinesis Firehosen skaalautuvuudessa on aika- ja tiedostokokorajoitukset. Olimme alunperin huolestuneita skaalautumisen riittävyydestä. Kuitenkin Firehose toimii aika lailla virheettä, vaikka annetut rajat paukkuvatkin selvästi. Ainoa ongelma on, että kirjoitus Redshiftiin tapahtuu liian usein, alle minuutin välein. Tästä pääsemmekin seuraavaan ongelmaan.

Redshift on keskeinen työkalumme, mutta suorituskyvystä on tullut rajoite. Redshiftin tyypillinen ongelma on tasapainottelu tilankäytön ja prosessointitehon välillä. Usein kehittäjät ostavat paljon levytilaa prosessointitehon kustannuksella. Tällä hetkellä datamäärämme on viitisen teratavua, minkä vuoksi meillä on käytössä kymmenkunta suurempaa HDD-levyllistä Redshift-konetta. Jos koneet korvattaisiin nopeammilla SSD-ratkaisuilla, hinta kasvaisi huomattavasti. Tämän lisäksi merkittävä työmäärä käytetään, kuten tyypillistä, tietokannan sisäisen data-arkkitehtuurin ylläpitoon ja kehittämiseen. Redshiftin omalaatuinen indeksitön toimintaperiaate myös lisää työtä. Kaiken kaikkiaan Redshift on mielestäni toimiva työkalu, kunhan sen optimoimiseen käyttää riittävästi aikaa. Viime aikoina on kuitenkin kasvattanut suosiotaan myös vastaava Snowflake-tietokanta, johon kannattanee tutustua.

Redshift ja S3 ovat hinnaltaan arvokkaimpia käyttämistämme komponenteista. Saimme kuitenkin laskettua S3-tallennuksen hintaa ottamalla käyttöön halvempaa ja hitaampaa Glacier-kapasiteettia. Uuteen eurooppalaiseen tietosuojakäytäntöön (GDPR) valmistautuessa meidän on kuitenkin pohdittava datan säännöllistä sulattamista käsittelyä varten. Tämä vähentäisi Glacierin tuomia kustannusvähennyksiä.

Mitä olemme oppineet?

Pilvipalvelutoimittajat, kuten AWS, tarjoavat paljon erilaisia työkaluja verkkotapahtumien big datan käsittelyyn. Lisäksi datan käsittelyyn ja hyödyntämiseen on tulossa jatkuvasti uusia työkaluja. AWS:ltä kiinnostavia mahdollisuuksia analytiikan kannalta löytyy mm. Athena-kyselymoottorista, Redshiftin Spectrum-kyselylaajennuksesta ja SageMaker-analytiikka-alustasta.

Uutta alustaa suunnitellessa kannattaa lähteä liikkeelle kevyestä ensikokeilusta. Toisaalta on hyvä pohtia jo alkuvaiheessa komponenttien käyttötarkoitusta ja kasvavan käytön aiheuttamaa kuormitusta. Arkkitehtuurin on mukauduttava ennalta arvaamattomiin käyttötarkoituksiin.

Eräs konkreettinen kysymys on datan tallennusmuoto. Data saapuu usein rivimuodossa ja tätä esimerkiksi Redshift-tietokanta tukee suoraan. Kuitenkin kyseleminen mm. Athenalla on halvempaa ja nopeampaa sarakemuodossa. Kuinka usein ja miten datan muodon muuttaminen tapahtuu? Tallennetaanko kaikki data useampaan kertaan eri hakemistorakenteisiin ja tiedostomuotoihin? Voiko datasta karsia suoraan jotain pois? Analytiikkaratkaisujen toteuttamiseen käsiteltävän tiedon muoto vaikuttaa hyvinkin paljon. Toki ratkaisua voi myöhemmin muuttaa, kunhan varmistaa datan säilyvyyden ja yhteensopivuuden vanhan ja uuden datamuodon kanssa.

Haluan lopuksi vielä jakaa kantapään kautta oppimamme vinkin: kehitysaikaisen kuormitustestauksen ja tuotantojärjestelmän monitorointiin kannattaa nähdä vaivaa. Näillä voidaan toimintavirheitä havaita jo alkuvaiheessa, kun niiden korjaaminen on halpaa.

Jos mieleesi nousi kysymyksiä tai kommentteja, ota ihmeessä yhteyttä vaikkapa sähköpostiosoitteeseeni joka on muotoa etunimi.sukunimi@yle.fi

Timo Aho
Data Scientist / Data Analytics Architect, Tuotannot, Yle