Osvědčené postupy nasazení Azure Purview

Tento článek popisuje běžné úlohy, které vám můžou pomoct nasadit Purview do produkčního prostředí. Tyto úkoly je možné provádět ve fázích v průběhu měsíce nebo déle. Dokonce i organizace, které už Purview nasadily, mohou tuto příručku využít k zajištění maximálního využití svých investic.

Dobře naplánované nasazení platformy zásad správného řízení dat (například Azure Purview) může poskytnout následující výhody:

• Lepší zjišťování dat
• Vylepšená analytická spolupráce
• Maximalizovaná návratnost investic.

Požadavky

• Přístup k Microsoft Azure pomocí vývojového nebo produkčního předplatného
• Schopnost vytvářet prostředky Azure včetně Purview
• Přístup ke zdrojům dat, jako je Azure Data Lake Storage nebo Azure SQL v testovacím, vývojovém nebo produkčním prostředí
  • Pro Data Lake Storage je požadovanou rolí, kterou je potřeba zkontrolovat, role čtenáře.
  • V SQL musí být identita schopná dotazovat se tabulek na vzorkování klasifikací.
• Přístup k Microsoft Defenderu pro cloud nebo možnost spolupráce s Defenderem for Cloud Admin na označování dat

Identifikace cílů a cílů

Mnoho organizací zahájilo cestu k řízení dat tím, že vyvíjely jednotlivá řešení, která splňují specifické požadavky izolovaných skupin a datových domén v celé organizaci. I když se prostředí můžou lišit v závislosti na odvětví, produktu a kulturě, pro většinu organizací je obtížné zachovat konzistentní kontroly a zásady pro tyto typy řešení.

Mezi běžné cíle zásad správného řízení dat, které byste mohli chtít identifikovat v počátečních fázích, patří:

• Maximalizace obchodní hodnoty vašich dat
• Povolení datové kultury, ve které spotřebiteli dat snadno najdou, interpretují a důvěřují datům
• Zvýšení spolupráce mezi různými obchodními jednotkami za poskytování konzistentního prostředí pro data
• Podpora inovací zrychlením analýz dat, aby bylo možno využívat výhod cloudu
• Zkušení doba zjišťování dat prostřednictvím samoobslužných možností pro různé skupiny dovedností
• Zkrácení doby dodání analytického řešení, která vylepšují služby zákazníkům, na trh
• Snížení provozních rizik způsobených používáním nástrojů specifických pro doménu a nepodporovaných technologií

Obecným přístupem je rozdělit tyto zaoceující cíle do různých kategorií a cílů. Tady je několik příkladů:

Nejčastější dotazy

Jakmile se vaše organizace shodne na hlavních cílech a cílech, bude mnoho otázek od více skupin. Tyto otázky je nezbytné shromáždit, aby bylo možné vytvořit plán, který řeší všechny tyto obavy. Několik příkladů otázek, na které můžete naběhat během počáteční fáze:

1. Jaké jsou hlavní zdroje dat organizace a datové systémy?
2. Jaké mám možnosti u zdrojů dat, které Purview ještě nepodporuje?
3. Kolik instancí Purview potřebujeme?
4. Kdo jsou uživatelé?
5. Kdo můžete kontrolovat nové zdroje dat?
6. Kdo můžete upravovat obsah uvnitř Purview?
7. Jaký proces můžu použít ke zlepšení kvality dat v Purview?
8. Jak použít platformu s existujícími důležitými prostředky, termíny glosáře a kontakty?
9. Jak se integrovat se stávajícími systémy?
10. Jak shromáždit zpětnou vazbu a vytvořit udržitelné procesy?

I když na většinu těchto otázek pravděpodobně nemáte odpověď hned, může to vaší organizaci pomoct tento projekt vytvořit a zajistit, aby bylo možné splnit všechny požadavky "nutné".

Zahrnout správné účastníky

Pokud chcete zajistit úspěšnou implementaci Purview pro celý podnik, je důležité zapojit správné účastníky. Do počáteční fáze se zapojuje jenom několik lidí. Jak se ale rozsah bude rozšiřovat, budete k přispívání do projektu a poskytnutí zpětné vazby vyžadovat další osoby.

