Skalowanie analizy w skali chmury na platformie Azure
Skalowalna platforma danych ma kluczowe znaczenie dla szybkiego wzrostu danych. Ogromne ilości danych są generowane co sekundę na całym świecie. Oczekuje się, że ilość dostępnych danych będzie nadal rosnąć wykładniczo w ciągu najbliższych kilku lat. Wraz ze wzrostem szybkości generowania danych szybkość przenoszenia danych również wzrasta.
Niezależnie od ilości posiadanych danych użytkownicy żądają szybkich odpowiedzi na zapytania. Oczekują, że będą czekać minuty, a nie godziny, na wyniki. W tym artykule wyjaśniono, jak można skalować rozwiązanie analizy w skali chmury platformy Azure i nadal spełniać wymagania użytkowników dotyczące szybkości.
Wprowadzenie
Wiele przedsiębiorstw ma monolity dużych platform danych. Te monolity są budowane wokół pojedynczego konta usługi Azure Data Lake Gen2, a czasami pojedynczego kontenera magazynowania. Pojedyncza subskrypcja platformy Azure jest często używana dla wszystkich zadań związanych z platformą danych. Skalowanie na poziomie subskrypcji jest nieobecne na większości platform architektury, co może utrudnić dalsze wdrażanie platformy Azure, jeśli użytkownicy napotkają dowolne ograniczenia subskrypcji platformy Azure lub poziomu usług . Mimo że niektóre ograniczenia są limitami miękkimi, napotkanie ich nadal może mieć znaczący negatywny wpływ na platformę danych.
Podczas tworzenia struktury platformy danych należy wziąć pod uwagę strukturę organizacji. Zwróć uwagę na własność danych i obowiązki funkcjonalne zespołów. Jeśli Twoja organizacja zapewnia zespołom duży stopień autonomii i rozproszonej własności, najlepszym rozwiązaniem jest architektura siatki danych.
Unikaj sytuacji, w których różne zespoły są odpowiedzialne za różne zadania rozwiązania — takie jak pozyskiwanie, czyszczenie, agregacja i obsługa. Poleganie na wielu zespołach może spowodować dramatyczną utratę tempa. Jeśli na przykład użytkownicy danych w warstwie obsługującej muszą dołączyć nowe zasoby danych lub zaimplementować zmiany funkcjonalne dla określonego zasobu danych, muszą przejść przez proces wieloetapowy. W tym przykładzie kroki są następujące:
- Użytkownik danych przesyła bilet do każdego zespołu odpowiedzialnego za etap potoku danych.
- Zespoły muszą współpracować w sposób zsynchronizowany, ponieważ warstwy są połączone. Nowe usługi wymagają zmian w warstwie czyszczenia danych, co prowadzi do zmian w warstwie agregacji danych, co prowadzi do zmian w warstwie obsługującej. Zmiany mogą mieć wpływ na każdy etap procesu.
- Zespołom trudno jest zobaczyć potencjalne skutki zmian przetwarzania, ponieważ nie mają one przeglądu całego cyklu życia od początku do końca. Muszą one współpracować w celu zaprojektowania szczegółowego planu wydania, który minimalizuje wpływ na istniejących konsumentów i kanały dystrybucji. To zarządzanie zależnościami zwiększa obciążenie związane z zarządzaniem.
- Z reguły zespoły nie są ekspertami w zakresie zasobu danych, którego żąda klient danych. Aby zrozumieć nowe funkcje zestawu danych lub wartości parametrów, muszą skonsultować się z ekspertem.
- Po wdrożeniu wszystkich zmian odbiorca danych jest powiadamiany, że nowy zasób danych jest gotowy do użycia.
Każda duża organizacja ma tysiące użytkowników danych. Skomplikowany proces, taki jak opisany, poważnie zmniejsza szybkość w dużych architekturach, ponieważ scentralizowane zespoły stają się wąskim gardłem dla jednostek biznesowych. Rezultatem jest mniejsza innowacja i ograniczona skuteczność. Potencjalnie jednostki biznesowe mogą zdecydować się na opuszczenie usługi i utworzenie własnej platformy danych.
Metody skalowania
Analiza w skali chmury rozwiązuje problemy ze skalowaniem przy użyciu dwóch podstawowych pojęć:
- Strefy docelowe danych na potrzeby skalowania
- Produkty danych lub integracje danych na potrzeby skalowania w celu uzyskania możliwej rozproszonej i zdecentralizowanej własności danych
Można wdrożyć pojedynczą strefę docelową danych lub wiele z nich. Strefy docelowe danych umożliwiają odnajdywanie danych i zarządzanie nimi, łącząc się ze strefą docelową zarządzania danymi. Każda strefa docelowa zarządzania danymi znajduje się w ramach jednej subskrypcji platformy Azure.
Subskrypcje to jednostki zarządzania, rozliczeń i skali platformy Azure. Odgrywają one kluczową rolę w planie wdrażania platformy Azure na dużą skalę.
Skalowanie przy użyciu stref docelowych danych
Główne pojęcia analizy w skali chmury to Microsoft Purview, Azure Databricks Unity Catalog, jeśli używasz usługi Azure Databricks, strefy docelowej zarządzania danymi i strefy docelowej danych. Każda z nich powinna znajdować się we własnej subskrypcji platformy Azure. Oddzielenie ich umożliwia wyraźne oddzielenie obowiązków, przestrzeganie zasady najniższych uprawnień i częściowe rozwiązywanie problemów ze skalowaniem subskrypcji wymienionych wcześniej. Minimalna konfiguracja analizy w skali chmury obejmuje pojedynczą strefę docelową danych i strefę docelową zarządzania danymi.
Jednak minimalna konfiguracja nie jest wystarczająca w przypadku wdrożeń platform danych na dużą skalę. Firmy tworzą platformy na dużą skalę i inwestują w spójną i wydajną skalę swoich działań związanych z danymi i analizami w czasie. Aby przezwyciężyć ograniczenia na poziomie subskrypcji, analiza w skali chmury używa subskrypcji jako jednostki skalowania, jak opisano w obszarach docelowych platformy Azure. Ta technika umożliwia zwiększenie zakresu platformy danych przez dodanie kolejnych stref przeznaczenia danych do architektury. Zastosowanie tej techniki rozwiązuje również problem jednej usługi Azure Data Lake Gen2 używanej dla całej organizacji, ponieważ każda strefa docelowa danych obejmuje trzy magazyny typu data lake. Projekty i działania z wielu domen mogą być dystrybuowane w więcej niż jednej subskrypcji platformy Azure, co zapewnia większą skalowalność.
Zdecyduj, ile stref docelowych danych wymaga twoja organizacja przed wdrożeniem architektury analizy w skali chmury. Wybranie odpowiedniego rozwiązania stanowi podstawę efektywnej i wydajnej platformy danych.
Wymagana liczba wymaganych stref docelowych danych zależy od wielu czynników, szczególnie:
- Dopasowanie organizacyjne, takie jak liczba jednostek biznesowych, które potrzebują własnej strefy docelowej danych
- Zagadnienia operacyjne, takie jak dopasowanie organizacji zasobów operacyjnych i zasobów specyficznych dla jednostki biznesowej.
Użycie odpowiedniego modelu strefy docelowej danych minimalizuje przyszłe wysiłki, aby przenieść produkty danych i zasoby danych z jednej strefy docelowej do innej. Ułatwia również efektywne i spójne skalowanie danych big data i działań analitycznych w przyszłości.
Podczas decydowania o liczbie stref docelowych danych do wdrożenia należy wziąć pod uwagę następujące czynniki.
| Czynnik | Opis |
|---|---|
| Struktura organizacyjna i własność danych | Zastanów się, w jaki sposób organizacja ma strukturę i jak dane są własnością organizacji. |
| Region i lokalizacja | W przypadku wdrożenia w wielu regionach zdecyduj, które regiony powinny obsługiwać strefy danych. Upewnij się, że przestrzegasz wszystkich wymagań dotyczących rezydencji danych. |
| Kontyngent | Limity przydziału subskrypcji nie są gwarancjami pojemności i są stosowane dla poszczególnych regionów. |
| Niezależność danych | Ze względu na przepisy dotyczące niezależności danych dane muszą być przechowywane w określonym regionie i przestrzegać zasad specyficznych dla regionu. |
| Zasady platformy Azure | Strefy docelowe danych muszą spełniać wymagania różnych zasad platformy Azure. |
| Granica zarządzania | Subskrypcje zapewniają granicę zarządzania dla zarządzania i izolacji, które wyraźnie oddzielają zagadnienia. |
| Sieci | Każda strefa docelowa ma sieć wirtualną. Ponieważ sieć wirtualna znajduje się w jednym regionie, każdy nowy region wymaga nowej strefy docelowej. Sieci wirtualne muszą być równorzędnymi sieciami, aby umożliwić komunikację między domenami. |
| Limity | Subskrypcja ma limity. Mając kilka subskrypcji, możesz ograniczyć niebezpieczeństwa związane z osiąganiem tych limitów. |
| Alokacja kosztów | Rozważ, czy usługi udostępnione, takie jak konta magazynu płatne centralnie, muszą być podzielone według jednostki biznesowej lub domeny. Użycie oddzielnej subskrypcji tworzy granicę alokacji kosztów. Te same funkcje można osiągnąć przy użyciu tagów. |
| Klasyfikacje danych i wysoce poufne dane | Mechanizmy zabezpieczeń mogą mieć wpływ na rozwój produktów danych i użyteczność platformy danych. Rozważ klasyfikacje danych i zdecyduj, czy wysoce poufne zestawy danych wymagają specjalnego traktowania, takiego jak dostęp just in time, klucze zarządzane przez klienta (CMK), szczegółowe mechanizmy kontroli sieci lub więcej szyfrowania. |
| Inne konsekwencje prawne lub związane z bezpieczeństwem | Zastanów się, czy istnieją inne wymagania prawne lub wymagania dotyczące zabezpieczeń, które wymagają logicznego lub fizycznego rozdzielenia danych. |
W przypadku zaimplementowania architektury siatki danych należy wziąć pod uwagę następujące czynniki, gdy zdecydujesz, jak dystrybuować strefy docelowe danych i domeny danych.
| Czynnik | Opis |
|---|---|
| Domeny danych | Należy wziąć pod uwagę domeny danych używane przez organizację i zdecydować o domenach danych dla platformy danych. Rozważ rozmiar poszczególnych domen danych. Aby uzyskać więcej informacji, zobacz Co to są domeny danych? |
| Opóźnienie | Domeny współpracujące z dużymi ilościami danych mogą przesyłać duże ilości danych między strefami docelowymi. Rozważ przydzielenie domen w tej samej strefie docelowej lub regionie. Oddzielenie ich zwiększa opóźnienie i może zwiększyć koszty w domenach między regionami. |
| Bezpieczeństwo | Niektóre wdrożenia usługi lub konfiguracje wymagają podniesionych uprawnień w subskrypcji. Przyznanie tych uprawnień użytkownikowi w jednej domenie niejawnie daje temu użytkownikowi te same uprawnienia w innych domenach w ramach tej samej subskrypcji. |
Więcej zagadnień można znaleźć w przewodniku dotyczącym wdrażania chmury dla subskrypcji .
Wiele organizacji chce wydajnego skalowania platformy danych przedsiębiorstwa. Jednostki biznesowe powinny mieć możliwość tworzenia własnych rozwiązań i aplikacji danych w celu spełnienia ich unikatowych wymagań. Zapewnienie tej możliwości może być wyzwaniem, ponieważ wiele istniejących platform danych nie jest opartych na pojęciach skalowalności i zdecentralizowanej własności. Ten brak jest wyraźnie widoczny w modelu architektury, struktury zespołu i operacji tych platform danych.
Strefy docelowe danych nie tworzą silosów danych w organizacji. Zalecana konfiguracja sieci na potrzeby analizy w skali chmury umożliwia bezpieczne i miejscowe udostępnianie danych w różnych strefach docelowych, co z kolei umożliwia innowacje między domenami danych i jednostkami biznesowymi. Aby dowiedzieć się więcej, zobacz Zagadnienia dotyczące architektury sieci.
To samo dotyczy warstwy tożsamości. Korzystając z jednej dzierżawy Microsoft Entra, można przyznać dostęp tożsamościom do zasobów danych w wielu strefach przyjmowania danych. Aby dowiedzieć się więcej na temat procesu autoryzacji użytkowników i tożsamości, zobacz Zarządzanie dostępem do danych.
Notatka
Jeśli masz wiele stref docelowych danych, każda strefa może łączyć się z danymi hostowanymi w innych strefach. Umożliwia to grupom współpracę w całej firmie.
Analiza w skali chmury używa wspólnej architektury, aby opowiadać się za spójnym ładem. Twoja architektura definiuje podstawowe możliwości i zasady. Wszystkie strefy docelowe danych są zgodne z tymi samymi mechanizmami inspekcji i mechanizmami kontroli. Zespoły mogą tworzyć potoki danych, pozyskiwać źródła i tworzyć produkty danych, takie jak raporty i pulpity nawigacyjne. Zespoły mogą również wykonywać analizę spark/SQL zgodnie z potrzebami. Możliwości strefy docelowej danych można rozszerzyć, dodając usługi do możliwości w zasadach. Na przykład zespół może dodać silnik grafowy innej firmy, aby zrealizować wymagania biznesowe.
Analiza w skali chmury stawia silny nacisk na centralne katalogowanie i klasyfikację, aby chronić dane i umożliwić różnym grupom odnajdywanie produktów danych.
Ostrożność
Zalecamy, aby nie wykonywać zapytań dotyczących danych w różnych regionach. Zamiast tego upewnij się, że dane są blisko zasobów obliczeniowych, które go używają, przy jednoczesnym poszanowaniu granic regionalnych.
Architektura analizy w skali chmury i koncepcja stref docelowych danych umożliwiają organizacji łatwe zwiększenie rozmiaru platformy danych w czasie. Możesz dodać więcej stref docelowych danych w podejściu fazowym. Klienci nie muszą mieć na początku wielu stref docelowych. Podczas wdrażania tej architektury należy określić priorytety kilku stref docelowych danych i produktów danych, które zawierają. Właściwa priorytetyzacja pomaga zapewnić sukces wdrożenia analizy w skali chmury.
Skalowanie za pomocą aplikacji danych
W każdej strefie docelowej organizacja może skalać swoje działania przy użyciu aplikacji do obsługi danych. Aplikacje danych to jednostki lub składniki architektury danych, które hermetyzują funkcje, które zapewniają produkty danych zoptymalizowane pod kątem odczytu do użycia przez inne aplikacje danych. Na platformie Azure aplikacje danych to środowiska w postaci grup zasobów, które umożliwiają zespołom funkcjonalnym implementowanie rozwiązań i obciążeń danych. Skojarzony zespół zajmuje się całym cyklem życia rozwiązania danych, w tym pozyskiwaniem, czyszczeniem, agregacją i obsługą zadań.
Analiza w skali chmury rozwiązuje problemy z integracją danych i odpowiedzialnością, które zostały omówione wcześniej. Zamiast monolitycznych obowiązków funkcjonalnych dotyczących pozyskiwania tabel i integracji systemu źródłowego, projekt referencyjny zapewnia architekturę rozproszoną opartą na domenach danych. Zespoły wielofunkcyjne przejmują kompleksową odpowiedzialność funkcjonalną i własność zakresu danych.
Zamiast scentralizowanego stosu technicznego i zespołu odpowiedzialnego za wszystkie zadania przepływu pracy przetwarzania danych, można rozdzielić kompleksową odpowiedzialność między wieloma autonomicznymi zespołami integracji danych funkcjonalnych. Każdy zespół jest właścicielem domeny lub poddomeny i jest zachęcany do obsługi zestawów danych zgodnie z wymaganiami użytkowników danych.
Te różnice architektoniczne prowadzą do zwiększenia szybkości działania platformy danych. Użytkownicy danych nie muszą już polegać na zestawie scentralizowanych zespołów lub walczyć o ich żądane zmiany, które mają być priorytetowe. Ponieważ mniejsze zespoły przejmują odpowiedzialność za całościowe przepływy pracy integracji, cykl informacji zwrotnej między dostawcą danych a odbiorcą danych jest krótszy. Takie podejście powoduje szybsze ustalanie priorytetów, szybsze cykle programowania i bardziej elastyczny proces programowania. Zespoły nie muszą już synchronizować między sobą procesów i planów wydawania, ponieważ zespół integracji danych funkcjonalnych ma pełną świadomość kompleksowego stosu technicznego i skutków zmian. Dzięki praktykom inżynieryjnym oprogramowania można uruchamiać testy jednostkowe i integracyjne w celu zminimalizowania ogólnego wpływu na konsumentów.
W idealnym przypadku zespół, który jest właścicielem systemów integracji danych, jest również właścicielem systemów źródłowych. Ten zespół powinien składać się z inżynierów danych, którzy pracują nad systemami źródłowymi, ekspertami z dziedziny (MŚP) dla zestawów danych, inżynierów ds. chmury i właścicieli produktów danych. Tworzenie tego rodzaju zespołu międzyfunkcyjnego zmniejsza ilość komunikacji potrzebnej z zespołami zewnętrznymi i jest niezbędne podczas opracowywania kompletnego stosu od infrastruktury do rzeczywistych potoków danych.
Podstawą platformy danych są zestawy danych zintegrowane z systemów źródłowych. Te zestawy danych umożliwiają zespołom ds. produktów danych wprowadzanie innowacji w tabelach faktów biznesowych oraz ulepszanie procesów decyzyjnych i biznesowych. Zespoły integracji danych i zespoły ds. produktów danych powinny oferować umowy SLA konsumentom i zapewnić spełnienie wszystkich umów. Oferowane SLA mogą być powiązane z jakością danych, terminowością, współczynnikami błędów, czasem dostępności i innymi zadaniami.
Streszczenie
Korzystanie z mechanizmów skalowania architektury analizy w skali chmury umożliwia organizacji rozszerzanie majątku danych na platformie Azure w czasie, unikając typowych ograniczeń technicznych. Obie metody skalowania opisane w tym artykule ułatwiają przezwyciężenie różnych złożoności technicznych i mogą być używane w prosty i wydajny sposób.