Analizuj wydatki Amazon SageMaker i określaj możliwości optymalizacji kosztów w oparciu o wykorzystanie, część 3: Przetwarzanie i praca administratora danych

Opublikowane ponownie przez Plato

Obserwuje: 0

W 2021 roku wystartowaliśmy AWS obsługuje usługi proaktywne ramach Wsparcie dla przedsiębiorstw AWS plan. Od czasu jego wprowadzenia pomogliśmy setkom klientów zoptymalizować obciążenia, ustawić bariery ochronne i poprawić widoczność kosztów i użycia obciążeń związanych z uczeniem maszynowym (ML).

W tej serii postów dzielimy się doświadczeniami dotyczącymi optymalizacji kosztów w Amazon Sage Maker. W tym poście skupimy się na wykorzystaniu wstępnego przetwarzania danych Przetwarzanie Amazon SageMaker i Pogromca danych Amazon SageMaker Oferty pracy.

Wstępne przetwarzanie danych odgrywa kluczową rolę w podejściu opartym na sztucznej inteligencji opartym na danych. Jednak przygotowywanie nieprzetworzonych danych do szkolenia i oceny uczenia maszynowego jest często żmudnym i wymagającym zadaniem pod względem zasobów obliczeniowych, czasu i wysiłku ludzkiego. Przygotowanie danych zwykle wymaga integracji z różnych źródeł i radzenia sobie z brakującymi lub zaszumionymi wartościami, wartościami odstającymi i tak dalej.

Ponadto, oprócz typowych zadań wyodrębniania, przekształcania i ładowania (ETL), zespoły ML czasami wymagają bardziej zaawansowanych możliwości, takich jak tworzenie szybkich modeli do oceny danych i generowanie ocen ważności funkcji lub ocena modelu po szkoleniu w ramach potoku MLOps.

SageMaker oferuje dwie funkcje zaprojektowane specjalnie, aby pomóc w rozwiązaniu tych problemów: SageMaker Processing i Data Wrangler. SageMaker Processing umożliwia łatwe uruchamianie przetwarzania wstępnego, końcowego i oceny modelu we w pełni zarządzanej infrastrukturze. Data Wrangler skraca czas potrzebny na agregację i przygotowanie danych, upraszczając proces integracji źródła danych i inżynierii funkcji przy użyciu jednego interfejsu wizualnego i w pełni rozproszonego środowiska przetwarzania danych.

Obie funkcje SageMaker zapewniają dużą elastyczność dzięki kilku opcjom wejścia/wyjścia, przechowywania i obliczeń. Jednak nieprawidłowe ustawienie tych opcji może prowadzić do niepotrzebnych kosztów, zwłaszcza w przypadku dużych zbiorów danych.

W tym poście analizujemy czynniki cenowe i zapewniamy wskazówki dotyczące optymalizacji kosztów dla zadań SageMaker Processing i Data Wrangler.

Przetwarzanie SageMaker

SageMaker Processing to zarządzane rozwiązanie do uruchamiania zadań związanych z przetwarzaniem danych i oceną modeli. Możesz go używać na etapach przetwarzania danych, takich jak inżynieria funkcji, sprawdzanie poprawności danych, ocena modelu i interpretacja modelu w przepływach pracy ML. Dzięki SageMaker Processing możesz wprowadzić własne niestandardowe skrypty przetwarzania i zdecydować się na zbudowanie niestandardowego kontenera lub użyć zarządzanego kontenera SageMaker z popularnymi platformami, takimi jak scikit-learn, Lime, Spark i inne.

SageMaker Processing pobiera opłaty za wybrany typ instancji na podstawie czasu użytkowania i udostępnionej pamięci masowej dołączonej do tej instancji. W części 1 pokazaliśmy, jak zacząć używać Eksplorator kosztów AWS zidentyfikować możliwości optymalizacji kosztów w SageMaker.

Możesz filtrować koszty przetwarzania, stosując filtr według typu użycia. Nazwy tych typów użycia są następujące:

REGION-Processing:instanceType (na przykład, USE1-Processing:ml.m5.large)
REGION-Processing:VolumeUsage.gp2 (na przykład, USE1-Processing:VolumeUsage.gp2)

Aby przejrzeć koszt przetwarzania SageMaker w Eksploratorze kosztów, zacznij od filtrowania w SageMaker dla Usługi, A na Typ użytkowania, możesz wybrać godziny pracy wszystkich instancji przetwarzania, wprowadzając processing:ml prefiks i wybranie listy w menu.

Unikaj kosztów związanych z przetwarzaniem i opracowywaniem rurociągów

Przed dopasowaniem rozmiaru i optymalizacją czasu trwania zadania SageMaker Processing sprawdzamy metryki wysokiego poziomu dotyczące historycznych uruchomień zadań. Możesz wybrać jedną z dwóch metod, aby to zrobić.

Po pierwsze, możesz uzyskać dostęp do Przetwarzanie na konsoli SageMaker.

Alternatywnie możesz użyć API list_processing_jobs.

Stan zadania Przetwarzanie może być InProgress, Completed, Failed, Stoppinglub Stopped.

Podczas opracowywania nowych potoków MLOps często występuje duża liczba nieudanych zadań. Jednak zawsze powinieneś przetestować i dołożyć wszelkich starań, aby zweryfikować zadania przed uruchomieniem ich w SageMaker, ponieważ są opłaty za wykorzystane zasoby. W tym celu możesz użyć SageMaker Processing w tryb lokalny. Tryb lokalny to funkcja SageMaker SDK, która umożliwia tworzenie estymatorów, procesorów i potoków oraz wdrażanie ich w lokalnym środowisku programistycznym. To świetny sposób na przetestowanie skryptów przed uruchomieniem ich w zarządzanym środowisku SageMaker. Tryb lokalny jest obsługiwany przez kontenery zarządzane przez SageMaker oraz te, które dostarczasz samodzielnie. Aby dowiedzieć się więcej o korzystaniu z trybu lokalnego z Rurociągi Amazon SageMaker, odnosić się do Tryb lokalny.

Zoptymalizuj koszty związane z wejściami/wyjściami

Zadania SageMaker Processing oferują dostęp do trzech źródeł danych w ramach zarządzanego przetwarzanie danych wejściowych: Usługa Amazon Simple Storage (Amazonka S3), Amazonka Atena, Amazonka Przesunięcie ku czerwieni. Aby uzyskać więcej informacji, zobacz PrzetwarzanieS3Input, Definicja zestawu danych Athena, Definicja zestawu danych przesunięcia ku czerwieni, Odpowiednio.

Zanim zajmiemy się optymalizacją, należy zauważyć, że chociaż zadania SageMaker Processing obsługują te źródła danych, nie są one obowiązkowe. W swoim kodzie przetwarzającym możesz zaimplementować dowolną metodę pobierania danych dostępowych z dowolnego źródła (pod warunkiem, że instancja przetwarzająca ma do nich dostęp).

Aby uzyskać lepszy wgląd w wydajność przetwarzania i wykrywanie możliwości optymalizacji, zalecamy następujące czynności najlepsze praktyki w zakresie rejestrowania w twoim skrypcie przetwarzania. SageMaker publikuje dzienniki przetwarzania w Amazon Cloud Watch.

W poniższym przykładowym dzienniku zadania widzimy, że przetwarzanie skryptu trwało 15 minut (między Start custom script i End custom script).

Jednak na konsoli SageMaker widzimy, że zadanie zajęło dodatkowe 4 minuty (prawie 25% całkowitego czasu działania zadania).

Wynika to z faktu, że oprócz czasu, jaki zajmował nasz skrypt przetwarzania, pobieranie i wysyłanie danych zarządzanych przez SageMaker również zajęło trochę czasu (4 minuty). Jeśli okaże się, że stanowi to dużą część kosztów, rozważ alternatywne sposoby przyspieszenia czasu pobierania, takie jak użycie interfejsu API Boto3 z przetwarzaniem wieloprocesowym do jednoczesnego pobierania plików lub użycie bibliotek innych firm, takich jak WebDataset lub s5cmd, w celu szybszego pobierania z Amazon S3 . Aby uzyskać więcej informacji, patrz Równoległe obciążenia S3 za pomocą s5cmd. Należy pamiętać, że takie metody mogą wprowadzać opłaty w Amazon S3 z powodu transfer danych.

Obsługa zadań przetwarzania Tryb potoku. Dzięki tej metodzie SageMaker przesyła strumieniowo dane wejściowe ze źródła bezpośrednio do kontenera przetwarzania do nazwanych potoków bez użycia woluminu pamięci masowej ML, eliminując w ten sposób czas pobierania danych i mniejszą pojemność dysku. Wymaga to jednak bardziej skomplikowanego modelu programowania niż zwykłe czytanie z plików na dysku.

Jak wspomniano wcześniej, SageMaker Processing obsługuje również Athena i Amazon Redshift jako źródła danych. Podczas konfigurowania zadania przetwarzania z tymi źródłami SageMaker automatycznie kopiuje dane do Amazon S3, a instancja przetwarzająca pobiera dane z lokalizacji Amazon S3. Jednak po zakończeniu zadania nie ma zarządzanego procesu czyszczenia, a skopiowane dane nadal pozostaną w Amazon S3 i mogą wiązać się z niechcianymi opłatami za przechowywanie. Dlatego podczas korzystania ze źródeł danych Athena i Amazon Redshift należy zaimplementować procedurę czyszczenia, taką jak funkcja Lambda, która kursuje według harmonogramu lub w Krok Lambdy jako część potoku SageMaker.

Podobnie jak pobieranie, przesyłanie artefaktów przetwarzania może być okazją do optymalizacji. Gdy dane wyjściowe zadania przetwarzania są skonfigurowane przy użyciu pliku ProcessingS3Output parametr, możesz określić który S3UploadMode używać. The S3UploadMode domyślna wartość parametru to EndOfJob, co sprawi, że SageMaker prześle wyniki po zakończeniu zadania. Jeśli jednak zadanie przetwarzania generuje wiele plików, możesz ustawić S3UploadMode do Continuous, umożliwiając w ten sposób jednoczesne przesyłanie artefaktów w trakcie przetwarzania i skracając czas wykonywania zadania.

Instancje zadań przetwarzania o odpowiednim rozmiarze

Wybór odpowiedniego typu i rozmiaru instancji jest głównym czynnikiem optymalizacji kosztów zadań SageMaker Processing. Możesz dopasować rozmiar wystąpienia, migrując do innej wersji w ramach tej samej rodziny wystąpień lub migrując do innej rodziny wystąpień. Podczas migracji w ramach tej samej rodziny instancji należy wziąć pod uwagę tylko procesor/procesor graficzny i pamięć. Aby uzyskać więcej informacji i ogólne wskazówki dotyczące wyboru odpowiednich zasobów przetwarzania, zobacz Zapewnij wydajne zasoby obliczeniowe w Amazon SageMaker.

Aby dostroić wybór instancji, zaczynamy od analizy metryk zadania przetwarzania w CloudWatch. Aby uzyskać więcej informacji, patrz Monitoruj Amazon SageMaker za pomocą Amazon CloudWatch.

CloudWatch zbiera surowe dane z SageMaker i przetwarza je w czytelne wskaźniki w czasie zbliżonym do rzeczywistego. Chociaż te statystyki są przechowywane przez 15 miesięcy, konsola CloudWatch ogranicza wyszukiwanie do danych, które zostały zaktualizowane w ciągu ostatnich 2 tygodni (zapewnia to, że wyświetlane są tylko bieżące oferty pracy). Metryki zadań przetwarzania można znaleźć w przestrzeni nazw /aws/sagemaker/ProcessingJobs, a zebrane metryki są CPUUtilization, MemoryUtilization, GPUUtilization, GPUMemoryUtilization, DiskUtilization.

Poniższy zrzut ekranu pokazuje przykład w CloudWatch zadania przetwarzania, które widzieliśmy wcześniej.

W tym przykładzie widzimy uśrednione wartości procesora i pamięci (co jest wartością domyślną w CloudWatch): średnie użycie procesora to 0.04%, pamięć 1.84%, a użycie dysku 13.7%. Aby dobrać właściwy rozmiar, zawsze należy brać pod uwagę maksymalne wykorzystanie procesora i pamięci (w tym przykładzie maksymalne wykorzystanie procesora wyniosło 98% w ciągu pierwszych 3 minut). Zasadniczo, jeśli maksymalne wykorzystanie procesora i pamięci jest stale mniejsze niż 40%, można bezpiecznie zmniejszyć maszynę o połowę. Na przykład, jeśli używasz instancji ml.c5.4xlarge, możesz przejść do instancji ml.c5.2xlarge, co może obniżyć koszty o 50%.

Praca w firmie Data Wrangler

Data Wrangler jest funkcją Studio Amazon SageMaker które zapewnia powtarzalne i skalowalne rozwiązanie do eksploracji i przetwarzania danych. Używasz interfejsu Data Wrangler do interaktywnego importowania, analizowania, przekształcania i prezentowania danych. Te kroki są rejestrowane w przepisie (plik .flow), którego można następnie użyć w zadaniu Data Wrangler. Ułatwia to ponowne zastosowanie tych samych przekształceń danych do danych, a także skalowanie do rozproszonego zadania przetwarzania danych wsadowych w ramach potoku ML lub niezależnie.

Aby uzyskać wskazówki dotyczące optymalizacji aplikacji Data Wrangler w Studio, zapoznaj się z częścią 2 z tej serii.

W tej sekcji skupiamy się na optymalizacji pracy Data Wranglera.

Data Wrangler używa Zadania przetwarzania SageMaker Spark z kontenerem zarządzanym przez Data Wrangler. Ten kontener uruchamia wskazówki z pliku .flow w zadaniu. Podobnie jak w przypadku innych zadań przetwarzania, Data Wrangler pobiera opłaty za wybrane instancje na podstawie czasu użytkowania i udostępnionej pamięci masowej dołączonej do tej instancji.

W Eksploratorze kosztów możesz filtrować koszty zadań Data Wrangler, stosując filtr według typu użycia. Nazwy tych typów użycia to:

REGION-processing_DW:instanceType (na przykład, USE1-processing_DW:ml.m5.large)
REGION-processing_DW:VolumeUsage.gp2 (na przykład, USE1-processing_DW:VolumeUsage.gp2)

Aby wyświetlić koszt usługi Data Wrangler w Eksploratorze kosztów, przefiltruj usługę, aby korzystać z SageMaker i dla Typ użytkowania, Wybierz processing_DW prefiks i wybierz listę w menu. Spowoduje to wyświetlenie zarówno kosztów związanych z użyciem instancji (w godzinach), jak i pojemnością pamięci masowej (GB). (Jeśli chcesz zobaczyć koszty Studio Data Wrangler, możesz filtrować typ użycia według Studio_DW prefiks.)

Odpowiednio dopasuj i zaplanuj instancje zadań Data Wrangler

Obecnie Data Wrangler obsługuje tylko instancje m5 o następujących rozmiarach: ml.m5.4xlarge, ml.m5.12xlarge i ml.m5.24xlarge. Możesz użyć funkcji zadania rozproszonego, aby precyzyjnie dostosować koszt zadania. Załóżmy na przykład, że musisz przetworzyć zestaw danych, który wymaga 350 GiB w pamięci RAM. 4xlarge (128 GiB) i 12xlarge (256 GiB) mogą nie być w stanie przetworzyć i doprowadzą do użycia instancji m5.24xlarge (768 GiB). Możesz jednak użyć dwóch instancji m5.12xlarge (2 * 256 GiB = 512 GiB) i obniżyć koszty o 40% lub trzech instancji m5.4xlarge (3 * 128 GiB = 384 GiB) i zaoszczędzić 50% m5.24xlarge koszt instancji. Należy pamiętać, że są to szacunki i że przetwarzanie rozproszone może wprowadzić pewne narzuty, które wpłyną na ogólny czas wykonywania.

