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 kopiowania, przepływ danych i właściwości platformy Spark
Działanie Kopiowania Potoku | Dataflow Gen 2 | iskra | |
---|---|---|---|
Przypadek użycia | Migracja usługi Data Lake i magazynu danych, pozyskiwanie danych, lekkie przekształcanie |
Pozyskiwanie danych, przekształcanie danych, porządkowanie 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, programista danych |
podstawowy zestaw umiejętności deweloperów | ETL, SQL JSON |
ETL, M, SQL |
Spark (Scala, Python, Spark SQL, R) |
kod napisany | Brak kodu, niski kod |
Brak kodu, niski kod |
Kod |
objętość danych | Od niskiego do wysokiego | od niskiego do wysokiego | Od najniższego do najwyższego |
interfejs rozwojowy | Czarodziej płótno |
Power Query | Notatnik Definicja zadania platformy Spark |
źródeł | 30+ łączniki | 150+ łączniki | Setki bibliotek platformy Spark |
Miejsca docelowe | 18+ łączniki | Lakehouse, Azure SQL Database Azure Data Explorer, Analiza usługi Azure Synapse |
Setki bibliotek platformy Spark |
złożoność transformacji | Niski: lightweight — konwersja typów, mapowanie kolumn, scalanie/dzielenie plików, spłaszczanie hierarchii |
Od niskiego do wysokiego Ponad 300 funkcji przekształcania |
Od najniższego do najwyższego 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.
Scenariusz1
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 przestrzegać najlepszych praktyk dotyczących warstw medalu: brązowej, srebrnej i złotej. 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 surowych danych do jeziora "lakehouse" warstwy brązowej z zasobów danych platformy Azure oraz 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 funkcji kopiowania Leo może załadować dane Gold do magazynu danych bez potrzeby programowania, jeśli zajdzie taka konieczność, a potoki zapewniają pozyskiwanie danych na dużą skalę, które umożliwia transfer danych na poziomie petabajtów. Działanie kopiowania to najlepszy wybór bezkodowy i niskokodowy do przenoszenia petabajtów danych do jezior danych i hurtowni danych z różnorodnych źródeł, zarówno ad hoc, jak i 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 ponad 300 opcji przekształcania danych i zapisywać wyniki w wielu miejscach docelowych z łatwym w użyciu i bardzo wizualnym interfejsem użytkownika. Mary przegląda opcje i decyduje, że warto użyć Dataflow 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 opinii klientów w celu uzyskania wglądu w ich doświadczenia oraz poprawy świadczonych usług.
Adam decyduje, że najlepszym rozwiązaniem jest użycie 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.