SQL Server Analysis Services Tabular

SSAS Tabular to tryb analityczny oparty na modelu tabelarycznym i technologii kompresji kolumnowej.

Model tabelaryczny w środowisku analitycznym Microsoft

SQL Server Analysis Services Tabular jest częścią platformy Microsoft SQL Server przeznaczoną do budowania modeli analitycznych dla raportów, kokpitów i analiz wielowymiarowych. Zamiast udostępniać użytkownikowi bezpośredni dostęp do wielu tabel źródłowych, model przedstawia uporządkowany zestaw tabel, kolumn, relacji, miar i reguł bezpieczeństwa. Dane mogą pochodzić między innymi z relacyjnej bazy SQL Server, plików, hurtowni danych lub innych źródeł obsługiwanych przez użyte konektory.

Model Tabular zwykle projektuje się wokół schematu gwiazdy. Tabele faktów przechowują zdarzenia i wartości liczbowe, natomiast tabele wymiarów opisują daty, produkty, klientów, lokalizacje albo inne cechy potrzebne do filtrowania raportów. Relacje określają sposób przepływu filtrów między tabelami. Takie uporządkowanie ogranicza liczbę niejednoznacznych połączeń i ułatwia tworzenie miar, które zachowują się przewidywalnie w różnych widokach raportu.

Ważnym elementem rozwiązania jest język DAX. Służy on przede wszystkim do definiowania miar, kolumn obliczeniowych i tabel obliczeniowych. Miara jest obliczana w momencie wykonania zapytania, w zależności od aktualnego kontekstu filtrów, dlatego ta sama definicja może zwrócić inną wartość dla całego zestawienia, pojedynczego miesiąca lub wybranego produktu. Kolumna obliczeniowa jest natomiast wyliczana podczas przetwarzania modelu i przechowywana razem z pozostałymi danymi.

Połączenie relacji, metadanych i obliczeń pozwala narzędziom takim jak Power BI, Excel oraz aplikacje korzystające z usług analitycznych pobierać gotowe wskaźniki bez powtarzania całej logiki biznesowej w każdym raporcie. Model może również zawierać opisy pól, formaty liczbowe, hierarchie użytkownika i ustawienia widoczności, dzięki czemu odbiorca pracuje na znaczeniach biznesowych, a nie na technicznych nazwach kolumn źródłowych.

Przetwarzanie danych, zapytania i dobór trybu pracy

W typowym wdrożeniu dane są ładowane do modelu podczas przetwarzania. Silnik przygotowuje je do szybkiego odczytu, a następnie zapytania raportowe korzystają z już uporządkowanych struktur. W modelach importowanych użytkownik otrzymuje szybkie odpowiedzi, ale dane muszą być odświeżane, gdy zmieni się zawartość źródła. Można przetwarzać cały model albo wybrane tabele i partycje, co pozwala ograniczyć czas odświeżania dużych zbiorów.

Tryb DirectQuery działa inaczej: część danych pozostaje w źródle, a zapytania są przekazywane do niego w czasie pracy raportu. Zmniejsza to potrzebę przechowywania pełnego zestawu danych w modelu, lecz zwiększa zależność od wydajności źródłowej bazy, jakości generowanych zapytań i poprawnej konfiguracji połączenia. Wybór między importem a DirectQuery powinien wynikać z wymagań dotyczących świeżości danych, rozmiaru modelu, obciążenia źródła oraz oczekiwanego czasu odpowiedzi.

W większych modelach znaczenie mają partycje, selektywne przetwarzanie i właściwe przygotowanie danych przed załadowaniem. Filtrowanie rekordów, usuwanie nieużywanych kolumn oraz ograniczenie zbędnej szczegółowości może zmniejszyć zużycie pamięci i skrócić odświeżanie. Nie należy jednak przenosić całej logiki do kolumn obliczeniowych bez analizy kosztu. Często korzystniejsze jest przygotowanie danych w źródle lub w warstwie zapytania, a w modelu pozostawienie tylko obliczeń potrzebnych do analizy.

Tabular można porównać z drugim trybem modeli dostępnym w SQL Server Analysis Services, czyli modelem wielowymiarowym. Tabular opiera się na tabelach, relacjach i DAX, natomiast model wielowymiarowy wykorzystuje kostki, wymiary, hierarchie oraz język MDX jako podstawowy sposób definiowania zapytań i obliczeń. Nie jest to jedynie różnica nazewnictwa. Przeniesienie projektu z jednego trybu do drugiego wymaga ponownego zaprojektowania modelu, miar, uprawnień i sposobu komunikacji z narzędziami raportowymi.

W modelu można zdefiniować zabezpieczenia na poziomie wierszy. Reguła przypisuje użytkownikowi albo grupie dostęp do określonego podzbioru danych, na przykład do wybranych oddziałów lub regionów. Skuteczność takiej ochrony zależy od poprawnego mapowania tożsamości, relacji filtrujących oraz konfiguracji klienta. Samo ukrycie kolumny nie jest mechanizmem kontroli dostępu, ponieważ nie ogranicza dostępu do pozostałych danych znajdujących się w modelu.

