4.05.2017 / Ville Niemijärvi

Olimme aikanaan tekemässä QlikView-toteutusta ja ihmettelimme miten karmean näköistä jälkeä edellinen konsulttitalo oli tehnyt.

Koodi oli hirveää spagettia ja ulkonäkö oli karmea. Miten niin hyvällä tuotteella, joka on tunnettu hyvästä visualisoinnista, voi tehdä tällaista jälkeä?

Paljastuikin, että kyse ei ollut konsulttien taidoista vaan siitä, että asiakas oli halunnut säästää ja investoida vain muutaman päivän kerralla.

Välillä yritys teki kehitystä omin voimin ja sitten taas konsultti paikalle pariksi päiväksi.

Toisaalta arkkitehtuurisuunnitteluun ja tietomallinnukseen ei panostettu laisinkaan. Lähdettiin vain tekemään.

Ei paljoa mietitty miten ja missä dataa summataan. Mikä lataus hoitaa keskitetysti tuotetiedot ja tallentuuko johonkin tuote- tai asiakasmaster.

Yhtenäisestä käyttöliittymäsuunnittelusta (UI/UX) puhumattakaan.

Tehtiin siis tilkkutäkkiä ja kokonaisuutta ei ehditty tai pystytty hahmottamaan. Vuosien varralle toteutus paisui ja paisui. Lopulta oli kasassa 20GB mötkylä, jonka suorituskyky oli heikko ja jota ei voitu laajentaa. Ja se näytti aivan karmealta.

Oltiin solmussa.

Vaikka et käytä tietovarastoa, älä laista arkkitehtuurisuunnittelusta ja tietomallinnuksesta.

Vaikka lähtisitkin nopeasti liikkeelle, älä unohda arkkitehtuurisuunnittelua ja tietomallinnusta.

Vaatimusmäärittelyn ohella nämä ovat tärkeimmät vaiheet business intelligence -hankkeissa.

Tämä pätee myös silloin kun et käytä tietokantaratkaisua pohjalla tiedon tallentamiseen.

Myös Qlik, Tableau tai PowerBI toteutus vaatii sen arkkitehtuurisuunnittelun.

Niihin ei tarvitse käyttää aikaa viikkotolkulla. Päivässäkin saat aikaan valtavasti ja saatat säästää ehkä kymmeniä tai satojatuhansia tai ainakin annat BI-ympäristöllesi pari vuotta lisäaikaa kun spagettikoodihirviöitä ei tarvitse rakentaa uudestaan vuoden päästä.

Tässä oma esimerkki yhdestä isohkosta tietovarastohankkeesta.

  • piirsin loogisen tietoarkkitehtuurin tunnissa powerpointiin. Karkea esimerkki löytyy edellisestä blogikirjoituksesta.
  • heitin sen asiakasorganisaation experttien kommentoitavaksi
  • muutamat asiat olivat vaihtoehtoisia, emme osanneet päättää (pilvi vs. on-premise vs. hybridi, datan aggregointi: miten ja missä, MPP vs. normirelaatio)
  • näitä päätöksiä varten tilasimme ulkopuolisen asiantuntijan, pidimme 2 kpl noin 3h työpajoja
  • vedimme konsulttien, meidän ja asiakasorganisaation suositukset yhteen ja teimme päätökset arkkitehtuurista

Kalenteriaikaa saattoi kulua ehkä pari viikkoa mutta työaikaa ehkä vain pari päivää. Ei kovin iso investointi kun lähdetään rakentamaan satojen tuhansien investointia.

Älä hinkkaa arkkitehtuuria liian kauan, tärkeintä on lähteä liikkeelle

On tapauksia missä yritys ei ole osannut lähteä liikkeelle laisinkaan.

On pohdittu kumpi on parempi:

  • MS SQL Server vai Oracle
  • Azure vai AWS
  • SSIS vai Informatica
  • normi-sql vai mpp vai datan virtualisointi

Vaihtoehtojen runsaus ja joskus myös konsulttien kykenemättömyys antaa suosituksia (ja olla jotain mieltä) on aiheuttanut sen, että ei ole tehty mitään tai että hanke on viivästynyt kuukausilla.

