Organizowanie metodyki MLOps za pomocą usługi Azure Databricks

Azure Databricks

Pomysły dotyczące rozwiązań

W tym artykule opisano pomysł rozwiązania. Architekt chmury może użyć tych wskazówek, aby ułatwić wizualizowanie głównych składników dla typowej implementacji tej architektury. Skorzystaj z tego artykułu jako punktu wyjścia, aby zaprojektować dobrze zaprojektowane rozwiązanie zgodne z konkretnymi wymaganiami obciążenia.

Ten artykuł zawiera architekturę i proces operacji uczenia maszynowego (MLOps), który korzysta z usługi Azure Databricks. Analitycy danych i inżynierowie mogą używać tego standardowego procesu do przenoszenia modeli i potoków uczenia maszynowego z programowania do środowiska produkcyjnego.

To rozwiązanie może korzystać z pełnej automatyzacji, ciągłego monitorowania i niezawodnej współpracy, a w związku z tym jest przeznaczone dla poziomu 4 dojrzałości MLOps. Ta architektura używa kodu podwyższania poziomu, który generuje podejście modelu , a nie podwyższanie poziomu modeli . Podwyższanie poziomu kodu, który generuje podejście modelu , koncentruje się na pisaniu kodu, który generuje modele uczenia maszynowego i zarządzaniu nim. Zalecenia zawarte w tym artykule obejmują opcje procesów automatycznych lub ręcznych.

Architektura

Diagram przedstawiający rozwiązanie do korzystania z usługi Azure Databricks dla metodyki MLOps.

Ten diagram przedstawia 12 kroków tego przepływu pracy. Sekcja danych produkcyjnych usługi Lakehouse zawiera tabelę danych, tabelę funkcji i metryki modelu tabel lakehouse. Sekcja kontroli źródła zawiera środowisko programistyczne, przejściowe i wydania. Kontrola źródła obejmuje usługi Azure DevOps i GitHub. W głównym środowisku deweloperskim krok 1 eksploracyjna analiza danych odczytuje dane z tabeli danych. Trenowanie modelu krok 2 odczytuje dane z tabeli danych i tabeli funkcji. Krok 3 zatwierdza kod w środowisku projektowym w kontroli źródła. Krok 4 scala żądanie do środowiska przejściowego. Środowisko przejściowe kontroli źródła wyzwala krok 5 jednostek i testów ciągłej integracji w głównym środowisku przejściowym, które odczytuje dane z tabeli funkcji i tabeli danych. Kod zmienia się scalać ze środowiskiem przejściowym kontroli źródła. Krok 6 tworzy gałąź wydania w środowisku wydania. Strzałka wskazująca środowisko wydania do głównego środowiska produkcyjnego to Deploy machine learning Databricks jobs (Wdrażanie zadań usługi Databricks w usłudze Machine Learning). W głównym środowisku produkcyjnym tabela funkcji krok 7 odświeża dane z tabeli danych i wysyła dane do tabeli funkcji. Trenowanie modelu krok 8 odczytuje dane z wykrywania dryfu i ponownego trenowania modelu. Krok 8 wypycha również model do katalogu aparatu Unity. Krok 9 oceny i podwyższania poziomu modelu ładuje model z wykazu aparatu Unity do oceny. Następnie wysyła model do etapu przejściowego, a następnie produkcyjnego w wykazie aparatu Unity. Wdrożenie modelu krok 10 ładuje model do wnioskowania i odczytywania danych z tabeli funkcji. Krok 11 monitorowania odczytuje dane z tabeli funkcji i odczytuje metryki modelu tabel lakehouse. Krok 11 zapisuje również dane w tabeli lakehouse i w usłudze Azure Monitor. Krok 12. Ponowne trenowanie modelu wskazuje krok 8, a strzałka wskazuje wyzwalanie ponownego trenowania modelu.

Pobierz plik programu Visio z tą architekturą.

Przepływ pracy

Poniższy przepływ pracy odpowiada powyższemu diagramowi. Użyj składników kontroli źródła i magazynu, aby zarządzać i organizować kod i dane.

Kontrola źródła: repozytorium kodu tego projektu organizuje notesy, moduły i potoki. Możesz tworzyć gałęzie programistyczne w celu testowania aktualizacji i nowych modeli. Twórz kod w notesach obsługiwanych przez usługę Git lub zintegrowanych środowiskach projektowych (IDE), które integrują się z folderami Git, aby umożliwić synchronizację z obszarami roboczymi usługi Azure Databricks. Kontrola źródła promuje potoki uczenia maszynowego ze środowiska deweloperskiego do testowania w środowisku przejściowym i wdrażania w środowisku produkcyjnym.

Dane produkcyjne usługi Lakehouse: jako analityk danych masz dostęp tylko do odczytu do danych produkcyjnych w środowisku deweloperskim. Środowisko projektowe może mieć zdublowane dane i zredagowane poufne dane. Masz również dostęp do odczytu i zapisu w środowisku magazynu deweloperskiego na potrzeby programowania i eksperymentowania. Zalecamy użycie architektury typu lakehouse dla danych, w których dane w formacie usługi Delta Lake są przechowywane w usłudze Azure Data Lake Storage. Usługa Lakehouse zapewnia niezawodne, skalowalne i elastyczne rozwiązanie do zarządzania danymi. Aby zdefiniować mechanizmy kontroli dostępu, użyj funkcji przekazywania poświadczeń identyfikatora entra firmy Microsoft lub kontroli dostępu do tabel.

Następujące środowiska składają się z głównego przepływu pracy.

Opracowywanie zawartości

W środowisku deweloperskim tworzysz potoki uczenia maszynowego.

  1. Wykonywanie eksploracyjnej analizy danych (EDA): eksplorowanie danych w interaktywnym, iteracyjnym procesie. Ta praca może nie zostać wdrożona w środowisku przejściowym lub produkcyjnym. Użyj narzędzi, takich jak Databricks SQL, dbutils.data.summarize i Databricks AutoML.

  2. Opracowywanie trenowania modelu i innych potoków uczenia maszynowego: opracowywanie potoków uczenia maszynowego w kodzie modułowym i organizowanie kodu za pomocą notesów usługi Databricks lub projektu MLFlow. W tej architekturze potok trenowania modelu odczytuje dane z magazynu funkcji i innych tabel lakehouse. Potok trenuje itunes parametry i metryki modelu dziennika do serwera śledzenia MLflow. Interfejs API magazynu funkcji rejestruje ostatni model. Te dzienniki obejmują model, jego dane wejściowe i kod trenowania.

  3. Zatwierdź kod: aby podwyższyć poziom przepływu pracy uczenia maszynowego do produkcji, zatwierdź kod do cechowania, trenowania i innych potoków w celu kontroli źródła. W bazie kodu umieść kod uczenia maszynowego i kod operacyjny w różnych folderach, aby członkowie zespołu mogli tworzyć kod jednocześnie. Kod uczenia maszynowego to kod powiązany z modelem i danymi. Kod operacyjny to kod powiązany z zadaniami i infrastrukturą usługi Databricks.

Ten podstawowy cykl działań wykonywanych podczas pisania i testowania kodu jest nazywany procesem innerloop. Aby wykonać proces innerloop dla fazy programowania, użyj programu Visual Studio Code w połączeniu z interfejsem wiersza polecenia kontenera deweloperskiego i interfejsem wiersza polecenia usługi Databricks. Kod można napisać i przeprowadzić lokalne testowanie jednostkowe. Należy również przesyłać, monitorować i analizować potoki modelu z lokalnego środowiska deweloperskiego.

Przygotowanie

W środowisku przejściowym testy infrastruktury ciągłej integracji zmieniają się w potoki uczenia maszynowego w środowisku, które naśladuje produkcję.

  1. Scal żądanie: po przesłaniu żądania scalania lub żądania ściągnięcia względem gałęzi przejściowej (głównej) projektu w kontroli źródła narzędzie ciągłej integracji i ciągłego dostarczania (CI/CD), takie jak usługa Azure DevOps uruchamia testy.

  2. Uruchamianie testów jednostkowych i testów ciągłej integracji: testy jednostkowe są uruchamiane w infrastrukturze ciągłej integracji, a testy integracji są uruchamiane w pełnych przepływach pracy w usłudze Azure Databricks. Jeśli testy przejdą, kod zmieni się w scalanie.

  3. Utwórz gałąź wydania: jeśli chcesz wdrożyć zaktualizowane potoki uczenia maszynowego w środowisku produkcyjnym, możesz utworzyć nową wersję. Potok wdrażania w narzędziu ciągłej integracji/ciągłego wdrażania ponownie wdraża zaktualizowane potoki jako nowe przepływy pracy.

