Architektura ujednoliconej platformy danych

Ten artykuł pomaga osobom podejmującym decyzje w podejmowaniu decyzji architektonicznych dotyczących ich strefy docelowej platformy Azure w celu utworzenia ujednoliconej platformy danych.

Organizacje muszą określić, których aktualizacji wymaga landing zone platformy oraz jak obciążenia platformy Azure powinny być zintegrowane z ujednoliconą platformą danych. Bez jasnej architektury dane mogą pozostać odizolowane między obciążeniami i platformami lub przechodzić między nimi bez spójnego ładu i zabezpieczeń. Ten artykuł zawiera wskazówki dotyczące aktualizowania strefy docelowej platformy i tworzenia architektury stref docelowych obciążeń, dzięki czemu obciążenia platformy Azure mogą tworzyć dane dla Microsoft Fabric i korzystać z zarządzanych danych z niej.

Architektury i drzewo decyzyjne

1. strefa docelowa platformy Azure

Jak zaktualizować naszą strefę docelową platformy Azure? Ujednolicona platforma danych powinna używać istniejącej architektury Azure landing zone organizacji. Organizacja nie powinna tworzyć oddzielnej architektury Azure wyłącznie dla Microsoft Fabric lub obciążeń danych.

1.1. Aktualizacje landing zone platformy

Jakie zmiany są wymagane w landing zone platformy? Strefa lądowania platformy powinna nadal zapewniać współdzielone funkcje platformy Azure używane w całej organizacji. Organizacja powinna zachować istniejącą hierarchię grup zarządzania, chyba że nowe wymagania regulacyjne, bezpieczeństwa, suwerenności lub operacyjne wymagają innego zakresu zasad.

Poziom bazowy ładu: zespół ds. platformy powinien ocenić każdą usługę Azure wprowadzoną przez ujednoliconą platformę danych względem istniejącego poziomu bazowego zasad. Przegląd powinien określić, czy istniejące mechanizmy kontrolne mają zastosowanie i czy wymagane są dodatkowe mechanizmy kontrolne. Odpowiednie odwołania do zasad wbudowanych obejmują:

• Azure Databricks
• Azure Machine Learning
• Azure Data Lake Storage
• Maszyny wirtualne (obliczenia)
• Dozwolone lokalizacje

1.2. Strefy lądowania obciążeń

Co należy umieścić w landing zones obciążeń roboczych? Zasoby platformy Azure, które obsługują ujednoliconą platformę danych, powinny znajdować się w strefach docelowych dla obciążeń, chyba że zapewniają podstawowe możliwości platformy Azure zdefiniowane przez architekturę strefy docelowej platformy Azure w organizacji.

1.3 integracja z Fabric

Jak obciążenia platformy Azure powinny integrować się z Microsoft Fabric? Obciążenia Azure powinny być integrowane z Microsoft Fabric za pośrednictwem zatwierdzonych wzorców obowiązujących w całej organizacji w celu udostępniania danych za pośrednictwem usługi OneLake i korzystania z produktów danych objętych nadzorem. Integracja z Fabric nie powinna zmieniać umiejscowienia obciążenia roboczego.

Architektura powinna obsługiwać produkty danych utworzone w Fabric i produkty danych utworzone za pośrednictwem innych zatwierdzonych platform, takich jak Azure Databricks. Wzorzec integracji powinien identyfikować system referencyjny i unikać niepotrzebnego duplikowania przetwarzania lub danych. Zobacz integrację usługi Azure Databricks z usługą OneLake i skrót Azure Data Lake Storage (ADLS) Gen2.

Organizacja powinna zdefiniować obsługiwane wzorce integracji poprzez swoje standardy operacyjne.

2. architektura Microsoft Fabric

Jak organizacja powinna projektować Microsoft Fabric? Microsoft Fabric powinna zapewnić udostępnioną platformę, za pomocą której domeny danych tworzą, publikują i korzystają z produktów danych. Organizacja powinna ustanowić wspólną architekturę Fabric, zanim domeny danych wdrożą produkcyjne produkty danych.

2.1 wdrażanie zasobów usługi Fabric

Jak należy wdrożyć pojemności usługi Fabric? Każda domena danych powinna wdrożyć swoje pojemności usługi Fabric za pośrednictwem wyznaczonej subskrypcji strefy docelowej dla obciążeń. Domena danych powinna zarządzać pojemnością usługi Fabric w ramach zatwierdzonego budżetu i standardów obowiązujących w całej organizacji.

• Wymagania dotyczące pojemności: domena danych powinna dodać Fabric pojemność, gdy istniejące zasoby nie mogą spełniać zatwierdzonych wymagań dotyczących wydajności, izolacji, regionu lub cyklu życia. Domena danych nie powinna dodawać Fabric pojemności tylko w celu organizowania produktów lub zespołów danych.

• Azure wymagania dotyczące subskrypcji: domena danych powinna używać tylko innej subskrypcji strefy docelowej obciążenia, gdy wymagany jest odrębny ład Azure lub granica administracyjna. Inny obszar roboczy, środowisko lub produkt danych nie uzasadnia innej subskrypcji.

