Hogyan gyorsítja fel az Imperva az ML fejlesztést és az együttműködést az Amazon SageMaker notebookokon keresztül

Ez az Imperva, a kiberbiztonsági megoldások szolgáltatója vendégbejegyzése. 

Imperva egy kiberbiztonsági vezető, székhelye Kaliforniában, az Egyesült Államokban található, és küldetése az adatok és a hozzájuk vezető út védelme. Az elmúlt néhány évben azon dolgoztunk, hogy a gépi tanulást (ML) integráljuk termékeinkbe. Ez magában foglalja a rosszindulatú tevékenységek észlelését az adatbázisokban, a biztonsági házirendek automatikus konfigurálását és a biztonsági események értelmes történetekké történő fürtözését.

Miközben az észlelési képességeink fejlesztésére törekszünk, megoldásainkat ML modellekbe fektetjük. Például az Imperva API biztonsági szolgáltatást nyújt. Ennek a szolgáltatásnak az a célja, hogy megvédje az összes API-t a különféle támadásoktól, beleértve azokat a támadásokat is, amelyeket a hagyományos WAF nem tud könnyen megállítani, mint például a OWASP top 10. Ez egy jelentős befektetési terület számunkra, ezért lépéseket tettünk az ML fejlesztési folyamatunk felgyorsítása érdekében annak érdekében, hogy több területet lefedjünk, hatékonyan kutassuk az API-támadásokat, és felgyorsítsuk azon képességünket, hogy értéket biztosítsunk ügyfeleink számára.

Ebben a bejegyzésben megosztjuk, hogyan gyorsítottuk fel az ML fejlesztést és együttműködést Amazon SageMaker notebook.

Jupyter Notebooks: A közös kutatási terület

Az adattudományi kutatási folyamatok új magasságokba emelték a nagy technológiai cégek és a fejlesztő közösség figyelmét. Mostantól minden eddiginél egyszerűbb elindítani egy adatvezérelt projektet a felügyelt ML szolgáltatások segítségével. Remek példa erre az állampolgári adatokkal foglalkozó tudósok térnyerése, amely szerint Gartner olyan „erőteljes felhasználók, akik egyszerű és közepesen kifinomult elemzési feladatokat is el tudnak végezni, amelyek korábban több szakértelmet igényeltek volna”.

Az ML-felhasználók számának várható növekedésével a kísérletek csapatok közötti megosztása a fejlesztési sebesség kritikus paraméterévé válik. A sok közös lépés közül az egyik legfontosabb lépés a projektet elindító adattudósok számára egy új Jupyter notebook kinyitása, és az előttünk álló kihívásba való belemerülés.

A Jupyter notebookok egy IDE és egy dokumentum keresztezése. Egyszerű és interaktív módot biztosít a kutató számára a különböző megközelítések tesztelésére, az eredmények ábrázolására, bemutatására és exportálására, miközben olyan nyelvet és interfészt használ, mint a Python, R, Spark, Bash vagy mások.

Az Amazon SageMaker egy teljesen felügyelt szolgáltatás, amely minden fejlesztőnek és adatkutatónak lehetőséget biztosít az ML felépítésére, betanítására és telepítésére. A SageMaker pontosan ezt a képességet és még sok minden mást is tartalmaz a SageMaker notebook funkciójának részeként.

Bárki, aki megpróbálta egy csapatban használni a Jupyter Notebookokat, valószínűleg elérte azt a pontot, ahol megpróbált egy valaki máséhoz tartozó notebookot használni, de rájött, hogy ez nem olyan egyszerű, mint amilyennek hangzik. Gyakran előfordul, hogy egyszerűen nem fér hozzá a szükséges notebookhoz. Más esetekben a notebookokat helyileg használják a kutatáshoz, így a kód gyakran tele van merevkódolt útvonalakkal, és nem kötődik semmilyen tárolóhoz. Még akkor is, ha a kód valamilyen tárolóba van véglegesítve, (remélhetőleg) a szükséges adatok nincsenek véglegesítve. Összefoglalva, nem könnyű együttműködni a Jupyter Notebooks-szal.

Ebben a bejegyzésben bemutatjuk, hogyan osztjuk meg az adattudományi kutatási kódokat az Impervánál, és hogyan használjuk a SageMaker notebookokat az egyéni követelményeink támogatása és az együttműködés fokozása érdekében hozzáadott további funkciókkal. Azt is megosztjuk velünk, hogy mindezek az erőfeszítések hogyan vezettek a költségek és a háztartási idő jelentős csökkenéséhez. Bár ez az architektúra jól illeszkedik hozzánk, választhat különböző konfigurációkat, például teljes erőforrás-elszigetelést külön fájlrendszerrel minden felhasználó számára.

Hogyan gyorsítottuk fel ML fejlesztésünket

Munkafolyamatunk meglehetősen szabványos, veszünk egy adathalmazt, betöltjük egy Jupyter notebookba, és elkezdjük az adatok feltárását. Miután megfelelően megértettük az adatokat, elkezdünk kísérletezni és különböző algoritmusokat kombinálni, amíg megfelelő kezdeti megoldást nem kapunk. Ha elég jó proof of concept (POC) áll rendelkezésünkre, folytatjuk az eredmények érvényesítését az idő múlásával, kísérletezgetve és menet közben módosítva az algoritmust. Végül, amikor elérjük az önbizalom magas szintjét, szállítjuk a modellt és folytassa az eredmények érvényesítését.

Eleinte ez a folyamat teljesen logikus volt. Voltak olyan kis projektjeink, amelyek nem igényeltek nagy számítási teljesítményt, és elég időnk volt egyedül dolgozni rajtuk, amíg el nem értük a POC-t. A projektek elég egyszerűek voltak ahhoz, hogy magunk telepítsük, kiszolgáljuk és felügyeljük a modellt, vagy más esetekben Docker-tárolóként szállíthassuk a modellt. Amikor a teljesítmény és a méretarány fontos volt, a modell tulajdonjogát egy pszeudokóddal ellátott specifikációs dokumentum segítségével egy fejlesztőcsapatnak adtuk át. De az idők változnak, és ahogy a csapat és a projektek növekedtek és fejlődtek, jobb módra volt szükségünk a dolgok elvégzéséhez. Méreteznünk kellett projektjeinket, amikor hatalmas számítási erőforrásokra volt szükség, és jobb módot kellett találnunk a tulajdonjog átadására unalmas és kiterjedt specifikációs dokumentumok használata nélkül.

Továbbá, amikor mindenki valamilyen távoli virtuális gépet, ill Amazon rugalmas számítási felhő (Amazon EC2) példánya a Jupyter notebookok futtatásához, a projektjeik általában nem tartalmaznak dokumentációt és rendetlenek.

SageMaker notebookok

Jönnek a SageMaker notebookok: az AWS-en üzemeltetett, menedzselt Jupyter Notebooks platform, ahol egyszerűen létrehozhat jegyzetfüzet példányt – egy EC2 (virtuális számítógép) példányt, amely Jupyter Notebooks szervert futtat. Amellett, hogy a notebook már a felhőben van, és mindenhonnan elérhető, könnyedén átméretezheti a notebook példányt, így annyi számítási erőforrást biztosít, amennyire szüksége van.

A korlátlan számítási erőforrások nagyszerűek, de nem ezért döntöttünk úgy, hogy elkezdjük használni a SageMaker notebookokat. Az elérni kívánt célokat három fő pontban foglalhatjuk össze:

• A kutatás megkönnyítése – Könnyű, felhasználóbarát munkakörnyezet létrehozása, amely gyorsan elérhető és megosztható a kutatócsoporton belül.
• Adatok és kódok rendszerezése – A rendetlenség megszüntetése az adatokhoz való hozzáférés megkönnyítésével és a kódmegőrzés strukturált módjának létrehozásával.
• Projektek megvalósítása – A kutatási játszóterek és a termelés szétválasztásának jobb módja, valamint ötleteink jobb megosztása a fejlesztőcsapatokkal anélkül, hogy kiterjedt, unalmas dokumentumokat használnánk.

Könnyebb kutatás

A SageMaker notebookok a felhőben találhatók, így szinte bárhonnan elérhetővé teszik őket. A Jupyter notebook elindítása mindössze néhány percet vesz igénybe, és az előző futtatás összes kimenete elmentésre kerül, így nagyon egyszerű visszaugrani hozzá. Kutatási követelményeink azonban tartalmaztak néhány további szempontot, amelyek megoldást igényeltek:

• Gyorsnézet – A notebookok mindig rendelkezésre állnak, hogy áttekintsék a korábbi futtatások eredményeit. Ha az a példány, ahol a kódot tartja, nem működik, el kell indítania, csak hogy megnézze a kimenetet. Ez frusztráló lehet, különösen akkor, ha drága példányt használ, és csak az eredményeket szeretné megnézni. Ez 5–15 percről 0-ra csökkentette azt az időt, amelyet minden csapattagnak a példány indítására kellett várnia.
• Megosztott nézetek – A többpéldányos jegyzetfüzetek felfedezésének képessége. A SageMaker notebook példányok alapértelmezés szerint dedikált tárhellyel rendelkeznek. Szerettük volna áttörni ezt a falat, és lehetővé akartuk tenni a csapat együttműködését.
• Állandó könyvtárak – A könyvtárakat ideiglenesen a SageMaker jegyzetfüzet példányai tárolják. Módosítani akartuk, hogy csökkentsük az összes szükséges könyvtár teljes telepítéséhez szükséges időt, és 100%-kal lerövidítsük, körülbelül 5 percről 0-ra.
• Költséghatékony szolgáltatás – A költségek optimalizálása a kutatók részvételének minimalizálása mellett. Alapértelmezés szerint a példányok be- és kikapcsolása manuálisan történik. Ez emberi mulasztás miatt szükségtelen költségekhez vezethet.

Az alapértelmezett SageMaker konfiguráció és az általunk keresett szakadék áthidalására mindössze két fő összetevőt használtunk: Amazon elasztikus fájlrendszer (Amazon EFS) és életciklus konfiguráció a SageMakerben. Az első, ahogy a neve is sugallja, egy fájlrendszer, a második pedig alapvetően egy kódrészlet, amely a notebook indításakor vagy első létrehozásakor fut le.

Megosztott és gyors nézetek

Ezt a fájlrendszert az összes notebook-példányunkhoz csatlakoztattuk, így mindegyiknek megosztott fájlrendszere van. Így a kódunkat a notebook példány fájlrendszere helyett az Amazon EFS-be menthetjük, és bármely notebook példányból elérhetjük.

Ez megkönnyítette a dolgunkat, mert mostantól létrehozhatunk egy írásvédett, kicsi, szuperolcsó notebook példányt (ennél a bejegyzésnél nevezzük megtekintő példánynak), amely mindig bekapcsolva marad, és segítségével könnyedén elérheti a kódot és az eredményeket anélkül, hogy elkezdene. a kódot futtató notebook példány. Ezen túlmenően mostantól könnyedén megoszthatjuk egymás között a kódot, mivel azt egy megosztott helyen tároljuk, ahelyett, hogy több különböző notebook példányban tárolnák.

Tehát valójában hogyan lehet fájlrendszert csatlakoztatni egy notebook példányhoz?

Létrehoztunk egy életciklus-konfigurációt, amely az EFS-t egy notebook-példányhoz köti, és ezt a konfigurációt csatoltuk minden notebook-példányhoz, amelyet a megosztott környezet részévé akartunk tenni.

Ebben a részben végigvezetjük az általunk írt életciklus-konfigurációs szkripten, vagy hogy pontosabbak legyünk, szemérmetlenül elloptuk az AWS által szolgáltatott példákat, és összekevertük őket.

A következő szkript előtag szabványos minta:

#!/bin/bash
set -e

Most csatlakoztatjuk a notebookot egy EFS-hez, és győződjön meg róla, hogy ismeri az EFS-példány nevét:

EFS_NAME=EFS_INSTANCE_NAME.efs.REGION.amazonaws.com
mkdir -p /home/ec2-user/SageMaker/efs
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport $EFS_NAME:/ /home/ec2-user/SageMaker/efs
sudo chmod go+rw /home/ec2-user/SageMaker/efs

Kitartó és költséghatékony szolgáltatás

Miután csatlakoztattuk a fájlrendszert, elkezdtünk gondolkodni a notebookokkal való együttműködésről. Mivel az AWS a példány minden futási órájáért díjat számít fel, úgy döntöttünk, hogy jó gyakorlat lenne automatikusan leállítani a SageMaker notebookot, ha az egy ideig tétlen. Kezdetben 1 órás alapértelmezett értékkel kezdtük, de a példány címkéivel a felhasználók a SageMaker grafikus felhasználói felületéről bármilyen, számukra megfelelő értéket beállíthattak. Az alapértelmezett 1 órás konfiguráció alkalmazása a következőképpen határozható meg globális életciklus-konfiguráció, és ezt felülírva úgy definiálható helyi életciklus konfiguráció. Ez a házirend hatékonyan megakadályozta, hogy a kutatók véletlenül elhagyják a nem használt példányokat, így a SageMaker példányok költsége 25%-kal csökkent.

# get instance tags location
NOTEBOOK_ARN=$(jq '.ResourceArn' /opt/ml/metadata/resource-metadata.json --raw-output) # extract idle time parameter value from tags list
IDLE_TIME=$(aws sagemaker list-tags --resource-arn $NOTEBOOK_ARN | jq '.Tags[] | select(.Key=="idle") | .Value') # in case idle time not specified set to one hour (3600 sec) [[ -z "$IDLE_TIME" ]] && IDLE_TIME=3600 # fetch the auto stop script from AWS samples repo
wget https://raw.githubusercontent.com/aws-samples/amazon-sagemaker-notebook-instance-lifecycle-config-samples/master/scripts/auto-stop-idle/autostop.py # starting the SageMaker autostop script in cron
(crontab -l 2>/dev/null; echo "*/5 * * * * /usr/bin/python $PWD/autostop.py --time $IDLE_TIME --ignore-connections") | crontab - sudo -u ec2-user -i <<'EOF'
unset SUDO_UID

Így most a notebook csatlakozik az Amazon EFS-hez, és tétlenség esetén automatikusan leáll. Ez azonban egy másik problémát vetett fel – alapértelmezés szerint a SageMaker jegyzetfüzetpéldányokban lévő Python-könyvtárak az átmeneti tárolóba vannak telepítve, ami azt jelenti, hogy a példány leállításakor törlődnek, és a példány következő indításakor újra kell telepíteni őket. Ez azt jelenti, hogy naponta legalább egyszer újra kell telepítenünk a könyvtárakat, ami nem a legjobb élmény, és csomagonként néhány másodperctől néhány percig tarthat. Úgy döntöttünk, hogy hozzáadunk egy szkriptet, amely megváltoztatja ezt a viselkedést, és az összes könyvtártelepítést állandóvá teszi azáltal, hogy megváltoztatja a Python könyvtár telepítési útvonalát a notebook példány tárhelyére (Amazon Elastic Block Store), hatékonyan kiküszöböli a csomagok újratelepítésével elvesztegetett időt.

Ez a szkript minden alkalommal lefut, amikor a notebook példány elindul, telepíti a minicondát és néhány alapvető Python könyvtárat a perzisztens tárolóban, és aktiválja a minicondát:

# use an address within the notebook instance’s file system
WORKING_DIR=/home/ec2-user/SageMaker/custom-miniconda
# if this is the first time the lifecycle config is running - install miniconda
if [ ! -d "$WORKING_DIR" ]; then mkdir -p "$WORKING_DIR" # download miniconda wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O "$WORKING_DIR/miniconda.sh" # install miniconda bash "$WORKING_DIR/miniconda.sh" -b -u -p "$WORKING_DIR/miniconda" # delete miniconda installer rm -rf "$WORKING_DIR/miniconda.sh" # create a custom conda environment source "$WORKING_DIR/miniconda/bin/activate" KERNEL_NAME="custom_python" PYTHON="3.9" conda create --yes --name "$KERNEL_NAME" python="$PYTHON" conda activate "$KERNEL_NAME" pip install --quiet ipykernel conda install --yes numpy pip install --quiet boto3 pandas matplotlib sklearn dill EOF
fi
# activate miniconda
source "$WORKING_DIR/miniconda/bin/activate"
for env in $WORKING_DIR/miniconda/envs/*; do BASENAME=$(basename "$env") source activate "$BASENAME" python -m ipykernel install --user --name "$BASENAME" --display-name "Custom ($BASENAME)"
Done # disable SageMaker-provided Conda functionality, leaving in only what we've installed
echo "c.EnvironmentKernelSpecManager.use_conda_directly = False" >> /home/ec2-user/.jupyter/jupyter_notebook_config.py
rm /home/ec2-user/.condarc
EOF

Gyors újraindítás és kész!

# restart the Jupyter server
restart jupyter-server

Adat- és kódszervezés

Emlékszel az EFS-re, amiről az imént beszéltünk? Többekért itt van.

Miután az összes kódunkat ugyanazon a helyen tároltuk, úgy gondoltuk, jobb egy kicsit rendszerezni.

Úgy döntöttünk, hogy minden csapattagnak létre kell hoznia saját jegyzetfüzet-példányát, amelyet csak ők használnak. A példány fájlrendszere helyett azonban Amazon EFS-t használunk, és a következő hierarchiát valósítjuk meg:

---Csapat tagja

—————-Projekt

--------kód

-----------erőforrások

Így mindannyian könnyen hozzáférhetünk egymás kódjához, de még mindig tudjuk, hogy mi kié.

De mi a helyzet a befejezett projektekkel? Úgy döntöttünk, hogy hozzáadunk egy további ágat a teljes körűen dokumentált és leszállított projektekhez:

---Csapat tagja

—————-Projekt

--------kód

-----------erőforrások

——–Befejezett projektek

—————-Projekt

--------kód

-----------erőforrások

Tehát most, hogy a kódunk szépen van rendszerezve, hogyan férhetünk hozzá az adatainkhoz?

Adatainkat tároljuk Amazon egyszerű tárolási szolgáltatás (Amazon S3), és ezen keresztül érheti el Amazon Athéné. Ez nagyon megkönnyítette az Athena és az Amazon S3 hozzáférési engedéllyel rendelkező notebook példányaink szerepének beállítását. Így egyszerűen néhány sornyi kód használatával, és anélkül, hogy a hitelesítő adatokkal vacakolnánk, egyszerűen lekérdezhetjük az Athénát, és lekérhetjük az adatokat a munkához.

Ezen felül létrehoztunk egy dedikált hálózatot Amazon Virtual Private Cloud (Amazon VPC), amely hozzáférést biztosított a notebook példányoknak a belső Git-tárhelyünkhöz és a privát PyPI-tárhelyünkhöz. Ez megkönnyítette a hasznos belső kódok és csomagok elérését. A következő ábra azt mutatja be, hogyan néz ki mindez a notebook-platformunkon.

Kézbesítés

Végül, hogyan használhatjuk fel ezeket a notebookokat a projektek egyszerű megvalósítására?

A Jupyter notebookok egyik nagyszerűsége, hogy a kód írása és a kimenet megjelenítése mellett egyszerűen hozzáadhat szöveget és címsorokat, ezáltal interaktív dokumentumot hozhat létre.

A következő néhány sorban leírjuk szállítási folyamatainkat, amikor átadjuk a modellt egy fejlesztői csapatnak, és amikor magunk telepítjük a modellt.

Azoknál a projekteknél, ahol a méretarány, a teljesítmény és a megbízhatóság kiemelt fontosságú, átadjuk a modellt, hogy egy fejlesztői csapat írja át újra. Miután elértük a kiforrott POC-t, megosztjuk a notebookot a projekthez rendelt fejlesztőkkel a korábban említett írásvédett notebook példány segítségével.

A fejlesztők mostantól elolvashatják a dokumentumot, láthatják az egyes kódblokkok bemeneti és kimeneti adatait, és jobban megérthetik, hogyan működik és miért, ami megkönnyíti számukra a megvalósítást. Régebben az ilyen típusú esetekre specifikációs dokumentumot kellett írnunk, ami alapvetően azt jelenti, hogy a kódot pszeudo kódra írjuk át, sok megjegyzéssel és magyarázattal. Most egyszerűen integrálhatjuk megjegyzéseinket és magyarázatainkat a SageMaker jegyzetfüzetbe, amely sok munkanapot takarított meg minden egyes projektnél.

Azoknál a projekteknél, amelyeknél nincs szükség fejlesztői csapatra a kód átírására, átszervezzük a kódot egy Docker-tárolóban, és egy Kubernetes-fürtben helyezzük üzembe. Bár nehézségnek tűnhet a kód átalakítása notebookból Dockerizált, szabványos Python-projektgé, ennek a folyamatnak megvannak a maga előnyei:

• Magyarázatosság és láthatóság – Ahelyett, hogy elmagyarázná, mit csinál az algoritmusa a zűrös projektben, egyszerűen használhatja azt a notebookot, amelyen a kutatási szakaszban dolgozott.
• Cél szerinti szétválasztás – A kutatási kód a notebookban, a gyártási kód pedig a Python projektben van. Folytathatja a kutatást anélkül, hogy hozzáérne a gyártási kódhoz, és csak akkor frissítheti, ha már áttörést ért el.
• Hibakeresés – Ha a modellje hibába ütközik, könnyen hibakeresést végezhet a notebookban.

Mi a következő lépés

A Jupyter notebookok nagyszerű játszóteret biztosítanak az adatkutatóknak. Kisebb méretben nagyon kényelmes a helyi gépen való használata. Ha azonban nagyobb csapatokban kezd el dolgozni nagyobb projekteken, számos előnnyel jár a felügyelt Jupyter Notebooks szerverre való átállás. A SageMaker notebookok nagyszerűsége az, hogy testreszabhatja a notebook példányait, például a példányméretet, a kódmegosztást és az automatizálási szkripteket, a kernelválasztást és még sok mást, amivel rengeteg időt és pénzt takaríthat meg.

Egyszerűen fogalmazva, olyan folyamatot hoztunk létre, amely felgyorsítja az ML fejlesztést és az együttműködést, miközben legalább 25%-kal csökkenti a SageMaker notebookok költségeit, és csökkenti a kutatók által a telepítéssel és a munkavégzésre való várakozással töltött többletidőt.

Jelenlegi SageMaker notebook környezetünk a következőket tartalmazza:

• Felügyelt Jupyter notebook példányok
• Különálló, testreszabható számítási példányok minden felhasználó számára
• Megosztott fájlrendszer a projektek szervezésére és a kód egyszerű megosztására a többiekkel
• Életciklus-konfigurációk, amelyek csökkentik a költségeket és megkönnyítik a munkakezdést
• Csatlakozás adatforrásokhoz, kódtárolókhoz és csomagindexekhez

Azt tervezzük, hogy még jobbá tesszük ezt a környezetet néhány további funkció hozzáadásával:

• Költségfigyelés – Költségkeretünk figyelemmel kísérése érdekében minden példányhoz külön címkét adunk, hogy nyomon tudjuk követni a költségeket.
• Automatikus mentési állapot – Létrehozunk egy életciklus-konfigurációt, amely automatikusan elmenti a notebook állapotát, így a felhasználók könnyedén visszaállíthatják a notebook állapotát még a leállítás után is.
• Korlátozott engedélyek rendszere – Szeretnénk lehetővé tenni a különböző csoportokhoz tartozó felhasználók számára, hogy részt vegyenek a kutatásunkban és feltárják adatainkat azáltal, hogy notebook példányokat hozhatnak létre és hozzáférhetnek adatainkhoz, de előre meghatározott korlátozások mellett. Például csak kisméretű, olcsó notebook-példányokat tudnak létrehozni, és csak az adatok egy részét érik el.

Következő lépésként javasoljuk, hogy próbálja ki SageMaker notebookok. További példákért nézze meg a SageMaker példák GitHub repo.

A szerzőkről

Matan Lion az Imperva's Threat Research Group Data Science csoportvezetője. Csapata felelős az adatvezérelt megoldások és a kiberbiztonsági innovációk megvalósításáért a vállalati termékportfólión belül, beleértve az alkalmazás- és adatbiztonsági frontvonalakat, a big data és a gépi tanulás kihasználását.

Johnathan Azaria Data Scientist és tagja az Imperva Research Labsnak, amely a biztonsági elemzésekkel, sebezhetőségek feltárásával és megfelelőségi szakértelemmel foglalkozó vezető kutatószervezet. Az adattudományi szerepkör betöltése előtt Johnathan biztonsági kutató volt, aki hálózati és alkalmazásalapú támadásokra specializálódott. Johnathan tartja a B.Sc és egy M.Sc Bioinformatikából a Bar Ilan Egyetemen.

Yaniv Vaknin az Amazon Web Services gépi tanulási szakértője. Az AWS előtt Yaniv vezető pozíciókat töltött be az AI startupoknál és az Enterprise-nál, beleértve a Dipsee.ai társalapítóját és vezérigazgatóját. A Yaniv együttműködik az AWS-ügyfelekkel, hogy a Machine Learning erejét valós feladatok megoldására és értékteremtésre fordítsa. Szabadidejében Yaniv szívesen focizik a fiaival.

Forrás: https://aws.amazon.com/blogs/machine-learning/how-imperva-expedites-ml-development-and-collaboration-via-amazon-sagemaker-notebooks/