Wybieranie magazynu danych analitycznych na platformie Azure

Architektura danych big data często wymaga magazynu danych analitycznych, który obsługuje przetworzone dane w formacie ustrukturyzowanym. Możesz wykonywać zapytania dotyczące tych danych przy użyciu narzędzi analitycznych. Magazyny danych analitycznych, które obsługują wykonywanie zapytań dotyczących zarówno danych ścieżki gorącej, jak i zimnej ścieżki, są zbiorczo określane jako warstwa obsługująca lub magazyn obsługujący dane.

Warstwa obsługująca przetworzone dane zarówno ze ścieżki gorącej, jak i ścieżki zimnej. W architekturze lambda warstwa obsługi jest podzielona na dwie warstwy. Warstwa szybkości przetwarzania zawiera dane przetwarzane stopniowo. Warstwa przetwarzania wsadowego zawiera dane wyjściowe przetworzone wsadowo.

Chociaż ogólna warstwa udostępniania wymaga solidnego wsparcia dla losowych operacji odczytu o niskich opóźnieniach, magazyn danych dla warstwy szybkościowej powinien również obsługiwać losowe operacje zapisu, ponieważ wsadowe ładowanie danych do tego magazynu wprowadza niepożądane opóźnienia. Z drugiej strony magazyn danych dla warstwy wsadowej musi obsługiwać zapisy wsadowe, a nie losowe zapisy.

Żadne pojedyncze rozwiązanie do zarządzania danymi nie pasuje do każdego zadania magazynu danych. Różne rozwiązania są optymalne dla określonych zadań. Większość aplikacji chmurowych używanych w praktyce oraz procesów przetwarzania dużych zbiorów danych ma różne wymagania dotyczące przechowywania danych i często korzysta z połączenia różnych rozwiązań pamięci masowej.

Nowoczesne rozwiązania analityczne, takie jak Microsoft Fabric, zapewniają kompleksową platformę, która integruje różne usługi i narzędzia danych w celu spełnienia różnych potrzeb analitycznych. Fabric obejmuje usługę OneLake, która jest jednym, ujednoliconym, logicznym jeziorem danych w całej organizacji. Usługa OneLake została zaprojektowana do przechowywania i zabezpieczania wszystkich danych organizacji oraz zarządzania nimi w jednej lokalizacji. Ta elastyczność pozwala organizacji sprostać szerokiemu zakresowi wymagań dotyczących magazynowania i przetwarzania danych.

Wybieranie analitycznego magazynu danych

Microsoft oferuje kilka opcji przechowywania danych w zależności od potrzeb:

Różne modele baz danych odpowiadają różnym typom zadań:

  • Magazyny danych typu klucz-wartość przechowują jeden zserializowany obiekt dla każdego klucza. Mogą zarządzać dużymi ilościami danych podczas pobierania na podstawie określonego klucza bez konieczności wykonywania zapytań o inne właściwości elementu.

  • Magazyny danych dokumentów to magazyny danych typu klucz-wartość, w których wartości są dokumentami. W tym kontekście dokument jest kolekcją nazwanych pól i wartości. Magazyn danych zazwyczaj przechowuje dane w formacie, takim jak XML, YAML, JSON lub binarny kod JSON, ale może używać zwykłego tekstu. Magazyny danych dokumentów mogą wykonywać zapytania dotyczące pól innych niż kluczowe i definiować indeksy pomocnicze w celu zwiększenia wydajności zapytań. Ta funkcja sprawia, że baza danych dokumentów jest bardziej odpowiednia dla aplikacji, które muszą pobierać dane na podstawie kryteriów bardziej złożonych niż wartość klucza dokumentu. Można na przykład wykonywać zapytania dotyczące pól, takich jak identyfikator produktu, identyfikator klienta lub nazwa klienta.

  • Magazyny danych rodziny kolumn to magazyny danych typu klucz-wartość, które przechowują każdą kolumnę oddzielnie na dysku. Baza szerokokolumnowa przechowuje rodziny kolumn, a nie tylko pojedyncze kolumny. Na przykład baza danych spisu może mieć oddzielną rodzinę kolumn dla każdego z atrybutów poszczególnych osób:

    • Imię, środkowe i nazwisko
    • Adres wysyłkowy
    • Informacje o profilu, takie jak data urodzenia lub płeć

    Magazyn danych może przechowywać każdą rodzinę kolumn w oddzielnej partycji, zachowując jednocześnie wszystkie dane dla jednej osoby powiązanej z tym samym kluczem. Aplikacja może odczytać rodzinę kolumn bez skanowania wszystkich danych dla jednostki.

  • Dane programu Graph przechowują informacje jako kolekcję obiektów i relacji. Grafowa baza danych może wydajnie wykonywać zapytania, które przemierzają sieć obiektów oraz relacji między nimi. Na przykład obiekty mogą być pracownikami w bazie danych zasobów ludzkich i warto ułatwić wykonywanie zapytań, takich jak "znajdowanie wszystkich pracowników, którzy bezpośrednio lub pośrednio pracują dla Scotta".

  • Telemetria i bazy danych szeregów czasowych to kolekcja obiektów, do których można tylko dodawać. Bazy danych telemetrycznych efektywnie indeksują dane w różnych magazynach kolumnowych i strukturach w pamięci. Ta funkcja sprawia, że są one optymalnym wyborem do przechowywania i analizowania ogromnych ilości danych telemetrycznych i danych szeregów czasowych.

Fabric obsługuje różne modele baz danych, w tym bazy danych typu klucz-wartość, dokumentowe, kolumnowe, grafowe i telemetryczne. Ta elastyczność zapewnia skalowalność dla szerokiego zakresu zadań analitycznych. Aby wybrać odpowiedni magazyn danych Fabric dla obciążeń analitycznych, zobacz Fabric przewodnik po decyzjach: wybieranie magazynu danych.

Kluczowe kryteria wyboru

Aby uściślić proces wyboru, należy wziąć pod uwagę następujące kryteria:

  • Czy potrzebujesz obsługiwać magazyn, który może służyć jako gorąca ścieżka dla danych? Jeśli tak, wybierz opcje najlepiej dopasowane do warstwy szybkiego udostępniania danych.

  • Czy potrzebujesz obsługi masowego przetwarzania równoległego, w którym zapytania są automatycznie dystrybuowane między kilka procesów lub węzłów? Jeśli tak, wybierz opcję, która obsługuje skalowanie w poziomie zapytań.

  • Czy wolisz używać relacyjnego magazynu danych? W takim przypadku wybierz opcje, które mają model relacyjnej bazy danych. Jednak niektóre magazyny nierelacyjne obsługują składnię SQL na potrzeby wykonywania zapytań i można używać narzędzi, takich jak punkty końcowe analizy SQL, do wykonywania zapytań dotyczących magazynów danych nierelacyjnych, takich jak OneLake.

  • Czy zbierasz dane szeregów czasowych? Czy używasz danych tylko do dodawania? OneLake obsługuje wiele mechanizmów analitycznych, w tym Analysis Services, T-SQL i Apache Spark. Usługa Eventhouse doskonale nadaje się do różnych potrzeb przetwarzania danych szeregów czasowych i wykonywania zapytań.

Macierz możliwości

W poniższych tabelach podsumowano kluczowe różnice w możliwościach między tymi usługami zarządzanymi.

Ogólne możliwości

Zdolność Lakehouse Data Warehouse Eventhouse Baza danych SQL Fabric Azure SQL Database Azure Cosmos DB Analysis Services
Podstawowy model bazy danych Ujednolicone przetwarzanie typu data lake, relacyjne, zarządzane przez użytkownika format usługi delta lake przy użyciu oprogramowania Apache Parquet Ujednolicony relacyjny format Delta Lake zarządzany przez system dla data lake, wykorzystujący Apache Parquet Magazyn danych zorientowany na dołączanie szeregów czasowych, graf, wektor Relacyjne (format magazynu kolumn podczas korzystania z indeksów magazynu kolumn) Relacyjne (format magazynu kolumn podczas korzystania z indeksów magazynu kolumn) Magazyn dokumentów, graf, magazyn klucz-wartość, szeroki magazyn kolumn Modele semantyczne tabelaryczne
Obsługa języka SQL Tak1 Tak Tak2 Tak Tak Tak Nie
Zoptymalizowane pod kątem szybkiej obsługi warstwy Tak Tak Tak3 Tak4 Tak5 Tak Nie

