Udostępnij przez


Wykorzystanie bazy danych SQL w odwrotnym ETL

Dotyczy:Baza danych SQL w usłudze Microsoft Fabric

W tym artykule opisano sposób używania bazy danych SQL w systemie Fabric jako docelowego systemu odwrotnego ETL w infrastrukturze danych opartej na Fabric. Zawiera wskazówki dotyczące architektury, wzorce operacyjne i zagadnienia dotyczące implementacji dotyczące przenoszenia wyselekcjonowanych danych ze źródeł analitycznych (takich jak Magazyn danych usługi Microsoft Fabric lub Fabric Lakehouse) do bazy danych SQL w usłudze Fabric na potrzeby użycia operacyjnego przez aplikacje, interfejsy API i środowiska czasu rzeczywistego.

Co to jest reverse ETL w Fabric?

Wielu klientów zainwestowało dużo czasu i wysiłku w tworzenie procesów wyodrębniania, przekształcania, ładowania (ETL) w celu przekształcania pierwotnych danych operacyjnych w bardziej wyrafinowane dane analityczne, które mogą być używane do raportowania biznesowego. Końcowym wynikiem procesu ETL jest zazwyczaj magazyn analityczny, taki jak magazyn lub magazyn typu lakehouse, do którego uzyskuje dostęp warstwa raportowania, taka jak usługa Power BI. Ta architektura dobrze obsługuje użytkowników biznesowych, ale raportowanie jest stosunkowo statyczne i szczegółowe informacje mogą być uzyskiwane tylko przez interwencję człowieka. Korzystając z odwrotnego etL, można podawać przekształcone dane z powrotem do systemów operacyjnych, dzięki czemu aplikacje i agenci mogą uzyskiwać szczegółowe informacje na podstawie tych analizowanych danych w czasie rzeczywistym. Funkcja Reverse ETL wypycha dane z faktów i wymiarów w magazynach analitycznych do warstwy obsługującej, do której można uzyskać dostęp za pośrednictwem punktów końcowych, takich jak GraphQL lub bezpośrednio za pośrednictwem zapytań TDS (tabelarycznego strumienia danych).

Aplikacje operacyjne można łączyć bezpośrednio z magazynem danych lub lakehouse, ale te magazyny danych są przeznaczone dla obciążeń analitycznych. Operacyjne magazyny danych, takie jak baza danych SQL w sieci szkieletowej, są przeznaczone do obsługi zapytań transakcyjnych i zapewniają lepszą wydajność i skalowalność obciążeń operacyjnych. Operacyjne bazy danych umożliwiają również dalsze wzbogacanie danych przy użyciu osadzeń wektorów i dodatkowych metadanych w celu ułatwienia wyszukiwania wektorowego i hybrydowego, a także pobierania rozszerzonej generacji (RAG).

  • W tym wzorze magazyn lub lakehouse pozostaje systemem referencyjnym analityki.
  • Baza danych SQL w sieci szkieletowej służy jako magazyn operacyjny, który oferuje małe opóźnienia, wyrafinowane indeksowanie, ścisłe ograniczenia danych i relacji oraz umowy SLA oczekiwane przez zespoły aplikacji.

Typowe odwrotne cele ETL

Typowe odwrotne cele ETL zazwyczaj reprezentują wyselekcjonowane wycinki danych o wysokiej wartości, które systemy operacyjne mogą przetwarzać z minimalną transformacją. Te cele zostały zaprojektowane tak, aby zapewnić dostęp o małych opóźnieniach do zaufanych danych przy zachowaniu logiki biznesowej stosowanej w warstwie analitycznej. Oto kilka przykładów:

  • Dane klientów i użytkowników (na przykład metryki zaangażowania, takie jak aktywność sesji, użycie funkcji i interakcje)
  • Dane dotyczące sprzedaży i marketingu (na przykład metryki oceniania, takie jak skłonność do zakupu, oceny zakontraktowania, prawdopodobieństwo konwersji)
  • Dane operacyjne i transakcyjne (na przykład dane dotyczące zamówień i zapasów, takie jak poziomy zapasów, stan zamówienia i czas dostawy)
  • Dane pochodne sztucznej inteligencji/uczenia maszynowego (na przykład spersonalizowane rekomendacje dotyczące produktów, oceny predykcyjne, takie jak ryzyko rezygnacji, skłonność do zakupu dodatkowego produktu, czy analiza sentymentu)

