Najlepsze rozwiązania: Konfiguracja klastra

Azure Databricks udostępnia wiele opcji podczas tworzenia i konfigurowania klastrów, aby ułatwić uzyskiwanie najlepszej wydajności przy najniższych kosztach. Ta elastyczność może jednak tworzyć wyzwania podczas próby określenia optymalnych konfiguracji ’ dla obciążeń. Dokładne rozważenie sposobu, w jaki użytkownicy będą korzystać z klastrów, pomoże w kierowaniu opcjami konfiguracji podczas tworzenia nowych lub konfigurowania istniejących klastrów. Podczas określania opcji konfiguracji należy wziąć pod uwagę następujące czynniki:

  • Jakiego typu użytkownik będzie używać klastra? Analityk danych może uruchamiać różne typy zadań o różnych wymaganiach niż inżynier danych lub analityk danych.
  • Jakie typy obciążeń będą uruchamiać użytkownicy w klastrze? Na przykład zadania wyodrębniania, przekształcania i ładowania wsadowego (ETL) prawdopodobnie będą mieć inne wymagania niż obciążenia analityczne.
  • Jaki poziom umowy sla (service level agreement) musisz spełnić?
  • Jakie masz ograniczenia budżetowe?

Ten artykuł zawiera zalecenia dotyczące konfiguracji klastra dla różnych scenariuszy w oparciu o te zagadnienia. W tym artykule omówiono również konkretne funkcje Azure Databricks klastrów oraz zagadnienia, które należy wziąć pod uwagę w przypadku tych funkcji.

Decyzje dotyczące konfiguracji będą wymagały kompromisu między kosztami i wydajnością. Podstawowy koszt klastra obejmuje jednostki usługi Databricks (DBU) używane przez klaster oraz koszt podstawowych zasobów potrzebnych do uruchomienia klastra. Co może nie być oczywiste, są koszty pomocnicze, takie jak koszt dla firmy, który nie spełnia umowy SLA, obniżona wydajność pracowników lub możliwe marnowanie zasobów z powodu słabej kontroli.

Funkcje klastra

Przed omówieniem bardziej szczegółowych scenariuszy konfiguracji klastra ważne jest, aby zrozumieć niektóre funkcje klastrów Azure Databricks i jak najlepiej ’ używać tych funkcji.

Klastry wszystkiego przeznaczenia i klastry zadań

Podczas tworzenia klastra wybierasz typ klastra: klaster wszystkiego przeznaczenia lub klaster zadań. Klastry wszelkiego przeznaczenia mogą być współużytkowanie przez wielu użytkowników i najlepiej wykonywać analizy ad hoc, eksplorowanie danych lub opracowywanie. Po zakończeniu implementowania przetwarzania i przygotowaniu go do operacji kodu przełącz się na uruchamianie ’ go w klastrze zadań. Klastry zadań kończą się po zakończeniu zadania, co zmniejsza użycie zasobów i obniża koszty.

Tryb klastra

Azure Databricks obsługuje trzy tryby klastra:Standardowy, Wysoka współbieżność i Pojedynczy węzeł. Większość zwykłych użytkowników używa klastrów standardowych lub jednowęzłowych.

  • Klastry standardowe idealnie nadają się do przetwarzania dużych ilości danych przy użyciu Apache Spark.
  • Klastry z jednym węzłem są przeznaczone dla zadań, które korzystają z małych ilości danych lub niezproszonych obciążeń, takich jak biblioteki uczenia maszynowego z jednym węzłem.
  • Klastry o wysokiej współbieżności są idealne dla grup użytkowników, którzy muszą udostępniać zasoby lub uruchamiać zadania ad hoc. Administratorzy zazwyczaj tworzą klastry o wysokiej współbieżności. Usługa Databricks zaleca włączenie skalowania automatycznego dla klastrów o wysokiej współbieżności.

Wystąpienia na żądanie i wystąpienia typu spot

Aby zaoszczędzić koszty, Azure Databricks obsługuje tworzenie klastrów przy użyciu kombinacji wystąpień typu spot i na żądanie. Za pomocą wystąpień punktowych można wykorzystać nieużywaną pojemność na platformie Azure, aby zmniejszyć koszt uruchamiania aplikacji, zwiększyć pojemność obliczeniową aplikacji i ’ zwiększyć przepływność.