Vaikka tekisit “väärän” päätöksen, voi tuon päätöksen muuttaa. Ja hankkeen menestykselle on tärkeämpää saa loppukäyttäjän palautetta ja kokemusta uudesta arkkitehtuurista mahdollisimman nopeasti, kuin yrittää päättää täydellinen arkkitehtuuri kerralla.

Ahteri edellä puuhun, soitellen sotaan ja takki auki ei kannata edetä. Mutta älä yliajattele, älä ylisuunnittele. Sekään ei ole hyväksi.

Kyseessä on oppimisprosessi. Lähde siis liikkeelle pienesti ja opi matkan varrella. Tärkeintä on vain lähteä.

Kyllä nämä jutut vähän maksavatkin

Vedin kerran asiakkaalla toimittajien kilpailutusta. Erään toimittajan konsultin hieman ylimielinen kommentti hieman kummaksutti kun kysyimme häneltä perusteluja suurille työmääräarvioille:

“No kyllä nämä vaan maksavat”

Kaveri oli tietovarastoinnin huippuosaaja ja hänen leipälajina ei ollut myynti tai (potentiaalisten) asiakkaiden ärsyttäviin kysymyksiin vastaaminen.

Mutta hän oli oikeassa tuossa tylyssä vastauksessa.

Kyllä näissä vain menee aikaa ja se maksaa.

Ne ketkä tuntevat työtapaani tai kirjoituksiani, tietävät että halveksin ylisuuria työmääräarvioita ja asiakkaita kuppaavia konsultteja. Tykkään tehdä hommat nopeasti ja joskus oikoa mutkiakin.

Mutta olen itsekin joskus vääntänyt 20-30 päivää yhtä dashboardia. Se oli kallis työpöytä.

Mutta kannattaa huomata, että tuotetoimittaja haluaa myydä asiakkaalle lisenssin.

Hänen etuna on vähätellä työmäärän suuruutta. Jos työmäärä on kovin iso, voi se haitata lisenssimyyntiä. Siksi kannattaa mainostaa, että meidän softalla teet hienot raportit päivässä.

Konsultit näkevät usein pidemmälle. Se on heidän intresseissään. Ajatella pari vuotta eteenpäin. Ajatellaan laajennettavuutta, skaalautuvuuta, suorituskykyä, tulevia käyttötapauksia. Ajatellaan käytettävyyttä, käyttöönottoa, koulutusta.

Konsulttina tietenkin näen jälkimmäisen näkökannan paremmaksi.

Kuuntelit sitten konsulttia, tuotemyyjää tai lompakkoasi, suosittelen seuraavaa:

  • pysähdy edes edes päiväksi miettimään tietoarkkitehtuuriasi
  • älä mieti päätäsi puhki, loppukäyttäjän palaute ja oppi on niin tärkeämpää kuin saada täydellistä kerralla


9.12.2015 / Jani Liimatta

Syystä tai toisesta on tullut viime aikoina törmättyä useammin ja useammin XML-muotoiseen dataan tietovarastojen datalähteenä. Yksi yleisimmistä käyttötapauksista taitaa olla tuotetiedon hallintajärjestelmien (PDM/MDM) tuottamien XML-dokumenttien hyödyntäminen.

SQL Serverissä on ollut XML tuki jo versiosta 2005 asti. Harvempi sitä on kuitenkaan tietovarastokäytössä hyödyntänyt. XML-tuki löytyy myös SSIS-välineessä. Ne jotka ovat sitä yrittäneet oikeissa projekteissa käyttää, ovat huomanneet sen vaillinaiset ominaisuudet. Kolmansien osapuolien parempia (ja maksullisia) SSIS- XML-lähdekomponenttejakin on olemassa – mutta miksi ei käyttäisi natiivia Transact-SQL:ää? Pienellä oppimiskäyrällä SQL Serverin XML-ominaisuuksista voi saada paljon irti.

Eli lyhyesti ja ytimekkäästi päivän idea on laajentaa tietovaraston tuotedimensiota SQL Serverin XML-sarakkeella. Erityisesti PDM-järjestelmissä tallennetaan monessa tapauksessa valtavasti tuotetietoa, joiden hyödyntäminen ja tallentaminen kokonaisuudessaan relaatiomalliin on järjetöntä. Miksi ei tallennettaisi tietovarastoon koko XML:ää? Osa sisällöstä on toki pakko kääntää sarakkeiksi, monasti jo historiointitarpeidenkin vuoksi (Slowly Changing Dimension)