Mechanizmy przenoszenia danych

Proces rozpoczyna się od zdefiniowania danych źródłowych, ustawienia miejsca docelowego, a następnie wybrania mechanizmu przenoszenia danych. Wybierz jeden lub więcej z poniższych mechanizmów, aby przenieść dane z magazynu analitycznego do bazy danych SQL w Fabric.

Wskazówka

W zasadzie należy użyć:

  • Potoki dla prostych kopii i zaplanowanych obciążeń.
  • Przepływy danych Gen2 w przypadku przekształceń z małą ilością kodu.
  • Platforma Spark umożliwia przetwarzanie złożone i na dużą skalę (w tym uczenie maszynowe).
  • Krzyżowe operacje z użyciem T-SQL, gdzie to możliwe, aby zachować operacje skoncentrowane na języku SQL, na przykład połączenie tabeli w bazie danych SQL z tabelą w magazynie danych lub punkcie końcowym analizy SQL.
Mechanizm Użyj, gdy Mocne strony Zagadnienia do rozważenia
Potoki danych Fabric Potrzebne są zarządzalne, powtarzalne procesy (wsadowe lub mikro-batchowe) kopiowania danych. Integracja klasy pierwszej; obsługuje znakowanie wodne i procedury przechowywane Współbieżność: skalowanie bazy danych SQL podczas ładowania
Przepływ danych Gen2 Potrzebne są przekształcenia danych z małą ilością kodu i rozszerzona logika procesu Przyjazne dla firmy; obsługuje kształtowanie i czyszczenie kolumn Niższa przepustowość dla dużych woluminów; partycjonowanie woluminów
Spark (notesy/zadania) Potrzebujesz złożonych przekształceń opartych na kodzie i zmieniania na dużą skalę Pełna kontrola kodu; wydajne odczyty funkcji Delta; Obsługa zapisu JDBC Uwierzytelnianie i grupowanie; unikanie dużych transakcji
Zapytania T-SQL między elementami Potrzebujesz przenoszenia SQL w bazie danych między elementami Fabric. Minimalna infrastruktura; SQL-native; łatwe do zaplanowania

Architektura referencyjna: reverse ETL do bazy danych SQL w Fabric

Architektura referencyjna odwrotnego ETL w Fabric łączy podstawowe komponenty wymagane do wdrożenia wyselekcjonowanych danych analitycznych. Pokazuje, jak dane przepływają z zaufanych źródeł analitycznych za pośrednictwem warstw przekształcania do ustrukturyzowanej bazy danych SQL. Operacyjna baza danych służy jako interfejs dla systemów podrzędnych. Ten wzorzec zapewnia, że aplikacje, interfejsy API i narzędzia do raportowania mogą uzyskiwać dostęp do danych o małych opóźnieniach i wysokiej jakości bez naruszania integralności systemu analitycznego rekordu.

Podstawowe składniki tego przepływu obejmują:

  • Źródło: wyselekcjonowane zestawy danych z usługi Fabric Data Warehouse lub Lakehouse (delta).
  • Przekształcenia: przekształcenia Reverse ETL stosowane przy użyciu Pipelines, Dataflow Gen2, Spark lub T-SQL dla wielu elementów.
  • Cel: baza danych SQL w Fabric ze zdefiniowanymi schematami docelowymi, historią (opcjonalnie), kwarantanną i serwowanymi schematami.
  • Użytkownicy: aplikacje poprzez GraphQL lub TDS, API i Power BI na potrzeby pulpitów nawigacyjnych i raportowania w czasie rzeczywistym.

Diagram przedstawiający architekturę referencyjną ETL typu reverse, z bazą danych SQL w Fabryce.

Components

Następujące składniki są zaangażowane w ogólny przepływ korzystania z bazy danych SQL w ramach Fabric jako docelowego obiektu ETL wstecz.

Serwowanie i docelowe schematy

  • Mapuj dane źródłowe na odpowiednie schematy docelowe w bazie danych SQL w Fabric.
  • Opcjonalnie zachowaj schemat pod kątem history audytowalności.
  • Użyj schematu quarantine do odrzucania (problemy z jakością danych).
  • Zdefiniuj serving schemat dla użycia podrzędnego z odpowiednimi ograniczeniami i indeksowaniem.

Orkiestracja

  • Zaplanuj transfery w Fabric przy użyciu potoków, przepływów danych lub zadań Spark.
  • Użyj wbudowanego planowania, aby skonfigurować cykl, czas rozpoczęcia i strefę czasową.
  • Harmonogramowanie notesów Spark za pośrednictwem portalu Fabric lub interfejsu API.
  • Monitorowanie pełnych przebiegów w centrum monitorowania sieci szkieletowej.

Zużycie

  • Uwidaczniaj dane za pośrednictwem punktów końcowych GraphQL lub języka T-SQL za pośrednictwem TDS przy użyciu bibliotek klienckich, takich jak ADO.NET (i inne).
  • Twórz pulpity nawigacyjne i wizualizacje usługi Power BI bezpośrednio za pośrednictwem bazy danych SQL w usłudze Fabric.

Nadzór i zabezpieczenia

  • Użyj identyfikatora Entra firmy Microsoft do uwierzytelniania i autoryzacji.
  • Łącz uprawnienia ról w obszarze roboczym Fabric i uprawnienia SQL dla uzyskania szczegółowej kontroli.
  • Opcjonalnie skonfiguruj klucze zarządzane przez klienta do szyfrowania danych magazynowanych.
  • Przeprowadź audyt dostępu i zabezpiecz dane w trakcie przesyłania przy użyciu usługi Private Link.

Obsługa aplikacji

Po zakończeniu kuracji i odświeżeniu danych w bazie danych SQL skoncentruj się na zapewnieniu szybkiego i niezawodnego dostępu dla operacyjnych użytkowników. W tym kontekście obsługa aplikacji oznacza uwidacznianie zaufanych zestawów danych za pomocą interfejsów o małych opóźnieniach, które są zgodne z nowoczesnymi wzorcami aplikacji.

Po wylądowaniu i odświeżeniu danych w bazie danych SQL w usłudze Fabric:

  • Aby obsługiwać obciążenia operacyjne, uwidaczniaj dane za pośrednictwem punktów końcowych GraphQL lub protokołu TDS , które mają być używane za pośrednictwem ADO.NET i innych bibliotek klienckich. Na przykład podaj informacje o produkcie, łańcuch dostaw lub przypadki użycia obsługi klienta.
  • Połącz zestaw danych z usługą Power BI, aby zapewniać pulpity nawigacyjne w czasie rzeczywistym i analizy samoobsługowe.

Zagadnienia specyficzne dla sieci szkieletowej

Baza danych SQL w Fabric używa tego samego silnika bazy danych SQL co Azure SQL Database i jest kontrolowana, zabezpieczona, rozliczana oraz obsługiwana za pośrednictwem portalu Fabric. Oferuje również wbudowane dublowanie plików delta/Parquet przechowywanych w usłudze Microsoft OneLake, do których można uzyskać dostęp za pośrednictwem punktu końcowego analizy SQL. Ponieważ znajduje się on w środowisku usługi Microsoft Fabric, podczas tworzenia projektu należy wziąć pod uwagę kilka zagadnień:

  • Parzystość funkcji: baza danych SQL w usłudze Fabric jest zbieżna z usługą Azure SQL Database. Zweryfikuj określone funkcje , których potrzebujesz, aby zapewnić odpowiednie rozwiązanie i monitorować aktualizacje planu działania.
  • Model zabezpieczeń: baza danych SQL w Fabric używa tylko uwierzytelniania Microsoft Entra ID. Zaplanuj tożsamości dla potoków, przepływów danych i zadań platformy Spark odpowiednio.
  • Replikacja: baza danych SQL w usłudze Fabric automatycznie replikuje dane w trybie tylko do odczytu do OneLake. Ta synchronizacja jest przydatna w przypadku potrzeb związanych z raportowaniem i analizą, podczas gdy baza danych pozostaje dostępna dla obciążeń operacyjnych odczytu/zapisu.