Mezi klíčové účastníky, které byste měli zahrnout:

Identifikace klíčových scénářů

Purview se používá k centrální správě zásad správného řízení dat v rámci datových majetku organizace, která se používají v cloudových a místních prostředích. Pokud chcete zajistit úspěšnou implementaci, musíte identifikovat klíčové scénáře, které jsou pro firmu klíčové. Tyto scénáře mohou překročit hranice obchodních jednotek nebo ovlivnit více uživatelů, a to buď upstreamu, nebo podřízeného uživatele.

Tyto scénáře je možné vytvořit různými způsoby, ale měli byste zahrnout alespoň tyto pět dimenzí:

1. Persona – Kdo jsou uživatelé?
2. Zdrojový systém – Jaké jsou zdroje dat, jako je Azure Data Lake Storage Gen2 nebo Azure SQL Database?
3. Oblast dopadu – Jaká je kategorie tohoto scénáře?
4. Podrobné scénáře – jak uživatelé používají Purview k řešení problémů?
5. Očekávaný výsledek – jaká jsou kritéria úspěchu?

Scénáře musí být konkrétní, použitelné a spustitelné s měřitelnými výsledky. Některé příklady scénářů, které můžete použít:

Modely nasazení

Pokud máte pouze jednu malou skupinu využívající Purview se základními případy použití spotřeby, může být tento přístup jednoduchý, například mít jednu instanci Purview pro správu celé skupiny. Může vás ale také zajímat, jestli vaše organizace potřebuje více než jednu instanci Purview. A pokud používáte více instancí Purview, jak mohou zaměstnanci propagovat prostředky z jedné fáze do druhé.

Určení počtu instancí Purview

Ve většině případů by pro celou organizaci měl být jenom jeden účet Purview. Tento přístup využívá co největší výhody "síťových efektů", kdy se hodnota platformy exponenciálně zvyšuje jako funkce dat, která se nacházejí uvnitř platformy.

Existují však výjimky z tohoto modelu:

1. Testování nových konfigurací – Organizace mohou chtít vytvořit více instancí pro testování konfigurací nebo klasifikací kontroly v izolovaných prostředích. I když v některých oblastech platformy existuje funkce "správu verzí", jako je glosář, bylo by jednodušší mít "jednorázovou" instanci, která by mohla volně testovat.
2. Oddělení testování, předprodukce a produkce – Organizace chtějí vytvářet různé platformy pro různé druhy dat uložených v různých prostředích. Nedoporučuje se, protože tyto druhy dat jsou různé typy obsahu. K oddělení typů obsahu můžete použít termín glosáře na nejvyšší úrovni hierarchie nebo kategorii.
3. Conglomerates a federovaný model – Conglomerates mají často mnoho obchodních jednotek (BU), které fungují samostatně, a v některých případech dokonce nebudou ani sdílet fakturaci mezi sebou. V těchto případech organizace vytvoří instanci Purview pro každou obchodní instanci. Tento model není ideální, ale může být nezbytný, zejména proto, že BU často nejsou ochotni sdílet fakturaci.
4. Dodržování předpisů – Existují některé striktní předpisy dodržování předpisů, které s metadaty zachází jako s citlivými a vyžadují, aby byla v konkrétní geografické oblasti. Pokud má společnost více zeměpisných lokalit, jediným řešením je mít několik instancí Purview, jednu pro každou zeměpisnou oblast.

Vytvoření procesu přechodu do produkčního prostředí

Některé organizace se mohou rozhodnout, že vše pro jednoduchost zpracují s jedinou produkční verzí Purview. Pravděpodobně nemusí jít nad rámec scénářů zjišťování, vyhledávání a procházení. Pokud některé prostředky mají nesprávné termíny glosáře, je docela užitečné nechat lidi, aby se opraví. Většina organizací, které chtějí nasadit Purview napříč různými obchodními jednotkami, ale bude chtít nějakou formu procesu a řízení.

