Zaawansowane odświeżanie przyrostowe i dane w czasie rzeczywistym za pomocą punktu końcowego XMLA

Modele semantyczne w zasobie Premium z włączonym punktem końcowym XMLA dla operacji odczytu/zapisu umożliwiają bardziej zaawansowane odświeżanie, zarządzanie partycjami oraz wdrożenia wyłącznie metadanych za pośrednictwem narzędzi, skryptów i obsługi interfejsu API. Ponadto operacje odświeżania za pośrednictwem punktu końcowego XMLA nie są ograniczone do 48 odświeżeń dziennie, a zaplanowany limit czasu odświeżania nie jest nakładany .

Partitions

Partycje tabel modelu semantycznego nie są widoczne i nie można nimi zarządzać przy użyciu programu Power BI Desktop ani usługi Power BI. W przypadku modeli w obszarze roboczym przypisanym do pojemności Premium partycje można zarządzać za pośrednictwem punktu końcowego XMLA. Za pomocą narzędzi, takich jak SQL Server Management Studio (SSMS) lub edytor tabelaryczny typu open source, można zarządzać partycjami za pomocą skryptów za pomocą języka TMSL (Tabular Model Scripting Language) i programowo za pomocą tabelarycznego modelu obiektów (TOM).

Po pierwszym opublikowaniu modelu w usłudze Power BI każda tabela w nowym modelu ma jedną partycję. W przypadku tabel bez zasad odświeżania przyrostowego jedna partycja zawiera wszystkie wiersze danych dla tej tabeli, chyba że zastosowano filtry. W przypadku tabel z zasadami odświeżania przyrostowego istnieje tylko jedna partycja początkowa, ponieważ usługa Power BI nie zastosowała jeszcze zasad. Partycję początkową można skonfigurować w programie Power BI Desktop, definiując filtr zakresu daty/godziny dla tabeli na podstawie parametrów RangeStart i RangeEnd, oraz wszelkich innych filtrów zastosowanych w Edytorze Power Query. Ta początkowa partycja zawiera tylko te wiersze danych, które spełniają kryteria filtrowania.

Podczas pierwszej operacji odświeżania tabele bez zasad odświeżania przyrostowego odświeżają wszystkie wiersze zawarte w domyślnej pojedynczej partycji tej tabeli. W przypadku tabel z polityką odświeżania przyrostowego, partycje odświeżania i partycje historyczne zostają utworzone automatycznie, a wiersze są do nich ładowane zgodnie z datą/godziną każdego wiersza. Jeśli zasady odświeżania przyrostowego obejmują pobieranie danych w czasie rzeczywistym, usługa Power BI dodaje również partycję DirectQuery do tabeli.

Ta pierwsza operacja odświeżania może zająć sporo czasu w zależności od ilości danych, które należy załadować ze źródła danych. Złożoność modelu może być również istotnym czynnikiem, ponieważ operacje odświeżania muszą wykonywać więcej operacji przetwarzania i ponownego obliczania. Tę operację można zainicjować samodzielnie. Aby uzyskać więcej informacji, zobacz Zapobieganie przekroczeniom limitu czasu podczas początkowego pełnego odświeżania.

Partycje są tworzone i nazywane według stopnia szczegółowości okresu: lata, kwartały, miesiące i dni. Najnowsze partycje, czyli partycje odświeżania, zawierają wiersze w okresie odświeżania określonym w zasadach. Partycje historyczne zawierają wiersze według pełnego okresu aż do okresu odświeżania. Jeśli włączono czas rzeczywisty, partycja DirectQuery pobiera wszelkie zmiany danych, które wystąpiły po dacie zakończenia okresu odświeżania. Stopień szczegółowości odświeżania i partycji historycznych zależy od poziomu szczegółowości odświeżania i okresów przechowywania, które wybierasz podczas definiowania polityki.

Jeśli na przykład bieżąca data to 2 lutego 2021 r., a tabela FactInternetSales w źródle danych zawiera wiersze do dnia dzisiejszego, a nasze zasady określają, że należy uwzględniać zmiany w czasie rzeczywistym, wtedy odświeżane są wiersze w ciągu ostatniego dnia w okresie odświeżania i przechowywane są wiersze w okresie historycznym obejmującym ostatnie trzy lata. Następnie przy pierwszej operacji odświeżania zostanie utworzona partycja DirectQuery pod kątem zmian w przyszłości. Nowa partycja importu jest tworzona dla dzisiejszych wierszy, a historyczna partycja jest tworzona dla pełnego dnia wczoraj, 1 lutego 2021 r. Partycja historyczna jest tworzona dla poprzedniego całego miesiąca (styczeń 2021 r.). Partycja historyczna jest tworzona dla poprzedniego okresu całego roku (2020). Tworzone są partycje historyczne dla całych okresów roku 2019 i 2018. Nie są tworzone podziały pełnego kwartału, ponieważ 2 lutego pierwszy pełny kwartał 2021 r. nie został jeszcze ukończony.

W przypadku każdej operacji odświeżania odświeżane są tylko partycje dla okresu odświeżania. Filtr daty partycji DirectQuery jest aktualizowany tak, aby zawierał tylko te zmiany, które występują po bieżącym okresie odświeżania. Nowa partycja odświeżania jest tworzona dla nowych wierszy z nową datą/godziną w zaktualizowanym okresie odświeżania. Istniejące wiersze z datą/godziną, które już znajdują się w istniejących partycjach, są odświeżane w okresie odświeżania poprzez aktualizacje. Wiersze z datą/godziną starszą niż okres odświeżania nie są już aktualizowane.

W miarę zamykania całych okresów partycje są scalane. Jeśli na przykład w zasadach zostanie określony okres odświeżania jednodniowego i trzyletni okres przechowywania historycznego, w pierwszym dniu miesiąca wszystkie partycje z poprzedniego miesiąca zostaną scalone w miesięczną partycję. W pierwszym dniu nowego kwartału wszystkie trzy poprzednie miesięczne partycje są scalane w partycję kwartalną. W pierwszym dniu nowego roku wszystkie cztery partycje z poprzednich kwartałów są scalane w jedną partycję roczną.

Model zawsze zachowuje partycje dla całego historycznego okresu przechowywania oraz partycje całego okresu do bieżącego okresu odświeżania. W tym przykładzie dane historyczne z pełnych trzech lat są przechowywane w partycjach dla lat 2018, 2019, 2020, a także w partycjach dla miesięcznego okresu 2021Q101, dziennego okresu 2021Q10201 oraz okresu odświeżania bieżącego dnia. Ponieważ przykład przechowuje dane historyczne przez trzy lata, partycja z 2018 r. jest zachowywana do czasu pierwszego odświeżenia 1 stycznia 2022 r.

W przypadku przyrostowego odświeżania Power BI i danych czasu rzeczywistego, usługa obsługuje zarządzanie partycjami na podstawie zasad. Mimo że usługa może obsługiwać wszystkie funkcje zarządzania partycjami, korzystając z narzędzi za pośrednictwem punktu końcowego XMLA, można selektywnie odświeżać partycje pojedynczo, sekwencyjnie lub równolegle.

Typowe wzorce odświeżania partycji

Podczas pracy z operacjami punktu końcowego XMLA należy wziąć pod uwagę te typowe wzorce zarządzania operacjami odświeżania:

• Częste małe odświeżanie: uruchamianie wielu małych, docelowych operacji odświeżania w godzinach pracy przy użyciu poleceń partycji XMLA lub rozszerzonego interfejsu API REST, aby zachować najnowsze dane bez przetwarzania całej tabeli.
• Selektywne wypełnianie historyczne: przeprowadź większe odświeżanie partycji historycznych lub jednorazowe korekty danych poza godzinami pracy, używając języka TMSL, applyRefreshPolicy: false aby ponownie skompilować określone okresy historyczne bez wpływu na zachowanie zasad automatycznych.
• Początkowe obciążenia etapowe: w przypadku dużych okresów historycznych należy podzielić odświeżanie początkowe na mniejsze partie, przetwarzając partycje przyrostowo, aby uniknąć przekroczenia limitu czasu i zarządzania zużyciem zasobów.

Te wzorce umożliwiają zrównoważenie aktualności danych w czasie rzeczywistym z ograniczeniami wydajności systemu i zasobów.

Zarządzanie odświeżaniem za pomocą programu SQL Server Management Studio

Program SQL Server Management Studio (SSMS) może służyć do wyświetlania partycji utworzonych przez aplikację zasad odświeżania przyrostowego i zarządzania nimi. Korzystając z programu SSMS, można na przykład odświeżyć konkretną partycję historyczną, która nie przypada w okresie odświeżania przyrostowego, aby wykonać aktualizację z datą wsteczną bez konieczności odświeżania wszystkich danych historycznych. Można również używać SSMS podczas bootstrappingu, aby ładować dane historyczne dla dużych modeli poprzez przyrostowe dodawanie/odświeżanie partycji historycznych w grupach.

Zastępowanie przyrostowego zachowania odświeżania

W programie SSMS masz również większą kontrolę nad sposobem wywoływania odświeżeń przy użyciu języka skryptowego modelu tabelarycznego i modelu obiektów tabelarycznych. Na przykład w programie SSMS w Eksploratorze obiektów kliknij prawym przyciskiem myszy tabelę, a następnie wybierz opcję menu Przetwarzanie tabeli , a następnie wybierz przycisk Skrypt , aby wygenerować polecenie odświeżania TMSL.

Te parametry mogą być używane z poleceniem odświeżania TMSL w celu zastąpienia domyślnego zachowania odświeżania przyrostowego:

• applyRefreshPolicy. Jeśli tabela ma zdefiniowane zasady odświeżania przyrostowego, określ, applyRefreshPolicy czy zasady są stosowane, czy nie. Jeśli zasady nie są stosowane, pełna operacja procesu pozostawia definicje partycji bez zmian, a wszystkie partycje w tabeli zostaną w pełni odświeżone. Domyślna wartość to "true".

• effectiveDate. Jeśli są stosowane zasady odświeżania przyrostowego, należy znać bieżącą datę, aby określić przedziały czasowe przesuwające dla okresów odświeżania przyrostowego i historycznych. Parametr effectiveDate umożliwia zastąpienie bieżącej daty. Ten parametr jest przydatny do testowania, demonstracji i scenariuszy biznesowych, w których dane są odświeżane przyrostowo do daty w przeszłości lub przyszłości, jak na przykład planowanie budżetów. Wartość domyślna to bieżąca data.

{ 
  "refresh": {
    "type": "full",

    "applyRefreshPolicy": true,
    "effectiveDate": "12/31/2013",

    "objects": [
      {
        "database": "IR_AdventureWorks", 
        "table": "FactInternetSales" 
      }
    ]
  }
}

Aby dowiedzieć się więcej na temat zmiany domyślnego zachowania odświeżania przyrostowego za pomocą języka TMSL, zobacz polecenie Refresh.

Zarządzanie zasadami za pomocą edytora tabelarycznego

Oprócz programu SSMS można użyć edytora tabelarycznego do tworzenia i modyfikowania zasad odświeżania przyrostowego bezpośrednio względem modeli semantycznych za pośrednictwem punktu końcowego XMLA. Ta metoda umożliwia dostosowanie ustawień zasad — takich jak okresy odświeżania, okresy historyczne i wyrażenia źródłowe — bez konieczności ponownego publikowania modelu z poziomu programu Power BI Desktop. Edytor tabelaryczny może również służyć do stosowania zasad odświeżania do istniejących tabel i zarządzania wyrażeniami parametrów RangeStart oraz RangeEnd. Aby uzyskać więcej informacji, zobacz Odświeżanie przyrostowe w dokumentacji edytora tabelarycznego.

Odświeżanie aranżacji i automatyzacji

Poza używaniem SSMS, TMSL i TOM do zarządzania odświeżeniami za pośrednictwem punktu końcowego XMLA. Operacje odświeżania modelu semantycznego można również organizować przy użyciu interfejsu API REST usługi Power BI. Rozszerzony interfejs API odświeżania oferuje więcej możliwości, w tym odświeżanie na poziomie tabeli i na poziomie partycji, logikę ponawiania prób, anulowanie i niestandardowe zarządzanie limitem czasu. Takie podejście jest przydatne w przypadku integrowania operacji odświeżania z zautomatyzowanymi przepływami pracy i potokami ciągłej integracji/ciągłego wdrażania. Aby uzyskać szczegółowe wskazówki, zobacz Rozszerzone odświeżanie przy użyciu interfejsu API REST usługi Power BI.

Zapewnianie optymalnej wydajności

W przypadku każdej operacji odświeżania usługa Power BI może wysyłać zapytania inicjowania do źródła danych dla każdej partycji odświeżania przyrostowego. Możesz zwiększyć wydajność odświeżania przyrostowego, zmniejszając liczbę zapytań inicjacyjnych, zapewniając następującą konfigurację:

• Tabela, dla której konfigurujesz odświeżanie przyrostowe, powinna pobierać dane z jednego źródła danych. Jeśli tabela pobiera dane z więcej niż jednego źródła danych, liczba zapytań wysyłanych przez usługę dla każdej operacji odświeżania jest mnożona przez liczbę źródeł danych, co potencjalnie zmniejsza wydajność odświeżania. Upewnij się, że zapytanie dotyczące tabeli odświeżania przyrostowego dotyczy pojedynczego źródła danych.
• W przypadku rozwiązań z przyrostowym odświeżaniem partycji importu i danych w czasie rzeczywistym za pomocą zapytania bezpośredniego wszystkie partycje muszą wykonywać zapytania dotyczące danych z jednego źródła danych.
• Jeśli wymagania dotyczące bezpieczeństwa na to pozwalają, ustaw poziom prywatności źródła danych na Organizacyjny lub Publiczna. Domyślnie poziom prywatności to Prywatny. Jednak ten poziom może uniemożliwić wymianę danych z innymi źródłami chmury. Aby ustawić poziom prywatności, wybierz menu Więcej opcji, a następnie wybierz pozycję Ustawienia>Poświadczenia źródła danych>>dla tego źródła danych. Jeśli poziom prywatności został ustawiony w modelu programu Power BI Desktop przed opublikowaniem w usłudze, nie zostanie przeniesiony do usługi podczas publikowania. Nadal musisz ustawić go w ustawieniach modelu semantycznego w usłudze. Aby dowiedzieć się więcej, zobacz Poziomy prywatności.
• Jeśli używasz lokalnej bramy danych, upewnij się, że używasz wersji 3000.77.3 lub nowszej.

Zapobieganie przekroczeniom limitu czasu podczas początkowego pełnego odświeżania

Po opublikowaniu w usłudze Power BI, początkowa operacja pełnego odświeżania modelu tworzy partycje dla tabeli odświeżania przyrostowego, ładuje i przetwarza dane historyczne dla całego okresu zdefiniowanego w polityce odświeżania przyrostowego. W przypadku niektórych modeli, które ładują i przetwarzają duże ilości danych, czas, jaki trwa początkowa operacja odświeżania, może przekroczyć limit czasu odświeżania narzucony przez usługę lub limit czasu zapytania narzucony przez źródło danych.

Bootstrapping początkowej operacji odświeżania umożliwia usłudze tworzenie obiektów partycji dla tabeli odświeżania przyrostowego, ale nie ładowania i przetwarzania danych historycznych do żadnej z partycji. Program SSMS jest następnie używany do selektywnego przetwarzania partycji. W zależności od ilości danych do załadowania dla każdej partycji można przetwarzać poszczególne partycje sekwencyjnie lub w małych partiach. Ta metoda zmniejsza ryzyko, że co najmniej jedna z tych partycji spowoduje wystąpienie przekroczenia limitu czasu. Poniższe metody działają dla dowolnego źródła danych.

Zastosuj politykę odświeżania

Narzędzie Tabular Editor 2 typu open source umożliwia łatwe uruchomienie początkowej operacji odświeżania. Po opublikowaniu modelu z zasadami odświeżania przyrostowego zdefiniowanymi dla niego z programu Power BI Desktop do usługi połącz się z modelem przy użyciu punktu końcowego XMLA w trybie odczytu/zapisu. Uruchom Zastosuj Politykę Odświeżania na tabeli przyrostowego odświeżania. W przypadku zastosowania tylko zasad partycje są tworzone, ale żadne dane nie są do nich ładowane. Następnie połącz się z programem SSMS, aby odświeżyć partycje sekwencyjnie lub w partiach w celu załadowania i przetworzenia danych. Aby uzyskać więcej informacji, zobacz Odświeżanie przyrostowe w dokumentacji edytora tabelarycznego.