Tuumasta toimeen.

1) Luodaan taulu, jossa on XML-tyyppinen sarake

[code language=”sql”]
CREATE TABLE D_ProductXML
(Product_ID INT IDENTITY (1,1),
ProductName VARCHAR(50),
ProductXML XML)
[/code]

2) Tuupataan dataa tauluun (elävässä elämässä tuupattaisiin toki hieman eri lailla ja XML:tkin seuraisivat standardia, he jotka jaksavat lukea tätä juttua tänne asti todennäköisesti tämän tietävätkin). Sitten taas ne, jotka saavat näppylöitä polkupyörädemoista, ottakaa hydrokortisoonipurnukat tässä vaiheessa esille.

[code language=”sql”]
INSERT INTO D_ProductXML (ProductName, ProductXML)
VALUES (‘Mummopyörä’,

<bike>
<id>1</id>
<status>Active</status>
<names>
<name>Bike</name>
<name>Cykel</name>
</names>
<parts>
<parts id="1">Etupyörä</parts>
<parts id="2">Runko"</parts>
</parts>
</bike>

),
(‘Kilpapyörä’,

<bike>
<id>2</id>
<status>Passive</status>
<names>
<name>Competition</name>
<name>Cykeln</name>
</names>
<parts>
<parts id="1">Etupyörä 22"</parts>
<parts id="2">Kisarunko</parts>
</parts>
</bike>

)
[/code]

Eli meillä on nyt käsissä maailman yksinkertaisin tuotetaulu, jossa on surrogaatti, tuotteen nimi sekä lisää dataa XML-sarakkeessa. Tätä XML:ää voi hyödyntää SQL:ssä monella tavalla.
Esimerkki1. Pidetään data flattina mutta kysellään XML:stä ensimmäinen nimi sekä tuotteen status. Jos tämä näyttää monimutkaiselta, tuon xqueryn voi toki piilottaa raportintekijältä vaikka näkymän taakse.

[code language=”sql”]
SELECT
Product_ID,
ProductName,
ProductXML.value(‘(bike/names/name)[1]’, ‘varchar(50)’) as Name1,
ProductXML.value(‘(bike/status)[1]’, ‘varchar(50)’) as ProductStatus
FROM D_ProductXML
[/code]

Lopputulos näyttää tältä:

Esimerkki1

 

 

 

Esimerkki2. Käyttämällä CROSS APPLY:a voidaan XML räjäyttää riveiksi. Tässä halutaan nähdä käytetyt komponentit polkupyörittäin riveillä. Kahdesta tuoterivistä populoituu yksi rivi per yksi komponentti.

[code language=”sql”]

