Edytuj

Organizowanie metodyki MLOps przy użyciu usługi Azure Databricks

Azure Databricks

Pomysły dotyczące rozwiązań

Ten artykuł jest pomysłem na rozwiązanie. Jeśli chcesz, abyśmy rozszerzyli zawartość o więcej informacji, takich jak potencjalne przypadki użycia, alternatywne usługi, zagadnienia dotyczące implementacji lub wskazówki dotyczące cen, daj nam znać, przekazując opinię w usłudze GitHub.

Ten artykuł zawiera architekturę i proces operacji uczenia maszynowego (MLOps), który korzysta z usługi Azure Databricks. Ten proces definiuje ustandaryzowany sposób przenoszenia modeli i potoków uczenia maszynowego z programowania do środowiska produkcyjnego z opcjami obejmującymi zautomatyzowane i ręczne procesy.

Architektura

Diagram that shows a solution for using Azure Databricks for MLOps.

Pobierz plik programu Visio z tą architekturą.

Przepływ pracy

To rozwiązanie zapewnia niezawodny proces MLOps korzystający z usługi Azure Databricks. Wszystkie elementy architektury są podłączane, dzięki czemu można w razie potrzeby zintegrować inne usługi platformy Azure i innych firm w całej architekturze. Ta architektura i opis są dostosowane z książki e-book The Big Book of MLOps. Ta książka elektroniczna zawiera bardziej szczegółowe omówienie architektury opisanej tutaj.

  • Kontrola źródła: repozytorium kodu tego projektu organizuje notesy, moduły i potoki. Analitycy danych tworzą gałęzie programistyczne w celu testowania aktualizacji i nowych modeli. Kod jest opracowywany w notesach lub środowiskach IDE wspieranych przez usługę Git z integracją usługi Databricks Repos na potrzeby synchronizacji z obszarami roboczymi usługi Azure Databricks. Kontrola źródła promuje potoki uczenia maszynowego od programowania przez etap przejściowy (na potrzeby testowania) do środowiska produkcyjnego (na potrzeby wdrożenia).

  • Lakehouse — dane produkcyjne: analitycy danych pracują w środowisku deweloperskim, gdzie mają dostęp tylko do odczytu do danych produkcyjnych. (Alternatywnie dane mogą być dublowane lub redagowane). Mają również dostęp do odczytu/zapisu w środowisku magazynu deweloperskiego na potrzeby programowania i eksperymentowania. Zalecamy architekturę usługi Lakehouse dla danych, w których dane są przechowywane w usłudze Azure Data Lake Storage w formacie usługi Delta Lake. Mechanizmy kontroli dostępu są definiowane za pomocą funkcji przekazywania poświadczeń firmy Microsoft lub kontroli dostępu do tabel.

Opracowywanie zawartości

W środowisku deweloperskim analitycy danych i inżynierowie opracowują potoki uczenia maszynowego.

  1. Eksploracyjna analiza danych (EDA): analitycy danych eksplorują dane w interaktywnym, iteracyjnym procesie. Ta praca ad hoc może nie zostać wdrożona w środowisku przejściowym lub produkcyjnym. Narzędzia mogą obejmować usługi Databricks SQL, dbutils.data.summarize i AutoML.

  2. Trenowaniemodelu i inne potoki uczenia maszynowego: potoki uczenia maszynowego są opracowywane jako modułowy kod w notesach i/lub środowiskach IDE. Na przykład potok trenowania modelu odczytuje dane ze sklepu Feature Store i innych tabel lakehouse. Trenowanie i dostrajanie parametrów i metryk modelu dziennika na serwerze śledzenia MLflow. Interfejs API magazynu funkcji rejestruje ostatni model. Te dzienniki łączą model, jego dane wejściowe i kod trenowania.

  3. Zatwierdź kod: aby promować przepływ pracy uczenia maszynowego w kierunku produkcji, analityk danych zatwierdza kod do cechowania, trenowania i innych potoków w celu kontroli źródła.

Przygotowanie

