Onko raportointikuutiosi pyyhkäisty vasemmalla kädellä?

Tunnistatko raportointiympäristössäsi seuraavia ongelmia?

  • Kuutiot eivät ole vastaa todellisiin raportointitarpeisiin varsinkaan Excelistä käytettynä. Raportointia käyttävät vain harvat käyttäjät.
  • Kuutioista ja tietovarastosta huolimatta dataa joudutaan kopioimaan Exceliin, jotta liiketoiminnan kannalta olelliset mittarit on saadaan irti.
  • Kuutioissa on suorituskykyongelmia

Muutama vinkki josta voi tarkistaa, voisiko omasta Microsoft-raportointikuutioostasi saada irti pienellä kehityspanostuksella paljon lisää. Esimerkeissä olevan Microsoftin AdventureWorks-demokuution voit ladata tarvittaessa  Codeplex:istä, http://msftdbprodsamples.codeplex.com/releases/view/55330. AdventureWorks-demokuutiokaan ei ole käytettävyydeltään paras mahdollinen, erityisesti sen aika/kalenterikäsittely kaipaisi parannuksia.

1. Avaa tuotantokuutio SQL Server Data Tools:illa (Business Intelligence Development Studio aiemmin).  File/Open/Analysis Services Database

2. Measures/Cubes. Ilmeisesti Wizard-tyyppinen lähestymistapa tuottaa joka osa-alueesta oman kuutionsa. Miten silloin vertaat esim. tilauskannan ja laskutuksen kehityksen suhdetta? Excelissä joudut vaihtamaan kuutiota jos haluat verrata asioita keskenään. Jos suorituskykyä haetaan, se kannattaa tehdä partitioilla. Siitä alla lisää. Mutta jos faktoja yhdistää edes yksi dimensio (vaikka tuote), kannattaa ne ehdottomasti pitää saman kuution sisällä. Vain silloin eri tapahtutumalajien kehitystä voi verrata keskenään. Eihän budjettiakaan tarkastella ilman myyntiä.

Tässähän voi olla taustalla sellainenkin ongelma että tieto itsessään on siiloutunut. Onko joka asialla oma tietovarastonsa? Jos on niin miksi? Onko siitä enemmän haittaa kuin hyötyä?

Yhdessä AdventureWorks-kuutiossa on monta Measure Grouppia

3. Calculations. Muutama rivi yksinkertaista MDX:ää helpottaa huomattavasti raportointia.  Jotta kuutio olisi helppo käyttää raportoinnissa, täällä kannattaisi vähintäänkin olla valmiina laskennallisina jäseninä Edellisen vuoden myynti, Muutos verrattuna edelliseen vuoteen jne. Lisäksi on erittäin järkevää lisätä valmiiksi dynaamisiksi seteiksi kalenterista edelliset 6kk sekä edelliset 12kk. Tai kuten alla, vaikka negatiivisen katteen tuotteet, jos tarpeellista. SSAS-kuution aikakäsittely on hieman puutteellinen verrattuna esim. Cognoksen vastaavaan. Siksi moni asia on ratkaistava laskennallisina jäseninä – jotta kuution käyttö on mahdollisimman jouhevaa.

Kuutiossa on paljon valmiiksi laskettuja mittareita sekä settejä

4. Partitiot. Partitioilla tuodaan suorituskykyä raportointiin hyvin helposti. Kuution käyttäminen on nopeampaa kun data on pilkottu pienempiin palasiin. Esimerkiksi – jos käytetään SQL Server Std-versiota, voidaan tehdä dynaamiset partitiot 3 kpl (std-lisenssi ei salli enempää partitoita per Measure Group) historiadatalle, edelliselle vuodella ja kuluvalle vuodelle. Koska tätä ja edellistä vuotta raportoidaan eniten, kannattaa nillä olla omat partitionsa. Tällöin myös kuution prosessointi on hurjan paljon nopeampaa- kun voidaan prosessoida vain kuluvan vuoden partitio. Ilman partitointia jodutaan prosessoimaan aina koko kuutio – eli käymään koko tapahtumahistoria läpi.

Tässä kuutiossa data on partitioitu

5. Aggregoinnit. Aggregointien lisääminen parantaa kuution suorituskykyä käytännössä ilmaiseksi. Pelkän wizardin käytölläkin saa jo hyviä tuloksia, tämä vie aikaa pari minuuttia. Kumma kyllä, tämäkin on monessa kuutiossa jätetty tekemättä.

Measure Gruopien taakse on määritelty aggregointeja

4 comments on “Onko raportointikuutiosi pyyhkäisty vasemmalla kädellä?

  1. Asko Kauppinen on

    Näiden kuutioiden tekeminen on sinänsä suoraviivaista, mutta jonkin aikaa menee MDX:n opetteluun ja laskenallisten jäsenten tuunaamiseen. Joskus olemme käyttäneet myös välineitä, joilla loppukäyttäjät voivat julkaista kuutioon laskennallisia jäseniä. Mm. ProClarity oli aikoinaan tällainen tuote, mutta Mikkisofta tappoi sen sen takia että heidän mielestään Excelin myyntiä pitää edistää…

    Muistan kerran että eräälle Aureoliksen asiakkaalle oli joku toinen Mikkis – konsulttitalo sanonut että näistä partitioista ja aggregoinneista ei muka olisi käytännössä mitään hyötyä… 🙂 Konsulttien osaaminen jättää joskus toivomisen varaa…

    Osaatko muuten sanoa mitä muuta pitää tehdä partitioiden ja niiden storage mode asetusten lisäksi että loppukäyttäjien clienttien MDX:llä tekemät kyselyt toimisivat optimaalisesti?

    Vastaa
  2. Jani Liimatta on

    ProClarity oli lupaava tuote, MS osti sen pois markkinoilta ja hävitti vähin äänin, harmin paikka.

    Mitä enemmän dataa on kuutiossa, sitä enemmän on hyötyä partitioista ja aggregoinneista. Jos dataa on hyvin vähän, on hyöty suorituskyvyssä ja prosessoinnissa pieni. Eli siinä mielessä tuossakin väitteessä voi piillä osa totuutta.

    Excelin luomaan MDX:ään on hankala vaikuttaa. Jonkin verran suunnittelulla pystyy vaikuttamaan siihen mitä käyttäjät pystyvät tekemään. Mutta jos Excelillä pääsee kuutiota pyörittelemään, on aina mahdollisuus että käyttäjä pääsee tekemään suorituskyvyn kannalta järjettömiä juttuja. Ja usein Excelin MDX on kaikkea muuta kuin optimaalista.

    Laskunumerotkin kuutioon saa – mutta onko ne järkevämpää pitää kuitenkin SQL:ssä ja luoda vaikka porautuva raportti? Tai esimerkiksi käyttäjille voi luoda sopivia Template-Exceleitä, joita käyttämällä voi todennäköisemmin edetä oikeampaan suuntaan. Sekä tietysti luomalla riittävästi käyttökelpoisia settejä ja valmiita laskennallisia jäseniä.

    Vastaa
  3. Asko Kauppinen on

    Jani,

    ehkä pienen datamäärän tapauksessa Reporting Services ja suora parametrisoitu SQL-kysely tietokantaan olisi järkevin raportointimalli? Siis jos tykkää käyttää MS välineitä…

    Tarkoitin kyllä että ”Slice Property” – asetus pitää tehdä yhdenmukaiseksi partitioinnissa käytettävän kyselyn kanssa että eri partitioiden rivit osuvat MDX:n kannalta optimaalisesti….

    Vastaa
  4. Jani Liimatta on

    Aika hankalaa on SSRS:llä ja SQL:llä korvata SSAS- tai PowerPivot-mallia pienelläkään tietomallilla. Tarpeet ratkaisevat sen miten ne on järkevää täyttää. Dynaamisella SQL:llä pystyy tekemään jotain – mutta menee nopeasti paljon hankalammaksi, kankeammaksi ja työläämmäksi kuin kuution tekeminen.

    Mitä enemmän on todellisia kuution tehokäyttäjiä, sitä vähemmän kyselyt osuvat partitiointiin. Toki jos on paljon vakioraportteja ja vähän dimensiota, on partitiointi suorituskyvyn optimoinnin kannalta helpompaa.

    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.