Dalším důležitým aspektem, který je třeba zahrnout do produkčního procesu, je způsob migrace klasifikací a popisků. Purview má více než 90 systémových klasifikátorů. Systémové nebo vlastní klasifikace můžete použít u prostředků souborů, tabulek nebo sloupců. Klasifikace se jako značky předmětu používají k označení a identifikaci obsahu konkrétního typu, který se během prohledávání nachází ve vašich datových majetekch. Popisky citlivosti slouží k identifikaci kategorií typů klasifikace v datech organizace a pak seskupují zásady, které chcete použít pro každou kategorii. Používá stejné typy citlivých informací jako Microsoft 365, což vám umožní roztáhnout stávající zásady zabezpečení a ochranu napříč celým obsahem a datovými majetek. Může kontrolovat a automaticky klasifikovat dokumenty. Pokud máte například soubor s názvem multiple.docx, který má v obsahu národní ID, Purview přidá na stránku Podrobnosti o aktivech klasifikaci, jako je národní identifikační číslo EU.

V Purview existuje několik oblastí, kde správci katalogu potřebují zajistit konzistenci a osvědčené postupy údržby v průběhu životního cyklu:

• Datové assety – Zdroje dat bude potřeba znovu prohledovat v různých prostředích. Nedoporučuje se kontrolovat jenom ve vývoji a pak je znovu vygenerovat pomocí rozhraní API v produkčním prostředí. Hlavním důvodem je to, že skenery Purview prochová na pozadí mnohem více "propojení" datových prostředků, což může být složité, když je přesunou do jiné instance Purview. Je mnohem jednodušší přidat stejný zdroj dat do produkčního prostředí a znovu je zkontrolovat. Obecným osvědčeným postupem je mít dokumentaci ke všem použitým kontrolám, připojením a ověřovacím mechanismům.
• Sady pravidel prohledávání – jedná se o kolekci pravidel přiřazených ke konkrétní skenu, jako je například typ souboru a klasifikace, které se má zjistit. Pokud nemáte tolik sad pravidel prohledávání, můžete je znovu ručně znovu vytvořit prostřednictvím produkčního prostředí. To bude vyžadovat interní proces a dobrou dokumentaci. Pokud se ale sady pravidel mění každý den nebo týdně, můžete to vyřešit prozkoumáváním REST API trasy.
• Vlastní klasifikace – Vaše klasifikace se také nemusí pravidelně měnit. V počáteční fázi nasazení může nějakou dobu trvat, než pochopíte různé požadavky na vlastní klasifikace. Jakmile se ale uspořádá, bude to vyžadovat jen malou změnu. Tady se proto doporučujeme ručně migrovat všechny vlastní klasifikace přes nebo použít REST API.
• Glosář – Termíny glosáře je možné exportovat a importovat prostřednictvím uživatelského rozhraní. Pro scénáře automatizace můžete také použít REST API.
• Zásady vzorů sady prostředků – Tato funkce je velmi pokročilá pro všechny typické organizace. V některých případech má vaše služba Azure Data Lake Storage zásady vytváření názvů složek a specifickou strukturu, které mohou způsobit problémy s generováním sady prostředků purview. Vaše obchodní jednotka může také chtít změnit konstrukci sady prostředků s dalšími úpravami tak, aby vyhovovala obchodním potřebám. V tomto scénáři je nejlepší sledovat všechny změny prostřednictvím REST API a dokumentovat změny prostřednictvím externí platformy pro versioning.
• Přiřazení role – tady můžete řídit, kdo má přístup k Purview a která oprávnění má. Purview také REST API podporu exportu a importu uživatelů a rolí, ale není kompatibilní s rozhraním Atlas API. Doporučujeme místo toho přiřadit skupinu zabezpečení Azure a spravovat členství ve skupině.

Plánování a implementace různých bodů integrace pomocí Purview

Je pravděpodobné, že vyspělá organizace už má existující katalog dat. Klíčovou otázkou je, jestli pokračovat v používání stávající technologie a synchronizovat s Purview, nebo ne. Pro synchronizaci se stávajícími produkty v organizaci poskytuje Purview rozhraní Atlas REST API. Rozhraní Atlas API poskytují výkonný a flexibilní mechanismus pro scénáře nabízení a přetáování. Informace je možné publikovat do Purview pomocí rozhraní Atlas API pro zavádění nebo k nabízení nejnovějších aktualizací z jiného systému do Purview. Informace dostupné v Purview si také můžete přečíst pomocí rozhraní Atlas API a pak je synchronizovat zpět do existujících produktů.

Pro další scénáře integrace, jako je lístkování, vlastní uživatelské rozhraní a orchestrace, můžete použít rozhraní Atlas API a koncové body Kafka. Obecně platí, že purview má čtyři body integrace:

• Datový asset – Purview tak může prohledat prostředky obchodu, aby mohl zobrazit výčet toho, co jsou tyto prostředky, a shromažďovat o nich snadno dostupná metadata. Například SQL seznam databáze, tabulek, uložených procedur, zobrazení a konfiguračních dat o nich uchovávané na místech, jako je sys.tables . Například u Azure Data Factory (ADF) to může být vytvoření výčtu všech kanálů a získávání dat při jejich vytvoření, posledním spuštění a aktuálním stavu.
• Lineage –To umožňuje Purview shromažďovat informace ze systému analýzy nebo mutace dat o tom, jak se data pohybují. U něčeho jako Spark by to mohlo být shromažďování informací ze spuštění poznámkového bloku, aby bylo možné zobrazit, jaká data poznámkový blok ingestoval, jak je transformoval a kam je výstupem. Například v SQL může být analýza protokolů dotazů, která zpětně analyzuje, jaké mutační operace byly provedeny a co dělají. V závislosti na potřebách podporujeme jak na základě nabízení, tak na základě vyžádané tažení.
• Klasifikace – Purview tak může vzít fyzické vzorky ze zdrojů dat a spustit je prostřednictvím našeho klasifikačního systému. Klasifikační systém vyhodnotí sémantiku částí dat. Můžeme například zjistit, že soubor je soubor Parquet a má tři sloupce a třetí druhý je řetězec. Klasifikátory, které na ukázkách spouštíme, nám sdělí, že řetězec je jméno, adresa nebo telefonní číslo. Rozsvícení tohoto integračního bodu znamená, že jsme definovali, jak může dosah otevřít objekty, jako jsou poznámkové bloky, kanály, soubory Parquet, tabulky a kontejnery.
• integrované prostředí – produkty, které mají zkušenosti, jako je například ADF, Synapse, SQL studio, PBI a Dynamics), obvykle chtějí uživatelům umožnit zjišťování dat, se kterými chtějí pracovat, a také najít místa pro výstupní data. Katalog dosah vám může přispět k urychlení těchto prostředí tím, že poskytuje prostředí pro vkládání. K tomuto prostředí může dojít v rozhraní API nebo na úrovni uživatelského rozhraní na možnosti partnera. Když zaškrtnete volání dosah, může organizace využít mapu prvků dosah na datové assety a najít datové assety. Projděte si informace o prostředcích, kontrolách schémat, Prohlédněte si hodnocení, kontakty atd.

Fáze 1: pilotní nasazení

V této fázi je třeba vytvořit dosah a nakonfigurovat pro velmi malou skupinu uživatelů. Obvykle se jedná o skupinu 2-3 lidí, které pracují dohromady, aby běžely prostřednictvím koncových scénářů. Považují se za poradce dosah ve své organizaci. Hlavním cílem této fáze je zajistit, aby bylo možné splnit klíčové funkce a zda jsou o projektu informováni přímo zúčastněné strany.

Úkoly k dokončení

Kritéria přijetí

• Účet dosah se úspěšně vytvořil v předplatném organizace v rámci tenanta organizace.
• K dosah může přistupovat malá skupina uživatelů s více rolemi.
• Dosah je nakonfigurován tak, aby kontroloval alespoň jeden zdroj dat.
• Uživatelé by měli být schopni extrahovat klíčové hodnoty dosah, například:
  • Hledat a procházet
  • Lineage
