De “bruikbare” metadata – DATAVERSITY

Klik voor meer informatie over auteur
Anand Govindarajan.

Tijdens de dagen van het bouwen van datawarehouses en BI-systemen, was alles dat werd vastgelegd, als echte “metadata”, de gegevens over het aanmaken / openen van de datastructuren voor audits, gegevens over de uitvoering van het laden van gegevens, enzovoort. In de eerste plaats, wat de “operaties” van het datawarehouse ondersteunde. Tijdens de datamodelleringfase werd de beschrijving van de entiteiten vastgelegd in de modelleringstool om te helpen bij de discussies, maar toen het model eenmaal was goedgekeurd en geïmplementeerd, nam niemand echt de moeite om het up-to-date te houden.

Sommige van deze beschrijvingen gingen naar de fysieke kolommen, aangezien de meeste databaseproducten opmerkingen voor de fysieke structuren ondersteunen. Vervolgens werden pogingen ondernomen om de fysieke gegevensstructuurdetails in een portaal te reverse-engineeren en te publiceren om het ontwerpen van de ETL-jobmakers te vergemakkelijken en voor de BI-teams om het magazijn te bevragen voor het genereren van rapporten. Dit waren de echte fundamenten van het vastleggen van respectievelijk ‘operationele’, ‘zakelijke’ en ‘technische’ metagegevens, die meer een passieve rol speelden bij de ondersteuning van de infrastructuur dan alles wat uitvoerbaar was.

Ik heb me nooit gerealiseerd dat op een dag hetzelfde metadata zou zo “krachtig” en “uitvoerbaar” worden als de gegevens die erin worden beschreven. Zonder deze metadata verliezen zelfs de gegevens die het beschrijft hun kracht, aangezien er geen echte “context” voor die gegevens is. Het implementeren van Data Governance-initiatieven voor mijn klanten in de afgelopen vijf jaar heeft dit besef alleen maar vergroot.

Laat me delen in deze agenda wat sommige van deze echte “acties” zijn gebaseerd op deze implementatie ervaringen terwijl we ingaan op de details van “hoe” in de volgende blogs.

De onderstaande tabel geeft een overzicht van enkele van de “acties” die verschillende soorten metadata kunnen aansturen.

Gegevensgeletterdheid: Met de toenemende behoefte voor gebruikers om de gegevens die ze gebruiken uit verschillende datameren en datastores te “vinden” en te “begrijpen”, worden de zakelijke metadata die deze gegevens beschrijven bijzonder belangrijk. Datacatalogi bieden deze geletterdheid en taggen alle inhoud met de juiste woordenlijstelementen – vastgelegd door samenwerking of door autotagging via ML-algoritmen.

Gegevensbescherming: Organisaties worden steeds vaker geconfronteerd met de uitdaging om te voldoen aan gegevensprivacy- en beschermingsregels zoals de AVG, CCPA, enzovoort. Dataclassificatie-algoritmen sturen deze gevoelige data-identificatie aan en taggen de inhoud met zakelijke metadata, zoals de PII-tags. Organisaties kunnen deze metagegevens vervolgens gebruiken om verschillende toegangsbeleidsregels voor de gegevens aan te sturen.

Gegevensredundantiecontrole: Hoe belangrijk het opbouwen van vertrouwen in gegevens ook is, er is behoefte aan verbetering van de efficiëntie in Gegevensbeheer om de flexibiliteit die het bedrijf nodig heeft uit de data-infrastructuur te halen. Het elimineren van gegevensredundanties als gevolg van oudere praktijken is een manier om dit te doen. De zakelijke metagegevens die aan de gegevens zijn getagd, zijn een ander middel om overtolligheden te identificeren.

Analytics-beheer: Een van de belangrijkste aandachtsgebieden in organisaties is ervoor te zorgen dat de consumenten van analyses betrouwbare inhoud zien die ze kunnen gebruiken om zakelijke beslissingen te nemen. Technische metadata veroverd op de gegevensbronnen op de rapportage / analytics platforms kunnen aan elkaar worden gekoppeld aan de gegevens herkomst te begrijpen en daarmee de kwaliteit van de output. Dit kan concepten zoals “rapportcertificering” stimuleren die het vertrouwen in de uiteindelijke inhoud die wordt geconsumeerd, vergroten.

Data Provenance en impactanalyse: Zoals hierboven beschreven, kunnen de technische metadata van verschillende platforms met elkaar worden verbonden en kunnen ze de platformontwikkelingsteams helpen de impact van de veranderingen te begrijpen. Wat gebeurt er bijvoorbeeld als de structuur van een tabel in een gegevensbron wordt gewijzigd? Wat zijn de gevolgen voor alle rapporten? Wat is de impact als het data-integratieplatform moet worden gemigreerd?

Ontwikkelingsnormen: Technische metadata van rapportageplatforms zoals de SQL’s zijn ingebed in de rapportages; die van data-integratieplatforms kunnen wijzen op slechte programmeerpraktijken. Die kunnen vervolgens worden gebruikt om de ontwikkeling van ontwikkelingsnormen te stimuleren om de efficiëntie te vergroten.

Fraudeanalyse: Systeemtoegangslogboeken zijn een geweldige bron van informatie om frauduleuze transacties te begrijpen. Evenzo leveren metadata rond e-mailuitwisselingen tussen partijen nuttige input om hun rol bij frauduleuze activiteiten te begrijpen.

Infrastructuuronderhoud: Logboeken die het gebruik van bronnen van verschillende toepassingen en processen bieden, fungeren als een belangrijke input voor het onderhoud van de infrastructuur. De datapunten kunnen zelfs in een machine learning-algoritme worden ingevoerd om mogelijke storingen te voorspellen en het zogenaamde “preventieve onderhoud” van deze servers aan te sturen.

Gebruiksanalyse: Terwijl organisaties hun analyseplatform willen moderniseren, helpen inputs zoals de meest gebruikte rapporten, databronnen, enz. De objecten die gemigreerd worden van het oudere naar het nieuwe platform te rationaliseren, in plaats van alles blindelings over te dragen van het oude naar het nieuwe platform.

follow:
Jernst van Veen

Jernst van Veen

Related Posts