• Współdzielone pojemności usługi Fabric: wiele domen danych może współdzielić pojemność usługi Fabric, gdy udostępnione zasoby zapewniają akceptowalną wydajność i lepsze wykorzystanie zasobów.

• Wdrożenie regionalne: Organizacja powinna ustanowić domyślny region platformy Azure dla jednostek pojemności usługi Fabric. Domeny danych powinny używać tego regionu, chyba że zatwierdzone wymaganie uzasadnia inny region. Dopuszczalne wyjątki obejmują miejsce przechowywania danych, niezależność danych, opóźnienie, dostępność funkcji Fabric lub zatwierdzony projekt odzyskiwania po awarii. Wygoda lub lokalizacja zespołu nie są wystarczające dla innego regionu. Zobacz obsługa funkcji Multi-Geo dla usługi Fabric i wzorców wdrażania usługi Fabric.

• Zatwierdzenie wyjątku: organizacja powinna zdefiniować, kto zatwierdza region w innym obszarze lub pojemność Fabric współdzieloną między domenami danych. Wniosek o wyjątek powinien określać wymaganie, objęte nim produkty danych, oczekiwane koszty i warunki zakończenia.

2.2 Obszary robocze usługi Fabric

Jak należy używać obszarów roboczych? Obszary robocze usługi Fabric powinny zapewniać ramy, w ramach których domeny danych tworzą produkty danych i zarządzają nimi w Microsoft Fabric. Każda domena danych powinna określać strukturę przestrzeni roboczej w ramach standardów obowiązujących w całej organizacji.

• Użycie obszaru roboczego: utwórz oddzielny obszar roboczy, gdy elementy Fabric wymagają innej granicy administracyjnej, dostępu, wdrożenia lub sieci.

• Organizacja obszaru roboczego. Domeny danych powinny przypisywać powiązane obszary robocze do domen Fabric. Fabric domeny logicznie grupują obszary robocze Fabric i obsługują nadzór delegowany, ale przypisanie domeny nie określa dostępu do elementów Fabric. Zobacz Najlepsze rozwiązania dotyczące planowania i tworzenia domen w Microsoft Fabric.

3. architektura Microsoft Purview

Jak należy zaprojektować Microsoft Purview? Architektura Microsoft Purview powinna odzwierciedlać domeny danych organizacji bez traktowania domen ładu usługi Purview, domen Data Map, kolekcji lub domen Fabric jako zamiennych.

3.1 Umieszczanie konta Microsoft Purview

Gdzie należy wdrożyć konto usługi Purview? Organizacja powinna umieścić zasób Microsoft Purview Azure w wewnętrznej strefie lądowania obciążeń. Wybrana subskrypcja i region powinny spełniać wymagania prawne i operacyjne organizacji.

Organizacja powinna centralnie wyznaczyć odpowiedzialność za usługę Purview. Domeny danych powinny otrzymywać delegowaną decyzyjność w zakresie swoich metadanych i pojęć biznesowych za pośrednictwem zatwierdzonych ról usługi Purview. Nie powinny wdrażać oddzielnych środowisk Usługi Purview wyłącznie w celu uzyskania autonomii administracyjnej.

Zobacz Microsoft Purview często zadawane pytania.

3.2 Struktura Purview

Jak należy strukturyzować usługę Purview? Organizacja powinna ustanowić swoje domeny ładu i strukturę mapy danych, zanim domeny danych zaczną rejestrować źródła danych i publikować produkty danych.

• Domeny ładu: domeny ładu zapewniają kontekst biznesowy dla produktów danych i powiązanych pojęć. Mogą one obejmować terminy słownika, cele i kluczowe wyniki oraz krytyczne elementy danych. Domeny zarządzania powinny początkowo być zgodne z domenami danych organizacji. Użyj innej granicy, gdy wymaga tego własność w zakresie zarządzania. Zobacz Domeny zarządzania.

• Struktura mapy danych: domeny mapy danych powinny reprezentować granice cyklu życia lub najwyższego poziomu administracji technicznej. Ponieważ domeny mapy danych są ograniczone, należy ich używać do wyznaczania szerokich granic administracji technicznej, zamiast odzwierciedlać organizacyjne domeny danych.

• Kolekcje: Kolekcje powinny zapewnić bardziej szczegółową administrację i dostęp do metadanych w domenie mapy danych. Organizacja powinna używać kolekcji, gdy zespoły operacyjne potrzebują delegowanej odpowiedzialności za rejestrowanie i skanowanie źródeł danych. Kolekcje mogą również oddzielać źródła produkcyjne i nieprodukcyjne, gdy te źródła nie uzasadniają innej domeny mapy danych. Każde źródło danych musi być zarejestrowane w jednej kolekcji w jednej domenie Data Map. Zasoby skanowane z tego źródła pozostają skojarzone z tą strukturą. W związku z tym organizacja powinna zdefiniować zasady rozmieszczania źródeł przed szerokim wdrożeniem.

Zobacz Domeny ładu i zalecenia dotyczące domen oraz architektura domen i kolekcji oraz najlepsze praktyki w Microsoft Purview.