A múltkor egy átadás előtti oktatáson mutattam az üzleti felhasználóknak, hogy hogyan lehet létrehozni statikus és dinamikus nevesített halmazokat a Pivot tábla segítségével. Mondtam pár valós üzleti példát és egyből beindult a fantáziájuk: Nekik is szükségük van ilyenre, de…

És itt elmesélték, hogy egy relatíve gyakran változó ügyfél listát szeretnének összerakni és ebből csinálni egy nevesített halmazt. Odaülni a szerver elé nem akarnak, az informatikát nem akarják megkérni e lista karbantartására. Valami olyan megoldást képzelnének el, hogy ők Excelben karbantartják e vevők listáját, és az a lista valahogy kússzon fel a szerverre és legyen belőle nevesített halmaz.

A válasz persze az volt ezt sajnos nem tudja megvalósítani az eszköz, …  Most azonban találtam erre egy jó megoldást:

Tartsuk nyílván a nevesített halmazok elemeit– esetünkben az ügyfeleket - egy központi törzsadatkezelőben és az Analysis Services e lista alapján építse fel a nevesített halmazokat a szerveren. Itt le is írják, hogy hogyan lehet ezt megvalósítani: Managing SSAS Named Sets with Master Data Services Collections

Az SQL Server 2012-től pedig már Excelből is elérhetjük majd a törzsadatkezelő rendszert, így megnyílik majd a lehetőség az üzleti felhasználók előtt, hogy Excelből, egy központi törzsadat kezelő rendszeren keresztül tudják karbantartani az Analysis Services nevesített halmazait

Mutatom hogy lehet összetett, több dimenziót érintő szűrést megvalósítani az Excel KOCKA.HALM() függvényével:

=KOCKA.HALM("PowerPivot Data"; "CrossJoin({[Dátum].[hónap].[január]},{[Termék].[Termékcsop].[A]})")

Vagy ahogy most tanultam az Excel kocka függvény konvertálójától:

=KOCKA.TAG("PowerPivot Data";{"[Dátum].[hónap].[január]"\"[Termék].[Termékcsop].[A]"})

Gyakran lesz rá szükség, ha amorf riportok készítésekor be akarjuk nyomni a szűrőfeltételeket a táblázat fejlécébe.

Aligha. Csak a fordítók magyarították az ORDER kulcsszót „Rendelés”-re, a MEMBERS-t tagokra és így tovább:

A példák úgy helyesek ahogy az angol nyelvű oldalon láthatóak:

A hibát jeleztem.

Forrás: KOCKA.HAML függvény

A múltkor elmélkedtem a BI projekt blogon, hogy OLAP adatbázis használata esetén vajon melyik a jobb adatmodell: a csillagsémás, vagy a normalizált hópehely, és akkor arra jutottam, hogy MS OLAP használata esetén jobb a csillagsémás. De mi a helyzet a PowerPivot oszlopalapú adatbázis-kezelőjének használata esetén?

Nos. Ahogy az a PowerPivot Data Modelling for Performance című cikkből kiderül, a Microsoft oszlopalapú adatbázis-kezelőjének használata esetén is jobb teljesítményt ad a csillagsémás adatmodell a normalizált hópehely adatmodellel szemben. Helyszükségletben nincs nagy különbség a csillagsémás és a normalizált adatmodell között (köszönhetően a tömörített tárolásnak) ugyanakkor a csillagsémás adatmodell rövidebb válaszidőkkel szolgálja ki a lekérdezéseket.

A Microsoft nemrégen bejelentette, hogy nyugdíjazza az OLE DB-t és helyette az ODBC-n keresztüli adatkommunikációt favorizálja. A hír két ok miatt is érdekes. Egyfelől az évek során megtanultuk, hogy az ODBC lassú és az OLE DB gyors, másfelől az Analysis Services nem támogatja közvetlenül az ODBC-n keresztüli adatelérést.

Ezzel kapcsolatban a múlt héten az Analysis Services Team írt egy bejegyzést „Impact of the SQL Server OLE DB Deprecation on Analysis Services” címen, amely tisztázza a helyzetet. Ezek szerint

1)      Az Analysis Services feltöltéséhez továbbra is az OLE DB-t kell használnunk mindaddig, amíg meg nem jelenik a natív ODBC driver az SQL Serverhez

2)      Az Analysis Services lekérdezéséhez továbbra is az MSOLAP OLE DB providert kell használni, mert az nem kerül nyugdíjazásra.

Konklúzió: aggodalomra semmi ok. Csak az SQL Server OLE DB provider fog nyugdíjba menni, és az sem most, hanem majd 7 év múlva. Valószínűleg nemsokára megjelenik a natív ODBC támogatás is és akkor majd azt kell használni. De addig minden marad a régiben és továbbra is az OLE DB lesz a leghatékonyabb eszköze az SQL serverben tárolt adatok elérésének.

Vidas Matelis összeállított egy egész jó listát azokról a dokumentumokról, amelyek szükségesek lehetnek egy SSAS fejlesztőnek. Íme:

• SQL Server 2008 White Paper: Analysis Services Performance Guide
• Analysis Services Processing Best Practices
• Analysis Services 2005 Processing Architecture
• Analysis Services Distinct Count Optimization
• Analysis Services Distinct Count Optimization Using Solid State Devices
• Analysis Services Many-to-Many Dimensions: Query Performance Optimization Techniques
• SQL Server 2005 Analysis Services (SSAS) Server Properties
• Running Microsoft SQL Server 2008 Analysis Services on Windows Server 2008 vs. Windows Server 2003 and Memory Preallocation: Lessons Learned
• SQL Server Best Practices Article: Identifying and Resolving MDX Query Performance Bottlenecks in SQL Server 2005 Analysis Services
• Analysis Services ROLAP for SQL Server Data Warehouses
• Scale-Out Querying for Analysis Services with Read-Only Databases
• Microsoft SQL Server 2008 Analysis Services Consolidation Best Practices
• Identifying and Resolving MDX Query Performance Bottlenecks in SQL Server 2005 Analysis Services
• Analysis Services Query Performance Top 10 Best Practices
• OLAP Design Best Practices for Analysis Services 2005