• Uživatelé by měli být schopni přiřadit vlastnictví prostředků na stránce assetů.
• Prezentace a ukázka pro zvýšení povědomí o klíčových zúčastněných osobách
• Kupte si ze správy, abyste schválili další zdroje pro fázi MVP.

Fáze 2: minimální životaschopný produkt

Až budete mít dohodnuté požadavky a podílované obchodní jednotky na dosah, bude dalším krokem práce s minimální verzí životaschopného produktu (MVP). V této fázi rozšíříte využití dosah pro více uživatelů, kteří budou mít další potřeby vodorovně a svisle. K dispozici jsou klíčové scénáře, které je potřeba splnit vodorovně pro všechny uživatele, jako jsou glosářové podmínky, hledání a procházení. u každé obchodní jednotky nebo skupiny se budou pokrývat také podrobné požadavky, které pokrývají konkrétní ucelené scénáře, jako je například Azure Data Lake Storage do služby Azure Synapse DW Power BI.

Úkoly k dokončení

Kritéria přijetí

• Úspěšně připojit větší skupinu uživatelů k dosah (50 +)
• Kontrola důležitých podnikových zdrojů dat
• Import a přiřazení všech kritických pojmů glosáře
• Test důležitých popisků pro klíčové prostředky je úspěšný
• Úspěšné splnění minimálních scénářů pro uživatele zapojených obchodních jednotek

Fáze 3: předprodukční verze

Po úspěšné fázi MVP je čas naplánovat předprodukční milník. Vaše organizace se může rozhodnout, že bude mít samostatnou instanci dosah pro předprodukční a produkční prostředí, nebo zachovat stejnou instanci, ale omezit přístup. V této fázi je také vhodné zahrnout kontrolu místních zdrojů dat, jako je SQL Server. Pokud je ve zdrojích dat nějaká mezera, kterou dosah nepodporuje, je čas prozkoumat rozhraní API pro Atlas, abyste porozuměli dalším možnostem.

Úkoly k dokončení

Kritéria přijetí

• Úspěšné připojení alespoň jedné obchodní jednotky se všemi uživateli
• Kontrola místního zdroje dat, jako je SQL Server
• PoC alespoň jeden scénář integrace s využitím REST API
• Dokončení plánu přejít do produkčního prostředí, který by měl zahrnovat klíčové oblasti infrastruktury a zabezpečení

Fáze 4: Produkce

Ve výše uvedených fázích byste měli vytvořit efektivní zásady správného řízení informací, které jsou základem lepších programů zásad správného řízení. Zásady správného řízení dat pomůžou vaší organizaci připravit se na rostoucí trendy, jako je AI, Hadoop, IoT a blockchain. Je to jen začátek mnoha věcí, které se řešily v datech a analýzách, a je tu spousta dalších věcí, které je možné projednat. Výsledek tohoto řešení by byl následující:

• Zaměřené na obchodní informace – řešení, které je v souladu s obchodními požadavky a scénáři a s technickými požadavky.
• Připraveno na budoucnost – Řešení maximalizuje výchozí funkce platformy a použije standardizované oborové postupy pro aktivity konfigurace nebo skriptování, které podporují pokroky/vývoj platformy.

Úkoly k dokončení

Kritéria přijetí

• Úspěšné připojení všech obchodních jednotek a jejich uživatelů
• Úspěšné splnění požadavků na infrastrukturu a zabezpečení pro produkční prostředí
• Úspěšné splnění všech případů použití požadovaných uživateli

Vytánění platformy

Je možné provést další kroky pro zotvrdění:

• Zvyšte úroveň zabezpečení povolením kontroly prostředků brány firewall nebo použijte Private Link
• Vyladění kontroly rozsahu za účelem zvýšení výkonu kontroly
• Použití rozhraní REST API k exportu důležitých metadat a vlastností pro zálohování a obnovení
• Automatizace lístků a událostí s cílem vyhnout se lidským chybám pomocí pracovního postupu

Další kroky

• Osvědčené postupy pro kolekce
• Přechod na domovskou stránku a vyhledání assetu