Amazon SageMaker Feature Store új képessége Amazon SageMaker amely segít az adattudósoknak és a gépi tanulási (ML) mérnököknek biztonságosan tárolni, felfedezni és megosztani a képzési és előrejelzési munkafolyamatokhoz felhasznált, válogatott adatokat. Miközben a szervezetek adatvezérelt alkalmazásokat készítenek ML segítségével, folyamatosan összeállítanak és mozgatnak funkciókat egyre több funkcionális csapat között. Az adatoknak ez az állandó mozgása következetlenségekhez vezethet a szolgáltatásokban, és szűk keresztmetszetet jelenthet több csapatot átfogó ML kezdeményezések tervezésekor. Például egy e-kereskedelmi vállalatnál több adattudományi és mérnöki csapat dolgozik a platformjuk különböző szempontjain. A Core Search csapata a lekérdezések megértésére és az információkeresési feladatokra összpontosít. A Product Success csapata megoldja a vásárlói véleményekkel és visszajelzésekkel kapcsolatos problémákat. A személyre szabott csapat a kattintásfolyam- és munkamenet-adatokat használja fel ML-modellek létrehozására személyre szabott ajánlásokhoz. Ezenkívül az adatmérnöki csapatok, például a Data Curation csapata kezelhetik és ellenőrizhetik a felhasználóspecifikus információkat, amelyek más csapatok által felhasználható alapvető összetevők. A Feature Store egységes felületként működik e csapatok között, lehetővé téve az egyik csapat számára, hogy kihasználja a többi csapat által generált szolgáltatásokat, ami minimálisra csökkenti a funkciók csapatok közötti replikálásának és áthelyezésének többletköltségét.
A gyártásra kész ML-modell betanítása jellemzően olyan különféle funkciókhoz való hozzáférést foglal magában, amelyek nem mindig a modellt építő csapat tulajdonában és karbantartásában állnak. Az ML-t alkalmazó szervezetek bevett gyakorlata, hogy ezeket az adattudományi csapatokat egyéni csoportoknak tekintik, amelyek egymástól függetlenül, korlátozott együttműködéssel dolgoznak. Ez olyan ML-munkafolyamatokat eredményez, amelyekben nincs szabványos mód a funkciók csapatok közötti megosztására, ami döntő korlátozó tényezővé válik az adattudományi termelékenység szempontjából, és megnehezíti az adatkutatók számára az új és összetett modellek felépítését. A megosztott szolgáltatások tárolójával a szervezetek méretgazdaságosságot érhetnek el. Ahogy egyre több megosztott funkció válik elérhetővé, a csapatok könnyebben és olcsóbban tudnak új modelleket építeni és karbantartani. Ezek a modellek újra fel tudják használni a már kifejlesztett, tesztelt és egy központi szolgáltatástároló segítségével kínált funkciókat.
Ez a bejegyzés rögzíti a Feature Store lényeges, több fiókra kiterjedő architektúra mintáit, amelyek megvalósíthatók egy olyan szervezetben, ahol számos adatmérnöki és adattudományi csapat működik különböző AWS-fiókokban. Egy lépésről lépésre bemutatott példán keresztül megosztjuk a funkciók fiókok közötti megosztásának engedélyezését, amelyet Ön is kipróbálhat az oldalunkon található kóddal. GitHub repo.
A SageMaker Feature Store áttekintése
Alapértelmezés szerint a SageMaker Feature Store helyileg ahhoz a fiókhoz tartozik, amelyben létrehozták, de központosítható és számos fiók megosztható. Egy több csapattal rendelkező szervezet rendelkezhet egyetlen központi szolgáltatástárolóval, amely meg van osztva a csapatok között, valamint külön szolgáltatástárolókkal, amelyeket az egyes csapatok használhatnak. A különálló tárolók vagy érzékeny jellegű, vagy egyedi ML-munkaterhelésre jellemző szolgáltatáscsoportokat tartalmazhatnak.
Ebben a bejegyzésben először megismerheti a központosított funkció bolt minta. Ez a minta egy központi felületet ír elő, amelyen keresztül a csapatok új funkciókat hozhatnak létre és közzétehetnek, és amelyről más csapatok (vagy rendszerek) szolgáltatásokat fogyaszthatnak. Azt is biztosítja, hogy egyetlen igazságforrás álljon rendelkezésére a szolgáltatási adatokhoz az egész szervezetben, és leegyszerűsíti az erőforrás-kezelést.
Ezután megtudhatja a kombinált funkció bolt mintát, amely lehetővé teszi a csapatok számára, hogy saját fiókjukhoz tartozó saját szolgáltatástárolókat tartsanak fenn, miközben továbbra is hozzáférhetnek a megosztott funkciókhoz a központi funkciótárolóból. Ezek a helyi szolgáltatástárolók általában adattudományi kísérletezésre készültek. A központosított áruház megosztott funkcióinak a helyi funkciókkal való kombinálásával a csapatok új, továbbfejlesztett funkciókhoz juthatnak, amelyek segíthetnek az összetettebb ML-modellek felépítésében. A helyi üzletekben olyan érzékeny adatokat is tárolhat, amelyek szabályozási és megfelelőségi okokból nem oszthatók meg a szervezeten belül.
Végül röviden bemutatunk egy kevésbé gyakori mintát, amely magában foglalja a jellemzőadatok replikációját.
Központi szolgáltatástároló
A szervezetek maximalizálhatják a szolgáltatásbolt előnyeit, ha az központosított. A központi szolgáltatástároló minta bemutatja, hogy a több fiókból származó szolgáltatásfolyamatok hogyan tudnak egyetlen központi szolgáltatástárolóba írni, és hogy több másik fiók hogyan használhatja fel ezeket a szolgáltatásokat. Ez egy gyakori minta a közepes és nagy méretű vállalatoknál, ahol több csapat kezeli a különböző típusú adatokat vagy egy alkalmazás különböző részeit.
Az adatbevitelek hipotézisének, kiválasztásának és az ML-modellek számára megfelelő használható formává alakításának folyamatát ún. jellemző tervezés. A jellemző csővezeték magában foglalja a szolgáltatástervezési folyamat összes lépését, amely ahhoz szükséges, hogy a nyers adatokat hasznos funkciókká alakítsa, amelyeket az ML-modellek az előrejelzések bemeneteként vesznek fel. A szolgáltatási folyamatok karbantartása költséges, időigényes és hibákra hajlamos folyamat. Ezenkívül a szolgáltatásreceptek és átalakítások fiókok közötti replikálása következetlenségekhez és torzulásokhoz vezethet a funkciók jellemzőiben. Mivel a központosított szolgáltatástároló megkönnyíti a tudásmegosztást, a csapatoknak nem kell minden projektben a semmiből újból elkészíteniük a funkciók receptjeit és átírniuk a folyamatokat.
Ebben a mintában a szolgáltatások helyileg egy fiókspecifikus szolgáltatástárolóba írása helyett a szolgáltatások egy központi szolgáltatástárolóba íródnak. A központosított áruház központi tárolóként szolgál, és szabványosított módot teremt a funkciók elérésére és karbantartására a csoportok közötti együttműködéshez. Lehetővé teszi és gyorsítója a mesterséges intelligencia bevezetésének, csökkentve az ML-megoldások piacra kerülésének idejét, és lehetővé teszi az ML-szolgáltatások központosított irányítását és hozzáférés-szabályozását. Hozzáférést biztosíthat külső fiókoknak, felhasználóknak vagy szerepköröknek az egyes szolgáltatáscsoportok olvasásához és írásához az adathozzáférési szabályzatokkal összhangban. Az AWS azt javasolja, hogy csak azokhoz a szolgáltatáscsoportokhoz kényszerítse ki a legkisebb jogosultságokhoz való hozzáférést, amelyekre szüksége van a feladatköréhez. Ezt a mögöttes kezeli AWS Identity and Access Management (IAM) irányelvei. Tovább finomíthatja a hozzáférés-szabályozást szolgáltatáscsoport-címkékkel és IAM feltételek annak eldöntésére, hogy mely megbízók hajthatnak végre konkrét műveleteket. Ha nagyszabású központosított áruházat használ, fontos a megfelelő funkcióirányítás bevezetése is annak biztosítása érdekében, hogy a funkciócsoportok jól meg legyenek tervezve, dokumentált és támogatott szolgáltatási folyamatokkal rendelkezzenek, valamint folyamatok legyenek a funkciók minőségének biztosítására. Az ilyen típusú irányítás segít elnyerni a bizalmat, amely a funkciók csapatok közötti újrafelhasználásához szükséges.
Mielőtt végigmennénk egy példán, azonosítsunk néhány kulcsfontosságú szolgáltatástároló fogalmat. Első, jellemzőcsoportok jellemzők logikai csoportjai, amelyek jellemzően ugyanabból a jellemzőfolyamatból származnak. An offline áruház nagy mennyiségű előzményadatot tartalmaz, amelyeket modellfejlesztéshez szükséges betanítási és tesztelési adatok létrehozásához vagy modellpontozáshoz kötegelt alkalmazásokhoz használnak. A célja a online áruház is to serve these same features in real time with low latency. Unlike the offline store, which is append-only, the goal of the online store is to serve the most recent feature values. Behind the scenes, Feature Store automatically carries out data synchronization between the two stores. If you ingest new feature values into the online store, they’re automatically appended to the offline store. However, you can also create offline and online s
tores separately if this is a requirement for your team or project.
A következő diagram három funkcionális csapatot ábrázol, amelyek mindegyike saját szolgáltatásfolyamattal rendelkezik, amelyek egy központi szolgáltatástároló jellemzőcsoportjába írnak.
A személyre szabott fiók kezeli a felhasználói munkamenet-adatokat, amelyeket egy ügyfélszolgálati alkalmazásból gyűjtöttek össze, és rendelkezik egy szolgáltatásfolyamattal, amely egy Munkamenetek nevű szolgáltatáscsoportot hoz létre a munkamenetadatokból származó szolgáltatásokkal. Ez a folyamat a generált jellemzőértékeket a központi jellemzőtárolóba írja. Hasonlóképpen, a Product Success fiókban egy funkciófolyamat felelős a Vélemények funkciócsoport funkcióinak létrehozásáért, az Adatkezelési fiók pedig a Felhasználók funkciócsoportban.
A központi szolgáltatástároló fiók tartalmazza a három termelői fióktól kapott összes szolgáltatást, három szolgáltatáscsoportra van leképezve: Munkamenetek, Vélemények és Felhasználók. A szolgáltatásfolyamatok úgy írhatnak a központi szolgáltatástárolóba, hogy felvesznek egy adott IAM-szerepet, amely a központosított tárolófiókban jön létre. A bejegyzés későbbi részében megvitatjuk, hogyan engedélyezhető ez a több fiókra kiterjedő szerepkör. A külső fiókok a központi tár jellemzőcsoportjaiból is lekérdezhetnek funkciókat betanítás vagy következtetés céljából, amint az az előző architektúra diagramon látható. A képzéshez átveheti az IAM-szerepet a központosított áruházból, és több fiókot futtathat Amazon Athéné lekérdezéseket (az ábrán látható módon), vagy kezdeményezzen egy Amazon EMR or SageMaker feldolgozás képzési adatkészletek létrehozása. Valós idejű következtetés esetén az online funkciókat közvetlenül olvashatja ugyanazon a feltételezett IAM-szerepen keresztül, amely a fiókok közötti hozzáféréshez kapcsolódik.
Ebben a modellben a központosított szolgáltatástároló általában egy éles fiókban található. Az ezt az áruházat használó alkalmazások ebben a fiókban vagy más olyan fiókokban élhetnek, amelyek fiókokon keresztül hozzáférnek a központi szolgáltatástárolóhoz. Ezt a teljes struktúrát lemásolhatja alacsonyabb környezetekben, például fejlesztésben vagy kivitelezésben, hogy tesztelje az infrastruktúra-változásokat, mielőtt azokat élesre tereli.
Kombinált funkciók boltja
Ebben a részben a központosított szolgáltatástároló minta egy változatát tárgyaljuk, az úgynevezett kombinált funkció bolt minta. A funkciótervezésben bevett gyakorlat az, hogy a meglévő funkciókat kombinálják új szolgáltatások létrehozása érdekében. Amikor a csapatok kombinálják a központi áruház megosztott funkcióit a saját szolgáltatástárolójuk helyi funkcióival, új, továbbfejlesztett funkciókat állíthatnak elő, amelyek segítségével összetettebb adatmodelleket hozhatnak létre. Az előző részből tudtuk, hogy a központosított áruház segítségével bármely adattudományi csapat könnyen hozzáférhet a külső funkciókhoz, és a meglévő szolgáltatáskészletével együtt használhatja azokat új funkciók kombinálására és fejlesztésére.
A biztonság és a megfelelőség egy másik olyan eset, amikor a csapatok egy csoportspecifikus szolgáltatástárolót tarthatnak fenn, amellett, hogy a központi áruházból hozzáférhetnek a szolgáltatásokhoz. Sok csapatnak speciális hozzáférési jogokra van szüksége, amelyeket nem biztosítanak mindenkinek a szervezetben. Előfordulhat például, hogy nem lehetséges az érzékeny adatokból kinyert funkciók közzététele a szervezeten belüli központi szolgáltatástárolóban.
A következő architektúra diagramban a központosított szolgáltatástároló az a fiók, amely a több szolgáltatásfolyamatból kapott összes szolgáltatást egyetlen központi tárba gyűjti és katalogizálja. Ebben a példában az egyesített áruház fiókja a Core Search csapathoz tartozik. Ez a fiók a központi áruház megosztható funkcióinak fogyasztója. Ezenkívül ez a fiók kezeli a felhasználói kulcsszóadatokat, amelyeket az ügyfeleknek szóló keresőalkalmazásokon keresztül gyűjtöttek össze.
Ez a fiók saját helyi offline és online üzleteket tart fenn. Ezeket a helyi üzleteket egy szolgáltatási folyamat tölti be, amely helyileg be van állítva a felhasználói lekérdezési kulcsszavak adatainak feldolgozására és szolgáltatások létrehozására. Ezek a funkciók a Kulcsszavak nevű szolgáltatáscsoportba vannak csoportosítva. A Feature Store alapértelmezés szerint automatikusan létrehoz egy AWS ragasztó táblázat ehhez a szolgáltatáscsoporthoz, amely a fiók AWS ragasztóadat-katalógusában van regisztrálva. A táblázat metaadatai a szolgáltatáscsoport Amazon S3 helyére mutatnak a fiók offline áruházában.
A kombinált áruházi fiók a Munkamenetek, Vélemények és Felhasználók funkciócsoportokhoz is hozzáférhet a központi áruházból. A fiókok közötti hozzáférést szerepkör szerint engedélyezheti, amit a következő szakaszokban tárgyalunk. Az adattudósok és kutatók az Athena segítségével lekérdezhetik a helyileg létrehozott szolgáltatáscsoportokat, és összekapcsolhatják ezeket a belső funkciókat az adattudományi kísérletek központosított tárából származó külső jellemzőkkel.
Több fiókra kiterjedő hozzáférés áttekintése
Ez a szakasz áttekintést nyújt arról, hogyan lehet engedélyezni a több fiókhoz való hozzáférést a Feature Store számára két fiók között egy feltételezett szerepkör használatával: AWS biztonsági token szolgáltatás (AWS STS). Az AWS STS egy webszolgáltatás, amely lehetővé teszi ideiglenes, korlátozott jogosultságokkal rendelkező hitelesítő adatok kérését az IAM-felhasználók számára. Az AWS STS ideiglenes biztonsági hitelesítő adatokat ad vissza, amelyek segítségével hozzáférhet olyan AWS-erőforrásokhoz, amelyekhez általában nem fér hozzá. Ezek az ideiglenes hitelesítő adatok egy hozzáférési kulcs azonosítójából, titkos hozzáférési kulcsból és biztonsági tokenből állnak.
Ennek a folyamatnak a bemutatásához tegyük fel, hogy két fiókunk van, A és B, amint azt a következő diagram mutatja.
A B fiók központosított online és offline szolgáltatástárolót tart fenn. Az A fiókhoz hozzá kell férni a B fiókban található online és offline üzletekhez. Ennek engedélyezéséhez hozunk létre egy szerepet a B fiókban, és hagyjuk, hogy az A fiók vegye fel ezt a szerepet az AWS STS használatával. Ez lehetővé teszi, hogy az A fiók úgy viselkedjen, mint a B fiók, engedélyekkel a szerep által azonosított konkrét műveletek végrehajtására. AWS szolgáltatások, mint a SageMaker (feldolgozási és betanítási feladatok, végpontok) és AWS Lambda Az A fiókból használt felveheti a B fiókban létrehozott IAM-szerepet egy AWS STS-kliens használatával (lásd a kódblokkot később ebben a bejegyzésben). Ez biztosítja számukra a szükséges engedélyeket az olyan erőforrásokhoz való hozzáféréshez, mint az Amazon S3, az Athena és az AWS Glue Data Catalog a B fiókon belül. Miután az A fiók szolgáltatásai megszerezték a szükséges engedélyeket az erőforrásokhoz, mind az offline, mind az online áruházhoz hozzáférhetnek a fiókban. B. A választott szolgáltatástól függően az adott szolgáltatás IAM-végrehajtási szerepkörét is hozzá kell adnia a B fiók több fiókra kiterjedő IAM-szerepkörének megbízható szabályzatához. Ezt a következő részben tárgyaljuk részletesen.
Az előző architektúra diagram azt mutatja, hogy az A fiók hogyan vesz fel szerepet a B fióktól, hogy olvasson és írjon a B fiókban található online és offline üzletekbe. A diagram hét lépése a következő:
- A B fiók olyan szerepet hoz létre, amelyet mások is átvehetnek (használati esetünkben az A fiók).
- Az A fiók átveszi az IAM-szerepet a B fióktól az AWS STS használatával. Az A fiók mostantól ideiglenes hitelesítő adatokat hozhat létre, amelyek segítségével olyan AWS-szolgáltatási ügyfeleket hozhat létre, amelyek úgy viselkednek, mintha a B fiókon belül lennének.
- In Account A, SageMaker and other service
clients (such as Amazon S3 and Athena) are created using the temporary credentials via the assumed role. - Az A fiók szolgáltatásügyfelei mostantól az AWS SDK használatával funkciócsoportokat hozhatnak létre, és funkcióértékeket tölthetnek fel a B fiók központi online áruházába.
- A B fiókban lévő online áruház automatikusan szinkronizálódik az offline áruházzal, szintén a B fiókban.
- Az A fiókon belüli Athena szolgáltatáskliens több fiókra vonatkozó lekérdezéseket futtat a szolgáltatáskészletek olvasásához, csoportosításához és megvalósításához a B fiókon belüli Athena táblák segítségével. Mivel az offline tároló a B fiókban található, a megfelelő AWS Glue táblák, metaadat katalógusbejegyzések és S3 objektumok mindegyik a B fiókban található. Az A fiók használhatja az AWS STS-t a B fiókon belüli offline szolgáltatások (S3 objektumok) lekérdezésére.
- Az Athena lekérdezés eredményei szolgáltatási adatkészletként kerülnek vissza az A fiók S3 tárolójába.
Az ideiglenes hitelesítési adatok az AWS STS GetSessionToken API-t használják, és 1 órán belül korlátozottak. Használatával meghosszabbíthatja a munkamenet időtartamát RefreshableCredentials, egy Botocore osztály, amely automatikusan frissíti a hitelesítő adatokat, hogy az 1 órás időkereten túl is működjön a régóta futó alkalmazásaival. An példafüzet ennek bemutatása elérhető a GitHub-tárhelyünkön.
Hozzon létre több fiókra kiterjedő hozzáférést
Ez a szakasz részletezi a több fiókra kiterjedő hozzáférési szerepkörök, házirendek és engedélyek létrehozásának lépéseit, amelyek lehetővé teszik a funkciók megosztását az A és B fiók között az architektúránknak megfelelően.
Hozzon létre egy Feature Store hozzáférési szerepet
A B fiókból létrehozunk egy Feature Store hozzáférési szerepet. Ezt a szerepet vállalják az AWS-szolgáltatások az A fiókon belül, hogy hozzáférjenek a B fiók erőforrásaihoz.
- Az IAM-konzol navigációs ablaktáblájában válassza a lehetőséget szerepek.
- A pop-art design, négy időzóna kijelzése egyszerre és méretének arányai azok az érvek, amelyek a NeXtime Time Zones-t kiváló választássá teszik. Válassza a Szerep létrehozása.
- A pop-art design, négy időzóna kijelzése egyszerre és méretének arányai azok az érvek, amelyek a NeXtime Time Zones-t kiváló választássá teszik. Válassza a Egy másik AWS-fiók.
- A felhasználónév, adja meg a B fiók 12 számjegyű számlaazonosítóját.
- A pop-art design, négy időzóna kijelzése egyszerre és méretének arányai azok az érvek, amelyek a NeXtime Time Zones-t kiváló választássá teszik. Válassza a Következő: Engedélyek.
- A Engedélyek szakaszban keresse meg és csatolja a következő AWS felügyelt házirendeket:
AmazonSageMakerFullAccess
(ezt tovább korlátozhatja a legkevesebb jogosultságra a használati esete alapján)AmazonSageMakerFeatureStoreAccess
- Hozzon létre és csatoljon egyéni házirendet ehhez az új szerepkörhöz (adja meg az S3 csoport nevét az A fiókban, amelybe a B fiókban gyűjtött Athena lekérdezési eredményeket írják):
Ha ezt az új, több fiókra kiterjedő AWS STS-szerepet használja az A fiókból, akkor az Athena lekérdezéseket futtathat a B fiók offline áruházi tartalmával szemben. Az egyéni házirend lehetővé teszi az Athena számára (a B fiókon belül), hogy visszaírja az eredményeket a fiókban található eredménygyűjtőbe. V. Az előző szabályzat létrehozása előtt győződjön meg arról, hogy ez az eredménycsoport létrejött az A fiókban.
Alternatív megoldásként megengedheti, hogy a B fiók központi szolgáltatástárolója karbantartsa az összes Athena-lekérdezési eredményt egy S3 tárolóban. Ebben az esetben be kell állítania több fiókra kiterjedő Amazon S3 olvasási hozzáférési házirendeket a külső fiókokhoz a mentett eredmények (S3 objektumok) olvasásához.
- Miután csatolta az irányelveket, válassza a lehetőséget Következő.
- Adjon meg egy nevet ennek a szerepnek (például: cross-account-ssume-role).
- A Összegzésként oldal a létrehozott szerepkörhöz, alatt Bizalmi kapcsolatok, választ A bizalmi kapcsolat szerkesztése.
- Szerkessze a hozzáférés-vezérlési szabályzat dokumentumát a következő kód szerint:
Az előző kód hozzáadja a SageMaker-t és az Athena-t szolgáltatásként a Principal részhez. Ha azt szeretné, hogy több külső fiók vagy szerepkör vegye fel ezt a szerepet, ebben a szakaszban felveheti a megfelelő ARN-eket.
Hozzon létre egy SageMaker jegyzetfüzet példányt
Az A fiókból hozzon létre egy SageMaker jegyzetfüzet-példányt IAM-végrehajtási szerepkörrel. Ez a szerepkör biztosítja az A fiókban lévő SageMaker-jegyzetfüzet számára a szükséges engedélyeket, hogy a B fiókon belüli szolgáltatástárolóban műveleteket futtasson. Ha nem SageMaker-jegyzetfüzetet használ, hanem Lambdát használ, létre kell hoznia egy szerepkört a Lambda számára ugyanazzal a funkcióval. csatolt szabályzatok, amint az ebben a részben látható.
Alapértelmezés szerint a következő házirendek csatolva vannak, amikor új végrehajtási szerepkört hoz létre egy SageMaker jegyzetfüzethez:
AmazonSageMaker-ExecutionPolicy
AmazonSageMakerFullAccess
Létre kell hoznunk és csatolnunk kell két további egyéni szabályzatot. Először hozzon létre egy egyéni házirendet a következő kóddal, amely lehetővé teszi az A fiókban lévő végrehajtási szerepkör számára, hogy végrehajtson bizonyos S3-műveleteket, amelyek a B fiók offline áruházával való interakcióhoz szükségesek:
Az AWS felügyelt házirendjét is csatolhatja AmazonSageMakerFeatureStoreAccess
, ha az offline áruház S3 vödörneve tartalmazza a SageMaker
kulcsszó.
Másodszor, hozza létre a következő egyéni házirendet, amely lehetővé teszi, hogy az A fiókban lévő SageMaker notebook átvegye a szerepet (cross-account-assume-role
) létrehozva a B fiókban:
We know Account A can access the online and offline store in Account B. When Account A assumes the cross-account AWS STS role of Account B, it can run Athena queries inside Account B against its offline store. However, the results of these queries (feature datasets) need to be saved in Account A’s S3 bucket in order to enable model training. Therefore, we need to create a bucket in Account A that can store the Athena query results as well as create a bucket policy (see the following code). This policy allows the cross-account AWS STS role to write and read objects in this
vödör:
Módosítsa a bizalmi kapcsolatok szabályzatát
Mivel létrehoztunk egy IAM-végrehajtási szerepet az A fiókban, ennek a szerepkörnek az ARN-jét használjuk a B fiókban lévő, több fiókra kiterjedő szerepvállalás bizalmi kapcsolati politikájának módosítására:
Érvényesítse a beállítási folyamatot
Miután beállította az összes szerepkört és a kapcsolódó házirendet, ellenőrizheti a beállítást a példajegyzetfüzetek futtatásával a GitHub repo. A következő kódblokk egy kivonat a példajegyzetfüzetből, és az A fiókon belül futó SageMaker jegyzetfüzetben kell futtatni. Bemutatja, hogyan veheti át a több fiókra vonatkozó szerepet B fiókból az AWS STS használatával a AssumeRole API hívás. Ez a hívás ideiglenes hitelesítő adatok készletét adja vissza, amelyeket az A fiók használhat bármilyen szolgáltatási ügyfél létrehozásához. Amikor ezeket az ügyfeleket használja, a kód a feltételezett szerepkör engedélyeit használja, és úgy viselkedik, mintha a B fiókhoz tartozna. További információért lásd: vállal_szerepet az AWS SDK for Python (Boto 3) dokumentációjában.
Miután létrehozta a SageMaker klienseket az előző kódpélda szerint az A fiókban, szolgáltatáscsoportokat hozhat létre, és funkciókat tölthet fel a B fiók központi online és offline áruházába. A szolgáltatáscsoportok létrehozásával, leírásával és törlésével kapcsolatos további információkért lásd: Create_feature_group a Boto3 dokumentációjában. Használhatja a Feature Store futásidejű kliens jellemzőrekordok elhelyezésére és lekérésére jellemzőcsoportokba.
Offline bolti replikáció
A reprodukálhatóság egy ML-modell pontos újraalkotásának képessége, tehát ha ugyanazokat a szolgáltatásokat használja, mint a bemenet, a modell ugyanazt a kimenetet adja vissza, mint az eredeti modell. Lényegében erre törekszünk a kutatási környezetben kifejlesztett és a termelési környezetben alkalmazott modellek között. A szolgáltatástervezési folyamatok fiókok közötti replikálása összetett és időigényes folyamat, amely nem megfelelően implementált modelleltéréseket okozhat. Ha a modell betanításához használt jellemzőkészlet a betanítási fázis után megváltozik, előfordulhat, hogy nehéz vagy lehetetlen a modell reprodukálása.
Az AWS-ben található alkalmazások általában több különálló környezettel és fiókkal rendelkeznek, például fejlesztési, tesztelési, színpadi és gyártási. Az alkalmazás különböző környezetekben történő automatizált telepítéséhez CI/CD-folyamatokat használunk. A szervezeteknek gyakran elszigetelt munkakörnyezeteket és több adatmásolatot kell fenntartaniuk ugyanabban vagy különböző AWS-régióban, vagy különböző AWS-fiókokban. A Feature Store kontextusában előfordulhat, hogy egyes vállalatok az offline szolgáltatástároló adatait szeretnék replikálni. Offline bolti replikáció ezen keresztül Amazon S3 replikáció hasznos minta lehet ebben az esetben. Ez a minta lehetővé teszi az elszigetelt környezetek és fiókok számára, hogy a teljes szolgáltatáskészlettel újratanítsák az ML-modelleket, több fiókra kiterjedő szerepkörök vagy engedélyek használata nélkül.
Következtetés
Ebben a bejegyzésben különféle architektúramintákat mutattunk be, például a központosított szolgáltatástárolót, a kombinált szolgáltatástárolót és a SageMaker Feature Store egyéb tervezési szempontjait, amelyek elengedhetetlenek a többfunkciós adattudományi együttműködéshez. Megmutattuk azt is, hogyan állíthat be több fiókhoz való hozzáférést az AWS STS használatával.
Ha többet szeretne megtudni a Feature Store képességeiről és használati eseteiről, lásd: Az Amazon SageMaker Feature Store legfontosabb képességeinek megismerése és a Az Amazon SageMaker Feature Store streaming feldolgozása az ML-alapú döntések meghozatalához közel valós időben.
Ha bármilyen észrevétele vagy kérdése van, kérjük, tegye meg a megjegyzés rovatban.
A szerzőkről
Arunprasath Shankar a mesterséges intelligencia és a gépi tanulás (AI/ML) specialistája az AWS-vel, segít a globális ügyfeleknek mesterséges intelligencia-megoldásaik hatékony és eredményes felhőben történő méretezésében. Szabadidejében Arun szívesen néz sci-fi filmeket és hallgat klasszikus zenét.
Mark Roy az AWS fő gépi tanulási építésze, aki segít az AWS ügyfeleknek AI/ML megoldások tervezésében és kivitelezésében. Mark munkája az ML felhasználási esetek széles skáláját fedi le, elsősorban a számítógépes látás, a mély tanulás és az ML méretezése a vállalaton belül. Számos iparágban segített cégeknek, többek között a biztosítás, a pénzügyi szolgáltatások, a média és a szórakoztatás, az egészségügy, a közművek és a gyártás területén. Mark 6 AWS tanúsítvánnyal rendelkezik, beleértve az ML Specialty Certificationt is. Mielőtt csatlakozott az AWS-hez, Mark több mint 25 éven át építész, fejlesztő és technológiai vezető volt, ebből 19 évig pénzügyi szolgáltatásokkal foglalkozott.
Stefan Natu Sr. AI/ML Specialist Solutions Architect az Amazon Web Servicesnél. Arra összpontosít, hogy segítse a pénzügyi szolgáltatásokat nyújtó ügyfeleit teljes körű gépi tanulási megoldások kidolgozásában az AWS-en. Szabadidejében szívesen olvas gépi tanulási blogokat, gitározik és felfedezi a New York-i ételvilágot.
- gázpedál
- hozzáférés
- Fiók
- Akció
- További
- Örökbefogadás
- AI
- AI elfogadása
- amazon
- Amazon SageMaker
- Az Amazon Web Services
- között
- api
- Alkalmazás
- alkalmazások
- építészet
- mesterséges intelligencia
- Mesterséges intelligencia és gépi tanulás
- Automatizált
- AWS
- a színfalak mögött
- blogok
- épít
- Épület
- hívás
- esetek
- Tanúsítvány
- Város
- ügyfél részére
- felhő
- kód
- együttműködés
- Hozzászólások
- Közös
- Companies
- vállalat
- teljesítés
- összetevő
- Összetett
- Számítógépes látás
- fogyaszt
- fogyasztó
- tartalom
- Hitelesítő adatok
- Ügyfelek
- dátum
- adat hozzáférés
- adat-tudomány
- mély tanulás
- Design
- részlet
- Fejleszt
- Fejlesztő
- Fejlesztés
- e-kereskedelem
- Mérnöki
- Mérnökök
- Vállalkozás
- Szórakozás
- Környezet
- végrehajtás
- Funkció
- Jellemzők
- pénzügyi
- pénzügyi szolgáltatások
- vezetéknév
- élelmiszer
- forma
- Tele
- funkció
- GitHub
- Globális
- kormányzás
- támogatások
- Csoport
- egészségügyi
- tart
- Hogyan
- How To
- HTTPS
- IAM
- azonosítani
- Identitás
- Beleértve
- iparágak
- információ
- Infrastruktúra
- biztosítás
- Intelligencia
- kamat
- IT
- Munka
- Állások
- csatlakozik
- tartás
- Kulcs
- tudás
- nagy
- vezet
- TANUL
- tanulás
- Tőkeáttétel
- Korlátozott
- Lista
- Kihallgatás
- helyi
- helyileg
- elhelyezkedés
- gépi tanulás
- vezetés
- gyártási
- jel
- piacára
- Média
- ML
- modell
- Filmek
- zene
- Navigáció
- új funkció
- Új funkciók
- New York
- new york city
- laptopok
- online
- online áruház
- üzemeltetési
- érdekében
- Más
- Egyéb
- Mintás
- Testreszabás
- emelvény
- Politikák
- politika
- medence
- előrejelzés
- Tippek
- termelő
- Termékek
- Termelés
- termelékenység
- program
- közzétesz
- Piton
- világítás
- hatótávolság
- Nyers
- nyers adatok
- Olvasás
- real-time
- miatt
- receptek
- nyilvántartások
- Kapcsolatok
- kutatás
- forrás
- Tudástár
- Eredmények
- Visszatér
- Vélemények
- futás
- futás
- sagemaker
- Skála
- skálázás
- Tudomány
- tudósok
- sdk
- Keresés
- biztonság
- Szolgáltatások
- készlet
- Megosztás
- megosztott
- So
- Megoldások
- nyilatkozat
- tárolni
- árnyékolók
- folyó
- siker
- Támogatott
- Systems
- Technológia
- ideiglenes
- Tesztelés
- idő
- jelképes
- Képzések
- Bízzon
- Felhasználók
- segédprogramok
- látomás
- gyalogos
- háló
- webes szolgáltatások
- belül
- Munka
- művek
- írás
- év