Zrozumienie architektury typu medallion lakehouse dla Microsoft Fabric z wykorzystaniem OneLake

Architektura typu medallion lakehouse, powszechnie znana jako architektura medalionu, jest wzorcem projektowym używanym do organizowania danych w lakehouse. Jest to zalecane podejście projektowe dla Fabric. Ponieważ OneLake jest jeziorem danych dla Fabric, architektura medalionu jest realizowana poprzez tworzenie lakehouse'ów w OneLake.

Architektura medalionu składa się z trzech odrębnych warstw. Trzy warstwy medalonu to: brązowy (nieprzetworzone dane), srebrny (wzbogacone dane) i złoty (wyselekcjonowane dane). Każda warstwa wskazuje jakość danych przechowywanych w lakehouse, a wyższe poziomy reprezentują wyższą jakość.

Architektura medallionowa pomaga w zachowaniu dokładności i niezawodności danych zgodnie z zasadami atomowości, spójności, izolacji i trwałości (ACID). Dane są początkowo w formie surowej, a ich oryginalne kopie są zachowywane jako wiarygodne źródło, podczas gdy procesy weryfikacji i transformacji przygotowują dane do analizy.

Aby uzyskać więcej informacji, zobacz Co to jest architektura medalionowa lakehouse?.

Publiczność

W tym artykule przedstawiono architekturę medallion lake i opisano sposób implementowania wzorca projektowego w usłudze Microsoft Fabric. Jest ona przeznaczona dla wielu odbiorców:

Inżynierowie danych: personel techniczny, który projektuje, kompiluje i utrzymuje infrastrukturę i systemy, które umożliwiają organizacji zbieranie, przechowywanie, przetwarzanie i analizowanie dużych ilości danych.
Centrum doskonałości, IT i zespoły ds. analizy biznesowej: Zespoły odpowiedzialne za nadzorowanie analiz w całej organizacji.
Administratorzy Fabric: administratorzy, którzy są odpowiedzialni za nadzorowanie Fabric w organizacji.

Co to jest architektura medalionu?

Celem architektury medalionu jest przyrostowe zwiększenie struktury i jakości danych. Architekturę medaliową można traktować jako trzyetapowy proces czyszczenia i organizacji danych. Każda warstwa sprawia, że dane są bardziej niezawodne i łatwiejsze w użyciu.

Brąz (surowy): Przechowuj wszystko dokładnie w stanie, w jakim przybywa. Żadne zmiany nie są dozwolone.
Silver (wzbogacone): Naprawianie błędów, standaryzacja formatów i usuwanie duplikatów.
Złoto (wyselekcjonowane): Organizuj dla raportów i pulpitów nawigacyjnych.

Każda warstwa powinna być utrzymywana w oddzielnym magazynie lakehouse lub magazynie danych w usłudze OneLake, z danymi przemieszczającymi się między warstwami w miarę ich przekształcania i udoskonalania.

W typowej implementacji architektury medallionu w usłudze Fabric warstwa z brązu przechowuje dane w tym samym formacie co źródło danych. Gdy źródło danych jest relacyjną bazą danych, tabele delty są dobrym wyborem. Warstwy srebra i złota powinny zawierać tabele Delta.

Napiwek

Aby dowiedzieć się, jak utworzyć jezioro, zapoznaj się z samouczkiem dotyczącym kompleksowego scenariusza usługi Lakehouse.

Przykład rzeczywisty

Rozważmy następujący przykład firmy zajmującej się handlem elektronicznym, która stosuje architekturę medalonu do swoich danych:

Warstwa brązowa:

Przechowywanie nieprzetworzonych danych sprzedaży z witryny internetowej (JSON)
Przechowuj surowe dane inwentarzowe z magazynu (CSV)
Przechowywanie nieprzetworzonych danych klientów z programu CRM (eksport SQL)

Warstwa srebra:

Standaryzacja formatów dat we wszystkich źródłach
Przekonwertuj całą walutę na USD
Usuwanie transakcji testowych
Dopasowywanie rekordów klientów między systemami

Warstwa złota:

Utwórz dzienną tabelę dashboardu sprzedaży
Tworzenie tabeli wartości okresu istnienia klienta
Generowanie tabeli prognozowania spisu

Architektura medalionu w usłudze OneLake

Podstawą nowoczesnego magazynu danych jest jezioro danych. Microsoft OneLake to jedno, ujednolicone, logiczne jezioro danych dla całej organizacji. Jest ona konfigurowana automatycznie z każdą dzierżawą usługi Fabric i jest jedynym miejscem dla wszystkich danych analitycznych.

Aby przechowywać dane w usłudze OneLake, należy utworzyć platformę lakehouse w usłudze Fabric. Lakehouse to platforma architektury danych do przechowywania danych, zarządzania nimi i analizowania danych ze strukturą i bez struktury w jednej lokalizacji. Można go skalować do dużych ilości danych wszystkich typów i rozmiarów plików, a ponieważ dane są przechowywane w jednej lokalizacji, mogą być współużytkowane i ponownie używane w całej organizacji.

Aby uzyskać więcej informacji, zobacz Co to jest lakehouse w usłudze Microsoft Fabric?.

Tabele i pliki

Podczas tworzenia magazynu lakehouse w usłudze OneLake aprowizowane są automatycznie dwie fizyczne lokalizacje przechowywania:

Tabele przechowują tabele wszystkich formatów na platformie Apache Spark (CSV, Parquet lub Delta).
Pliki przechowują dane w dowolnym formacie pliku. Jeśli chcesz utworzyć tabelę na podstawie danych w obszarze plików, możesz utworzyć skrót wskazujący folder zawierający pliki tabeli.

W warstwie z brązu dane są przechowywane w oryginalnym formacie, który może być tabelami lub plikami. Jeśli dane źródłowe pochodzą z OneLake, Azure Data Lake Store Gen2 (ADLS Gen2), Amazon S3 lub Google, utwórz skrót w warstwie brązowej zamiast kopiować dane.

W warstwach srebra i złota zazwyczaj dane są przechowywane w tabelach delty. Można jednak również przechowywać dane w plikach Parquet lub CSV. W takim przypadku należy jawnie utworzyć skrót lub tabelę zewnętrzną z lokalizacją wskazującą niezarządzany folder zawierający pliki usługi Delta Lake na platformie Apache Spark.

W Microsoft Fabric Eksplorator Lakehouse udostępnia ujednoliconą graficzną reprezentację całego Lakehouse, aby użytkownicy mogli nawigować po danych, uzyskiwać do nich dostęp i aktualizować je.

Magazyn Delta Lake

Usługa Delta Lake to zoptymalizowana warstwa magazynu, która stanowi podstawę do przechowywania danych i tabel. Obsługuje transakcje ACID dla obciążeń big data, i z tego powodu jest domyślnym formatem magazynu w systemie Fabric Lakehouse.

Delta Lake gwarantuje niezawodność, bezpieczeństwo i wydajność w architekturze lakehouse dla operacji przesyłania strumieniowego i przetwarzania wsadowego. Wewnętrznie przechowuje dane w formacie pliku Parquet, jednak także prowadzi dzienniki transakcji i statystyki, co zapewnia dodatkowe funkcje oraz poprawę wydajności w porównaniu do standardowego formatu Parquet.

Format usługi Delta Lake zapewnia następujące korzyści w porównaniu z ogólnymi formatami plików:

Obsługa właściwości ACID, zwłaszcza trwałości, aby zapobiec uszkodzeniom danych.
Szybsze odczytywanie zapytań.
Zwiększona świeżość danych.
Obsługa obciążeń wsadowych i przesyłanych strumieniowo.
Obsługa wycofywania danych przy użyciu funkcji podróżowania w czasie Delta Lake.
Ulepszono zgodność z przepisami i audyty dzięki wykorzystaniu historii tabel Delta Lake.

Platforma standaryzuje format pliku przechowywania za pomocą Delta Lake. Domyślnie każdy silnik w Fabric tworzy tabele Delta podczas zapisywania danych w nowej tabeli. Aby uzyskać więcej informacji, zobacz Lakehouse i Delta Lake tabele.

Model wdrażania

Aby zaimplementować architekturę medalionu w usłudze Fabric, możesz użyć lakehouse'ów (po jednym dla każdej warstwy), magazynu danych lub połączenia obu. Twoja decyzja powinna być oparta na preferencjach i wiedzy twojego zespołu. Za pomocą usługi Fabric można używać różnych silników analitycznych działających na jednej kopii danych w OneLake.

Poniżej przedstawiono dwa wzorce, które należy wziąć pod uwagę:

Wzorzec 1: Utwórz każdą warstwę jako jezioro. W takim przypadku użytkownicy biznesowi uzyskują dostęp do danych przy użyciu punktu końcowego analizy SQL.
Wzorzec 2: Utwórz warstwy brązową i srebrną jako lakehouse'y, a warstwę złotą jako magazyn danych. W takim przypadku użytkownicy biznesowi uzyskują dostęp do danych przy użyciu punktu końcowego magazynu danych.

Chociaż można tworzyć wszystkie lakehouse'y w jednym Fabric workspace, zalecamy utworzenie każdego lakehouse'u we własnym, osobnym obszarze roboczym. Takie podejście zapewnia większą kontrolę i lepszy nadzór na poziomie warstwy.

W przypadku warstwy brązowej zalecamy przechowywanie danych w oryginalnym formacie lub używanie Parquet lub Delta Lake. Jeśli to możliwe, zachowaj dane w oryginalnym formacie. Jeśli dane źródłowe pochodzą z usługi OneLake, Azure Data Lake Store Gen2 (ADLS Gen2), Amazon S3 lub Google, utwórz skrót w warstwie brązowej zamiast kopiowania danych.

W przypadku warstw srebrnych i złotych zalecamy używanie tabel Delta ze względu na dodatkowe możliwości i ulepszenia wydajności, które oferują. Platforma standaryzuje format Delta Lake, a domyślnie każdy silnik w platformie zapisuje dane w tym formacie. Ponadto te aparaty używają optymalizacji czasu zapisu V-Order do formatu pliku Parquet. Ta optymalizacja umożliwia szybkie odczyty przez silniki obliczeniowe Fabric, takie jak Power BI, SQL, Apache Spark i inne. Aby uzyskać więcej informacji, zobacz optymalizacja tabel Delta Lake i V-Order.

Na koniec wiele organizacji stoi w obliczu ogromnego wzrostu ilości danych, wraz z coraz większą potrzebą organizowania tych danych i zarządzania nimi w logiczny sposób, ułatwiając bardziej ukierunkowane i wydajne wykorzystanie i nadzór. Może to prowadzić do ustanowienia i zarządzania zdecentralizowaną lub federacyjną organizacją danych z odpowiednim nadzorem. Aby osiągnąć ten cel, rozważ zaimplementowanie architektury siatki danych. Siatka danych to wzorzec architektury, który koncentruje się na tworzeniu domen danych, które oferują dane jako produkt.

Możesz utworzyć architekturę siatki danych dla majątku danych w usłudze Fabric, tworząc domeny danych. Możesz tworzyć domeny, które odpowiadają domenom biznesowym, na przykład marketingowi, sprzedaży, inwentarzowi, zasobom ludzkim i innym. Następnie można zaimplementować architekturę medalionu, konfigurując warstwy danych w każdej domenie. Aby uzyskać więcej informacji o domenach, zobacz Domeny.

Używanie zmaterializowanych widoków jeziora na potrzeby architektury medalonu

Zmaterializowane widoki jeziora w Microsoft Fabric ułatwiają implementowanie architektury medaliowej w Lakehouse. Zamiast tworzyć złożone potoki do przekształcania danych między warstwami brązową, srebrną i złotą, można zdefiniować zmaterializowane widoki jeziorowe, które automatycznie zarządzają transformacjami danych.

Najważniejsze korzyści wynikające z używania zmaterializowanych widoków typu lake dla architektury medalonu obejmują:

Potoki deklaratywne: definiowanie przekształceń danych przy użyciu instrukcji SQL zamiast kompilowania ręcznych potoków między warstwami.
Automatyczne zarządzanie zależnościami: sieć szkieletowa automatycznie określa poprawną kolejność wykonywania na podstawie zależności widoku.
Reguły jakości danych: wbudowana obsługa definiowania i wymuszania ograniczeń jakości danych w miarę przechodzenia danych przez warstwy.
Optymalne odświeżanie: system automatycznie określa, czy wykonać odświeżanie przyrostowe, pełne, czy też zrezygnować z odświeżania dla każdego widoku.
Wizualizacja i monitorowanie: wyświetlanie pochodzenia we wszystkich warstwach i śledzenie postępu wykonywania.

Można na przykład utworzyć widok warstwy srebrnej, który czyści i łączy dane z tabel z brązu, a następnie utworzyć widoki warstwy złotej, które agregują dane warstwy srebrnej na potrzeby raportowania. System automatycznie obsługuje koordynację odświeżania.

Aby uzyskać więcej informacji, zobacz Implementowanie architektury medalonu za pomocą zmaterializowanych widoków jeziora.

Zrozumienie magazynowania danych tabeli Delta

W tej sekcji opisano dodatkowe wskazówki związane z implementacją architektury lakehouse w usłudze Fabric.

Rozmiar pliku

Ogólnie rzecz biorąc, platforma danych big data działa lepiej, gdy ma kilka dużych plików, a nie wiele małych plików. Obniżenie wydajności występuje, gdy aparat obliczeniowy ma wiele metadanych i operacji na plikach do zarządzania. Aby uzyskać lepszą wydajność zapytań, zalecamy, aby dążyć do plików danych o rozmiarze około 1 GB.

Różne warstwy architektury medalonu mają różne wymagania dotyczące rozmiaru pliku w zależności od tego, który silnik przetwarzania będzie używany. W warstwie z brązu możesz mieć mniejsze pliki z powodu nieprzetworzonego charakteru danych, o ile koncentrujesz się na modyfikacji i przygotowaniu danych za pomocą platformy Spark. W warstwach srebrnej i złotej należy zoptymalizować dla większych rozmiarów plików oraz większych grup wierszy, aby poprawić wydajność zapytań dla silników analitycznych. Aby dowiedzieć się więcej na temat optymalizowania rozmiarów plików dla różnych warstw, zobacz Konserwacja i optymalizacja tabel dla różnych obciążeń.

Przechowywanie historyczne

Domyślnie usługa Delta Lake przechowuje historię wszystkich wprowadzonych zmian, dzięki czemu rozmiar metadanych historycznych rośnie wraz z upływem czasu. Na podstawie wymagań biznesowych zachowaj dane historyczne tylko przez określony czas, aby zmniejszyć koszty magazynowania. Rozważ przechowywanie danych historycznych tylko w ostatnim miesiącu lub w innym odpowiednim przedziale czasu.

Starsze dane historyczne z tabeli delty można usunąć przy użyciu polecenia VACUUM. Jednak domyślnie nie można usuwać danych historycznych w ciągu ostatnich siedmiu dni. To ograniczenie utrzymuje spójność danych. Skonfiguruj domyślną liczbę dni za pomocą właściwości delta.deletedFileRetentionDuration = "interval <interval>"tabeli . Ta właściwość określa okres, przez który plik musi zostać usunięty, zanim będzie można go uznać za kandydata do operacji opróżnienia.

Partycje tabel i klastrowanie

Podczas przechowywania danych w każdej warstwie zalecamy użycie struktury folderów partycjonowanych wszędzie tam, gdzie ma to zastosowanie. Ta technika zwiększa możliwości zarządzania danymi i wydajność zapytań. Ogólnie rzecz biorąc, partycjonowane dane w strukturze folderów skutkują szybszym wyszukiwaniem określonych wpisów danych z powodu oczyszczania/eliminacji partycji. Partycjonowanie jest zwykle dobrą strategią częstego przesyłania danych w warstwie Brązowej, ponieważ jest zgodne z wieloma narzędziami do przesyłania danych. Jednak w przypadku warstw Silver i Gold zalecamy użycie funkcji Liquid Clustering zamiast partycjonowania w celu zoptymalizowania wydajności zapytań. Aby dowiedzieć się więcej na temat optymalizowania dla różnych warstw, zobacz Utrzymanie i optymalizacja tabel wielozadaniowej.

Zazwyczaj dane są dołączane do tabeli docelowej w miarę nadejścia nowych danych. Jednak w niektórych przypadkach możesz scalić dane, ponieważ trzeba zaktualizować istniejące dane w tym samym czasie. W takim przypadku można wykonać operację upsert przy użyciu polecenia MERGE. Podczas partycjonowania tabeli docelowej należy użyć filtru partycji, aby przyspieszyć operację. Dzięki temu aparat może wyeliminować partycje, które nie wymagają aktualizacji.

Dostęp do danych

Należy zaplanować i kontrolować, kto potrzebuje dostępu do określonych danych w lakehouse. Należy również zrozumieć różne wzorce transakcji, których będą używać podczas uzyskiwania dostępu do tych danych dla każdej warstwy.