A dokumentumok nagyjából fontossági sorrendben vannak. Az első három kötelező olvasmány, de az utána következők is nagyon fontos részét képezik az OLAP-os irodalmaknak.

Így lehet lekérdezni:

<Discover xmlns="urn:schemas-microsoft-com:xml-analysis">

  <RequestType>DISCOVER_XML_METADATA</RequestType>

  <Restrictions>

    <RestrictionList>

      <ObjectExpansion>ObjectProperties</ObjectExpansion>

    </RestrictionList>

  </Restrictions>

  <Properties>

    <PropertyList>

    </PropertyList>

  </Properties>

</Discover>

A választ pedig megtalálhatjuk az edition tag-ek között:

Olvasom az Analysis Services Distinct Count Optimization Using Solid State Devices című cikket és közben azon töröm a fejem, hogy miért nem használunk SSD diszkeket az Analyis Services adatkockák tárolásához. Persze nem biztos, hogy minden esetben jelentősen gyorsabb lenne az SSD mint egy gyors diszken tárolt Analysis Services, de itt inkább a gondolkodásmód a fontos: Ahogy az SSD-re gondolunk ma, egy adattárházas környezetben.

Az SSD még drága – vágja rá szinte mindenki. Én meg azt mondom számoljunk. Közelítsük meg két oldalról a problémát: Egyszer a lekérdezések gyorsítása szempontjából, másodszor a tárolókapacitás oldaláról. Kezdjük ez utóbbival

Kapacitás

Az SSD tényleg drágább, mint a sima diszk, ha azt nézzük, hogy mennyibe kerül 1 giga kapacitás egyik vagy másik technológián. De most Analysis Services-ben gondolkodunk, ami elég jól tömöríti az adatokat. Az fenti cikkben azt mondják, hogy egy  éles OLAP megoldáson tesztelték az SSD-t, ahol az adattárház 10 tera volt és a ráépülő MOLAP kocka 120 giga. Azaz az Analysis Services kb 1%-a volt a relációs adattárháznak. Én ilyen arányt megmondom őszintén sose tapasztaltam. Saját tapasztalatom szerint az Analysis Services kockák mérete a relációs adattárház méretének kb. 10-20%-a szokott lenni. Vegyünk egy 2-300 gigás adatpiacot. Ebben az esetben az adatpiacra épülő OLAP adatbázist le tudnánk tárolni egy 60 Gigás SSD-n. Mennyibe kerül egy 60 Gigás SSD? Nem tudom. De nem többszázezerebe, az tuti…

Optimalizáció

Megmondom őszintén ez az SSD-s történet akkor fordult meg először a fejemben, amikor egy csomó distinct count mutatót tartalmazó kockát kellett volna optimalizálnom. Persze mint esetünkben kiderült egy if áthelyezése az MDX Script-ben megoldotta a problémát, de itt gondolkodtam el azon először, hogy a megrendelő szempontjából lehet hogy érdemesebb lenne áttenni a kockát egy SSD diszkre, mint 1-2 napig optimalizálni az MDX scriptet…

Összefoglalva: Lehet, hogy drága még az SSD egy adattárház tárolására, de egy Analysis Services alapú BI megoldás tárolásához már érdemes lenne komolyabban elgondolkodni az SDD használatán...

Ha több dátum dimenziónk is van (szerepjátszó dimenziók) és van legalább egy semmi additive measure-ünk (olyanok, amelyekre eltérő aggregációt kell készíteni időben és a többi dimenzióban) akkor az Analysis Services csak az első idődimenzió mentén tud semi additeive-en aggregálni. A második szerepjátszó dimenziót már SUM felösszegzési mód szerint aggregálja. Melyik az első idő dimenzió? Itt le van írva.

A SCOPE MDX utasítás NEM írja felül a kocka tartalmát!

Több mint 12 éve nem írtam egy sor ORACLE Express kódot, de az akkor tanultak olyan mélyen rögzültek, hogy alig tudok elvonatkoztatni tőlük. (Az Express volt az ORACLE OLAP adatbáziskezelője) Express-ben a LIMIT parancs (ami az MDX SCOPE utasítás ORACLE-ös megfelelője) után kiadott értékadás (pl.: Mennyiség = 4) hatására felülírtuk a kocka tartalmát. Ezzel szemben az Analysis Services csak képleteket generál, és kvázi a képlet eredményét jeleníti meg kliens oldalon. Ezzel nincs is probléma, csakhogy ebből következően nincs jelentősége az értékadás sorrendjének. Tehát:

SCOPE A;

THIS = B;

END SCOPE;

SCOPE B;

THIS = 0;

END SCOPE;

Utasítás sorozat eredményeképpen A-ra is és B-re is nullát fogunk visszakapni. Ha ezt meg akarjuk változtatni akkor a FREEZE () utasítással rögzíteni kell az először kiszámított értéket. Mutatom:

SCOPE A;

THIS = B;

FREEZE(THIS);

END SCOPE;

SCOPE B;

THIS = 0;

END SCOPE;

és ebben az esetben A B eredeti értékével lesz egyenlő, B pedig nulla lesz