Best practices voor Azure Purview-implementatie

In dit artikel worden algemene taken beschreven die u kunnen helpen bij het implementeren van Purview in productie. Deze taken kunnen in fasen worden uitgevoerd gedurende een maand of meer. Zelfs organisaties die Purview al hebben geïmplementeerd, kunnen deze handleiding gebruiken om ervoor te zorgen dat ze het meeste uit hun investering kunnen doen.

Een goed geplande implementatie van een platform voor gegevensbeheer (zoals Azure Purview) kan de volgende voordelen bieden:

• Betere gegevensdetectie
• Verbeterde analytische samenwerking
• Gemaximaliseerd rendement op investeringen.

Vereisten

• Toegang tot Microsoft Azure met een ontwikkelings- of productieabonnement
• Mogelijkheid om Azure-resources te maken, inclusief Purview
• Toegang tot gegevensbronnen zoals Azure Data Lake Storage of Azure SQL in test-, ontwikkelings- of productieomgevingen
  • Voor Data Lake Storage is De rol lezer de vereiste rol om te scannen
  • Voor SQL moet de identiteit tabellen kunnen opvragen voor steekproeven van classificaties
• Toegang tot Microsoft Defender for Cloud of de mogelijkheid om samen te werken met Defender for Cloud Admin voor gegevenslabels

Doelstellingen en doelstellingen identificeren

Veel organisaties hebben hun gegevensbeheertraject gestart door afzonderlijke oplossingen te ontwikkelen die voldoen aan specifieke vereisten van geïsoleerde groepen en gegevensdomeinen in de hele organisatie. Hoewel de ervaringen kunnen variëren afhankelijk van de branche, het product en de cultuur, vinden de meeste organisaties het lastig om consistente controles en beleidsregels voor deze typen oplossingen te handhaven.

Enkele algemene doelstellingen voor gegevensbeheer die u in de eerste fasen kunt identificeren, zijn:

• De bedrijfswaarde van uw gegevens maximaliseren
• Een gegevenscultuur mogelijk maken waarin gebruikers van gegevens eenvoudig gegevens kunnen vinden, interpreteren en vertrouwen
• Meer samenwerking tussen verschillende bedrijfseenheden om een consistente gegevenservaring te bieden
• Innovatie bevorderen door gegevensanalyses te versnellen om de voordelen van de cloud te profiteren
• Tijd verminderen om gegevens te ontdekken via selfserviceopties voor verschillende vaardigheidsgroepen
• De time-to-market verkorten voor de levering van analyseoplossingen die de service aan hun klanten verbeteren
• Het verminderen van de operationele risico's die worden veroorzaakt door het gebruik van domeinspecifieke hulpprogramma's en niet-ondersteunde technologie

De algemene aanpak is om deze overkoepelende doelstellingen op te delen in verschillende categorieën en doelstellingen. Een aantal voorbeelden:

Belangrijkste vragen die u moet stellen

Zodra uw organisatie akkoord gaat met de doelstellingen en doelstellingen op hoog niveau, zijn er veel vragen vanuit meerdere groepen. Het is van cruciaal belang om deze vragen te verzamelen om een plan te maken om alle problemen aan te pakken. Enkele voorbeeldvragen die u tijdens de eerste fase tegen kunt komen:

1. Wat zijn de belangrijkste gegevensbronnen en gegevenssystemen van de organisatie?
2. Wat zijn mijn opties voor gegevensbronnen die nog niet worden ondersteund door Purview?
3. Hoeveel Purview-exemplaren hebben we nodig?
4. Wie zijn de gebruikers?
5. Wie kunt nieuwe gegevensbronnen scannen?
6. Wie kunt u inhoud in Purview wijzigen?
7. Welk proces kan ik gebruiken om de gegevenskwaliteit in Purview te verbeteren?
8. Hoe start u het platform op met bestaande kritieke assets, woordenlijsttermen en contactpersonen?
9. Hoe kan ik integreren met bestaande systemen?
10. Hoe kan ik feedback verzamelen en een duurzaam proces bouwen?

Hoewel u mogelijk niet meteen het antwoord op de meeste van deze vragen hebt, kan het uw organisatie helpen dit project te kaderen en ervoor te zorgen dat aan alle 'must-have'-vereisten kan worden voldaan.

Neem de juiste belanghebbenden op

Om ervoor te zorgen dat Purview voor de hele onderneming kan worden geïmplementeerd, is het belangrijk om de juiste belanghebbenden erbij te betrekken. Slechts enkele personen zijn betrokken bij de eerste fase. Naarmate het bereik echter wordt uitgebreid, hebt u extra persona's nodig om bij te dragen aan het project en feedback te geven.

Enkele belangrijke belanghebbenden die u mogelijk wilt opnemen:

Belangrijke scenario's identificeren

Purview kan worden gebruikt voor het centraal beheren van gegevensgovernance in de gegevensomgevingen van een organisatie die cloud- en on-premises omgevingen beslaat. Voor een geslaagde implementatie moet u belangrijke scenario's identificeren die essentieel zijn voor het bedrijf. Deze scenario's kunnen bedrijfseenheidgrenzen overschrijden of van invloed zijn op meerdere persona's van gebruikers, upstream of downstream.

Deze scenario's kunnen op verschillende manieren worden geschreven, maar u moet ten minste deze vijf dimensies opnemen:

1. Persona: Wie zijn de gebruikers?
2. Bronsysteem: wat zijn de gegevensbronnen, zoals Azure Data Lake Storage Gen2 of Azure SQL Database?
3. Impactgebied: wat is de categorie van dit scenario?
4. Detailscenario's: hoe gebruiken de gebruikers Purview om problemen op te lossen?
5. Verwacht resultaat: wat zijn de succescriteria?

De scenario's moeten specifiek, uitvoerbaar en uitvoerbaar zijn met meetbare resultaten. Enkele voorbeeldscenario's die u kunt gebruiken:

Implementatiemodellen

Als u slechts één kleine groep hebt die gebruik maakt van Purview met gebruiksgevallen voor basisverbruik, kan de aanpak net zo eenvoudig zijn als het hebben van één exemplaar van Purview om de hele groep te servicen. U kunt zich echter ook afvragen of uw organisatie meer dan één Purview-exemplaar nodig heeft. En als u meerdere Purview-instanties gebruikt, hoe kunnen werknemers de assets dan van de ene fase naar de andere promoveren.

Het aantal Purview-exemplaren bepalen

In de meeste gevallen mag er slechts één Purview-account voor de hele organisatie zijn. Deze aanpak maakt maximaal gebruik van de 'netwerkeffecten' waarbij de waarde van het platform exponentieel toeneemt als een functie van de gegevens die zich in het platform bevinden.

Er zijn echter uitzonderingen op dit patroon:

1. Nieuwe configuraties testen: organisaties willen mogelijk meerdere exemplaren maken voor het testen van scanconfiguraties of -classificaties in geïsoleerde omgevingen. Hoewel er op sommige gebieden van het platform een functie voor versieverlening is, zoals een woordenlijst, is het eenvoudiger om een 'eenmalig' exemplaar vrij te testen.
2. Testen, preproductie en productie scheiden: organisaties willen verschillende platforms maken voor verschillende soorten gegevens die zijn opgeslagen in verschillende omgevingen. Dit wordt niet aanbevolen omdat dit soort gegevens verschillende inhoudstypen zijn. U kunt woordenlijsttermen op het hoogste hiërarchieniveau of categorie gebruiken om inhoudstypen te scheiden.
3. Conglomeraten en federatief model: conglomeraten hebben vaak veel bedrijfseenheden (BE's) die afzonderlijk worden gebruikt, en in sommige gevallen delen ze de facturering niet eens met elkaar. In dergelijke gevallen zal de organisatie uiteindelijk een Purview-exemplaar maken voor elke BU. Dit model is niet ideaal, maar kan noodzakelijk zijn, met name omdat BE's vaak niet bereid zijn om facturering te delen.
4. Naleving: er zijn enkele strikte nalevingsbibliotheken die zelfs metagegevens als gevoelig behandelen en vereisen dat ze zich in een specifieke geografie hebben. Als een bedrijf meerdere geografische gebieden heeft, is de enige oplossing om meerdere purview-instanties te hebben, één voor elke geografie.

Een proces maken om naar productie over te gaan

Sommige organisaties kunnen besluiten om het eenvoudig te houden door met één productieversie van Purview te werken. Ze hoeven waarschijnlijk niet verder te gaan dan detectie-, zoek- en bladerscenario's. Als sommige assets onjuiste woordenlijsttermen hebben, is het erg belangrijk om mensen zichzelf te laten corrigeren. De meeste organisaties die Purview in verschillende bedrijfseenheden willen implementeren, willen echter een vorm van proces en controle hebben.

Een ander belangrijk aspect dat u in uw productieproces moet opnemen, is de manier waarop classificaties en labels kunnen worden gemigreerd. Purview heeft meer dan 90 systeemclassificatoren. U kunt systeem- of aangepaste classificaties toepassen op bestands-, tabel- of kolomactiva. Classificaties zijn net als onderwerptags en worden gebruikt om inhoud van een specifiek type te markeren en te identificeren die tijdens het scannen in uw gegevens estate is gevonden. Gevoeligheidslabels worden gebruikt om de categorieën classificatietypen binnen uw organisatiegegevens te identificeren en vervolgens de beleidsregels te groeperen die u op elke categorie wilt toepassen. Het maakt gebruik van dezelfde gevoelige informatietypen als Microsoft 365, zodat u uw bestaande beveiligingsbeleid en beveiliging kunt uitstrekken over uw hele inhoud en gegevens. Het kan documenten scannen en automatisch classificeren. Als u bijvoorbeeld een bestand met de naam multiple.docx en het een nationale id-nummer in de inhoud heeft, voegt Purview classificatie toe, zoals het Nationale identificatienummer van de EU op de pagina Activumdetails.

In Purview zijn er verschillende gebieden waar de catalogusbeheerders moeten zorgen voor consistentie en best practices voor onderhoud gedurende de levenscyclus:

• Gegevensactiva: gegevensbronnen moeten opnieuw worden gescand in omgevingen. Het is niet raadzaam om alleen in ontwikkeling te scannen en ze vervolgens opnieuw te maken met behulp van API's in Productie. De belangrijkste reden is dat de Purview-scanners achter de schermen veel meer 'bedrading' op de gegevensactiva doen, wat ingewikkeld kan zijn om ze naar een ander Purview-exemplaar te verplaatsen. Het is veel eenvoudiger om dezelfde gegevensbron in productie toe te voegen en de bronnen opnieuw te scannen. De algemene best practice is dat u documentatie hebt over alle scans, verbindingen en verificatiemechanismen die worden gebruikt.
• Regelsets scannen: dit is uw verzameling regels die zijn toegewezen aan een specifieke scan, zoals het bestandstype en classificaties die moeten worden gedetecteerd. Als u niet zoveel scanregelsets hebt, is het mogelijk om ze handmatig opnieuw te maken via Productie. Hiervoor is een intern proces en goede documentatie vereist. Als u regelsets echter dagelijks of wekelijks wijzigt, kan dit worden verholpen door de route REST API verkennen.
• Aangepaste classificaties: uw classificaties worden mogelijk niet regelmatig gewijzigd. Tijdens de eerste implementatiefase kan het enige tijd duren om inzicht te krijgen in de verschillende vereisten voor het maken van aangepaste classificaties. Zodra dit is opgelost, is er echter weinig verandering nodig. Het wordt daarom aanbevolen om aangepaste classificaties handmatig te migreren via of de REST API.
• Verklarende woordenlijst: het is mogelijk om woordenlijsttermen te exporteren en te importeren via de UX. Voor automatiseringsscenario's kunt u ook de REST API.
• Beleidsregels voor resourcesetpatronen: deze functionaliteit is zeer geavanceerd voor elke typische organisatie om toe te passen. In sommige gevallen heeft uw Azure Data Lake Storage naamconventy's voor mappen en een specifieke structuur die problemen kunnen veroorzaken voor Purview om de resourceset te genereren. Uw bedrijfseenheid kan ook de constructie van de resourceset wijzigen met aanvullende aanpassingen om aan de bedrijfsbehoeften te voldoen. Voor dit scenario kunt u het beste alle wijzigingen bijhouden via REST API en de wijzigingen documenteren via een extern versieplatform.
• Roltoewijzing: hier kunt u bepalen wie toegang heeft tot Purview en welke machtigingen ze hebben. Purview heeft ook REST API ondersteuning voor het exporteren en importeren van gebruikers en rollen, maar dit is niet compatibel met atlas-API. Het wordt aanbevolen om een Azure-beveiligingsgroep toe te wijzen en in plaats daarvan het groepslidmaatschap te beheren.

Verschillende integratiepunten plannen en implementeren met Purview

Het is waarschijnlijk dat een volwassen organisatie al een bestaande gegevenscatalogus heeft. De belangrijkste vraag is of u de bestaande technologie wilt blijven gebruiken en wilt synchroniseren met Purview of niet. Als u synchronisatie met bestaande producten in een organisatie wilt afhandelen, biedt Purview Atlas REST API's. Atlas-API's bieden een krachtig en flexibel mechanisme voor het afhandelen van zowel push- als pull-scenario's. Informatie kan worden gepubliceerd naar Purview met behulp van Atlas-API's voor bootstrapping of om de meest recente updates van een ander systeem naar Purview te pushen. De informatie die beschikbaar is in Purview kan ook worden gelezen met behulp van Atlas-API's en vervolgens weer worden gesynchroniseerd met bestaande producten.

Voor andere integratiescenario's, zoals ticketing, aangepaste gebruikersinterface en orchestration, kunt u Atlas-API's en Kafka-eindpunten gebruiken. Over het algemeen zijn er vier integratiepunten met Purview:

• Gegevensactivum: hiermee kan Purview de assets van een winkel scannen om te inventariseren wat deze assets zijn en eventuele direct beschikbare metagegevens over deze assets te verzamelen. Dit kan SQL een lijst met TB's, tabellen, opgeslagen procedures, weergaven en configuratiegegevens zijn die worden bewaard op plaatsen zoals sys.tables . Voor bijvoorbeeld Azure Data Factory (ADF) kan dit het opsnoemen van alle pijplijnen zijn en het verkrijgen van gegevens op het moment dat ze zijn gemaakt, de laatste keer dat ze zijn uitgevoerd, de huidige status.
• Gegevensvereeding: hiermee kan Purview informatie verzamelen van een analyse-/gegevensanalysesysteem over de manier waarop gegevens worden verplaatst. Voor iets als Spark kan dit gegevens verzamelen van de uitvoering van een notebook om te zien welke gegevens het notebook heeft opgenomen, hoe deze zijn getransformeerd en waar ze zijn uitgevoerd. Voor iets zoals SQL kan het querylogboeken analyseren om te reverse engineeren welke operationele bewerkingen zijn uitgevoerd en wat ze hebben gedaan. Afhankelijk van de behoeften ondersteunen we zowel push- als pull-gebaseerde vereeniging.
• Classificatie: hiermee kan Purview fysieke steekproeven nemen uit gegevensbronnen en deze uitvoeren via ons classificatiesysteem. Het classificatiesysteem becijfert de semantiek van een stukje gegevens. We weten bijvoorbeeld dat een bestand een Parquet-bestand is en drie kolommen heeft en de derde een tekenreeks. Maar de classificaties die we op de voorbeelden uitvoeren, geven aan dat de tekenreeks een naam, adres of telefoonnummer is. Door dit integratiepunt te ontsteken, hebben we gedefinieerd hoe Met Purview objecten zoals notebooks, pijplijnen, parquet-bestanden, tabellen en containers kunnen worden geopend.
• Ingesloten ervaring: producten met een 'studio'-ervaring (zoals ADF, Synapse, SQL Studio, PBI en Dynamics) willen gebruikers meestal in staat stellen om gegevens te ontdekken waarmee ze willen communiceren en ook locaties om gegevens uit te geven. De catalogus van Purview kan helpen deze ervaringen te versnellen door een insluitervaring te bieden. Deze ervaring kan optreden op API- of UX-niveau bij de optie van de partner. Door een aanroep van Purview in tesluiten, kan de organisatie profiteren van de kaart van De gegevens in Purview om gegevensactiva te vinden, gegevensgegevens te bekijken, schema's te controleren, beoordelingen, contactpersonen enzovoort te bekijken.

Fase 1: Pilot

In deze fase moet Purview worden gemaakt en geconfigureerd voor een zeer kleine groep gebruikers. Meestal is het slechts een groep van 2-3 personen die samenwerken om end-to-end-scenario's uit te voeren. Ze worden beschouwd als de advocates van Purview in hun organisatie. Het belangrijkste doel van deze fase is ervoor te zorgen dat aan belangrijke functies kan worden voldaan en dat de juiste belanghebbenden op de hoogte zijn van het project.

Taken die moeten worden voltooid

Acceptatiecriteria

• Het account Purview is gemaakt in het organisatieabonnement onder de tenant van de organisatie.
• Een kleine groep gebruikers met meerdere rollen heeft toegang tot Purview.
• Purview is geconfigureerd om ten minste één gegevensbron te scannen.
• Gebruikers moeten sleutelwaarden van Purview kunnen extraheren, zoals:
  • Zoeken en bladeren
  • Herkomst
• Gebruikers moeten het eigendom van activa kunnen toewijzen op de assetpagina.
• Presentatie en demo om de belangrijkste belanghebbenden onder de aandacht te brengen.
• Inkopen van beheer om aanvullende resources voor de MVP-fase goed te keuren.

Fase 2: Minimum viable product

Zodra u de overeengekomen vereisten hebt en bedrijfseenheden hebt deelgenomen om Purview te onboarden, is de volgende stap het werken aan een Minimum Viable Product-release (MVP). In deze fase breidt u het gebruik van Purview uit voor meer gebruikers die horizontaal en verticaal extra behoeften hebben. Er zijn belangrijke scenario's die horizontaal moeten worden bereikt voor alle gebruikers, zoals woordenlijsttermen, zoeken en bladeren. Er zijn ook verticale vereisten voor elke bedrijfseenheid of groep om specifieke end-to-end-scenario's te behandelen, zoals de gegevens van Azure Data Lake Storage naar Azure Synapse DW naar Power BI.

Taken die moeten worden voltooid

Acceptatiecriteria

• Onboarding van een grotere groep gebruikers naar Purview (50+)
• Bedrijfskritieke gegevensbronnen scannen
• Alle kritieke woordenlijsttermen importeren en toewijzen
• Belangrijke labels voor sleutelactiva testen
• Met succes voldaan aan minimale scenario's voor de gebruikers van de deelnemende bedrijfseenheden

Fase 3: preproductie

Zodra de MVP-fase is verstreken, is het tijd om de mijlpaal vóór de productie te plannen. Uw organisatie kan besluiten om een afzonderlijk exemplaar van Purview te hebben voor preproductie en productie, of om hetzelfde exemplaar te behouden, maar de toegang te beperken. In deze fase wilt u mogelijk ook scannen op on-premises gegevensbronnen, zoals SQL Server. Als er sprake is van een hiaat in gegevensbronnen die niet worden ondersteund door Purview, is het tijd om de Atlas-API te verkennen om inzicht te krijgen in aanvullende opties.

Taken die moeten worden voltooid

Acceptatiecriteria

• Onboarding van ten minste één bedrijfseenheid met alle gebruikers is geslaagd
• On-premises gegevensbron scannen, zoals SQL Server
• POC ten minste één integratiescenario met behulp van REST API
• Voltooi een plan om naar productie te gaan, met belangrijke gebieden op het gebied van infrastructuur en beveiliging

Fase 4: Productie

De bovenstaande fasen moeten worden gevolgd om een effectieve informatiegovernance te maken. Dit is de basis voor betere governanceprogramma's. Met gegevensbeheer kan uw organisatie zich voorbereiden op de groeiende trends, zoals AI, Hadoop, IoT en blockchain. Het is slechts het begin voor veel gegevens en analyses en er kan nog veel meer worden besproken. Het resultaat van deze oplossing zou het volgende opleveren:

• Bedrijfsgericht: een oplossing die is afgestemd op zakelijke vereisten en scenario's ten opzichte van technische vereisten.
• Gereed voor de toekomst: een oplossing maximaliseert de standaardfuncties van het platform en maakt gebruik van gestandaardiseerde brancheprocedures voor configuratie- of scriptactiviteiten ter ondersteuning van de voortgang/ontwikkeling van het platform.

Taken die moeten worden voltooid

Acceptatiecriteria

• Onboarding van alle bedrijfseenheden en hun gebruikers is geslaagd
• Voldoen aan infrastructuur- en beveiligingsvereisten voor productie
• Voldoen aan alle use cases die de gebruikers nodig hebben

Platformverharding

U kunt extra maatregelen nemen:

• Verhoog de beveiligingsstatus door het inschakelen van scan op firewallbronnen of het gebruik van Private Link
• Bereikscan afstemmen om scanprestaties te verbeteren
• REST API's gebruiken om kritieke metagegevens en eigenschappen voor back-up en herstel te exporteren
• Werkstroom gebruiken om ticketing en gebeurtenissen te automatiseren om menselijke fouten te voorkomen

Volgende stappen

• Best practices voor verzamelingen
• Naar de startpagina navigeren en een asset zoeken