Kluczowe pojęcia w usłudze Databricks Apps

W tym artykule przedstawiono podstawowe pojęcia dotyczące usługi Databricks Apps, w tym sposób strukturalnych aplikacji, sposobu zarządzania zależnościami i stanami, sposobu działania uprawnień i interakcji aplikacji z zasobami platformy. Zrozumienie tych pojęć pomaga podczas tworzenia, wdrażania i zarządzania aplikacjami w obszarze roboczym.

App

Aplikacja usługi Databricks to aplikacja internetowa, która działa jako usługa konteneryzowana na platformie bezserwerowej usługi Azure Databricks. Deweloperzy używają obsługiwanych frameworków, takich jak Streamlit, Dash lub Gradio, aby tworzyć aplikacje dostarczające interaktywne dane lub doświadczenia AI w środowisku pracy Azure Databricks.

Każda aplikacja zawiera własną konfigurację, tożsamość i izolowane środowisko uruchomieniowe. Ponieważ aplikacje należą do określonego obszaru roboczego, mogą uzyskiwać dostęp do zasobów na poziomie obszaru roboczego, takich jak magazyny SQL, oraz zasobów na poziomie konta, takich jak Unity Catalog. Deweloperzy mogą również udostępniać aplikacje użytkownikom spoza obszaru roboczego, ale na tym samym koncie usługi Azure Databricks.

Mimo że kontener aplikacji działa w infrastrukturze bezserwerowej usługi Azure Databricks, sama aplikacja może łączyć się zarówno z zasobami bezserwerowymi, jak i serwerowymi. Koncepcyjnie aplikacja działa jako usługa płaszczyzny sterowania, która hostuje interfejs użytkownika w sieci web i uzyskuje dostęp do usług płaszczyzny danych Azure Databricks. Aby uzyskać więcej informacji, zobacz Omówienie architektury usługi Databricks.

Aby uruchomić aplikacje i zarządzać nimi, przejdź do sekcji Aplikacje w interfejsie użytkownika obszaru roboczego.

Adres URL aplikacji

Usługa Databricks automatycznie przypisuje każdej aplikacji unikatowy adres URL podczas jego tworzenia. Adres URL ma następujący format:

https://<app-name>-<workspace-id>.<region>.databricksapps.com

Where:

• <app-name> to nazwa podana podczas tworzenia aplikacji
• <workspace-id> jest unikatowym identyfikatorem obszaru roboczego
• <region> to region chmury, w którym znajduje się obszar roboczy

Nie można zmienić adresu URL po utworzeniu aplikacji. Jeśli potrzebujesz innego adresu URL, utwórz nową aplikację o innej nazwie.

Template

Szablon aplikacji to wstępnie utworzony szkielet, który ułatwia deweloperom szybkie tworzenie aplikacji przy użyciu obsługiwanej platformy. Każdy szablon zawiera podstawową strukturę plików, app.yaml manifest, requirements.txt plik dla aplikacji języka Python i przykładowy kod źródłowy.

Plik app.yaml definiuje polecenie uruchamiania aplikacji (na przykład streamlit run <app-name> dla aplikacji streamlit), konfiguruje lokalne zmienne środowiskowe i deklaruje wszystkie wymagane zasoby.

• Użyj requirements.txt do wymienienia dodatkowych pakietów języka Python do zainstalowania za pomocą pip.
• Użyj package.json, aby wyświetlić listę pakietów Node.js do zainstalowania za pomocą npm.

Te pliki uzupełniają domyślne środowisko systemowe i wstępnie zainstalowane pakiety. Aby uzyskać więcej informacji, zobacz Środowisko systemowe usługi Databricks Apps.

Deweloperzy mogą wygenerować nową aplikację na podstawie szablonu przy użyciu interfejsu użytkownika lub interfejsu wiersza polecenia usługi Azure Databricks.

Środowisko systemowe i pakiety

Aplikacje usługi Databricks działają w wstępnie skonfigurowanym środowisku systemowym zarządzanym przez usługę Azure Databricks. Aby uzyskać szczegółowe informacje, zobacz Środowisko systemowe usługi Databricks Apps.

Każda aplikacja ma własne izolowane środowisko, aby zapobiec konfliktom zależności. Aby zapewnić spójność, zdefiniuj wymagane pakiety i ich wersje w odpowiednim pliku dla aplikacji:

• W przypadku języka Python użyj polecenia requirements.txt.
• W przypadku Node.js, użyj package.json.

W przypadku wdrożeń hybrydowych prawdopodobnie będziesz mieć oba pliki.

Podczas wdrażania usługa Azure Databricks instaluje te zależności w izolowanym środowisku uruchomieniowym aplikacji. Jeśli uwzględnisz pakiet, który jest już wstępnie zainstalowany, określona wersja zastępuje wartość domyślną.

Aby uzyskać więcej informacji, zobacz Manage dependencies for a Databricks app (Zarządzanie zależnościami dla aplikacji usługi Databricks ).

Zasoby aplikacji

Zasoby aplikacji to usługi natywne dla usługi Azure Databricks, od których zależy aplikacja, takich jak magazyny SQL, model obsługujący punkty końcowe, zadania, wpisy tajne lub woluminy. Deklarujesz te zależności w databricks.yml manifeście za pomocą pola resources. Usługa Azure Databricks obsługuje następujące typy zasobów:

• SQL Warehouse
• Job
• Punkt końcowy obsługujący model
• Genie Space
• Secret
• Volume

Aby uzyskać dostęp do usług Azure Databricks, które nie mają jeszcze obsługiwanego typu zasobu, użyj sekretu zarządzanego przez Unity Catalog, aby bezpiecznie wstrzyknąć poświadczenia. Zobacz Zarządzanie tajemnicami.

Istnieją dwa etapy konfigurowania zasobów aplikacji:

• Deklaracja (programowanie) — zadeklaruj databricks.yml każdy wymagany zasób w manifeście. Definiuje zasoby, których potrzebuje aplikacja i jakich uprawnień wymaga.
• Konfiguracja (wdrożenie) — podczas wdrażania użyj interfejsu użytkownika usługi Databricks Apps, aby skonfigurować zadeklarowane zasoby z rzeczywistymi wystąpieniami specyficznymi dla obszaru roboczego (na przykład wybranie określonego magazynu SQL).

Ta separacja między deklaracją a konfiguracją umożliwia przenoszenie aplikacji między środowiskami. Możesz na przykład wdrożyć ten sam kod aplikacji w obszarze roboczym programowania i połączyć go z jednym magazynem SQL Warehouse. W środowisku produkcyjnym można ponownie użyć kodu i skonfigurować inny magazyn bez wprowadzania zmian w kodzie. Aby to umożliwić, należy unikać trwałego kodowania identyfikatorów zasobów lub wartości specyficznych dla środowiska w aplikacji.

Usługa Azure Databricks wymusza dostęp z najmniejszymi uprawnieniami. Aplikacje muszą używać istniejących zasobów i nie mogą tworzyć nowych. Podczas wdrażania administratorzy obszaru roboczego przeglądają i zatwierdzają żądany dostęp aplikacji do zasobów. Jednostka usługi aplikacji otrzymuje niezbędne uprawnienia, a deweloper aplikacji musi mieć uprawnienia, aby je udzielić.

Aby dowiedzieć się więcej, zobacz Dodawanie zasobów do aplikacji Databricks.

Stan aplikacji

Aplikacja może mieć jeden z następujących stanów: Uruchomiono, Zatrzymano, Wdrażanie lub Awaria.

• Uruchomiona — aplikacja jest aktywna i dostępna. Opłaty za zasoby obliczeniowe używane podczas działania aplikacji są rozliczane w usłudze Azure Databricks.
• Zatrzymano — aplikacja jest niedostępna i nie wiąże się z żadnymi kosztami. Usługa Azure Databricks zachowuje konfigurację i środowisko aplikacji, dzięki czemu można ją ponownie uruchomić bez ponownego konfigurowania.
• Wdrażanie — aplikacja jest uruchamiana. Nie jest jeszcze dostępny i na tym etapie nie są naliczane żadne opłaty.
• Awaria — nie można uruchomić lub zatrzymać aplikacji nieoczekiwanie. Jest niedostępna i nie powoduje naliczania opłat. Po rozwiązaniu problemu możesz wyświetlić dzienniki, aby rozwiązać problem i ponownie uruchomić aplikację.

Stan aplikacji

Stan aplikacji zawiera wszystkie dane lub kontekst, które aplikacja musi utrwalać w ramach sesji lub interakcji użytkownika. Aplikacje nie zachowują stanu w pamięci po ponownym uruchomieniu. Wszystkie dane przechowywane w pamięci zostaną utracone po zamknięciu aplikacji.

Stan można przechowywać na następujące sposoby:

• Przechowywanie w pamięci dla danych tymczasowych w ramach jednej sesji. Te dane zostaną utracone po ponownym uruchomieniu aplikacji.
• Lokalny system plików dla plików tymczasowych podczas wykonywania aplikacji. Te dane zostaną utracone po ponownym uruchomieniu aplikacji.
• Tabele usługi Azure Databricks korzystające z usługi Databricks SQL na potrzeby trwałych obciążeń danych ustrukturyzowanych i analitycznych.
• Pliki obszaru roboczego dla trwałych danych niestrukturyzowanych.
• Woluminy Unity Catalog do trwałego przechowywania danych nieustrukturyzowanych z zarządzaniem Unity Catalog.

• Instancje baz danych Lakebase do przechowywania trwałych danych relacyjnych z kompatybilnością z PostgreSQL.

Typowe przypadki użycia obejmują buforowanie wyników zapytań, zapisywanie preferencji użytkownika lub rejestrowanie akcji użytkownika między sesjami.

Uwierzytelnianie i autoryzacja aplikacji

Usługa Databricks Apps używa protokołu OAuth 2.0 do uwierzytelniania i kontroli dostępu. Każda aplikacja ma dwie uzupełniające tożsamości, które określają sposób uwierzytelniania i autoryzacji dostępu do zasobów usługi Azure Databricks: autoryzacja aplikacji i autoryzacja użytkownika.

• Autoryzacja aplikacji — usługa Azure Databricks automatycznie tworzy jednostkę usługi dla każdej aplikacji. Ten podmiot usługi pełni rolę tożsamości aplikacji i otrzymuje uprawnienia od dewelopera aplikacji. Wszyscy użytkownicy aplikacji współużytkowali tę tożsamość i mieli dostęp do tego samego zestawu uprawnień. Ten model jest przydatny w przypadku operacji, które nie zależą od kontekstu poszczególnych użytkowników, takich jak rejestrowanie lub akcje na poziomie systemu.

• Autoryzacja użytkownika — ten model używa tożsamości użytkownika aplikacji do uwierzytelniania i autoryzacji dostępu. Użytkownicy muszą należeć do konta usługi Azure Databricks, na którym jest wdrażana aplikacja. Po zalogowaniu się za pomocą logowania jednokrotnego aplikacja może używać poświadczeń użytkownika do uzyskiwania dostępu do zarządzanych zasobów, takich jak usługa SQL Warehouse. Dzięki temu aplikacja może respektować szczegółowe uprawnienia zarządzane przez Unity Catalog bez udzielania tych uprawnień głównej usługi aplikacji.

Aplikacje żądają określonych zakresów protokołu OAuth w manifeście, aby kontrolować, do których interfejsów API i zasobów mogą uzyskiwać dostęp. Ten elastyczny model obsługuje zabezpieczenia klasy korporacyjnej i umożliwia szczegółową kontrolę dostępu.

Aby uzyskać więcej informacji, zobacz Konfigurowanie autoryzacji w aplikacji usługi Databricks.

Użytkownicy aplikacji

Po wdrożeniu deweloperzy aplikacji mogą udostępniać aplikację użytkownikom lub grupom, udzielając CAN_USE uprawnień lub CAN_MANAGE w instancji aplikacji. Użytkownicy nie muszą należeć do tego samego obszaru roboczego, ale muszą być częścią tego samego konta usługi Azure Databricks. Aby udostępnić je użytkownikom zewnętrznym, najpierw zsynchronizuj je z kontem przy użyciu dostawcy tożsamości. Aby uzyskać więcej informacji, zobacz Synchronizowanie użytkowników i grup z witryny Microsoft Entra ID przy użyciu protokołu SCIM.

Tę samą aplikację można również dystrybuować w środowiskach programistycznych, testowych oraz produkcyjnych przy użyciu potoków CI/CD oraz infrastruktury jako kodu. Scentralizowany interfejs użytkownika aplikacji ułatwia użytkownikom odnajdywanie i uruchamianie aplikacji, które są autoryzowane do użycia.