SELECT
Product_ID,
ProductName,
Parts.value(‘(text())[1]’, ‘varchar(100)’) as Part
FROM D_ProductXML
CROSS APPLY ProductXML.nodes(‘//parts/parts’) as P(Parts)

[/code]

Lopputulema näyttää jotakuinkin tältä:

Esimerkki2

 

 

 

 

Summa summarum, hyödyt:

  • Ylläpito: XML voi elää omaa elämäänsä. Uuden sarakkeen lisääminen ei tarkoita välttämättä ensimmäistäkään muutosta tietovarastoon tai ETL:ään. XML:n uutta tietuetta voi hyödyntää suoraan näkymässä tai kyselyllä
  • Suorituskyky: XML:n lukeminen kantaan on nopeampaa kuin XML:n käsittely tiedostona – käyttötapauksesta riippuen. Toisaalta esim. laskurivin mallintaminen riveinä XML:ksi laskun otsikkoriville ei välttämättä ole se paras idea
  • ETL:n tekemisen kannalta natiivi-SQL:n käyttö XML:n lukemisessa on mielestäni yksinkertaisempaa ja vähemmän virhealtista kuin SSIS:n omien komponenttien käyttö. Etenkään jos XML:t ovat näitä esimerkkejä yhtään monimutkaisempia.

18.03.2015 / Ville Niemijärvi

Edellisessä kirjoituksessa muistutin miksi vähänkään isomman yrityksen ja vakavasti itsensä ottavan CIO:n ei kannata rakentaa yrityksensä tietoarkkitehtuuria ja johtamisjärjestelmää pelkästän Qlikin varaan. Tai minkään raportointityövälineen.

Turvallisempi, suorituskykyisempi, skaalautuvampi ja pitkällä tähtäimellä edullisempi ratkaisu on rakentaa se tietovaraston päälle.

Tästä huolimatta tiedän, että Suomessa valtaosa Qlik-ratkaisuista on tehty suoraan operatiivisten järjestelmien päälle.

Tällaisissa tapauksissa voidaan mennä parin vuoden sisällä todella syvälle suohon tai koittaa selviytyä tilanteesta kunnialla. Eli nyt tarkkana: kumpaan kastiin haluat kuulua?

Käyn seuraavaksi läpi jälkimmäisen vaihtoehdon; miten tehdä hyvä Qlik-ratkaisu ilman tietovarastoa.

Simuloi Qlikillä tietovarastointia

Qlikissä on alkeellinen sql:n kaltaiseen komentokieleen perustuva ns. etl-työväline. Voit ladata ja muokata sillä dataa aika monipuolisesti. Qlikissä on myös omat datatiedostot (tiedosto.qvd), joihin voi tallentaa suuria määriä tietoa, ennen kuin sen vie varsinaiseen qlik-sovellukseen (tiedosto.qvw).

Qlikillä on siis kaikki komponentit, joilla voidaan toteuttaa samankaltainen arkkitehtuuri ja toiminnallisuus kuin tietovarastossa. Lisäksi kun otat käyttöön muutamia parhaita käytäntöjä, jotka ovat tietovarastomaailmassa arkipäivää, pääset varmasti säädyllisen lopputulokseen (edelleen olet menossa perse edellä puuhun mutta nyt sentään tyylillä).

Seuraavassa on kolme tärkeää oppia tietovaraston maailmasta, jotka kannattaa ottaa käyttöön Qlik-ympäristöä toteuttaessa.

1. Tietomallinnus ja datan harmonisointi on tärkeintä

Tietovarastossa on tärkeää määrittää yhteiset käsitteet ja laskentasäännöt. Tietovaraston perusperiaatteita on datan yhteismitallistaminen – tarjota yhdet yhteiset luvut yhdestä paikasta.

Tähän päästään mallintamalla yrityksen tiedot, päättämällä miten se kate lasketaan tai mikä on yrityksen virallinen tuote- tai tilihierarkia. Miten hyvitykset ja alennukset huomioidaan myynnissä ja puhutaanko ylipäätään myynnistä, liikevaihdosta vai laskutuksesta.

Tämän lopputuloksena on tietomalli. Tai käsitemalli. Se kuvaa yrityksen tärkeimmät käsitteet ja niiden väliset suhteet selkokielellä. Tietomalli on tietovaraston sydän ja sisäelimet, runko ja ranka.

tietomalli
Tietomalli, joka sopii 9/10 suomalaisista tietovarastoista.

 

Tietomalli toimii ennen kaikkea kommunikointivälineenä IT:n ja liiketoiminnan välillä. Se auttaa myös Qlik-kehittäjiä hahmottamaan, miten eri tietokokonaisuudet linkittyy toisiinsa.

Qlik-sovelluksia tehdessä kannattaa käyttää hetki aikaa käsitemallinnukseen. Lupaan, että tämä maksaa itsensä takaisin moninkertaisesti.

2. Kerroksellinen arkkitehtuuri (2- tai 3-kerros)

Tietovarastot toteutetaan kerroksittain. Alunperin tietovarastoissa oli kaksi kerrosta: ns. datan latausalue (staging-tietokanta) ja varsinainen tietovarasto. Nykyään data vaultin myötä näkee 4-tasoarkkitehtuureja. Tätä samaa kerroksellisuutta kannattaa suosia Qlikissä.

Onkin erittäin tärkeää erotella Qlikissä data ja sovellukset toisistaan. Tallenna siis operatiivisten järjestelmien data kuten laskutus, ostotilaukset, varastosaldot, tuotteet… kukin omaan Qlikin datatiedostoon (qvd).

Määrittele lisäksi hallintamalli kullekin datatiedostolle ja dokumentoi latausrutiinit hyvin: millä syklillä, järjestyksellä ja millä logiikalla tärkeitä yhteisiä käsitteitä ja etenkin dimensioita päivitetään.

Tuotteet, asiakkaat, organisaatio, tilihierarkia jne. ovat useimmiten tärkeimpiä yhteisiä dimensioita. Määrittele näille tiedon omistaja, joka vastaa siitä, että dimensiot pysyvät kunnossa ja data on validia.

Näin datatiedostot ajavat tietovaraston virkaa. Tärkeimmät tiedot ovat keskitetyssä paikassa ja Qlikin sovellukset pystyvät myös lukemaan niitä huomattavasti nopeammin kuin operatiivisia tietolähteitä.

Pyri minimoidaan suoraan Qlik-sovelluksiin (esim. johdon työpöytä) tietojen lataaminen, vaikka se kuinka kivalta ja nopealta tuntuisikin. Se, että viet datan ensiksi qvd-tiedostoon, vie ehkä 15 min enemmän aikaa mutta vuoden sisällä tämä voi säästää sinulta 15 päivää. Lue aiheesta lisää: Usain Bolt Jukolan viestissä.

3. Datan yhteiskäyttö: pyritään yhteen totuuteen

Kun datat on keskitetysti ylläpidetyissä datatiedostoissa, voit käyttää samoja tiedostoja useissa eri sovelluksissa. Tuotteita saatetaan tarvita kymmenellä eri sovelluksella ja raportilla – nyt se haetaan kaikille raporteille yhdestä keskitetystä paikasta. Sama pätee myynteihin, ostoihin, saldoihin, kiertonopeuksiin ja muihin tärkeisiin mittareihin.

Tällöin käyttäjät saavat yhteismitallista tietoa mutta helpotat myös IT-osaston työtä kun tiedot ovat helpommin hallittavissa kun liittymiä on vähemmän ja laskentalogiikat hallitaan keskitetysti.

Yhteenveto

Vaikka päädyt innoissasi tekemään Qlik-ratkaisun ilman raportointikantaa tai tietovarastoa, älä hätäänny. Plöröt on housuissa mutta ne voi pestä ja tilanteesta voi selvitä kunnialla. Tässä tiivistetyt ohjeet:

  1. Tee tietomalli
  2. Tee kevyt hallintamalli, määritä latausrutiinit ja tiedon omistajuudet
  3. Erota data ja sovellukset toisistaan (2- tai 3-tasohierarkia)
  4. Yhteismitallista ja yhteiskäytä: pyri yhteen yhteiseen totuuteen

Alla vielä kuvina miten Qlikillä voi tehdä a.) tuhoa b.) kohtuullisen fiksusti ja c.) todella järkeviä ja kestäviä ratkaisuja. Valinta on sinun (kuten vastuukin).

Qlik arkkitehtuuri tehtynä väärin
Qlik sillisalaatti: älä lataa sovelluksiin tietoa suoraan lähdejärjestelmistä.

 

Qlik arkkitehtuuri tehtynä lähes oikein
Erottele data- ja sovelluskerros toisistaan. Näin simuloit tietovarastointia ja teet eheämmän kokonaisuuden.

 

Qlik arkkitehtuuri tietovaraston kanssa on kestävä
Fiksuin ratkaisu on kuitenkin rakentaa Qlik-ratkaisu tietovaraston päälle. Näin varmistat modulaarisuuden, turvallisuuden, skaalautuvuuden ja suorituskyvyn.

6.11.2013 / Ville Niemijärvi

QlikView siirtyi tänä vuonna ansaitusti business intelligence -ohjelmistojen Suomen markkinajohtajaksi. Tämä oli vain ajan kysymys. Onnittelut QlikView:lle.

Vaikka kyseessä on huipputuote, törmään jatkuvasti asiakkaisiin, jotka ovat ihan solmussa sen kanssa. Yrityksillä saattaa olla kymmeniä, jollei satoja erillisiä raportteja täynnä spagettikoodia ja kukaan ei enää tiedä mikä luku on oikein. Ferrari on siis lähtenyt lapasesta.

