Przewodnik po decyzjach dotyczących usługi Microsoft Fabric: działanie kopiowania, przepływ danych lub platforma Spark
Skorzystaj z tego przewodnika referencyjnego i przykładowych scenariuszy, aby ułatwić podjęcie decyzji, czy potrzebujesz działania kopiowania, przepływu danych lub platformy Spark dla obciążeń usługi Microsoft Fabric.
działanie Kopiuj, przepływ danych i właściwości platformy Spark
| Działanie kopiowania potoku | Przepływ danych Gen 2 | Spark | |
|---|---|---|---|
| Przypadek użycia | Migracja usługi Data Lake i magazynu danych, pozyskiwanie danych, uproszczone przekształcanie |
Pozyskiwanie danych, przekształcanie danych, uzdatnianie danych, profilowanie danych |
Pozyskiwanie danych, przekształcanie danych, przetwarzanie danych, profilowanie danych |
| Podstawowa osoba dewelopera | Inżynier danych, integrator danych |
Inżynier danych, integrator danych, analityk biznesowy |
Inżynier danych, analityk danych, deweloper danych |
| Podstawowy zestaw umiejętności deweloperów | ETL SQL JSON |
ETL M SQL |
Spark (Scala, Python, Spark SQL, R) |
| Napisany kod | Brak kodu, niski kod |
Brak kodu, niski kod |
Kod |
| Wolumin danych | Od niskiej po wysoką | Od niskiej po wysoką | Od niskiej po wysoką |
| Interfejs programowania | Kreatora Płótnie |
Power Query | Notebook Definicja zadania platformy Spark |
| Źródeł | 30+ łączniki | 150+ łączniki | Setki bibliotek platformy Spark |
| Miejsc | 18+ łączniki | Lakehouse Azure SQL Database, Azure Data Explorer, Analiza usługi Azure Synapse |
Setki bibliotek platformy Spark |
| Złożoność przekształcania | Niski: lightweight — konwersja typów, mapowanie kolumn, scalanie/dzielenie plików, spłaszczanie hierarchii |
Niski do wysoki: Funkcje przekształcania w wersji 300+ |
Niski do wysoki: obsługa natywnych bibliotek Spark i open source |
Zapoznaj się z następującymi trzema scenariuszami, aby uzyskać pomoc dotyczącą wybierania sposobu pracy z danymi w usłudze Fabric.
Scenariusz 1
Leo, inżynier danych, musi pozyskiwać dużą ilość danych z systemów zewnętrznych, zarówno lokalnych, jak i w chmurze. Te systemy zewnętrzne obejmują bazy danych, systemy plików i interfejsy API. Leo nie chce pisać i obsługiwać kodu dla każdego łącznika ani operacji przenoszenia danych. Chce postępować zgodnie z najlepszymi rozwiązaniami medalonu, z brązowym, srebrnym i złotym. Leo nie ma doświadczenia z platformą Spark, więc preferuje jak najwięcej przeciągania i upuszczania interfejsu użytkownika przy minimalnym kodowaniu. Chce również przetwarzać dane zgodnie z harmonogramem.
Pierwszym krokiem jest pobranie danych pierwotnych do magazynu lakehouse warstwy brązowej z zasobów danych platformy Azure i różnych źródeł innych firm (takich jak Snowflake Web, REST, AWS S3, GCS itp.). Chce skonsolidowanego magazynu typu lakehouse, tak aby wszystkie dane z różnych źródeł biznesowych, lokalnych i w chmurze znajdowały się w jednym miejscu. Leo przegląda opcje i wybiera działanie kopiowania potoku jako odpowiedni wybór dla jego nieprzetworzonej kopii binarnej. Ten wzorzec dotyczy zarówno odświeżania danych historycznych, jak i przyrostowych. Dzięki działaniu kopiowania Leo może załadować dane Gold do magazynu danych bez kodu, jeśli wystąpi taka potrzeba, a potoki zapewniają pozyskiwanie danych o dużej skali, które mogą przenosić dane w skali petabajtów. działanie Kopiuj to najlepszy niski kod i brak wyboru kodu, aby przenieść petabajty danych do magazynów i magazynów z różnych źródeł, ad hoc lub zgodnie z harmonogramem.
Scenariusz 2
Mary jest inżynierem danych z głęboką wiedzą na temat wielu wymagań raportowania analitycznego LOB. Zespół nadrzędny pomyślnie zaimplementował rozwiązanie do migrowania danych historycznych i przyrostowych wielu loB do wspólnej usługi lakehouse. Mary ma za zadanie oczyścić dane, zastosować logikę biznesową i załadować je do wielu miejsc docelowych (takich jak Azure SQL DB, ADX i lakehouse) w ramach przygotowań do odpowiednich zespołów raportowania.
Mary jest doświadczonym użytkownikiem dodatku Power Query, a ilość danych znajduje się w niskim do średnim zakresie, aby osiągnąć żądaną wydajność. Przepływy danych zapewniają interfejsy bez kodu lub niskiego poziomu kodu do pozyskiwania danych z setek źródeł danych. Dzięki przepływom danych można przekształcać dane przy użyciu opcji przekształcania danych w wersji 300+ i zapisywać wyniki w wielu miejscach docelowych z łatwym w użyciu, wysoce wizualnym interfejsem użytkownika. Mary przegląda opcje i decyduje, że warto użyć przepływu danych Gen 2 jako preferowanej opcji transformacji.
Scenariusz3
Adam jest inżynierem danych pracującym w dużej firmie zajmującej się sprzedażą detaliczną, która korzysta z usługi Lakehouse do przechowywania i analizowania danych klientów. W ramach swojej pracy Adam jest odpowiedzialny za tworzenie i konserwowanie potoków danych, które wyodrębniają, przekształcają i ładują dane do magazynu typu lakehouse. Jednym z wymagań biznesowych firmy jest przeprowadzenie analizy przeglądu klientów w celu uzyskania wglądu w środowiska klientów i ulepszania ich usług.
Adam decyduje, że najlepszym rozwiązaniem jest użycie platformy Spark do utworzenia logiki wyodrębniania i przekształcania. Platforma Spark udostępnia rozproszoną platformę obliczeniową, która może przetwarzać duże ilości danych równolegle. Pisze aplikację Platformy Spark przy użyciu języka Python lub Scala, która odczytuje ustrukturyzowane, częściowo ustrukturyzowane i nieustrukturyzowane dane z usługi OneLake na potrzeby przeglądów i opinii klientów. Aplikacja oczyszcza, przekształca i zapisuje dane w tabelach delta w lakehouse. Dane są następnie gotowe do użycia na potrzeby analizy podrzędnej.