Saimme joku aika sitten tehtäväksi mielenkiintoisen projektin. Pohjimmiltaan kyse oli antureiden tuottamasta raakadatasta. Tehtävänä oli tuottaa nivaska raportteja eri laitteiden antureilta saapuvasta datasta. Laitteiden määrä lisääntyy koko ajan, jokainen anturi tuottaa dataa 5-15 sekunnin välein 24/7. Osa datasta on kumulatiivista summadataa, osa taas antureiden tuottamia mittausarvoja.
Teknologiavalinta oli tehty etukäteen, SQL Server 2012 Standard. Aikataulu oli tiukka ja budjetti pieni. Muutamia haasteita tunnistettiin heti alkuun:
- Dataa on paljon, ja on varauduttava siihen että vuoden päästä sitä on paljon enemmän
- Anturidata on muodoltaan haasteellista raportointia ajatellen. Datassa oli mukana kumulatiivisia summia, lisäksi raporteilla pitäisi tutkia kestoaikoja sekä muita mittareita, jotka saadaan laskettua rivien välisistä erotuksista. Koko datanmassa sellaisenaan SQL-kannassa aiheuttaisi lisäksi takuuvarmasti suorituskykyongelmia.
- Antureiden antamat lukuarvot eivät kerro loppukäyttäjälle mitään, ne on käännettävä ymmärrettäviksi, tämä nyt oli kuitenkin ongelmista pienin
- On myös otettava huomioon antureilta tulevat virhearvot, nollautumiset jne.
Jossain vaiheessa projektia naureskelimme että hei, tämähän onkin nyt sitä hypetettyä Big Dataa!
Hieman dataa tutkittuamme totesimme että yli 95% antureiden tuottamasta datasta ei kiinnosta ketään. Itse asiassa raportoinnin kannaltahan käyttäjää kiinnostavat ne rivi, joilla on tapahtunut jotain, eli anturin antama arvo on muuttunut. Täytyy saada kiinni se rivi – ja ajanhetki – jolla haluttu anturiarvo on muuttunut – sekä tätä edeltävä rivi. Tämän jälkeen lasketaan kestot, kappaleet, rivimäärät sekä otetaan kumulatiivista summista erotukset.
Tällöin päästään eroon itse asiassa kaikista datan ongelmista; data saadaan raportointiin kelpaavaksi, sekä suorituskykyongelmista päästään eroon kun, suuri osa riveistä heitetään romukoppaan.
Miten tämä sitten tehdään teknisesti? Saamme joka päivä snapshotin päivän tapahtumista. Kaikeksi onneksi yhden päivän datamassa mahtuu serverin muistiin helposti nyt ja tulevaisuudessa. Tästä datasta rakennetaan tietovarastoon kelpaava datasetti seuraavasti Transact SQL:llä:
- Luetaan anturidata tietotyyppi kerrallaan @Temp-tauluun, tauluun luodaan PRIMARY KEY IDENTITY(1,1)-sarake
- Käyttäen hyväksi tuota muistissa olevaa IDENTITY-saraketta, loopataan taulun sisältö läpi rivi kerrallaan. Koska data on serverin muistissa, sen läpikäynti SQL:llä on hyvin nopeaa. Verrataan rivi kerrallaan käsissä olevia arvoja edellisen käsitellyn rivin arvoihin.
- Jos käsissä olevalla rivillä on tapahtunut relevantti muutos, kirjoitetaan ko. rivi raporttitauluun. Muistissa on myös edellisen rivin arvot – sekä edellisen raporttitauluun kirjoitetun rivin anturiarvot, niitä käyttäen saadaan laskettua tarvittavat kestot kumulatiivisten summien erotuksina sekä aikaleimoista laskettua kestot.
Lopputuloksena käsissä on nopeasti toimiva, käyttäjäystävällinen, pieni tietovarasto alun perin massiivisesta anturidatasta.
SQL-logiikan läpiajo päivittäin vie muutaman minuutin. Tässä esimerkissä siis paljon hypetetty Big Data puristetaan vanhanaikaisilla, halvoilla ja nopeilla SQL-logiikoilla loppukäyttäjän hyödynnettävään muotoon.
Vastaavan kompressoinnin datalle voi tehdä muillakin tekniikoilla, tässä tapauksessa yllä kuvattu SQL-logiikka oli nopein, käyttäjäystävällisin ja kustannustehokkain tapa ratkoa anturidatan raportintekijälle heittämät haasteet.