W środowisku przejściowym infrastruktura ciągłej integracji testuje zmiany potoków uczenia maszynowego w środowisku, które naśladuje produkcję.

  1. Żądanie scalania: gdy żądanie scalania (lub ściągnięcia) jest przesyłane 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. Testy jednostkowe i ciągłej integracji: testy jednostkowe są uruchamiane w infrastrukturze ciągłej integracji, a testy integracji uruchamiają kompleksowe przepływy pracy w usłudze Azure Databricks. Jeśli testy przejdą, kod zmieni się w scalanie.

  3. Tworzenie gałęzi wydania: gdy inżynierowie uczenia maszynowego są gotowi do wdrożenia zaktualizowanych potoków uczenia maszynowego w środowisku produkcyjnym, mogą 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. Jest on uruchamiany w trybie przesyłania strumieniowego, uruchamiany zgodnie z harmonogramem lub jest wyzwalany.

  2. Trenowanie modelu: W środowisku produkcyjnym potok trenowania lub ponownego trenowania modelu jest wyzwalany lub zaplanowany do trenowania nowego modelu na najnowszych danych produkcyjnych. Modele są rejestrowane w rejestrze modeli MLflow.

  3. Ciągłe wdrażanie: rejestrowanie nowych wersji modelu wyzwala potok ciągłego wdrażania, który uruchamia testy w celu zapewnienia, że model będzie działać dobrze w środowisku produkcyjnym. Gdy model przechodzi testy, jego postęp jest śledzony w rejestrze modeli za pośrednictwem przejść etapu modelu. Elementy webhook rejestru mogą być używane do automatyzacji. Testy mogą obejmować testy zgodności, testy A/B w celu porównania nowego modelu z bieżącym modelem produkcyjnym i testami infrastruktury. Wyniki testów i metryki są rejestrowane w tabelach usługi Lakehouse. Opcjonalnie możesz wymagać ręcznego logowania przed przejściem modeli do środowiska produkcyjnego.

  4. Wdrażanie modelu: gdy model wchodzi w środowisko produkcyjne, jest wdrażany do 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 ze Sklepu funkcji, ładuje najnowszą wersję modelu produkcyjnego z rejestru modeli i wykonuje wnioskowanie w zadaniu usługi Databricks. Może publikować przewidywania w tabelach Lakehouse, połączeniu Połączenie ivity (JDBC) w języku Java, plikach prostych, kolejkach komunikatów lub innych systemach podrzędnych.
    • Obsługa w trybie online (interfejsy API REST): w przypadku przypadków użycia o małych opóźnieniach obsługa online jest zwykle niezbędna. Rozwiązanie MLflow może wdrażać modele w usłudze MLflow Model Serving w usłudze Azure Databricks, systemach obsługujących dostawcę usług w chmurze i innych systemach. We wszystkich przypadkach system obsługujący jest inicjowany przy użyciu najnowszego modelu produkcyjnego z rejestru modeli. 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. Tabele delta Live Tables mogą uprościć automatyzację potoków monitorowania, przechowując metryki w tabelach usługi 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.

  6. Ponowne trenowanie: ta architektura obsługuje zarówno ręczne, jak i automatyczne ponowne trenowanie. Zaplanowane zadania ponownego trenowania to najprostszy sposób, aby zachować świeżość modeli.

Elementy

  • Data Lakehouse. Architektura usługi Lakehouse łączy najlepsze elementy magazynów typu data lake i magazynów danych, zapewniając zarządzanie danymi i wydajność zwykle spotykane w magazynach danych z niskimi kosztami, elastycznymi magazynami obiektów oferowanymi przez magazyny typu data lake.
    • Usługa Delta Lake jest zalecanym wyborem dla formatu 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. Są to jego główne składniki:
    • Śledzenie umożliwia śledzenie eksperymentów w celu rejestrowania i porównywania parametrów, metryk i artefaktów modelu.
    • Model MLFlow umożliwia przechowywanie i wdrażanie modeli z dowolnej biblioteki uczenia maszynowego do różnych platform obsługujących i wnioskowania modeli.
    • Rejestr modeli zapewnia scentralizowany magazyn modeli do zarządzania etapami cyklu życia modelu z programowania do produkcji.
    • Obsługa modelu umożliwia hostowanie modeli MLflow jako punktów końcowych REST.
  • Azure Databricks. 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 Edukacja automatyzuje tworzenie klastra zoptymalizowanego pod kątem uczenia maszynowego, wstępnie instalując popularne biblioteki uczenia maszynowego, takie jak TensorFlow, PyTorch i XGBoost, oprócz narzędzi usługi Azure Databricks for Machine Edukacja, takich jak klienci automatycznego uczenia maszynowego i magazynu funkcji.
    • Magazyn funkcji to scentralizowane repozytorium funkcji. Umożliwia udostępnianie i odnajdywanie funkcji oraz pomaga uniknąć niesymetryczności danych między trenowaniem i wnioskowaniem modelu.
    • Databricks SQL. Usługa Databricks SQL zapewnia proste środowisko zapytań SQL dotyczących danych usługi Lakehouse oraz wizualizacji, pulpitów nawigacyjnych i alertów.
    • Usługa Databricks Repos zapewnia integrację z dostawcą usługi Git w obszarze roboczym usługi Azure Databricks, upraszczając wspólne opracowywanie notesów lub integracji kodu i ś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. Typowe dostosowania obejmują:

  • Wiele obszarów roboczych programowania, które współużytkuje 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.

Szczegóły scenariusza

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

Korzystając z tej architektury, można wykonywać następujące czynności:

  • Połączenie zainteresowanych stron biznesowych zespołami uczenia maszynowego i nauki o danych. Ta architektura umożliwia analitykom danych używanie notesów i środowisk IDE do programowania. Umożliwia to uczestnikom projektu biznesowego wyświetlanie metryk i pulpitów nawigacyjnych w usłudze Databricks SQL w ramach tej samej architektury usługi Lakehouse.
  • Uśmierć dane infrastruktury uczenia maszynowego. Ta architektura traktuje dane uczenia maszynowego (dane z inżynierii cech, trenowania, wnioskowania i monitorowania), podobnie jak inne dane. Ponownie używa narzędzi dla potoków produkcyjnych, pulpitów nawigacyjnych i innego ogólnego przetwarzania danych na potrzeby przetwarzania danych uczenia maszynowego.
  • Implementowanie metodyki MLOps w modułach i potokach. Podobnie jak w przypadku każdej aplikacji programowej modułowe potoki i kod w tej architekturze umożliwiają testowanie poszczególnych składników i obniżają 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 każdy krok musi zostać zautomatyzowany. 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/sztucznej inteligencji używane 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 wymiarów danych i problemów.

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

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

Przykłady można znaleźć w witrynie internetowej usługi Databricks.

Współautorzy

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

Główny autor:

Inny współautor:

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

Następne kroki