Często zadawane pytania dotyczące narzędzi do zarządzania cyklem życia Fabric

Zarządzanie cyklem życia ma dwie części, integrację i wdrażanie. Aby zrozumieć, czym jest integracja w Fabric, zapoznaj się z Omówieniem integracji z Git. Aby dowiedzieć się, jakie potoki wdrażania znajdują się w Fabric, zapoznaj się z omówieniem potoków wdrażania .

Aby uzyskać krótkie wyjaśnienie integracji z Git, zobacz Omówienie integracji z Git. Wieloliniowa lub sformatowana odpowiedź na pytanie. Użyj dowolnego formatowania Markdown, pod warunkiem, że zachowasz wcięcie w wierszach po znakach |.

Aby uzyskać krótkie wyjaśnienie potoków wdrażania, zobacz omówienie potoków wdrażania.

Aby uzyskać informacje na temat licencji, zobacz Fabric licenses.

Wszystkie obszary robocze muszą być przypisane do licencji Fabric. Można jednak używać różnych typów pojemności dla różnych obszarów roboczych.

Aby uzyskać informacje na temat typów pojemności, zobacz Pojemność i SKU.

Model uprawnień potoków wdrażania opisano w sekcji uprawnień.

Aby skonfigurować reguły wdrażania w potokach wdrażania, musisz być właścicielem modelu semantycznego.

Jeśli pojemność obszaru roboczego znajduje się w jednej lokalizacji geograficznej, gdy repozytorium Azure DevOps znajduje się w innej lokalizacji, administrator Fabric może zdecydować, czy włączyć eksporty między lokalizacjami geograficznymi. Aby uzyskać więcej informacji, zobacz Użytkownicy mogą eksportować elementy do repozytoriów Git w innych lokalizacjach geograficznych.

Rozpocznij pracę nad integracją z pomocą Git, korzystając z instrukcji początkowych.

Może istnieć kilka powodów, dla których element został usunięty z obszaru roboczego.

• Jeśli element nie został zatwierdzony i wybrano go w akcji cofania, element zostanie usunięty z obszaru roboczego.
• Jeśli element został zatwierdzony, może zostać usunięty, jeśli przełączysz gałęzie, a element nie istnieje w nowej gałęzi.

Należy pamiętać o następujących kwestiach:

• Ograniczenia reguły wdrażania
• Obsługiwane źródła danych dla przepływów danych i reguł modelu semantycznego
• Odświeżanie przyrostowe
• Automatyzacja

Możesz przypisać jeden obszar roboczy do potoku i wdrożyć go we wszystkich etapach potoku, lub przypisać inny obszar roboczy do każdego etapu potoku. Aby uzyskać więcej informacji, zobacz przypisywanie obszaru roboczego do potoku wdrażania.

Zestawy danych wykorzystujące tryb łączności DirectQuery lub tryb złożony i posiadające tabele zmienności lub automatycznej daty/godziny nie są obsługiwane w potokach wdrażania. Jeśli wdrożenie zakończy się niepowodzeniem i uważasz, że przyczyną jest zestaw danych zawierający tabelę wariantów, możesz wyszukać właściwość wariantów w kolumnach tej tabeli. Możesz użyć jednej z następujących metod, aby edytować model semantyczny, aby działał w potokach wdrażania.

• W zestawie danych, zamiast używać trybu DirectQuery lub trybu złożonego, użyj trybu importu .

• Usuń tabele automatycznej daty/godziny z modelu semantycznego. W razie potrzeby usuń pozostałe odmiany ze wszystkich kolumn w tabelach. Usunięcie odmiany może unieważnić miary utworzone przez użytkownika, kolumny obliczeniowe i tabele obliczeniowe. Użyj tej metody tylko wtedy, gdy rozumiesz, jak działa model semantyczny, ponieważ może to spowodować uszkodzenie danych w wizualizacjach.

Po przypięciu kafelka do pulpitu nawigacyjnego, jeśli kafelek opiera się na nieobsługiwanym elemencie (żaden element nie na tej liście jest nieobsługiwany) lub na elemencie, który nie ma uprawnień do wdrożenia, po wdrożeniu pulpitu nawigacyjnego kafelek nie jest renderowany. Jeśli na przykład utworzysz kafelek na podstawie raportu, który opiera się na modelu semantycznym, na którym nie jesteś administratorem, podczas wdrażania raportu zostanie wyświetlone ostrzeżenie o błędzie. Podczas wdrażania pulpitu nawigacyjnego z kafelkiem, nie zostanie wyświetlony żaden komunikat o błędzie – wdrożenie zakończy się pomyślnie, ale kafelek nie będzie wyświetlać żadnych informacji.

Krótkie wyjaśnienie planów wdrożenia można znaleźć w przeglądzie planu rozmieszczenia.

Typ elementu planu wdrożenia pojawia się dopiero wtedy, gdy administrator Fabric włączy ustawienie dzierżawy. W portalu administratora w obszarze Ustawienia dzierżawy>Microsoft Fabric włącz opcję Użytkownicy mogą tworzyć elementy planu wdrożenia (wersja zapoznawcza), ustaw Zastosuj do całej organizacji lub grupy zabezpieczeń, a następnie wybierz Zastosuj.

Dopóki to ustawienie nie zostanie włączone, typ przedmiotu pozostaje ukryty w każdej przestrzeni roboczej.

Wdrożenie powraca do swojego domyślnego zachowania. Elementy są wdrażane bez zadeklarowanego rozkazu oraz bez akcji przed lub po wdrożeniu. Każda zależność chroniona przez plan, na przykład widok magazynu danych, który odczytuje tabelę w lakehouse zasilaną przez notes, ponownie przestaje działać.

Prawidłowo uporządkowany plan wdraża metadane elementów w kolejności, w jakiej je zadeklarowano, ale wdrożenie lakehouse’a nie powoduje wstawienia wierszy do jego tabel. Widok magazynowy, który odczytuje tabelę lakehouse, nie wiąże się, chyba że notatnik lub potok danych najpierw wygenerował tę tabelę. Dodaj akcję po rozmieszczeniu między domkiem nad jeziorem a magazynem, który produkuje stół. Akcja raportuje zakończenie w momencie zakończenia działania, a nie gdy usługi, które zasila, nadrobią zaległości, więc umieść wszelką kontrolę gotowości w ostatniej komórce notatnika lub ostatniej aktywności potoku danych. Przykładem jest zobaczenie przykładów planów wdrożenia.

Domyślne pole lakehouse w notatniku zawiera identyfikatory wskazujące na konkretny domek nad jeziorem w określonym obszarze pracy. Gdy notatnik trafi do nowego obszaru roboczego za pośrednictwem Git, te identyfikatory nadal mogą wskazywać na oryginalny obszar roboczy. Ustaw domyślny lakehouse dla środowiska docelowego w ustawieniach notesu przed uruchomieniem albo pozwól notesowi ustalić w czasie wykonywania, którego lakehouse’a użyć. Aby uzyskać więcej informacji, zobacz Notes source control and deployment (Kontrola źródła notesu i wdrażanie).

Dane wyjściowe uruchomienia są widoczne z poziomu wdrożenia w portalu. Uruchomienia akcji prowadzą do historii uruchomień elementu źródłowego, gdzie dostępne są dzienniki i szczegóły kroków.

Nieudane wdrożenie nie cofa ukończonych wdrożeń przedmiotów ani zmian wprowadzonych przez działania. Wskazówki dotyczące odzyskiwania można znaleźć w artykule Wdrażanie zostało zatrzymane w trakcie.

Nie bezpośrednio. Uruchom Update from Git z poziomu zewnętrznego harmonogramu, takiego jak Azure Pipelines lub GitHub Actions, a dołączony plan zostanie uruchomiony jako część tego wdrożenia.

Tak, jeśli potok realizuje wdrożenie za pomocą interfejsu API usługi Fabric, który obsługuje dołączanie planu, na przykład interfejsu Git sync API, interfejsu API wdrażania potoków wdrożeniowych lub interfejsu API importu wsadowego. Wdrożenie prowadzone przez Fabric CLI, dostawcę Terraform dla Fabric lub bibliotekę Python fabric-cicd nie może dołączyć planu.

No. Plan określa elementy wdrożenia oraz działania wykonywane wokół nich. Konfiguracja na poziomie przestrzeni roboczej nie jest częścią wdrożenia, więc ustawienia takie jak tożsamość przestrzeni roboczej, ustawienia Spark czy połączenie z Gitem nie są tworzone ani aktualizowane przez plan.

Skonfiguruj je w docelowej przestrzeni roboczej przed wdrożeniem. Element zależny od konfiguracji na poziomie przestrzeni roboczej, taki jak notes uwierzytelniający się przy użyciu tożsamości przestrzeni roboczej, ulega awarii w czasie wykonywania, jeśli docelowa przestrzeń robocza nie jest skonfigurowana w taki sam sposób jak źródłowa.

No. Plan wdrożenia opiera się na standardowym modelu Fabric workspace. Aby uzyskać więcej informacji, zobacz uprawnienia planu wdrażania.

Właściciel wdrożonego raportu podzielonego na strony jest użytkownikiem, który wdrożył raport. Podczas wdrażania raportu podzielonego na strony po raz pierwszy stajesz się właścicielem raportu.

Jeśli wdrażasz raport podzielony na strony na etapie, który zawiera już kopię tego raportu podzielonego na strony, zastępujesz poprzedni raport i stajesz się jego właścicielem zamiast poprzedniego właściciela. W takich przypadkach potrzebne są poświadczenia do bazowego źródła danych, aby dane mogły być używane w raporcie podzielonym na strony.

Podraporty raportów podzielonych na strony są przechowywane w tym samym folderze, który zawiera raport podzielony na strony. Aby uniknąć problemów z renderowaniem, gdy używasz selektywnej kopii do kopiowania raportu podzielonego na strony z podraportami, wybierz zarówno raport nadrzędny, jak i podraporty.

Reguły raportów podzielonych na strony można utworzyć, jeśli chcesz wskazać raport podzielony na strony do modelu semantycznego na tym samym etapie. Podczas tworzenia reguły wdrażania dla raportu podzielonego na strony należy wybrać bazę danych i serwer.

Jeśli ustawiasz regułę wdrażania dla raportu podzielonego na strony, który nie ma Fabric modelu semantycznego, ponieważ docelowe źródło danych jest zewnętrzne, musisz określić zarówno serwer, jak i bazę danych.

Jednak stronicowane raporty korzystające z modelu semantycznego Fabric używają wewnętrznego modelu semantycznego. W takich przypadkach nie można polegać na nazwie źródła danych, aby zidentyfikować model semantyczny Fabric, do którego nawiązujesz połączenie. Nazwa źródła danych nie zmienia się podczas jego aktualizacji w etapie docelowym, ani poprzez utworzenie reguły źródła danych, ani przez wywołanie interfejsu API aktualizacji źródła danych. Po ustawieniu reguły wdrażania należy zachować format bazy danych i zastąpić identyfikator obiektu modelu semantycznego w polu bazy danych. Ponieważ model semantyczny jest wewnętrzny, serwer pozostaje taki sam.

• Database — format bazy danych raportu podzielonego na strony z modelem semantycznym Fabric jest sobe_wowvirtualserver-<dataset ID>. Na przykład sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63. Zastąp element <dataset ID> identyfikatorem zestawu danych. Identyfikator zestawu danych można uzyskać z adresu URL, wybierając identyfikator GUID, który następuje po datasets/ i przed następnym ukośnikiem.

  

• Serwer — serwer hostujący bazę danych. Zachowaj istniejący serwer w następujący sposób.

Po wdrożeniu, jeśli pobierzesz plik RDL raportu podzielonego na strony, może on nie zostać zaktualizowany do najnowszej wersji, którą można zobaczyć w usłudze Power BI.

Jeśli masz przepływ danych zawierający modele semantyczne skonfigurowane przy użyciu odświeżania przyrostowego, zasady odświeżania nie są kopiowane ani zastępowane podczas wdrażania. Po wdrożeniu przepływu danych zawierającego model semantyczny z odświeżaniem przyrostowym na etapie, który nie obejmuje tego przepływu danych, jeśli masz zasady odświeżania, musisz ponownie skonfigurować go na etapie docelowym. Jeśli wdrażasz przepływ danych z odświeżaniem przyrostowym na etapie, w którym już się znajduje, zasady odświeżania przyrostowego nie zostaną skopiowane. W takich przypadkach, jeśli chcesz zaktualizować politykę odświeżania w docelowym etapie, musisz to zrobić ręcznie.

Powiązana zawartość

• Wprowadzenie do integracji z usługą Git
• Rozpocznij korzystanie z potoków wdrażania