3.11.2016 / Jani Liimatta

Oikeaoppinen menetelmä budjettien laadintaanhan on aina alhaalta ylös. Eli laaditaan budjetit alimmalla mahdollisella tasolla, ja summataan sieltä ylöspäin yhteen. Näin yleensä saadaan aikaiseksi luotettavammat budjetit.

No, joskus voi tietysti miettiä, onko sinne alimmalle tasolle aina mielekästä tai edes mahdollistakaan pähkäillä oikeita lukuja? Joskus se vaan on mahdotonta. Ja olisi ehkä kuitenkin hyödyllistä nähdä ne budjettiluvut siellä atomitasolla. Esimerkiksi, jos tuote jakautuu satoihin eri variaatioihin. Askartelepa siitä sitten budjetti kaikille myyntialueille. Tai jos tarkin myyntialue on kuntataso? Budjetoinnin rivimäärä räjähtää käsiin. Perinteisesti tässä on käytetty staattisia kertoimia, tai viime vuoden myyntejä. Voisikohan tämän tehdä jotenkin tarkemmin ja automaattisemmin?

Eräällä asiakkaalla haasteena oli että budjetit luodaan tuotteittain ja kuukausittain. Nämä pitäisi sitten jakaa myyntialueille - eli esim. 10 tuotetta * 12 kk * 30 aluetta = 3600 riviä. Käsipelillä tekemätön paikka jo muutamallekin tuotteelle.

Esimerkki: kenkätehtaan budjetointihaasteet.

Kenkätehtaalla on laaja skaala kenkiä, joita myydään maantieteellisesti eri alueille. Kuukausimyyntien jakaumat poikkeavat toisistaan. Saappaita myydään pohjoisessa eri tahtiin kuin etelässä. Tarve on räjäyttää budjetoitu myynti alueille, joita Suomessa on kymmeniä. Lisäksi on erityyppisiä kauppoja; kenkäkauppoja, tavarataloja, nettimyyntiä jne.

Lisäksi eri tuotteet ovat eri vaiheissa elinkaartaan. Siksi mitään perinteisiä kertoimia budjetin jakamiseksi ei pystytä asettamaan. Täytyy keksiä jotain viisaampaa.

Budjetithan voisi ylätasolla syöttää vaikka SharePoint-listalle, josta ne luetaan jatkojalostusta varten eteenpäin. Eli syötetään budjetit tuotetasolle, myyntikanavittain. Lisäksi uusille tuotteille annetaan oma laskentamallinsa, jos historiamyynti puuttuu.

 

 

 

 

 

 

 

Data kirjoitetaan ja luetaan SSIS:n SharePoint-komponenteilla SQL Server-tietovarastoon.

Seuraavaksi valjastetaan maailmalla hypetetty R budjetointiprosessin tajunnanräjäyttäjäksi.

rlogo

  1. Tietovarastosta luetaan R:lle annettujen parametrien perusteella myyntihistoria alueittain taaksepäin useamman vuoden ajalta. Eli per yksi budjettirivi, meillä on käsissä useamman vuoden myyntihistoria kaikilla maantieteellisillä alueilla. Myyntihistorian muodostuksessa huomioidaan myös annetut parametrit: 'Uusi kärkituote'-myyntihistoria muodostetaan uusien kärkituotteiden tuoteryhmästä. Kävelykengät-historia kaikista kävelykengistä alueittain.
  2. Integroidaan ennustavan analytiikan R osaksi ETL-prosessia. Hyödynnetään sinne itse rakennettuja älykkäitä aikasarjaennustemalleja. R-koodi valitsee parhaan algoritmin automaattisesti kullekin tuotteelle, sekä generoi myyntiennusteen hamaan tulevaisuuteen.

Eli: syöttämällä 1 budjettirivi per tuote, ennustemoottori jyvittää yhden budjettirivin 30:lle myyntialueelle automaattisesti. Näin saadusta myyntiennusteesta lasketaan vielä ennustettu suhteellinen myynnin jakauma. Jakaumalla kerrotaan käyttäjän antama budjetti.

Lopputuloksena on aluekohtainen raportti, jossa samalla saadaan näkyviin sekä toteutunut myynti, että myyntibudjetti. Budjetti jatkuu toteutuneen myynnin jatkeena hämmästyttävällä tarkkuudella.

Graafi

Saapas lyhyt on uusi tuote, jolla ei ole aikaisempaa myyntiä. Lenkkarilla sen sijaan on. Olisi voinut tehdä hieman monimutkaisemmat graafit tähän. Junamatka loppui kerrankin kesken.

Lopputuloksena saatiin generoitua automaattisesti hirmuinen nivaska budjettirivejä. Ja voidaan mainostaa turuilla ja toreilla nykyiseen liioittelevaan tyyliin, että käytettiin budjetoinnissa AI:tä, koneoppimista, machine learningia, ennustavaa analytiikkaa ja R:ää. Big Dataa ei nyt sentään. Mutta hetkonen... tähänhän olisi voinut lyödä sekaan vaikka pitkän aikavälin luotettavat sääennusteet. Tiedettäisiin etukäteen, kuinka moneen kumisaappaaseen täytyy tilata raaka-aineita. Ja somedatasta saataisiin selvitettyä onko kumisaappaista tulossa uusi muoti-ilmiö..

 

 

 

 


17.10.2016 / Jani Liimatta

Vaikka SSAS-kuutioiden käyttöoikeudet mahdollistavat melkein kaikki mahdolliset kombinaatiot, mitä vaativammallakin asiakkalla voi mieleen juolahtaa, on dimension tai attribuutin piilottaminen kokonaisuudessaan käyttöoikeuksilla mahdotonta.

Esimerkiksi kuutiossa on mahdollista:

  • Dimension detaljit voi piilottaa käyttäjäryhmältä
  • Mittarin voi arvot voi piilottaa käyttäjäryhmältä
  • Osan riveistä voi piilottaa oikeuksiin perustuen, käyttäjä voi esimerkiksi nähdä vain oman osastonsa luvut

Mutta, käyttäjiltä ei siis pysty piilottamaan esimerkiksi tietoa siitä, että joku muu saa dataa ulos tarkemmalla tasolla. Harvemminhan tämä on tarpeellista, mutta pari kertaa on tullut tällainenkin tarve eteen. Piilottamiseen on olemassa workaround, joka ei ainakaan itselläni tullut ihan heti mieleen. Sen voi nimittäin toteuttaa kuution Linked Object:eja käyttämällä.

Steb-by-step:

Skenaaario, jossa osa osastoista ei saa nähdä, että myyjätasoinen data on olemassa kuutiossa.

1.Luodaan minuutissa peruskuutio, jossa on 'kaikki' dimensiot käytössä. Käytetään tässä erimerkissä hmm... persoonallisesti mallinnettua, vanhaa ja tuttua Microsoftin AdventureWorks DW:tä pohjana.

peruskuutio
 

 

 

2. Luodaan tyhjä kuutio (Create Empty Cube) projektipäälliköille (ProjectSales). Projektipäälliköt eivät saa nähdä myyjäkohtaisia myyntejä.

uusikuutio

 

 

 

 

3. Avaa tämä uusi kuutio. Valitse oikalla napilla 'New Linked Object'-wizard. Valitaan nykyisestä kuutiosta kaikki measuret. Näiden mukana pöllähtää mukana myös kaikki liittyvät dimensiot.

linkedobject

 

 

 

 

 

 

 

4. Nyt on siis käsissä uusi kuutio, joka sisältää vain linkit alkuperäiseen kuutioon. Poistetaan siitä Employee-dimensio

removeemployee

 

 

 

 

 

5. Seuraavaksi voidaan käyttöoikeuksilla säätää kuutioihin pääsy. Nyt on käsissä siis peruskuutio - sekä projektimyyntikuutio, josta ei edes näe, että myyjätasolle on mahdollista päästä.

excel

 

 

 

 

 

Harvemmin on oikeasti tarvetta piilottaa koko dimensio, mutta jos tulee tarvetta, linkatut objektit ovat ainut järkevä tapa toteutukseen. Toinen tapa on tehdä peruskuutiosta kopioita - mutta silloin haukataan levytilaa, kadotetaan kuutioiden prosessointiaikaa, sekä duplikoidaan logiikkaa. Linkattujen objektien ansioista kun peruskuutio on prosessoitu, on linkkikuutiokin ajan tasalla.

Toisaalta tässä on olemassa sellainen 'hauska ominaisuus', että muutokset eivät automaattisesti periydy eteenpäin. Eli jos muutat peruskuution rakennetta, on linkkikuutio käytännössä tehtävä uusiksi. Tai ainakin muutettu measure group poistettava ja lisättävä takaisin. Se ei onneksi ole kummoinenkaan tehtävä. Paitsi jos muut käyttöoikeusasetukset ovat monimutkaisia... periytymisongelman takia ei näitä linkattujen objektien kuutiossa ei oikein muuta logiikkaa kannata ollakaan.

https://msdn.microsoft.com/en-us/library/ms174899.aspx

Lisensoinnin kannalta linkatut objektit toimivat std-SQL Serverissä, jos kuutiot ovat saman SSAS-kannan sisällä. Toisen projektin/kannan kautta tarvitaan Enterprise-lisenssi.


2.09.2016 / Jani Liimatta

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?

 


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.

11.05.2015 / Jani Liimatta

Budjetti1

Vuosia sitten tuli käytettyä muutamassa projektissa Microsoftin SSAS-kuution Writeback-ominaisuutta. Tämä ominaisuus pääsi itseltänikin melkein jo unohtumaan - kunnes nyt parissa projektissa on tätä tullut pitkästä aikaa käytettyä. Ominaisuus on tainnut vaipua unholaan monelta muultakin tekijältä, asiaa tästä kun ei Google juurikaan löydä.

Tämä ominaisuus kuuluu SQL Server Standard-editioonkin. Lyhyesti - MS-kuutioon voidaan määritellä ns. WriteBack-ominaisuus, joka mahdollistaa esim. budjettilukujen syöttämisen Excel-Pivot-taulukosta suoraan kuutioon. Luvut eivät itse asiassa tallennu kuutioon, vaan SQL Serverin tauluun. Samaa teknistä ominaisuutta hyödyntää itse asiassa parikin kaupallista raskaampaa budjetointisovellusta.

Mitään kovin monimutkaista logiikka tätä perustoiminnallisuutta käyttäen ei kannata lähteä rakentamaan, sekä kehittäjä että asiakaskin ovat pian syvällä suossa säännöstöjen ylläpidon kanssa. Yksinkertaisten ja kevyiden tavoitteiden sekä myyntibudjettien syöttö tällä sen sijaan luonnistuu helposti.

Step-by-step:

1) Lisätään kantaan tyhjä budjettitaulu. Tämä toimii ensisijaisena tietolähteenä kuutiolle. Ideana tässä demossa on syöttää DepartmentGroup/kk-tasolle myyntibudjetit.

Kanta

 

 

 

 

 

2) Lisätään tyhjä budjettitaulu kuutioon. DSV tietysti ensin, dimensiomappaukset (kalenteri ja Department). Measureksi kuutioon lisätään budjetti

BudjettiSSAS

 

 

 

 

 

3) Varsinaisen Writeback-toiminnallisuuden määrittely. 

Tämä tapahtuu hyvin yksinkertaisesti tehdyn budjettirivit-partition takaa. Hiiren oikealla aukeaa 'WriteBack'-settings:

WriteBack_partitio

 

 

 

 

 

 

 

 

 

 

Syöttämisen ja lukemisen luonteen vuoksi lienee luontevinta valita Storage mode:ksi ROLAP. Tällöin Excelissä tehdyt budjettimuutokset näkyvät kaikille käyttäjille.

4) Kuution deployment/prosessointi luo tietokantaan uuden taulun joka on alkujaan tyhjä. Tässä alla näkyy nyt jo muutama Excelin kautta sinne syötetty budjettirivi:

Kanta2

Tähän tauluun päivittyvät Excelissä tehtävät muutokset. Eli jos F_Budjettirivit-taulussa ei ole alun perin rivejä/summia, tärähtää tauluun Excelissä syötetty summa 201504, 5300 EUR. Jos käyttäjä vaihtaisi seuraavaksi 201504 summan 5200:aan, tulisi tauluun uusi rivi, -100 EUR.

Eli tuo logiikka on huomioitava jos budjettia käytetään muuallakin raportoinnissa. On järkevää tehdä pätkä SQL:ää joka summaa budjetin vaikka yöajona alkuperäiseen F_Budjettirivit-tauluun ja tyhjentää WriteTable:n määräajoin. Tarvittaessa muutos-/audit-lokin säilyttäen.

5) Excel-jumppa

Raapaistaan Exceliin lakana, johon myyntibudjetit voidaan syöttää.

Tässä on huomattava pari asiaa. Ennenkuin syöttäminen onnistuu, on Excelistä valittava Olap Tools/What If Analysis/Enable What If Analysis. Soluun kirjoittaminen ei vielä tallenna syötettyjä lukuja Writeback-tauluun, vasta What If Analysis / Publish Changes tekee sen.

Lisäksi jos F_Budjettirivit-taulu on tyhjä - tai et käytä syöttäjän apuna esim. tämän ja viime vuoden myyntejä, ei Pivotkaan oletuksena näytä rivejä. Valitse Pivot-taulun Propertyistä tarvittaessa Display/Show items with no data on rows/columns

Käyttäjälle näkyvä lopputulos alla. Myyntiennuste on tässä esimerkissä laskettu avustamaan budjetin syöttäjää käyttäen Louhian älykkäitä aikasarjaennustealgoritmeja.

Käyttäjä pystyy näppärästi valitsemaan osaston ja vuoden ja alkaa täyttelemään budjettia.

That's it! Helppoa, yksinkertaista ja suoraviivaista.

BudjettiExcel

 


9.04.2015 / Jani Liimatta

Tietovarastojen tekeminen on kokemassa suurta murrosta. Meidän lisäksi pari muutakin kilpailijaa kotimaassa on puuhastelemassa automatisointituotteiden parissa. Louhia on valinnut tuotteekseen yhden maailman markkinajohtajista, tanskalaisen TimeXtenderin. TimeXtender toimii täysin Microsoftin BI-stack:in päällä.

Miten tuo otsikossa mainittu 80% ajansäästö on mahdollista? Olen itse asiassa hyvin vakuuttunut tästä. Ajan säästö koostuu mm.

  • Automaattisesta tietokantaskeemojen ylläpidosta (kehittäjä ei enää lisää sarakkeita, indeksejä, näkymiä jne tietokantaan)
  • SQL:n määrän radikaalista vähenemisestä
  • Pienemmästä virhemäärästä (mm. partitioinnit, hitaasti muuttuvat dimensiot, inkrementaaliset lataukset kun hoituvat tavallaan itsestään, aina samalla tavalla)
  • Pienemmästä aivotyöstä (aikaa kuluu vähemmän ratkaisujen pohdiskelemiseen)
  • Tietovaraston ylläpito voidaan hoitaa asiakkaan pääkäyttäjän toimesta (vaikka nyt uuden sarakkeen tuonti lähdejärjestelmästä kuutioon/Qlik:iin/raporteille asti)

Toki - jos lähdejärjestelmä on kovin monimutkainen, tarvittavat laskennat ja datan muokkaukset hyvin vaativia, datan laatu huttua, ei tuo 80% toteudu. Kaikkea ei kuitenkaan voi automatisoida.

Tietovarastohankkeessa kuitenkaan ei pidä ajatella pelkän yksittäisen projektin kustannusta. On ajateltava myös koko hankkeen elinkaarta. Esimerkiksi - jos haluat valmiista tietovarastosta raportille uuden puuttuvan sarakkeen, tapahtuu perinteisessä ympäristössä seuraavia steppejä:

  1. Ota yhteyttä toimittajaan. Määrittele lähdejärjestelmän sarake ja kuvaa mihin se pitäisi raportilla/tietovarastossa saada
  2. Odota toimittajan resurssin toimenpiteitä. Tässä voi mennä aikaa 1-15 päivää
  3. Toimittaja tekee seuraavaa stagen osalta: muokkaa lähde-SQL:ää, lisää stage-kantaan sarakkeen, muuttaa ETL-latausta, suorittaa latauksen
  4. Toimittaja tekee seuraavat toimenpiteet tietovaraston osalta: muokkaa lähde-SQL:ää, lisää kantaan tai metamalliin sarakkeen, päivittää tietokannan, ajaa ETL:n
  5. Toimittaja päivittää dokumentaatiota, jos päivittää. Tässä vaiheessa ollaan vasta kehitysympäristössä.

Tässä menee yleensä kalenteriaikaa 3...15 päivää. Suuren toimittajan laskutus tästä ilosta voi olla 2 htp sisältäen muutokset testiympäristössä, testaukset, viennit tuotantoon. ISTU JA PALA! YHDEN SARAKKEEN LISÄÄMINEN RAPORTILLE!

