Przewodnik po decyzjach dotyczących usługi Microsoft Fabric: wybieranie magazynu danych
Skorzystaj z tego przewodnika referencyjnego i przykładowych scenariuszy, aby ułatwić wybór magazynu danych dla obciążeń usługi Microsoft Fabric.
Właściwości magazynu danych
Te informacje służą do porównywania magazynów danych usługi Fabric, takich jak magazyn, lakehouse, eventhouse, baza danych SQL i datamart usługi Power BI, na podstawie woluminu danych, typu, osoby dewelopera, zestawu umiejętności, operacji i innych możliwości. Te porównania są zorganizowane w następujące dwie tabele:
| Lakehouse | Magazyn | Eventhouse | |
|---|---|---|---|
| Wolumin danych | Nieograniczony | Nieograniczony | Nieograniczony |
| Typ danych | Niestrukturalnych częściowo ustrukturyzowane, Strukturalnych |
Dane ustrukturyzowane | Niestrukturalnych częściowo ustrukturyzowane, Strukturalnych |
| Podstawowa osoba dewelopera | Inżynier danych, analityk danych | Deweloper magazynu danych, architekt danych, deweloper bazy danych | Deweloper aplikacji, analityk danych, inżynier danych |
| Podstawowa umiejętność dewelopera | Spark (Scala, PySpark, Spark SQL, R) | SQL | Brak kodu, KQL, SQL |
| Dane uporządkowane według | Foldery i pliki, bazy danych i tabele | Bazy danych, schematy i tabele | Bazy danych, schematy i tabele |
| Operacje odczytu | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Operacje zapisu | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, ekosystem łącznika |
| Transakcje obejmujące wiele tabel | Nie. | Tak | Tak, w przypadku pozyskiwania wielu tabel |
| Podstawowy interfejs projektowy | Notesy platformy Spark, definicje zadań platformy Spark | Skrypty SQL | Zestaw zapytań KQL, baza danych KQL |
| Bezpieczeństwo | Zabezpieczenia na poziomie wiersza, CLS**, poziom tabeli (T-SQL), brak dla platformy Spark | Poziom obiektu, zabezpieczenia na poziomie wiersza, CLS, DDL/DML, dynamiczne maskowanie danych | Zabezpieczenia na poziomie wiersza |
| Uzyskiwanie dostępu do danych za pomocą skrótów | Tak | Tak | Tak |
| Może być źródłem skrótów | Tak (pliki i tabele) | Tak (tabele) | Tak |
| Wykonywanie zapytań między elementami | Tak | Tak | Tak |
| Analiza zaawansowana | Interfejs do przetwarzania danych na dużą skalę, wbudowanego równoległości danych i odporności na uszkodzenia | Interfejs do przetwarzania danych na dużą skalę, wbudowanego równoległości danych i odporności na uszkodzenia | Elementy natywne szeregów czasowych, pełne możliwości geoprzestrzeni i zapytań |
| Obsługa zaawansowanego formatowania | Tabele zdefiniowane przy użyciu formatu plików ZGODNEgo z programem PARQUET, CSV, AVRO, JSON i dowolnego formatu pliku zgodnego z usługą Apache Hive | Tabele zdefiniowane przy użyciu formatu plików ZGODNEgo z programem PARQUET, CSV, AVRO, JSON i dowolnego formatu pliku zgodnego z usługą Apache Hive | Pełne indeksowanie wolnych danych tekstowych i częściowo ustrukturyzowanych, takich jak JSON |
| Opóźnienie pozyskiwania | Dostępne natychmiast na potrzeby wykonywania zapytań | Dostępne natychmiast na potrzeby wykonywania zapytań | Pozyskiwanie w kolejce, pozyskiwanie przesyłania strumieniowego ma kilka sekund opóźnienia |
* Platforma Spark obsługuje odczytywanie z tabel przy użyciu skrótów, nie obsługuje jeszcze uzyskiwania dostępu do widoków, procedur składowanych, funkcji itp.
| Sieć szkieletowa SQL Database | Power BI Datamart | |
|---|---|---|
| Wolumin danych | 4 TB | Do 100 GB |
| Typ danych | Strukturalnych częściowo ustrukturyzowane, Niestrukturalnych |
Dane ustrukturyzowane |
| Podstawowa osoba dewelopera | Deweloper sztucznej inteligencji, deweloper aplikacji, deweloper bazy danych, administrator bazy danych | Analityk danych, analityk danych |
| Podstawowa umiejętność dewelopera | SQL | Brak kodu, SQL |
| Dane uporządkowane według | Bazy danych, schematy, tabele | Baza danych, tabele, zapytania |
| Operacje odczytu | T-SQL | Spark, T-SQL |
| Operacje zapisu | T-SQL | Przepływy danych, T-SQL |
| Transakcje obejmujące wiele tabel | Tak, pełna zgodność acid | Nie. |
| Podstawowy interfejs projektowy | Skrypty SQL | Power BI |
| Bezpieczeństwo | Poziom obiektu, zabezpieczenia na poziomie wiersza, CLS, DDL/DML, dynamiczne maskowanie danych | Wbudowany edytor zabezpieczeń na poziomie wiersza |
| Uzyskiwanie dostępu do danych za pomocą skrótów | Tak | Nie. |
| Może być źródłem skrótów | Tak (tabele) | Nie. |
| Wykonywanie zapytań między elementami | Tak | Nie. |
| Analiza zaawansowana | Funkcje analityczne języka T-SQL, dane replikowane do magazynu delta parquet w usłudze OneLake na potrzeby analizy | Interfejs do przetwarzania danych z automatycznym dostrajaniem wydajności |
| Obsługa zaawansowanego formatowania | Obsługa tabel OLTP, JSON, vector, graph, XML, spatial, key-value | Tabele zdefiniowane przy użyciu formatu plików ZGODNEgo z programem PARQUET, CSV, AVRO, JSON i dowolnego formatu pliku zgodnego z usługą Apache Hive |
| Opóźnienie pozyskiwania | Dostępne natychmiast na potrzeby wykonywania zapytań | Dostępne natychmiast na potrzeby wykonywania zapytań |
** Zabezpieczenia na poziomie kolumny dostępne w usłudze Lakehouse za pośrednictwem punktu końcowego analizy SQL przy użyciu języka T-SQL.
Scenariusze
Przejrzyj te scenariusze, aby uzyskać pomoc dotyczącą wybierania magazynu danych w sieci szkieletowej.
Scenariusz 1
Susan, profesjonalny deweloper, jest nowym deweloperem w usłudze Microsoft Fabric. Są one gotowe do rozpoczęcia czyszczenia, modelowania i analizowania danych, ale muszą zdecydować się na utworzenie magazynu danych lub magazynu lakehouse. Po zapoznaniu się ze szczegółami w poprzedniej tabeli główne punkty decyzyjne to dostępny zestaw umiejętności i potrzeba transakcji obejmujących wiele tabel.
Susan spędziła wiele lat na tworzeniu magazynów danych w aparatach relacyjnych baz danych i zna składnię i funkcjonalność języka SQL. Myśląc o większym zespole, głównymi konsumentami tych danych są również wykwalifikowanych w narzędziach analitycznych SQL i SQL. Susan decyduje się na użycie magazynu sieci szkieletowej, który umożliwia zespołowi interakcję przede wszystkim z językiem T-SQL, a także zezwalanie wszystkim użytkownikom platformy Spark w organizacji na dostęp do danych.
Susan tworzy nowy magazyn lakehouse i uzyskuje dostęp do możliwości magazynu danych za pomocą punktu końcowego analizy SQL lakehouse. Za pomocą portalu sieci szkieletowej tworzy skróty do tabel danych zewnętrznych i umieszcza je w folderze /Tables . Susan może teraz pisać zapytania T-SQL, które odwołują się do skrótów do wykonywania zapytań dotyczących danych usługi Delta Lake w lakehouse. Skróty są automatycznie wyświetlane jako tabele w punkcie końcowym analizy SQL i mogą być odpytywane przy użyciu języka T-SQL przy użyciu trzech części nazw.
Scenariusz 2
Rob, inżynier danych, musi przechowywać i modelować kilka terabajtów danych w sieci szkieletowej. Zespół ma mieszankę umiejętności PySpark i T-SQL. Większość zespołu uruchamiającego zapytania T-SQL jest konsumentami i dlatego nie musi pisać instrukcji INSERT, UPDATE ani DELETE. Pozostali deweloperzy dobrze pracują w notesach, a ponieważ dane są przechowywane w funkcji Delta, mogą wchodzić w interakcje z podobną składnią SQL.
Rob decyduje się na użycie usługi Lakehouse, która umożliwia zespołowi inżynierów danych wykorzystanie swoich zróżnicowanych umiejętności względem danych przy jednoczesnym umożliwieniu członkom zespołu, którzy są wysoko wykwalifikowanych w języku T-SQL do korzystania z danych.
Scenariusz 3
Ash, deweloper obywatel, jest deweloperem usługi Power BI. Znają one program Excel, usługę Power BI i pakiet Office. Muszą utworzyć produkt danych dla jednostki biznesowej. Wiedzą, że nie mają umiejętności tworzenia magazynu danych lub magazynu typu lakehouse, a ci wydają się zbyt wiele dla swoich potrzeb i woluminów danych. Zapoznają się ze szczegółami w poprzedniej tabeli i zobaczą, że główne punkty decyzyjne są ich własnymi umiejętnościami i potrzebą samoobsługi, brak możliwości kodu i ilości danych poniżej 100 GB.
Ash współpracuje z analitykami biznesowymi zaznajomionymi z usługami Power BI i Microsoft Office i wie, że mają już subskrypcję pojemności Premium. Gdy myślą o większym zespole, zdają sobie sprawę, że głównymi odbiorcami tych danych są analitycy, zaznajomieni z narzędziami analitycznymi bez kodu i sql. Ash decyduje się na użycie schematu danych usługi Power BI, który umożliwia zespołowi szybkie tworzenie możliwości przy użyciu środowiska bez kodu. Zapytania można wykonywać za pośrednictwem usług Power BI i T-SQL, a także zezwalać dowolnym użytkownikom platformy Spark w organizacji na dostęp do danych.
Scenariusz 4
Daisy jest analitykiem biznesowym doświadczonym w korzystaniu z usługi Power BI do analizowania wąskich gardeł łańcucha dostaw dla dużej globalnej sieci detalicznej. Muszą one utworzyć skalowalne rozwiązanie danych, które może obsługiwać miliardy wierszy danych i może służyć do tworzenia pulpitów nawigacyjnych i raportów, które mogą służyć do podejmowania decyzji biznesowych. Dane pochodzą z zakładów, dostawców, nadawców i innych źródeł w różnych formatach ustrukturyzowanych, częściowo ustrukturyzowanych i bez struktury.
Daisy decyduje się na użycie usługi Eventhouse ze względu na skalowalność, szybkie czasy odpowiedzi, zaawansowane możliwości analizy, w tym analizę szeregów czasowych, funkcje geoprzestrzenne i szybki tryb zapytań bezpośrednich w usłudze Power BI. Zapytania można wykonywać przy użyciu usług Power BI i KQL w celu porównania między bieżącymi i poprzednimi okresami, szybko zidentyfikować pojawiające się problemy lub zapewnić geoprzestrzenną analizę tras lądowych i morskich.
Scenariusz 5
Kirby to architekt aplikacji doświadczony w tworzeniu aplikacji platformy .NET na potrzeby danych operacyjnych. Potrzebują bazy danych o wysokiej współbieżności z pełną zgodnością transakcji ACID i silnie wymuszanymi kluczami obcymi na potrzeby integralności relacyjnej. Kirby chce korzystać z automatycznego dostrajania wydajności, aby uprościć codzienne zarządzanie bazami danych.
Kirby decyduje o bazie danych SQL w sieci szkieletowej z tym samym aparatem usługi SQL Database co usługa Azure SQL Database. Bazy danych SQL w sieci szkieletowej są automatycznie skalowane w celu zaspokojenia zapotrzebowania w ciągu dnia roboczego. Mają one pełną możliwość tabel transakcyjnych i elastyczność poziomów izolacji transakcji z możliwością serializacji do odczytu zatwierdzonej migawki. Baza danych SQL w usłudze Fabric automatycznie tworzy i odrzuca nieklastrowane indeksy na podstawie silnych sygnałów z planów wykonywania obserwowanych w czasie.
W scenariuszu kirby dane z aplikacji operacyjnej muszą być przyłączone do innych danych w usłudze Fabric: w usłudze Spark, w magazynie i z zdarzeń w czasie rzeczywistym w usłudze Eventhouse. Każda baza danych sieci szkieletowej zawiera punkt końcowy analizy SQL, więc dane, które mają być dostępne w czasie rzeczywistym z platformy Spark lub zapytań usługi Power BI przy użyciu trybu DirectLake. Te rozwiązania do raportowania oszczędzą podstawowej operacyjnej bazy danych przed obciążeniem obciążeń analitycznych i unikaj denormalizacji. Kirby ma również istniejące dane operacyjne w innych bazach danych SQL i musi importować te dane bez transformacji. Aby zaimportować istniejące dane operacyjne bez konwersji typu danych, kirby projektuje potoki danych z usługą Fabric Data Factory w celu zaimportowania danych do bazy danych SQL fabric.