A kiskereskedők és a fogyasztói márkák arra összpontosítanak, hogy megfelelő termékekkel és szolgáltatásokkal rendelkezzenek, amelyeket a fogyasztók a piactéren kívánnak megvásárolni. Az értékesítés maximalizálása során a vásárlási élmény fő részét a termékek (vagy termékek kombinációi) képezik. Az ajánlatok rendelkezésre állása – a leltár – állandó problémát jelent a fogyasztói márkák számára.
A termékleltár, más néven termékváltozat egy összetett probléma, amely az ellátási és logisztikai értékláncra terjed ki. Ebben a cikkben kifejezetten arra a problémára összpontosítunk, hogy optimalizáljuk a termékváltozat-választékot a fogyasztási cikkek szempontjából származó bevétel maximalizálása érdekében
A termékváltozat-optimalizálás rejtvényét algoritmusok fejlesztésével oldhatja meg a következő kérdések megválaszolásához:
- Melyik termékváltozat teljesít a legjobban egy adott piacon vagy áruházban?
- Milyen termékváltozatokat kell kiosztani egy adott piacra vagy áruházba a teljesítményük alapján?
- Mely termékváltozatok teljesítménye alacsony, és ezeket a magasabb teljesítményű termékváltozatok váltják fel?
- Milyen egyéb megállapításokat nyerhetünk a fogyasztói és piaci szegmenseinkről?
Döntéshozatal automatizálása
A fogyasztói márkák hagyományosan a termékváltozat portfóliójában lévő termékváltozatok számának növelésével közelítik meg a fogyasztói kereslet problémáját. A ballonozott termékváltozatok és a verseny számának növekedésével a becslések szerint a bevétel 90 százaléka a termék termékváltozatainak csak 10 százaléka a portfólióban. A bevétel 80 százaléka általában a termékváltozatok 20 százalékából származik. Ez az arány pedig a jövedelmezőség javítására is alkalmas.
A statikus jelentéskészítés hagyományos módszerei előzményadatokat használnak, ami korlátozza az elemzéseket. A legjobb esetben a döntéseket továbbra is manuálisan hozzák meg és hajtják végre. Ez emberi beavatkozást és feldolgozási időt jelent. Az AI és a felhőalapú számítástechnika fejlődésével fejlett elemzések használatával számos választási lehetőséget és előrejelzést biztosíthat. Ez a fajta automatizálás javítja az eredményeket és az ügyfél-ügyfél sebességét.
Termékváltozat-optimalizálás
A termékváltozat-választékmegoldásoknak több millió termékváltozatot kell kezelnie az értékesítési adatok értelmes és részletes összehasonlításokba való szegmentálásával. A megoldás célja, hogy fejlett elemzések használatával maximalizálja az értékesítést minden üzletben vagy üzletben a termékválaszték finomhangolásával. A második cél a készleten kívüli állományok megszüntetése és a választék javítása. A pénzügyi cél az értékesítések 5-10 százalékos növekedése. Ennek érdekében az elemzések lehetővé teszik az alábbiakat:
- Az SKU-portfólió teljesítményének megismerése és az alacsony teljesítményűek kezelése.
- Optimalizálja az SKU-k elosztását a készlethiány csökkentése érdekében.
- Ismerje meg, hogyan támogatják az új termékváltozatok a rövid és hosszú távú stratégiákat.
- Meglévő adatokból ismétlődő, méretezhető és végrehajtható elemzéseket hozhat létre.
Leíró elemzés
A leíró modellek összesítik az adatpontokat, és feltárják a termékértékesítést befolyásoló tényezők közötti kapcsolatokat. Az információk kiegészíthetők néhány külső adatponttal, például a tartózkodási hely, az időjárás és a census adataival. A vizualizációk segítségével a felhasználók az adatok értelmezésével nyerhetnek megállapításokat. Ennek során azonban a megértés csak arra korlátozódik, hogy mi történt az előző értékesítési ciklusban, vagy esetleg arra, hogy mi történik az aktuálisban (attól függően, hogy milyen gyakran frissülnek az adatok).
A hagyományos adattárház- és jelentéskészítési megközelítés ebben az esetben elegendő ahhoz, hogy megértse például, hogy mely termékváltozatok voltak a legjobb és legrosszabb teljesítményt nyújtók egy adott időszakban.
Az alábbi ábrán az előzményértékesítési adatok tipikus jelentése látható. Számos olyan blokkot tartalmaz, amelyek jelölőnégyzetekkel jelölik ki az eredmények szűrésére vonatkozó feltételeket. A központ két sávdiagramot jelenít meg, amelyek az értékesítéseket jelenítik meg az idő függvényében. Az első diagram a heti átlagos értékesítéseket mutatja. A második hét szerint jeleníti meg a mennyiségeket.
Előrejelző elemzés
Az előzményjelentés segít megérteni a történteket. Végső soron előrejelzést szeretnénk kapni arról, hogy mi várható. A múltbeli információk hasznosak lehetnek erre a célra. Azonosíthatjuk például a szezonális trendeket. Ez azonban nem segíthet például egy új termék bevezetésének modellezésében. Ehhez az ügyfél viselkedésének modellezésére kell összpontosítanunk, mert ez a végső tényező, amely meghatározza az értékesítéseket.
A probléma részletes áttekintése: választási modellek
Kezdjük azzal, hogy meghatározzuk, hogy mit keresünk, és milyen adatokkal rendelkezünk:
A választékoptimalizálás azt jelenti, hogy olyan termékek egy részhalmazát találja meg, amely a várt bevételt maximalizálja. Ezt keressük.
A tranzakciós adatokat rendszeresen gyűjtjük pénzügyi célokra.
A szortimentadatok tartalmazhatnak mindent, ami az SKU-kkal kapcsolatos: Íme egy példa arra, hogy mit szeretnénk:
- A termékváltozatok száma
- Termékváltozat leírásai
- Lefoglalt mennyiségek
- Termékváltozat és vásárolt mennyiség
- Események időbélyegei (például vásárlások)
- Termékváltozat ára
- Termékváltozat ára POS-n
- Az összes termékváltozat készletszintje bármikor
Sajnos az ilyen adatok gyűjtése nem olyan megbízható, mint a tranzakciós adatok.
Ebben a cikkben az egyszerűség kedvéért csak a tranzakciós adatokat és a termékváltozat adatait fogjuk figyelembe venni, külső tényezőket nem.
Ennek ellenére vegye figyelembe, hogy az n termékek halmaza esetén 2n lehetséges választék van. Így az optimalizálási probléma számításigényes folyamattá válik. Az összes lehetséges kombináció kiértékelése sok termékkel nem praktikus. A szortimenteket tehát általában kategóriák (például gabonafélék), hely és egyéb feltételek szerint szegmentálják a változók számának csökkentése érdekében. Az optimalizálási modellek megpróbálják a permutációk számát egy működőképes részhalmazra csökkenteni.
A probléma keresztje a fogyasztók viselkedésének hatékony modellezésében van. A tökéletes világban a nekik bemutatott termékek megegyeznek a megvásárolni kívánt termékekkel.
A fogyasztói döntések előrejelzésére használható matematikai modelleket évtizedek során fejlesztettek ki. A modell kiválasztása végső soron meghatározza a legmegfelelőbb megvalósítási technológiát. Ezért összefoglaljuk őket, és megfontoljuk néhány szempontot.
Parametrikus modellek
A parametrikus modellek az ügyfelek viselkedését egy véges paraméterkészlettel rendelkező függvény használatával közelítik meg. A paraméterek készletét úgy becsüljük meg, hogy a legjobban illeszkedjenek a rendelkezésünkre álló adatokhoz. Az egyik legrégebbi és legismertebb a multinomiális logisztikai regresszió (más néven MNL, többosztályos logit vagy softmax regresszió). A besorolási problémák számos lehetséges kimenetének valószínűségének kiszámítására szolgál. Ebben az esetben az MNL használatával kiszámíthatja a következőt:
Annak a valószínűsége, hogy a fogyasztó (c) egy adott időpontban (t) kiválaszt egy elemet (i) az adott kategória elemeinek egy olyan választékban (a) megadva, amely az ügyfél számára ismert segédprogrammal rendelkezik (v).
Azt is feltételezzük, hogy egy elem segédprogramja a funkcióinak függvénye lehet. Külső információk is szerepelhetnek a segédprogram mértékében (például az esernyő hasznosabb, ha esik).
Az MNL-t gyakran használjuk teljesítménytesztként más modellekhez, mivel a paraméterek becslése és az eredmények kiértékelése során hasznosítható. Más szóval, ha rosszabb, mint az MNL, az algoritmus nem használható.
Számos modell származik az MNL-ből, de a jelen tanulmány hatókörén kívül esik ezek megvitatása.
Az R- és Python-programozási nyelvekhez vannak kódtárak. Az R esetében használhatja a glm-et (és származékokat). Python esetén scikit-learn, biogeme és vörösfenyő található. Ezek a kódtárak olyan eszközöket kínálnak, amelyekkel MNL-problémákat határozhatnak meg, és párhuzamos megoldásokat kínálnak a különböző platformokon történő megoldások megtalálásához.
A közelmúltban az MNL-modellek GPU-kon történő implementálását olyan összetett modellek kiszámítására javasolták, amelyek számos olyan paraméterrel rendelkeznek, amelyek egyébként nem lennének követhetők.
A softmax kimeneti réteggel rendelkező neurális hálózatokat hatékonyan használták nagy, többosztályos problémák esetén. Ezek a hálózatok a kimenetek olyan vektorát állítják elő, amely valószínűségeloszlást jelent számos különböző eredmény között. A többi implementációhoz képest lassúak a betanításuk, de számos osztályt és paramétert képesek kezelni.
Nem parametrikus modellek
Népszerűsége ellenére az MNL jelentős feltételezéseket helyez el az emberi viselkedésről, amelyek korlátozhatják a hasznosságát. Különösen azt feltételezi, hogy annak relatív valószínűsége, hogy valaki két lehetőség közül választ, független a készletben később bevezetett további alternatíváktól. Ez a legtöbb esetben nem praktikus.
Ha például az A és a B terméket egyformán szereti, akkor az idő 50%-a helyett egyet fog választani. Vizsgáljuk meg a C terméket a keverékben. Az idő 50%-ában továbbra is választhat A terméket, de most a B termékre 25%, a C termékre pedig 25%-ra osztotta a preferenciáját. A relatív valószínűség megváltozott.
Az MNL-nek és a származékoknak nincs egyszerű módja annak, hogy figyelembe vegyék azokat a helyettesítéseket, amelyek a készlethiány vagy a választék fajtája miatt vannak (vagyis ha nincs világos fogalma, és véletlenszerű elemet választanak a polcon lévők között).
A nem parametrikus modellek úgy vannak kialakítva, hogy figyelembe vegyék a helyettesítéseket, és kevesebb korlátozást szabjanak az ügyfelek viselkedésére.
Bevezetik a rangsorolás fogalmát, ahol a fogyasztók szigorúan előnyben részesítik a termékeket egy választékban. A vásárlási viselkedésük tehát modellelhető úgy, hogy csökkenő sorrendbe rendezi a termékeket.
A választékoptimalizálási probléma a bevétel maximalizálásaként fejezhető ki:
- ri a termék bevételét jelöli i.
- yik 1, ha a terméket választják rangsor k. Ellenkező esetben 0.
- λk annak a valószínűsége, hogy az ügyfél a k rangsor alapján választ.
- xi 1, ha a termék szerepel a választékban. Ellenkező esetben 0.
- K a rangsorok száma.
- n a termékek száma.
Feljegyzés
Korlátozásoktól függően:
- Minden rangsorhoz pontosan 1 választás adható meg.
- A rangsor k, a termék lehet választani csak akkor, ha ez része a szorzat.
- Ha egy termék i szerepel a választékban, egyik kevésbé előnyös lehetőségek rangsor k lehet választani.
- Nincs vásárlás egy lehetőség, és mint ilyen egyik kevésbé előnyös lehetőségek a rangsorban lehet választani.
Egy ilyen megfogalmazásban a probléma vegyes egész szám optimalizálásnak tekinthető.
Vegyük figyelembe, hogy ha vannak n termékek, akkor a lehetséges rangsorok maximális száma, beleértve a választás nélküli lehetőséget is, faktoriális: (n+1)!
A készítmény korlátai lehetővé teszik a lehetséges lehetőségek viszonylag hatékony metszését. Például csak a legkedvezményesebb lehetőség van kiválasztva, és 1 értékre van állítva. A többi 0 értékre van állítva. El lehet képzelni, hogy a megvalósítás méretezhetősége fontos lesz, tekintettel a lehetséges alternatívák számára.
Az adatok fontossága
Korábban már említettük, hogy az értékesítési adatok könnyen elérhetők. Azt szeretnénk használni, hogy tájékoztassuk a választékoptimalizálási modellünket. Különösen a λ valószínűségeloszlást szeretnénk megtalálni.
Az értékesítési pontrendszer értékesítési adatai olyan tranzakciókból állnak, amelyek időbélyegekkel rendelkeznek, valamint olyan termékekből állnak, amelyek az adott időpontban és helyen jelennek meg az ügyfelek számára. Ezekből létrehozhatjuk a tényleges értékesítések vektorát, amelynek vi.m elemei az i. tétel értékesítésének valószínűségét jelentik egy Sm választékban megadott vevőnek
Mátrixot is létrehozhatunk:
A valószínűségeloszlás megkeresése λ mivel az értékesítési adataink egy másik optimalizálási problémát okoznak. Egy λ vektort szeretnénk találni az értékesítési becslési hiba minimalizálásához:
minλ |Λλ - v|
Vegye figyelembe, hogy a számítás regresszióként is kifejezhető, és mint ilyen, olyan modellek is használhatók, mint a több variáts döntési fák.
Megvalósítás részletei
Ahogy az előző megfogalmazásból is kikövetkeztethetjük, az optimalizálási modellek adatvezéreltek és számításigényesek is.
A Microsoft-partnerek, például a Neal Analytics robusztus architektúrákat fejlesztettek ki, hogy megfeleljenek ezeknek a feltételeknek. Lásd a termékváltozatok választékoptimalizálását. Ezeket az architektúrákat fogjuk példaként használni, és néhány szempontot is figyelembe fogunk venni.
- Először is egy robusztus és méretezhető adatfolyamra támaszkodnak a modellek táplálásához, valamint egy robusztus és méretezhető végrehajtási infrastruktúrára a futtatásukhoz.
- Másodszor, az eredményeket egyszerűen használhatják a tervezők egy irányítópulton keresztül.
A 2. ábrán egy példaarchitektúra látható. Négy fő blokkot tartalmaz: rögzítést, folyamatot, modellt és működést. Minden blokk fő folyamatokat tartalmaz. A rögzítés magában foglalja az adatok előfeldolgozását; a folyamat magában foglalja az adattár-adatfüggvényt; a modell tartalmazza a gépi tanulási modell betanítása funkciót; és az üzemeltetés magában foglalja az adattárolási és jelentéskészítési lehetőségeket (például irányítópultokat).
2. ábra: Az SKU-optimalizálás architektúrája, a Neal Analytics jóvoltából
Az adatfolyam
Az architektúra kiemeli az adatfolyam létrehozásának fontosságát a modell betanítása és működése szempontjából is. A folyamat tevékenységeit az Azure Data Factory, egy felügyelt kinyerési, átalakítási és betöltési (ETL) szolgáltatás használatával vezényljük, amely lehetővé teszi az integrációs munkafolyamatok tervezését és futtatását.
Az Azure Data Factory egy felügyelt szolgáltatás, amely olyan összetevőkkel rendelkezik, amelyeket adathalmazokat használó és/vagy előállító tevékenységeknek neveznek.
A tevékenységek feloszthatók a következőre:
- Adatáthelyezés (például másolás forrásról célhelyre)
- Adatátalakítás (például SQL-lekérdezéssel való összesítés vagy tárolt eljárás futtatása)
A tevékenységek csoportjait összekapcsoló munkafolyamatokat a data factory szolgáltatás ütemezheti, figyelheti és felügyelheti. A teljes munkafolyamatot folyamatnak nevezzük.
A rögzítési fázisban a Data Factory másolási tevékenységével különböző forrásokból (helyszíni és felhőbeli) adatokat továbbíthatunk az Azure SQL Data Warehouse-ba. Példák a dokumentációban szereplő műveletekre:
Az alábbi ábra egy folyamat definícióját mutatja be. Három egyenlő méretű blokkból áll egy sorban. Az első kettő egy adatkészlet és egy, nyilakkal összekapcsolt tevékenység, amely az adatfolyamokat jelzi. A harmadik folyamat címkével van ellátva, és az első kettőre mutat a beágyazás jelzésére.
3. ábra: Az Azure Data Factory alapfogalmai
A Neal Analytics-megoldás által használt adatformátumra példa található a Microsoft kereskedelmi piactér oldalán. A megoldás a következő adatkészleteket tartalmazza:
- Értékesítési előzmények adatai az áruház és a termékváltozat egyes kombinációihoz
- Tárolási és fogyasztói rekordok
- Termékváltozat kódjai és leírása
- Termékváltozat-attribútumok, amelyek rögzítik a termékek funkcióit (például méret és anyag). Ezeket jellemzően parametrikus modellekben használják a termékváltozatok megkülönböztetésére.
Ha az adatforrások nem az adott formátumban jelennek meg, a Data Factory számos átalakítási tevékenységet kínál.
A folyamat fázisában az SQL Data Warehouse a fő tárolási motor. Egy ilyen átalakítási tevékenységet sql-alapú tárolt eljárásként fejezhet ki, amely automatikusan meghívható a folyamat részeként. A dokumentáció részletes útmutatást nyújt:
Vegye figyelembe, hogy a Data Factory nem korlátozza az SQL Data Warehouse és az SQL tárolt eljárásait. Valójában számos platformmal integrálható. Használhatja például a Databrickset, és futtathat egy Python-szkriptet az átalakításhoz. Ez azért előnyös, mert a következő modellszakaszban egyetlen platformot használhat a gépi tanulási algoritmusok tárolására, átalakítására és betanítására.
Az ML-algoritmus betanítása
Számos olyan eszköz létezik, amely segíthet a parametrikus és a nem parametrikus modellek implementálásában. A választás a méretezhetőségtől és a teljesítménykövetelményektől függ.
Az Azure Machine Learning Studio kiváló eszköz a prototípus-készítéshez. Egyszerű módot kínál egy betanítási munkafolyamat létrehozására és futtatására kódmoduljaival (R vagy Python) vagy előre definiált ML-összetevőkkel (például többosztályos osztályozókkal és megnövelt döntési fa regresszióval) grafikus környezetben. Emellett megkönnyíti egy betanított modell webszolgáltatásként való közzétételét is további felhasználás céljából, és rest felületet hoz létre Önnek.
Az általa kezelhető adatméret azonban jelenleg 10 GB-ra van korlátozva, és az egyes összetevők számára elérhető magok száma kettőre korlátozódik.
Ha további skálázásra van szüksége, de továbbra is használni szeretné a gyakori gépi tanulási algoritmus (például a többnomiális logisztikai regresszió) gyors, párhuzamos Microsoft-implementációit, érdemes megfontolnia az Azure Adattudomány virtuális gépen futó Microsoft ML Server használatát.
Nagyon nagy adatméretek (TB-k) esetén érdemes olyan platformot választani, ahol a tárolás és a számítási elem a következő lehetőségeket képes:
- Skálázás egymástól függetlenül, a költségek csökkentése érdekében, ha nem a modellek betanítása történik.
- Ossza el a számítást több mag között.
- Futtassa a számítást a tároló közelében az adatáthelyezés korlátozásához.
Az Azure HDInsight és a Databricks is megfelel ezeknek a követelményeknek. Emellett mindkét végrehajtási platform támogatott az Azure Data Factory-szerkesztőben. Viszonylag egyszerű bármelyiket integrálni egy munkafolyamatba.
Az ML Server és a kódtárak a HDInsighton kívül is üzembe helyezhetők, de a platform képességeinek teljes kihasználásához implementálhatja a választott ML-algoritmust a SparkML, a PythonBan található Microsoft ML Spark-kódtárak vagy más speciális lineáris programozási solverek, például a TFoCS, a Spark-LP vagy a SolveDF használatával.
A betanítási folyamat indítása után felmerül a kérdés, hogy a megfelelő pySpark-szkriptet vagy jegyzetfüzetet kell-e beiktatni egy Data Factory-munkafolyamatból. Ez teljes mértékben támogatott a grafikus szerkesztőben. További részletekért lásd : Databricks-jegyzetfüzet futtatása a Databricks Notebook-tevékenységgel az Azure Data Factoryben.
Az alábbi ábrán a Data Factory felhasználói felülete látható az Azure Portalon keresztül elérhető módon. Blokkokat tartalmaz a munkafolyamat különböző folyamataihoz.
4. ábra: Data Factory-folyamat példája Databricks-notebook-tevékenységgel
Vegye figyelembe azt is, hogy a készletoptimalizálási megoldásban az Azure Batch-en keresztül skálázott solverek tárolóalapú implementálását javasoljuk. Az olyan speciális optimalizálási kódtárak, mint a pyomo, lehetővé teszik az optimalizálási probléma kifejezését a Python programozási nyelv használatával, majd olyan független megoldáskezelők meghívásával, mint a bonmin (nyílt forráskód) vagy a gurobi (kereskedelmi) megoldás.
A készletoptimalizálás dokumentációja egy másik problémával (rendelési mennyiségekkel) foglalkozik, mint a választékoptimalizálással, de a megoldási feladatok végrehajtása az Azure-ban is hasonlóan alkalmazható.
Bár összetettebb, mint eddig javasolt, ez a technika lehetővé teszi a maximális méretezhetőséget, főleg a magok száma korlátozza, amit megengedhet magának.
A modell futtatása (üzembe)
A modell betanítása után a futtatás általában más infrastruktúrát igényel, mint az üzembe helyezéshez használt. A könnyen használhatóság érdekében rest felülettel rendelkező webszolgáltatásként is üzembe helyezheti. Az Azure ML Studio és az ML Server egyaránt automatizálja az ilyen szolgáltatások létrehozásának folyamatát. Az ML Server esetében a Microsoft sablonokat biztosít egy támogató infrastruktúra üzembe helyezéséhez. Tekintse meg a vonatkozó dokumentációt.
Az alábbi ábra az üzembe helyezés architektúráját mutatja be. Tartalmazza az R nyelvet és a Pythont futtató kiszolgálók reprezentációit. Mindkét kiszolgáló a számítást végző webcsomópontok egy alszakaszával kommunikál. Egy nagy adattár csatlakozik a számítási blokkhoz.
5. ábra: Példa ml-kiszolgáló üzembe helyezésére
A HDInsighton vagy a Databricksen létrehozott modellek a Spark-környezettől (kódtáraktól, párhuzamos képességektől stb.) függnek. Érdemes lehet fürtön futtatni őket. Útmutatást itt talál. Ennek az az előnye, hogy az üzemeltetési modell maga is meghívható egy Data Factory-folyamat tevékenységen keresztül a pontozáshoz.
Tárolók használatához csomagolhatja a modelleket, és üzembe helyezheti őket az Azure Kubernetes Service-ben. A prototípusok használatához az Azure Adattudomány virtuális gép szükséges. Az Azure ML parancssori eszközeit is telepítenie kell a virtuális gépre.
Adatkimenet és -jelentéskészítés
Az üzembe helyezés után a modell feldolgozhatja a pénzügyi tranzakciós munkafolyamatokat és az árfolyam-leolvasásokat, hogy optimális választék-előrejelzéseket hozzon létre. Az így létrehozott adatok az Azure SQL Data Warehouse-ban tárolhatók további elemzés céljából. Különösen lehetséges a különböző termékváltozatok történeti teljesítményének tanulmányozása, a legjobb bevételgenerátorok és a veszteségkészítők azonosítása. Ezután összehasonlíthatja ezeket a modellek által javasolt választékokkal, és kiértékelheti a teljesítményt és az újratanítás szükségességét.
A Power BI lehetővé teszi a folyamat során előállított adatok elemzését és megjelenítését.
Az alábbi ábrán egy tipikus Power BI-irányítópult látható. Két grafikont tartalmaz, amelyek a termékváltozat részvényadatait jelenítik meg.
Biztonsági szempontok
A bizalmas adatokkal foglalkozó megoldás pénzügyi rekordokat, részvényszinteket és árinformációkat tartalmaz. Az ilyen bizalmas adatokat védeni kell. Az adatok biztonságával és adatvédelemmel kapcsolatos aggályait az alábbi módokon háríthatja el:
- Az Azure Data Factory-folyamat egy részét futtathatja a helyszínen az Azure Integration Runtime használatával. A futtatókörnyezet adatáthelyezési tevékenységeket hajt végre a helyszíni forrásokba és onnan. Emellett helyszíni végrehajtás céljából is küld tevékenységeket.
- Létrehozhat egy egyéni tevékenységet, amely anonimizálja az Adatokat az Azure-ba való átvitelhez, és futtathatja a helyszínen.
- Az összes említett szolgáltatás támogatja a titkosítást az átvitel és az inaktív állapotban. Ha úgy dönt, hogy az adatokat az Azure Data Lake használatával tárolja, a titkosítás alapértelmezés szerint engedélyezve van. Az Azure SQL Data Warehouse használata esetén engedélyezheti a transzparens adattitkosítást (TDE).
- Az ML Studio kivételével az összes említett szolgáltatás támogatja a Microsoft Entra ID-val való integrációt a hitelesítéshez és engedélyezéshez. Ha saját kódot ír, ezt az integrációt az alkalmazásba kell építenie.
Az Európai Unió adatvédelmi és adatvédelmi rendeletéről (GDPR) vonatkozó további információkért tekintse meg megfelelőségi oldalunkat.
Összetevők
Ebben a cikkben a következő technológiák szerepeltek:
- Azure Batch
- Microsoft Entra ID
- Azure Data Factory
- HDInsight
- Databricks
- Adattudomány virtuális gépek
- Azure Kubernetes Service
- Microsoft Power BI
Közreműködők
Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.
Fő szerző:
- Scott Seely | Szoftvertervező
A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.
Következő lépések
- Mi az Az Azure Data Factory?
- Integrációs modul az Azure Data Factoryben
- Mi a dedikált SQL-készlet (korábban SQL DW) az Azure Synapse Analyticsben?
- Azure Machine Learning Studio
- Mi az a Machine Learning Server?
- Pyomo-optimalizálás modellezési nyelve
- Bonmin solver
- TFoCS solver for Spark
Kapcsolódó erőforrások
Kapcsolódó kiskereskedelmi útmutató:
- Megoldások a kiskereskedelmi iparág számára
- Az e-kereskedelmi megoldás migrálása az Azure-ba
- Vizuális keresés a kiskereskedelemben az Azure Cosmos DB-vel
Kapcsolódó architektúrák: