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
Użyj tych informacji 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 wolumenu danych, typu, profilu dewelopera, umiejętności, operacji i innych funkcjonalności. Te porównania są zorganizowane w następujące dwie tabele:
| Tabela 1 z 2 | Lakehouse | magazyn | Eventhouse |
|---|---|---|---|
| objętość danych | Nieograniczony | Nieograniczony | Nieograniczony |
| typ danych | Niestrukturalny częściowo ustrukturyzowane, Uporządkowany |
Strukturalny częściowo ustrukturyzowane (JSON) |
Niestrukturalny półustrukturyzowane Ustrukturyzowany |
| podstawowa osoba dewelopera | Inżynier danych, analityk danych | Deweloper magazynu danych, architekt danych, inżynier danych, deweloper bazy danych | Deweloper aplikacji, analityk danych, inżynier danych |
| podstawowe umiejętności deweloperskie | Spark (Scala, PySpark, Spark SQL, R) | SQL | Brak kodu, KQL, SQL |
| dane zorganizowane przez | 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) | Język T-SQL | KQL, Spark, ekosystem łączników |
| Transakcje z wieloma tabelami | Nie | Tak | Tak, w przypadku zasilania wieloma tabelami |
| podstawowy interfejs programisty | Notesy platformy Spark, definicje zadań platformy Spark | Skrypty SQL | Zestaw zapytań KQL, baza danych KQL |
| Bezpieczeństwo | Zabezpieczenia na poziomie wiersza (RLS), CLS**, poziom tabeli (T-SQL), brak dla Spark | poziom obiektów, RLS (zabezpieczenia na poziomie wiersza), CLS, DDL/DML, dynamiczne maskowanie danych | Zabezpieczenia na poziomie wiersza |
| Dostęp do danych za pomocą skrótów | Tak | Tak, za pośrednictwem punktu końcowego analizy SQL | Tak |
| może być źródłem skrótów | Tak (pliki i tabele) | Tak (tabele) | Tak |
| Zapytanie między elementami | Tak | Tak | Tak |
| Zaawansowana analityka | Interfejs do przetwarzania danych na dużą skalę, wbudowaną równoległość danych i tolerancję błędów | Interfejs do przetwarzania danych na dużą skalę, wbudowanego równoległego przetwarzania danych i odporności na uszkodzenia | Elementy natywne szeregów czasowych, pełne możliwości geoprzestrzeni i zapytań |
| Obsługa formatowania zaawansowanego | Tabele zdefiniowane przy użyciu formatu plików takich jak PARQUET, CSV, AVRO, JSON oraz dowolnego formatu pliku zgodnego z Apache Hive. | Tabele zdefiniowane przy użyciu formatów plików takich jak PARQUET, CSV, AVRO, JSON i dowolnego formatu pliku zgodnego z platformą Apache Hive | Pełne indeksowanie wolnych danych tekstowych i częściowo ustrukturyzowanych, takich jak JSON |
| opóźnienie ingestii | Dostępne natychmiast na potrzeby wykonywania zapytań | Dostępne natychmiast na potrzeby wykonywania zapytań | Kolejkowane pobieranie i pobieranie strumieniowe mają kilkusekundowe opóźnienie. |
* 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.
| Tabela 2 z 2 | Fabric baza danych SQL | Datamart Power BI |
|---|---|---|
| objętość danych | 4 terabajty | Do 100 GB |
| Typ danych | Strukturalnych częściowo ustrukturyzowane, Niestrukturalny |
Ustrukturyzowany |
| podstawowa osoba dewelopera | Deweloper sztucznej inteligencji, deweloper aplikacji, deweloper bazy danych, administrator bazy danych | Naukowiec danych, analityk danych |
| podstawowe umiejętności deweloperskie | SQL | Brak kodu, SQL |
| dane zorganizowane przez | Bazy danych, schematy, tabele | Baza danych, tabele, zapytania |
| operacje odczytu | Język T-SQL | Spark, T-SQL |
| operacje zapisu | Język T-SQL | Przepływy danych, T-SQL |
| Transakcje z wieloma tabelami | Tak, pełna zgodność ACID | Nie |
| podstawowy interfejs programisty | Skrypty SQL | Power BI |
| Bezpieczeństwo | Poziom obiektu, zabezpieczenia na poziomie wiersza, CLS, DDL/DML, dynamiczne maskowanie danych | Wbudowany edytor RLS |
| Dostęp do danych za pomocą skrótów | Tak | Nie |
| może być źródłem skrótów | Tak (tabele) | Nie |
| Zapytanie między elementami | Tak | Nie |
| Zaawansowana analityka | Funkcje analityczne T-SQL, dane replikowane do formatu parquet delta w OneLake na potrzeby analiz. | Interfejs do przetwarzania danych z automatycznym dostrajaniem wydajności |
| Obsługa formatowania zaawansowanego | Obsługa tabel OLTP, JSON, vector, graph, XML, spatial, key-value | Tabele zdefiniowane przy użyciu formatów plików PARQUET, CSV, AVRO, JSON i dowolnego formatu pliku zgodnego z Apache Hive |
| opóźnienie przetwarzania | 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.
Scenariuszy
Przejrzyj te scenariusze, aby uzyskać pomoc w wyborze magazynu danych w Fabric.
Scenariusz 1
Susan, profesjonalny deweloper, jest nowym deweloperem w usłudze Microsoft Fabric. Są gotowi do rozpoczęcia czyszczenia, modelowania i analizowania danych, ale muszą zdecydować, czy zbudować magazyn danych czy jeziorodom danych (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 budowaniu magazynów danych na silnikach relacyjnych baz danych i zna składnię oraz funkcjonalność języka SQL. Myśląc o większym zespole, główni konsumenci tych danych są również wykwalifikowani w SQL i narzędziach analitycznych SQL. Susan decyduje się na użycie magazynu usługi Fabric, co pozwala zespołowi na interakcję głównie z językiem T-SQL, a także umożliwia wszystkim użytkownikom usługi Spark w organizacji dostęp do danych.
Susan tworzy nowy magazyn danych i współdziała z nim przy użyciu języka T-SQL, podobnie jak w przypadku innych baz danych programu SQL Server. Większość istniejącego kodu T-SQL, który napisała, aby skompilować swój magazyn w programie SQL Server, będzie działać w magazynie danych usługi Fabric, co ułatwia przejście. Jeśli zdecyduje się, może nawet używać tych samych narzędzi, które współpracują ze swoimi innymi bazami danych, takimi jak SQL Server Management Studio. Korzystając z edytora SQL w portalu Fabric, Susan i inni członkowie zespołu piszą zapytania analityczne odwołujące się do innych magazynów danych i tabel delty w lakehouse'ach, po prostu używając nazw trójczłonowych do wykonywania zapytań międzybazodanowych.
Scenariusz 2
Rob, inżynier danych, musi przechowywać i modelować kilka terabajtów danych w Fabric. 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 lakehouse, co pozwala zespołowi inżynierów danych na korzystanie z różnych umiejętności przy pracy z danymi, umożliwiając jednocześnie członkom zespołu, którzy są wysoko wykwalifikowani w języku T-SQL, korzystanie z danych.
Scenariusz 3
Ash, deweloper obywatelski, 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 danych typu lakehouse, a te wydają się być zbyt zaawansowane dla ich potrzeb i objętości danych. Zapoznają się ze szczegółami w poprzedniej tabeli i zobaczą, że główne punkty decyzyjne to ich własne umiejętności, potrzeba możliwości samoobsługi, obsługi bez kodowania oraz wolumenu 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 niewymagającymi kodowania i SQL. Ash decyduje się na użycie datamartu Power BI , co umożliwia zespołowi szybkie rozwijanie funkcji w środowisku 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 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 kompletną zgodnością transakcji ACID i silnie egzekwowanymi kluczami obcymi dla zachowania integralności relacyjnej. Kirby chce korzystać z automatycznego dostrajania wydajności, aby uprościć codzienne zarządzanie bazami danych.
Kirby decyduje o bazy danych SQL w usłudze Fabric, z tym samym aparatem usługi SQL Database co usługa Azure SQL Database. Bazy danych SQL w Fabric są automatycznie skalowane w celu zaspokojenia zapotrzebowania w ciągu dnia pracy. Mają one pełne możliwości tabel transakcyjnych i elastyczność poziomów izolacji transakcji, od poziomu serializowalnego do odczytu zatwierdzonego jako migawka. Baza danych SQL w usłudze Fabric automatycznie tworzy i usuwa nieklastrowane indeksy na podstawie silnych sygnałów z planów wykonania obserwowanych po 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 ze zdarzeń w czasie rzeczywistym w usłudze Eventhouse. Każda baza danych Fabric zawiera punkt końcowy analizy SQL, dzięki czemu możliwy jest dostęp do danych w czasie rzeczywistym z platformy Spark lub z zapytań usługi Power BI przy użyciu trybu DirectLake. Te rozwiązania do raportowania chronią podstawową operacyjną bazę danych przed obciążeniem wynikającym z 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 przy użyciu usługi Fabric Data Factory w celu zaimportowania danych do bazy danych Fabric SQL.