zef_logo.png
Ë
Mikael Häkkilä • helmikuuta 27, 2015

ZEF-raportointi kulissien takaa (osa 1)


2-Why-to-evaluate_tekstiton

Tämä blogisarja kertoo ZEF-raportointiin liittyvistä arkkitehtuuriratkaisuista sekä tarjoaa näkymiä “pellin alle”. Ensimmäisessä osassa haluamme antaa lukijoille yleiskäsityksen ZEF-raportoinnissa käytetyistä tekniikoista ja ratkaisuista. Myöhemmissä osissa paneudumme tarkemmin arkkitehtuurin eri osiin.

Uusi raportointijärjestelmä on käytössä MyZEF-palveluissa.

Raportointi on olennaisen tärkeä osa erilaisten kyselyjen ja vaalikoneiden vastausten analysointia. Ilman kunnollista raportointia kyselyn luoja ei pysty tarkasti analysoimaan, mitä ihmisten antamat vastaukset todellisuudessa merkitsevät. Raportit voivat myös piilottaa olennaista tietoa, elleivät niille luodut analysointi-työkalut ole tarpeeksi monipuolisia.

ZEF:llä olemme pyrkineet tekemään raportoinnista mahdollisimman tehokkaan työkalun käyttäjälle käsille olevan tiedon analysointiin. Olemme etsineet aktiivisesti uusia vaihtoehtoja raportoinnin työkaluihin, joilla asiakkaamme pystyvät mahdollisimman helposti analysoimaan ja profiloimaan juuri heidän omaa kyselyään. Markkinoilla on tarjolla monia kaupallisia ja vapaassa levityksiä olevia, hyvinkin monipuolisia vaihtoehtoja.

Monet näistä tuottavat laadukkaita raportteja suhteellisen vaivatta. Analysoimme eri tuotteita kattavasti, mutta suuri intohimomme tarjota vielä parempia raportteja kohtaan sulki pikkuhiljaa eri vaihtoehdot pois. Kaikki kunnia työkalujen kirjoille, joihinkin muihin sovelluksiin tarjolla olisi ollut mitä mainioimpia vaihtoehtoja. Kaikesta huolimatta juuri ZEF:in sovelluksiin täydellisesti sopivaa raportointityökalua ei ollut olemassa.

Tavoitteena oli tehdä raportoinnista hyvin käyttäjäläheinen ja graafisesti miellyttävä. Samalla halusimme antaa käyttäjälle mahdollisuuden analysoida dataa reaaliaikaisesti erilaisten suodattimien avulla ja tehdä raportin käsittelystä jopa pelinomaisen kokemuksen. Jotta pystyisimme vastaamaan parhaalla mahdollisella tavalla asiakkaidemme tarpeisiin päädyimme rohkeaan ratkaisuun, jossa suunnittelimme itse koko raportointiin liittyvän arkkitehtuurin ja rakensimme sen itse muutamien eri ohjelmistoalustojen tuella.

Kutsumme rakkaudella luomaamme työkalua interaktiiviseksi raportiksi. Uskomme sen olevan juuri oikeanlainen työkalu ZEF-kyselyjen analysointiin ja tarjoavan asiakkaillemme mielenkiintoisia hetkiä tiedonjyvästen äärellä!

Arkkitehtuuri

Alla olevassa kuvassa on esitetty ZEF-reportoinnin looginen arkkitehtuuri. Se koostuu UI kerroksesta, front-end:sta sekä raportoinnin back-end:ista joka sisältää datan käsittelyn sekä varastoinnin.

Reporting - Blog

ZEF-Platform on ZEF:in rakentama alusta kyselyiden ja vaalikoneiden luomiseen. Alusta itsessään ei varsinaisesti toteuta raportoinnin funktioita, mutta tarjoaa käyttäjien vastaukset raportoinnin käytettäväksi. ZEF-Platformia ei käsitellä tässä yhteydessä enempää, mutta lukijan on hyvä ymmärtää sen olevan varsinainen lähde analysoitavalle tiedolle.

UI-kerros toteutetaan kehittyneillä web-tekniikoilla, joka on nykypäivänä luonnollinen valinta. ZEF käyttää Enyo-alustaa pohjana lähes kaikissa web-applikaatioissaan. Myös raportoinnin käyttöliittymät on rakennettu Enyo-alustalle, joka tarjoaa kattavan valikoiman työkaluja käyttöliittymien kehitykseen.

Raportoinnin esittämisen apuna käytämme graafisiin taulukoihin erikoistunutta dc.js-kirjastoa. Kirjasto pystyy luomaan selaimessa miellyttävän näköisiä taulukoita erilaisiin tarpeisiin. Eri selaimet ovat kattavasti tuettu ja kirjaston suorituskyky on vähintäänkin riittävä, myös mobiililaitteissa. Taulukot luodaan svg-formaatissa jonka muuttaminen erilaisiin formaatteihin on suhteellisen vaivatonta. Dc.js kirjasto käyttää apunaan Crossfilter.js kirjasto joka tarjoaa erilaisia työkaluja tiedon käsittelyyn ja erilaisten esitysmallien luomiseen.

