Databricksin hyödyntäminen big data -analytiikassa (2/5) – Kehitys

Edellisessä Databricksiä käsittelevässä blogipostauksessa kerroin millainen kokonaisarkkitehtuuri tarvitaan big data AdHoc-analytiikkaan. Hajautetun laskentamoottorin virkaa toimitti tässä esimerkissä Databricks. Tässä osassa käyn läpi millaisen kehitysponnistuksen tiedon valmisteleminen vaatii.

Hajautetun ja skaalautuvan laskentamoottorin käyttö kehityksessä

Yksinkertaisena liiketoiminnan tarpeena esimerkissä toimii datasetti lentoliikenteen datasta. Liiketoiminnalla on tarve tutkia reilun 10 GB datamassaa aggregoimalla se ensin pienemmäksi, ja tämän jälkeen visualisoida se helposti ymmärrettävään muotoon. Tiedostot on tallennettu Azuren Data Lake Storage Gen2:een, josta ne haetaan Databricksiin ja aggregoidaan pienemmäksi tietomassaksi. Lopuksi tiedot julkaistaan Power BI:lla tarkempaa tutkimista varten. Tämä on kaiken kaikkiaan melko tavallinen data-analytiikan tarve nyky-ympäristöissä.

Huomionarvoista on se, että Databricksin klustereita on helppo tehostaa, ja näin ollen saadaan paljon suurempiinkin datamassoihin skaalautuva toteutus helposti aikaiseksi. Kehityksen voi tehdä muutamalla esimerkkitiedostolla ja kun se on todettu toimivaksi, voidaan laskentatehoa ja datamassaa kasvattaa. Liiketoiminnan käyttäjiltä tämä vaatii perus SQL (tai Python/R/Scala) -osaamista, ja lisäksi kykyä kopioida ja muuntaa muutama vakioskripti. Osaava ja auttavainen toimittaja voi kaventaa kynnyksen vielä pienemmäksi.

Käytin testidatasettinä kahta tiedostoa, joiden yhteiskoko oli noin 600 MB. Laskentakoneena (klusterina) käytin kehitykseen yhtä 4-ytimistä 8 GB:n muistilla varustettua palvelinta (nodea). Raakalatauksen kesto näillä tietomäärillä jäi alle minuutin, ja aggregointi alle puolen minuutin. Varsin vaatimattomia aikoja odotella, eikö?

On tärkeää aloittaa pienellä tuotantodataa vastaavalla aineistolla. Suurimmat toteutusta haittaavat tai estävät tiedon laadulliset ongelmat tulevat yleensä tietoon tässä vaiheessa. Kehitys pienellä aineistolla on kuitenkin verrattain nopeaa siihen verrattuna, että yrittäisimme lukea satoja tai tuhansia gigatavuja tietoa.

Kehitys Databricks-palvelun pystytyksestä tiedon visualisointiin Power BI:llä kesti noin tunnin. Toinen tunti kului toteutuksen viilaamiseen ja Power BI -raportin testailuun, sekä laajemman datasetin ajamiseen. Tiivistettynä voi siis sanoa, että niin ”rautaan” kuin kehitykseenkään ei uponnut valtavasti resursseja, joskin toteutus oli kohtalaisen yksinkertainen. Tämä antaa kuitenkin hyvää suuntaa tarvittavan panostuksen arvioimiseksi.

Seuraavassa blogipostauksessa kerron miten Databricksin skaalaaminen vaikutti ajoaikoihin.

Lue myös: Databricksin hyödyntäminen big data -analytiikassa (1/5) – Arkkitehtuuri

(Blog in English coming soon...)