Data Mesh
Credit: Thoughtworks
Databeheer centraliseren of distribueren? Die vraag staat op de voorgrond sinds de afdelingsminicomputers de onderneming binnenvielen, nog subversiever gevolgd door pc's en LAN's die via de achterdeur binnenkwamen. En sindsdien is de conventionele wijsheid heen en weer geslingerd. Werkgroep- of afdelingssystemen om gegevens toegankelijk te maken, en vervolgens consolidaties van bedrijfsdatabases om alle duplicatie te verwijderen.
Weet je nog toen het datameer de eindstatus moest zijn? Net als het bedrijfsdatawarehouse ervoor, bleek het idee dat alle gegevens op één plek zouden kunnen komen, zodat er slechts één enkele bron van waarheid was waartoe alle lagen van de bevolking in de onderneming toegang hadden, onrealistisch. De verbondenheid van internet, de schijnbaar goedkope opslag en eindeloze schaalbaarheid van de cloud, de explosie van smart device- en IoT-data dreigen de zo moeizaam opgezette datawarehouses en datameren te overweldigen. Data lakehouses zijn de laatste tijd ontstaan om het beste van twee werelden te bieden, terwijl datafabrics en intelligente datahubs de afweging tussen virtualiseren en repliceren van data optimaliseren.
Het zou zinloos zijn om te stellen dat een van deze alternatieven de definitieve oplossing biedt. silver bullet.
Voer de data mesh in
Het afgelopen jaar is er een nieuwe theorie ontstaan die de nutteloosheid van top-down of monolithische benaderingen van datamanagement erkent: de data mesh. Hoewel de laatste tijd veel aandacht is besteed aan AI en machine learning, zijn er in de datawereld minder onderwerpen die meer discussie oproepen dan datamesh. Kijk maar naar Google Trends-gegevens van de afgelopen 90 dagen: er zijn veel meer zoekopdrachten naar Data Mesh dan die voor Data Lakehouse.
Het is ontstaan door Zhamak Dehghani, directeur van de volgende technische incubatie bij Thinkworks North America, via een uitgebreide reeks werken, beginnend met een introductie in 2019, een diepgaande analyse van principes en logische architectuur eind 2020, die binnenkort zal uitmonden in een boek (als je geïnteresseerd bent, biedt Starburst Data een voorproefje). Data meshes zijn vaak vergeleken met data fabrics, maar als je Dehghani's werk goed leest, blijkt dat het meer om processen gaat dan om technologie, zoals James Serra, een architectuurleider bij EY en voorheen bij Microsoft, terecht opmerkte in een blogpost. Desalniettemin verdient het onderwerp van data meshes (die gedistribueerde weergaven van het data-domein zijn) versus data fabrics (die meer gecentraliseerde benaderingen toepassen) een eigen post, aangezien de interesse in beide vrij gelijkaardig is.
Simpel gezegd, als dat mogelijk is, is data mesh geen technologiestack of fysieke architectuur. Data mesh is een proces- en architectuurbenadering die de verantwoordelijkheid voor specifieke datasets delegeert aan domeinen of bedrijfsonderdelen die over de vereiste vakkennis beschikken om te weten wat de data moeten voorstellen en hoe ze moeten worden gebruikt.
Dit heeft een architectonisch aspect: in plaats van aan te nemen dat gegevens zich in een datameer zullen bevinden, is elk “domein” verantwoordelijk voor het kiezen hoe de datasets waarvan ze eigenaar zijn, te hosten en te bedienen.
Naast externe regelgeving of corporate governance beleid zijn de domeinen de reden waarom specifieke datasets worden verzameld. Maar de duivel zit in de details, en dat zijn er veel.
De data mesh wordt dus niet gedefinieerd door het datawarehouse, data lake of data lakehouse waar de data zich fysiek bevindt. Het wordt ook niet gedefinieerd door de gegevensfederatie, gegevensintegratie, query-engine of catalogiseringstools die deze gegevensarchieven vullen en annoteren. Dat weerhoudt technologieleveranciers er natuurlijk niet van om hun producten te wassen met datamesh. In het komende jaar zullen we waarschijnlijk leveranciers van catalogi, query-engines, datapijplijnen en governance hun tools of platforms in een datamesh-licht zien schilderen. Maar als u de marketingberichten ziet, onthoud dan dat datanetwerken gaan over processen en hoe u technologie implementeert. Een federatieve query-engine is bijvoorbeeld gewoon een enabler die een team kan helpen bij de implementatie, maar op zichzelf niet plotseling een data-domein verandert in een datamesh.
De kernpijlers
< p>Data Mesh is een complex concept, maar de beste manier om te beginnen is door de principes erachter te begrijpen.
Het eerste principe gaat over het eigendom van gegevens: het moet lokaal zijn en bij het team behoren dat verantwoordelijk is voor het verzamelen en/of gebruiken van de gegevens. Als er een centraal principe is voor data meshes, dan is dit het wel: de controle over data moet worden overgedragen aan het domein dat de data bezit. Beschouw een domein als een uitbreiding van domeinkennis – dit is de organisatie-eenheid of groep mensen die begrijpen wat de gegevens zijn en hoe deze zich verhouden tot het bedrijf. Dit is de entiteit die weet waarom de dataset wordt verzameld; hoe het wordt geconsumeerd en door wie; en hoe het moet worden beheerd tijdens zijn levenscyclus.
Het wordt een beetje ingewikkelder voor gegevens die worden gedeeld tussen domeinen, of waar gegevens onder één domein afhankelijk zijn van gegevens of API's van andere domeinen. Welkom in de echte wereld, waar data zelden een eiland is. Dit is een van de plaatsen waar het implementeren van meshes plakkerig kan worden.
Het tweede principe is dat data gezien moet worden als een product. Dat is in feite een uitgebreidere kijk op wat een data-entiteit omvat, in die zin dat het meer is dan het stuk data of een specifieke dataset en meer een levenscyclusvisie geeft van hoe data kunnen en moeten worden bediend en geconsumeerd. En een deel van de definitie van het product is een formele serviceniveaudoelstelling, die betrekking kan hebben op factoren als prestaties, betrouwbaarheid en betrouwbaarheid, gegevenskwaliteit, beveiligingsgerelateerde autorisatieregels, enzovoort. Het is een belofte die het domein dat eigenaar is van de gegevens doet aan de organisatie.
In het bijzonder gaat een dataproduct verder dan de dataset of data-entiteit en bevat het de code voor de datapijplijnen die nodig zijn om de data te genereren en/of te transformeren; de bijbehorende metadata (die natuurlijk alles kunnen omvatten, van schemadefinitie tot relevante termen uit de zakelijke woordenlijst, consumptiemodellen of formulieren zoals relationele tabellen, gebeurtenissen, batchbestanden, formulieren, grafieken, enz.); en infrastructuur (hoe en waar de gegevens worden opgeslagen en verwerkt). Dit heeft aanzienlijke organisatorische gevolgen, aangezien het bouwen van datapijplijnen vaak een onsamenhangende activiteit is die onafhankelijk wordt uitgevoerd door gespecialiseerde beoefenaars zoals data-engineers en ontwikkelaars. In een matrixcontext moeten ze tenminste deel uitmaken van of geassocieerd zijn met het domein of het zakelijke team dat eigenaar is van de gegevens.
Trouwens, dat dataproduct moet aan een aantal belangrijke eisen voldoen. De gegevens moeten gemakkelijk vindbaar zijn; dit is vermoedelijk waar catalogi voor zijn. Het moet ook verkend kunnen worden, zodat gebruikers meer informatie kunnen krijgen. En het moet adresseerbaar zijn; hier vermeldt Dehghani dat gegevens unieke canonieke adressen moeten hebben, wat klinkt als een abstractie op een hoger niveau dan het semantische webrestant, de klassieke Uri. Ten slotte moeten gegevens begrijpelijk zijn (Dehghani suggereert “zelfbeschrijvende semantiek en syntaxis”); betrouwbaar; en veilig. Laten we niet vergeten dat, aangezien dit bedoeld is om meerdere domeinen te overschrijden, inspanningen voor gegevensharmonisatie nodig zullen zijn.
Hoewel data mesh niet wordt gedefinieerd door technologie, zullen in de echte wereld specifieke technische groepen eigenaar zijn van het onderliggende dataplatform, of het nu een database, data lake en/of streaming-engine is. Dat geldt ongeacht of de organisatie deze platforms on-premises implementeert of profiteert van een beheerde databaseservice in de cloud, en waarschijnlijker op beide plaatsen. Iemand moet eigenaar zijn van het onderliggende platform, en deze platforms zullen in het grote geheel ook als producten worden beschouwd.
Self-service dataplatform
Credit: Thoughtworks
Het derde principe is dat data beschikbaar moet zijn via een selfservice dataplatform zoals hierboven weergegeven. Selfservice is natuurlijk een parool geworden voor bredere gegevenstoegang, omdat het de enige manier is waarop gegevens verbruikbaar worden naarmate het gegevensdomein zich uitbreidt, aangezien IT-bronnen eindig zijn, vooral met data-engineers die zeldzaam en kostbaar zijn. Wat ze hier beschrijft moet niet worden verward met zelfbedieningsplatforms voor datavisualisatie of datawetenschappers; deze is meer voor infrastructuur- en productontwikkelaars.
Dit platform kan, wat Dehghani noemt, verschillende vlakken (of huiden) hebben die verschillende groepen beoefenaars bedienen. Voorbeelden hiervan zijn een infrastructuurvoorzieningsvlak, dat alle lelijke fysieke mechanica van het rangschikken van gegevens afhandelt (zoals het inrichten van opslag; het instellen van toegangscontroles; en de query-engine); een productontwikkelingservaring die een declaratieve interface biedt voor het beheer van de gegevenslevenscyclus; en een supervisievliegtuig dat de dataproducten beheert. Dehghani gaat veel uitgebreider in op wat een zelfbedieningsdataplatform zou moeten ondersteunen, en hier is de lijst.
Ten slotte is geen enkele benadering voor het beheren van gegevens compleet zonder governance. Dat is het vierde principe, en Dehghani noemt het federated computational governance. Dit erkent de realiteit dat er in een gedistribueerde omgeving meerdere, onderling afhankelijke dataproducten zullen zijn die moeten samenwerken, en op die manier datasoevereiniteitsmandaten en de bijbehorende regels voor dataretentie en -toegang ondersteunen. Er zal een behoefte zijn om de gegevensafstamming volledig te begrijpen en te volgen.
Een enkele post zou dit onderwerp geen recht doen. Met het risico het idee te bastaarden, betekent dit dat een federatie van dataproducten en eigenaren van dataplatformproducten een globale set regels creëert en handhaaft die van toepassing zijn op alle dataproducten en interfaces. Wat hier ontbreekt, is dat er voorzieningen moeten zijn voor het topmanagement als het gaat om bedrijfsbrede beleidslijnen en mandaten; Dehghani leidt het af (hopelijk wordt haar boek specifieker). In wezen stelt Dehghani wat vandaag de dag waarschijnlijk informele praktijk is, waar al veel ad-hocbesluitvorming over governance op lokaal niveau wordt genomen.
Federated Computational Governance
Credit: Thoughtworks
Dus zou je dit thuis moeten proberen?
Weinig onderwerpen hebben het afgelopen jaar zoveel aandacht getrokken in de datawereld als de data mesh. Een van de triggers is dat, in een steeds meer cloud-native wereld waar applicaties en bedrijfslogica worden ontleed in microservices, waarom niet gegevens op dezelfde manier behandelen?
Het antwoord is makkelijker gezegd dan gedaan. Terwijl monolithische systemen bijvoorbeeld rigide en onpraktisch kunnen zijn, introduceren gedistribueerde systemen hun eigen complexiteit, welkom of niet. Het risico bestaat dat er nieuwe silo's worden gecreëerd, om nog maar te zwijgen van chaos, wanneer lokale empowerment niet voldoende is doordacht.
Het ontwikkelen van datapijplijnen zou bijvoorbeeld deel moeten uitmaken van de definitie van een dataproduct, maar wanneer die pijplijnen elders kunnen worden hergebruikt, moet worden voorzien in dataproductteams om hun IP te delen. Anders is er veel dubbele inspanning. Dehghani roept teams op om in een gefedereerde omgeving te opereren, maar hier is het risico iemand anders te betreden.
Het distribueren van het levenscyclusbeheer van gegevens kan empowerment zijn, maar in de meeste organisaties zijn er waarschijnlijk tal van gevallen waarin het eigendom van gegevens niet duidelijk is voor scenario's waarin meerdere groepen belanghebbenden het gebruik delen of waar gegevens worden afgeleid van de gegevens van iemand anders . Dehghani erkent dit en merkt op dat domeinen doorgaans gegevens uit meerdere bronnen halen en dat op hun beurt verschillende domeinen gegevens kunnen dupliceren (en ze op verschillende manieren transformeren) voor eigen gebruik.
Data meshes als concepten zijn work in progress. In haar inleidende post verwijst Dehghani naar een belangrijke benadering om gegevens vindbaar te maken: door middel van wat zij 'zelfbeschrijvende semantiek' noemt. Maar haar beschrijving is kort, wat aangeeft dat het gebruik van “goed beschreven syntaxis”, vergezeld van voorbeeldgegevenssets en specificaties voor schema's, goede uitgangspunten zijn – voor de data-engineer, niet voor de bedrijfsanalist. Het is een punt dat we graag zouden zien in haar aanstaande boek.
Een andere belangrijke vereiste, voor gefederaliseerd “computationeel” bestuur, kan een mondvol zijn om uit te spreken, maar het zal nog meer zijn om te implementeren, zoals een blik op het bovenstaande diagram illustreert. Het lokaliseren van beslissingen zo dicht bij de bron en het globaliseren van beslissingen over interoperabiliteit zal veel vallen en opstaan vergen.
Dat gezegd hebbende, er zijn goede redenen waarom we deze discussie voeren. Er zijn verbroken verbindingen met gegevens en veel van de problemen zijn nauwelijks nieuw. Gecentraliseerde architectuur, zoals een enterprise datawarehouse, data lake of data lakehouse, kan geen recht doen in een polyglot-wereld. Aan de andere kant kunnen argumenten worden aangevoerd voor de datafabricbenadering die stelt dat een meer gecentraliseerde benadering van metadatabeheer en datadetectie efficiënter zal zijn. Er valt ook te pleiten dat een hybride benadering die gebruikmaakt van de kracht van uniform metadatabeheer van de datafabric, kan worden gebruikt als een logische backplane voor domeinen om hun dataproducten te bouwen en te bezitten.
Een ander pijnpunt is dat de processen voor het verwerken van gegevens in elke fase van de levenscyclus vaak onsamenhangend zijn, waarbij data-ingenieurs of app-ontwikkelaars die pijplijnen bouwen, gescheiden kunnen zijn van de lijnorganisaties die de gegevens dienen. Selfservice is populair geworden bij bedrijfsanalisten voor visualisatie en voor datawetenschappers bij het ontwikkelen van ML-modellen en het in productie nemen ervan. Er is een goede reden om dit uit te breiden tot het beheer van de gegevenslevenscyclus voor teams die logischerwijs de eigenaar van de gegevens zouden moeten zijn.
Maar laten we niet op de zaken vooruitlopen. Dit is zeer ambitieus spul. Als het gaat om het distribueren van het beheer en eigendom van data-assets, zoals eerder vermeld, zit de duivel in de details. En er zijn genoeg details die nog moeten worden gladgestreken. We zijn er nog niet van overtuigd dat dergelijke bottom-up benaderingen van het bezitten van gegevens zich zullen uitstrekken over het gehele datadomein van de onderneming, en dat we ons misschien meer bescheiden moeten richten: de mesh beperken tot delen van de organisatie met gerelateerde of onderling afhankelijke domeinen.< /p>
We zien verschillende berichten waarin klanten voortijdig de overwinning uitroepen. Maar zoals dit bericht aangeeft, maakt het feit dat uw organisatie een federatieve querylaag heeft geïmplementeerd of haar datameren segmenteert, de implementatie ervan nog niet tot een datamesh. Op dit moment moet het implementeren van een datamesh met al zijn gedistribueerde governance worden behandeld als proof of concept.
Big Data
Microsoft's SQL Server 2022 wordt uitgerold in private preview EDB ontketent BigAnimal in de cloud Google Cloud Volgende: Ontmoeting met de onderneming waar ze woont Microsoft verbetert haar clouddatabase-, magazijn- en lake-services Data Management | Digitale transformatie | Robotica | Internet der dingen | Innovatie | Bedrijfssoftware