Nämä kirjastot muodostavat UI-kerroksen ytimen ja tarjoavat jo itsessäänkin monipuoliset työkalut tiedon analysointiin. Interaktiivisella raportilla käyttäjä pääsee analysoimaan dataa suoraan selaimessa. Käyttäjä voi valita suoraan hiirellä taulukoista sopivat suodattimet ja saada suodattimiin osuvat tulokset välittömästi takaisin ruudulle jatkokäsiteltäväksi.

Mihin sitten tarvitaan backend:ia, jos selaimessa toimiva raportointi-applikaatio itsessään kykenee käsittelemään tietoa ja suorittamaan raportointiin liittyviä funktioita? Vastaus kysymykseen on skaalautuvuus. Selain ei yksinkertaisesti selviä suurimmista vastaajamääristä. Jo kymmenien tuhansien vastaajien käsittely alkaa olemaan haasteellista selainpohjaisesti. Suurimpana pullonkaulana esiin nousee tiedon lataaminen selaimeen.

Front-endin rooli on perinteinen ZEF-raportointi arkkitehtuurissa. Se palvelee UI-kerroksen komponentteja, välittää pyyntöjä varsinaiselle raportointi backend:ille sekä suorittaa tiettyjä välimuisti-toimintoja. Myös load balancing on toteutettu front-end kerrokseen.

Tiedon ytimessä

Back-end on koko raportoinnin ydin. Perinteisesti raportoinnissa tiedot raporttiin kerätään pitkäkestoisten prosessien avulla erilaisista tietolähteistä. Tämä tekniikka sopii moneen tarkoitukseen, mutta ei mahdollista interaktiivista raportointia, jossa tieto on kokonaisuudessaan koko ajan helposti käsiteltävissä ja muokattavissa erilaisiin tarpeisiin.

ZEF-raportoinnissa tiedon käsittelyyn ja suodattamiseen käytetään Apache Spark- alustaa. Se mahdollistaa muistipohjaisen tiedon käsittelyn suurilla tietomäärillä. Apache Spark käyttää hyödykseen clusteri-pohjaista mallia, jossa tieto hajautetaan useammalle koneella käsiteltäväksi. Apache Spark mahdollistaa satojen, jopa tuhansien koneiden clustereiden luomisen ja täten varmistaa skaalautuvuuden suurille tietomäärille.

Toinen Apache Sparkin tarjoama tärkeä ominaisuus ovat lyhyet vastausajat tiedon käsittelyssä. Sopivalla konfiguraatiolla Apache Spark pystyy vastaamaan pyyntöön lähes välittömästi, jolloin varsinaiset tulokset saadaan takaisin selaimeen sadoissa millisekunneissa. Tämä tarkoittaa, että selaimessa asetettuihin suodattimiin pystytään reagoimaan riittävällä nopeudella sulavaa käyttäjäkokemusta ajatellen. Toki erilaiset kuormitustilanteet voivat lisätä viivettä joissakin tilanteissa, mutta edelleen asiakkaalle voidaan tarjota miellyttävä kokemus reportoinnin parissa.

Muistipaineita

Muistipohjaisesta tiedon käsittelystä puhuttaessa nousee välttämättä esiin kysymys muistikapasiteetin riittävyydestä. Ongelmaa voi lähestyä kahdesta suunnasta: pitämällä tarvittava muistin määrä mahdollisimman pienenä tai varmistamalla muistin riittävyys clusteria kasvattamalla.

Muistin tarpeen minimointi on luonnollisesti edullisin vaihtoehto varmistamaan muistikapasiteetin riittävyys. ZEF-platformista saadut vastaustiedot käsitellään ja tiivistetään käyttäen tehtävää varten suunniteltuja serialisointi algoritmejä ja HDFS-käsittelijöitä jotka pystyvät optimoimaan tiedon mahdollisimman pieneen tilaan. Tämän jälkeen tiedot kirjoitetaan HDFS-levyjärjestelmään sopivan kokoisissa lohkoissa, josta se on kaikkien clusteriin kuuluvien koneiden saatavilla.

Järjestelmä pitää aktiivisten käyttäjien raportti-tietokannat muistissa clusteriin hajautettuna. Täten raportti saadaan käsittelyyn hetkessä asiakkaan saavuttua raportointi-portaaliin. Ei-aktiivisten asiakkaiden raportti-tietokannat voidaan pudottaa clusterin muistista ja täten vapauttaa muisti muuhun käyttöön. Asiakkaan palattua jälleen aktiiviseksi tiedot voidaan ladata nopeasti HDFS-levyjärjestelmästä clusteriin.

Näillä keinoin muistintarve clusterissa on saatu minimoitua. Clusterin kokoa määriteltäessä laskenta-tehon tarve nouseekin määrääväksi tekijäksi.

Edellä kuvattiin ZEF-raportoinnin ratkaisu hyvin korkealla tasolla. Toimivan järjestelmän toteuttamisessa on jouduttu rakentamaan haastaviakin ratkaisuja arkkitehtuurin eri osa-alueille. Blogin seuraavissa osissa perehdytään tarkemmin näihin yksittäisiin ratkaisuihin!

Jaa:




Ota yhteyttä

Palvelemme kaikissa kyselyihin liittyvissä asiakastarpeissa. Jätä yhteystietosi, niin otamme sinuun välittömästi yhteyttä.