TimeXtenderillä homma hoituu seuraavasti:

  1. Avaa työkalu
  2. Klikkaa lähdejärjestelmän saraketta, prosessoi (tietokantaan lisätään sarake automaattisesti, ETL päivitetään automaattisesti)
  3. Klikkaa stagella oleva data mukaan tietovarastotauluun. Prosessoi (tässäkin kaikki tapahtuu automaattisesti taustalla)
  4. Dokumentaatio on automaattisesti ajan tasalla

Asiakas pystyy pienellä opastuksella tekemään tämän itse. Aikaa tähän kuluu latausten lisäksi ehkä 15 minuuttia. Toimittaja ei lähetä laskua. Näin tämän homman pitääkin mennä. Pysy kuulolla, tästä aiheesta kirjoittelemme lähiaikoina lisää.

Tule katsomaan miten homma tehdään 28.4. PASS-tapahtumaan

Jos et ehtinyt PASS-tapahtumaan, varaa oma demoaika 040-777 1142 tai tule paikalle TDWI-tapahtumaan 28.5.

Lue lisää TimeXtenderistä: www.timextender.com


9.02.2015 / Jani Liimatta

QlikView, Tableau, PowerBI, Hadoop. Siinä muutama kuuma tuote jotka ovat viime vuosina tuoneet uusia tuulia BI-markkinoille. Raporttien luonti on muuttunut ketterämmäksi. Samoihin aikoihin kankeimmatkin BI-talot ovat alkaneet siirtymään vähä vähältä agile-menetelmiin, pois vesiputousmallista. Onhan tämä tuonut pientä notkeutta ja nopeutta tietovarastojen kehitykseen. Tämä osin näennäinenkin kehitys ei vaan riitä vielä millään.

Samalla näemme viikoittain asiakkaita jotka ovat ongelmissa erityisesti QlikView-ympäristöjensä kanssa. Nämäkään projektit eivät ole olleet lähimainkaan niin helppoja ja yksinkertaisia kuin on alkuun luultu. Mallit pirstaloituvat, arkkitehtuuriset korttitalot huojuvat. Monessa paikassa on alettu pohtimaan uudestaan koko arkkitehtuuria. Tarvittaisiinko se tietovarasto sittenkin?  Huonot kokemukset tietovarastoprojekteista kuitenkin hirvittävät.

Toisaalla suuret kilpailijat rummuttavat valtavan kalliiden appliance-ratkaisuiden sekä Data Vault-mallinnuksen ylivertaisuutta. Jättämällä kertomatta että sen Data Vaultin päälle on kaiken kukkuraksi rakennettava se perinteinen tähtimallinen ja kankea tietovarasto.

Louhialaisetkaan eivät ole lepäilleet laakereillaan. Erityisesti muualla maailmassa on alettu enenevissä määrin puhumaan tietovarastojen tekemisen automatisoinnista. Voisiko tietovarastoja oikeasti luoda ketterillä menetelmillä?

Miten saada uusi sarake mahdollisimman nopeasti tietovarastoon, kuutioon, QlikView:iin? Onko pakko odottaa kaksi viikkoa?

Voisiko pääkäyttäjä lisätä uutta dataa tietovarastoon ihan omatoimisesti?

Tiedämme ette kotimaassa ole ainoita. Olemme törmänneet pariinkin projektiin jossa kehitellään automatisointivälineitä, tosin niissä ei ilmeisesti olla ilmeisesti kovin pitkällä kun tuotteita ei uskalleta vielä sen suuremmin mainostaa.

Maailmalla on käynnissä useampia työkaluprojekteja jotka käyttävät avointa BIML (Business Intelligence Markup Language)-rajapintaa.

  • BIML:issä itsessään on aika korkea oppimiskäyrä, vaatii skriptikielen opettelua
  • Tässä on kyse lopulta vain uudesta käyttöliittymästä tietovarastojen rakentamiseen.
  • Itse skriptikieli vaatisi ympärilleen vielä metadatan hallinnan, DDL:t, kuutiot jne.

Tämän lisäksi maailmalla on jo markkinoilla useampiakin valmistuotteita jotka pyrkivät ratkaisemaan automatisoinnin . Yhteistä lähes kaikille näille tuotteille on se että pyörivät Microsoftin SSIS:n (SQL Server Integration Services) päällä. Microsoftin välineet ovat meidän kokemustemme mukaan olleet tietovarastojen ylivoimaisesti yleisimmät työkalut jo useita vuosia.

Muutamia tuotteita maailmalla:

http://www.varigence.com/Products/Mist/Capabilities (perustuu BIML:iin)

http://www.cloveretl.com/

http://www.biready.com/

Tietovarastojen automatisoinnin kehitystä hidastavat suuret konsulttiyritykset. Moni kilpailijamme saa suuren osan liikevaihdostaan ETL-työstä. Mitä jos siitä työstä katoaakin yht´äkkiä 80%?

Stay tuned, tietovarastojen teon automatisointi tulee lyömään itsensä läpi. Jäykkää ja massiivista perinteistä tietovarastoprojektia ei ehkä kannata aloittaa vielä. Perinteiset jäykät tietovarastoprojektit ovat katoavaa kansanperinnettä. Maailmalla yksi suurimpia automatisointiin siirtyviä asiakasryhmiä ovat ne, jotka ovat jo kertaalleen kokeneet perinteisen tietovarastokehityksen hitausmomentin.

 


5.02.2014 / Ville Niemijärvi

sql_server_logoKävin myyntikeikalla asiakkaalla, jolla on käytössä Informatica tietovaraston etl-välineenä (etl = extract-transform-load). Mainitsin, että Microsoftin SQL Serverin Integration Services on huomattavasti edullisempi väline ja tekee saman asian. Sain vastaukseksi epäuskoisen silmien pyöräytyksen ja toteamuksen, että kun pitää siirtää dataa paikasta toiseen, Microsoftilla tekeminen tulee maksamaan ja paljon. Päädyimme olemaan asiassa sivistyneesti eri mieltä ja jatkoimme muulla agendalla. Mutta asia jäi vaivaamaan minua.

Olen tehnyt reilun kymmenen vuoden aikana kymmenittäin tietovarastoja. Näitä on tehty SQL Serverillä (SSIS), Informaticalla, DataStagella, Cognos Data Managerilla ja joskus puhtaasti SQL-skripteillä ilman mitään etl-välinettä. En ole ainakaan itse huomannut latausten suorituskyvyssä tai etl-prosessien toteutusvauhdissa tuotteissa juurikaan eroja. Ja jos joskus toteutustyö on ollut hidasta, se on johtunut vain tekijän ammattitaidottomuudesta tai erittäin hankalasta liiketoimintaongelmasta (yleensä dataa ei ole ollut saatavilla). Tai sitten tietovarasto on vain mallinnettu todella huonosti.

Suorituskykyongelmat ovat järjestään väline- ja tietokantariippumattomia.

SQL Server SSIS on itseasiassa yleisin tietovarastojen etl-työväline mihin itse olen törmännyt ja minkä kanssa olen työskennellyt. SQL Server -tietokanta on yleisin tietovarastojen tietokanta. Missään projektissa, vaikka etl-ajoissa käsiteltäisiin päivittäin miljoonia rivejä, SQL Serverin suorituskyky ei ole aiheuttanut edes keskusteluja. Meillä on paraikaa hallinnassa yhdellä asiakkaalla yli teratavun tietovarasto, joka makaa SQL Serverin päällä, eikä suorituskyky ole mikään kysymys.

Kestääkö toteutustyö kauemmin? Olin itse käyttänyt vuosia Data Manageria kun lähdin tekemään ensimmäistä tietovarastoa SSIS:llä. Kollegani opasti tuotteen käyttöä yhden päivän ajan, jonka jälkeen otin homman haltuun. Suoraan sanoen SSIS:n opettelu kävi puolet nopeammin kuin aikanaan Data managerin. Eli ei, SSIS:llä tietovaraston toteuttaminen ei kestä sen kauempaa kuin millään muullakaan.

En siis ymmärrä mistä moinen käsitys asiakkaalle on tullut?

Pelaa varman päälle - sijoita kalleimpaan mitä löytyy

Onko kyse vain varman päälle pelaamisesta? Olen törmännyt yrityksiin, joissa on pitänyt hankkia tietokanta tai etl-työväline eikä ole tunnettu oikein kunnolla tuotteita markkinoilla. Ja siksi on päädytty kaikista kalleimpaan vaihtoehtoon. Ihan vain varmuuden vuoksi. Näin kukaan ei pääse ainakaan syyttämään tuotteen ostajaa jos jokin menee pieleen.

Ja Informatica on kallis verrattuna SQL Serveriin. Informatican hintaa ei tietenkään tiedä kukaan koska se on tuotteena osastoa: emme kerro hintoja koska haluamme tehdä ostamisen mahdollisimman vaikeaksi (ja vihaamme asiakkaitamme). Mutta olen ymmärtänyt, että kustakin tietokantayhteydestä jotka Informaticaan liitetään, pitää maksaa erikseen. Jos haluat lukea SQL Serveristä (esim. Dynamicsin CRM) dataa Informaticalla, joudut latomaan muutaman kymppitonnin tiskiin. Nopeat Netezza-yhteydet maksavat jo yli satasen. Siis normilisenssin lisäksi (korjatkaa Informatica-expertit jos olen väärässä). Ei kovin käyttökelpoista puhuttaessa tietovarastoympäristöistä, joissa oletuksena on useita eri tietolähteitä ja useimmiten eri tietokantoja joihin pitää liittyä.

Kerran olin tekemässä asiakkaalla raportointia ja uuden tietovaraston tietokantana oli Oracle. Kysyin syytä ratkaisuun ja vastaus oli: "Tietoa on niin paljon, että pitää olla järeä kanta." Kysyin paljonkos sitä tietoa sitten tulee olemaan? "No miljoonia rivejä, ainakin kymmenen." En rohjennut enää sanoa, että ilmainen MariaDB olisi ollut varmasti ihan sopiva tietokanta tuohon miniympäristöön.

Vinkki tietokannan/tietovaraston hankkijalle: jos et tiedä, kysy asiantuntijalta. Parin tunnin konsultaatio maksaa jokusen satasen mutta voi säästää sinulle satatuhatta. 

Älä syytä työvälinettä jos et osaa käyttää sitä

Joskus yritys on kokeillut tuotetta omatoimisesti, ilman kunnollista opastusta, koulutusta tai perehdytystä. Työt eivät ole tietenkään sujuneet niin kuin myyntimies-mynttinen näytti ja näin tuote todetaan liian vaikeaksi käyttää tai täysin sudeksi.

Tähän olen törmännyt niin OLAP-kuutioiden kanssa (niin Microsoft kuin Cognos), raportointityövälineissä (Report Studio, Reporting Services) kuin etl-työvälineissä. Asiakkaat ovat haukkuneet esimerkiksi Cognos-kuutiot läpeensä huonoiksi ja kun on alettu selvittämään mistä on kyse, on paljastunut että kukaan ei ole koskaan järjestänyt koulutusta ja niitä ei osata käyttää. Tai pahimmassa tapauksessa kuutioyhteys ei ole päällä ja asiakas on saanut kuutiota avatessa virheviestin eteensä. Ja jättänyt tuotteen käytön siihen, koskaan näkemättäkään sitä tosi käytössä. Ja kerran asiakkaalla vaihdettiin raportointityövälinettä koska konsultti ei osannut käyttää sitä.

Syy ei ole toki asiakkaan: konsultit ja myyntimiehet jättävät asiakkaan liian helposti oman onnensa nojaan uuden tuotteen kanssa eikä kunnollisesta vierihoidosta ja käyttöönotosta huolehdita. Sitten tulee QlikView:n myyntimies ja pyyhkii kaikilla lattiaa ja vie potin.


2.04.2013 / Ville Niemijärvi

Gartner Magic Quandrant for Business Intelligence and Analytics Platforms 2013

Konsulttiyhtiö Gartner julkaisee vuosittain maailmankuulun arvionsa business intelligence ja analytiikkaohjelmistoista. Koko raportin löydät Gartnerin sivuilta. Käymme seuraavissa parissa kirjoituksessa tiivistetysti läpi tuon raportin tulokset.

Gartnerin nelikenttä 2013

Gartnerin raportti tiivistyy nelikenttään, jossa BI-softat on luokiteltu kahden mittarin mukaan: a.) ability to execute & b.) completeness of vision. Ensimmäinen tarkoittaa ohjelmiston kykyä suoriutua tehtävistään, käytön helppoutta, asiakastyytyväisyyttä, suorituskykyä jne. Jälkimmäinen viittaa siihen miten kokonaisvaltaisesta paketista on kyse. Jos tuoteperheestä löytyy työväline vain raportointiin, ei tule korkeaa arvosanaa. Mutta jos paletista löytyy mahdollisuuksia mobiilikäyttöön, työväline budjetointiin ja ennakoivaan analytiikkaan, nousee arvosana.

Näiden kahden mittarin perusteella ohjelmistot on luokiteltu 4 ryhmään: a.) niche-toimijoihin (vasen alakulma), b.) haastajiin (vasen yläkulma), c.) visionääreihin (oikea alakulma) ja d.) johtajiin (oikea yläkulma). Vuoden 2013 raportin nelikenttä näyttää tältä:

garter-mq_2013-graph

Gartnerin raportit visualisoituna vuosilta 2007-2013

Otimme Gartnerin raportit vuosilta 2007-2013, purimme nelikentät koordinaateiksi ja sijoitimme ne tekemäämme visualisointiin kauniiksi motion chart:ksi. Animoidun visualisoinnin löydät Louhian sivuilta. Visualisoinnin avulla näet miten softat ovat kehittyneet vuosien varrella.

Tableau siirtyy johtajiin

Hurjassa vauhdissa oleva Tableau siirtyy uusimmassa Gartnerin raportissa leaders-kategoriaan. Olemme myös Louhialla ottaneet käyttöön Tableau Public -ilmaisohjelmistot ja kokemukset ovat erinomaiset. Käy katsomassa vaikka kuntadatan visualisointimme. Kuten alla olevasta kuvasta näkyy, Tableau oli vielä pari vuotta sitten niche-kategoriassa mutta sen vauhti leaders-porukkaan on ollut kautta aikain nopein. Vain Qlikview on pystynyt yhtä huimaan nousuun mutta siltä vei siihen useampi vuosi.

Gartner_Tableau_motion_chart

Vahvuudet (Gartnerin raportin mukaan)

  • Intuitiivinen, visuaalinen, interaktiivinen kokemus, jota asiakkaat rakastavat ja kilpailijat matkivat. Tuotteen käyttö on helppoa ja hauskaa.
  • Useiden tietolähteiden yhdistäminen (ns. data mashup) ilman ohjelmointiosaamista yhdistettynä muistinvaraiseen tietokantaan (in-memory) --> monipuolisten eri tietoa sisältävien interaktiivisten mittaristojen toteuttaminen on helppoa ja suorituskyky on hyvä
  • Loppukäyttäjät arvioivat Tableaun kärkeen seuraavissa kategorioissa: implementointiaika, raportoinnin nopeus ja liiketoimintahyödyt
  • Tableau on kaikista mukana olleista BI-työvälineistä ykkönen käytön helppoudessa sekä kehittäjien että loppukäyttäjien mielestä
  • Tuotteen laadun osalta Tableau on myös kärkiporukoissa

Heikkoudet/huomioitavaa

  • Tableau on edelleen epätodennäköinen valinta useille yrityksille koko konserninlaajuiseksi BI-työvälineeksi (verrattuna tuotteisiin kuten SAP, Microsoft, IBM Cognos)
  • Isot ohjelmistotalot vastaavat haasteeseen ja integroivat samoja ominaisuuksia tuotteisiinsa millä Tableau on erottautunut. Tämä voi asettaa haasteen Tableaun kasvulle.
  • Vaikka Tableauta käytetään monenlaisiin käyttötapauksiin, sen toimintakenttä on varsin kapea: interaktiivinen visualisointi ja dashboardit. Siitä puuttuu laajemmat BI-alustan toiminnallisuudet.
  • Tableau saa keskiarvoa heikommat pisteet seuraavissa kategorioissa: metadatan hallinta, BI kehitystyökalut ja - infrastruktuuri. Toisin sanoen suuren yrityksen ainoaksi BI-työvälineeksi Tableaulla on vielä matkaa
  • Partneriohjelma on heikompi verrattuna vastaaviin kilpailijoihin (kuten Qlikview)
  • Keskittynyt lähinnä USA:n markkinoille, kansainvälinen peitto on vielä heikko. Euroopassa tukipalvelut ovat Englannissa

Seuraavassa numerossa: IBM Cognos, Qlikview ja Microsoft.