Zgradite in učite modele ML z uporabo arhitekture podatkovne mreže na AWS: 1. del

Organizacije v različnih panogah uporabljajo umetno inteligenco (AI) in strojno učenje (ML) za reševanje poslovnih izzivov, specifičnih za njihovo panogo. Na primer, v industriji finančnih storitev lahko uporabite AI in ML za reševanje izzivov v zvezi z odkrivanjem goljufij, napovedovanjem kreditnega tveganja, neposrednim trženjem in številnimi drugimi.

Velika podjetja včasih ustanovijo center odličnosti (CoE), da se spoprimejo s potrebami različnih poslovnih področij (LoB) z inovativno analitiko in projekti ML.

Za ustvarjanje visokokakovostnih in zmogljivih modelov ML v velikem obsegu morajo narediti naslednje:

• Zagotovite enostaven način za dostop do ustreznih podatkov za njihovo analitiko in ML CoE
• Ustvarite odgovornost za ponudnike podatkov iz posameznih LoBs za skupno rabo kuriranih podatkovnih sredstev, ki so vidna, razumljiva, interoperabilna in vredna zaupanja

To lahko skrajša dolg cikel za pretvorbo primerov uporabe ML iz poskusa v proizvodnjo in ustvari poslovno vrednost v celotni organizaciji.

Arhitektura podatkovne mreže si prizadeva rešiti te tehnične in organizacijske izzive z uvedbo decentraliziranega družbeno-tehničnega pristopa za skupno rabo, dostop in upravljanje podatkov v kompleksnih in obsežnih okoljih – znotraj ali med organizacijami. Oblikovalski vzorec podatkovne mreže ustvarja odgovoren model skupne rabe podatkov, ki je usklajen z organizacijsko rastjo za dosego končnega cilja povečanja donosnosti poslovnih naložb v podatkovne skupine, proces in tehnologijo.

V tej dvodelni seriji nudimo smernice o tem, kako lahko organizacije zgradijo sodobno podatkovno arhitekturo z uporabo vzorca načrtovanja podatkovne mreže na AWS ter omogočijo analitiki in ML CoE, da zgradijo in učijo modele ML s podatki v več LoB-jih. Za določitev konteksta in primera uporabe za to serijo uporabljamo primer organizacije za finančne storitve.

V tej prvi objavi prikazujemo postopke za nastavitev arhitekture podatkovne mreže z več računi proizvajalcev podatkov AWS in potrošnikov. Nato se osredotočimo na en podatkovni izdelek, ki je v lasti enega LoB-ja znotraj finančne organizacije, in kako ga je mogoče deliti v okolje podatkovne mreže, da se drugim LoB-jem omogoči uporaba in uporaba tega podatkovnega izdelka. To je namenjeno predvsem skrbniku podatkov, ki je odgovoren za racionalizacijo in standardizacijo procesa izmenjave podatkov med proizvajalci podatkov in potrošniki ter zagotavljanje skladnosti s pravili upravljanja podatkov.

V drugi objavi prikazujemo en primer, kako lahko analitika in ML CoE porabita podatkovni izdelek za primer uporabe predvidevanja tveganja. To je v glavnem namenjeno osebi podatkovnega znanstvenika, ki je odgovoren za uporabo podatkovnih sredstev na ravni organizacije in tretjih oseb za gradnjo in usposabljanje modelov ML, ki pridobivajo poslovne vpoglede za izboljšanje izkušenj strank finančnih storitev.

Pregled podatkovne mreže

Ustanovitelj vzorca podatkovne mreže, Zhamak Dehghani v svoji knjigi Podatkovna mreža zagotavlja vrednost v velikem obsegu, ki temelji na podatkih, je opredelil štiri načela za cilj podatkovne mreže:

• Lastništvo porazdeljene domene – Prizadevati si za organizacijski premik od centraliziranega lastništva podatkov s strani strokovnjakov, ki upravljajo tehnologije podatkovne platforme, k modelu decentraliziranega lastništva podatkov, s čimer se lastništvo in odgovornost podatkov vrne k LoB-jem, kjer se podatki proizvajajo (domene, usklajene z virom) ali porabljajo ( potrošniško usklajene domene).
• Podatki kot produkt – Navzgor dvigniti odgovornost deljenja kuriranih, visokokakovostnih, interoperabilnih in varnih podatkovnih sredstev. Zato so proizvajalci podatkov iz različnih LoBs odgovorni za izdelavo podatkov v potrošni obliki neposredno pri viru.
• Samopostrežna analitika – Poenostaviti izkušnjo uporabnikov podatkov analitike in strojnega učenja, tako da lahko odkrijejo, dostopajo in uporabljajo podatkovne izdelke s svojimi prednostnimi orodji. Poleg tega za poenostavitev izkušenj ponudnikov podatkov LoB za gradnjo, uvajanje in vzdrževanje podatkovnih izdelkov prek receptov ter komponent in predlog za večkratno uporabo.
• Zvezno računalniško upravljanje – Združiti in avtomatizirati odločanje, ki je vključeno v upravljanje in nadzor dostopa do podatkov, da bo na ravni lastnikov podatkov iz različnih LoBs, kar je še vedno v skladu s širšo pravno politiko, politiko skladnosti in varnostjo organizacije, ki se na koncu izvaja prek mreža.

AWS je predstavil svojo vizijo izgradnje podatkovne mreže na vrhu AWS v različnih objavah:

• Najprej smo se osredotočili na organizacijski del, povezan z lastništvom porazdeljene domene in principi podatkov kot izdelka. Avtorji so opisali vizijo usklajevanja več LOB-jev v organizaciji v smeri strategije podatkovnih izdelkov, ki domenam, usklajenim s potrošnjo, zagotavlja orodja za iskanje in pridobivanje podatkov, ki jih potrebujejo, hkrati pa zagotavlja potreben nadzor nad uporabo teh podatkov z uvedbo odgovornosti za domene, ki so usklajene z izvorom, da zagotovijo podatkovne izdelke, pripravljene za uporabo takoj pri viru. Za več informacij glejte Kako je JPMorgan Chase zgradil podatkovno mrežno arhitekturo za ustvarjanje pomembne vrednosti za izboljšanje podatkovne platforme podjetja.
• Nato smo se osredotočili na tehnični del, povezan z gradnjo podatkovnih izdelkov, samopostrežno analitiko in načeli zveznega računalniškega upravljanja. Avtorji so opisali osnovne storitve AWS, ki domenam, usklajenim z izvorom, omogočajo gradnjo in skupno rabo podatkovnih izdelkov, široko paleto storitev, ki lahko domenam, prilagojenim potrošnikom, omogočijo uporabo podatkovnih izdelkov na različne načine glede na njihova prednostna orodja in primere uporabe, in končno storitve AWS, ki urejajo postopek izmenjave podatkov z uveljavljanjem politik dostopa do podatkov. Za več informacij glejte Oblikujte arhitekturo podatkovne mreže z uporabo AWS Lake Formation in AWS Glue.
• Pokazali smo tudi rešitev za avtomatsko odkrivanje podatkov in nadzor dostopa prek centraliziranega uporabniškega vmesnika podatkovne mreže. Za več podrobnosti glejte Zgradite potek dela za skupno rabo podatkov z AWS Lake Formation za svojo podatkovno mrežo.

Primer uporabe finančnih storitev

Običajno imajo velike organizacije za finančne storitve več LoBs, kot so potrošniško bančništvo, investicijsko bančništvo in upravljanje premoženja, ter tudi eno ali več skupin za analitiko in ML CoE. Vsak LoB ponuja različne storitve:

• LoB za potrošniško bančništvo ponuja različne storitve za potrošnike in podjetja, vključno s krediti in hipoteko, upravljanjem gotovine, plačilnimi rešitvami, depoziti in naložbenimi produkti ter še več.
• Komercialno ali investicijsko bančništvo LoB ponuja celovite finančne rešitve, kot so posojila, tveganje stečaja in veleprodajna plačila strankam, vključno z malimi podjetji, srednje velikimi podjetji in velikimi korporacijami.
• LoB za upravljanje premoženja zagotavlja pokojninske produkte in naložbene storitve v vseh razredih sredstev

Vsak LoB definira lastne podatkovne produkte, ki jih pripravijo ljudje, ki razumejo podatke in so najprimernejši za določitev, kdo je pooblaščen za njihovo uporabo in kako se lahko uporabljajo. V nasprotju s tem so druge LoB in aplikacijske domene, kot sta analitika in ML CoE, zainteresirane za odkrivanje in uporabo kvalificiranih podatkovnih produktov, njihovo mešanje skupaj za ustvarjanje vpogledov in sprejemanje odločitev na podlagi podatkov.

Naslednja ilustracija prikazuje nekaj LoB-jev in primere podatkovnih izdelkov, ki jih lahko delijo. Prikazuje tudi potrošnike podatkovnih izdelkov, kot sta analitika in ML CoE, ki gradijo modele ML, ki jih je mogoče uporabiti v aplikacijah, namenjenih uporabnikom, da še izboljšajo izkušnjo končnih strank.

Po družbeno-tehničnem konceptu podatkovne mreže začnemo z družbenim vidikom z nizom organizacijskih korakov, kot so naslednji:

• Uporaba domenskih strokovnjakov za določitev meja za vsako domeno, tako da je mogoče vsak podatkovni izdelek preslikati v določeno domeno
• Identifikacija lastnikov za podatkovne izdelke, zagotovljene iz vsake domene, tako da ima vsak podatkovni izdelek strategijo, ki jo določi njihov lastnik
• Prepoznavanje politik upravljanja iz globalnih in lokalnih ali zveznih spodbud, tako da se lahko, ko potrošniki podatkov dostopajo do določenega podatkovnega izdelka, politika dostopa, povezana z izdelkom, samodejno uveljavi prek osrednje plasti upravljanja podatkov

Nato preidemo na tehnični vidik, ki vključuje naslednji scenarij od konca do konca, opredeljen v prejšnjem diagramu:

1. Opolnomočite LoB potrošniškega bančništva z orodji za izgradnjo izdelka s podatki o potrošniškem kreditnem profilu, pripravljenega za uporabo.
2. Omogočite LoB potrošniškega bančništva, da deli podatkovne izdelke s plastjo centralnega upravljanja.
3. Vdelajte globalne in zvezne definicije politik dostopa do podatkov, ki jih je treba uveljavljati med dostopanjem do izdelka s podatki o potrošniškem kreditnem profilu prek centralnega upravljanja podatkov.
4. Omogočite analitiki in ML CoE, da odkrijejo in dostopajo do podatkovnega izdelka prek osrednje ravni upravljanja.
5. Opolnomočite analitiko in ML CoE z orodji za uporabo podatkovnega izdelka za izdelavo in usposabljanje modela napovedi kreditnega tveganja. V tej seriji ne pokrivamo zadnjih korakov (6 in 7 v prejšnjem diagramu). Da bi prikazali poslovno vrednost, ki jo lahko tak model ML prinese organizaciji v scenariju od konca do konca, ponazarjamo naslednje:
6. Ta model bi lahko kasneje uporabili nazaj v sisteme, usmerjene v stranke, kot je spletni portal za potrošniško bančništvo ali mobilna aplikacija.
7. Uporablja se lahko posebej v vlogi za posojilo za oceno profila tveganja zahtevkov za kredit in hipoteko.

Nato opišemo tehnične potrebe vsake od komponent.

Poglobite se v tehnične potrebe

Da bi bile podatkovne produkte na voljo vsem, morajo organizacije poenostaviti izmenjavo podatkov med različnimi entitetami v organizaciji, hkrati pa ohraniti ustrezen nadzor nad njimi, ali z drugimi besedami, uravnotežiti agilnost z ustreznim upravljanjem.

Porabnik podatkov: Analytics in ML CoE

Potrošniki podatkov, kot so podatkovni znanstveniki iz analitike in ML CoE, morajo biti sposobni narediti naslednje:

• Odkrijte in dostopajte do ustreznih naborov podatkov za določen primer uporabe
• Bodite prepričani, da so nabori podatkov, do katerih želijo dostopati, že kurirani, posodobljeni in imajo zanesljive opise
• Zahtevajte dostop do naborov podatkov, ki jih zanimajo njihovi poslovni primeri
• Uporabite njihova prednostna orodja za poizvedovanje in obdelavo takšnih naborov podatkov v njihovem okolju za ML brez potrebe po podvajanju podatkov z izvirne oddaljene lokacije ali skrbi zaradi inženirskih ali infrastrukturnih zapletenosti, povezanih z obdelavo podatkov, ki so fizično shranjeni na oddaljenem mestu.
• Bodite obveščeni o morebitnih posodobitvah podatkov s strani lastnikov podatkov

Proizvajalec podatkov: Lastništvo domene

Proizvajalci podatkov, kot so domenske ekipe iz različnih LoB-jev v organizaciji finančnih storitev, se morajo registrirati in deliti izbrane nabore podatkov, ki vsebujejo naslednje:

• Tehnični in operativni metapodatki, kot so imena in velikosti baze podatkov in tabel, sheme stolpcev in ključi
• Poslovni metapodatki, kot so opis podatkov, klasifikacija in občutljivost
• Sledenje metapodatkom, kot je razvoj sheme od vira do ciljne oblike in vseh vmesnih oblik
• Metapodatki o kakovosti podatkov, kot so razmerja pravilnosti in popolnosti ter pristranskost podatkov
• Politike in postopki dostopa

Ti so potrebni, da uporabnikom podatkov omogočijo odkrivanje podatkov in dostop do njih, ne da bi se zanašali na ročne postopke ali se morali obrniti na strokovnjake za področje podatkovnega izdelka, da bi pridobili več znanja o pomenu podatkov in o tem, kako je mogoče dostopati do njih.

Upravljanje podatkov: odkrivanje, dostopnost in možnost revizije

Organizacije morajo uravnotežiti agilnosti, prikazane prej, z ustreznim zmanjševanjem tveganj, povezanih z uhajanjem podatkov. Zlasti v reguliranih panogah, kot so finančne storitve, obstaja potreba po vzdrževanju centralnega upravljanja podatkov, da se zagotovi splošen dostop do podatkov in revizijski nadzor, hkrati pa se zmanjša odtis shranjevanja z izogibanjem večkratnim kopijam istih podatkov na različnih lokacijah.

V tradicionalnih centraliziranih arhitekturah podatkovnih jezer proizvajalci podatkov pogosto objavljajo neobdelane podatke in prenašajo odgovornost za urejanje podatkov, upravljanje kakovosti podatkov in nadzor dostopa na inženirje podatkov in infrastrukture v ekipi centralizirane podatkovne platforme. Vendar pa so te ekipe podatkovne platforme morda manj seznanjene z različnimi podatkovnimi domenami in se še vedno zanašajo na podporo proizvajalcev podatkov, da lahko ustrezno pripravijo in upravljajo dostop do podatkov v skladu s politikami, uveljavljenimi v vsaki podatkovni domeni. V nasprotju s tem so proizvajalci podatkov sami v najboljšem položaju, da zagotovijo izbrana, kvalificirana podatkovna sredstva in se zavedajo domensko specifičnih politik dostopa, ki jih je treba uveljaviti pri dostopanju do podatkovnih sredstev.

Pregled rešitev

Naslednji diagram prikazuje visokonivojsko arhitekturo predlagane rešitve.

Obravnavamo porabo podatkov s strani analitike in ML CoE Amazonska Atena in Amazon SageMaker in del 2 te serije.

V tem prispevku se osredotočamo na proces vkrcanja podatkov v podatkovno mrežo in opisujemo, kako lahko posamezen LoB, kot je podatkovna skupina za potrošniško bančno domeno, uporablja orodja AWS, kot je AWS lepilo in AWS lepilo DataBrew za pripravo, negovanje in izboljšanje kakovosti njihovih podatkovnih izdelkov ter nato registracijo teh podatkovnih izdelkov v osrednji račun za upravljanje podatkov prek Oblikovanje jezera AWS.

LoB za potrošniško bančništvo (proizvajalec podatkov)

Eno od temeljnih načel podatkovne mreže je koncept podatkov kot izdelka. Zelo pomembno je, da podatkovna skupina za domeno potrošniškega bančništva dela na pripravi podatkovnih izdelkov, ki so pripravljeni za uporabo s strani uporabnikov podatkov. To lahko storite z uporabo orodij AWS za ekstrahiranje, preoblikovanje in nalaganje (ETL), kot je AWS Glue, za obdelavo neobdelanih podatkov, zbranih na Preprosta storitev shranjevanja Amazon (Amazon S3) ali pa se povežite s shrambami operativnih podatkov, kjer so podatki proizvedeni. Uporabite lahko tudi DataBrew, ki je orodje za vizualno pripravo podatkov brez kode, ki olajša čiščenje in normalizacijo podatkov.

Na primer, med pripravo izdelka s podatki o potrošniškem kreditnem profilu lahko skupina za podatke o domeni potrošniškega bančništva naredi preprosto kuracijo za prevajanje imen atributov neobdelanih podatkov, pridobljenih iz odprtokodnega nabora podatkov, iz nemščine v angleščino. Nemški kreditni podatki Statlog, ki je sestavljen iz 20 atributov in 1,000 vrstic.

Upravljanje podatkov

Osrednja storitev AWS za omogočanje upravljanja podatkovne mreže je Lake Formation. Lake Formation ponuja možnost uveljavljanja upravljanja podatkov znotraj vsake podatkovne domene in med domenami, da se zagotovi, da so podatki enostavno odkriti in varni. Zagotavlja zvezni varnostni model, ki ga je mogoče upravljati centralno, z najboljšimi praksami za odkrivanje podatkov, varnost in skladnost, hkrati pa omogoča visoko agilnost znotraj vsake domene.

Lake Formation ponuja API za poenostavitev vnosa, shranjevanja in upravljanja podatkov, skupaj z varnostjo na ravni vrstice za zaščito vaših podatkov. Zagotavlja tudi funkcionalnost, kot so razdrobljen nadzor dostopa, nadzorovane tabele in optimizacija shranjevanja.

Poleg tega Lake Formations ponuja a API za skupno rabo podatkov ki jih lahko uporabite za skupno rabo podatkov prek različnih računov. To omogoča uporabniku analitike in ML CoE izvajanje poizvedb Athena, ki poizvedujejo in združujejo tabele v več računih. Za več informacij glejte Vodnik za razvijalce AWS Lake Formation.

Upravitelj dostopa do virov AWS (AWS RAM) zagotavlja varen način za skupno rabo virov prek Upravitelj identitet in dostopa AWS (IAM) in uporabnike v računih AWS znotraj organizacije ali organizacijskih enot (OU) v Organizacije AWS.

Lake Formation skupaj z AWS RAM zagotavlja en način za upravljanje skupne rabe podatkov in dostopa med računi AWS. Ta pristop imenujemo Nadzor dostopa na osnovi RAM-a. Za več podrobnosti o tem pristopu glejte Zgradite potek dela za skupno rabo podatkov z AWS Lake Formation za svojo podatkovno mrežo.

Lake Formation ponuja tudi drug način za upravljanje skupne rabe podatkov in dostopa do njih Oznake Lake Formation. Ta pristop imenujemo nadzor dostopa na podlagi oznak. Za več podrobnosti glejte Zgradite sodobno podatkovno arhitekturo in vzorec podatkovne mreže v velikem obsegu z uporabo nadzora dostopa na podlagi oznak AWS Lake Formation.

V tej objavi uporabljamo pristop nadzora dostopa na podlagi oznak, ker poenostavlja ustvarjanje pravilnikov o manjšem številu logičnih oznak, ki jih običajno najdemo v različnih LoB-jih, namesto določanja pravilnikov o imenovanih virih na ravni infrastrukture.

Predpogoji

Za nastavitev arhitekture podatkovne mreže potrebujete vsaj tri račune AWS: račun proizvajalca, osrednji račun in račun potrošnika.

Razmestite okolje podatkovne mreže

Če želite razmestiti okolje podatkovne mreže, lahko uporabite naslednje GitHub repozitorij. To skladišče vsebuje tri Oblikovanje oblaka AWS predloge, ki uvajajo okolje podatkovne mreže, ki vključuje vsakega od računov (proizvajalec, centrala in potrošnik). Znotraj vsakega računa lahko zaženete ustrezno predlogo CloudFormation.

Centralni račun

V osrednjem računu izvedite naslednje korake:

1. Zaženite sklad CloudFormation:
   
2. Ustvarite dva uporabnika IAM:
   1. DataMeshOwner
   2. ProducerSteward
3. Grant DataMeshOwner kot skrbnik Lake Formation.
4. Ustvarite eno vlogo IAM:
   1. LFRegisterLocationServiceRole
5. Ustvarite dva pravilnika IAM:
   1. ProducerStewardPolicy
   2. S3DataLakePolicy
6. Ustvarite zbirko podatkov kreditne kartice za ProducerSteward na račun proizvajalca.
7. Delite dovoljenje za lokacijo podatkov z računom proizvajalca.

Račun proizvajalca

V računu proizvajalca izvedite naslednje korake:

1. Zaženite sklad CloudFormation:
   
2. Ustvarite vedro S3 credit-card, ki drži mizo credit_card.
3. Dovolite dostop do vedra S3 za vlogo storitve Lake Formation osrednjega računa.
4. Ustvarite pajka AWS Glue creditCrawler-<ProducerAccountID>.
5. Ustvarite vlogo storitve pajka AWS Glue.
6. Podeli dovoljenja za lokacijo vedra S3 credit-card-<ProducerAccountID>-<aws-region> v vlogo pajka AWS Glue.
7. Ustvarite uporabnika IAM skrbnika producenta.

Potrošniški račun

V potrošniškem računu izvedite naslednje korake:

1. Zaženite sklad CloudFormation:
   
2. Ustvarite vedro S3 <AWS Account ID>-<aws-region>-athena-logs.
3. Ustvarite delovno skupino Athena consumer-workgroup.
4. Ustvarite uporabnika IAM ConsumerAdmin.

Dodajte bazo podatkov in nanjo naročite račun potrošnika

Ko zaženete predloge, lahko pregledate korak po korak dodati izdelek v podatkovni katalog in potrošnika naročiti nanj. Priročnik se začne z vzpostavitvijo baze podatkov, kamor lahko proizvajalec postavi svoje izdelke, nato pa razloži, kako se lahko potrošnik naroči na to bazo podatkov in dostopa do podatkov. Vse to se izvaja med uporabo LF-oznake, kar je nadzor dostopa na podlagi oznak za nastanek jezera.

Registracija podatkovnega izdelka

Naslednja arhitektura opisuje podrobne korake, kako lahko skupina LoB za potrošniško bančništvo, ki deluje kot proizvajalec podatkov, registrira svoje podatkovne izdelke v osrednjem računu za upravljanje podatkov (vgrajeni podatkovni izdelki v podatkovno mrežo organizacije).

Splošni koraki za registracijo podatkovnega izdelka so naslednji:

1. Ustvarite ciljno zbirko podatkov za podatkovni izdelek v računu osrednjega upravljanja. Na primer, predloga CloudFormation iz osrednjega računa že ustvari ciljno bazo podatkov credit-card.
2. Delite ustvarjeno ciljno zbirko podatkov z izvorom v računu proizvajalca.
3. Ustvarite povezavo do vira baze podatkov v skupni rabi v računu proizvajalca. Na naslednjem posnetku zaslona na konzoli Lake Formation v računu proizvajalca vidimo, da rl_credit-card je povezava do vira credit-card baze podatkov.
   
4. Izpolnite tabele (s podatki, kuriranimi v računu proizvajalca) v zbirki podatkov povezav virov (rl_credit-card) z uporabo pajka AWS Glue v računu proizvajalca.
   

Ustvarjena tabela se samodejno prikaže v računu centralnega upravljanja. Naslednji posnetek zaslona prikazuje primer tabele v Lake Formation v osrednjem računu. To je po izvedbi prejšnjih korakov za zapolnitev baze podatkov povezav virov rl_credit-card na računu proizvajalca.

zaključek

V 1. delu te serije smo razpravljali o ciljih organizacij za finančne storitve, da bi dosegle večjo agilnost za svoje ekipe za analitiko in strojno upravljanje ter skrajšale čas od podatkov do vpogledov. Osredotočili smo se tudi na izgradnjo podatkovne mrežne arhitekture na AWS, kjer smo predstavili enostavne za uporabo, razširljive in stroškovno učinkovite storitve AWS, kot so AWS Glue, DataBrew in Lake Formation. Ekipe za proizvodnjo podatkov lahko uporabljajo te storitve za izdelavo in skupno rabo izbranih, visokokakovostnih, interoperabilnih in varnih podatkovnih izdelkov, ki so pripravljeni za uporabo s strani različnih uporabnikov podatkov za analitične namene.

In del 2, se osredotočamo na ekipe za analitiko in ML CoE, ki uporabljajo podatkovne izdelke, ki jih deli LoB potrošniškega bančništva, da bi zgradili model napovedi kreditnega tveganja z uporabo storitev AWS, kot sta Athena in SageMaker.

---

O avtorjih

Karim Hammouda je specializirani arhitekt rešitev za analitiko pri AWS s strastjo do integracije podatkov, analize podatkov in poslovne inteligence. Sodeluje s strankami AWS pri načrtovanju in izgradnji analitičnih rešitev, ki prispevajo k rasti njihovega poslovanja. V prostem času rad gleda televizijske dokumentarce in s sinom igra videoigrice.

Hasan Poonawala je višji arhitekt za rešitve AI/ML pri AWS, Hasan strankam pomaga pri načrtovanju in uvajanju aplikacij za strojno učenje v produkciji na AWS. Ima več kot 12 let delovnih izkušenj kot podatkovni znanstvenik, praktik strojnega učenja in razvijalec programske opreme. V prostem času Hasan rad raziskuje naravo in preživlja čas s prijatelji in družino.

Benoit de Patoul je specialist za rešitve AI/ML pri AWS. Strankam pomaga z zagotavljanjem navodil in tehnične pomoči za izdelavo rešitev, povezanih z AI/ML, z uporabo AWS. V prostem času rad igra klavir in se druži s prijatelji.