Storage Engine – jego rola w optymalizacji zapytań DAX w LuckyTemplates

W tym samouczku przyjrzymy się drugiemu mechanizmowi w usługach analitycznych — silnikowi pamięci masowej.

Omówiliśmy aparat najwyższego poziomu, aparat formuł , w poprzednim samouczku. Gdy użytkownicy zrozumieją, jak działają oba te aparaty, łatwiej będzie zoptymalizować i poprawić wydajność zapytań języka DAX.

Głównym celem mechanizmu składowania jest bezpośrednia praca z bazą danych.

Mechanizm formuł nie ma bezpośredniego dostępu do bazy danych, więc w tym celu zwykle przechodzi przez mechanizm magazynu.

Silnik pamięci ma dwa typy — tryb importu i tryb DirectQuery . Możesz mieszać i dopasowywać oba typy w tym samym modelu danych, aby utworzyć model złożony.

Spis treści

• Praca z trybem importu w silniku pamięci masowej
• Praca z DirectQuery w silniku pamięci masowej
• Praca z modelami złożonymi
• Inne krytyczne punkty dotyczące silnika pamięci masowej
• Praca nad skomplikowanymi zapytaniami
• Wniosek

Praca z trybem importu w silniku pamięci masowej

Najpierw porozmawiajmy o trybie importu. Jest to również bardziej znane jako Vertipaq, ale jest również nazywane xVelocity lub In Memory Columnar Database.

Istnieją cztery krytyczne rzeczy, które należy zrozumieć, aby zrozumieć, jak działa tryb importu.

Najpierw Vertipaq tworzy kopię danych bezpośrednio ze źródła danych i przechowuje je w pamięci RAM w skompresowanym formacie .

Po drugie, dane przetwarzane w trybie importu bazują na ostatniej operacji odświeżania . Oznacza to, że jeśli ostatnio odświeżałeś swoje dane w zeszłym tygodniu, to dane, z którymi masz do czynienia, to nadal te same dane z zeszłego tygodnia. Jest to szczególnie ważne w przypadku korzystania z konfiguracji złożonej, w której jedna tabela jest w trybie importu, a druga w trybie DirectQuery.

Załóżmy, że masz odświeżoną w zeszłym tygodniu tabelę Produkty w trybie importu. Jeśli chodzi o tabelę Sales, zdecydowałeś się przeprowadzić ją przez DirectQuery ze względu na jej rozmiar. Załóżmy również, że tworzysz raport na podstawie obu tabel, w których wprowadzasz kolumnę Marka i tworzysz miarę Total Sales w tej samej tabeli Sales. Chcesz również zwizualizować kwotę sprzedaży na podstawie marki.

Najpierw musisz odświeżyć dane pochodzące z trybu importu, ponieważ możesz otrzymać świeże i zaktualizowane dane z trybu DirectQuery oraz nieaktualne dane z Vertipaq. Spowoduje to pozostawienie kilku pustych wierszy w macierzy i wizualizacji.

Następną rzeczą, którą musisz wiedzieć o Vertipaq jest to, że natywnie dostępne są tylko podstawowe operacje, takie jak , , , lub . Oznacza to, że jeśli w planie zapytań znajdują się inne, bardziej skomplikowane operacje, mechanizm pamięci musiałby wywołać mechanizm formuł, aby rozwiązać tę część kodu.

Wreszcie, silnik pamięci masowej jest wysoce zoptymalizowaną bazą danych ze względu na kolumnową strukturę Vertipaq . Oznacza to, że wszystkie dane są przechowywane kolumna po kolumnie, a nie wiersz po wierszu. Dzięki tej strukturze Vertipaq zawsze będzie szybszy niż połączenie DirectQuery, nawet jeśli utworzysz indeksy w swoim relacyjnym modelu danych.

Praca z DirectQuery w silniku pamięci masowej

Następną opcją, którą mamy w usługach analizy LuckyTemplates, jest DirectQuery. W przypadku korzystania z połączenia DirectQuery usługi analityczne działają tylko jako przejściówka dla zapytań wysyłanych przez aparat formuł.

Załóżmy więc, że piszesz zapytanie. Mechanizm formuł wygeneruje plan zapytań. Następnie przekaże zapytanie do silnika magazynującego, już przetłumaczonego na język macierzysty bazy danych. W większości przypadków te zapytania są w języku SQL.

Jeśli zapytanie korzysta z trybu DirectQuery, oczekuj, że będzie ono zawsze aktualne. Nie musisz się martwić, kiedy ostatnio odświeżałeś dane.

Proces optymalizacji kodu DAX i modelu danych będzie również zależał od tego, jak powstała relacyjna baza danych. Jeśli masz indeksy w swoich kolumnach, Twoje zapytania będą zawsze optymalizowane. Ale jeśli Twoja baza danych nie jest zoptymalizowana pod kątem tworzenia raportów za pomocą usług analitycznych lub LuckyTemplates, możesz napotkać kilka wyzwań związanych z wydajnością. Bądź więc celowy w budowaniu baz danych na potrzeby opracowywania raportów.

Praca z modelami złożonymi

Trzecią opcją jest utworzenie modelu złożonego, dzięki czemu jedna tabela będzie dostępna w trybie importu, a druga w trybie DirectQuery.

Gdy używasz dwóch tabel z różnych źródeł, aparat formuł wyśle ​​jedno żądanie do Vertipaq, a drugie do źródła danych DirectQuery. W obu przypadkach usługi analityczne pobierają również pamięć podręczną danych zarówno z Vertipaq, jak i DirectQuery. Silnik formuł użyje następnie JOIN, lub dowolnej iteracji w obu pamięciach podręcznych danych przed udostępnieniem wyników użytkownikowi końcowemu.

Załóżmy więc, że próbujesz zwizualizować kwotę sprzedaży według marki produktu w swoim raporcie. Silnik formuł wyśle ​​żądanie do Vertipaq, skąd pobierze produkt, markę i klucz produktu. Następnie z trybu DirectQuery spróbuje pobrać sprzedaż, cenę netto, wielkość sprzedaży i klucz produktu sprzedaży.

Po uzyskaniu dwóch pamięci podręcznych danych opartych na kluczu produktu połączy się z dwiema pamięciami podręcznymi danych i obliczy całkowitą kwotę sprzedaży. Następnie przedstawi wyniki użytkownikowi końcowemu.

Inne krytyczne punkty dotyczące silnika pamięci masowej

Teraz, gdy omówiliśmy różne typy, jest jeszcze kilka innych krytycznych czynników, które należy znać o aparacie pamięci masowej, aby zoptymalizować zapytania języka DAX.

Jak wspomniałem wcześniej, mechanizm pamięci masowej udostępnia pamięć podręczną danych z powrotem do mechanizmu formuły w postaci nieskompresowanej pamięci podręcznej danych. Gdy jesteś w trybie importu, żądanie wysyłane z powrotem do Vertipaq jest wykonywane w języku xmSQL.

Język xmSQL jest nieco podobny do języka SQL, ale nie jest całkowicie taki sam. Szczegółowo omówimy xmSWL, gdy będziemy mówić o planach zapytań w innym samouczku.

Należy również pamiętać, że silnik pamięci masowej wykorzystuje wszystkie rdzenie dostępne w procesorze. Możliwość korzystania z wielu rdzeni jest korzystna w przypadku posiadania wielu segmentów w modelu danych.

Załóżmy, że masz tabelę w usłudze LuckyTemplates zawierającą 12 milionów wierszy. Ta tabela zostanie następnie podzielona na 12 segmentów, ponieważ zarówno w Power Pivot, jak i LuckyTemplates każdy segment mieści 1 milion wierszy. Różni się to ogólnie od usług analitycznych, w których jeden segment mieści 8 milionów wierszy.

Więc jeśli mam sześć rdzeni w moim procesorze, wszystkie sześć rdzeni skanuje jednocześnie pierwsze sześć z 12 segmentów. Gdy skończą, przejdą do następnych sześciu segmentów.

Ale jeśli pracuję z usługami analitycznymi, w których domyślny segment zawiera 8 milionów wierszy, zostaną użyte tylko dwa z moich sześciu rdzeni — jeden segment przetworzy 8 milionów wierszy, a drugi 4 miliony.

Praca nad skomplikowanymi zapytaniami

Wcześniej wspomniałem, że tryb importu obsługuje tylko podstawowe operacje, takie jak MIN, MAX, SUM, COUNT i GROUPBY. Co się stanie, jeśli będziesz pracować nad bardziej skomplikowanymi zapytaniami?

Załóżmy, że zdecydujesz się użyć instrukcji JEŻELI w kontekście wiersza lub zagnieżdżonej iteracji, takiej jak SUMX, w tabelach Products i Sales.

W takim przypadku aparat magazynu nie będzie w stanie samodzielnie rozwiązać zapytania. Następnie wywoła silnik formuł, który rozpocznie rozwiązywanie złożonych obliczeń wiersz po wierszu wewnątrz silnika magazynującego. Niektórym może się wydawać, że jest to korzystny scenariusz, w którym oba silniki pracują razem — ale jest to dalekie od prawdy.

Widzisz, kiedy tak się dzieje, pamięć podręczna danych tworzona przez silnik pamięci masowej nie może być buforowana w przypadku, gdy w tym konkretnym zapytaniu występuje callbackdataID. Jeśli więc odświeżysz wizualizację, to samo obliczenie będzie musiało zostać wykonane zarówno przez mechanizm formuł, jak i mechanizm pamięci, mimo że wykonałeś to samo zapytanie kilka sekund temu. Doprowadzi to do opóźnień w działaniu i złego doświadczenia użytkownika.

Należy również zauważyć, że mechanizm magazynu nie wie, czy zapytania zostały wykonane przy użyciu języka DAX czy MDX. Jak wspomnieliśmy wcześniej, zadaniem aparatu formuł jest konwersja zapytań na odpowiedni język przed przekazaniem planu zapytań.

Na koniec silnik formuł wysyła zapytania do mechanizmu magazynującego jeden po drugim. Oznacza to, że posiadanie wielu segmentów jest naprawdę lepsze, ponieważ całkowity czas skanowania w Vertipaq może zostać skrócony, gdy wiele segmentów jest skanowanych w tym samym czasie.

DAX dla usługi LuckyTemplates: Optymalizacja przy użyciu silników formuł w DAX Studio
Techniki i lekcje optymalizacji zapytań w języku DAX
Wydajność zapytań i konfiguracja w DAX Studio

Wniosek

Zrozumienie tajników mechanizmu magazynu naprawdę pomaga w optymalizacji zapytań DAX, zwłaszcza jeśli używasz DAX Studio. Jeśli zapoznałeś się również z samouczkiem objaśniającym aparat formuł, możesz podejmować lepsze decyzje dotyczące tworzenia skuteczniejszych zapytań.

Chociaż silnik formuły służy jako silnik najwyższego poziomu, nie ma wątpliwości, że nie będzie działał tak dobrze, jak tylko może, jeśli nie zmaksymalizujemy obu silników.

Wszystkiego najlepszego,