BI-miehen perjantai

On synkkä ja myrskyinen perjantai-iltapäivä. Käyn läpi toisen konsultin tekemää tietovarastoa ja ETL-latauksia. Otsasuoni pullistuu. Yritän oikean käden tiiviillä hiirityöskentelyllä epätoivon vimmalla löytää edes yhden parhaiden käytäntöjen mukaisen toteutuksen spagetin joukosta. Vasen käsi hapuilee farkkujen taskun pohjalta verenpainelääkitystä, siinä kuitenkaan onnistumatta. Päässä pyörii epätoivoisia ajatuksia:

  • Jos tehdään jotain uutta (= ei ole ennen tehty tietovarastoja), olisiko syytä edes hieman opiskella asiaa? Olisikohan joku jo maailmalla miettinyt, miten homma kannattaisi tehdä?
  • Löytyykö tekijöiltä minkäänlaista kunnianhimoa työn jäljen suhteen?
  • Eikö osaamista jaeta lainkaan edes yhden yrityksen sisällä? Eivätkö konsulttiyritykset edes halua luoda omia parhaita käytäntöjä? Onko busineksen ainut arvo laskutetut eurot, työn laadulla ei ole niin väliä? Kolikon kääntöpuolella on tietysti se, että puolivillaisesti tehty toteutus generoi enemmän laskutustunteja.

Normipäivä siis.

Ei hitto. Olisipa peruskoulussa opetettu googlauksen alkeet. Olisi edes joku perusasia kunnossa. Jos vaikka olisi väistetty edes yksi pahimmista munauksista ao. vartissa kirjoitetulta syntilistalta…

  1. SQL Server Integration Services-DW:n paras oppikirja tehtiin jo vuonna 2005! Huikeaa. Lue tämä ennen kuin teet ensimmäistäkään työliikettä. Moni alla olevista vinkeistäkin löytyy tästä kirjasta http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/books/microsoft-data-warehouse-dw-toolkit/
  2. Mallinnus. Oli se sitten tähtimalli tai DataVault. Dimensiodata dimensioon, faktat faktoihin jne. Määrittelyvaiheessa on tehtävä tietokannan mallinnus. Mallinnus on koko homman A ja O. Eräässä casessa oli päädytty tälläämään kaikki erityyppiset faktat yhteen ja samaan faktatauluun. No, tässä tapauksessa ei sitten voinut oikein puhuakaan agilesta kehityksestä, joustavuudesta tai kannan suorituskyvystä, ainakaan samassa lauseessa.
  3. Ensimmäiset johtopäätökset tekemisen laadusta voi melkein vetää jo siitä, onko SSIS:ssä käytetty mitään template-pakettia vai ei. 90%:ssa tapauksista ei. Omalla template-paketilla saat esim. lokitukset ja virheenkäsittelyt kuntoon. Ja yhtenevät muuttujat, dataflowt jne eri pakettien välillä – ja tekemisen edes jollain tasolla yhteneväiseksi eri kehittäjien kesken. Peukalosääntö: 1 taulu per 1 paketti. Jossain Microsoftin omassa esimerkeissäkin on tehty koko DW parilla paketilla. Mutta miten hoidat useamman kehittäjän työskentelyn tai suorituskyvyn optimoinnin, jos koko DW on yhdessä paketissa? Näitä virityksiä on nähty monessa projektissa.
  4. Mieti ETL:ää tehdessäsi kahta asiaa: ylläpidettävyys ja suorituskyky. Väärin käytettynä SSIS tappaa suorituskyvyn. SSIS perustuu muistin käyttöön, osa valmiskomponenteista vaatii koko datan lukemisen kerralla palvelimen muistiin. Kaksi karmeaa käytännön esimerkkiä kotimaisista tietovarastototeutuksista:
    1. Tietovarastoon kirjoitettiin kaikki data prosareilla, joita komennettiin Oledb Command-komponentilla. So what? No, jokainen tietovaraston läpi mennyt uusi rivi kutsui yksitellen prosaria. Eli miljooonan rivin kirjoittaminen kantaan generoi miljoona yksittäistä kyselyä. Loppuasiakas ihmetteli, kun ei meinannut latauksissa yö riittää. No ei ihme.
    2. Toisessa casessa tietovaraston rakentamisessa oli käytetty SSIS-paketteja – mutta kaikki oli tehty SQL:llä MERGE-kyselyitä käyttäen. Ylläpito oli ”hieman” hidasta ja kankeaa… ja olisihan sitä voinut myös googlettaa, suositteleeko MERGE:n käyttöä maailmalla kukaan muu… Tässä projektissa oli onnistuneesti jätetty käyttämättä kaikki SSIS:n hyvät puolet ja yhdistetty siihen päälle suorituskyvytön ja hankalasti ylläpidettävä SQL-koodi.
  5. Tietokannan perusasiat kuntoon. Ovatko indeksit, Foreign Keyt, Primary Keyt  tuntemattomia käsitteitä? Ei uskoisi, ellei omin silmin näkisi kantoja, joista kaikki mainitut pikkudetaljit ovat päässeet jotenkin unhottumaan. Tai relaatiot eri taulujen välillä hoidetaan SUBSTRING-funktioilla. Tämäkin on nähty, usko tai älä.
  6. Kannattaa perehtyä uusien työkaluversioiden tuomiin mahdollisuuksiin huolella ja ajatuksella. Äkkinäinen voisi kuvitella, että esimerkiksi kymmenessä vuodessa ETL-työkaluun saattaisi tulla joitain sellaisia ominaisuuksia, jotka kannattaisi jopa ehdottomasti ottaa käyttöön. Ehkä version 2005 kaikkia ominaisuuksia ei enää kannata käyttää vuonna 2016?

 

3 comments on “BI-miehen perjantai

  1. Jussi Järveläinen on

    ASIAA! Ymmärrä mitä teet, tee mitä ymmärrät! Jos et ymmärrä, hanki ymmärrys! Tee mieluummin oikeita asioita vähän väärin kun vääriä asioita hemmetin oikein!

    Vastaa
  2. Mika Laukkanen on

    Tämä on myös ongelma, joka liittyy projektien johtamiseen. Jokaisessa EDW/DW projektissa pitäisi olla ainakin yksi henkilö, jonka vastuulla vahtia että asiat tehdään kunnolla ja hyvien käytäntöjen mukaisesti. Yksi jos toinenkin DW on ryssitty, kun mitään monitorointia ei ole ollut. Sitä ei pitäisi jättää vain ETL-tekijöiden käsiin. Vuosia sitten olin isossa DW-projektissa, jossa oli useita toimittajia. Aika ajoin oli päiviä, jolloin meidän tuli monitoroida muiden tuotoksia ja toistepäin. Se oli ihan hyvä tapa (yksi monista) pitää homma kasassa.

    Vastaa
  3. Jani Liimatta on

    Totta. Monitorointi on myös hyvä tapa oppia muiden tekemisistä. Tuo tekemisen laatu teknisellä tasolla on sellainen asia, jota toisaalta mikään laatujärjestelmä tai loppuun asti hiotut tilaus-toimitusprosessitkaan eivät välttämättä osaa hanskata. Ja edelleen vaatii sitä tahtotilaa, että parhaisiin käytäntöihin halutaan oikeasti panostaa.

    Vastaa

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

Yhteydenotto

Mikäli olet kiinnostunut yrityskohtaisista palveluista tai sinulla kysyttävää palvelujemme sisällöstä, niin ota yhteyttä oheisella lomakkeella tai soita Mikalle numeroon 040 845 8432.

Please leave this field empty.