Objawy błędów w modelu i pytania pojawiające się podczas pracy

Jednym z częstszych problemów jest długi czas odświeżania. Przyczyną może być duża liczba rekordów, niepotrzebne kolumny o wysokiej różnorodności wartości, nieefektywne zapytanie źródłowe albo przetwarzanie większego zakresu danych, niż jest rzeczywiście potrzebny. Sam fakt, że model zawiera mało tabel, nie oznacza niskiego kosztu obliczeń. O wydajności decydują również rozmiar kolumn, złożoność relacji i sposób zapisania miar.

Inny objaw to poprawnie wyglądające dane w tabelach, ale nieprawidłowe sumy w raporcie. Często wynika to z różnicy między kontekstem wiersza a kontekstem filtra w DAX, z relacji o niewłaściwym kierunku filtrowania albo z użycia kolumny obliczeniowej tam, gdzie potrzebna jest miara. Szczególnej uwagi wymagają relacje wiele-do-wielu, nieunikalne klucze oraz daty przechowywane jako tekst. W takich sytuacjach wynik może być formalnie obliczony, lecz nie odpowiadać regułom biznesowym.

Użytkownicy pytają również, dlaczego po zmianie danych w bazie raport nie pokazuje nowych wartości. W trybie importowanym konieczne jest wykonanie odświeżenia modelu, a następnie sprawdzenie, czy proces zakończył się powodzeniem. Jeżeli odświeżenie jest uruchamiane automatycznie, trzeba zweryfikować harmonogram, konto używane do połączenia, dostęp do źródła i zakres przetwarzanych partycji. W trybie DirectQuery opóźnienie może wynikać z pamięci podręcznej, ograniczeń źródła lub błędów połączenia.

Problemy z dostępem do danych mogą mieć kilka przyczyn. Użytkownik może widzieć pusty raport z powodu reguły zabezpieczeń na poziomie wierszy, braku uprawnień do modelu, nieprawidłowego mapowania grupy albo błędnej relacji między tabelą uprawnień a tabelą faktów. Diagnozę warto rozpocząć od ustalenia, czy problem dotyczy wszystkich osób, jednego raportu, konkretnego zestawu filtrów czy tylko wybranej miary.

Trudności może powodować także rozbieżność między środowiskiem projektowym a wdrożonym modelem. Raport może odwoływać się do innej nazwy bazy, innego źródła danych lub nieaktualnej wersji metadanych. Po wdrożeniu zmian trzeba sprawdzić, czy klient korzysta z właściwego modelu, czy struktura tabel odpowiada definicjom miar oraz czy przetwarzanie zostało wykonane po publikacji zmian.

Sygnały, że model wymaga diagnozy technicznej

Do konsultacji technicznej warto przygotować opis objawu, nazwę raportu, moment wystąpienia problemu oraz informację, czy błąd pojawia się przy otwieraniu raportu, filtrowaniu, odświeżaniu czy wykonywaniu konkretnej miary. Przydatne są również komunikaty błędów, czas trwania operacji i informacja o tym, czy problem dotyczy jednego użytkownika, czy całego zespołu. Takie dane pozwalają oddzielić błąd modelu od problemu z aplikacją kliencką albo źródłem danych.

Jeżeli analiza wskazuje na awarię komputera używanego do projektowania lub przeglądania raportów, Warszawskie Pogotowie Komputerowe może sprawdzić fizyczny stan laptopa albo komputera stacjonarnego, pamięć, dysk, zasilanie, płytę główną, matrycę i klawiaturę. W razie problemów z nośnikiem możliwa jest także podstawowa próba odzysku danych z uszkodzonego dysku, o ile jego stan pozwala na bezpieczne wykonanie takich czynności.

Warto rozdzielić usterkę sprzętową od błędu konfiguracji samego modelu. Samoczynne wyłączanie komputera, zawieszanie aplikacji, błędy odczytu dysku, uszkodzona pamięć lub przegrzewanie mogą utrudniać pracę z narzędziami analitycznymi, lecz nie naprawią się przez zmianę miary DAX. Z kolei nieprawidłowa suma, brak nowych danych po odświeżeniu albo ograniczenie widoczności rekordów zwykle wymaga analizy projektu, uprawnień i połączenia ze źródłem.

Niektóre starsze konfiguracje sprzętowe spotykane przy pracy z modelami analitycznymi są dziś rzadkie, ponieważ współczesne zestawy robocze zapewniają więcej pamięci i szybsze nośniki. Nadal jednak warto sprawdzić, czy komputer spełnia wymagania używanych narzędzi, czy system ma wystarczająco dużo wolnego miejsca na pliki tymczasowe oraz czy procesor i pamięć nie są przeciążane podczas odświeżania. Rzetelna diagnoza powinna wskazać konkretny element powodujący problem, zakres możliwej naprawy sprzętu i czynności, które pozostają po stronie administratora modelu.