Skalowanie automatyczne

Autoskalowanie umożliwia klastrom automatyczne zmienianie rozmiaru na podstawie obciążeń. Autoskalowanie może korzystać z wielu przypadków użycia i scenariuszy zarówno z punktu widzenia kosztów, jak i wydajności, ale zrozumienie, kiedy i jak używać skalowania automatycznego, może być trudne. Poniżej przedstawiono niektóre zagadnienia dotyczące określania, czy używać skalowania automatycznego i jak uzyskać największe korzyści:

  • Skalowanie automatyczne zwykle zmniejsza koszty w porównaniu do klastra o stałym rozmiarze.
  • Obciążenia skalowania automatycznego mogą działać szybciej w porównaniu z klastrem o stałym rozmiarze, który nie został zaaprowizowany.
  • Niektóre obciążenia nie są zgodne z klastrami skalowania automatycznego, w tym zadania spark-submit i niektóre pakiety języka Python.
  • W przypadku klastrów wszystkich celów dla jednego użytkownika skalowanie automatyczne może spowalniać opracowywanie lub analizę, gdy minimalna liczba węzłów pracy jest ustawiona na zbyt małą. Wynika to z tego, że uruchomione polecenia lub zapytania są często od siebie od siebie od kilku minut, a klaster jest bezczynny i może być skalowany w dół, aby ’ zaoszczędzić na kosztach. Po wykonaniu następnego polecenia menedżer klastra podejmie próbę skalowania w górę, co potrwa kilka minut podczas pobierania wystąpień od dostawcy chmury. W tym czasie zadania mogą być uruchamiane z niewystarczającą ilość zasobów, co spowalnia czas pobierania wyników. Zwiększenie minimalnej liczby pracowników pomaga, ale również zwiększa koszty. Jest to kolejny przykład, w którym należy zrównoważyć koszt i wydajność.
  • Jeśli jest Buforowanie danych różnicowych, należy pamiętać, że wszelkie buforowane dane w węźle zostaną utracone, jeśli ten węzeł zostanie zakończony. Jeśli zachowywanie buforowanych danych jest ważne dla obciążenia, rozważ użycie klastra o stałym rozmiarze.
  • Jeśli masz klaster zadań z uruchomionym obciążeniem ETL, możesz czasami odpowiednio zmienić rozmiar klastra podczas dostrajania, jeśli wiesz, że jego zmiana jest mało prawdopodobna. Jednak skalowanie automatyczne zapewnia elastyczność w przypadku zwiększenia rozmiaru danych. Warto również zauważyć, że zoptymalizowane skalowanie automatyczne może zmniejszyć wydatki w przypadku długotrwałych zadań, jeśli istnieją długie okresy, gdy klaster jest niedostatecznie w pełni lub oczekuje na wyniki z ’ innego procesu. Jednak w przypadku zadania mogą wystąpić niewielkie opóźnienia, ponieważ klaster próbuje odpowiednio skalować w górę. Jeśli masz ścisłe umowy SLA dla zadania, klastry o stałym rozmiarze mogą być lepszym rozwiązaniem lub rozważyć użycie puli Azure Databricks w celu skrócenia czasu uruchamiania klastra.

Azure Databricks obsługuje również skalowanie automatyczne magazynu lokalnego. Dzięki automatyczneowi skalowania magazynu lokalnego Azure Databricks monitoruje ilość wolnego miejsca na dysku dostępnego w ’ klastrach węzłów węzłów Spark. Jeśli proces roboczy zaczyna działać na dysku, Azure Databricks automatycznie dołącza nowy wolumin zarządzany do procesu roboczego, zanim zabraknie miejsca na dysku.

Baseny

Pule skracają czas uruchamiania i skalowania klastra przez utrzymywanie zestawu dostępnych, gotowych do użycia wystąpień. Databricks zaleca korzystanie z pul w celu zwiększenia czasu przetwarzania przy jednoczesnym zminimalizowaniu kosztów.

Databricks Runtime wersji

Usługa Databricks zaleca używanie najnowszej Databricks Runtime dla klastrów wszelkiego przeznaczenia. Użycie najnowszej wersji zapewni najnowsze optymalizacje i najbardziej aktualną zgodność między kodem a wstępnie załadowanych pakietami.

W przypadku klastrów zadań z uruchomionymi obciążeniami operacyjnymi rozważ użycie wersji lts (Long Term Support) Databricks Runtime wersji. Korzystanie z wersji LTS gwarantuje, że nie będą problemy ze zgodnością i będzie ’ można dokładnie przetestować obciążenie przed uaktualnieniem. Jeśli masz zaawansowany przypadek użycia uczenia maszynowego lub genomiki, rozważ użycie wyspecjalizowanych Databricks Runtime maszynowych.

Zasady klastra

Azure Databricks klastrów umożliwiają administratorom wymuszanie kontroli nad tworzeniem i konfiguracją klastrów. Usługa Databricks zaleca używanie zasad klastra w celu zastosowania zaleceń omówiowanych w tym przewodniku. Dowiedz się więcej o zasadach klastra w przewodniku po najlepszych rozwiązaniach dotyczących zasad klastra.

Automatyczne zakończenie

Wielu użytkowników nie ’ myśli, aby zakończyć działanie klastrów po ’ zakończeniu korzystania z nich. Na szczęście klastry są automatycznie przerywane po upływie ustawionego okresu z wartością domyślną 120 minut.

Administratorzy mogą zmienić to ustawienie domyślne podczas tworzenia zasad klastra. Zmniejszenie tego ustawienia może obniżyć koszty przez skrócenie czasu bezczynności klastrów. Należy pamiętać, że po zakończeniu działania klastra cały stan zostanie utracony, łącznie ze wszystkimi zmiennymi, tabelami tymczasowymi, pamięciami ’ podręcznymi, funkcjami, obiektami itd. Cały ten stan będzie musiał zostać przywrócony, gdy klaster zostanie ponownie uruchomiony. Jeśli deweloper wytnie się na 30-minutową przerwę na lunch, marnowanie tego samego czasu na powrót do tego samego stanu, co wcześniej, byłoby marnowane.

Ważne

Bezczynne klastry nadal kumulują opłaty za wystąpienia dbu i chmury w okresie braku aktywności przed zakończeniem działania.

Odzyskiwanie pamięci

Chociaż może to być mniej oczywiste niż inne zagadnienia omówione w tym artykule, zwrócenie uwagi na odzyskiwanie pamięci może pomóc zoptymalizować wydajność zadań w klastrach. Zapewnienie dużej ilości pamięci RAM może ułatwić wykonywanie zadań wydajniej, ale może również prowadzić do opóźnień podczas wyrzucania elementów bezużytecznych.

Aby zminimalizować wpływ długich czyszczenia pamięci, należy unikać wdrażania klastrów z dużą ilością pamięci RAM skonfigurowaną dla każdego wystąpienia. Przydzielenie większej ilości pamięci RAM do wykonawcy spowoduje dłuższy czas wyrzucania elementów bezużytecznych. Zamiast tego należy skonfigurować wystąpienia o mniejszych rozmiarach pamięci RAM i wdrożyć więcej wystąpień, jeśli potrzebujesz więcej pamięci na potrzeby zadań. Istnieją jednak przypadki, w których zaleca się użycie mniejszej liczby węzłów z większą ilością pamięci RAM, na przykład obciążeń, które wymagają wielu mieszania, zgodnie z omówieniem w artykule Cluster sizing considerations(Zagadnienia dotyczące rozmiaru klastra).

Kontrola dostępu do klastra

Można skonfigurować dwa typy uprawnień klastra:

  • Uprawnienie Zezwalaj na tworzenie klastra kontroluje możliwość tworzenia klastrów przez użytkowników.
  • Uprawnienia na poziomie klastra kontrolują możliwość używania i modyfikowania określonego klastra.

Aby dowiedzieć się więcej na temat konfigurowania uprawnień klastra, zobacz kontrola dostępu do klastra.

