A kiskereskedők és a fogyasztói márkák arra összpontosítanak, hogy a 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 termékek (vagy termékkombinációk) a vásárlási élmény fő részét 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-választék egy összetett témakör, amely az ellátási és logisztikai értékláncra terjed ki. Ebben a dokumentumban kifejezetten arra a problémára összpontosítunk, hogy optimalizáljuk a termékváltozat-választékot a fogyasztási cikkekből származó bevétel maximalizálása érdekében. A termékváltozat-optimalizálás rejtvénye megoldható algoritmusok fejlesztésével a következő kérdések megválaszolására:
- Mely termékváltozatok teljesítenek a legjobban egy adott piacon vagy üzletben?
- 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 melyiket érdemes magasabb teljesítményű termékváltozatokkal helyettesíteni?
- Milyen egyéb megállapítások származtathatók a fogyasztói és piaci szegmensekről?
A döntéshozatal automatizálása
A fogyasztói márkák hagyományosan a termékváltozat-portfólióban lévő termékváltozatok számának növelésével közelítettek a fogyasztói igényekhez. A ballonozott termékváltozatok és a verseny növekedésével a becslések szerint a bevétel 90 százaléka a termékváltozatok 10%-ának van tulajdonítve a portfólión belül. 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 való jelölt.
A statikus jelentéskészítés hagyományos módszerei az előzményadatokat használják, ami korlátozza a megállapításokat. A legjobb, hogy 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. A mesterséges intelligencia (AI) és a felhőalapú számítástechnika fejlődésével a fejlett elemzések számos választási lehetőséget és előrejelzést kínálnak. Az ilyen típusú automatizálás javítja az eredményeket és a sebességet az ügyfelek felé.
Termékváltozat-választék optimalizálása
A termékváltozat-választékos megoldásoknak több millió termékváltozatot kell kezelnie azáltal, hogy az értékesítési adatokat értelmes és részletes összehasonlításokra szegmentálta. A megoldás célja, hogy a termékek választékának fejlett elemzésekkel történő finomhangolásával maximalizálja az értékesítést minden üzletben vagy üzletben. A második cél a készleten kívüli készletek 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. E célból az elemzések lehetővé teszik az alábbiakat:
- Megismerheti a termékváltozatok portfoliójának teljesítményét, és kezelheti az alacsony teljesítményt nyújtókat.
- Optimalizálja a termékváltozatok eloszlá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.
- Megismételhető, méretezhető és végrehajtható elemzéseket hozhat létre a meglévő adatokból.
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 hellyel, az időjárással, a census adatokkal stb. A vizualizációk segítenek a személynek elemzéseket kinyerni az adatok értelmezésével. Ennek során azonban a személy csak arra korlátozódik, hogy megértse, mi történt az előző értékesítési ciklusban, vagy esetleg mi történik az aktuális időszakban (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ő annak megértéséhez, hogy milyen termékváltozatok voltak a legjobb és legrosszabb teljesítményt nyújtók egy adott időszakban.
Az alábbi ábrán egy tipikus jelentés látható az előzményadatokról – az értékesítési adatokról. Számos jelölőnégyzetet tartalmazó blokkot tartalmaz az eredmények szűrésére vonatkozó feltételek kiválasztásához. A központban két sávdiagram látható, amelyek az időbeli értékesítéseket mutatják. Az első diagram a heti átlagos értékesítést mutatja; A második a mennyiségeket jeleníti meg hét szerint.
Előrejelző elemzés
Az előzményjelentések hasznosak a történtek megértéséhez. Végső soron előrejelzést szeretnénk kapni arról, hogy mi várható. A múltbeli információk erre a célra lehetnek hasznosak. Azonosíthatjuk például a szezonális trendeket. De nem fedheti le a "lehetőségelemzési" forgatókönyveket– például egy új termék bevezetésének modellezésére. Ehhez az ügyfelek viselkedésének modellezésére kell összpontosítanunk, mivel ez az értékesítést meghatározó végső tényező.
A probléma részletes áttekintése: választási modellek
Kezdjük azzal, hogy meghatározzuk, mit keresünk, és milyen adatokkal rendelkezünk:
A választékoptimalizálás azt jelenti, hogy olyan termékek egy részhalmazát keresi meg, amelyeket értékesíthet, így maximalizálhatja a várható bevételt. Ezt keressük.
A tranzakciós adatokat rendszeresen gyűjtjük pénzügyi célokra.
A választékadatok potenciálisan mindent tartalmaznak, ami a termékváltozatokra vonatkozik: Íme egy példa arra, hogy mit szeretnénk:
- a termékváltozatok száma
- Termékváltozat-leírások
- lefoglalt mennyiségek
- Termékváltozat és megvásárolt mennyiség
- események időbélyegei (például vásárlás)
- Termékváltozat ára
- SKU-ár POS-nél
- a termékváltozatok készletszintje bármikor
Sajnos az ilyen adatok gyűjtése nem olyan megbízható, mint a tranzakciós adatok.
Ebben a dokumentumban az egyszerűség kedvéért csak a tranzakciós adatokat és a termékváltozat-adatokat vesszük figyelembe, a külső tényezőket nem.
Még így is vegye figyelembe, hogy mivel egy sor n termék, van 2n lehetséges választék. Ez nagy számítási igényű folyamattá teszi az optimalizálási problémát. Az összes lehetséges kombináció kiértékelése sok termék esetében nem praktikus. Így a szorzatok jellemzően kategóriák (például gabonafélék), hely és egyéb kritériumok szerint vannak szegmentálva a változók számának csökkentésére. Az optimalizálási modellek megpróbálják "kimetszeni" a permutációk számát egy működőképes részhalmazra.
A probléma középpontjában a fogyasztók viselkedésének hatékony modellezése áll. Egy tökéletes világban a nekik bemutatott termékek megfelelnek azoknak, amelyeket meg szeretnének vásárolni.
A fogyasztók választásának előrejelzésére használható matematikai modelleket évtizedek alatt fejlesztettek ki. A modell kiválasztása végül meghatározza a legmegfelelőbb megvalósítási technológiát; ezért összefoglaljuk őket, és néhány szempontot is figyelembe fogunk venni.
Parametrikus modellek
A paraméteres modellek megközelítik az ügyfelek viselkedését egy véges paraméterkészlettel rendelkező függvénnyel. A paramétereket ú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 eredményének valószínűségének kiszámítására szolgál. Ebben az esetben az MNL használatával a következő számításokat végezheti el:
- Annak a valószínűsége, hogy a fogyasztó (c) egy adott időpontban (t) választ ki egy elemet (i) az adott kategóriába tartozó elemek egy választékában (a) az ügyfél számára ismert segédprogrammal (v).
Azt is feltételezzük, hogy egy elem segédprogramja a funkcióinak függvénye lehet. A segédeszközben külső információk is szerepelhetnek (például esés esetén az esernyő hasznosabb).
Gyakran használjuk az MNL-t más modellek teljesítménytesztjeként, mivel a paraméterek becslésekor és az eredmények kiértékelésekor hasznosítható. Más szóval, ha rosszabbat tesz, 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ására.
Az R- és Python-programozási nyelvekhez kódtárak tartoznak. Az R esetében használhatja a glm -et (és származékokat). A Pythonhoz a scikit-learn, a biogeme és a larch használható. Ezek a kódtárak eszközöket kínálnak az MNL-problémák meghatározásához, és párhuzamos megoldásokat kínálnak a különböző platformokon való megoldások megtalálásához.
Legutóbb az MNL-modellek GPU-kon történő implementálását javasolták összetett modellek kiszámítására számos paraméterrel, amelyek egyébként inkontraszthatóvá tennék őket.
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 több különböző eredmény valószínűségi eloszlását jelöli. A többi implementációhoz képest lassúak a betanításuk, de sok 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 a két lehetőség közötti választás relatív valószínűsége 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 egyenlően szereti, akkor az idő 50%-ában a másikat fogja választani. Lássunk a "C" terméket a keverékbe. Az idő 50%-ában továbbra is választhatja az "A" lehetőséget, de most 25%-ot "B" értékre, 25%-ot pedig "C"-ra osztott. A relatív valószínűség megváltozott.
Emellett az MNL és a származékos termékeknek nincs egyszerű módja a helyettesítés figyelembe vételére a készlet vagy a választék fajtája miatt (azaz ha nincs világos ötlete, és véletlenszerű elemet választ a polcon lévők között). A nem parametrikus modelleket úgy tervezték, hogy figyelembe vehessenek a helyettesítést, és kevesebb korlátozást írjanak elő az ügyfelek viselkedésére.
Bevezetik a "rangsorolás" fogalmát – ahol a fogyasztók szigorúan részesítik előnyben a termékeket egy választékban. A vásárlási viselkedésük ezért modellezhető ú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:
- $r_i$ az i. termék bevételét jelöli.
- _ $y_i^k$_ 1, ha az i terméket a k rangsorban választják. Ellenkező esetben 0.
- $\lambda_k$ annak a valószínűsége, hogy az ügyfél a k rangsor alapján választ.
- _ $x_i$_ 1, ha a termék szerepel a választékban. Ellenkező esetben 0.
- K a rangsorok száma.
- n a termékek száma.
Megjegyzés
Korlátozásoktól függ:
- Az egyes rangsorok esetében pontosan 1 választás lehet.
- A rangsor k, a termék csak akkor választható, ha része a választék.
- Ha egy termék i szerepel a választékban, a k rangsorban egyik kevésbé előnyös lehetőség sem választható.
- Nincs vásárlás lehetőség, és mint ilyen, a rangsorban egyik kevésbé előnyös lehetőség sem választható.
Egy ilyen megfogalmazásban a probléma vegyes egész szám optimalizálásnak tekinthető.
Vegyük figyelembe, hogy ha n termék van, akkor a lehetséges rangsorok maximális száma, beleértve a választható lehetőségeket is, faktoriális: (n+1)!
A készítmény korlátai lehetővé teszik a lehetséges lehetőségek viszonylag hatékony eltávolítását. (Például csak a legkedvezményesebb lehetőség van kiválasztva, és az 1 értékre van állítva. A többi értéke 0.) Elképzelhető, hogy az implementáció méretezhetősége fontos lesz a lehetséges alternatívák számának figyelembevételével.
Az adatok fontossága
Korábban már említettük, hogy az értékesítési adatok könnyen elérhetők. Ezeket szeretnénk felhasználni a választékoptimalizálási modellünk tájékoztatására. 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 időbélyegekkel ellátott tranzakciókból, valamint az ügyfelek számára az adott időpontban és helyen megjelenített termékekből állnak. Ezekből létrehozhatunk egy tényleges értékesítés vektorát, amelynek vi.m. elemei az i. tétel vevőnek való értékesítésének valószínűségét jelölik, $S_m$
Mátrixot is létrehozhatunk:
A valószínűségi eloszlás λ megkeresése az értékesítési adatok alapján egy másik optimalizálási problémává válik. Egy λ vektort szeretnénk találni az értékesítési becslési hiba minimalizálása érdekében:
$$min_\lambda|\Lambda\lambda - v|$$
Vegye figyelembe, hogy a számítás regresszióként is kifejezhető, és így olyan modellek is használhatók, mint a több variátumú döntési fák.
Megvalósítás részletei
Mivel az előző megfogalmazásból levonható, 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: termékváltozat max. Ezeket az architektúrákat fogjuk példaként használni, és néhány szempontot is figyelembe fogunk venni.
- Először is (1) egy robusztus és méretezhető adatfolyamra támaszkodnak a modellek betáplálásához, és (2) 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. ábra egy példaarchitektúrát mutat be. Négy fő blokkot tartalmaz, a rögzítést, a feldolgozást, a modellezést és az üzemeltetést. Minden blokk fő folyamatokat tartalmaz. A rögzítés magában foglalja az "adatok előfeldolgozását;" a "store data" függvényt; a modell tartalmazza a "gépi tanulási modell betanítása" függvényt; és az operationalize magában foglalja az "adatok tárolását" és a 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 üzemeltetése szempontjából is. A folyamat tevékenységeit Azure Data Factory, egy felügyelt ETL-szolgáltatással vezényeljük, amely lehetővé teszi az integrációs munkafolyamatok tervezését és futtatását.
A Azure Data Factory egy felügyelt szolgáltatás, amely "tevékenységnek" nevezett összetevőkkel rendelkezik, amelyek adatkészleteket használnak fel és/vagy állítanak elő.
A tevékenységek feloszthatók a következőre:
- adatáthelyezés (például másolás a forrásból a 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égcsoportokat összekapcsoló munkafolyamatokat az adat-előállító szolgáltatás ütemezheti, figyelheti és kezelheti. A teljes munkafolyamat neve "folyamat".
A rögzítési fázisban a másolási tevékenység (a Data Factorybe beépített) használatával különböző forrásokból (helyszíni és felhőbeli) adatokat továbbíthatunk Azure SQL Data Warehouse. Példák a dokumentációban található műveletekre:
Az alábbi ábrán egy folyamat definíciója látható. Három egyenlő méretű három blokkból áll egy sorban. Az első kettő egy adathalmaz és egy, az adatfolyamokat jelző nyilakkal összekapcsolt tevékenység. A harmadik blokk a "folyamat" címkével van ellátva, és egyszerűen az első kettőre mutat, amely beágyazást jelez.
3. ábra: A Azure Data Factory alapfogalmai
A Neal Analytics megoldása által használt adatformátumra a Microsoft Appsource oldalán talál példát. A megoldás a következő adathalmazokat tartalmazza:
- Az üzlet és a termékváltozat egyes kombinációinak értékesítési előzményadatai
- Tárolási és fogyasztói rekordok
- Termékváltozat-kódok és leírás
- Termékváltozat-attribútumok, amelyek rögzítik a termékek jellemzőit (például méret, anyag). Ezeket általában parametrikus modellekben használják a termékváltozatok megkülönböztetésére.
Ha az adatforrások nem az adott formátumban szerepelnek, a Data Factory számos átalakítási tevékenységet kínál.
A folyamat fázisában SQL Data Warehouse a fő tárolómotor. Ezért érdemes lehet egy ilyen átalakítási tevékenységet SQL tárolt eljárásként kifejezni, 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 a tárolt eljárások SQL Data Warehouse és SQL. Valójában számos platformmal integrálható. Választhatja például a Databricks használatát, és futtathat egy Python-szkriptet az átalakításhoz. Ez egy előny, mivel egy platformot használhat a gépi tanulási algoritmusok tárolásához, átalakításához és betanításához a következő "modell" szakaszban.
A ML algoritmus betanítása
Számos olyan eszköz létezik, amely segít a parametrikus és 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 ML Studio kiváló eszköz a prototípus-íráshoz. Egyszerű módot kínál a betanítási munkafolyamatok létrehozására és futtatására kódmodulokkal (R vagy Python) vagy előre definiált ML összetevőkkel (például többosztályos osztályozókkal, megnövelt döntési fa regresszióval) grafikus környezetben. Emellett lehetővé teszi egy betanított modell webszolgáltatásként való közzétételét további felhasználás céljából, néhány kattintással, rest felület létrehozásával.
Az általa kezelhető adatméret azonban 10 GB-ra van korlátozva (egyelőre), és az egyes összetevők számára elérhető magok száma is 2-re van korlátozva (egyelőre).
Ha további skálázásra van szüksége, de továbbra is használni szeretné a Microsoft gyakori gépi tanulási algoritmusának (például a többnomiális logisztikai regresszió) néhány párhuzamos implementációját, érdemes lehet áttekinteni az Azure-Data Science Virtual Machine futó Microsoft ML Server.
Nagyon nagy adatméretek (TB-k) esetén érdemes olyan platformot választani, ahol a tároló és a számítási elem a következő lehetőségeket kínálhatja:
- Skálázás egymástól függetlenül, a költségek csökkentése érdekében, ha nem betanítsa a modelleket.
- Ossza el a számítást több mag között.
- Futtassa a "közel" számítást a tárolóhoz 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 a Azure Data Factory szerkesztőben. Viszonylag egyszerű bármelyiket integrálni egy munkafolyamatba.
ML Server és kódtárai üzembe helyezhetők a HDInsighton, de a platform képességeinek teljes kihasználásához érdemes lehet implementálni a ML választott algoritmust a SparkML, a Microsoft ML Spark-kódtárak használatával a Pythonban, vagy más speciális lineáris programozási solvereket, például a TFoCS-ot, a Spark-LP-t vagy a SolveDF-et.
A betanítási folyamat elindítása után felmerül a kérdés, hogy a megfelelő pySpark-szkriptet vagy jegyzetfüzetet kell-e invokálásra használni 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-jegyzetfüzet tevékenységével Azure Data Factory.
Az alábbi ábrán a Data Factory felhasználói felülete látható, ahogyan az a Azure Portal keresztül érhető el. Blokkokat tartalmaz a munkafolyamat különböző folyamataihoz.
4. ábra: Data Factory-folyamat példája Databricks-jegyzetfüzettevékenységgel
Azt is vegye figyelembe, hogy készletoptimalizálási megoldásunkban a solverek tárolóalapú implementálását javasoljuk, amely Azure Batch keresztül van skálázva. Az olyan speciális optimalizálási kódtárak, mint a pyomo, lehetővé teszik, hogy optimalizálási problémát fejezhessen ki a Python programozási nyelvben, majd független megoldásmegoldókat hívhat meg, például bonmint (nyílt forráskód) vagy gurobitot (kereskedelmi) a megoldás megtalálásához.
A készletoptimalizálás dokumentációja más problémával (megrendelési mennyiségekkel) foglalkozik, mint a választékoptimalizálással, de a solvers azure-beli implementálása is hasonlóan alkalmazható.
Bár összetettebb, mint az eddig javasolt, ez a technika lehetővé teszi a maximális méretezhetőséget, amelyet többnyire a megengedhető magok mennyisége korlátoz.
A modell futtatása (operacionalizálás)
A modell betanítása után a futtatása általában az üzembe helyezéshez használt infrastruktúrától eltérő infrastruktúrát igényel. Annak érdekében, hogy könnyen használható legyen, dönthet úgy, hogy rest felülettel rendelkező webszolgáltatásként helyezi üzembe. Az Azure ML Studio és a ML Server is automatizálja az ilyen szolgáltatások létrehozásának folyamatát. A ML Server esetében sablonokat biztosítunk 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. Ez 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 HDInsightban vagy a Databricksben létrehozott, így a Spark-környezettől (kódtáraktól, párhuzamos képességektől stb.) függő modellek esetében érdemes megfontolni a fürtön való futtatásukat. Útmutatást itt talál.
Ez azzal az előnnyel jár, hogy az operatív 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 Azure Kubernetes Service. A prototípus használatához azure-beli adatelemzési virtuális gép szükséges; az Azure ML parancssori eszközöket is telepítenie kell a virtuális gépre.
Adatkimenet és jelentéskészítés
Az üzembe helyezést követően a modell képes lesz feldolgozni a pénzügyi tranzakciók munkafolyamatait és készletolvasásait, hogy optimális választék-előrejelzéseket hozzon létre. Az így előállított adatok további elemzés céljából vissza tárolhatók Azure SQL Data Warehouse. Különösen lehetséges lesz a különböző termékváltozatok korábbi teljesítményének tanulmányozása, a legjobb bevételgenerátorok és a veszteséges termelők azonosítása. Ezután összehasonlíthatja ezeket a modellek által javasolt választékokkal, és kiértékelheti a teljesítményt, valamint az újratanítás szükségességét.
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 mutatják.
Biztonsági szempontok
A bizalmas adatokkal foglalkozó megoldások pénzügyi rekordokat, készletszinteket és áradatokat tartalmaznak. Az ilyen bizalmas adatokat védeni kell. Az adatok biztonságával és adatvédettségével kapcsolatos aggodalmak eloszlatásához vegye figyelembe a következő szempontokat:
- A Azure Data Factory-folyamat egy részét futtathatja a helyszínen az Azure Integration Runtime használatával. A futtatókörnyezet a helyszíni forrásokba vagy forrásokból történő adatáthelyezési tevékenységeket hajtja végre. Emellett a helyszíni végrehajtáshoz is küld tevékenységeket.
- Érdemes lehet olyan egyéni tevékenységet fejleszteni, amely anonimizálja az Azure-ba továbbítandó adatokat (és futtatja őket a helyszínen).
- Az összes említett szolgáltatás támogatja az átvitel és az inaktív állapot titkosítását. Ha úgy dönt, hogy az adatokat egy Azure Data Lake-en tárolja, a titkosítás alapértelmezés szerint engedélyezve van. Ha Azure SQL Data Warehouse használ, engedélyezheti a transzparens adattitkosítást (TDE).
- Az összes említett szolgáltatás – a ML Studio kivételével – támogatja az integrációt a Azure Active Directory hitelesítéshez és engedélyezéshez. Ha saját kódot ír, ezt az integrációt kell beépítenie az alkalmazásba.
A GDPR-ről a megfelelőségi oldalunkon talál további információt.
Összetevők
Ebben a cikkben a következő technológiák szerepeltek:
- Azure Batch
- Azure Active Directory
- Azure Data Factory
- Azure Integration Runtime
- HDInsight
- Databricks
- Azure SQL Data Warehouse
- Azure ML Studio
- Microsoft ML Server
- Azure Data Science VM
- Azure Kubernetes Service
- Microsoft Power BI
- Pyomo optimization Modeling Language
- Bonmin Solver
- TFoCS solver for Spark
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ő