Ezt a blogbejegyzést Jonathan Lee, Nelson Leung, Paul Min és Troy Squillaci közösen írták az Inteltől.
In rész 1 A bejegyzésben megvitattuk, hogyan működött együtt az Intel®3DAT AWS gépi tanulási professzionális szolgáltatások (MLPS) egy méretezhető AI SaaS alkalmazás létrehozásához. A 3DAT számítógépes látást és mesterséges intelligenciát használ a szabványos videó több mint 1,000 biomechanikai adatpontjának felismerésére, nyomon követésére és elemzésére. Lehetővé teszi az ügyfelek számára, hogy gazdag és hatékony biomechanika által vezérelt termékeket hozzanak létre, például webes és mobilalkalmazásokat részletes teljesítményadatokkal és háromdimenziós vizualizációkkal.
A bejegyzés 2. részében mélyebbre merülünk az építészet egyes szakaszaiban. Feltérképezzük a 3DAT tervezési követelmények teljesítéséhez használt AWS szolgáltatásokat, beleértve Amazon Kinesis adatfolyamok és a Amazon Elastic Kubernetes szolgáltatás (Amazon EKS), annak érdekében, hogy skálázhatóan telepítse a szükséges pózbecslési modelleket ehhez a szoftverhez, mint szolgáltatáshoz (SaaS).
Építészeti áttekintés
Az MLPS csapatának elsődleges célja a 2D és 3D pózbecslési modellek gyártási folyamata volt, és egy funkcionális és méretezhető alkalmazás létrehozása volt. A következő ábra a megoldás architektúráját mutatja be.
A teljes architektúra öt fő összetevőre oszlik:
- Felhasználói alkalmazási felület rétegei
- adatbázis
- Munkafolyamat hangszerelése
- Skálázható pózbecslési következtetés generálása
- Működési felügyelet
Nézzük meg részletesen az egyes összetevőket, azok kölcsönhatásait és a tervezési döntések mögött meghúzódó indokokat.
Felhasználói alkalmazási felület rétegei
Az alábbi diagram azokat az alkalmazásfelületi rétegeket mutatja be, amelyek felhasználói hozzáférést biztosítanak az alkalmazáshoz és az erőforrásokhoz, illetve vezérelhetik azokat.
Ezek a hozzáférési pontok különböző használati eseteket támogatnak a különböző ügyfélszemélyek alapján. Például az alkalmazás felhasználója beküldhet egy munkát a CLI-n keresztül, míg a fejlesztő a Python SDK használatával építhet alkalmazást, és beágyazhat a pózbecslési intelligenciát az alkalmazásaiba. A CLI és az SDK moduláris komponensként épül fel – mindkét réteg az API réteg burkolója, amely a Amazon API átjáró az API-hívások megoldásához és kapcsolódó AWS Lambda függvények, amelyek gondoskodnak az egyes API-hívásokhoz társított háttérlogikáról. Ezek a rétegek döntő fontosságúak voltak az Intel OTG csapata számára, mivel széleskörű ügyfeleket nyitnak meg, akik hatékonyan használhatják ezt a SaaS-alkalmazást.
API réteg
A megoldás kilenc API-ból álló alapkészlettel rendelkezik, amelyek megfelelnek az ezen a platformon működő objektumok típusainak. Minden API-hoz tartozik egy Python-fájl, amely meghatározza a futtatható API-műveleteket. Az új objektumok létrehozásához szekvenciálisan automatikusan hozzárendel egy objektumazonosítót. Ezen objektumok attribútumait a rendszer tárolja és nyomon követi Amazon Aurora Serverless adatbázis ezt az azonosítót használva. Ezért az API-műveletek olyan függvényekhez kapcsolódnak, amelyek egy központi fájlban vannak definiálva, amely tartalmazza az Aurora adatbázis lekérdezéséhez szükséges háttérlogikát. Ez a háttérlogika a Boto3-at használja Amazon RDS DataService kliens az adatbázis-fürt eléréséhez.
Az egyetlen kivétel a /job
API, amely rendelkezik a create_job
metódus, amely kezeli a videó beküldését egy új feldolgozási feladat létrehozásához. Ez a módszer elindítja a AWS lépésfunkciók munkafolyamat-logika a feladat futtatásához. Áthaladva a job_id
, ez a módszer a Boto3 Step Functions kliens hívni a start_execution
módszer egy meghatározott stateMachineARN
(Amazon erőforrás neve).
A nyolc objektum API a következő táblázatban összefoglalt módszerekkel és hasonló hozzáférési mintával rendelkezik.
Módszer típusa | Funkció neve | Leírás |
GET | list_[object_name]s |
Kijelöli az összes ilyen típusú objektumot az adatbázisból és megjeleníti. |
POST | create_[object] |
Új objektumrekordot szúr be az adatbázisba a szükséges bemenetekkel. |
GET | get_[object] |
Az objektum attribútumait az adatbázisból származó objektumazonosító alapján választja ki, és megjeleníti. |
PUT | update_[object] |
Frissít egy meglévő objektumrekordot a szükséges bemenetekkel. |
DELETE | delete_[object] |
Töröl egy meglévő objektumrekordot az adatbázisból az objektumazonosító alapján. |
A kilenc API részletei a következők:
- / felhasználó – A felhasználó annak a személynek a személyazonossága, aki jogosult arra, hogy munkát küldjön be ehhez az alkalmazáshoz. A felhasználó létrehozásához szükség van egy felhasználónévre, felhasználói e-mail címre és csoportazonosítóra, amelyhez a felhasználó tartozik.
- /felhasználói csoport – A felhasználói csoport a felhasználók gyűjteménye. Minden felhasználói csoport egy projekthez és egy folyamatparaméterkészlethez van hozzárendelve. A különböző szintekhez (az infrastrukturális erőforrások és a folyamatparaméterek tekintetében) a felhasználók felhasználói csoportokba vannak osztva. Minden felhasználó csak egy felhasználói csoporthoz tartozhat. Felhasználói csoport létrehozásához projektazonosítóra, folyamatparaméterkészlet-azonosítóra, felhasználói csoport nevére és felhasználói csoport leírására van szükség. Vegye figyelembe, hogy a felhasználói csoportok eltérnek az AWS-fiókban meghatározott felhasználói szerepköröktől. Ez utóbbi a hozzáférési szerepkörük (például adminisztrátor) alapján különböző szintű hozzáférés biztosítására szolgál.
- /projekt – Egy projektet az infrastrukturális erőforrások különböző csoportjainak csoportosítására használnak. Egy projekt egyetlenhez van társítva
project_cluster_url
(Aurora cluster) a felhasználók, munkák és egyéb metaadatok rögzítésére, aproject_queue_arn
(Kinesis Data Streams ARN) és egy számítási futásidejű környezet (jelenleg Cortex-en keresztül vezérelve), amelyet a képkockakötegek következtetéseinek futtatására vagy a videók utófeldolgozására használnak. Minden felhasználói csoport egy projekthez van társítva, és ez a mechanizmus a különböző rétegek engedélyezése a késleltetés és a számítási teljesítmény tekintetében a különböző felhasználói csoportok számára. A projekt létrehozásához szükség van egy projektnévre, a projektfürt URL-címére és az ARN projektsorra. - /csővezeték – Egy folyamat egyetlen konfigurációhoz van társítva a feldolgozó tárolók sorozatához, amelyek videófeldolgozást végeznek a Cortex által koordinált Amazon EKS következtetésgeneráló fürtben (további részletekért lásd a videófeldolgozási következtetés generálásáról szóló részt). Ez általában három tárolóból áll: előfeldolgozás és dekódolás, objektumészlelés és pózbecslés. Például a dekódolás és az objektumészlelési lépés ugyanaz a 2D és 3D folyamatok esetében, de az utolsó tároló HRNet vagy 3DMPPE használatával történő kicserélése a 2D és 3D feldolgozó folyamatok paraméterkészletét eredményezi. Létrehozhat új konfigurációkat a feldolgozáshoz használható lehetséges folyamatok meghatározásához, és ehhez egy új Python-fájlra van szükség a Cortex repo-ban, amely részletezi a folyamatot meghatározó modellvégpont-hívások sorrendjét (lásd a videófeldolgozási következtetések generálásáról szóló részt ). A folyamat végpontja a Cortex végpont, amelyet egyetlen keret feldolgozására hívnak meg. A folyamat létrehozásához meg kell adni a folyamat nevét, leírását és a folyamat végpontját.
- /pipeline_parameter_set – A folyamatparaméterkészlet több paraméter rugalmas JSON-gyűjteménye (folyamatkonfigurációs futási környezet) egy adott folyamathoz, és rugalmasságot biztosít a jövőbeni testreszabáshoz, ha több folyamatkonfigurációs futási időre van szükség. Felhasználói csoportok társíthatók egy adott folyamatparaméterkészlethez, és célja, hogy felhasználói csoportonként és folyamatonként különböző paramétercsoportok legyenek. Ez egy fontos előremutató kiegészítés volt az Intel OTG számára a testreszabás beépítésében, amely támogatja a hordozhatóságot, amikor a különböző ügyfelek, különösen az ISV-k elkezdik használni az alkalmazást.
- /pipeline_parameters – A folyamatparaméterek egyetlen gyűjteménye egy folyamatparaméter-készlet példányosítása. Ez a folyamat 1:sok leképezését teszi a folyamat paramétereihez. Ennek az API-nak egy folyamatazonosítóra van szüksége a folyamatparaméter-készlethez társításához, amely lehetővé teszi egy folyamat létrehozását a folyamat paramétereinek a folyamathoz való 1:1-es leképezéséhez. Az API által megkövetelt többi bemenet a folyamat paraméterkészletének azonosítója, a folyamatparaméterek értéke és a folyamatparaméterek neve.
- /videó – A videoobjektum a munka során beküldött .zip-csomagot alkotó egyedi videók meghatározására szolgál. Ez a fájl a beküldést követően több videóra oszlik. Egy videó kapcsolódik a
job_id
arra a munkára, ahol a .zip csomagot benyújtják, és Amazon egyszerű tárolási szolgáltatás (Amazon S3) útvonalak a nyers elkülönített videók helyéhez és az egyes videók utófeldolgozási eredményeihez. A videoobjektum tartalmaz egy videó előrehaladási százalékot is, amely következetesen frissül az adott videó egyes képkockakötegeinek feldolgozása során, valamint egy videó állapotjelzőt, hogy kész vagy nem kész. A videó létrehozásához szükség van a munkaazonosítóra, a videó elérési útjára, a videó eredmények elérési útjára, a videó előrehaladási százalékára és a videó állapotára. - /frame_batch - A
frame_batch
Az objektum egyetlen videó mintavételével létrehozott képkockák mini kötegje. A videó normál méretű képkockakötegekre történő felosztása egy kar a késleltetés hangolásához, valamint növeli a párhuzamosítást és az átviteli sebességet. Ez az a szemcsés egység, amely a Kinesis adatfolyamokon keresztül fut le következtetések levonására. A kockaköteg létrehozásához videoazonosítóra, keretköteg kezdőszámára, keretköteg végszámára, képkockaköteg-beviteli útvonalra, keretköteg eredményének elérési útjára és keretköteg állapotára van szükség. - /munka – Ezt az interakciós API-t a feldolgozási feladat elindításához szükséges fájlküldéshez használják. Ennek az API-nak a funkciója eltér a többi objektum API-tól, mivel ez a közvetlen elérési út a videófeldolgozási háttérrendszer Step Functions munkafolyamat-koordinációjával és az Amazon EKS-fürttel. Ehhez az API-hoz felhasználói azonosítóra, projektazonosítóra, folyamatazonosítóra, folyamatparaméterkészlet-azonosítóra, feladatparaméterekre és feladatállapotra van szükség. A feladat paramétereiben egy bemeneti fájl elérési útja van megadva, amely az Amazon S3-ban az a hely, ahol a feldolgozandó videók .zip csomagja található. A fájlfeltöltést a
upload_handler
metódus, amely egy előre megjelölt S3 URL-t generál a felhasználó számára, hogy elhelyezhessen egy fájlt. A WORKFLOW_STATEMACHINE_ARN egy környezeti változó, amely a következőhöz kerül átadásracreate_job
API annak meghatározásához, hogy a bemeneti fájl elérési úttal rendelkező .zip videó csomag hova kerüljön elküldésre a feladat elindításához.
Az alábbi táblázat összefoglalja az API funkcióit.
Módszer típusa | Funkció | Leírás |
GET | list_jobs |
Kiválasztja az összes feladatot az adatbázisból, és megjeleníti. |
POST | create_ job |
Új jobrekordot szúr be felhasználói azonosítóval, projektazonosítóval, folyamatazonosítóval, folyamatparaméterkészlet-azonosítóval, a joberedmények elérési útjával, a feladatparaméterekkel és a job állapotával. |
GET | get_ job |
Kiválasztja a job attribútumait a jobazonosító alapján az adatbázisból, és megjeleníti azokat. |
GET | upload_handler |
Előre megjelölt S3 URL-t generál a .zip fájl feltöltésének helyeként. S3 vödörnevet igényel, és alkalmazás/zip fájltípust vár. |
Python SDK réteg
Az API-kra építve a csapat egy Python SDK-kliens-könyvtárat hozott létre burkolóként, hogy megkönnyítse a fejlesztők számára az API-metódusok elérését. Nyílt forráskódot használtak Költészet, amely a Python-csomagolást és a függőségkezelést kezeli. Létrehozták a client.py
fájl, amely az egyes API-kat a Python használatával burkoló függvényeket tartalmaz requests
könyvtár az API kérések és kivételek kezelésére.
Ahhoz, hogy a fejlesztők elindíthassák az Intel 3DAT SDK-t, telepíteniük és össze kell építeniük a Poetry csomagot. Ezután hozzáadhatnak egy egyszerű Python-importálást intel_3dat_sdk
bármely Python kódhoz.
Az ügyfél használatához létrehozhat egy példányt az ügyfélből, megadva az API-végpontot:
Ezután a kliens segítségével meghívhatja az egyes metódusokat, például a create_pipeline
metódust (lásd a következő kódot), figyelembe véve a megfelelő argumentumokat, például a folyamat nevét és leírását.
CLI réteg
Hasonlóképpen, a csapat az API-kra épített, hogy létrehozzon egy parancssori felületet azoknak a felhasználóknak, akik egy egyszerű felületen szeretnék elérni az API metódusokat anélkül, hogy Python-kódot kellene írniuk. A nyílt forráskódú Python csomagot használták Kattints (Command Line Interface Creation Kit). Ennek a keretrendszernek az előnyei közé tartozik a parancsok tetszőleges egymásba ágyazása, az automatikus súgóoldal generálás, valamint az alparancsok futás közbeni lusta betöltésének támogatása. Ugyanabban a client.py
fájl, mint az SDK-ban, minden SDK-ügyfélmetódus a Click használatával lett becsomagolva, és a szükséges metódusargumentumok parancssori jelzőkké lettek konvertálva. A jelzőbemenetek ezután az SDK parancs meghívásakor használatosak.
A CLI elindításához használhatja a CLI configure
parancs. A rendszer kéri a végpont URL-címét:
Most már használhatja a CLI-t az API metódusokhoz kapcsolódó különböző parancsok meghívására, például:
adatbázis
Adatbázisként ez az alkalmazás az Aurora Serverless-t használja az egyes API-khoz társított metaadatok tárolására, amelyekben a MYSQL adatbázis-motorként működik. Az Aurora Serverless adatbázis-szolgáltatás választása betartja a tervezési elvet, hogy minimálisra csökkentse az infrastrukturális többletköltséget azáltal, hogy lehetőség szerint kiszolgáló nélküli AWS-szolgáltatásokat használ. A következő diagram ezt az architektúrát szemlélteti.
A szerver nélküli motor mód megfelel az időszakos használati mintának, mivel ez az alkalmazás új ügyfelekre bővül, és a munkaterhelés még bizonytalan. Adatbázis-végpont indításakor nincs szükség adott DB-példányméretre, csak a fürt kapacitásának minimális és maximális tartományára. Az Aurora Serverless kezeli az útválasztó flotta megfelelő kiépítését, és elosztja a munkaterhelést az erőforrások között. Az Aurora Serverless automatikusan végrehajtja a biztonsági mentések megőrzését legalább 1 napig, de legfeljebb 35 napig. A csapat úgy optimalizálta a biztonságot, hogy az alapértelmezett 35-ös maximális értéket állította be.
Emellett a csapat használta a Data API az Aurora Serverless fürthöz való hozzáférés kezeléséhez, amely nem igényel állandó kapcsolatot, ehelyett biztonságos HTTP-végpontot és AWS SDK-kkal való integrációt biztosít. Ez a funkció használja AWS Secrets Manager az adatbázis hitelesítő adatainak tárolására, így nincs szükség a hitelesítő adatok kifejezett átadására. A CREATE TABLE parancsfájlokat .sql fájlokban írták mind a kilenc táblához, amelyek megfelelnek a kilenc API-nak. Mivel ez az adatbázis tartalmazta a rendszer összes metaadatát és objektumainak állapotát, az API metódusok a megfelelő SQL parancsokkal futottak (pl. select * from Job
az list_jobs
API) és átadták a execute_statement
módszert az Amazon RDS klienstől a Data API-ban.
Munkafolyamat hangszerelése
Az alkalmazás funkcionális gerincét a Step Functions segítségével kezelték a munkafolyamat koordinálására, amint az a következő ábrán látható.
Az állapotgép négy lambda-függvény sorozatából állt, amelyek akkor indulnak el, amikor egy feladatot elküldenek a create_job
módszer a job
API. A felhasználói azonosító, a projekt azonosítója, a folyamat azonosítója, a folyamatparaméterkészlet azonosítója, a joberedmények elérési útja, a job paraméterei és a job állapota szükséges a job létrehozásához. Először feltöltheti a videofájlok .zip csomagját a upload_handler
metódust a job API-ból egy előre aláírt S3 URL generálásához. A feladat elküldése során a bemeneti fájl elérési útja a feladat paraméterein keresztül kerül átadásra a fájl helyének meghatározásához. Ez elindítja a munkafolyamat állapotgépének futtatását, négy fő lépést indítva el:
- Inicializáló lambda funkció
- Submitter Lambda függvény
- Befejezés Ellenőrizze a lambda funkciót
- Kollektor lambda funkció
Inicializáló lambda funkció
Az Initializer fő funkciója, hogy a .zip csomagot különálló videofájlokra bontsa, és előkészítse a beküldő számára. Először a .zip fájlt tölti le, majd minden egyes fájlt, beleértve a videofájlokat is, kicsomagolja és kicsomagolja. A videók, lehetőleg .mp4 formátumban, visszakerülnek egy S3 vödörbe. Használni a create_video
módszer a video
API, egy videó objektum jön létre a videó elérési útjával. Ezzel az egyes videók adatait beszúrja az Aurora adatbázisba. Minden más fájltípus, például a JSON-fájlok metaadatnak minősül, és hasonlóan feltöltésre kerül, de nem jön létre videoobjektum. A kibontott fájlok és videofájlok nevének listája átkerül a következő lépéshez.
Submitter Lambda függvény
A Submitter funkció az inicializáló által kibontott videofájlokat veszi fel, és képként mini-köteges videókockákat hoz létre. A legtöbb jelenleg gyártott számítógépes látásmodell képre lett kiképezve, így még a videó feldolgozása során is először képkockákra osztják őket, mielőtt a modellre következtetnének. Ez a korszerű pózbecslési modellt használó jelenlegi megoldás nem különbözik egymástól – a Beküldőből származó keretkötegek átadódnak a Kinesis Data Streamsnek, hogy elindítsák a következtetés generálási lépést.
Először a videofájlt tölti le a Lambda funkció. A képkockasebességet és a képkockák számát a program segítségével számítja ki FileVideoStream
modul a imutils.video
feldolgozó könyvtár. A keretek kibontása és csoportosítása meghatározott mini kötegméret szerint történik, ami ennek a folyamatnak az egyik legfontosabb hangolható paramétere. A Python savanyúság-könyvtár használatával az adatok sorba rendeződnek, és feltöltődnek az Amazon S3-ba. Ezt követően létrejön egy frame batch objektum, és létrejön a metaadat bejegyzés az Aurora adatbázisban. Ezt a Lambda-függvényt egy Dockerfile segítségével építettük fel, függőséggel opencv-python
, numpy
és imutils
könyvtárak.
Befejezés Ellenőrizze a lambda funkciót
A Befejezés ellenőrzése funkció továbbra is lekérdezi az Aurora adatbázist, hogy az aktuális feladathoz tartozó .zip csomagban lévő egyes videóknál lássa, hány képkocka köteg van BEFEJEZETT állapotban. Ha az összes videóhoz tartozó keretköteg elkészült, az ellenőrzési folyamat befejeződött.
Kollektor lambda funkció
A Gyűjtő funkció a fogyasztói szakaszban az egyes képkockákon végrehajtott következtetések kimeneteit veszi, és egyesíti őket egy képkockakötegben és egy videóban. A kombinált egyesített adatok ezután feltöltésre kerülnek egy S3 tárolóba. A függvény ezután meghívja a Cortex utófeldolgozási API-t egy adott ML-folyamathoz, hogy elvégezzen bármilyen utófeldolgozási számítást, és az összesített eredményeket videón keresztül hozzáadja a kimeneti tárolóhoz. E mérőszámok nagy része képkockákon keresztül történik, például a sebesség, a gyorsulás és a csatlakozási szög, ezért ezt a számítást az összesített adatokon kell elvégezni. A fő kimenetek közé tartoznak a törzs kulcspontjai (CSV formátumba összesítve), a BMA-számítások (például a gyorsulás) és a kulcspontok vizuális átfedése a képfájl egyes képkockáihoz.
Skálázható pózbecslési következtetés generálása
Ebben a szakaszban történik meg az ML-következtetés skálázásához szükséges feldolgozómotor. Három fő elemet tartalmaz, amelyek mindegyike saját párhuzamossági karokkal rendelkezik, amelyek a késleltetési kompromisszumokhoz hangolhatók (lásd a következő diagramot).
Ez az architektúra lehetővé teszi a kísérletezést a késleltetési időnövekedés tesztelésében, valamint rugalmasságot biztosít a jövőre nézve, amikor a munkaterhelések változhatnak az alkalmazást elérő végfelhasználói szegmensek különböző keverékei miatt.
Kinesis adatfolyamok
A csapat azért választotta a Kinesis Data Streams-et, mert jellemzően adatfolyamok kezelésére használják, és ebben az esetben jól illeszkedik, mert a skálázhatóság és párhuzamosítás érdekében hasonló módon képes kezelni a keretkötegeket. A Submitter Lambda funkcióban a Kinesis Boto3 kliens használatos, a put_record
metódus, amely átadja az egyetlen képkockaköteghez tartozó metaadatokat, például a keretköteg-azonosítót, a keretköteg kezdőkockáját, a keretköteg-záró keretet, a kép alakját, a képkocka-sebességet és a videóazonosítót.
Különféle feladatsor- és Kinesis adatfolyam-konfigurációkat határoztunk meg, hogy beállíthassuk az átviteli szinteket, amelyek a különböző felhasználói csoportok prioritási szintjéhez kapcsolódnak. A feldolgozási teljesítmény különböző szintjeihez való hozzáférés egy ARN projektsor átadásával kapcsolódik, amikor új projektet hoz létre a project
API. Ezután minden felhasználói csoport egy adott projekthez kapcsolódik a felhasználói csoport létrehozása során. Három alapértelmezett adatfolyam-konfiguráció van meghatározva a AWS szerver nélküli alkalmazásmodell (AWS SAM) infrastruktúra sablon:
- Standard
-
JobStreamShardCount
- Prioritás -
PriorityJobStreamShardCount
- Magas prioritás -
HighPriorityJobStreamShardCount
A csapat néhány különböző kart használt az egyes adatfolyamok feldolgozási teljesítményének megkülönböztetésére vagy a rendszer késleltetésének hangolására, amint azt a következő táblázat foglalja össze.
Fogantyú | Leírás | Alapértelmezett érték |
szilánk | A szilánk a Kinesis Data Streamsben natív; ez a feldolgozás alapegysége. Az alapértelmezett érték 1 MB/s, ami másodpercenként 1,000 adatrekordnak felel meg. | 2 |
KinesisBatchSize |
Azon rekordok maximális száma, amelyeket a Kinesis Data Streams egyetlen kötegben kér le a fogyasztói lambda funkció meghívása előtt. | 1 |
KinesisParallelizationFactor |
Az egyes szilánkokból egyidejűleg feldolgozandó kötegek száma. | 1 |
Továbbfejlesztett ventilátor | Azok az adatfogyasztók, akiknél aktiválták a továbbfejlesztett fan-out átvitelt, fogyasztónként dedikált adatátviteli sebességgel rendelkeznek (például az alapértelmezett 1 MB/sec), ahelyett, hogy megosztanák az átviteli sebességet a fogyasztók között. | le |
Fogyasztói lambda funkció
A Kinesis Data Streams szemszögéből az adatfogyasztó egy AWS-szolgáltatás, amely adatokat kér le egy adatfolyam-szilánkról, amikor az adatfolyamban generálódnak. Ez az alkalmazás egy Consumer Lambda függvényt használ, amely akkor kerül meghívásra, amikor üzeneteket küldenek át az adatfolyam-sorokból. Minden fogyasztói funkció egy keretköteget dolgoz fel a következő lépések végrehajtásával. Először szinkron módon hívják meg a Cortex processzor API-t, amely a végpont, amely a modellkövetkeztetési folyamatot üzemelteti (további részletekért lásd az Amazon EKS with Cortex című részt). Az eredményeket az Amazon S3 tárolja, és frissítésre kerül az adatbázis a feldolgozott keretköteg állapotának módosításával Complete
. A hibakezelés be van építve a Cortex API-hívások újrapróbálkozási hurkával történő kezelésére, amely a Cortex-fürtből származó 504-es hibákat kezeli, és az újrapróbálkozások száma 5-re van állítva.
Amazon EKS Cortex-szel az ML következtetéshez
A csapat az Amazon EKS-t, az AWS-ben felügyelt Kubernetes szolgáltatást használta számítási motorként az ML következtetésekhez. A tervezés során úgy döntöttek, hogy az Amazon EKS-t használják az ML-végpontok hosztolására, ami rugalmasságot biztosít a Kubernetes upstream futtatásához, és a fürtök lehetőségével mindketten teljes mértékben az AWS-ben felügyelhetők. AWS Fargate, vagy a helyszíni hardver segítségével Amazon EKS bárhol. Ez az Intel OTG által megkívánt kritikus funkció volt, amely lehetőséget biztosított például arra, hogy az alkalmazást speciális helyszíni hardverhez csatlakoztassa.
A három ML-modell, amelyek a következtetési folyamatok építőkövei voltak, egy egyedi Yolo-modell (objektumérzékeléshez), egy egyéni HRNet-modell (2D-s pózbecsléshez) és egy 3DMPPE-modell (3D-s pózbecsléshez) (lásd az előzőt) ML szakasz további részletekért). Nyílt forráskódot használtak Fakéreg könyvtár az ML következtetési folyamat végpontjainak telepítéséhez és kezeléséhez, valamint az Amazon EKS-fürtök elindításához és telepítéséhez. Ezen modellek mindegyikét Docker-tárolókba csomagolták – a modellfájlokat az Amazon S3, a modellképeket pedig a Amazon Elastic Container Registry (Amazon ECR) – és Cortex Realtime API-ként kerül bevezetésre. A modelltárolók CPU-n és GPU-n futó verzióit azért hozták létre, hogy rugalmasságot biztosítsanak a számítási hardver típusához. A jövőben, ha további modelleket vagy modellfolyamatokat kell hozzáadni, egyszerűen létrehozhatnak további Cortex Realtime API-kat.
Ezután következtetési folyamatokat építettek össze úgy, hogy a Cortex Realtime modell API-kat Cortex Realtime pipeline API-kká szerkesztették. Egyetlen Realtime pipeline API valós idejű modell API-k sorozatának meghívásából állt. A Consumer Lambda funkciók kezelt a pipeline
Az API fekete dobozként, egyetlen API-hívással lekéri a kép végső következtetési kimenetét. Két csővezetéket hoztak létre: egy 2D-s és egy 3D-s csővezetéket.
A 2D-s folyamat egyesíti a dekódolási előfeldolgozási lépést, az objektumészlelést egyéni Yolo-modell segítségével a sportoló helyének meghatározásához és határolókeretek létrehozásához, végül pedig egy egyéni HRNet-modellt a 2D-s kulcspontok létrehozásához a pózbecsléshez.
A 3D-s folyamat egyesíti a dekódolási előfeldolgozási lépést, a tárgyfelismerést egy egyedi Yolo-modell segítségével a sportoló helyének meghatározásához és határolókeretek létrehozásához, végül pedig egy 3DMPPE-modellt a pózbecsléshez szükséges 3D-s kulcspontok létrehozásához.
Miután következtetéseket generált egy köteg kereten, minden folyamat egy külön utófeldolgozási Realtime Cortex végpontot is tartalmaz, amely három fő kimenetet generál:
- Az összesített törzskulcs egyetlen CSV-fájlba irányítja az adatokat
- BMA számítások (például gyorsulás)
- A képfájl egyes képkockáihoz hozzáadott kulcspontok vizuális átfedése
A Collector Lambda függvény elküldi az adott videóhoz társított megfelelő metaadatokat, például a képkockaazonosítókat és a pózbecslési következtetési kimenetek S3 helyeit, a végpontnak, hogy létrehozza ezeket az utófeldolgozási kimeneteket.
A Cortexet úgy tervezték, hogy integrálható legyen az Amazon EKS-sel, és csak egy fürtkonfigurációs fájlra és egy egyszerű parancsra van szüksége a Kubernetes-fürt elindításához:
A teljesítményhangolás másik karja a számítási fürtök példánykonfigurációja volt. Három szintet hoztak létre az M5 és G4dn példányok különböző keverékeivel, amelyeket .yaml fájlként kódoltak olyan specifikációkkal, mint a fürtnév, a régió, valamint a példány konfigurációja és keveréke. Az M5-példányok alacsonyabb költségű CPU-alapúak, a G4dn-példányok pedig magasabb költségű GPU-alapúak, hogy némi költség/teljesítmény kompromisszumot biztosítsanak.
Működési felügyelet
A működési naplózási szabványok fenntartása érdekében az összes Lambda funkció tartalmaz kódot a naplók rögzítésére és feldolgozására Amazon Kinesis Data Firehose. Például minden, a Submitter Lambda függvényből feldolgozott keretköteg naplózásra kerül az időbélyeggel, a művelet nevével és a Lambda függvény válaszának JSON-jával, és mentésre kerül az Amazon S3-ba. A következő diagram az architektúra ezen lépését szemlélteti.
bevetés
A telepítés az AWS SAM segítségével történik, amely egy nyílt forráskódú keretrendszer kiszolgáló nélküli alkalmazások készítésére az AWS-ben. Az AWS SAM lehetővé teszi az infrastruktúra-tervezést, beleértve a funkciókat, API-kat, adatbázisokat és eseményforrás-leképezéseket, hogy kodifikálják és egyszerűen telepíthetők az új AWS-környezetekben. A telepítés során az AWS SAM szintaxisa le lesz fordítva AWS felhőképződés az infrastruktúra kiépítésének kezelésére.
A template.yaml
fájl tartalmazza az infrastruktúra specifikációit, valamint a hangolható paramétereket, például a Kinesis Data Streams késleltetési karokat, amelyeket az előző szakaszokban részleteztünk. A samconfig.toml
A fájl olyan telepítési paramétereket tartalmaz, mint például a verem neve, az S3 vödör neve, ahol az alkalmazásfájlok, például a Lambda funkciókódok tárolódnak, és az erőforrás-címkék a költségek nyomon követéséhez. A teljes sablon felépítéséhez és üzembe helyezéséhez mindössze egy deploy.sh shell szkriptre van szükség az egyszerű parancsokkal:
Felhasználói munkafolyamat
Összefoglalva, az infrastruktúra üzembe helyezése után a következő munkafolyamatot követheti a kezdéshez:
- Hozzon létre egy Intel 3DAT klienst az ügyfélkönyvtár segítségével.
- Használja az API-t a folyamat új példányának létrehozásához, amely megfelel a szükséges feldolgozás típusának, például egy 3D-pozícióbecsléshez.
- Hozzon létre egy új projektpéldányt, amely átadja az ARN fürtöt és az ARN Kinesis várólista.
- Hozzon létre egy új példányt egy folyamatparaméterkészletből.
- Hozzon létre egy új folyamatparaméter-példányt, amely a folyamat paraméterkészletéhez van leképezve.
- Hozzon létre egy új felhasználói csoportot, amely egy projektazonosítóhoz és egy folyamatparaméterkészlet-azonosítóhoz van társítva.
- Hozzon létre egy új felhasználót, amely társítva van a felhasználói csoporthoz.
- Töltsön fel videókat tartalmazó .zip fájlt az Amazon S3-ra a feladat API-ban található feltöltési funkció által generált, előre aláírt S3 URL használatával.
- Küldés a
create_job
API-hívás, a videofájlok helyét meghatározó feladatparaméterekkel. Ezzel elindul a feldolgozási feladat.
Következtetés
Az alkalmazás már él, és készen áll arra, hogy sportolókkal és edzőkkel is teszteljék. Az Intel OTG izgatottan várja, hogy a számítógépes látást használó innovatív pózbecslési technológiát számos felhasználó számára elérhetővé tegye, a fejlesztőktől a sportolókon át a szoftvergyártó partnerekig.
Az AWS csapata szenvedélyesen segíti az olyan ügyfeleket, mint az Intel OTG, hogy felgyorsítsák ML-útjukat, az ML Solutions Lab ötletelési és felfedezési szakaszától az AWS ML ProServe segítségével a keményítési és telepítési szakaszig. Mindannyian szorosan figyelni fogjuk a 2021-es tokiói olimpiát ezen a nyáron, hogy elképzelhessük az ML által a sportban elérhető összes előrelépést.
Kezdje el még ma! Fedezze fel használati esetét az ebben a bejegyzésben említett szolgáltatásokkal és sok más szolgáltatással a webhelyen AWS felügyeleti konzol.
A szerzőkről
Han ember az AWS gépi tanulással és mesterséges intelligenciával foglalkozó felsővezetője, San Diego-ban, Kaliforniában. A Northwestern Egyetemen szerzett mérnöki PhD fokozatot, és több éves vezetési tanácsadói tapasztalattal rendelkezik, aki a gyártás, a pénzügyi szolgáltatások és az energia területén nyújt tanácsot ügyfeleknek. Napjainkban szenvedélyesen dolgozik különféle iparágak vásárlóival, hogy gépi tanulási és mesterséges intelligencia megoldásokat fejlesszen és implementáljon az AWS-en. Szereti követni az NBA-t, és szabadidejében kosárlabdázik.
Iman Kamyabi ML mérnök az AWS professzionális szolgáltatásokkal. Az AWS-ügyfelek széles körével dolgozott együtt annak érdekében, hogy a megismételhető és megbízható ML-folyamatok felállításának legjobb gyakorlatait képviselje.
Jonathan Lee az Intel olimpiai technológiai csoportjának sportteljesítmény-technológiai igazgatója. A gépi tanulás egészségügyi alkalmazását tanulmányozta az UCLA egyetemi hallgatójaként és az Oxfordi Egyetemen végzett diplomamunkája során. Karrierje az egészséget és az emberi teljesítményt szolgáló algoritmusok és érzékelők fejlesztésére összpontosított. Jelenleg ő vezeti az Intel 3D sportolókövetési projektjét.
Nelson Leung az Intel Sports Performance CoE Platform Architect-je, ahol végpontok közötti architektúrát határoz meg a sportolók teljesítményét javító élvonalbeli termékek számára. Ezenkívül ő vezeti ezeknek a gépi tanulási megoldásoknak a megvalósítását, bevezetését és termékesítését a különböző Intel partnerek számára.
Troy Squillaci DecSecOps mérnök az Intelnél, ahol professzionális szoftvermegoldásokat szállít az ügyfeleknek a DevOps legjobb gyakorlatain keresztül. Szívesen integrálja az AI-megoldásokat skálázható platformokba számos területen.
Paul Min az Amazon Web Services (AWS) munkatársa a megoldások építészmérnökeként, ahol a különböző iparági vertikumok ügyfeleit segíti küldetésük előmozdításában és felhőalapú alkalmazásuk felgyorsításában. Korábban az Intelnél szoftvermérnöki gyakornokként dolgozott a 3D Athlete Tracking Cloud SDK fejlesztésében. A munkán kívül Paul szeret golfozni, és hallani lehet énekelni.
- Coinsmart. Európa legjobb Bitcoin- és kriptográfiai tőzsdéje.
- Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. SZABAD HOZZÁFÉRÉS.
- CryptoHawk. Altcoin radar. Ingyenes próbaverzió.
- Forrás: https://aws.amazon.com/blogs/machine-learning/the-intel3d-athlete-tracking-3dat-scalable-architecture-deploys-pose-estimation-models-using-amazon-kinesis-data-streams- és-amazon-ek/
- "
- &
- 000
- 100
- 2021
- 3d
- Rólunk
- gyorsul
- hozzáférés
- hozzáférhető
- Szerint
- Fiók
- át
- Akció
- cselekvések
- mellett
- További
- admin
- Örökbefogadás
- AI
- algoritmus
- Minden termék
- amazon
- Az Amazon Web Services
- között
- api
- API-k
- Alkalmazás
- alkalmazások
- megfelelő
- építészet
- érvek
- kijelölt
- Társult
- sportolók
- attribútumok
- Automatikus
- AWS
- mentés
- Kosárlabda
- előtt
- Előnyök
- BEST
- legjobb gyakorlatok
- Fekete
- Blog
- test
- Doboz
- épít
- Épület
- hívás
- Kapacitás
- ami
- Karrier
- esetek
- központi
- bajnok
- változik
- választás
- ügyfél részére
- felhő
- kód
- gyűjtemény
- gyűjtő
- kombinált
- összetevő
- Kiszámít
- számítógép
- Configuration
- kapcsolat
- szaktanácsadó
- fogyasztó
- Fogyasztók
- Konténer
- Konténerek
- tartalmaz
- tovább
- ellenőrzés
- koordináta
- Mag
- Megfelelő
- teremt
- készítette
- teremt
- létrehozása
- teremtés
- Hitelesítő adatok
- kritikai
- kritikus
- Jelenlegi
- Jelenleg
- szokás
- vevő
- Ügyfelek
- élvonalbeli
- dátum
- adatbázis
- adatbázisok
- nap
- elszánt
- mélyebb
- szállít
- telepíteni
- telepített
- bevetés
- bevet
- Design
- tervezett
- részlet
- részletes
- részletek
- Érzékelés
- Fejleszt
- Fejlesztő
- fejlesztők
- Fejlesztés
- különböző
- különbséget
- közvetlen
- Igazgató
- felfedezés
- kijelzők
- Dokkmunkás
- Nem
- domainek
- le-
- alatt
- könnyen
- Endpoint
- energia
- Motor
- mérnök
- Mérnöki
- Környezet
- esemény
- példa
- izgatott
- létező
- elvárja
- tapasztalat
- feltárása
- Funkció
- Végül
- pénzügyi
- pénzügyi szolgáltatások
- vezetéknév
- megfelelő
- FLOTTA
- Rugalmasság
- rugalmas
- összpontosított
- következik
- következő
- következik
- formátum
- előretekintő
- KERET
- Keretrendszer
- funkció
- funkcionális
- funkcionalitás
- funkciók
- jövő
- generál
- generáló
- generáció
- Giving
- cél
- jó
- GPU
- diplomás
- Csoport
- Csoportok
- fogantyú
- Kezelés
- hardver
- Egészség
- hallott
- segít
- segít
- segít
- itt
- <p></p>
- Hogyan
- HTTPS
- emberi
- Identitás
- kép
- végre
- végrehajtás
- fontos
- tartalmaz
- magában foglalja a
- Beleértve
- egyéni
- iparágak
- ipar
- Infrastruktúra
- újító
- bemenet
- Betétek
- telepíteni
- integrált
- integráció
- Intel
- Intelligencia
- kölcsönhatás
- Felület
- IT
- Munka
- Állások
- utazás
- Kulcs
- labor
- indít
- indítás
- vezetékek
- tanulás
- szint
- könyvtár
- vonal
- Lista
- betöltés
- elhelyezkedés
- helyszínek
- gép
- gépi tanulás
- készült
- fenntartása
- fontos
- KÉSZÍT
- férfi
- kezelése
- sikerült
- vezetés
- gyártási
- térkép
- térképészet
- említett
- mód
- Metrics
- minimum
- Küldetés
- ML
- Mobil
- Mobilalkalmazások
- modell
- modellek
- moduláris
- több
- a legtöbb
- többszörös
- nevek
- NBA
- elengedhetetlen
- igények
- szám
- olympics
- nyit
- működik
- optimalizált
- opció
- érdekében
- Más
- saját
- Oxford
- csomag
- rész
- különös
- különösen
- partnerek
- Múló
- szenvedélyes
- Mintás
- százalék
- teljesítmény
- előadó
- perspektíva
- darab
- emelvény
- Platformok
- játék
- Költészet
- pont
- lehetséges
- hatalom
- erős
- Készít
- előző
- elsődleges
- alapelv
- prioritás
- folyamat
- Folyamatok
- feldolgozás
- Processzor
- gyárt
- Termelés
- Termékek
- szakmai
- program
- ad
- biztosít
- cél
- hatótávolság
- Nyers
- realtime
- elismerik
- rekord
- nyilvántartások
- tekintettel
- megbízható
- kéri
- szükség
- kötelező
- követelmények
- megköveteli,
- forrás
- Tudástár
- válasz
- Eredmények
- futás
- futás
- Biztonság
- San
- skálázhatóság
- skálázható
- Skála
- skálázás
- sdk
- biztonság
- szegmensek
- vagy szerver
- szolgáltatás
- Szolgáltatások
- készlet
- beállítás
- Alak
- megosztás
- Héj
- mutatott
- hasonló
- Hasonlóképpen
- Egyszerű
- Méret
- So
- szoftver
- szoftver mint szolgáltatás
- szoftverfejlesztés
- megoldások
- Megoldások
- néhány
- Valaki
- specializált
- specifikációk
- sebesség
- Sport
- verem
- Színpad
- standard
- szabványok
- kezdet
- kezdődött
- kezdődik
- Állami
- csúcs-
- Állapot
- tárolás
- tárolni
- folyam
- folyó
- benyújtott
- Később
- nyár
- támogatás
- Támogatja
- rendszer
- bevétel
- csapat
- Technológia
- Tesztelés
- ebből adódóan
- Keresztül
- NYAKKENDŐ
- idő
- Ma
- együtt
- tokyo
- vágány
- Csomagkövetés
- típusok
- jellemzően
- UCLA
- egyetemi
- University of Oxford
- kinyit
- Frissítések
- használ
- Felhasználók
- kihasználva
- érték
- fajta
- különféle
- függőlegesek
- videó
- Videók
- látomás
- háló
- webes szolgáltatások
- WHO
- nélkül
- Munka
- dolgozott
- dolgozó
- év