Podniková posílená architektura služby Azure Data Factory

Tento článek popisuje, jak upravit a posílit medailiónské jezerohouse při přijetí systému v rámci podniku. Tato architektura se řídí typickým vzorem přijetí popsaným v základní architektuře. Tato architektura je posílená tak, aby splňovala další nefunkční požadavky (NFR), poskytovala další možnosti a přesunula odpovědnost na federovaný model založený na doméně.

Tato architektura zahrnuje osvědčené postupy a pokyny z architektury přechodu na cloud od Microsoftu pro Azure a zaměřuje se na implementaci datových domén a přijetí datových produktů.

Posílení základní architektury

Podle základní architektury společnost Contoso provozuje medallion lakehouse, který podporuje své první datové úlohy pro finanční oddělení. Společnost Contoso tento systém rozšiřuje, aby podporoval potřeby analytických dat v podniku. Tato strategie poskytuje možnosti datových věd a samoobslužné funkce.

Klíčové požadavky

Existuje několik klíčových požadavků na úpravu a posílení medailiónového jezerahouse:

• Řešení musí být posíleno, aby fungovalo jako podniková platforma pro data a analýzu. Řešení musí také podporovat další podnikové funkce a dodržovat požadavky zásad přístupu k datům společnosti Contoso.

• Platforma musí být schopná ingestovat, ukládat, zpracovávat a obsluhovat data téměř v reálném čase. Cíl výkonu je definován jako méně než jedna minuta zpracování od příjmu dat po dostupnost ve vrstvě generování sestav.

• Platforma musí přinést úspory z úspor a efektivity škálování při současném využívání.

• Platforma musí umožňovat, aby obchodní oblasti rozhodovaly úroveň samoobslužných služeb a řízení, které vyžadují pro svá datová řešení a produkty.

• Tato platforma musí podporovat možnosti podnikových datových věd, které zahrnují povolení občanů dat.

• Platforma musí podporovat smlouvy o úrovni služeb (SLA) s vyšší cílovou úrovní služeb, mezi které patří:

  • Cílová doba provozu 99,9 % nebo přibližně 8,5 hodin prostoje za rok.

  • Cíl bodu obnovení (RPO) 1,5 dne.

  • Cíl doby obnovení (RTO) kratší než 1 den.

• Platforma musí podporovat očekávané využití 1 000 uživatelů v různých doménách s odhadovaným růstem 5 % ročně. K platformě mají přímý přístup jenom zaměstnanci Společnosti Contoso, ale vyžaduje se možnost sdílení dat s jinými společnostmi.

Klíčová rozhodnutí o návrhu

Základní architekturu můžete upravit tak, aby splňovala tyto požadavky, aniž byste vytvořili novou architekturu.

• Pro tento scénář dobře funguje návrh domény, který je založený na základech spravovaných podnikem. Návrh domény podporuje požadavky na rozšíření platformy v rámci celého podniku, samoobslužné funkce a obchodní strategický cíl. Základ je definován takto:

  • Řízení identit a přístupu.
  • Základní sítě, kontrolní mechanismy hranic a standardní hodnoty zabezpečení.
  • Funkce zásad správného řízení, auditu a monitorování.
  • Funkce pro příjem a počáteční zpracování dat do platformy

• Návrh domény je ukotvený kolem vlastnictví daného obchodního oddělení jejich dat a zdrojového systému. Nový provozní model umožňuje obchodním skupinám volitelně vytvořit vlastní sadu modelem a obsluhovaných komponent, které budou řídit a udržovat v budoucnu. Domény fungují v rámci mantinelí podle podnikových požadavků a umožňují provádět dobře definované a řízené experimenty. Funkce datových věd je poskytována prostřednictvím:

  • Power BI pro nízký kód a případy použití jednoduché nebo střední složitosti napříč tabulkovými daty Tento model je ideálním výchozím bodem pro občany dat.

  • Nabídky služeb Azure Machine Learning a AI, které podporují úplnou sadu případů použití a vyspělosti uživatelů.

  • Azure Databricks pro velké podnikové případy použití svazků s významnými požadavky na zpracování

  • Inovační sandbox, který podporuje testování konceptu pro nové technologie nebo techniky. Poskytuje izolované prostředí, které se odděluje od produkčního prostředí a předprodukčního prostředí.

• Funkce Azure Data Factory , které pokrývají případy použití téměř v reálném čase a mikrodávkovém příjmu dat, které jsou povolené funkcemi zachytávání dat změn. Tato funkce v kombinaci se strukturovaným streamováním Azure Databricks a Power BI podporuje komplexní řešení.