Produkcyjne

Inżynierowie uczenia maszynowego zarządzają środowiskiem produkcyjnym, w którym potoki uczenia maszynowego obsługują bezpośrednio aplikacje końcowe. Kluczowe potoki w tabelach funkcji odświeżania produkcyjnego, trenowanie i wdrażanie nowych modeli, wnioskowanie lub obsługa oraz monitorowanie wydajności modelu.

  1. Odświeżanie tabeli funkcji: ten potok odczytuje dane, funkcje obliczeniowe i zapisy w tabelach magazynu funkcji. Możesz skonfigurować ten potok tak, aby był uruchamiany w trybie ciągłego przesyłania strumieniowego, uruchamiany zgodnie z harmonogramem lub uruchamiany na wyzwalaczu.

  2. Trenowanie modelu: w środowisku produkcyjnym można skonfigurować trenowanie modelu lub potok ponownego trenowania w taki sposób, aby był uruchamiany na wyzwalaczu lub zgodnie z harmonogramem trenowania nowego modelu na najnowszych danych produkcyjnych. Modele są automatycznie rejestrowane w katalogu aparatu Unity.

  3. Ocena modelu i podwyższanie poziomu: po zarejestrowaniu nowej wersji modelu potok ciągłego wdrażania uruchamia testy w celu zapewnienia, że model będzie działać dobrze w środowisku produkcyjnym. Gdy model przejdzie testy, katalog aparatu Unity śledzi postęp za pośrednictwem przejść etapu modelu. Testy obejmują testy zgodności, testy A/B w celu porównania nowego modelu z bieżącym modelem produkcyjnym i testami infrastruktury. Tabele lakehouse rejestrują wyniki testów i metryki. Opcjonalnie możesz wymagać ręcznego logowania przed przejściem modeli do środowiska produkcyjnego.

  4. Wdrażanie modelu: gdy model wchodzi do środowiska produkcyjnego, jest wdrażany na potrzeby oceniania lub obsługi. Najbardziej typowe tryby wdrażania to:

    • Ocenianie wsadowe lub przesyłane strumieniowo: w przypadku opóźnień minut lub dłuższych usługa Batch i przesyłanie strumieniowe to najbardziej ekonomiczne opcje. Potok oceniania odczytuje najnowsze dane z magazynu funkcji, ładuje najnowszą wersję modelu produkcyjnego z wykazu aparatu Unity i wykonuje wnioskowanie w zadaniu usługi Databricks. Może publikować przewidywania w tabelach lakehouse, połączeniu JDBC (Java Database Connectivity), plikach prostych, kolejkach komunikatów lub innych systemach podrzędnych.

    • Obsługa online (interfejsy API REST): w przypadku przypadków użycia o małych opóźnieniach zazwyczaj potrzebna jest obsługa online. Rozwiązanie MLflow może wdrażać modele w usłudze Mosaic AI Model Serving, dostawcy usług w chmurze i innych systemach. We wszystkich przypadkach system obsługujący inicjuje najnowszy model produkcyjny z katalogu aparatu Unity. Dla każdego żądania pobiera funkcje ze sklepu funkcji online i tworzy przewidywania.

  5. Monitorowanie: Ciągłe lub okresowe przepływy pracy monitorują dane wejściowe i przewidywania modelu pod kątem dryfu, wydajności i innych metryk. Za pomocą platformy Delta Live Tables można zautomatyzować monitorowanie potoków i przechowywać metryki w tabelach lakehouse. Usługi Databricks SQL, Power BI i inne narzędzia mogą odczytywać z tych tabel w celu tworzenia pulpitów nawigacyjnych i alertów. Aby monitorować metryki, dzienniki i infrastrukturę aplikacji, możesz również zintegrować usługę Azure Monitor z usługą Azure Databricks.

  6. Wykrywanie dryfu i ponowne trenowanie modelu: ta architektura obsługuje zarówno ręczne, jak i automatyczne ponowne trenowanie. Zaplanuj ponowne trenowanie zadań, aby zachować świeżość modeli. Po wykryciu dryfu przekroczy wstępnie skonfigurowany próg ustawiony w kroku monitorowania, potoki ponownego trenowania analizują dryf i wyzwalają ponowne trenowanie. Potoki można skonfigurować do automatycznego wyzwalania lub otrzymywać powiadomienie, a następnie uruchamiać potoki ręcznie.

Składniki

  • Architektura typu data lakehouse łączy elementy magazynów danych i magazynów danych. Usługa Lakehouse umożliwia uzyskiwanie możliwości zarządzania danymi i wydajności, które zwykle znajdują się w magazynach danych, ale w przypadku tanich, elastycznych magazynów obiektów oferowanych przez magazyny typu data lake.

    • Usługa Delta Lake jest zalecanym formatem danych typu open source dla usługi Lakehouse. Usługa Azure Databricks przechowuje dane w usłudze Data Lake Storage i udostępnia aparat zapytań o wysokiej wydajności.
  • MLflow to projekt typu open source umożliwiający zarządzanie cyklem życia kompleksowego uczenia maszynowego. Rozwiązanie MLflow ma następujące składniki:

    • Funkcja śledzenia śledzi eksperymenty, dzięki czemu można rejestrować i porównywać parametry, metryki i artefakty modelu.

    • Model MLflow to format, za pomocą którego można przechowywać i wdrażać modele z dowolnej biblioteki uczenia maszynowego na różnych platformach obsługujących modele i wnioskowania.

    • Wykaz aparatu Unity zapewnia scentralizowaną kontrolę dostępu, inspekcję, pochodzenie i funkcje odnajdywania danych w obszarach roboczych usługi Azure Databricks.

    • Mozaika model AI obsługujący hostuje modele MLflow jako punkty końcowe REST.

  • Usługa Azure Databricks udostępnia zarządzaną usługę MLflow z funkcjami zabezpieczeń przedsiębiorstwa, wysoką dostępnością i integracją z innymi funkcjami obszaru roboczego usługi Azure Databricks.

    • Środowisko Databricks Runtime for Machine Learning automatyzuje tworzenie klastra zoptymalizowanego pod kątem uczenia maszynowego i preinstaluje popularne biblioteki uczenia maszynowego, takie jak TensorFlow, PyTorch i XGBoost. Usługa Azure Databricks jest również wstępnie instalowana dla narzędzi uczenia maszynowego, takich jak oprogramowanie AutoML i klienci magazynu funkcji.

    • Magazyn funkcji to scentralizowane repozytorium funkcji. Magazyn funkcji umożliwia odnajdywanie i udostępnianie funkcji oraz zapobieganie niesymetryczności danych między trenowaniem i wnioskowaniem modelu.

    • Usługa Databricks SQL integruje się z różnymi narzędziami, dzięki czemu można tworzyć zapytania i pulpity nawigacyjne w ulubionych środowiskach bez dostosowywania się do nowej platformy.

    • Foldery Git zapewniają integrację z dostawcą usługi Git w obszarze roboczym usługi Azure Databricks, co usprawnia współpracę notesu lub kodu i integrację środowiska IDE.

    • Przepływy pracy i zadania umożliwiają uruchamianie kodu nieinterakcyjnego w klastrze usługi Azure Databricks. W przypadku uczenia maszynowego zadania zapewniają automatyzację przygotowywania danych, cechowania, trenowania, wnioskowania i monitorowania.

Alternatywy

To rozwiązanie można dostosować do infrastruktury platformy Azure. Rozważ następujące dostosowania:

  • Użyj wielu obszarów roboczych programowania, które współdzielą wspólny obszar roboczy produkcyjny.

  • Wymiana co najmniej jednego składnika architektury dla istniejącej infrastruktury. Na przykład możesz użyć usługi Azure Data Factory do organizowania zadań usługi Databricks.

  • Integracja z istniejącymi narzędziami ciągłej integracji/ciągłego wdrażania za pośrednictwem interfejsów API REST usług Git i Azure Databricks.

  • Użyj usługi Microsoft Fabric lub Azure Synapse Analytics jako alternatywnych usług uczenia maszynowego.

Szczegóły scenariusza

To rozwiązanie zapewnia niezawodny proces MLOps korzystający z usługi Azure Databricks. Możesz zastąpić wszystkie elementy architektury, aby w razie potrzeby zintegrować inne usługi platformy Azure i usługi partnerskie. Ta architektura i opis są dostosowane z książki e-book The Big Book of MLOps. Książka elektroniczna bardziej szczegółowo bada tę architekturę.

Metodyka MLOps pomaga zmniejszyć ryzyko awarii w systemach uczenia maszynowego i sztucznej inteligencji oraz zwiększa wydajność współpracy i narzędzi. Aby zapoznać się z wprowadzeniem do metodyki MLOps i omówieniem tej architektury, zobacz Architektura metodyki MLOps w usłudze Lakehouse.

Użyj tej architektury, aby:

  • Połącz zainteresowanych stron biznesowych z zespołami uczenia maszynowego i nauki o danych. Ta architektura służy do dołączania notesów i środowisk IDE na potrzeby programowania. Uczestnicy projektu biznesowego mogą wyświetlać metryki i pulpity nawigacyjne w usłudze Databricks SQL— wszystkie w ramach tej samej architektury usługi LakeHouse.

  • Uśmierć dane infrastruktury uczenia maszynowego. Ta architektura traktuje dane uczenia maszynowego tak samo jak inne dane. Dane uczenia maszynowego obejmują dane z inżynierii cech, trenowania, wnioskowania i monitorowania. Ta architektura ponownie używa narzędzi dla potoków produkcyjnych, pulpitów nawigacyjnych i innych ogólnych przetwarzania danych na potrzeby przetwarzania danych uczenia maszynowego.

  • Implementowanie metodyki MLOps w modułach i potokach. Podobnie jak w przypadku każdej aplikacji programowej, użyj modułowych potoków i kodu w tej architekturze, aby przetestować poszczególne składniki i zmniejszyć koszt przyszłej refaktoryzacji.

  • Automatyzowanie procesów MLOps zgodnie z potrzebami. W tej architekturze można zautomatyzować kroki w celu zwiększenia produktywności i zmniejszenia ryzyka błędu ludzkiego, ale nie trzeba automatyzować każdego kroku. Usługa Azure Databricks zezwala na interfejs użytkownika i procesy ręczne oprócz interfejsów API na potrzeby automatyzacji.

Potencjalne przypadki użycia

Ta architektura ma zastosowanie do wszystkich typów uczenia maszynowego, uczenia głębokiego i zaawansowanych analiz. Typowe techniki uczenia maszynowego i sztucznej inteligencji w tej architekturze obejmują:

  • Klasyczne uczenie maszynowe, takie jak modele liniowe, modele oparte na drzewach i zwiększanie.
  • Nowoczesne uczenie głębokie, takie jak TensorFlow i PyTorch.
  • Analiza niestandardowa, na przykład statystyki, metody Bayesowskie i analiza grafów.

Architektura obsługuje zarówno małe dane (pojedyncze maszyny) jak i duże dane (przetwarzanie rozproszone i przyspieszone procesory GPU). Na każdym etapie architektury można wybrać zasoby obliczeniowe i biblioteki, aby dostosować się do danych i wymiarów problemów scenariusza.

Architektura ma zastosowanie do wszystkich typów branż i przypadków użycia biznesowego. Klienci usługi Azure Databricks korzystający z tej architektury obejmują małe i duże organizacje w następujących branżach:

  • Towary konsumpcyjne i usługi detaliczne
  • Usługi finansowe
  • Opieka zdrowotna i nauki przyrodnicze
  • Technologie informatyczne

Przykłady można znaleźć w temacie Klienci usługi Databricks.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki