Udostępnij przez

Przewodnik po decyzjach dotyczących usługi Microsoft Fabric: wybieranie magazynu danych

  • Artykuł

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

Magazyn Lakehouse Power BI Datamart Baza danych KQL (Eventhouse)
Wolumin danych Nieograniczony Nieograniczony Do 100 GB Nieograniczony
Typ danych Dane ustrukturyzowane Bez struktury, częściowo ustrukturyzowane, ustrukturyzowane Dane ustrukturyzowane Bez struktury, częściowo ustrukturyzowane, ustrukturyzowane
Podstawowa osoba dewelopera Deweloper magazynu danych, inżynier SQL Inżynier danych, analityk danych Deweloper obywatela Citizen Data scientist, inżynier danych, analityk danych, inżynier sql
Podstawowy zestaw umiejętności deweloperów SQL Spark(Scala, PySpark, Spark SQL, R) Brak kodu, SQL Brak kodu, KQL, SQL
Dane uporządkowane według Bazy danych, schematy i tabele Foldery i pliki, bazy danych i tabele Baza danych, tabele, zapytania Bazy danych, schematy i tabele
Operacje odczytu T-SQL, 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, fuctions itp.) Spark, T-SQL Spark, T-SQL, Power BI KQL, T-SQL, Spark, Power BI
Operacje zapisu T-SQL Spark(Scala, PySpark, Spark SQL, R) Przepływy danych, T-SQL KQL, Spark, ekosystem łącznika
Transakcje obejmujące wiele tabel Tak Nie. Nie. Tak, w przypadku pozyskiwania wielu tabel. Zobacz zasady aktualizacji.
Podstawowy interfejs projektowy Skrypty SQL Notesy platformy Spark, definicje zadań platformy Spark Power BI Zestaw zapytań KQL, baza danych KQL
Bezpieczeństwo Poziom obiektu (tabela, widok, funkcja, procedura składowana itp.), poziom kolumny, poziom wiersza, DDL/DML, dynamiczne maskowanie danych Poziom wiersza, poziom tabeli (w przypadku korzystania z języka T-SQL), brak dla platformy Spark Wbudowany edytor zabezpieczeń na poziomie wiersza Zabezpieczenia na poziomie wierszy
Uzyskiwanie dostępu do danych za pomocą skrótów Tak, przez jezioro przy użyciu trzech części nazw Tak Nie Tak
Może być źródłem skrótów Tak (tabele) Tak (pliki i tabele) Nie. Tak
Wykonywanie zapytań między elementami Tak, wykonywanie zapytań dotyczących tabel lakehouse i warehouse Tak, wykonaj zapytanie w tabelach lakehouse i warehouse; wykonywanie zapytań między magazynami lakehouse (w tym skrótami przy użyciu platformy Spark) Nie. Tak, wykonywanie zapytań dotyczących baz danych KQL, magazynów lakehouse i magazynów za pomocą skrótów
Analiza zaawansowana Elementy natywne szeregów czasowych, pełne funkcje przechowywania geoprzestrzennych i zapytań
Obsługa zaawansowanego formatowania Pełne indeksowanie wolnych danych tekstowych i częściowo ustrukturyzowanych, takich jak JSON
Opóźnienie pozyskiwania Pozyskiwanie w kolejce, pozyskiwanie przesyłania strumieniowego ma kilka sekund opóźnienia

Uwaga

Eventhouse to obszar roboczy dla wielu baz danych KQL. Baza danych KQL jest ogólnie dostępna, natomiast usługa Eventhouse jest dostępna w wersji zapoznawczej. Aby uzyskać więcej informacji, zobacz Omówienie usługi Eventhouse (wersja zapoznawcza).

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 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 danych, 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 jezioro. 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 ich większym zespole, zdają sobie sprawę, że głównymi odbiorcami tych danych mogą być 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 bazy danych KQL 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.

Powiązana zawartość