• Power BI umožňuje sdílení dat s externími stranami podle potřeby s autorizací a řízením přístupu Microsoft Entra B2B .

• Vzory dat streamování můžou být složité při implementaci a správě, zejména ve scénářích selhání. Před implementací se ujistěte, že obchodní požadavky jsou testovány na přijatelnou latenci a že zdrojová systém a síťová infrastruktura můžou podporovat požadavky na streamování.

• Jakékoli rozhodnutí o přechodu k doménovému modelu musí být provedeno ve spolupráci s obchodními účastníky. Je důležité, aby zúčastněné strany pochopili a přijali zvýšenou odpovědnost za vlastnictví domény.

• Vyspělost dat zúčastněných stran, dostupná dovednost v životním cyklu vývoje softwaru (SDLC), architektura zásad správného řízení, standardy a vyspělost automatizace mají vliv na to, jak daleko se počáteční provozní model přikloní k povolení domény. Tyto faktory můžou také znamenat vaši aktuální pozici v životním cyklu přechodu na analýzy na úrovni cloudu a zvýraznit kroky potřebné k dalšímu postupu.

Architektura

Workflow

Následující pracovní postup odpovídá předchozímu diagramu:

1. Ingestovaná data a Delta Lake jsou v souladu se zdrojem a zůstávají odpovědností centrálního technického týmu. Toto rozhodnutí odráží úroveň technických odborných znalostí potřebných pro vývoj Sparku a podporuje konzistentní standardizovaný přístup implementace, který bere v úvahu opětovnou použitelnost podniku.

   • Datové kontrakty řídí datové kanály ze zdrojových systémů. Kontrakty dat se dají použít k řízení architektury extrakce , transformace, načítání (ETL) založeného na metadatech a zpřístupnění dat uživatelům v rámci možností zásad správného řízení.

   • Adresářová struktura bronzové vrstvy (nebo nezpracované vrstvy) v Delta Lake odráží způsob využívání dat. Zdrojový systém objedná data. Tato metodologie organizace umožňuje jednotnou implementaci zabezpečení na základě obchodního vlastnictví zdrojových systémů.

   • Rychlá cesta pro data podporuje požadavek na streamování. Rychlá cesta ingestuje data prostřednictvím služby Data Factory a strukturované streamování Azure Databricks přímo zpracovává data pro analýzu a použití. K vytvoření historie auditu můžete použít zachytávání dat změn Delta Lake. Tato funkce podporuje přehrání a šíření přírůstkových změn do podřízených tabulek v architektuře medailiónu.

2. Modelem a obsluhou zůstává odpovědnost centrálního technického týmu na podporu řešení dat vlastněných podnikem. Technický tým také zodpovídá za poskytování volitelného katalogu služeb pro obchodní oblasti, které vyžadují datová řešení, ale nemají dovednosti, rozpočet nebo zájem o technicky správu vlastní implementace domény. Samoobslužná služba se nabízí v rámci modelem a obsluhovaných komponent, které spravuje centrální technický tým.

3. Centrální technický tým spravuje možnosti podnikových datových věd. Tento model také odpovídá podpoře podnikových řešení, poskytování volitelných služeb a hostování služeb s cenovou strukturou podniku.

4. Domény jsou povolené prostřednictvím logických kontejnerů na úrovni předplatného. Předplatná poskytují nezbytnou jednotku správy, fakturace, zásad správného řízení a izolace na úrovni domény.

   • Přístup se spravuje prostřednictvím infrastruktury jako infrastruktury (IaC) jako kódu (IaC), která poskytuje základní hodnoty podnikových kontrol monitorování, auditu a zabezpečení. Strategie označování platformy je rozšířená tak, aby podporovala rozšíření domény.

   • Každá doména má vlastní sadu rolí řízení přístupu na základě role (RBAC), které pokrývají řídicí roviny a roviny dat. Role řídicí roviny se primárně používají v rámci logických kontejnerů domény. Naproti tomu role roviny dat platí pro celou platformu, což zajišťuje konzistentní, sjednocené a nízké řízení složitosti.

5. V rámci předplatného domény je možné dostupné komponenty nakonfigurovat na základě sad dovedností, priorit a případů použití.

   • Pracovní prostory Power BI umožňují doménám spolupracovat, když je to praktické. Pracovní prostory můžou být také jedinečné pro domény a propojené s konkrétními kapacitami Premium, pokud se vyžaduje vyšší výkon.

   • Sandbox pro inovace je dočasná entita, která umožňuje ověřování nových technologií nebo procesů. Úložiště dat se poskytuje k onboardingu, vytváření nebo úpravě dat, aniž by byla omezena funkcemi jen pro připojení bronzové vrstvy Delta Lake.

Návrh sítě

Stáhněte si soubor aplikace Visio s touto architekturou.

• K zabezpečení síťového připojení mezi vaší místní infrastrukturou a virtuální sítí Azure použijte bránu firewall nové generace, jako je Azure Firewall .

• Místní prostředí Integration Runtime (SHIR) můžete nasadit na virtuální počítač ve vašem místním prostředí nebo v Azure. Pokud chcete zjednodušit zásady správného řízení a zabezpečení, zvažte nasazení virtuálního počítače v Azure jako součást cílové zóny sdílených prostředků podpory. SHIR můžete použít k bezpečnému připojení k místním zdrojům dat a provádění úloh integrace dat ve službě Data Factory.

• Popisování dat s asistencí strojového učení nepodporuje výchozí účty úložiště, protože jsou zabezpečené za virtuální sítí. Nejprve vytvořte účet úložiště pro označování dat s asistencí strojového učení. Pak použijte popisky a zabezpečte ho za virtuální sítí.

• Privátní koncové body poskytují privátní IP adresu z vaší virtuální sítě do služby Azure. Tento proces efektivně přináší službu do vaší virtuální sítě. Díky této funkci bude služba přístupná jenom z vaší virtuální sítě nebo připojených sítí, což zajišťuje bezpečnější a privátní připojení.

  Privátní koncové body používají Službu Azure Private Link, která zabezpečuje připojení k řešení PaaS (Platforma jako služba). Pokud vaše úloha používá nějaké prostředky, které nepodporují privátní koncové body, možná budete moct používat koncové body služby. Doporučujeme používat privátní koncové body pro klíčové úlohy, kdykoli je to možné.

Možnosti datových věd

Ve scénářích datových věd služba Data Factory primárně zpracovává přesun, plánování a orchestraci dat. Tyto úlohy jsou nezbytné pro dávkové odvozování v případech použití strojového učení. Dávkové odvozování, označované také jako dávkové bodování, zahrnuje vytváření předpovědí v dávce pozorování. Tyto scénáře obvykle vyžadují vysokou propustnost dat a vyhodnocování podle předdefinované frekvence.

V rámci služby Data Factory jsou tyto pracovní postupy definovány v kanálech, které se skládají z různých vzájemně propojených aktivit. Škálovatelné kanály služby Data Factory jsou obvykle parametrizovány a řízeny metadaty definovanými v řídicí tabulce. Tento model ingestuje data, zpracovává je za účelem generování předpovědí strojového učení a přenáší výstupy dat do služby pro účely modelování a obsluhu.

Azure Machine Learning a Azure Databricks zpracovávají data a generují předpovědi strojového učení různými způsoby.

• Poznámkový blok Azure Databricks zahrnuje veškerou logiku vyhodnocování modelu. K vyhodnocení modelu můžete použít aktivitu poznámkového bloku Azure Databricks.

• Koncový bod dávky služby Machine Learning se používá k začlenění všech logiky bodování modelu. K vyhodnocení modelu můžete použít aktivitu kanálu Machine Learning.

Alternativy

• Azure Event Hubs můžete použít jako alternativu pro streamování dat. V tomto scénáři poskytuje Azure Databricks potřebné funkce, které zjednodušuje návrh.

• Azure Data Share můžete použít jako alternativu ke sdílení dat. V tomto scénáři power BI poskytuje nezbytné funkce, které zjednodušuje návrh.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Dobře navržená architektura.

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro spolehlivost.

V porovnání se základní architekturou tato architektura:

• Splňuje zvýšené požadavky s výchozími smlouvami SLA Azure v rámci řešení. Tato strategie eliminuje potřebu vysoké dostupnosti nebo vyššího využití ve více oblastech.

• Vylepšuje strategii zotavení po havárii tak, aby zahrnovala úplný rozsah služeb platformy a aktualizované cílové metriky. Tato strategie se musí pravidelně testovat, aby se zajistila, že bude vhodná pro účely.

• Používá funkce redundance zón v komponentách řešení k ochraně před lokalizovanými problémy se službami. Následující tabulka ukazuje typy odolnosti služeb nebo funkcí v této architektuře.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v kontrolním seznamu pro kontrolu návrhu zabezpečení.

V porovnání se základní architekturou tato architektura:

• Vytvoří role RBAC specifické pro doménu, když se data specifická pro doménu ingestují do platformy s klasifikací dat vyšší než podnik. Další informace najdete v tématu Přehled řízení. Tyto role se pak znovu použijí ve všech komponentách řešení, které tato data používají. Tyto role dat domény můžete znovu použít pro všechna nová data domény nasazená na platformu. Tento přístup poskytuje konzistentní a jednotné ovládací prvky pro přístup k datům.

• Bere v úvahu vyšší požadavky na citlivost dat pro platformu, Microsoft Entra Privileged Identity Management (PIM) pro všechny klíčové role provozní podpory.

Optimalizace nákladů

Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro optimalizaci nákladů.

V porovnání se základní architekturou tato architektura:

• Poskytuje týmům domény dovednosti, aby zajistili, že rozumí disciplíně optimalizace nákladů a jejich zodpovědnostem v rámci nového provozního modelu.

• Rozšiřuje výstrahy správy nákladů na domény a obchodní zúčastněné strany, aby poskytovaly transparentnost a pozorovatelnost.

Provozní dokonalost

Efektivita provozu zahrnuje provozní procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro efektivitu provozu.

V porovnání se základní architekturou tato architektura:

• Vyvíjí provozní model tak, aby zohlednil nový doménový model, zúčastněné strany, struktury zásad správného řízení, trénování na základě osob a RACI.

• Rozšiřuje strategii označování tak, aby zohlednila model domény.

• Vyvíjí centrální nefunkční registraci požadavků a přijímá standard osvědčených postupů pro vývoj softwaru, na které může odkazovat jakékoli řešení platformy v libovolné oblasti pro vývojáře. Pro podporu těchto standardů integrujte robustní testovací architekturu do praxe kontinuální integrace a průběžného nasazování.

Efektivita výkonu

Efektivita výkonu je schopnost úlohy škálovat se tak, aby efektivním způsobem splňovala požadavky, které na ni kladou uživatelé. Další informace najdete v kontrolním seznamu pro kontrolu návrhu týkajícího se efektivity výkonu.

V porovnání se základní architekturou tato architektura:

• Poskytuje výstrahy a pozorovatelnost pro doménové týmy v rámci zřízení domény a směrného plánu monitorování.

• Vybízí ke sdílení znalostí a osvědčených postupů mezi pracovníky znalostí a nabízí pobídky pro zapojení komunity.

Antipatterny

• Transformace bez spolupráce: Přechod na doménový model je významným závazkem, který vyžaduje významnou změnu v celé organizaci. Tento posun by neměl být jednostranným úsilím, kdy vedení technologií rozhoduje výhradně na základě technologie, kterou chtějí přijmout. Tento přístup může vést k nesouhlasům nebo nedorozuměním mezi obchodními účastníky a technologickými týmy dále dolů, pokud v úloze dojde k problémům. Tato transformace je nejúčinnější, když obchodní účastníci chápou nezbytné aktivity a ocení hodnotu dodaných výsledků. Klíčem k úspěšné transformaci je hloubková spolupráce mezi technologiemi a obchodními účastníky.

• Nekritické přijetí technologických trendů: Nové nápady řídí technologii. Nové funkce, nové přístupy a nové návrhy jsou neustále představeny prostřednictvím různých online fór. Například trendový vzor návrhu dat na LinkedInu se může zdát jako atraktivní možnost. Vzdorujte pokušení přijmout nejnovější trendy, když vytváříte řešení podnikové třídy a upřednostňujete osvědčené technologie a vzory. Populární řešení můžou chybět důkladné testování a prověřený výkon v produkčních podnikových prostředích. Tato řešení můžou v produkčním prostředí selhat, pokud mají chybějící funkce, nedostatečnou dokumentaci nebo nemožnost správně škálovat.

• Vytváření funkcí bez řádného zvážení: Když identifikujete mezeru v technických funkcích, je často lákavé vytvořit si vlastní. I když tento přístup může být v některých případech platný, vlastníci produktů by měli zvážit vliv na celkový životní cyklus produktu, který by mohl zavádět vytváření řešení, které by mohlo být provedeno. Můžete vytvářet řešení, která budou zahrnovat mezeru v existujících, dobře podporovaných produktech. Tento přístup může výrazně zvýšit technický dluh v průběhu životního cyklu produktu, protože údržba tohoto řešení zvyšuje značnou režii, která se v průběhu času zvyšuje. Objem předpokládaného technického dluhu musí být vyvažovaný proti závažnosti chybějících funkcí. Pokud je tato funkce v plánu produktu pro řešení mimo police, může být v dlouhodobém horizontu lepší strategií čekání na dodavatele, aby tuto funkci doručil.

Další kroky

• Cílová zóna Azure
• Architektura přechodu na cloud od Microsoftu
• Doprovodné materiály k doméně dat

Související prostředky

• Kritická architektura služby Data Factory
• Základní architektura