DAX CALCULATETABLE Vs FILTER Funkcja

Zarówno , jak i to zaawansowane narzędzia do manipulowania i analizowania danych w zapytaniu DAX, ale mają pewne kluczowe różnice, które należy zrozumieć.

W tym blogu omówimy funkcję CALCULATETABLE i jej plan zapytań w DAX Studio oraz zrozumiemy, czym różni się ona od funkcji FILTER . Pod koniec będziesz lepiej rozumieć, jak wybrać odpowiednią funkcję do swoich potrzeb związanych z analizą danych.

Aby zademonstrować, użyjemy poniższego kodu DAX.

Po uruchomieniu tego kodu otrzymasz tabelę przedstawiającą markę i kolor.

Na karcie Plany zapytań otrzymasz kod odpowiadający operatorowi CrossApply w Formula Engine .

Jednocześnie możesz zobaczyć, że kod pobiera tylko kolor i markę produktu na karcie Czasy serwera .

Spis treści

• Wynik chronometrażu serwera DAX Studio dla CALCULATETABLE
• CALCULATETABLE Plan zapytań w DAX Studio
• Przejście kontekstu dla podobnych funkcji języka DAX
  • Czasy serwera
  • Plan zapytań
• Wniosek

Wynik chronometrażu serwera DAX Studio dla CALCULATETABLE

Jako przykład przefiltrujmy kolor produktu, aby pokazać tylko czerwony i/lub czarny.

Możesz to zrobić za pomocą funkcji FILTRUJ. Kiedy go uruchomisz, czasy serwera pokażą, że argument FILTER nie jest stosowany do kodu xmSQL .

Ale jeśli użyjesz funkcji CALCULATETABLE, zapytanie w zakładce Server Timings pokaże, że wyniki zostały przefiltrowane według koloru produktu.

CALCULATETABLE Plan zapytań w DAX Studio

Przyjrzyjmy się planowi zapytań dla każdej funkcji.

CALCULATETABLE znajduje się w pierwszym wierszu planu zapytań logicznych , ponieważ jest to funkcja najwyższego poziomu w kodzie i dlatego nie zależy od żadnych wymagań.

Kiedy czytasz plan zapytań funkcji CALCULATETABLE, nie zaczynasz od pierwszego argumentu. Najpierw musisz zrozumieć używany kontekst filtru. Przejdźmy więc do linii 5.

Widać, że operator VertiPaq wymaga kolumny koloru produktu ze względu na zastosowany filtr. Następnie skanuje tę kolumnę i używa kombinacji filtra Not IsEmpty , aby sprawdzić kolor produktu w każdym wierszu.

Po przygotowaniu kontekstu filtru wykonywany jest argument

Z perspektywy czasu, jeśli użyjesz funkcji FILTER, zobaczysz inny plan zapytań, więc argument CROSSJOIN jest wykonywany przed zidentyfikowaniem kontekstu filtru.

Wadą tego podejścia jest to, że nie przekazuje warunku filtru do aparatu pamięci masowej. Nie będziesz mógł użyć klauzuli WHERE wewnątrz xmSQL, co spowoduje duże obciążenie dla silnika formuł.

A kiedy pracujesz z wieloma tabelami, kombinacja filtrów funkcji CROSSJOIN będzie ogromna. Spowalnia to działanie kodu DAX. Dlatego w większości przypadków zaleca się użycie funkcji CALCULATETABLE.

Zamiast więc wykonywać wszystkie obliczenia w silniku formuł, możesz wstrzyknąć warunek filtru do klasy WHERE kodu XMSQL.

Przejście kontekstu dla podobnych funkcji języka DAX

Czasy serwera

Ta koncepcja ma również zastosowanie do funkcji OBLICZ. Użyjmy poniższego kodu DAX jako przykładu.

Miara automatycznie ma wokół siebie funkcję CALCULATE.

Po uruchomieniu tego kodu otrzymasz tabelę przedstawiającą łączną kwotę sprzedaży dla każdego koloru.

Na karcie Czasy serwera widać, że kod wykonuje dwa zapytania. Pierwsze zapytanie polega na obliczeniu sumy kwoty Sales z tabeli Sales w odniesieniu do tabeli Products.

Z drugiej strony drugie zapytanie ponownie pobiera kolor produktu z tabeli Produkty. Odpowiada funkcji w kodzie języka DAX.

Formuła Engine umieszcza pamięci podręczne danych dwóch zapytań obok siebie. Rozpoczyna się od pobrania wartości z drugiej pamięci podręcznej danych, a następnie przeprowadza wyszukiwanie w pierwszej pamięci podręcznej danych.

Plan zapytań

Na karcie Plan zapytań logiczny plan zapytań skanuje kolor produktu z powodu argumentu .

Następnie VertiPaq sumuje całkowitą kwotę sprzedaży w zależności od koloru produktu. Wykonuje przejście kontekstu, które konwertuje wartość koloru produktu na równoważny kontekst filtra.

Filtr utworzony przez przejście kontekstu jest tłumaczony na właściwość DependOnCols w planie zapytań. Gdy VertiPaq przeskanuje kolumny wymagane do obliczenia całkowitej sprzedaży, mnoży sprzedaną ilość przez cenę netto.

Całkowita sprzedaż jest następnie zwracana jako wynik w postaci danych typu waluta. I wreszcie, ADDCOLUMNS zwraca tabelę z dwiema kolumnami zawierającymi wartość Kolor i Łączna sprzedaż.

Wniosek

Plan kwerend może mieć znaczący wpływ na wydajność kwerendy, ponieważ różne plany kwerend mogą mieć różne poziomy wydajności.

W przypadku korzystania z funkcji CALCULATETABLE i FILTER w zapytaniu języka DAX plan zapytań może się różnić w zależności od konkretnego scenariusza i różnych czynników, takich jak używane wyrażenie formuły i możliwości aparatu zapytań.

Ogólnie rzecz biorąc, dobrym pomysłem jest przetestowanie i porównanie wydajności różnych planów zapytań w celu określenia najbardziej wydajnego podejścia dla danego scenariusza.

Wszystkiego najlepszego,