Klaster można utworzyć, jeśli masz uprawnienia do tworzenia klastra lub dostęp do zasad klastra, co umożliwia utworzenie dowolnego klastra w ’ ramach specyfikacji zasad. Twórca klastra jest właścicielem i ma uprawnienia Może zarządzać, które umożliwią mu udostępnienie go innym użytkownikom w ramach ograniczeń uprawnień dostępu do danych klastra.

Zrozumienie uprawnień klastra i zasad klastra jest ważne podczas podejmowania decyzji o konfiguracjach klastra dla typowych scenariuszy.

Tagi klastra

Tagi klastra umożliwiają łatwe monitorowanie kosztów zasobów w chmurze używanych przez różne grupy w organizacji. Tagi można określić jako ciągi klucz-wartość podczas tworzenia klastra, a Azure Databricks te tagi będą stosowane do zasobów w chmurze, takich jak wystąpienia i woluminy EBS. Dowiedz się więcej na temat wymuszania tagów w przewodniku po najlepszych rozwiązaniach dotyczących zasad klastra.

Zagadnienia do rozważenia dotyczące rozmiaru klastra

Usługa Azure Databricks uruchamia jedną funkcję wykonawczą na węzeł roboczy. W związku z tym terminy wykonawca i proces roboczy są używane zamiennie w kontekście Azure Databricks architektury. Często patrzy się na wielkość klastra przez pryzmat liczby węzłów roboczych, ale istnieją inne ważne czynniki, które należy wziąć pod uwagę:

  • Łączna liczba rdzeni wykonawczych (obliczeniowych): łączna liczba rdzeni we wszystkich wykonawcach. Określa maksymalną równoległość klastra.
  • Łączna pamięć wykonawcza: łączna ilość pamięci RAM dla wszystkich wykonawców. Określa to, ile danych można przechowywać w pamięci przed rozlaniem ich na dysk.
  • Magazyn lokalny wykonawcy: typ i ilość magazynu na dysku lokalnym. Dysk lokalny jest używany głównie w przypadku rozlania podczas mieszania i buforowania.

Dodatkowe zagadnienia obejmują typ i rozmiar wystąpienia procesu roboczego, które również wpływają na powyższe czynniki. Podczas zmiany rozmiaru klastra należy wziąć pod uwagę:

  • Ile danych będzie zużywać obciążenie?
  • Jaka ’ jest złożoność obliczeniowa obciążenia?
  • Skąd odczytujesz dane?
  • W jaki sposób dane są partycjonowane w magazynie zewnętrznym?
  • Jaka równoległość jest potrzebna?

Udzielenie odpowiedzi na te pytania pomoże określić optymalne konfiguracje klastra na podstawie obciążeń. W przypadku prostych obciążeń w stylu ETL, które używają tylko wąskich przekształceń (przekształceń, w których każda partycja wejściowa będzie współuścić tylko jedną partycję wyjściową), skoncentruj się na konfiguracji zoptymalizowanej pod kątem obliczeń. Jeśli spodziewasz się dużej ilości mieszania, ważne jest ilość pamięci, a także magazyn, który będzie uwzględniać rozlanie danych. Mniejsza liczba dużych wystąpień może zmniejszyć liczbę we/wy sieci podczas przesyłania danych między maszynami podczas obciążeń o dużym obciążeniu mieszanym.

Istnieje równoważenie liczby procesów roboczych i rozmiaru ’ typów wystąpień procesów roboczych. Klaster z dwoma procesami roboczymi, z których każdy ma 40 rdzeni i 100 GB pamięci RAM, ma takie same zasoby obliczeniowe i pamięć jak osiem klastrów procesów roboczych z 10 rdzeniami i 25 GB pamięci RAM.

Jeśli oczekujesz wielu ponownych odczytów tych samych danych, buforowanie obciążeń może być korzystne. Rozważ konfigurację zoptymalizowaną pod kątem magazynu za pomocą usługi Delta Cache.

Przykłady rozmiarów klastrów

W poniższych przykładach przedstawiono zalecenia dotyczące klastra na podstawie określonych typów obciążeń. Te przykłady obejmują również konfiguracje, których można uniknąć, oraz przyczyny, dla których te konfiguracje nie są odpowiednie dla typów obciążeń.

Analiza danych

Analitycy danych zwykle wykonują przetwarzanie wymagające danych z wielu partycji, co prowadzi do wielu operacji mieszania. Klaster o mniejszej liczbie węzłów może zmniejszyć liczbę operacji we/wy sieci i dysku wymaganych do wykonania tych mieszanych operacji. Klaster A na poniższym diagramie jest prawdopodobnie najlepszym wyborem, szczególnie w przypadku klastrów, które obsługują jednego analityka.

Klaster D prawdopodobnie zapewni najgorszą wydajność, ponieważ większa liczba węzłów z mniejszą pamięcią i magazynem będzie wymagać większej ilości danych do ukończenia przetwarzania.

Data analysis cluster sizing

Obciążenia analityczne prawdopodobnie będą wymagać wielokrotnego odczytywania tych samych danych, dlatego zalecane typy procesów roboczych są zoptymalizowane pod kątem magazynu z włączoną usługą Delta Cache.

Dodatkowe funkcje zalecane dla obciążeń analitycznych obejmują:

  • Włącz automatyczne przerywanie, aby upewnić się, że klastry są przerywane po upływie okresu braku aktywności.
  • Rozważ włączenie skalowania automatycznego na podstawie typowego obciążenia ’ analityka.
  • Rozważ użycie pul, które umożliwią ograniczenie klastrów do wstępnie zatwierdzonych typów wystąpień i zapewni spójne konfiguracje klastrów.

Funkcje, które prawdopodobnie nie są przydatne:

  • Storage skalowanie automatyczne, ponieważ ten użytkownik prawdopodobnie nie będzie tworzyć wielu danych.
  • Klastry o wysokiej współbieżności, ponieważ ten klaster jest przeznaczony dla jednego użytkownika, a klastry o wysokiej współbieżności najlepiej nadają się do współużytkowania.

ETL wsadu podstawowego

Proste zadania ETL wsadowe, które nie wymagają szerokich przekształceń, takich jak sprzężenia lub agregacje, zwykle korzystają z klastrów zoptymalizowanych ’ pod kątem obliczeń. W przypadku tego typu obciążeń dowolny z klastrów na poniższym diagramie jest prawdopodobnie akceptowalny.

Basic batch ETL cluster sizing

Zalecane są typy procesów roboczych zoptymalizowane pod kątem obliczeń. Będą one tańsze, a te obciążenia prawdopodobnie nie będą wymagały znacznej ilości pamięci ani magazynu.

Użycie puli może być korzystne dla klastrów, które obsługują proste zadania ETL, skracając czas uruchamiania klastra i zmniejszając całkowity czas wykonywania podczas uruchamiania potoków zadań. Jednak ze względu na to, że tego typu obciążenia są zwykle uruchamiane jako zaplanowane zadania, w przypadku których klaster działa wystarczająco długo, aby ukończyć zadanie, użycie puli może nie zapewnić korzyści.

Następujące funkcje prawdopodobnie nie ’ są przydatne:

  • Różnica Buforowanie, ponieważ ponowne odczytywanie danych nie jest oczekiwane.
  • Automatyczne zakończenie prawdopodobnie nie ’ jest wymagane, ponieważ są to prawdopodobnie zaplanowane zadania.
  • Skalowanie automatyczne nie jest zalecane, ponieważ obliczenia i magazyn powinny być wstępnie skonfigurowane dla przypadku użycia.
  • Klastry o wysokiej współbieżności są przeznaczone dla wielu użytkowników i nie będą korzystne ’ dla klastra z uruchomionym jednym zadaniem.

Złożone partie ETL

Bardziej złożone zadania ETL, takie jak przetwarzanie wymagające unii i sprzężenia w wielu tabelach, będą prawdopodobnie działać najlepiej, gdy można zminimalizować ilość mieszanych danych. Ponieważ zmniejszenie liczby węzłów pracy w klastrze pomoże zminimalizować mieszanie, należy rozważyć mniejszy klaster, taki jak klaster A na poniższym diagramie, na większym klastrze, na przykład klastrze D.

Complex ETL cluster sizing

Złożone przekształcenia mogą wymagać intensywnych obliczeń, dlatego w przypadku niektórych obciążeń, które osiągną optymalną liczbę rdzeni, może być konieczne dodanie dodatkowych węzłów do klastra.

