Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Skorzystaj z tego przewodnika referencyjnego oraz przykładowych scenariuszy, aby pomóc Ci wybrać magazyn danych dla swoich obciążeń Microsoft Fabric. Wszystkie magazyny danych są dostępne w zunifikowanej pamięci masowej w OneLake.
Na diagramie przedstawiono przewodnik po decyzjach dotyczących wybierania magazynu danych Fabric. W przypadku przesyłania strumieniowego danych zdarzeń i interaktywnej analizy o wysokim stopniu szczegółowości użyj eventhouse. Do baz danych NoSQL używaj Cosmos DB w Fabric. W przypadku obciążeń transakcyjnych (OLTP) należy użyć bazy danych SQL w Fabric. Aby rozwijać AI z typami danych wektorowych, użyj bazy danych SQL w Fabric lub Cosmos DB w Fabric. Do magazynowania danych w przedsiębiorstwie, BI, OLAP oraz pełnego wsparcia transakcji SQL korzystaj z Fabric Data Warehouse. Do big data i uczenia maszynowego z danymi nieustrukturyzowanymi, półstrukturalnymi lub ustrukturyzowanymi oraz inżynierią danych użyj lakehouse. Wszystkie magazyny danych Fabric są domyślnie dostępne w OneLake w formacie otwartej tabeli.
| Idealny przypadek użycia | Obciążenie usługi Microsoft Fabric | Dane dostępne w usłudze OneLake domyślnie w formacie otwartej tabeli |
|---|---|---|
| Przesyłanie strumieniowe danych zdarzeń, wysoki stopień szczegółowości (w czasie, przestrzeni, szczegółach — dane działania JSON/Text) na potrzeby interaktywnej analizy | Eventhouse | Dostępne opcjonalnie |
| Baza NoSQL | Cosmos DB w Fabric | Tak |
| Transakcyjna baza danych, OLTP lub znormalizowana baza danych | Baza danych SQL w Fabric | Tak |
| Rozwijaj AI z wykorzystaniem wektorowych typów danych | Baza danych SQL w Fabric lub Cosmos DB w Fabric | Tak |
| Enterprise data warehouse, SQL-based BI, OLAP, pełne wsparcie dla transakcji SQL oraz funkcje AI (wersja zapowiednia) | Magazyn danych | Tak |
| Big data i uczenie maszynowe, dane niestrukturalne, półstrukturalne lub strukturalne, inżynieria danych | Lakehouse | Tak |
- W przypadku przesyłania strumieniowego danych zdarzeń i interaktywnej analizy o wysokim stopniu szczegółowości użyj eventhouse.
- Do baz danych NoSQL używaj Cosmos DB w Fabric.
- Dla operacyjnych, transakcyjnych, OLTP lub znormalizowanych relacyjnych baz danych używaj bazy SQL w Fabric.
- Aby rozwijać AI z typami danych wektorowych, użyj bazy danych SQL w Fabric lub Cosmos DB w Fabric.
- Do magazynowania danych w przedsiębiorstwie, BI, OLAP oraz pełnego wsparcia transakcji SQL korzystaj z Fabric Data Warehouse.
- W przypadku analizy dużych zbiorów danych, uczenia maszynowego z wykorzystaniem danych nieustrukturyzowanych, częściowo ustrukturyzowanych lub ustrukturyzowanych oraz inżynierii danych użyj architektury lakehouse.
- Wszystkie magazyny danych Fabric są domyślnie dostępne w OneLake w formacie otwartej tabeli, z wyjątkiem bazy danych KQL w eventhouse, gdzie dostępność OneLake jest dostępna jako funkcja opcjonalna.
Personas i umiejętności
| Obciążenie usługi Microsoft Fabric | Podstawowe postacie deweloperów | Podstawowe umiejętności i narzędzia | Języki podstawowe |
|---|---|---|---|
| Eventhouse | Deweloper aplikacji, analityk danych, inżynier danych | Brak kodu, KQL, SQL | KQL (język zapytań Kusto), T-SQL |
| Cosmos DB w Fabric | Deweloper sztucznej inteligencji, deweloper aplikacji | Pojęcia NoSQL, interfejsy API REST podobne do usługi Azure Cosmos DB | Integracja interfejsu API REST za pośrednictwem języka JavaScript/TypeScript, Python, C#, Java i innych |
| Baza danych SQL w Fabric | Deweloper sztucznej inteligencji, deweloper aplikacji, deweloper bazy danych, administrator bazy danych | Administrowanie bazami danych i tworzenie ich, podobnie jak w przypadku usług Azure SQL Database, SSMS, VS Code i narzędzi zapytań zgodnych z programem SQL Server | Język T-SQL |
| Magazyn danych sieci szkieletowej | Deweloper magazynu danych, architekt danych, inżynier danych, deweloper bazy danych | Pojęcia dotyczące magazynowania danych, projekt bazy danych schematu gwiazdy, program SSMS, program VS Code i narzędzia zapytań zgodne z programem SQL Server | T-SQL, brak kodu |
| Lakehouse | Inżynier danych, analityk danych | PySpark, Delta Lake, notebooki | Spark (Scala, PySpark, Spark SQL, R) |
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 rozpocząć czyszczenie, modelowanie i analizę danych, ale muszą zdecydować, czy zbudować hurtownię danych, czy domek nad jeziorem. Po przeanalizowaniu szczegółów z poprzedniej tabeli, głównymi punktami decyzyjnymi są dostępny zestaw umiejętności oraz potrzeba transakcji wielotabelowych.
Susan przez wiele lat budowała hurtownie danych na relacyjnych silnikach baz danych i zna składnię oraz funkcjonalność 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, by zbudować magazyn na SQL Server, działa w Fabric Data Warehouse, 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, które odwołują się do innych hurtowni danych i tabel Delta w lakehouse’ach, po prostu używając nazw trójczłonowych, aby wykonywać zapytania międzybazodanowe.
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 wykonującego zapytania T-SQL to konsumenci, więc nie muszą pisać INSERT, UPDATE, ani DELETE instrukcji. 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
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. Może wykonywać zapytania za pomocą Power BI i KQL do porównywania okresów obecnych i poprzednich, szybkiego identyfikowania pojawiających się problemów lub dostarczania analiz geoprzestrzennych tras lądowych i morskich.
Scenariusz 4
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 się na bazę danych SQL w środowisku Fabric, z tym samym silnikiem bazy danych SQL co 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 z usługą Fabric Data Factory w celu zaimportowania danych do bazy danych Fabric SQL.