Zmieniając typ instancji, pamiętaj o zaktualizowaniu pliku Konfiguracja iskry odpowiednio. Na przykład, jeśli masz początkowe zadanie instancji ml.m5.4xlarge skonfigurowane z właściwościami spark.driver.memory ustawiony na 2048 i spark.executor.memory ustaw na 55742, a później przeskaluj do ml.m5.12xlarge, te wartości konfiguracyjne muszą zostać zwiększone, w przeciwnym razie będą wąskim gardłem w zadaniu przetwarzania. Możesz zaktualizować te zmienne w graficznym interfejsie użytkownika Data Wrangler lub w pliku konfiguracyjnym dołączonym do ścieżki konfiguracji (zobacz poniższe przykłady).

Kolejną atrakcyjną funkcją w Data Wrangler jest możliwość ustawić zaplanowane zadanie. Jeśli okresowo przetwarzasz dane, możesz utworzyć harmonogram automatycznego uruchamiania zadania przetwarzania. Można na przykład utworzyć harmonogram, który automatycznie uruchamia zadanie przetwarzania po otrzymaniu nowych danych (przykłady można znaleźć w sekcji Eksport do Amazon S3 or Eksportuj do sklepu z funkcjami Amazon SageMaker). Należy jednak pamiętać, że podczas tworzenia harmonogramu Data Wrangler tworzy plik eventRule w EventBridge. Oznacza to, że zostaniesz również obciążony opłatami za utworzone przez siebie reguły zdarzeń (oraz za instancje używane do uruchamiania zadania przetwarzania). Aby uzyskać więcej informacji, zobacz Ceny Amazon EventBridge.

Wnioski

W tym poście przedstawiliśmy wskazówki dotyczące analizy kosztów i najlepszych praktyk podczas przetwarzania wstępnego

danych przy użyciu zadań SageMaker Processing i Data Wrangler. Podobnie jak w przypadku przetwarzania wstępnego, istnieje wiele opcji i ustawień konfiguracyjnych w budowaniu, szkoleniu i uruchamianiu modeli ML, które mogą prowadzić do niepotrzebnych kosztów. W związku z tym, że uczenie maszynowe staje się potężnym narzędziem w różnych branżach, obciążenia uczenia maszynowego muszą pozostać opłacalne.

SageMaker oferuje szeroki i głęboki zestaw funkcji ułatwiających każdy krok w potoku ML.

Ta solidność zapewnia również możliwości ciągłej optymalizacji kosztów bez uszczerbku dla wydajności lub elastyczności.

O autorach

Analizuj wydatki Amazon SageMaker i określaj możliwości optymalizacji kosztów w oparciu o wykorzystanie, Część 3: Przetwarzanie i zadania administratora danych | Amazon Web Services PlatoBlockchain Data Intelligence. Wyszukiwanie pionowe. AI. Deepali Rajale jest starszym specjalistą AI/ML w AWS. Współpracuje z klientami korporacyjnymi, dostarczając wskazówek technicznych z najlepszymi praktykami wdrażania i utrzymywania rozwiązań AI/ML w ekosystemie AWS. Pracowała z wieloma organizacjami nad różnymi przypadkami użycia głębokiego uczenia się, obejmującymi NLP i wizję komputerową. Pasjonuje się wspieraniem organizacji w wykorzystywaniu generatywnej sztucznej inteligencji w celu poprawy ich doświadczeń związanych z użytkowaniem. W wolnym czasie lubi filmy, muzykę i literaturę.

Uriego Rosenberga jest kierownikiem technicznym ds. sztucznej inteligencji i uczenia maszynowego na Europę, Bliski Wschód i Afrykę. Z siedzibą w Izraelu, Uri działa na rzecz wspierania klientów korporacyjnych we wszystkich aspektach ML w zakresie projektowania, tworzenia i obsługi na dużą skalę. W wolnym czasie lubi jeździć na rowerze, spacerować i oglądać zachody słońca (minimum raz dziennie).