Podobnie jak w przypadku prostych zadań ETL, zalecane są typy procesów roboczych zoptymalizowane pod kątem obliczeń. Będą one tańsze, a te obciążenia prawdopodobnie nie będą wymagały znacznej ilości pamięci ani magazynu. Podobnie jak w przypadku prostych zadań ETL, główną funkcją klastra, która należy wziąć pod uwagę, są pule, które skracają czas uruchamiania klastra i zmniejszają całkowity czas wykonywania podczas uruchamiania potoków zadań.

Następujące funkcje prawdopodobnie nie ’ są przydatne:

  • Różnica Buforowanie, ponieważ ponowne odczytywanie danych nie jest oczekiwane.
  • Automatyczne zakończenie prawdopodobnie nie ’ jest wymagane, ponieważ są to prawdopodobnie zaplanowane zadania.
  • Skalowanie automatyczne nie jest zalecane, ponieważ obliczenia i magazyn powinny być wstępnie skonfigurowane dla przypadku użycia.
  • Klastry o wysokiej współbieżności są przeznaczone dla wielu użytkowników i nie będą korzystne ’ dla klastra z uruchomionym jednym zadaniem.

Trenowania modeli uczenia maszynowego

Ponieważ początkowe iteracje trenowania modelu uczenia maszynowego są często eksperymentalne, mniejszy klaster, taki jak klaster A, jest dobrym wyborem. Mniejszy klaster zmniejszy również wpływ mieszania.

Jeśli stabilność jest problemem lub w przypadku bardziej zaawansowanych etapów, dobrym wyborem może być większy klaster, taki jak klaster B lub C.

Duży klaster, taki jak klaster D, nie jest zalecany ze względu na obciążenie związane z dusić danymi między węzłami.

Machine learning cluster sizing

Zalecane typy procesów roboczych to magazyn zoptymalizowany pod kątem Buforowanie delta, który umożliwia obsługę powtarzających się odczytów tych samych danych i buforowanie danych szkoleniowych. Jeśli opcje obliczeniowe i magazynowe udostępniane przez węzły zoptymalizowane pod kątem magazynu nie są wystarczające, rozważ węzły zoptymalizowane pod kątem procesora GPU. Możliwą minusem jest brak obsługi Buforowanie delta w tych węzłach.

Dodatkowe funkcje zalecane dla obciążeń analitycznych obejmują:

  • Włącz automatyczne przerywanie, aby upewnić się, że klastry są przerywane po upływie okresu braku aktywności.
  • Rozważ włączenie skalowania automatycznego na podstawie typowego obciążenia ’ analityka.
  • Użyj pul, które umożliwią ograniczenie klastrów do wstępnie zatwierdzonych typów wystąpień i zapewni spójne konfiguracje klastrów.

Funkcje, które prawdopodobnie nie są przydatne:

  • Skalowanie automatyczne, ponieważ dane buforowane mogą zostać utracone po usunięciu węzłów w przypadku skalowania klastra w dół. Ponadto typowe zadania uczenia maszynowego często korzystają ze wszystkich dostępnych węzłów. W takim przypadku autoskalowanie nie zapewni żadnych korzyści.
  • Storage skalowanie automatyczne, ponieważ ten użytkownik prawdopodobnie nie będzie tworzyć wielu danych.
  • Klastry o wysokiej współbieżności, ponieważ ten klaster jest przeznaczony dla jednego użytkownika, a klastry o wysokiej współbieżności najlepiej nadają się do współużytkowania.

Typowe scenariusze

W poniższych sekcjach przedstawiono dodatkowe zalecenia dotyczące konfigurowania klastrów dla typowych wzorców użycia klastra:

  • Wielu użytkowników uruchamia analizę danych i przetwarzanie ad hoc.
  • Wyspecjalizowane przypadki użycia, takie jak uczenie maszynowe.
  • Obsługa zaplanowanych zadań wsadowych.

Klastry dla wielu użytkowników

Scenariusz

