Sklep funkcji Amazon SageMaker to nowa możliwość Amazon Sage Maker który pomaga naukowcom zajmującym się danymi i inżynierom uczenia maszynowego (ML) bezpiecznie przechowywać, odkrywać i udostępniać wyselekcjonowane dane używane w szkoleniach i prognozach. Gdy organizacje tworzą aplikacje oparte na danych przy użyciu ML, nieustannie gromadzą i przenoszą funkcje między coraz bardziej funkcjonalnymi zespołami. Ten ciągły przepływ danych może prowadzić do niespójności funkcji i stać się wąskim gardłem podczas projektowania inicjatyw ML obejmujących wiele zespołów. Na przykład firma zajmująca się handlem elektronicznym może mieć kilka zespołów zajmujących się nauką danych i inżynierią, które pracują nad różnymi aspektami swojej platformy. Zespół Core Search koncentruje się na zrozumieniu zapytań i zadaniach związanych z wyszukiwaniem informacji. Zespół ds. Sukcesu produktu rozwiązuje problemy związane z opiniami klientów i sygnałami zwrotnymi. Zespół ds. Personalizacji korzysta ze strumienia kliknięć i danych sesji do tworzenia modeli ML na potrzeby spersonalizowanych rekomendacji. Ponadto zespoły inżynierii danych, takie jak zespół ds. Doboru danych, mogą wybierać i weryfikować informacje specyficzne dla użytkownika, co jest podstawowym elementem, z którego mogą korzystać inne zespoły. Feature Store działa jako ujednolicony interfejs między tymi zespołami, umożliwiając jednemu zespołowi wykorzystanie funkcji generowanych przez inne zespoły, co minimalizuje narzut operacyjny związany z replikacją i przenoszeniem funkcji między zespołami.
Szkolenie modelu ML gotowego do produkcji zazwyczaj obejmuje dostęp do zróżnicowanego zestawu funkcji, które nie zawsze należą do zespołu tworzącego model i nie są przez niego obsługiwane. Powszechną praktyką organizacji stosujących ML jest traktowanie tych zespołów analityki danych jako indywidualnych grup pracujących niezależnie w ograniczonym zakresie. Skutkuje to przepływami pracy ML bez ustandaryzowanego sposobu udostępniania funkcji między zespołami, co staje się kluczowym czynnikiem ograniczającym produktywność nauki danych i utrudnia naukowcom zajmującym się danymi tworzenie nowych i złożonych modeli. Dzięki współużytkowanemu magazynowi funkcji organizacje mogą osiągnąć korzyści skali. Wraz z udostępnieniem większej liczby funkcji współdzielonych tworzenie i utrzymywanie nowych modeli staje się łatwiejsze i tańsze dla zespołów. Te modele mogą ponownie wykorzystywać funkcje, które zostały już opracowane, przetestowane i oferowane przy użyciu scentralizowanego magazynu funkcji.
W tym poście przedstawiono podstawowe wzorce architektury między kontami dla Feature Store, które można wdrożyć w organizacji z wieloma zespołami inżynierii danych i nauki o danych działającymi na różnych kontach AWS. Udostępniamy, jak włączyć udostępnianie funkcji między kontami, przedstawiając przykład krok po kroku, który możesz wypróbować samodzielnie, korzystając z kodu w naszym GitHub repo.
Przegląd SageMaker Feature Store
Domyślnie SageMaker Feature Store jest lokalny dla konta, na którym został utworzony, ale może być również scentralizowany i współdzielony przez wiele kont. Organizacja z wieloma zespołami może mieć jeden scentralizowany magazyn funkcji, który jest współużytkowany przez zespoły, a także oddzielne magazyny funkcji do użytku przez poszczególne zespoły. Oddzielne magazyny mogą zawierać grupy funkcji o wrażliwym charakterze lub specyficzne dla unikatowego obciążenia ML.
W tym poście najpierw dowiesz się o scentralizowane sklep z funkcjami wzór. Ten wzorzec wyznacza centralny interfejs, za pomocą którego zespoły mogą tworzyć i publikować nowe funkcje oraz z którego inne zespoły (lub systemy) mogą korzystać z funkcji. Zapewnia również dostęp do jednego źródła prawdziwych danych o funkcjach w całej organizacji i upraszcza zarządzanie zasobami.
Następnie dowiesz się o sklep z połączonymi funkcjami wzorzec, który umożliwia zespołom utrzymywanie własnych magazynów funkcji lokalnie na swoim koncie, przy jednoczesnym zachowaniu dostępu do funkcji współdzielonych ze scentralizowanego magazynu funkcji. Te lokalne magazyny funkcji są zwykle tworzone w celu eksperymentowania z nauką o danych. Łącząc funkcje wspólne ze scentralizowanego sklepu z funkcjami lokalnymi, zespoły mogą uzyskać nowe, ulepszone funkcje, które mogą pomóc w tworzeniu bardziej złożonych modeli ML. Możesz również używać lokalnych sklepów do przechowywania poufnych danych, których nie można udostępniać w całej organizacji ze względów prawnych i zgodności.
Na koniec omówimy pokrótce mniej powszechny wzorzec obejmujący replikację danych o cechach.
Scentralizowany magazyn funkcji
Organizacje mogą zmaksymalizować korzyści ze sklepu funkcji, gdy jest on scentralizowany. Plik scentralizowany magazyn funkcji wzorzec pokazuje, jak potoki funkcji z wielu kont mogą zapisywać w jednym scentralizowanym magazynie funkcji oraz jak wiele innych kont może korzystać z tych funkcji. Jest to powszechny wzorzec w średnich i dużych przedsiębiorstwach, w których wiele zespołów zarządza różnymi typami danych lub różnymi częściami aplikacji.
Nazywa się proces tworzenia hipotez, wybierania i przekształcania danych wejściowych w użyteczną formę odpowiednią dla modeli ML inżynieria funkcji, ZA funkcja potoku obejmuje wszystkie etapy procesu inżynierii funkcji potrzebne do przekształcenia surowych danych w przydatne funkcje, które modele ML przyjmują jako dane wejściowe do prognoz. Utrzymywanie potoków funkcji jest procesem kosztownym, czasochłonnym i podatnym na błędy. Ponadto replikowanie receptur funkcji i przekształceń między kontami może prowadzić do niespójności i wypaczenia cech funkcji. Ponieważ scentralizowany magazyn funkcji ułatwia dzielenie się wiedzą, zespoły nie muszą odtwarzać receptur funkcji i przepisywać potoków od podstaw w każdym projekcie.
W tym wzorcu, zamiast zapisywać funkcje lokalnie w sklepie funkcji dla konkretnego konta, funkcje są zapisywane w scentralizowanym magazynie funkcji. Scentralizowany magazyn służy jako skarbiec centralny i tworzy ustandaryzowany sposób uzyskiwania dostępu i utrzymywania funkcji współpracy między zespołami. Działa jako czynnik umożliwiający i przyspieszający wdrażanie sztucznej inteligencji, skracając czas wprowadzania na rynek rozwiązań ML i umożliwia scentralizowane zarządzanie i kontrolę dostępu do funkcji ML. Możesz przyznać dostęp do zewnętrznych kont, użytkowników lub ról w celu odczytu i zapisu poszczególnych grup funkcji zgodnie z zasadami dostępu do danych. AWS zaleca wymuszanie dostępu do najniższych uprawnień tylko do tych grup funkcji, które są potrzebne do pełnionej funkcji. Jest to zarządzane przez instrument bazowy AWS Zarządzanie tożsamością i dostępem (IAM) zasady. Możesz dodatkowo udoskonalić kontrolę dostępu za pomocą tagów grup funkcji i Warunki uprawnień zdecydować, którzy zleceniodawcy mogą wykonywać określone czynności. W przypadku korzystania ze scentralizowanego sklepu na dużą skalę ważne jest również zaimplementowanie odpowiedniego zarządzania funkcjami, aby upewnić się, że grupy funkcji są dobrze zaprojektowane, mają udokumentowane i obsługiwane potoki funkcji oraz mają wdrożone procesy zapewniające jakość funkcji. Ten rodzaj zarządzania pomaga zdobyć zaufanie wymagane do ponownego wykorzystania funkcji w zespołach.
Zanim przejdziemy do przykładu, zidentyfikujmy kilka kluczowych koncepcji sklepu z funkcjami. Pierwszy, grupy funkcji to logiczne grupy cech, zwykle pochodzące z tego samego potoku funkcji. Na sklep offline zawiera duże ilości historycznych danych o cechach używanych do tworzenia danych szkoleniowych i testowych do tworzenia modeli lub przez aplikacje wsadowe do oceniania modeli. Celem sklep internetowy ma obsługiwać te same funkcje w czasie rzeczywistym z niskim opóźnieniem. W przeciwieństwie do sklepu offline, który służy tylko do dołączania, celem sklepu internetowego jest udostępnianie najnowszych wartości funkcji. Za kulisami Feature Store automatycznie przeprowadza synchronizację danych między dwoma sklepami. Jeśli pozyskujesz nowe wartości funkcji do sklepu online, są one automatycznie dołączane do sklepu offline. Możesz jednak także tworzyć wiadomości offline i online
tores osobno, jeśli jest to wymagane dla Twojego zespołu lub projektu.
Poniższy diagram przedstawia trzy zespoły funkcjonalne, z których każdy ma własny potok funkcji zapisujący w grupie funkcji w scentralizowanym magazynie funkcji.
Konto Personalizacja zarządza danymi sesji użytkownika zebranymi z aplikacji skierowanej do klienta i jest właścicielem potoku funkcji, który tworzy grupę funkcji o nazwie Sesje z funkcjami pochodzącymi z danych sesji. Ten potok zapisuje wygenerowane wartości funkcji do scentralizowanego magazynu funkcji. Podobnie potok funkcji na koncie Sukces produktu jest odpowiedzialny za tworzenie funkcji w grupie funkcji Recenzje, a konto Dobór danych tworzy funkcje w grupie funkcji Użytkownicy.
Scentralizowane konto sklepu z funkcjami zawiera wszystkie funkcje otrzymane z trzech kont producentów, przypisane do trzech grup funkcji: Sesje, Recenzje i Użytkownicy. Potoki funkcji mogą zapisywać dane w scentralizowanym magazynie funkcji, przyjmując określoną rolę uprawnień, która jest tworzona na koncie scentralizowanego sklepu. Omówimy, jak włączyć tę rolę dla wielu kont w dalszej części tego wpisu. Konta zewnętrzne mogą również wysyłać zapytania do funkcji z grup funkcji w scentralizowanym magazynie w celu szkolenia lub wnioskowania, jak pokazano na poprzednim diagramie architektury. Na potrzeby szkolenia możesz przyjąć rolę IAM ze scentralizowanego sklepu i uruchomić wiele kont Amazonka Atena zapytania (jak pokazano na diagramie) lub zainicjuj Amazon EMR or Przetwarzanie SageMaker zadanie tworzenia zbiorów danych szkoleniowych. W przypadku wnioskowania w czasie rzeczywistym możesz czytać funkcje online bezpośrednio, korzystając z tej samej, założonej roli IAM dla dostępu do wielu kont.
W tym modelu scentralizowany magazyn elementów zwykle znajduje się na koncie produkcyjnym. Aplikacje korzystające z tego sklepu mogą znajdować się na tym koncie lub na innych kontach z dostępem dla wielu kont do scentralizowanego magazynu funkcji. Możesz replikować całą tę strukturę w niższych środowiskach, takich jak programowanie lub przemieszczanie, w celu testowania zmian infrastruktury przed promowaniem ich do produkcji.
Sklep z połączonymi funkcjami
W tej sekcji omówimy wariant scentralizowanego wzorca magazynu elementów o nazwie sklep z połączonymi funkcjami wzór. W inżynierii cech powszechną praktyką jest łączenie istniejących funkcji w celu uzyskania nowych funkcji. Gdy zespoły łączą funkcje udostępnione ze scentralizowanego sklepu z funkcjami lokalnymi we własnym magazynie funkcji, mogą uzyskać nowe, ulepszone funkcje, aby pomóc w tworzeniu bardziej złożonych modeli danych. Wiemy z poprzedniej sekcji, że scentralizowany magazyn ułatwia każdemu zespołowi analityków danych dostęp do funkcji zewnętrznych i używanie ich z istniejącą pulą funkcji w celu łączenia i rozwijania nowych funkcji.
Bezpieczeństwo i zgodność to kolejny przypadek użycia dla zespołów do utrzymywania magazynu funkcji specyficznych dla zespołu, oprócz uzyskiwania dostępu do funkcji ze scentralizowanego magazynu. Wiele zespołów wymaga określonych praw dostępu, które nie są przyznawane wszystkim w organizacji. Na przykład może nie być możliwe opublikowanie funkcji wyodrębnionych z poufnych danych w scentralizowanym magazynie funkcji w organizacji.
Na poniższym diagramie architektury scentralizowany magazyn funkcji to konto, które gromadzi i kataloguje wszystkie funkcje otrzymane z wielu potoków funkcji w jednym centralnym repozytorium. W tym przykładzie konto połączonego sklepu należy do zespołu Core Search. To konto jest odbiorcą udostępnianych funkcji ze scentralizowanego sklepu. Ponadto to konto zarządza danymi słów kluczowych użytkowników zbieranymi za pośrednictwem aplikacji wyszukiwania dostępnej dla klientów.
To konto prowadzi własne lokalne sklepy offline i online. Te magazyny lokalne są zapełniane przez potok funkcji skonfigurowany lokalnie w celu pozyskiwania danych słów kluczowych zapytań użytkownika i generowania funkcji. Te funkcje są zgrupowane w grupie funkcji o nazwie Słowa kluczowe. Feature Store domyślnie automatycznie tworzy plik Klej AWS tabela dla tej grupy funkcji, która jest zarejestrowana w katalogu danych kleju AWS na tym koncie. Metadane tej tabeli wskazują lokalizację Amazon S3 grupy funkcji w sklepie offline tego konta.
Połączone konto sklepu może również uzyskiwać dostęp do grup funkcji, sesji, recenzji i użytkowników ze scentralizowanego sklepu. Możesz włączyć dostęp do wielu kont według roli, co omówimy w następnych sekcjach. Naukowcy zajmujący się danymi i badacze mogą wykorzystać Athena do przeszukiwania grup funkcji utworzonych lokalnie i łączenia tych funkcji wewnętrznych z funkcjami zewnętrznymi pochodzącymi ze scentralizowanego magazynu na potrzeby eksperymentów z nauką danych.
Omówienie dostępu do wielu kont
Ta sekcja zawiera omówienie sposobu włączania dostępu do wielu kont Feature Store między dwoma kontami przy użyciu zakładanej roli za pośrednictwem Usługa tokena bezpieczeństwa AWS (AWS STS). AWS STS to usługa internetowa, która umożliwia żądanie tymczasowych poświadczeń z ograniczonymi uprawnieniami dla użytkowników IAM. AWS STS zwraca zestaw tymczasowych poświadczeń bezpieczeństwa, których możesz użyć, aby uzyskać dostęp do zasobów AWS, do których normalnie nie masz dostępu. Te tymczasowe poświadczenia składają się z identyfikatora klucza dostępu, tajnego klucza dostępu i tokenu zabezpieczającego.
Aby zademonstrować ten proces, załóżmy, że mamy dwa konta, A i B, jak pokazano na poniższym diagramie.
Konto B utrzymuje scentralizowany magazyn funkcji online i offline. Konto A potrzebuje dostępu do sklepów online i offline zawartych na Koncie B. Aby to umożliwić, tworzymy rolę na Koncie B i pozwalamy Kontu A przejąć tę rolę przy użyciu AWS STS. Dzięki temu konto A może zachowywać się jak konto B, z uprawnieniami do wykonywania określonych działań określonych przez rolę. Usługi AWS, takie jak SageMaker (zadania przetwarzania i szkolenia, punkty końcowe) i AWS Lambda używany z konta A może przyjąć rolę IAM utworzoną na koncie B przy użyciu klienta AWS STS (zobacz blok kodu w dalszej części tego postu). To daje im niezbędne uprawnienia dostępu do zasobów, takich jak Amazon S3, Athena i AWS Glue Data Catalog na koncie B. Po uzyskaniu przez usługi na koncie A niezbędnych uprawnień do zasobów, mogą uzyskać dostęp zarówno do sklepu offline, jak i online na koncie B. W zależności od wyboru usługi musisz również dodać rolę wykonawczą IAM dla tej usługi do zaufanej zasady roli IAM dla wielu kont na koncie B. Omówimy to szczegółowo w następnej sekcji.
Powyższy diagram architektury pokazuje, jak konto A przyjmuje rolę od konta B do odczytywania i zapisywania w sklepach online i offline zawartych na koncie B. Siedem kroków na diagramie jest następujących:
- Konto B tworzy rolę, którą mogą przejąć inne osoby (w naszym przypadku jest to Konto A).
- Konto A przyjmuje rolę IAM z Konta B przy użyciu AWS STS. Konto A może teraz generować tymczasowe poświadczenia, których można użyć do tworzenia klientów usługi AWS, które zachowują się tak, jakby znajdowały się na koncie B.
- Na koncie A, SageMaker i inne usługi
klienci (tacy jak Amazon S3 i Athena) są tworzeni przy użyciu tymczasowych poświadczeń za pośrednictwem przyjętej roli. - Klienci usług na Koncie A mogą teraz tworzyć grupy funkcji i wprowadzać wartości funkcji do scentralizowanego sklepu internetowego Konta B za pomocą AWS SDK.
- Sklep internetowy na koncie B automatycznie synchronizuje się ze sklepem offline, również na koncie B.
- Klient usługi Athena na koncie A uruchamia zapytania między kontami w celu odczytywania, grupowania i materializowania zestawów funkcji przy użyciu tabel Athena na koncie B. Ponieważ sklep offline istnieje na koncie B, odpowiadające mu tabele kleju AWS, wpisy katalogu metadanych i obiekty S3 wszystkie znajdują się na Koncie B. Konto A może używać AWS STS do wykonywania zapytań o funkcje offline (obiekty S3) na Koncie B.
- Wyniki zapytania Athena są zwracane jako zestawy danych funkcji do zasobnika S3 Konta A.
Tymczasowe poświadczenia korzystają z API AWS STS GetSessionToken i są ograniczone do 1 godziny. Możesz przedłużyć czas trwania sesji używając Odświeżane poświadczenia, klasa Botocore, która może automatycznie odświeżać poświadczenia, aby pracować z długo działającymi aplikacjami po upływie 1 godziny. Na przykładowy notatnik wykazanie tego jest dostępne w naszym repozytorium GitHub.
Utwórz dostęp do wielu kont
W tej sekcji opisano wszystkie kroki tworzenia ról, zasad i uprawnień dostępu do wielu kont, aby umożliwić współużytkowanie funkcji między kontami A i B zgodnie z naszą architekturą.
Utwórz rolę dostępu do Feature Store
Na koncie B tworzymy rolę dostępu do Feature Store. Jest to rola pełniona przez usługi AWS na Koncie A w celu uzyskania dostępu do zasobów na Koncie B.
- W konsoli IAM w okienku nawigacji wybierz role.
- Dodaj Utwórz rolę.
- Dodaj Kolejne konto AWS.
- W razie zamówieenia projektu ID kontawprowadź 12-cyfrowy identyfikator konta B.
- Dodaj Dalej: Uprawnienia.
- W Uprawnienia wyszukaj i dołącz następujące polityki zarządzane przez AWS:
AmazonSageMakerFullAccess
(możesz dodatkowo ograniczyć to do najmniejszych uprawnień w oparciu o swój przypadek użycia)AmazonSageMakerFeatureStoreAccess
- Utwórz i dołącz niestandardową zasadę do tej nowej roli (podaj nazwę zasobnika S3 na koncie A, gdzie zapisywane są wyniki zapytania Athena zebrane na koncie B):
Gdy używasz tej nowej roli między kontami AWS STS z konta A, może ona uruchamiać zapytania Athena dotyczące zawartości sklepu offline na koncie B. Niestandardowe zasady umożliwiają Athenie (wewnątrz konta B) zapisywanie wyników w zasobniku wyników na koncie A. Upewnij się, że ten zasobnik wyników został utworzony na koncie A przed utworzeniem poprzedniej zasady.
Alternatywnie możesz pozwolić scentralizowanemu przechowywaniu funkcji na koncie B zachować wszystkie wyniki zapytań Athena w zasobniku S3. W takim przypadku należy skonfigurować zasady dostępu do odczytu Amazon S3 dla wielu kont dla kont zewnętrznych, aby odczytać zapisane wyniki (obiekty S3).
- Po załączeniu zasad wybierz Następna.
- Wprowadź nazwę dla tej roli (na przykład przejmowanie roli dla wielu kont).
- Na Podsumowanie strona dla utworzonej roli, pod Relacje zaufaniawybierz Edytuj relację zaufania.
- Edytuj dokument zasad kontroli dostępu, jak pokazano w poniższym kodzie:
Poprzedni kod dodaje SageMaker i Athena jako usługi w sekcji Principal. Jeśli chcesz, aby więcej zewnętrznych kont lub ról pełniło tę rolę, możesz dodać odpowiadające im ARN w tej sekcji.
Utwórz instancję notatnika SageMaker
Na koncie A utwórz instancję notatnika SageMaker z rolą wykonawczą IAM. Ta rola przyznaje notatnikowi SageMaker na Koncie A wymagane uprawnienia do uruchamiania akcji w magazynie funkcji na Koncie B. Alternatywnie, jeśli nie używasz notatnika SageMaker i zamiast tego używasz Lambda, musisz utworzyć rolę dla Lambda z tym samym dołączone zasady, jak pokazano w tej sekcji.
Domyślnie podczas tworzenia nowej roli wykonawczej dla notatnika SageMaker dołączane są następujące zasady:
AmazonSageMaker-ExecutionPolicy
AmazonSageMakerFullAccess
Musimy utworzyć i dołączyć dwie dodatkowe niestandardowe zasady. Najpierw utwórz niestandardową zasadę z następującym kodem, który pozwoli roli wykonawczej na koncie A na wykonanie pewnych działań S3 potrzebnych do interakcji ze sklepem offline na koncie B:
Możesz również dołączyć zasady zarządzane przez AWS AmazonSageMakerFeatureStoreAccess
, jeśli nazwa zasobnika S3 Twojego sklepu offline zawiera rozszerzenie SageMaker
słowo kluczowe.
Po drugie, utwórz następującą niestandardową zasadę, która pozwoli notatnikowi SageMaker na koncie A przejąć rolę (cross-account-assume-role
) utworzone na koncie B:
Wiemy, że Konto A może uzyskiwać dostęp do sklepu online i offline na Koncie B. Kiedy Konto A przejmuje rolę AWS STS międzykontowego Konta B, może uruchamiać zapytania Athena wewnątrz Konta B względem swojego sklepu offline. Jednak wyniki tych zapytań (zestawy danych funkcji) muszą zostać zapisane w zasobniku S3 konta A, aby umożliwić trenowanie modelu. Dlatego musimy utworzyć zasobnik na koncie A, który może przechowywać wyniki zapytania Athena, a także utworzyć zasady zasobnika (zobacz poniższy kod). Ta zasada umożliwia międzykontowej roli AWS STS zapisywanie i odczytywanie obiektów w tym
wiaderko:
Zmodyfikuj zasady relacji zaufania
Ponieważ utworzyliśmy rolę wykonawczą IAM na koncie A, używamy ARN tej roli do modyfikowania zasad relacji zaufania dotyczących między kontami przejmującymi rolę na koncie B:
Sprawdź poprawność procesu konfiguracji
Po skonfigurowaniu wszystkich ról i towarzyszących zasad można sprawdzić poprawność konfiguracji, uruchamiając przykładowe notesy w GitHub repo. Poniższy blok kodu jest fragmentem przykładowego notatnika i musi być uruchomiony w notatniku SageMaker działającym na koncie A. Pokazuje, w jaki sposób można przejąć rolę wielu kont z konta B przy użyciu AWS STS za pośrednictwem Przyjmij rolę Wywołanie API. To wywołanie zwraca zestaw tymczasowych poświadczeń, których konto A może używać do tworzenia dowolnych klientów usługi. W przypadku korzystania z tych klientów kod używa uprawnień przyjętej roli i zachowuje się tak, jakby należał do konta B. Aby uzyskać więcej informacji, zobacz zakładaj_role w dokumentacji AWS SDK for Python (Boto 3).
Po utworzeniu klientów SageMaker zgodnie z poprzednim przykładem kodu na koncie A, można tworzyć grupy funkcji i wprowadzać funkcje do scentralizowanego sklepu online i offline konta B. Aby uzyskać więcej informacji na temat tworzenia, opisywania i usuwania grup funkcji, zobacz utwórz_grupę_funkcji w dokumentacji Boto3. Możesz również użyć Klient środowiska wykonawczego Feature Store umieszczać i pobierać rekordy funkcji do iz grup funkcji.
Replikacja magazynu offline
Odtwarzalność to możliwość dokładnego odtworzenia modelu ML, więc jeśli używasz tych samych funkcji, co dane wejściowe, model zwraca te same dane wyjściowe, co model oryginalny. Zasadniczo to właśnie staramy się osiągnąć między modelami, które opracowujemy w środowisku badawczym i wdrażamy w środowisku produkcyjnym. Replikowanie potoków inżynierii funkcji na kontach jest złożonym i czasochłonnym procesem, który może powodować rozbieżności w modelu, jeśli nie zostanie prawidłowo wdrożony. Jeśli zestaw funkcji używany do trenowania modelu zmienia się po fazie uczenia, odtworzenie modelu może być trudne lub niemożliwe.
Aplikacje rezydujące w AWS zwykle mają kilka różnych środowisk i kont, takich jak programowanie, testowanie, przemieszczanie i produkcja. Aby osiągnąć zautomatyzowane wdrożenie aplikacji w różnych środowiskach, używamy potoków CI / CD. Organizacje często muszą utrzymywać izolowane środowiska pracy i wiele kopii danych w tym samym lub różnych regionach AWS lub na różnych kontach AWS. W kontekście Feature Store niektóre firmy mogą chcieć replikować dane z magazynu funkcji offline. Replikacja magazynu offline za pośrednictwem Replikacja Amazon S3 w tym przypadku może być przydatnym wzorcem. Ten wzorzec umożliwia izolowanym środowiskom i kontom ponowne trenowanie modeli ML przy użyciu pełnych zestawów funkcji bez używania ról lub uprawnień dla wielu kont.
Wnioski
W tym poście zademonstrowaliśmy różne wzorce architektury, takie jak scentralizowany magazyn funkcji, połączony magazyn funkcji i inne zagadnienia projektowe dotyczące SageMaker Feature Store, które są niezbędne do współpracy międzyfunkcyjnej w dziedzinie nauki o danych. Pokazaliśmy również, jak skonfigurować dostęp do wielu kont za pomocą AWS STS.
Aby dowiedzieć się więcej o możliwościach i przypadkach użycia Feature Store, zobacz Zrozumienie kluczowych możliwości Amazon SageMaker Feature Store i Korzystanie z przetwarzania strumieniowego w sklepie Amazon SageMaker Feature Store do podejmowania decyzji opartych na technologii ML w czasie prawie rzeczywistym.
Jeśli masz jakieś uwagi lub pytania, zostaw je w sekcji komentarzy.
O autorach
Arunprasath Shankar jest specjalistą ds. rozwiązań w zakresie sztucznej inteligencji i uczenia maszynowego (AI / ML) w AWS, pomagając globalnym klientom skutecznie i wydajnie skalować rozwiązania AI w chmurze. W wolnym czasie Arun lubi oglądać filmy science fiction i słuchać muzyki klasycznej.
Marka Roya jest głównym architektem uczenia maszynowego dla AWS, pomagając klientom AWS projektować i budować rozwiązania AI / ML. Praca Marka obejmuje szeroki zakres przypadków użycia ML, z głównym zainteresowaniem widzeniem komputerowym, głębokim uczeniem się i skalowaniem ML w całym przedsiębiorstwie. Pomagał firmom z wielu branż, w tym ubezpieczeń, usług finansowych, mediów i rozrywki, opieki zdrowotnej, usług komunalnych i produkcji. Mark posiada 6 certyfikatów AWS, w tym ML Specialty Certification. Przed dołączeniem do AWS Mark był architektem, programistą i liderem technologicznym przez ponad 25 lat, w tym 19 lat w usługach finansowych.
Stefana Natu jest starszym architektem rozwiązań AI / ML w firmie Amazon Web Services. Koncentruje się na pomaganiu klientom usług finansowych w tworzeniu kompleksowych rozwiązań uczenia maszynowego w AWS. W wolnym czasie czyta blogi o uczeniu maszynowym, gra na gitarze i odkrywa kulinarną scenę Nowego Jorku.
- akcelerator
- dostęp
- Konto
- Działania
- Dodatkowy
- Przyjęcie
- AI
- Przyjęcie AI
- Amazonka
- Amazon Sage Maker
- Amazon Web Services
- wśród
- api
- Zastosowanie
- aplikacje
- architektura
- sztuczna inteligencja
- Sztuczna inteligencja i uczenie maszynowe
- zautomatyzowane
- AWS
- za kulisami
- blogi
- budować
- Budowanie
- wezwanie
- Etui
- Certyfikacja
- Miasto
- klientów
- Chmura
- kod
- współpraca
- komentarze
- wspólny
- Firmy
- sukcesy firma
- spełnienie
- składnik
- Mieszanka
- Wizja komputerowa
- konsumować
- konsument
- zawartość
- Listy uwierzytelniające
- Klientów
- dane
- dostęp do danych
- nauka danych
- głęboka nauka
- Wnętrze
- detal
- rozwijać
- Deweloper
- oprogramowania
- ecommerce
- Inżynieria
- Inżynierowie
- Enterprise
- rozrywka
- Środowisko
- egzekucja
- Cecha
- Korzyści
- budżetowy
- usługi finansowe
- i terminów, a
- jedzenie
- Nasz formularz
- pełny
- funkcjonować
- GitHub
- Globalne
- zarządzanie
- Dotacje
- Zarządzanie
- opieki zdrowotnej
- przytrzymaj
- W jaki sposób
- How To
- HTTPS
- IAM
- zidentyfikować
- tożsamość
- Włącznie z
- przemysłowa
- Informacja
- Infrastruktura
- ubezpieczenie
- Inteligencja
- odsetki
- IT
- Praca
- Oferty pracy
- przystąpić
- konserwacja
- Klawisz
- wiedza
- duży
- prowadzić
- UCZYĆ SIĘ
- nauka
- Dźwignia
- Ograniczony
- Lista
- Słuchanie
- miejscowy
- lokalnie
- lokalizacja
- uczenie maszynowe
- i konserwacjami
- produkcja
- znak
- rynek
- Media
- ML
- model
- Kino
- Muzyka
- Nawigacja
- Nowa cecha
- Nowe funkcje
- I Love New York
- nowy jork
- laptopy
- Online
- sklep internetowy
- operacyjny
- zamówienie
- Inne
- Pozostałe
- Wzór
- personalizacja
- Platforma
- polityka
- polityka
- basen
- przepowiednia
- Przewidywania
- producent
- Produkt
- Produkcja
- wydajność
- projekt
- publikować
- Python
- jakość
- zasięg
- Surowy
- surowe dane
- Czytający
- w czasie rzeczywistym
- Przyczyny
- przepisy
- dokumentacja
- Relacje
- Badania naukowe
- Zasób
- Zasoby
- Efekt
- powraca
- Recenzje
- run
- bieganie
- sagemaker
- Skala
- skalowaniem
- nauka
- Naukowcy
- Sdk
- Szukaj
- bezpieczeństwo
- Usługi
- zestaw
- Share
- shared
- So
- Rozwiązania
- Zestawienie sprzedaży
- sklep
- sklep
- Streaming
- sukces
- Utrzymany
- systemy
- Technologia
- tymczasowy
- Testowanie
- czas
- żeton
- Trening
- Zaufaj
- Użytkownicy
- Użytkowe
- wizja
- chodzący
- sieć
- usługi internetowe
- w ciągu
- Praca
- działa
- pisanie
- lat