Qlikview:llä on niin helppo tehdä raportteja, että joskus tulee vauhtisokeus ja suunta hukkuu. Tällöin raportointi on vähän kuin Usain Bolt vetäisi amfetamiinia ja laitettaisiin suunnistuskisoihin ilman karttaa. Vauhti on hurja ja onhan sitä kiva katsoa mutta yhtään rastia ei löydy ja maaliin tuskin päästään.

A Fool with a tool is still a fool

Oletko kuullut koskaan kaverista, joka olisi alkanut rakentamaan omakotitaloa ilman ensimmäistäkään piirrustusta? Ilman arkkitehtuuria, ilman näkemystä, mikä tulee mihinkäkin ja missä järjestyksessä? Alkanut vain latomaan tiiltä toisen päälle. No et tietenkään. Se olisi hölmöläisten hommaa. Omakotitalo maksaa  satojatuhansia, joten se kannattaa suunnitella  ja tehdä kerralla kunnolla.

Raportointiympäristöt maksavat myös usein satojatuhansia. Olen ollut useissa hankkeissa, missä on laitettu miljoona euroa vuodessa pelkästään konsulttityöhön, tähän on tullut päälle ohjelmistolisenssi ja hardware-kustannukset.

Silti raportointihankkeita, varsinkin näinä “self-service BI:n” aikoina, lähdetään tekemään ilman ainuttakaan suunnitelmaa. Qlikview, Tableau, Microsoftin PowerPivot… mainostavat kaikki sitä miten helppo kenen tahansa on tehdä omia raportteja, analysointeja ja visualisointeja.

Tämä on oikein hyvä, teknologian tekeminen käyttäjille helpoksi on mahtavaa. Mutta tällöin unohtuu helposti ne piirrustukset. Aletaan latomaan tiiltä toisen päälle. Ja kun viimeistellään yläkerran tapetteja ja vaimo mallailee tauluja seinille huomataan, että hups, portaat jäi tekemättä. Mietitään, että olisikin ihan kiva jos parveke olisikin etelään ja jos sittenkin vedettäisiin ne putketkin johonkin.

Gehry, Gaudi, Wright…

Tietomallinnus ja -arkkitehtuuri on tätä varten kun puhutaan raportointiympäristöistä. Se vie jokusen viikon tai kuukauden yrityksen ajasta ennen kuin päästään tekemään upeita visualisointeja, mutta sen avulla säästää oikeasti kymmeniä, ellei satojatuhansia euroja. Tietomallinnus ei ole vain tähtimallien tai ER-kaavioiden piirtämistä. Se on tietotarpeiden kartoittamista ja raportoinnnin ollessa kyseessä: päätöksentekoprosessien kartoittamista. Selvitetään mihin kysymyksiin raportoinnilla todella halutaan vastaus.

Selvitetään siis tarvitsetko oikeasti sen harrastushuoneen, josta kuitenkin tulee ostos-TV hankintojesi hautausmaa. Tarkastetaan olisiko aidon viinikellarin sijaan tarpeellisempaa rakentaa 4 lapsellesi toinen makuuhuone.

Hengitä syvään – ei se mihinkään katoa

Älkää ymmärtäkö väärin, minä jos kuka arvostan helppokäyttöistä informaatioteknologiaa. Kun aloin opiskelemaan alaa, sammutin tietokoneen vetämällä töpselin pois seinästä. En oikeasti tiennyt miten se sammuisi muuten. Mutta kun välineet on tehokkaita ja helppokäyttöisiä, tulee helposti sohittua sinne tänne. Qlikview, Tableua ja MS:n Excel-integroitu BI on helppokäyttöistä ja ne ovat todella tehokkaita välineitä. Olemme tulleet kymmenessä vuodessa valtavia harppauksia eteenpäin.

Mutta kun saat huipputuotteen eteesi, se on kuin avaisi huippuviskin – ei sitä siemaista ykkösellä huiviin. Sitä pyöritellään, katsellaan, nautitaan. Hahmotellaan mihin kaikkeen se pystyy. Siemaistaan pieni siivu – ja lasketaan lasi alas. Ja aletaan suunnitella huimia seikkailuja joihin ryhtyä yhdessä.