Musisz zapewnić wielu użytkownikom dostęp do danych na potrzeby uruchamiania analizy danych i zapytań ad hoc. Użycie klastra może zmieniać się w czasie, a większość zadań nie wymaga dużej ilości zasobów. Użytkownicy w większości wymagają dostępu tylko do odczytu do danych i chcą przeprowadzać analizy lub tworzyć pulpity nawigacyjne za pomocą prostego interfejsu użytkownika.

Zalecanym podejściem do aprowizowania klastrów jest hybrydowe podejście do aprowizowania węzłów w klastrze wraz ze skalowaniem automatycznym. Podejście hybrydowe obejmuje zdefiniowanie liczby wystąpień na żądanie i wystąpień typu spot dla klastra oraz włączenie skalowania automatycznego między minimalną i maksymalną liczbą wystąpień.

Multi-user scenario

Ten klaster jest domyślnie zawsze dostępny i udostępniany użytkownikom należącym do grupy. Włączenie skalowania automatycznego umożliwia klastrowi skalowanie w górę i w dół w zależności od obciążenia.

Użytkownicy nie mają dostępu do uruchamiania/zatrzymywania klastra, ale początkowe wystąpienia na żądanie są natychmiast dostępne do odpowiadania na zapytania użytkowników. Jeśli zapytanie użytkownika wymaga większej pojemności, autoskalowanie automatycznie administracyjnych większej liczby węzłów (przede wszystkim wystąpień typu spot) w celu uwzględnienia obciążenia.

Azure Databricks ma inne funkcje, które jeszcze bardziej ulepszają przypadki użycia z wieloma użytkowaniami:

Takie podejście pozwala utrzymać ogólny koszt na:

  • Korzystanie z udostępnionego modelu klastra.
  • Używanie kombinacji wystąpień na żądanie i wystąpień typu spot.
  • Używanie skalowania automatycznego w celu uniknięcia płacenia za nie w pełni w pełni wykorzystujące klastry.

Wyspecjalizowane obciążenia

Scenariusz

Należy udostępnić klastry dla wyspecjalizowanych przypadków użycia lub zespołów w organizacji, na przykład dla naukowców zajmujących się złożonymi eksplorowania danych i algorytmami uczenia maszynowego. Typowym wzorcem jest to, że użytkownik potrzebuje klastra przez krótki czas, aby uruchomić analizę.

Najlepszym rozwiązaniem dla tego rodzaju obciążenia jest utworzenie zasad klastra ze wstępnie zdefiniowanymi konfiguracjami dla zakresów domyślnych, stałych i ustawień. Te ustawienia mogą obejmować liczbę wystąpień, typów wystąpień, wystąpień typu spot i na żądanie, role, biblioteki do zainstalowania itd. Korzystanie z zasad klastra umożliwia użytkownikom z bardziej zaawansowanymi wymaganiami szybkie tworzenie klastrów, które mogą konfigurować zgodnie z potrzebami w przypadku użycia, oraz wymuszanie kosztów i zgodności z zasadami.

Specialized workloads

Takie podejście zapewnia użytkownikom większą kontrolę przy jednoczesnym zachowaniu możliwości utrzymania kontroli nad kosztami dzięki wstępnemu zdefiniowaniu konfiguracji klastra. Umożliwia to również konfigurowanie klastrów dla różnych grup użytkowników z uprawnieniami dostępu do różnych zestawów danych.

Jedną z minus tego podejścia jest to, że użytkownicy muszą współpracować z administratorami w celu zmiany w klastrach, takich jak konfiguracja, zainstalowane biblioteki itd.

Obciążenia usługi Batch

Scenariusz

Należy udostępnić klastry dla zaplanowanych zadań wsadowych, takich jak produkcyjne zadania ETL, które wykonują przygotowywanie danych. Sugerowanym najlepszym rozwiązaniem jest uruchomienie nowego klastra dla każdego uruchomienia zadania. Uruchamianie każdego zadania w nowym klastrze pomaga uniknąć błędów i nieudanych sla spowodowanych przez inne obciążenia uruchomione w klastrze udostępnionym. W zależności od poziomu krytyczności zadania można użyć wszystkich wystąpień na żądanie w celu spełnienia warunków sla lub zrównoważenia między wystąpieniami typu spot i na żądanie, aby uzyskać oszczędności kosztów.

Scheduled batch workloads