Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W modelach semantycznych usługi Power BI tryb przechowywania tabeli zależy od źródła danych. Tryb przechowywania umożliwia kontrolowanie, czy usługa Power BI przechowuje dane tabeli w pamięci dla raportów, czy pobiera dane ze źródła danych podczas ładowania wizualizacji.
W tym artykule przedstawiono różne tryby przechowywania tabel i opisano, jak wpływają one na zachowanie raportu.
Tryby przechowywania tabel
| Tryb przechowywania tabel | Gdy jest dostępny | Korzyści | Notatka |
|---|---|---|---|
| Import | W programie Power BI Desktop i modelowaniu internetowym usługi Power BI dla prawie wszystkich źródeł danych po wybraniu pozycji Pobierz dane i użyciu dodatku Power Query. | Migawka danych jest przechowywana w magazynie natywnym na potrzeby szybkiego ładowania wizualizacji w raportach. | Aby pobrać najnowsze dane ze źródła danych, odśwież model semantyczny lub tabelę. |
| Usługa Direct Lake w usłudze OneLake | W programie Power BI Desktop i modelowaniu internetowym usługi Power BI w przypadku źródeł danych usługi Microsoft Fabric po wybraniu katalogu OneLake. | Dane są skanowane z tabel różnicowych usługi Microsoft OneLake w celu szybkiego ładowania wizualizacji w raportach. | Domyślnie są ładowane najnowsze dane. Aby uzyskać dostęp do najnowszych danych, odświeżając je ręcznie, wyłącz automatyczną synchronizację na stronie ustawień zaplanowanego odświeżania. Odświeżanie jest również nazywane reframowaniem dla usługi Direct Lake. Aby uzyskać więcej informacji na temat usługi Direct Lake, zobacz Omówienie usługi Direct Lake. |
| Direct Lake na SQL | W punktach końcowych analizy SQL elementów sieci szkieletowej po wybraniu pozycji Nowy model semantyczny. | Dane są skanowane z tabel OneLake Delta w celu szybkiego ładowania raportów. | W tym trybie usługa Power BI używa trybu przechowywania DirectQuery w celu uzyskania dostępu do danych w następujących przypadkach: — Jest używany widok. — włączono szczegółowy dostęp SQL. - Osiągnięto barierę chroniącą w usłudze Direct Lake. |
| DirectQuery | W programie Power BI Desktop w przypadku niektórych źródeł danych, takich jak bazy danych SQL, po wybraniu pozycji Pobierz dane i użyciu dodatku Power Query. | Dane są odpytywane ze źródła danych, gdy wizualizacje ładują się i nie są przechowywane w modelu semantycznym. | Zapytanie jest tłumaczeniem zapytania języka DAX (Power BI Data Analysis Expressions), które jest używane przez wizualizacje do natywnego języka zapytań źródła danych, takiego jak zapytanie SQL. |
| Tryb DirectQuery w modelach semantycznych usługi Power BI | W programie Power BI Desktop po nawiązaniu połączenia z modelem semantycznym usługi Power BI, a następnie wybraniu pozycji Wprowadź zmiany w tym modelu lub po dodaniu tabeli Import lub DirectQuery. | Zapytania języka DAX z nowego modelu działają w modelu źródłowym i mogą używać miar z obu. Niektóre właściwości kolumny w modelu zdalnym można zastąpić w nowym modelu. To dostosowanie obejmuje ciągi formatowania i nazwę wyświetlaną. | Użyj tego trybu przechowywania, gdy musisz wprowadzić niewielką zmianę w istniejącym modelu semantycznym dla określonego raportu. |
| Podwójny | W programie Power BI Desktop podczas konwertowania tabeli DirectQuery na tryb importu. Zostanie wyświetlone okno dialogowe z opcjami konwertowania pozostałych tabel DirectQuery na tryb podwójny. | Relacje między tabelami DirectQuery i Import są ograniczone. Przełączanie z trybu DirectQuery na tryb podwójny może pomóc w regularnym zachowaniu tych relacji. | |
| Hybrydowy | W scenariuszach odświeżania przyrostowego w tabeli Importuj. Najnowsza partycja tabeli może znajdować się w trybie DirectQuery, aby zapewnić dostępność najnowszych danych między odświeżaniami importu. | Tworzenie partycji i zarządzanie nimi są zautomatyzowane w celu zmniejszenia ilości danych, które należy odświeżyć. | Aby uzyskać więcej informacji, zobacz Konfigurowanie odświeżania przyrostowego i danych w czasie rzeczywistym dla modeli semantycznych usługi Power BI. |
Notatka
Tryb połączenia na żywo jest używany w następujących przypadkach:
- Aby nawiązać połączenie z semantycznym modelem usługi Power BI w programie Power BI Desktop w celu utworzenia raportu
- Aby utworzyć raport na podstawie semantycznego modelu usługi Power BI w Internecie
Raport połączenia na żywo nie ma lokalnego modelu semantycznego i jest czasami nazywany raportem cienkim. Zdalny model semantyczny usługi Power BI może używać dowolnego trybu przechowywania tabel. Jako autor raportu możesz zobaczyć model w widoku modelu , ale dostępne są tylko ograniczone informacje. Utworzone miary są przechowywane w raporcie.
Model semantyczny złożony to semantyczny model z tabelami w więcej niż jednym trybie przechowywania. Aby uzyskać więcej informacji, zobacz Używanie modeli złożonych w usłudze Power BI.
Wyświetlanie trybu przechowywania tabeli
Każda tabela ma Storage mode właściwość . Aby wyświetlić tryb przechowywania tabeli, wykonaj następujące kroki:
W widoku Model wybierz tabelę.
W okienku Właściwości rozwiń sekcję Zaawansowane , a następnie rozwiń listę Tryb przechowywania .
W przypadku większości tabel można ustawić tryb przechowywania tylko podczas dodawania tabeli. Tryb przechowywania można zmienić tylko wtedy, gdy tabela jest w trybie DirectQuery lub w trybie Direct Lake w trybie OneLake podczas tworzenia:
- Tabelę DirectQuery można zmienić na tabelę Import lub Dual. Po ustawieniu tej właściwości nie można ustawić trybu z powrotem na Tryb DirectQuery. Wyjątki to modelowanie internetowe usługi Power BI i edytowanie na żywo w programie Power BI Desktop. Oba środowiska mają kontrolę wersji, której można użyć do odwrócenia zmienionego trybu przechowywania.
- Usługę Direct Lake w tabelach OneLake można przekonwertować na tabele Importuj przy użyciu laboratoriów linków semantycznych w notesach usługi Fabric.
Ograniczenia dotyczące tabel DirectQuery i Dual
Tabele podwójne mają te same ograniczenia funkcjonalne co tabele DirectQuery. Te ograniczenia obejmują ograniczone przekształcenia języka M i ograniczone funkcje języka DAX w kolumnach obliczeniowych. Aby uzyskać więcej informacji, zobacz ograniczenia trybu DirectQuery.
Propagacja ustawienia podwójnego
Rozważmy następujący model. Wszystkie tabele pochodzą z jednego źródła, które obsługuje tryby Import i DirectQuery.
Załóżmy, że wszystkie tabele w tym modelu są początkowo ustawione na zapytanie bezpośrednie. Jeśli zmienisz tryb przechowywania tabeli SurveyResponse na Import, zostanie wyświetlone następujące okno ostrzeżenia:
Tabele wymiarów, Customer, Geography i Date można ustawić na Tryb podwójny, aby zmniejszyć liczbę ograniczonych relacji w modelu semantycznym i zwiększyć wydajność. Ograniczone relacje zwykle obejmują co najmniej jedną tabelę DirectQuery, w której JOIN logika nie może być wypychana do systemów źródłowych. Ponieważ tabele podwójne mogą działać jako tabele DirectQuery lub Import, ta sytuacja jest unikana.
Logika propagacji została zaprojektowana, aby pomóc w pracy z modelami zawierającymi wiele tabel. Załóżmy, że masz model z 50 tabelami, a tylko niektóre tabele faktów (transakcyjne) muszą być buforowane. Logika w programie Power BI Desktop oblicza minimalny zestaw tabel wymiarów, które muszą być ustawione na tryb podwójny, więc nie trzeba tego robić.
Logika propagacji przechodzi tylko do jednej strony relacji jeden do wielu.
Przykład użycia trybu przechowywania
Rozważmy przykład obejmujący następujące tabele i tryby przechowywania:
| Stół | Tryb przechowywania |
|---|---|
| Sales | DirectQuery |
| SurveyResponse | Import |
| Data | Podwójny |
| Klient | Podwójny |
| Geografia | Podwójny |
Użycie tych trybów przechowywania powoduje następujące zachowanie przy założeniu, że tabela Sales ma znaczący wolumin danych:
Program Power BI Desktop buforuje tabele wymiarów, datę, klienta i lokalizację geograficzną, aby skrócić czas ładowania początkowych raportów podczas pobierania wartości fragmentatora do wyświetlenia.
Program Power BI Desktop nie buforuje tabeli Sales.
- Buforowanie tej tabeli pomaga skrócić czas odświeżania danych i zmniejszyć zużycie pamięci.
- Zapytania raportów oparte na tabeli Sales są uruchamiane w trybie DirectQuery. Te zapytania mogą trwać dłużej niż importowanie zapytań. Jednak wyniki zapytań DirectQuery są bliżej wyników w czasie rzeczywistym, ponieważ nie wprowadzono opóźnień buforowania.
Zapytania raportów oparte na tabeli SurveyResponse są stosunkowo szybkie, ponieważ są zwracane z pamięci podręcznej w pamięci.
Zapytania trafiające lub omijające pamięć podręczną
Możesz użyć programu SQL Server Profiler, aby zobaczyć, które zapytania trafią lub przegapią pamięć podręczną w pamięci. Jeśli połączysz to narzędzie z portem diagnostycznym programu Power BI Desktop, możesz wykonać ślad oparty na następujących zdarzeniach:
- Zdarzenia zapytań\Początek zapytania
- Przetwarzanie zapytań\Początek zapytania Vertipaq SE
- Przetwarzanie zapytań\Początek zapytania bezpośredniego
Dla każdego zdarzenia Początek zapytania sprawdź inne zdarzenia o tej samej ActivityID wartości. Jeśli na przykład nie istnieje zdarzenie DirectQuery Begin, ale istnieje zdarzenie Vertipaq SE Query Begin, zapytanie zostanie obsłużone z pamięci podręcznej.
Zapytania odwołujące się do tabel podwójnych zwracają dane z pamięci podręcznej, jeśli to możliwe. W przeciwnym razie przywracają tryb DirectQuery.
Rozważ kilka zapytań języka DAX odwołujących się do tabel w poprzedniej sekcji. Na przykład następujące zapytanie odwołuje się tylko do kolumny z tabeli Date (Data ), która jest w trybie podwójnym. W związku z tym zapytanie powinno trafić do pamięci podręcznej:
Poniższe zapytanie odwołuje się tylko do kolumny z tabeli Sales (Sprzedaż ), która jest w trybie DirectQuery. W związku z tym nie powinno trafić do pamięci podręcznej.
Poniższe zapytanie jest interesujące, ponieważ łączy obie kolumny. To zapytanie nie trafia do pamięci podręcznej. Początkowo można oczekiwać pobrania wartości CalendarYear z pamięci podręcznej i wartości SalesAmount ze źródła, a następnie połączenia wyników. Jednak takie podejście jest mniej wydajne niż przesyłanie operacji SUM lub GROUP BY do systemu źródłowego. Jeśli źródło wykonuje operację, zwracana jest tylko suma sprzedaży dla każdego roku. Ten wynik prawdopodobnie zawiera znacznie mniej wierszy niż wtedy, gdy zostaną zwrócone wszystkie wartości SalesAmount .
Notatka
To zachowanie różni się od relacji wiele-do-wielu w programie Power BI Desktop, gdy buforowane tabele są łączone z tabelami, które nie są buforowane.
Zachowywanie synchronizacji pamięci podręcznych
Zapytania w poprzedniej sekcji pokazują, że tabele podwójne czasami trafiają do pamięci podręcznej, a czasami nie. W związku z tym wartości zwracane z nieaktualnej pamięci podręcznej mogą różnić się od wartości zwracanych ze źródła. Wykonywanie zapytania nie próbuje maskować problemów z danymi, na przykład przez filtrowanie wyników zapytania bezpośredniego w celu dopasowania do buforowanych wartości. Twoim zadaniem jest zapoznanie się z przepływami danych i odpowiednie projektowanie. Istnieją ustalone techniki obsługi takich przypadków w źródle, w razie potrzeby.
Tryb przechowywania podwójnego jest optymalizacją wydajności. Należy używać go tylko w sposób, który nie narusza możliwości spełnienia wymagań biznesowych. Aby uzyskać alternatywne zachowanie, rozważ użycie technik opisanych w artykule Omówienie relacji wiele-do-wielu w programie Power BI Desktop.
Widok tabeli
Jeśli co najmniej jedna tabela w modelu semantycznym ma tryb przechowywania Import lub Dual, dostępna jest karta Widok tabeli usługi Power BI.
Po wybraniu tabeli Podwójne lub Importuj w widoku tabeli zostaną wyświetlone buforowane dane. Dla tabel DirectQuery nie są wyświetlane żadne dane. Zamiast tego zostanie wyświetlony komunikat informujący, że nie można wyświetlić tabel DirectQuery.
Zagadnienia i ograniczenia
Obecnie istnieją pewne ograniczenia dotyczące trybów przechowywania tabel i korzystania z niektórych trybów w modelach złożonych:
Następujących źródeł połączenia na żywo (wielowymiarowych) nie można używać z modelami złożonymi:
- SAP HANA
- SAP Business Warehouse
Podczas nawiązywania połączenia z tymi wielowymiarowymi źródłami przy użyciu trybu DirectQuery nie można nawiązać połączenia z innym źródłem DirectQuery ani połączyć go z zaimportowanymi danymi.
Ograniczenia korzystania z trybu DirectQuery nadal mają zastosowanie w przypadku korzystania z modeli złożonych. Wiele z tych ograniczeń ma zastosowanie na poziomie tabeli i zależy od trybu przechowywania tabeli. Na przykład kolumna obliczeniowa w zaimportowanej tabeli może odwoływać się do innych tabel, ale kolumna obliczeniowa w tabeli DirectQuery może odwoływać się tylko do kolumn w tej samej tabeli. Inne ograniczenia dotyczą modelu jako całości, jeśli którakolwiek z tabel w modelu jest w trybie DirectQuery.
Powiązana zawartość
Aby uzyskać więcej informacji na temat modeli złożonych i trybu DirectQuery, zobacz następujące artykuły: