Zones voor gegevenslanding
Gegevenslandingszones zijn verbonden met uw landingszone voor gegevensbeheer door peering van virtuele netwerken of privé-eindpunten. Elke landingszone voor gegevens wordt beschouwd als een landingszone gerelateerd aan de architectuur van de Azure-landingszone.
Belangrijk
Voordat u een gegevenslandingszone inricht, moet u ervoor zorgen dat uw DevOps- en CI/CD-bedrijfsmodel aanwezig is en dat er een landingszone voor gegevensbeheer wordt geïmplementeerd.
Elke gegevenslandingszone heeft verschillende lagen die flexibiliteit bieden voor de servicegegevensintegraties en gegevenstoepassingen die deze bevat. U kunt een nieuwe gegevenslandingszone implementeren met een standaardset services waarmee de gegevenslandingszone kan beginnen met het opnemen en analyseren van gegevens.
Een typisch Azure-abonnement dat is gekoppeld aan een gegevenslandingszone heeft de volgende structuur:
| Laag | Vereist | Resourcegroepen |
|---|---|---|
| Platformserviceslaag | Ja | |
| Core services | Ja | |
| gegevenstoepassing | Facultatief |
|
| rapportage en visualisatie | Facultatief |
Notitie
Hoewel de laag Basisservices is gemarkeerd als vereist, zijn niet alle resourcegroepen en services die in dit artikel zijn opgenomen, mogelijk nodig voor uw gegevenslandingszone.
Architectuur van gegevenslandingszones
De architectuur van de gegevenslandingszone illustreert de lagen, de bijbehorende resourcegroepen en de services die elke resourcegroep bevat. De architectuur biedt een overzicht van alle groepen en rollen die zijn gekoppeld aan uw gegevenslandingszone en de mate van toegang tot uw besturings- en gegevensvlakken. De architectuur illustreert ook hoe elke laag overeenkomt met de verantwoordelijkheden van het operationele model.
Fooi
Voordat u een gegevenslandingszone implementeert, moet u ervoor zorgen dat u rekening houdt met het aantal initiële gegevenslandingszones dat u wilt implementeren.
Platformservices
De platformserviceslaag bevat services die nodig zijn om connectiviteit en waarneembaarheid voor uw gegevenslandingszone mogelijk te maken binnen de context van analyses op cloudschaal. De volgende tabel bevat de aanbevolen resourcegroepen.
| Resourcegroep | Vereist | Beschrijving |
|---|---|---|
network-rg |
Ja | Netwerken |
security-rg |
Ja | Beveiliging en bewaking |
Netwerken
De netwerkresourcegroep bevat connectiviteitsservices, waaronder Azure Virtual Networks, netwerkbeveiligingsgroepen (NSG) en routetabellen. Al deze services worden geïmplementeerd in één resourcegroep.
Het virtuele netwerk van uw gegevenslandingszone wordt automatisch gekoppeld aan het virtuele netwerk van uw databeheerlandingszone en aan het virtuele netwerk van uw connectiviteitsabonnement .
Beveiliging en bewaking
De resourcegroep beveiliging en bewaking omvat Azure Monitor- en Microsoft Defender for Cloud voor het verzamelen van servicetelemetrie, het definiëren van bewakingscriteria en waarschuwingen en het toepassen van beleid en scannen op services.
Kernservices
De kernserviceslaag bevat basisservices die nodig zijn om uw gegevenslandingszone in te schakelen binnen de context van analyses op cloudschaal. De volgende tabel bevat de resourcegroepen die de standaardsuite met beschikbare services bieden in elke datalandingszone die u implementeert.
| Resourcegroep | Vereist | Beschrijving |
|---|---|---|
storage-rg |
Ja | Datalakediensten |
runtimes-rg |
Ja | Gedeelde integratieruntimes |
mgmt-rg |
Ja | CI/CD-agents |
external-data-rg |
Ja | Externe gegevensopslag |
data-ingestion-rg |
Facultatief | Gedeelde gegevensopnameservices |
shared-applications-rg |
Facultatief | Gedeelde toepassingen (Synapse of Databricks) |
Opslag
Zoals in het diagram wordt weergegeven, worden drie Azure Data Lake Storage Gen2--accounts ingericht in één Data Lake Services-resourcegroep. Gegevens die in verschillende fasen worden getransformeerd, worden opgeslagen in een van de datalakes van uw datalandingszone. De gegevens zijn beschikbaar voor gebruik door uw analyse-, gegevenswetenschap- en visualisatieteams.
Data Lake-lagen gebruiken verschillende terminologie, afhankelijk van technologie en leverancier. Deze tabel bevat richtlijnen voor het toepassen van termen voor analyses op cloudschaal:
| Analyses op cloudschaal | Delta Lake | Andere termen | Beschrijving |
|---|---|---|---|
| Rauw | Brons | Landing en conformiteit | Opnametabellen |
| Verrijkt | Zilver | Standaardisatiezone | Verfijnde tabellen. Opgeslagen volledige entiteit, recordsets die gereed zijn voor verbruik van systemen van records. |
| Gecureerd | Goud | Product zone | Kenmerk- of samengevoegde tabellen. Primaire zone voor toepassingen, teams en gebruikers om gegevensproducten te gebruiken. |
| Ontwikkeling | -- | Ontwikkelzone | Locatie voor data engineers en wetenschappers, bestaande uit zowel een analyse-sandbox als een zone voor productontwikkeling. |
Notitie
In het vorige diagram heeft elke data landingszone drie Data Lake Storage-accounts. Afhankelijk van uw vereisten kunt u er echter voor kiezen om uw onbewerkte, verrijkte en gecureerde lagen samen te voegen in het ene opslagaccount en een ander opslagaccount met de naam 'werkruimte' te onderhouden voor gegevensgebruikers om andere nuttige gegevensproducten in te voeren.
Zie voor meer informatie:
- Overzicht van Azure Data Lake Storage voor analyses op cloudschaal
- Gegevensstandaardisatie
- Azure Data Lake Storage Gen2-accounts inrichten per gegevenslandingszone
- Belangrijke overwegingen voor Azure Data Lake Storage-
- Toegangsbeheer en Data Lake-configuraties in Azure Data Lake Storage
Gedeelde integratieruntimes
Azure Data Factory en Azure Synapse Analytics Pipelines gebruiken integration runtimes (IR) om veilig toegang te krijgen tot gegevensbronnen in gekoppelde of geïsoleerde netwerken. Gedeelde IR's moeten worden geïmplementeerd op een virtuele machine (of Azure Virtual Machine Scale Sets) in de gedeelde integration runtime-resourcegroep.
De gedeelde resourcegroep inschakelen:
- Maak ten minste één Azure Data Factory in de gedeelde integratieresourcegroep van uw gegevenslandingszone. Gebruik dit alleen voor het koppelen van de gedeelde zelf-hostende Integration Runtime, niet voor gegevenspijplijnen.
- Maak en configureer een zelf-gehoste integratieruntime op de virtuele machine.
- Koppel de zelfgehoste integratieruntime aan Azure-gegevensfabrieken in uw datalandingszones.
- Gebruik PowerShell-scripts om de zelf-hostende Integration Runtime-periodiek bij te
.
Notitie
De implementatie beschrijft één implementatie van virtuele machines met een zelf-hostende Integration Runtime. U kunt een zelf-hostende Integration Runtime koppelen aan meerdere virtuele machines on-premises of in Azure. Deze machines worden knooppunten genoemd en u kunt maximaal vier knooppunten hebben die zijn gekoppeld aan een zelf-hostende Integration Runtime. De voordelen van het hebben van meerdere knooppunten zijn:
- Hogere beschikbaarheid van de Zelf-Hostende Integration Runtime, zodat het geen 'single point of failure' meer is in uw gegevenstoepassing of in de orkestratie van cloudgegevensintegratie.
- Verbeterde prestaties en doorvoer tijdens gegevensverplaatsing tussen on-premises en cloudgegevensservices. Meer informatie over prestatievergelijkingen.
U kunt meerdere knooppunten koppelen door de zelf-hostende Integration Runtime-software te installeren vanuit Downloadcentrum. Registreer deze vervolgens met behulp van een van de verificatiesleutels die zijn verkregen uit de cmdlet New-AzDataFactoryV2IntegrationRuntime Key, zoals beschreven in de zelfstudie.
Meer informatie vindt u in Hoge beschikbaarheid en schaalbaarheid van Azure Data Factory.
Belangrijk
Implementeer gedeelde integratieruntimes zoveel mogelijk bij de gegevensbron. U kunt de integratieruntimes implementeren in een gegevenslandingszone, in clouds van derden of in een privécloud, mits de virtuele machine verbinding heeft met de vereiste gegevensbronnen.
Beheer
CI/CD-agents worden uitgevoerd op virtuele machines en helpen bij het implementeren van artefacten uit de broncode-opslagplaats, inclusief data-applicaties en wijzigingen in de data-landingszone.
Zie Azure Pipeline-agentsvoor meer informatie.
Externe opslag
Uitgevers van partnergegevens moeten gegevens in uw platform landen, zodat uw datatoepassingsteams deze kunnen ophalen in hun data lakes. U kunt ook interne of externe gegevensbronnen hebben die geen ondersteuning bieden voor de connectiviteits- of authenticatievereisten zoals die worden afgedwongen in de rest van de gegevenslandingszones. Het gebruik van een afzonderlijk opslagaccount is de aanbevolen benadering voor het ontvangen van gegevens, en vervolgens een gedeelde integratieruntime of een vergelijkbaar opnameproces om het in uw verwerkingspijplijn op te nemen. Zoals u in het volgende diagram kunt zien, kunt u met uw opslagresourcegroep voor uploaden blobarchieven inrichten voor deze gebruiksvoorbeelden.
De datatoepassingsteams vragen de opslagblobs aan. Deze aanvragen worden goedgekeurd door het operations-team voor gegevenslandingszones. Gegevens moeten worden verwijderd uit de bronopslagblob nadat ze zijn opgenomen in de onbewerkte gegevensopslag.
Belangrijk
Aangezien Azure Storage-blobs op basis van naar behoefte worden ingericht, moet u in eerste instantie een lege resourcegroep voor opslagservices implementeren in elke gegevenslandingszone.
Gegevensopname
Deze resourcegroep is optioneel en staat u niet in de weg bij het implementeren van uw landingszone. Dit is van toepassing als u een gegevensagnostische opname-engine hebt of ontwikkelt die automatisch gegevens opneemt op basis van geregistreerde metagegevens, waaronder verbindingsreeksen, paden voor gegevensoverdracht en opnameschema's.
De resourcegroep voor opname en verwerking bevat belangrijke services voor deze soort frameworks.
Implementeer een Azure SQL Database-exemplaar voor het opslaan van metagegevens die worden gebruikt door Azure Data Factory. Richt een Azure Key Vault in voor het opslaan van geheimen met betrekking tot geautomatiseerde opnameservices. Deze geheimen kunnen het volgende omvatten:
- Referenties voor Azure Data Factory-metastore
- Referenties van de service-principal voor uw geautomatiseerde opnameproces
Raadpleeg voor meer informatie hoe geautomatiseerde opnameframeworks grootschalige cloudanalyses ondersteunen in Azure.
Services die zijn opgenomen in deze resourcegroep zijn onder andere:
| Dienst | Vereist | Richtsnoeren |
|---|---|---|
| Azure Data Factory | Ja | Azure Data Factory is uw orkestratiemotor voor gegevensagnostische datainvoer. |
| Azure SQL DB | Ja | Azure SQL DB is de metastore voor Azure Data Factory. |
| Event Hubs of IoT Hub | Facultatief | Event Hubs of IoT Hub kan real-time gegevens streamen naar Event Hubs, en biedt daarnaast batch- en streamingverwerking via een Databricks-werkruimte voor engineering. |
| Azure Databricks | Facultatief | U kunt Azure Databricks of Azure Synapse Spark implementeren voor gebruik met uw gegevensagnostische verwerkingsengine. |
| Azure Synapse | Facultatief | U kunt Azure Databricks of Azure Synapse Spark implementeren voor gebruik met de gegevensagnostische opname-engine. |
Gedeelde toepassingen
Deze optionele resourcegroep wordt gebruikt wanneer er behoefte is aan een set gedeelde services die beschikbaar zijn voor alle teams die gegevenstoepassingen bouwen in deze gegevenslandingszone. Voorbeelden van gebruik zijn:
- Een Azure Databricks-werkruimte die wordt gebruikt als een gedeelde metastore voor alle andere Databricks-werkruimten die zijn gemaakt in dezelfde gegevenslandingszone (of regio)
- Een gedeeld Azure Synapse Analytics-exemplaar met serverloze SQL-pools om gebruikers in staat te stellen query's uit te voeren op geïsoleerde opslagaccounts.
Notitie
Azure Databricks maakt gebruik van Unity Catalog om de toegang en zichtbaarheid van metastores in Databricks-werkruimten te beheren. Unity Catalog is ingeschakeld op tenantniveau, maar metastores worden afgestemd op Azure-regio's. In de praktijk betekent dit dat alle Databricks-werkruimten met Unity Catalog in een bepaalde Azure-regio moeten worden geregistreerd bij dezelfde Metastore. Zie Best Practices voor Unity Catalogvoor meer informatie.
Volg de beste praktijken voor cloud-scale analyses voor de integratie van Azure Databricks.
Data-applicatie
Elke gegevenslandingszone kan meerdere gegevenstoepassingen hebben. U kunt deze toepassingen maken door gegevens op te nemen uit verschillende bronnen. U kunt ook gegevenstoepassingen maken van andere gegevenstoepassingen binnen dezelfde gegevenslandingszone of vanuit andere gegevenslandingszones. Het maken van de gegevenstoepassingen is onderhevig aan goedkeuring van de gegevenssteward.
Resourcegroep voor gegevenstoepassing
Uw gegevenstoepassingsresourcegroep bevat alle services die nodig zijn om die gegevenstoepassing te maken. Een Azure Database is bijvoorbeeld vereist voor MySQL, dat wordt gebruikt door een visualisatieprogramma. Gegevens moeten worden opgenomen en getransformeerd voordat ze terechtkomen in die MySQL-database. In dit geval kunt u Azure Database for MySQL en een Azure Data Factory implementeren in de resourcegroep van de gegevenstoepassing.
Tip
Als u ervoor kiest om geen gegevensagnostische engine te implementeren voor het opnemen van gegevens uit operationele bronnen of als complexe verbindingen niet worden gefaciliteerd in uw gegevensagnostische engine, maakt u een gegevenstoepassing die is uitgelijnd op basis van een bron. Zie Gegevenstoepassingen (bron uitgelijnd)voor meer informatie.
Zie Analysegegevenstoepassingen op cloudschaal in Azurevoor meer informatie over het onboarden van gegevensproducten.
Rapportage en visualisatie
U kunt visualisatie- en rapportagehulpprogramma's gebruiken in Fabric-werkruimten, die veel overeenkomsten hebben met Power BI-werkruimten, zonder dat u unieke resources hoeft te implementeren binnen uw datalandingszone. U kunt een resourcegroep opnemen om Fabric-capaciteit, virtuele machines voor gegevensgateways of andere noodzakelijke dataservices te implementeren, zodat uw gegevenstoepassing aan de eindgebruiker kan worden geleverd.