[1] T-SQL w punkcie końcowym analizy SQL.

[2] Język zapytań Kusto (KQL) ma częściową obsługę języka T-SQL.

[3] Obsługuje pozyskiwanie w kolejce i pozyskiwanie strumieniowe.

[4] Obsługuje precyzję transakcyjną z dostępem o małych opóźnieniach i aktualizacjami w czasie rzeczywistym.

[5] Przy użyciu tabel zoptymalizowanych pod kątem pamięci i skrótów lub indeksów nieklastrowanych.

Możliwości skalowalności

Zdolność Lakehouse Data Warehouse Eventhouse Baza danych SQL Fabric Azure SQL Database Azure Cosmos DB Analysis Services
Nadmiarowe serwery regionalne w celu zapewnienia wysokiej dostępności Tak1,2 Tak1,2 Tak Tak Tak Tak Tak
Obsługuje skalowanie zapytań w poziomie Tak3 Tak4 Tak5 Tak Nie Tak Tak
Dynamiczna skalowalność (skalowanie w górę) Tak3 Tak4 Tak5 Tak Tak Tak Tak
Obsługuje buforowanie danych w pamięci Tak6 Tak6 Tak7 Tak Tak Tak Nie

Punkty końcowe SQL są trasowane przez globalne menedżery ruchu, jednak dane są zawsze przetwarzane w regionie przypisanej pojemności Fabric.

[2] Lakehouse i Warehouse przechowują dane w usłudze OneLake w formacie Delta Parquet, który obsługuje zapytania i replikację między mechanizmami.

Usługa Lakehouse obsługuje rozproszoną architekturę opartą na Spark dla danych bez struktury i danych ustrukturyzowanych.

[4] Magazyn używa języka T-SQL i obsługuje transakcje wielotabłowe, autonomiczne zarządzanie obciążeniami i rozproszone przetwarzanie zapytań (DQP). DQP działa jak menedżer klastra, dynamicznie przydzielając zasoby obliczeniowe na podstawie złożoności zapytania.

[5] Usługa Eventhouse obsługuje język KQL i federację SQL na potrzeby analizy w czasie rzeczywistym w wielu źródłach oraz skalowania zasobów obliczeniowych w górę, jeśli użycie gorącej pamięci podręcznej przekracza około 95%.

[6] Inteligentna pamięć podręczna dla zadań platformy Spark, buforowanie w pamięci, buforowanie zestawu wyników dla punktów końcowych analizy SQL.

[7] Często używane dane są przechowywane w szybkiej pamięci podręcznej, która obejmuje pamięć operacyjną i dyski SSD.

Możliwości zabezpieczeń

Zdolność Lakehouse Data Warehouse Eventhouse Baza danych SQL Fabric Azure SQL Database Azure Cosmos DB Analysis Services
Uwierzytelnianie Microsoft Entra ID Microsoft Entra ID Microsoft Entra ID Microsoft Entra ID SQL lub Microsoft Entra ID Użytkownicy bazy danych lub Microsoft Entra ID za pomocą kontroli dostępu (zarządzanie tożsamościami i dostępem) Microsoft Entra ID
Szyfrowanie danych w spoczynku Tak Tak Tak Tak Tak1 Tak Tak
Zabezpieczenia na poziomie wiersza Tak Tak Tak Tak Tak Nie Tak
Obsługuje zapory Tak2 Tak2 Tak3 Tak Tak Tak Tak
Dynamiczne maskowanie danych Tak4 Tak4 Nie Tak Tak Nie Nie

[1] Wymaga użycia funkcji przezroczystego szyfrowania danych do szyfrowania i odszyfrowywania danych w spoczynku.

[2] Użyj linków prywatnych i Dostęp warunkowy usługi Microsoft Entra, aby ograniczyć dostęp do zasobów Fabric.

[3] Obciążenia usługi Fabric Eventhouse i Real-Time Intelligence mogą pozyskiwać dane z bezpiecznych źródeł, takich jak Kafka, Azure Event Hubs i AMQP, przy użyciu bezpiecznych punktów końcowych do routingu.

[4] Zastosuj to na poziomie punktu końcowego SQL usługi Fabric.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

  • Last updated on