Filtr Power Query dla pustych partycji

Przed opublikowaniem modelu w usłudze, w Edytorze Power Query, dodaj kolejny filtr do kolumny ProductKey, który odfiltruje wszystkie wartości inne niż 0, skutecznie usuwając wszystkie dane z tabeli FactInternetSales.

Po wybraniu pozycji Zamknij i zastosuj w Edytorze Power Query, po zdefiniowaniu zasad odświeżania przyrostowego i zapisaniu modelu, model jest publikowany w usłudze. Z poziomu usługi początkowa operacja odświeżania jest uruchamiana w modelu. Partycje tabeli FactInternetSales są tworzone zgodnie z zasadami, ale żadne dane nie są ładowane i przetwarzane, ponieważ wszystkie dane są odfiltrowane.

Po zakończeniu początkowej operacji odświeżania w Edytorze Power Query drugi filtr w kolumnie ProductKey zostanie usunięty. Po wybraniu pozycji Zamknij i zastosuj w Edytorze Power Query i zapisaniu modelu model nie zostanie ponownie opublikowany. Jeśli model zostanie ponownie opublikowany, zastępuje ustawienia zasad odświeżania przyrostowego i wymusza pełne odświeżanie modelu po wykonaniu kolejnej operacji odświeżania z usługi. Zamiast tego przeprowadź wdrożenie metadanych tylko przy użyciu zestawu narzędzi do zarządzania cyklem życia aplikacji (ALM), który usuwa filtr w ProductKey kolumnie z modelu. Program SSMS może następnie służyć do selektywnego przetwarzania partycji. Gdy wszystkie partycje są w pełni przetwarzane, co musi obejmować ponowne obliczanie procesu na wszystkich partycjach z programu SSMS, kolejne operacje odświeżania modelu z usługi odświeżają tylko partycje odświeżania przyrostowego.

Aby dowiedzieć się więcej na temat przetwarzania tabel i partycji z programu SSMS, zobacz Process database, table, or partitions (Analysis Services). Aby dowiedzieć się więcej na temat przetwarzania modeli, tabel i partycji przy użyciu języka TMSL, zobacz Odświeżanie polecenia (TMSL).

Zapytania niestandardowe do wykrywania zmian danych

TMSL i TOM mogą służyć do zastępowania zachowania wykrytych zmian danych. Tej metody można użyć, aby uniknąć utrwalania kolumny ostatniej aktualizacji w pamięci podręcznej. Może również włączyć scenariusze, w których konfiguracja lub tabela instrukcji jest przygotowywana przez procesy wyodrębniania, przekształcania i ładowania (ETL). Umożliwienie oznaczania tylko tych partycji, które należy odświeżyć. Ta metoda może utworzyć bardziej wydajny proces odświeżania przyrostowego, w którym odświeżane są tylko wymagane okresy, niezależnie od tego, jak długo miały miejsce aktualizacje danych.

Element pollingExpression ma być lekkim wyrażeniem języka M lub nazwą innego zapytania języka M. Musi zwrócić wartość skalarną i jest wykonywana dla każdej partycji. Jeśli zwrócona wartość różni się od wartości sprzed ostatniego przyrostowego odświeżenia, partycja jest oznaczona do pełnego przetwarzania.

Poniższy przykład obejmuje wszystkie 120 miesięcy w okresie historycznym dla zmian z datą wsteczną. Określenie 120 miesięcy zamiast 10 lat oznacza, że kompresja danych może nie być tak wydajna. Jednak unika konieczności odświeżenia całego roku historycznego, co byłoby droższe, gdy miesiąc byłby wystarczający do zmiany wstecznej.

"refreshPolicy": {
    "policyType": "basic",
    "rollingWindowGranularity": "month",
    "rollingWindowPeriods": 120,
    "incrementalGranularity": "month",
    "incrementalPeriods": 120,
    "pollingExpression": "<M expression or name of custom polling query>",
    "sourceExpression": [
    "let ..."
    ]
}

Wdrażanie tylko metadanych

Podczas publikowania nowej wersji pliku pbix z programu Power BI Desktop do obszaru roboczego. Zostanie wyświetlony następujący monit o zastąpienie istniejącego modelu, jeśli model o tej samej nazwie już istnieje.

W niektórych przypadkach możesz nie chcieć zastąpić modelu, zwłaszcza przy odświeżaniu przyrostowym. Model w programie Power BI Desktop może być znacznie mniejszy niż model w usłudze Power BI. Jeśli model w usłudze Power BI ma zastosowane zasady odświeżania przyrostowego, możesz stracić kilka lat danych historycznych, jeśli model zostanie zastąpiony. Odświeżanie wszystkich danych historycznych może potrwać kilka godzin i spowodować przestój systemu dla użytkowników.

Zamiast tego lepiej jest wykonać wdrożenie tylko metadanych, co umożliwia wdrażanie nowych obiektów bez utraty danych historycznych. Jeśli na przykład dodasz tylko kilka miar, możesz wdrożyć tylko nowe miary bez konieczności odświeżania danych, co pozwala zaoszczędzić czas.

W przypadku obszarów roboczych przypisanych do pojemności Premium, skonfigurowanej do odczytu/zapisu na punkcie końcowym XMLA, zgodne narzędzia umożliwiają wdrażanie wyłącznie metadanych. Na przykład, ALM Toolkit jest narzędziem do porównywania schematów dla modeli Power BI i może być używane jedynie do wdrożenia metadanych.

Pobierz i zainstaluj najnowszą wersję ALM Toolkit z repozytorium Git usługi Analysis Services. Szczegółowe wskazówki dotyczące korzystania z zestawu narzędzi ALM Toolkit nie są zawarte w dokumentacji firmy Microsoft. Linki do dokumentacji zestawu narzędzi ALM Toolkit i informacje na temat możliwości obsługi są dostępne na wstążce Pomoc . Aby wykonać wdrożenie zawierające tylko metadane, przeprowadź porównanie i wybierz uruchomione wystąpienie programu Power BI Desktop jako źródło oraz istniejący model w usłudze Power BI jako cel. Rozważ wyświetlone różnice i pomiń aktualizację tabeli przy użyciu partycji odświeżania przyrostowego lub użyj okna dialogowego Opcje, aby zachować partycje podczas aktualizacji tabeli. Zweryfikuj wybór, aby zapewnić integralność modelu docelowego, a następnie zaktualizuj go.

Programowe dodawanie zasad odświeżania inkrementalnego i danych w czasie rzeczywistym

Możesz także użyć TMSL i TOM, aby dodać politykę odświeżania przyrostowego do istniejącego modelu za pośrednictwem endpointu XMLA.

Proces obejmuje następujące kroki:

1. Upewnij się, że model docelowy ma wymagany minimalny poziom zgodności. W programie SSMS kliknij prawym przyciskiem myszy pozycję [nazwa modelu]>Poziom zgodności>. Aby zwiększyć poziom zgodności, użyj skryptu createOrReplace TMSL lub sprawdź poniższy przykładowy kod TOM.

   a. Import policy - 1550
   b. Hybrid policy - 1565
   

2. Dodaj parametry RangeStart i RangeEnd do wyrażeń modelu. W razie potrzeby dodaj również funkcję, aby przekonwertować wartości daty/godziny na klucze dat.

3. Zdefiniuj obiekt RefreshPolicy z żądanym archiwizowaniem (oknem kroczącym) i okresami odświeżania przyrostowego, a także wyrażeniem źródłowym, które filtruje tabelę docelową na podstawie parametrów RangeStart i RangeEnd. Ustaw tryb zasad odświeżania na Import lub Hybrid w zależności od wymagań dotyczących danych w czasie rzeczywistym. Hybryda powoduje, że usługa Power BI dodaje partycję DirectQuery do tabeli, aby pobrać najnowsze zmiany ze źródła danych, które wystąpiły po ostatnim odświeżeniu.

4. Dodaj zasady odświeżania do tabeli i wykonaj pełne odświeżanie, aby Power BI partycjonował tabelę zgodnie z Twoimi wymaganiami.

W poniższym przykładzie kodu pokazano, jak wykonać poprzednie kroki przy użyciu funkcji TOM. Jeśli chcesz użyć tego przykładu w następujący sposób, musisz mieć kopię bazy danych AdventureWorksDW i zaimportować tabelę FactInternetSales do modelu. W przykładzie kodu przyjęto założenie, że parametry RangeStart oraz funkcja RangeEnd i DateKey nie istnieją w modelu. Wystarczy zaimportować tabelę FactInternetSales i opublikować model w obszarze roboczym w usłudze Power BI Premium. Następnie zaktualizuj element workspaceUrl , aby przykładowy kod mógł nawiązać połączenie z modelem. Zaktualizuj więcej wierszy kodu w razie potrzeby.

using System;
using TOM = Microsoft.AnalysisServices.Tabular;
namespace Hybrid_Tables
{
    class Program
    {
        static string workspaceUrl = "<Enter your Workspace URL here>";
        static string databaseName = "AdventureWorks";
        static string tableName = "FactInternetSales";
        static void Main(string[] args)
        {
            using (var server = new TOM.Server())
            {
                // Connect to the dataset.
                server.Connect(workspaceUrl);
                TOM.Database database = server.Databases.FindByName(databaseName);
                if (database == null)
                {
                    throw new ApplicationException("Database cannot be found!");
                }
                if(database.CompatibilityLevel < 1565)
                {
                    database.CompatibilityLevel = 1565;
                    database.Update();
                }
                TOM.Model model = database.Model;
                // Add RangeStart, RangeEnd, and DateKey function.
                model.Expressions.Add(new TOM.NamedExpression {
                    Name = "RangeStart",
                    Kind = TOM.ExpressionKind.M,
                    Expression = "#datetime(2021, 12, 30, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
                });
                model.Expressions.Add(new TOM.NamedExpression
                {
                    Name = "RangeEnd",
                    Kind = TOM.ExpressionKind.M,
                    Expression = "#datetime(2021, 12, 31, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
                });
                model.Expressions.Add(new TOM.NamedExpression
                {
                    Name = "DateKey",
                    Kind = TOM.ExpressionKind.M,
                    Expression =
                        "let\n" +
                        "    Source = (x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)\n" +
                        "in\n" +
                        "    Source"
                });
                // Apply a RefreshPolicy with Real-Time to the target table.
                TOM.Table salesTable = model.Tables[tableName];
                TOM.RefreshPolicy hybridPolicy = new TOM.BasicRefreshPolicy
                {
                    Mode = TOM.RefreshPolicyMode.Hybrid,
                    IncrementalPeriodsOffset = -1,
                    RollingWindowPeriods = 1,
                    RollingWindowGranularity = TOM.RefreshGranularityType.Year,
                    IncrementalPeriods = 1,
                    IncrementalGranularity = TOM.RefreshGranularityType.Day,
                    SourceExpression =
                        "let\n" +
                        "    Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW\"),\n" +
                        "    dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],\n" +
                        "    #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= DateKey(RangeStart) and [OrderDateKey] < DateKey(RangeEnd))\n" +
                        "in\n" +
                        "    #\"Filtered Rows\""
                };
                salesTable.RefreshPolicy = hybridPolicy;
                model.RequestRefresh(TOM.RefreshType.Full);
                model.SaveChanges();
            }
            Console.WriteLine("{0}{1}", Environment.NewLine, "Press [Enter] to exit...");
            Console.ReadLine();
        }
    }
}

Treści powiązane

• Konfigurowanie odświeżania przyrostowego i danych w czasie rzeczywistym
• Rozwiązywanie problemów z odświeżaniem przyrostowym i danymi w czasie rzeczywistym
• Ulepszone odświeżanie przy użyciu interfejsu API REST usługi Power BI
• Partycje w modelach tabelarycznych
• Narzędzia zewnętrzne w programie Power BI Desktop
• Konfigurowanie zaplanowanego odświeżania