Ontwerpoverwegingen voor selfservicegegevensplatforms
Data mesh is een interessante nieuwe benadering van het ontwerp en de ontwikkeling van gegevensarchitectuur. In tegenstelling tot de traditionele gegevensarchitectuur scheidt data mesh de verantwoordelijkheid tussen functionele gegevensdomeinen die zich richten op het maken van gegevensproducten en een platformteam dat zich richt op technische mogelijkheden. Deze scheiding van verantwoordelijkheden moet worden weerspiegeld in uw platform. U moet een evenwicht vinden tussen het bieden van domeinagnostische mogelijkheden en het in staat stellen van uw domeinteams om hun gegevens te modelleren, te verwerken en te distribueren in uw organisatie.
Het kiezen van het juiste niveau van domeingranulariteit en regels voor het ontkoppelen met behulp van platforms is niet eenvoudig. Dit artikel bevat verschillende scenario's die u gedetailleerde richtlijnen bieden.
Analyses op cloudschaal
Wanneer u een data mesh wilt bouwen met Azure, raden we u aan om cloudanalyses te gebruiken. Dit framework is een implementeerbare referentiearchitectuur en wordt geleverd met opensource-sjablonen en best practices. Analysearchitectuur op cloudschaal heeft twee belangrijke bouwstenen die van fundamenteel belang zijn voor alle implementatiekeuzen:
- Landingszone voor gegevensbeheer: De basis van uw gegevensarchitectuur. Het bevat alle essentiële mogelijkheden voor gegevensbeheer, zoals gegevenscatalogus, gegevensherkomst, API-catalogus, hoofdgegevensbeheer, enzovoort.
- Gegevenslandingszones: Abonnementen die als host fungeren voor uw analyse- en AI-oplossingen. Ze bevatten belangrijke mogelijkheden voor het hosten van een analyseplatform.
Het volgende diagram geeft een overzicht van een analyseplatform op cloudschaal met een landingszone voor gegevensbeheer en één gegevenslandingszone. Niet alle Azure-services worden weergegeven in het diagram. Het is vereenvoudigd om de belangrijkste concepten van resource-organisatie binnen deze architectuur te benadrukken.
Het cloudgebaseerde analyseframework is niet expliciet over het exacte type gegevensarchitectuur dat u moet inrichten. U kunt het gebruiken voor veel algemene analyseoplossingen op cloudschaal, waaronder (enterprise) datawarehouses, data lakes, data lake houses en data meshes. Alle voorbeeldoplossingen in dit artikel maken gebruik van een data mesh-architectuur.
Begrijp dat alle architecturen voldoen aan de principes van data mesh: domeineigendom, gegevens als product, selfservicegegevensplatform en federatief rekenkundig beheer. Verschillende paden kunnen allemaal leiden tot een data-mesh. Er is geen enkel goed of fout antwoord. U moet de juiste afwegingen maken voor de behoeften van uw organisatie.
Eén gegevenslandingszone
Het eenvoudigste implementatiepatroon voor het bouwen van een data mesh-architectuur omvat één landingszone voor gegevensbeheer en één gegevenslandingszone. De gegevensarchitectuur in een dergelijk scenario ziet er als volgt uit:
In dit model bevinden al uw functionele gegevensdomeinen zich in dezelfde gegevenslandingszone. Eén abonnement bevat een standaardset services. Resourcegroepen scheiden verschillende gegevensdomeinen en gegevensproducten. Standaardgegevensservices, zoals Azure Data Lake Store, Azure Logic Apps en Azure Synapse Analytics, zijn van toepassing op alle domeinen.
Alle gegevensdomeinen volgen data mesh-principes: gegevens volgen domeineigendom en gegevens worden behandeld als producten. Het platform is volledig selfservice, maar er zijn beperkte variaties in services. Alle domeinen moeten sterk voldoen aan dezelfde principes voor gegevensbeheer.
Deze implementatieoptie kan handig zijn voor kleinere bedrijven of greenfield-projecten die data mesh willen omarmen, maar niet te ingewikkeld willen zijn. Deze implementatie kan ook een startpunt zijn voor een organisatie die van plan is om iets complexers te bouwen. In dit geval kunt u op een later tijdstip uitbreiden naar meerdere landingszones.
Op het bronsysteem uitgelijnde landingszones en op de consument afgestemde landingszones
In het vorige model hebben we geen rekening gehouden met andere abonnementen of on-premises toepassingen. U kunt het vorige model enigszins wijzigen door een op het systeem afgestemde bronzone toe te voegen om alle binnenkomende gegevens te beheren. Het onboarden van gegevens is een moeilijk proces, dus het is handig om twee gegevenslandingszones te hebben. Onboarding blijft een van de meest uitdagende onderdelen van het gebruik van gegevens in het algemeen. Onboarding vereist ook vaak extra hulpprogramma's om integratie aan te pakken, omdat de uitdagingen verschillen van die van de integratie. Het helpt om onderscheid te maken tussen het leveren van gegevens en het verbruiken van gegevens.
In de architectuur aan de linkerkant van dit diagram vergemakkelijken services het onboarden van alle gegevens, zoals CDC, services voor het ophalen van API's of data lake-services voor het dynamisch bouwen van gegevenssets. Services in dit platform kunnen gegevens ophalen uit on-premises, cloudomgevingen of SaaS-leveranciers. Dit type platform heeft doorgaans ook meer overhead, omdat er meer koppeling is met onderliggende operationele toepassingen. Mogelijk wilt u dit anders behandelen dan elk gegevensgebruik.
In de architectuur aan de rechterkant van het diagram optimaliseert de organisatie voor verbruik en beschikt de organisatie over services die zijn gericht op het omzetten van gegevens in waarde. Deze services kunnen machine learning, rapportage, enzovoort omvatten.
Deze architectuurdomeinen volgen alle principes van data mesh. Domeinen nemen eigenaar van gegevens en mogen gegevens rechtstreeks naar andere domeinen distribueren.
Hub-, algemene en speciale gegevenslandingszones
De volgende implementatieoptie is een andere herhaling van het vorige ontwerp. Deze implementatie volgt een beheerde mesh-topologie: gegevens worden gedistribueerd via een centrale hub, waarin gegevens per domein worden gepartitioneerd, logisch geïsoleerd en niet geïntegreerd. De hub van dit model maakt gebruik van een eigen (domein-agnostische) gegevenslandingszone en kan eigendom zijn van een centraal gegevensbeheerteam dat toezicht houdt op welke gegevens naar welke andere domeinen worden gedistribueerd. De hub biedt ook services die onboarding van gegevens mogelijk maken.
Gebruik algemene gegevenslandingszone voor domeinen waarvoor standaardservices nodig zijn voor het gebruiken, gebruiken, analyseren en maken van nieuwe gegevens. Dit ene abonnement bevat een standaardset services. Pas ook gegevensvirtualisatie toe, omdat de meeste van uw gegevensproducten al in de hub zijn opgeslagen en u geen gegevensduplicatie meer nodig hebt.
Deze implementatie maakt 'specials' mogelijk: extra landingszones die u kunt inrichten wanneer het niet mogelijk is om domeinen logisch te groepeert. Ze kunnen nodig zijn wanneer regionale of wettelijke grenzen van toepassing zijn, of wanneer uw domeinen unieke en contrasterende vereisten hebben. Mogelijk hebt u ze ook nodig in situaties waarin een sterke wereldwijde governance van dochterondernemingen wordt toegepast, met uitzonderingen voor buitenlandse activiteiten.
Als uw organisatie moet bepalen welke gegevens worden gedistribueerd en gebruikt door welke domeinen, is hubimplementatie een goede optie. Het is ook een optie als u rekening houdt met tijdvarianten en niet-vluchtige problemen voor grote gegevensgebruikers. U kunt het ontwerp van gegevensproducten sterk standaardiseren, zodat uw domeinen tijd kunnen reizen en opnieuw kunnen worden geleverd. Dit model is met name gebruikelijk in de financiële sector.
Functionele en regionaal uitgelijnde gegevenslandingszones
Door meerdere landingszones voor gegevens in te richten, kunt u functionele domeinen groeperen op basis van samenhang en efficiëntie voor het werken en delen van gegevens. Al uw gegevenslandingszones voldoen aan dezelfde controle- en besturingselementen, maar u kunt nog steeds flexibiliteit en ontwerpwijzigingen tussen verschillende gegevenslandingszones hebben.
Meerdere aspecten bepalen welke functionele gegevensdomeinen u logisch moet groeperen en kandidaten maken voor een gedeelde gegevenslandingszone. Regionale grenzen kunnen er bijvoorbeeld toe leiden dat u dezelfde blauwdrukken implementeert. Eigendom, beveiliging of juridische grenzen kunnen u dwingen domeinen te scheiden. Flexibiliteit, het tempo van verandering en scheiding of verkoop van uw mogelijkheden zijn ook belangrijke factoren.
Meer richtlijnen en best practices vindt u in gegevensdomeinen.
Verschillende landingszones staan niet op zichzelf. Ze kunnen verbinding maken met data lakes die worden gehost in andere zones. Hierdoor kunnen domeinen in uw hele onderneming samenwerken. U kunt ook polyglot-persistentie toepassen om verschillende technologieën voor gegevensopslag te combineren. Met Polyglot-persistentie kunnen uw domeinen gegevens rechtstreeks lezen uit andere domeinen zonder gegevens te dupliceren.
Wanneer u meerdere gegevenslandingszones implementeert, moet u weten dat er beheeroverhead is gekoppeld aan elke gegevenslandingszone. U moet VNet-peering toepassen tussen alle gegevenslandingszones, u moet extra privé-eindpunten beheren, enzovoort.
Het implementeren van meerdere landingszones voor gegevens is een goede optie als uw gegevensarchitectuur groot is. U kunt meer landingszones toevoegen aan uw architectuur om te voldoen aan algemene behoeften van verschillende domeinen. Deze extra landingszones maken gebruik van peering van virtuele netwerken om verbinding te maken met zowel de landingszone voor gegevensbeheer als alle andere landingszones. Met peering kunt u gegevenssets en resources delen in uw landingszones. Door gegevens over afzonderlijke zones te splitsen, kunt u workloads verdelen over uw Azure-abonnementen en -resources. Deze aanpak helpt bij het organisch implementeren van de data mesh.
Grootschalige ondernemingen die verschillende zones voor gegevensbeheer nodig hebben
Grote ondernemingen die wereldwijd actief zijn, kunnen uiteenlopende vereisten voor gegevensbeheer hebben tussen verschillende onderdelen van hun organisatie. U kunt meerdere zones voor gegevensbeheer en gegevenslanding samen implementeren om dit probleem op te lossen. In het volgende diagram ziet u een voorbeeld van dit type architectuur:
Meerdere landingszones voor gegevensbeheer moeten uw overhead en integratiecomplexiteit rechtvaardigen. Een andere landingszone voor gegevensbeheer kan bijvoorbeeld zinvol zijn voor situaties waarin de (meta)gegevens van uw organisatie niet mogen worden gezien door iemand buiten uw organisatie.
Conclusie
De overgang naar data mesh is een culturele verschuiving met nuances, afwegingen en overwegingen. U kunt analyses op cloudschaal gebruiken om best practices en uitvoerbare resources te verkrijgen. De referentiearchitecturen van dit artikel bieden uitgangspunten voor u om aan de slag te gaan met uw implementatie.