Projektowanie agregacji w Microsoft SQL Server Analysis Services 2005, cz. II
Zawartość strony
 | Aggregation Manager |
| Praca z Aggregation Manager |
| Dobre praktyki projektowania i budowania agregacji |
| Przeczytaj pozostałe części tego artykułu |
Aggregation Manager
Jak już wiemy z poprzedniej części artykułu, tworząc rozwiązanie hurtowni danych, mamy do dyspozycji kilka możliwości utworzenia agregacji. Możemy pozwolić by to SQL Server Analysis Services 2005 (SSAS) zaproponował i ustalił pewien zestaw agregacji. Co w przypadku, kiedy nie chcemy korzystać z automatu, kiedy sami mamy ochotę zaprojektować i zbudować agregację?
Tu z pomocą przychodzi nam narzędzie o nazwie Aggregation Manager. Ta mała aplikacja umożliwia ręczne ustawianie wcześniej zaprojektowanych agregacji. Główna funkcjonalność pozwala na podgląd, edycję i usuwanie istniejących agregacji oraz dodawanie nowych.
Aggregation Manager nie jest narzędziem standardowo dołączanym do środowiska SQL Server 2005, jednak bez problemów można go pobrać ze stron Microsoftu. Po pobraniu kodu, należy skompilować go za pomocą kompilatora Microsoft Visual C#.NET 2.0. Można także pokusić się o pobranie już działającej aplikacji w formie pliku wykonywalnego. Aplikacja taka znajduje się w pakiecie o nazwie BIDS Helper, który można pobrać z lokalizacji www.codeplex.com\bidshelper. Najlepiej wykorzystać oba sposoby, ponieważ każdy z nich niesie ze sobą pewne zalety. W przypadku pierwszego mamy możliwość uruchomienia niezależnej aplikacji i podłączenia się do dowolnego serwera Analysis Services. W drugim przypadku Aggregation Manager integruje się z Visual Studio 2005, przez co możliwe jest zarządzenie jedynie agregacjami wybranego projektu. Czasem właśnie o to nam chodzi by było łatwo i szybko.
Jeśli chodzi o techniczną stronę Aggregation Managera to krótko można wspomnieć, że komunikuje się on z SSAS w oparciu o Analysis Management Objects.
Praca z Aggregation Manager
Jeśli wybraliśmy pierwszy sposób, po kompilacji kodu otrzymamy wykonywalny plik, który należy uruchomić. Następnie musimy dostarczyć wszystkie potrzebne informacje dotyczące serwera i bazy, do których chcemy się podłączyć.
W przypadku, gdy zainstalowaliśmy pakiet BIDS Helper, aplikację Aggregation Manager uruchomić można wybierając zakładkę „Partitions” dla odpowiedniej kostki, a następnie klikając ikonę „Edit Aggregation…” (Rysunek 3.1a).
Rys. 3.1a. Uruchomienie Aggregation Managera.
Alternatywnym sposobem jest kliknięcie prawym klawiszem myszy na wybranej kostce i wybranie z menu kontekstowego pozycji „Edit Aggregation…” (Rysunek 3.1b).
Rys. 3.1b Uruchomienie Aggregation Managera.
Główne okno Aggregation Managera (Rysunek 3.2) przedstawia zestaw informacji dotyczących grup miar, partycji, agregacji oraz zależności między nimi w postaci drzewa. Główny węzeł prezentuje wybraną kostkę (Adventure Works DW). Następnie kolejno wylistowane zostały wszystkie grupy miar (Fact Finance, Dim Time). Każda z nich może posiadać wiele zestawów agregacji. W tym przypadku grupa miar „Fact Finance” posiada tylko jeden zestaw o nazwie „AggregationDesign”. Każdy zestaw agregacji posiada listę partycji, których dotyczy. Jeśli dana partycja nie posiada żadnych przypisanych zestawów agregacji, automatycznie jest przypisywana do sekcji „No Aggregation Design".
Rys. 3.2. Główne okno Aggregation Managera.
Po wybraniu danego zestawu agregacji w prawym panelu pojawi się liczba agregacji zawartych we wskazanym zestawie. Klikając prawym klawiszem myszy na dowolnym zestawie agregacji, wywołujemy menu kontekstowe z kolejnymi funkcjonalnościami (Rysunek 3.3).
Rys. 3.3 Menu kontekstowe Aggregation Managera.
| • | Edit – wybranie tej opcji powoduje pojawienie się nowego okna (Rysunek 3.4), gdzie możemy zarządzać agregacjami w obrębie wybranego zestawu agregacji. |
| • | Delete – wybranie tej opcji powoduje usunięcie całego zestawu agregacji, wszystkie przypisane do niego partycje zostaną przeniesione do zakładki „No Aggregation Design". |
| • | Add Aggregations from QueryLog – wybranie tej opcji umożliwia dodanie agregacji na podstawie informacji zgromadzonych w QueryLog; do dyspozycji mamy okno z kilkoma parametrami, kluczowym jest tu zapytanie, które pobiera dane z tabeli logów i na ich podstawie tworzy agregacje. |
Rys. 3.4 Dodawanie agregacji na podstawie QueryLog.
| • | Change Partitions – wybranie tej opcji powoduje pojawienie się listy wszystkich partycji (Rysunek 3.5), jeśli jakaś partycja znajduje się w zakładce „No Aggregation Design" to właśnie w tym miejscu możemy przypisać ją do wybranego zestawu agregacji. |
Rys. 3.5 Wybór partycji dla danego zestawu agregacji.
Skupmy się jednak na kluczowej funkcjonalności aplikacji, jaką jest możliwość zarządzania agregacjami. Po wybraniu opcji „Edit” pokaże nam się panel zarządzania agregacjami (Rysunek 3.6). Tabela po lewej stronie zawiera zestaw istniejących już agregacji. Prawy panel prezentuje drzewo wszystkich wymiarów dotyczących danej grupy miar wraz z atrybutami i ich relacjami. W celu modyfikacji wybranej agregacji musimy najpierw ją zaznaczyć. Następnie mamy dwie możliwości dokonania zmian. Pierwsza - bezpośrednio edytujemy definicje agregacji na ciągu zer i jedynek; druga - zaznaczamy wybrane atrybuty na drzewie. Oba te mechanizmy są ze sobą ściśle powiązane i na bieżąco synchronizowane tzn. zmiana ciągu zer i jedynek pociąga za sobą edycję drzewa i odwrotnie.
Rys. 3.6. Panel zarządzania agregacjami.
Na chwilę uwagi zasługują opcje “Eliminate Redundancy” oraz „Eliminate Duplicates”. Użycie pierwszej z nich powoduje skanowanie drzewa atrybutów w celu wyszukania i wyeliminowania redundantnych atrybutów wchodzących w skład danej agregacji. Inaczej mówiąc, jeśli któryś z wymiarów będzie miał zaznaczony więcej niż jeden atrybut i oba te atrybuty będą ze sobą w relacji, jeden z nich zostanie usunięty. Natomiast opcja „Eliminate Duplicates” służy do wyeliminowania takich samych agregacji. Podsumowując, jeśli uważnie projektujemy agregacje, użycie wspomnianych opcji nie jest konieczne.
Kolejną ciekawostką jest wskaźnik “Estimated Size”, umiejscowiony w prawym górnym rogu panelu zarządzania agregacjami; obrazuje poziom wielkości agregacji w stosunku do wielkości tabeli faktów dla wybranej agregacji. Zgodnie z przyjętymi praktykami powinien być on nie większy niż 33%. I tu uwaga, wskaźnik ten nie zawsze jest odwzorowaniem rzeczywistości.
Bardziej szczegółowa prezentacja fizycznej zajętości miejsca przez agregacje jest dostępna z menu kontekstowego wybranej partycji (Rysunek 3.7).
Rys. 3.7. Opcja „Physical Aggregation Size”.
Dla wybranej partycji otrzymujemy dość szczegółowy raport na temat zajętości miejsca oraz ilości rekordów dla kolejnych agregacji (Rysunek 3.8).
Rys. 3.8. Fizyczne wielkości agregacji.
Na koniec istotna uwaga, o której należy pamiętać by nasza praca nie poszła na marne. Opuszczenie aplikacji Aggregation Manager nie powoduje zapisania agregacji na serwerze. Aby zmiany zostały zachowane należy zapisać cały projekt.
Dobre praktyki projektowania i budowania agregacji
Projektowanie i ręczne ustawianie agregacji jest bardzo trudnym i wymagającym uwagi zajęciem. Jeśli jednak wybierzemy tą drogę, powinniśmy pamiętać o kilku zasadach, którymi należy się kierować. Oczywiście nie wszystkie podane tu wskazówki będą miały zastosowanie w każdym przypadku, ale jeśli już zdecydujemy się odstąpić od reguł musimy zadać sobie pytanie, dlaczego tak postąpiliśmy. Inaczej mówiąc nasz wybór musi być w pełni świadomy i uzasadniony.
Poniższa lista wskazówek zawiera esencję dobrych praktyk projektowania agregacji.
| • | Nie buduj zbyt wielu agregacji. Zbyt duża liczba agregacji spowoduje wzrost wielkości bazy oraz w znaczny sposób wydłuży czas procesowania. Dobrą praktyką jest nie przekraczanie liczby 500 agregacji dla jednej partycji. Liczba agregacji powinna być raczej wyrażona w dziesiątkach, niż w setkach. |
| • | Staraj się tworzyć agregacje, których rozmiar nie przekracza 1/3 rozmiaru danych z tabeli faktów. Agregacje o większych rozmiarach nie wpływają dobrze na wydajność. |
| • | Rozważ, czy dana partycja wymaga agregacji. Zazwyczaj każda partycja zawierająca powyżej 500 000 rekordów powinna posiadać agregacje. W przypadku kiedy partycja zawiera mniej niż 500 000 rekordów obliczenia są na tyle szybkie, że istnienie agregacji staje się niezauważalne. |
| • | Utwórz agregacje dla wszystkich dostępnych grup miar. |
| • | Unikaj przechowywania agregacji, które nie są wykorzystywane przez żadne partycje. Przetrzymywanie takich agregacji spowalnia proces przetwarzania, nie przynosząc przy tym żadnych korzyści. |
| • | Staraj się wykorzystać już istniejące zestawy agregacji dla podobnych partycji. Jeśli nowa partycja swoim rozmiarem i przeznaczeniem odpowiada już istniejącym, dobrą praktyką jest wykorzystanie już istniejącego zestawu agregacji. Spowoduje to zmniejszenie liczby zestawów agregacji, przez co model stanie się bardziej przejrzysty i „szybszy”. |
| • | Twórz nowe zestawy agregacji dla nowych różnorodnych partycji. Jeśli nowa partycja swoim rozmiarem i przeznaczeniem znacznie odbiega od już istniejących, dobrą praktyką jest utworzenie nowego zestawu agregacji. Nowy zestaw agregacji będzie z pewnością bardziej przystosowany do potrzeb wynikających z użycia nowej partycji, przez co zyskamy na wydajności. |
| • | Unikaj tworzenia agregacji zawierających atrybuty, które są ze sobą w relacji. Tworzenie takich agregacji powoduje, że zagregowane dane są niejako powielone. Zwiększa to czas procesowania oraz ilość potrzebnego miejsca. Wystarczy, że wybierzesz jeden najbardziej elementarny atrybut, a pozostałe wartości zostaną wyliczone na podstawie tego jednego. |
| • | Rozważ dodanie wymiaru czasu do każdego zestawu agregacji. Wymiar czasu jest specjalnym wymiarem, którego obecność w agregacji może znacznie zwiększyć wydajność. |
Przeczytaj pozostałe części tego artykułu
| • | Projektowanie agregacji w Microsoft SQL Server Analysis Services 2005, cz. I |
 | Daniel Arak (InspireTech) |
 | Łukasz Kieloch (InspireTech) |