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
W tej tabeli porównano magazyny danych, takie jak magazyn, lakehouse, datamart usługi Power BI i magazyn zdarzeń na podstawie ilości danych, typu, osoby dewelopera, zestawu umiejętności, operacji. i inne możliwości.
Magazyn | Lakehouse | Power BI Datamart | 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 dostępu do widoków, procedur składowanych, funkcji 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 kolumny (w przypadku usługi Lakehouse dostępnej za pośrednictwem punktu końcowego analizy SQL), 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 |
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 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 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 magazynu zdarzeń 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.