Adattartományok

Az adatháló alapja a decentralizáltság és a felelősség tartományok közötti elosztása. Ha valóban tisztában van a vállalkozás ezen részével, akkor a legjobb helyzetben van a kapcsolódó adatok kezeléséhez és azok pontosságának biztosításához. Ez a tartományorientált adattulajdonság elve.

A tartományorientált adattulajdonlás előmozdításához először el kell bontania az adatarchitektúrát. A data mesh alapítója, Zhamak Dehghani a szoftverfejlesztés tartományalapú tervezési (DDD) megközelítését támogatja hasznos módszerként az adattartományok azonosításához.

A DDD adatkezeléshez való használatának nehézsége az, hogy a DDD eredeti használati esete az összetett rendszerek szoftverfejlesztési környezetben való modellezése volt. Eredetileg nem vállalati adatok modellezésére lett létrehozva, és az adatkezelési szakemberek számára ez a módszer absztrakt és technikai is lehet. A DDD ismerete is gyakran hiányzik. A gyakorlók túl nehezen tudják felfogni a fogalmi fogalmakat, vagy megpróbálnak példákat kivetíteni a szoftverarchitektúrából vagy az objektumorientált programozásból az adatkészletükre. Ez a cikk gyakorlati útmutatást és egyértelmű szókincset biztosít a DDD megértéséhez és használatához.

Tartományalapú tervezés

Az Eric Evans által bevezetett tartományalapú tervezés a szoftverfejlesztés támogatásának egyik módszere, amely segít leírni a nagyobb szervezetek összetett rendszereit. A DDD azért népszerű, mert számos magas szintű gyakorlata hatással van a modern szoftver- és alkalmazásfejlesztési megközelítésekre, például a mikroszolgáltatásokra.

A DDD megkülönbözteti a határolt környezeteket, tartományokat és altartományokat. A tartományok olyan problématerek, amelyeket meg szeretne címzni. Ezek olyan területek, ahol a tudás, a viselkedés, a törvények és a tevékenységek összejönnek. Szemantikai összekapcsolás jelenik meg a tartományokban, az összetevők vagy szolgáltatások közötti viselkedési függőségek. A tartományok másik aspektusa a kommunikáció. A csapattagoknak olyan nyelvet kell használniuk, amelyet a teljes csapat megoszt, hogy mindenki hatékonyan működjön. Ezt a megosztott nyelvet mindenütt elterjedt nyelvnek vagy tartománynyelvnek nevezzük.

A tartományok altartományokra vannak bontva az összetettség jobb kezelése érdekében. Erre egy gyakori példa, ha egy tartományt altartományokba bont, amelyek mindegyike egy adott üzleti problémának felel meg, ahogyan az AI/ML adathálójának üzemeltetése című cikkben látható.

Nem minden altartomány azonos. A tartományokat például úgy osztályozhatja, hogy mag, általános vagy támogató legyen. Az alapvető altartományok a legfontosabbak. Ezek a titkos szószok, az összetevők, amelyek egyedivé teszik a szervezetet. Az általános altartományok nem specifikusak, és általában könnyen megoldhatók a polcon kívüli termékekkel. Az altartományok támogatása nem kínál versenyelőnyt, de a szervezet működésének fenntartásához szükséges, és általában nem összetettek.

A határolt környezetek logikai (környezeti) határok. A megoldástérre összpontosítanak: a rendszerek és alkalmazások tervezésére. Ez egy olyan terület, ahol a fókusz igazítása a megoldástérre logikus. A DDD-ben ez magában foglalhatja a kódot, az adatbázisterveket és így tovább. A tartományok és a határos környezetek között lehet egymáshoz igazítás, a kettő összekötése nem kötelező. A határolt környezetek technikai jellegűek, és több tartományra és altartományra is kiterjedhetnek.

Tartománymodellezési javaslatok

Ha az adathálót az adatdemokratizálás fogalmaként alkalmazza, és a rugalmasság növelése érdekében implementálja a tartományorientált adattulajdonság elvét, hogyan működik ez a gyakorlatban? Hogyan nézhet ki a vállalati adatmodellezésről a tartományalapú tervezési modellezésre való áttérés? Milyen tanulságokat vonhat le a DDD-ből az adatkezeléshez?

A problématér funkcionális üzleti felbontásának létrehozása

Mielőtt lehetővé tenné a csapatok számára az adatok végpontok közötti üzemeltetését, tekintse meg a hatókört, és ismerje meg a kezelni kívánt problématereket. Fontos, hogy ezt a gyakorlatot először végezze el, mielőtt belevág a technikai megvalósítás részleteibe. Ha logikai határokat állít be ezek között a problématerek között, a felelősségek egyértelműbbé válnak, és hatékonyabban kezelhetők.

Tekintse meg az üzleti architektúrát, amikor csoportosítja a problémás tereket. Az üzleti architektúrán belül vannak üzleti képességek: képességek vagy kapacitások, amelyeket egy vállalkozás birtokol vagy cserél egy adott cél vagy eredmény elérése érdekében. Ez az absztrakció az adatokat, folyamatokat, szervezetet és technológiát egy adott kontextusba csomagolja, a szervezet stratégiai üzleti céljaival és célkitűzéseivel összhangban. Az üzleti képességek térképe megmutatja, hogy mely funkcionális területek szükségesek a küldetés és a jövőkép teljesítéséhez.

A tailwind traders nevű fiktív vállalat képességbeli felbontását az alábbi modellben tekintheti meg.

A Sikeresség érdekében a Tailwind Tradersnek az üzleti képességek térképében felsorolt összes funkcionális területet el kell sajátítnia. A Tailwind Tradersnek képesnek kell lennie jegyek értékesítésére az online vagy offline jegykezelési rendszerek részeként, például a pilótakezelő program részeként, vagy a pilóták számára, hogy repülőket repülhessenek. A vállalat kiszervezhet bizonyos tevékenységeket, miközben mások maradnak az üzleti tevékenység középpontjában.

A gyakorlatban azt fogja megfigyelni, hogy a legtöbb ember üzleti képességek köré van szervezve. Kapcsolatok ugyanazon üzleti képességen dolgozva ugyanazt a szókincset használja. Ugyanez igaz az alkalmazásokra és folyamatokra is, amelyek általában jól illeszkednek és szorosan kapcsolódnak az általuk támogatott tevékenységek kohéziója alapján.

Az üzleti képességek leképezése remek kiindulópont, de a történet nem itt fejeződik be.

Üzleti képességek leképezése alkalmazásokhoz és adatokhoz

A vállalati architektúra jobb kezelése érdekében igazodjon az üzleti képességekhez, a kötött környezetekhez és az alkalmazásokhoz. Fontos, hogy betartsunk néhány alapszabályt.

Az üzleti képességeknek üzleti szinten kell maradniuk, és absztraktnak kell maradniuk. Ezek képviselik a szervezet által elvégezhető feladatokat, és célként jelölik meg a problématereket. Egy üzleti képesség megvalósításakor létrejön egy adott környezet megvalósítása (képességpéldánya). Több alkalmazás és összetevő együttműködik a megoldástér ilyen határain belül, hogy konkrét üzleti értéket nyújtson.

Az adott üzleti képességhez igazított alkalmazások és összetevők függetlenek maradnak az egyéb üzleti képességekhez igazodó alkalmazásoktól, mivel különböző üzleti problémákat kezelnek. A kötött környezetek az üzleti képességekből származnak, és kizárólag az üzleti képességekre vannak leképezve. Ezek az üzleti képességek megvalósításának határait jelölik, és tartományként viselkednek.

Ha az üzleti képességek megváltoznak, a kötött környezetek megváltoznak. Lehetőleg a tartományok és a kapcsolódó kötött környezetek közötti teljes igazítást várhatja el, de ahogy a későbbi szakaszokban megtanulja, a valóság néha eltér az ideálistól.

Ha a Tailwind Tradershez projekteljük a képességleképezést, a határolt környezethatárok és a tartománymegvalósítások az alábbi diagramhoz hasonlóan nézhetnek ki.

Ebben a diagramban az ügyfélkezelés a szakterületek szakértelmére épül, ezért tudja a legjobban, hogy milyen adatokat szolgáljon ki más tartományok számára. Az ügyfélkezelés belső architektúrája leválasztva van, így a határokon belüli összes alkalmazásösszetevő közvetlenül kommunikálhat alkalmazásspecifikus interfészek és adatmodellek használatával.

Az adattermékeket és az egyértelmű együttműködési szabványokat arra használják, hogy alakilag alakilag alakizálják az adateloszlást más tartományok számára. Ebben a megközelítésben az összes adattermék a tartományhoz is igazodik, és örökli a mindenütt elterjedt nyelvet, amely egy, az érdekelt felek és a tervezők által ugyanabból a tartományból elfogadott, az adott tartomány igényeinek kiszolgálására létrehozott, formalizált nyelv.

További tartományok több képességmegvalósításból

Fontos elismerni, hogy az üzleti képességtérképek használatakor bizonyos üzleti képességek többször is példányosíthatók.

A Tailwind Traders például több honosított felismeréssel (vagy implementációval) rendelkezhet a "poggyászkezelésről és elveszett elemekről". Tegyük fel, hogy egy üzletáguk csak Ázsiában működik. Ebben az összefüggésben a "poggyászkezelés és az elveszett tárgyak" olyan képesség, amely az Ázsiai repülők számára teljesíthető. Egy másik üzletág az európai piacot célozhatja meg, és ebben az összefüggésben egy másik "poggyászkezelési és elveszett árukezelési" képességet használnak. Ez a több példányból álló forgatókönyv több honosított implementációhoz vezethet, amelyek különböző technológiai szolgáltatásokat és nem összekapcsolt csapatokat használnak a szolgáltatások üzemeltetéséhez.

Az üzleti képességek és képességpéldányok (megvalósítások) kapcsolata egy-a-többhöz. Emiatt a végén további (al-) tartományok lesznek.

Megosztott képességek keresése és a megosztott adatok figyelése

A megosztott üzleti képességek kezelése fontos. A megosztott képességeket általában központilag, szolgáltatási modellként valósítja meg, és különböző üzletágaknak nyújtja őket. Az "ügyfélkezelés" példa lehet erre a fajta képességre. A Tailwind Traders-példánkban az ázsiai és az európai üzletág is ugyanazt az adminisztrációt használja ügyfelei számára.

De hogyan vetítheti ki a tartományi adatok tulajdonjogát egy megosztott képességre? Valószínűleg több üzleti képviselő is felelős az ugyanazon megosztott felügyeleten belül lévő ügyfelekért.

Van egy alkalmazástartomány és egy adattartomány. A tartomány és a határolt környezet nem igazodik tökéletesen az adattermék szempontjából. Ezzel szemben azzal érvelhet, hogy az üzleti képességek szempontjából még mindig egyetlen adatkapcsolat áll fenn.

Az olyan megosztott képességek, mint az összetett szállítói csomagok, az SaaS-megoldások és az örökölt rendszerek, konzisztensek lehetnek a tartományadatok tulajdonjogának megközelítésében. Adattermékeken keresztül elkülönítheti az adattulajdont, ami alkalmazásfejlesztést igényelhet. A Tailwind Traders "ügyfélkezelés" példájában az alkalmazástartomány különböző folyamatai több adatterméket is létrehozhatnak: egy adatterméket az összes Ázsiai régióhoz kapcsolódó ügyfél számára, egyet pedig az összes Európához kapcsolódó ügyfél számára. Ebben az esetben több adattartomány is ugyanabból az alkalmazástartományból származik.

Az alkalmazástartományokat arra is megkérheti, hogy hozzanak létre egyetlen adatterméket, amely magában foglalja a metaadatokat az adattulajdonlás önmagában történő megkülönböztetéséhez. Lefoglalhat például egy oszlopnevet a tulajdonjoghoz, és minden sort egyetlen adott adattartományra képezhet le.

Több üzleti képességet kínáló monolitok azonosítása

Figyelje meg azokat az alkalmazásokat is, amelyek több üzleti képességet is kielégítenek, amelyeket gyakran a nagy és a hagyományos vállalatok is láthatnak. Példaforgatókönyvünkben a Tailwind Traders egy összetett szoftvercsomagot használ a "költségkezelés" és az "eszközök és finanszírozás" megkönnyítésére. Ezek a megosztott alkalmazások monolitok, amelyek a lehető legtöbb funkciót biztosítják, így nagyok és összetettek. Ilyen esetben az alkalmazástartománynak nagyobbnak kell lennie. Ugyanez vonatkozik a megosztott tulajdonjogra is, amelyben több adattartomány található egy alkalmazástartományban.

Tervezési minták a forráshoz igazított, a redelivery és a fogyasztó által igazított tartományokhoz

A tartományok megfeleltetésekor az adatok létrehozása, felhasználása vagy újrafelfedése alapján választhat mintát. Az architektúrához olyan sablonokat tervezhet, amelyek a tartomány adott jellemzői alapján támogatják a tartományokat.

Forrásrendszerhez igazított tartományok

A forrásrendszerhez igazított tartományok olyan forrásrendszerekkel vannak összhangban, amelyekből az adatok származnak. Ezek a rendszerek általában tranzakciós vagy üzemeltetési jellegűek.

A cél az adatok közvetlen rögzítése ezekből az arany forrásrendszerekből. Olvasásoptimalizált adattermékek a szolgáltató tartományokból az intenzív adatfelhasználás érdekében. Megkönnyítheti ezeket a tartományokat szabványosított szolgáltatásokkal az adatátalakításhoz és -megosztáshoz.

Ezek a szolgáltatások, amelyek előre konfigurált tárolóstruktúrát is tartalmaznak, lehetővé teszik a forrásorientált tartományi csapatok számára az adatok egyszerűbb közzétételét. Ez a legkisebb ellenállás útja minimális megszakítással és költségekkel.

Fogyasztóhoz igazított tartományok

A fogyasztó által igazított tartományok a forráshoz igazított tartományok ellentétei. Ezek igazodnak azokhoz a végfelhasználói használati esetekhez, amelyek más tartományokból származó adatokat igényelnek. Az ügyfélhez igazított tartományok a szervezet használati eseteinek megfelelően használják fel és alakítják át az adatokat.

Fontolja meg, hogy megosztott adatszolgáltatásokat kínáljon az adatátalakításhoz és a felhasználáshoz, hogy kielégítse ezeket a fogyasztási igényeket. Tartományszintű adatinfrastruktúra-képességeket kínálhat például az adatfolyamok, a tárolási infrastruktúra, a streamszolgáltatások, az elemzési feldolgozás stb. kezelésére.

Redelivery domains

Az adatok újrafelhasználhatósága egy másik és nehezebb forgatókönyv. Ha például az alsóbb rétegbeli fogyasztók különböző tartományokból származó adatok kombinációjára kíváncsiak, létrehozhat olyan adattermékeket, amelyek összesítik az adatokat, vagy kombinálják a számos tartomány által megkövetelt magas szintű adatokat. Így elkerülheti az ismétlődő munkát.

Ne hozzon létre erős függőségeket az adattermékek és az elemzési használati esetek között. Törekedjen inkább a rugalmasságra és a laza összekapcsolásra. Az alábbi modell bemutatja, hogyan érheti el a rugalmasságot. A tartományok az adattermékek és az elemzési használati esetek tulajdonjogát is átveszik, és külön folyamatokat terveztek az adattermékek létrehozásához és az adathasználathoz.

Átfedésben lévő tartományminták definiálása

A tartománymodellezés gyakran bonyolulttá válik, ha az adatok vagy az üzleti logika meg van osztva a tartományok között. A nagy méretű szervezetekben a tartományok gyakran más tartományokból származó adatokra támaszkodnak. Hasznos lehet olyan általános tartományokkal rendelkezni, amelyek olyan integrációs logikát biztosítanak, amely lehetővé teszi más altartományok számára, hogy egységesítsék és kihasználják azt. Tartsa a megosztott modellt az altartományok között, és mindig igazodjon a mindenütt használt nyelvhez.

Az egymást átfedő adatkövetelmények esetében a tartományalapú tervezés különböző mintáit használhatja. Íme egy rövid összefoglalás azokról a mintákról, ahonnan választhat:

• Ha az újrahasználhatósághoz kapcsolódó duplikálási költségeket szeretné előnyben részesíteni, külön módszerekkel is használható. Az újrahasználhatóság feláldozható a nagyobb rugalmasságért és rugalmasságért.
• Az ügyfél-szállító minta akkor használható, ha egy tartomány erős, és hajlandó átvenni az alsóbb rétegbeli fogyasztók adatainak és igényeinek tulajdonjogát. A hátrányok közé tartoznak az ütköző aggodalmak, és az alsóbb rétegbeli csapatok kényszerítése a termékek egyeztetésére és a prioritások ütemezésére.
• Partnerségi minta akkor használható, ha az integrációs logika nem tervezett módon van koordinálva egy újonnan létrehozott tartományban. Minden csapat együttműködik és figyelembe veszi egymás igényeit. Mivel senki sem módosíthatja szabadon a megosztott logikát, jelentős elkötelezettségre van szükség minden érintetttől.
• Egy konformista minta segítségével minden tartomány megfelelhet az összes követelménynek. Ezt a mintát akkor használja, ha az integrációs munka összetett, más felek nem rendelkezhetnek ellenőrzéssel, vagy szállítói csomagokat használnak.

A tartományoknak minden esetben meg kell felelnie az együttműködési szabványoknak. Egy olyan partneri tartománynak, amely új adatokat állít elő más tartományok számára, közzé kell tennie az adattermékeit, mint bármely más tartományt, beleértve a tulajdonjogot is.

Tartományi felelősségek

A Data Mesh decentralizáltan osztja el az adatok tulajdonjogát a tartományi csapatok között. Sok vállalat esetében ez azt jelenti, hogy a központosított modellről az összevont modellre vált. A tartományi csapatokhoz hozzárendelt feladatok, például:

• Az olyan adatfolyamok tulajdonjogának átvétele, mint az adatok betöltése, tisztítása és átalakítása, a lehető legtöbb adatigény kiszolgálása érdekében
• Az adatminőség javítása, beleértve az SLA-k betartását és az adatfogyasztók által meghatározott minőségi intézkedéseket
• Metaadatok beágyazása vagy fenntartott oszlopnevek használata részletes sor- és oszlopszintű szűréshez
• A metaadatok kezelési szabványainak betartása, beleértve a következőket:
  • Alkalmazás- és forrásrendszer-sémaregisztráció
  • Metaadatok a jobb felderíthetőség érdekében
  • Verziószámozási információk
  • Adatattribútumok és üzleti kifejezések összekapcsolása
  • A metaadatok integritása a tartományok közötti jobb integráció érdekében
• Az adat-együttműködési szabványok betartása, beleértve a protokollokat, az adatformátumokat és az adattípusokat
• Az életút biztosítása a forrásrendszerek és integrációs szolgáltatások szkennerekhez való összekapcsolásával, vagy a leállás manuális biztosításával
• Az adatmegosztási feladatokhoz való hozzáférés, beleértve az IAM hozzáférési felülvizsgálatait és az adatszerződés létrehozását

Részletességi szint a leválasztáshoz

Most már tudja, hogyan ismerheti fel és könnyítheti meg az adattartományok felismerését és megkönnyítését, megtanulhatja, hogyan tervezheti meg a tartomány részletességének megfelelő szintjét és a leválasztási szabályokat. Az architektúra lebontásakor két fontos dimenzió áll a háttérben.

A funkcionális tartományok részletessége és a határolt környezetek beállítása egyetlen dimenzió. A tartományok megfelelnek egy adott működési módnak, biztosítva, hogy az adatok minden megosztott szolgáltatást használó tartomány számára elérhetővé váljon, tulajdonjogot vállaljanak, betarthassák a metaadat-szabványokat stb.

Ahol csak lehetséges, adjon meg részletes határokat az adateloszláshoz. Az adatvezéreltvé válás az adatok intenzív újrafelhasználása érdekében való elérhetővé tételéről szól. Ha túl lazavá teszi a határokat, kényszeríti a nem kívánt összekapcsolást számos alkalmazás között, és elveszíti az adatok újrafelhasználhatóságát. Törekedjen a szétválasztásra minden alkalommal, amikor az adatok átlépik az üzleti képességek határait. Egy tartományon belül a tartomány belső architektúrájának szoros összekapcsolása engedélyezett. Az üzleti képességek határainak átlépésekor azonban a tartományoknak függetlennek kell lenniük, és olvasásoptimalizált adattermékeket kell terjeszteni a más tartományokkal való megosztáshoz.

A műszaki tartományok és az infrastruktúra kihasználtsága a másik fontos dimenzió. Az adat-kezdőzónák rugalmasságot tesznek lehetővé az adatalkalmazások karbantartásához, amelyek adattermékeket hoznak létre. Hogyan hozhat létre ilyen típusú célzónát megosztott infrastruktúrával és szolgáltatások alatt? A funkcionális tartományok logikailag csoportosítva vannak, és alkalmasak a platforminfrastruktúra megosztására. Az alábbiakban néhány tényezőt érdemes figyelembe venni a kezdőzónák létrehozásakor:

• Az adatok használata és megosztása során a kohézió és a hatékonyság a funkcionális tartományok adat-kezdőzónához való igazításának erős hajtóereje. Ez az adatgravitációval kapcsolatos, a nagy adattermékek tartományok közötti folyamatos megosztásának tendenciája.
• A regionális határok további adat-célzónák implementálását eredményezhetik.
• A tulajdonjog, a biztonság vagy a jogi határok kényszeríthetik a tartományok elkülönítését. Egyes adatok például nem láthatók más tartományok számára.
• A rugalmasság és a változás üteme fontos hajtóerő. Egyes tartományokban nagy az innováció sebessége, míg más tartományok erősen értékelik a stabilitást.
• A funkcionális határok szétválaszthatják a csapatokat. Erre példa lehet a forrás-orientált és a fogyasztó-orientált határok. A tartománycsapatok fele bizonyos szolgáltatásokat másokkal szemben értékelhet.
• Ha potenciálisan el szeretné adni vagy el szeretné különíteni a képességet, ne integráljon szorosan más tartományok megosztott szolgáltatásaival.
• A csapat mérete, készségei és érettsége mind fontos tényező lehet. A magasan képzett és érett csapatok gyakran inkább saját szolgáltatásokat és infrastruktúrát üzemeltetnek, míg a kevésbé érett csapatok kisebb valószínűséggel értékelik a platformkarbantartás többletterhelését.

Mielőtt sok adat-kezdőzónát kiépített, tekintse meg a tartomány felbontását, és állapítsa meg, hogy mely funkcionális tartományok lehetnek a mögöttes infrastruktúra megosztására jelölt tartományok.

Összegzés

Az üzleti képességek modellezése segít a tartományok jobb felismerésében és rendszerezésében egy adathálós architektúrában. Átfogó képet nyújt arról, hogy az adatok és alkalmazások hogyan biztosítanak értéket a vállalatnak, ugyanakkor segít rangsorolni és az adatstratégiára és az üzleti igényekre összpontosítani. Az üzleti képességek modellezése több adathoz is használható. Ha például a méretezhetőség problémát jelent, ezzel a modellel azonosíthatja a legkritikusabb alapvető képességeket, és kialakíthat hozzájuk egy stratégiát.

Egyes gyakorlók azt az aggodalmat keltik, hogy a célállapot-architektúra létrehozása minden elöl lévő leképezéssel intenzív gyakorlat. Ehelyett azt javasolják, hogy organikusan azonosítsa a tartományait, miközben azokat az új adathálós architektúrába helyezi. Ahelyett, hogy felülről lefelé definiálja a célállapotot, alulról felfelé dolgozik, feltárja, kísérletezi és áttűnésbe helyezi az aktuális állapotot egy célállapotra. Bár ez a javasolt megközelítés gyorsabb lehet, jelentős kockázatot hordoz. Könnyen egy összetett áthelyezési vagy újramodellezési művelet közepén lehet, amikor a dolgok elkezdenek megszakadni. Mindkét irányból, felülről lefelé és alulról felfelé haladva, majd az idő közepén való értekezlet sokkal árnyaltabb megközelítés.

Következő lépés

• Mi az az adattermék?