Delen via

Belangrijke overwegingen voor Azure Data Lake Storage

  • Artikel

Meer informatie over belangrijke opslagoverwegingen voor uw Azure Data Lakes.

Levenscyclusbeheer

Azure Storage biedt verschillende toegangslagen, waarmee u op de meest rendabele manier blobobjectgegevens kunt opslaan. De beschikbare toegangslagen zijn onder andere:

  • Dynamisch: geoptimaliseerd voor het opslaan van gegevens die regelmatig worden geopend.
  • Statisch: geoptimaliseerd voor het opslaan van gegevens die niet vaak worden geopend. Gegevens worden minstens 30 dagen opgeslagen.
  • Koude laag: geoptimaliseerd voor het opslaan van gegevens die niet vaak worden geopend of gewijzigd. Gegevens worden minstens 90 dagen opgeslagen. De koude laag heeft lagere opslagkosten en hogere toegangskosten dan de statische laag.
  • Archief: geoptimaliseerd voor het opslaan van gegevens die zelden worden geopend. De gegevens worden minstens 180 dagen opgeslagen met flexibele latentievereisten, op volgorde van uren.

Belangrijk

Er zijn geen compromissen voor betrouwbaarheid, beveiliging, operationele uitmuntendheid of prestatie-efficiëntie tussen de verschillende onlinetoegangslagen, waardoor de keuze van een onlinelaag een financiële beslissing moet zijn, per blob, op basis van de gegevensgrootte van de werkbelasting, operationele interacties en tijd voordat de blob wordt verwijderd. Selecteer de juiste laag, per blob, op basis van een berekening van de voorgaande factoren. Zie Kosten voor Azure Blob Storage plannen en beheren voor meer informatie.

Houd rekening met de volgende informatie bij het gebruik van toegangslagen:

  • Alleen de toegangslagen Dynamisch en Statisch kunnen worden ingesteld op accountniveau. De archieftoegangslaag is niet beschikbaar op accountniveau.

  • Dynamische, statische en archieflagen kunnen allemaal worden ingesteld op blobniveau tijdens het uploaden of na uploaden.

  • Gegevens in de lagen Statisch en Koud hebben iets lagere beschikbaarheid, maar bieden dezelfde hoge duurzaamheid, ophaallatentie en doorvoerkenmerken als de gegevens in de dynamische laag. Voor gegevens in de laag Statisch of Koud, kunnen iets lagere beschikbaarheids- en hogere toegangskosten acceptabel zijn voor lagere totale opslagkosten in vergelijking met de hot-laag.

  • Archiefopslag slaat gegevens offline op en biedt de laagste opslagkosten. Het biedt echter ook de hoogste kosten voor rehydratatie en toegang tot gegevens.

Zie Access-lagen voor blobgegevens voor meer informatie.

Let op

Voor analyses op cloudschaal raden we u aan levenscyclusbeheer te implementeren met behulp van een aangepaste microservice en zorgvuldig na te denken over de impact van het verplaatsen van detecteerbare gegevens van gebruikers naar statische opslag.

U moet alleen secties van uw data lake verplaatsen naar de statische laag voor goed begrepen workloads.

Data Lakes-connectiviteit

Elk van uw data lakes moet gebruikmaken van privé-eindpunten die zijn geïnjecteerd in het virtuele netwerk van uw datalandingszone. Als u toegang wilt bieden tussen landingszones, verbindt u uw gegevenslandingszones via peering van virtuele netwerken. Deze verbinding biedt een optimale oplossing vanuit zowel kosten- als toegangsbeheerperspectief.

Zie Privé-eindpunten en landingszone voor gegevensbeheer naar de landingszone voor gegevens voor meer informatie.

Belangrijk

Gegevens uit een gegevenslandingszone kunnen worden geopend vanuit een andere gegevenslandingszone via peering van virtuele netwerken tussen de zones. Dit gebeurt met behulp van de privé-eindpunten die zijn gekoppeld aan elk Data Lake-account. U wordt aangeraden alle openbare toegang tot uw meren uit te schakelen en privé-eindpunten te gebruiken. Uw platformbewerkingsteam moet de netwerkconnectiviteit in uw datalandingszones beheren.

Containers voorlopig verwijderen

Voorlopig verwijderen voor containers beschermt uw gegevens tegen onbedoelde of schadelijke verwijdering. Als u voorlopig verwijderen van containers inschakelt voor uw opslagaccount, worden verwijderde containers en de inhoud ervan gedurende een bepaalde periode bewaard in Azure Storage. Tijdens de gegevensretentieperiode kunt u eerder verwijderde containers herstellen. Als u een container herstelt, worden ook blobs hersteld die zich in die container bevonden toen deze werd verwijderd.

Schakel de volgende functies voor gegevensbeveiliging in om end-to-end blobgegevensbeveiliging te bereiken:

Waarschuwing

Het verwijderen van een opslagaccount kan niet ongedaan worden gemaakt. Voorlopig verwijderen van containers beschermt niet tegen het verwijderen van opslagaccounts, alleen tegen het verwijderen van containers binnen een account. Als u een opslagaccount wilt beveiligen tegen verwijdering, configureert u een vergrendeling voor de opslagaccountresource. Zie Resources vergrendelen om onverwachte wijzigingen te voorkomen voor meer informatie over het vergrendelen van Azure Resource Manager-resources.

Controleren

In een gegevenslandingszone moet alle bewaking worden verzonden naar uw Azure Landing Zone-beheerabonnement voor analyse.

Zie Azure-resources bewaken met Azure Monitor voor meer informatie over de bewakingsgegevens die Azure Storage gebruikt. Zie Bewaking van Azure Blob Storage voor meer informatie over de logboeken en metrische gegevens die Azure Storage maakt.

Logboekvermeldingen worden alleen gemaakt als er aanvragen worden gedaan op basis van het service-eindpunt. De typen geverifieerde aanvragen die zijn geregistreerd, zijn:

  • Geslaagde aanvragen
  • Mislukte aanvragen, inclusief time-out-, beperkings-, netwerk-, autorisatiefouten en overige fouten
  • Aanvragen die gebruikmaken van een Shared Access Signature (SAS) of OAuth, inclusief mislukte en geslaagde aanvragen
  • Aanvragen voor analysegegevens, zoals klassieke logboekgegevens in de $logs container en metrische gegevens van klasse in de $metric tabellen

Aanvragen die door de opslagservice zelf worden gedaan, zoals het maken of verwijderen van logboeken, worden niet geregistreerd. De typen anonieme aanvragen die zijn geregistreerd, zijn:

  • Geslaagde aanvragen
  • Serverfouten
  • Time-outfouten voor zowel de client als de server
  • Mislukte HTTP GET-aanvragen met foutcode 304 (Not Modified)

Alle andere mislukte anonieme aanvragen worden niet geregistreerd.

Belangrijk

Stel uw standaardbewakingsbeleid in om opslag te controleren en logboeken te verzenden naar uw bedrijfsbeheerabonnement.

De volgende gebruiksgegevens zijn de aanbevolen beveiligingspatronen voor elk van de Data Lake-zones:

  • Onbewerkt gebruik biedt alleen toegang tot gegevens met behulp van SPN's (Security Principal Names), bij voorkeur met beheerde identiteiten.
  • Verrijkt gebruik biedt alleen toegang tot gegevens met behulp van SPN's (Security Principal Names), bij voorkeur met behulp van beheerde identiteiten.
  • Gecureerd gebruik maakt toegang tot zowel SPN's (Security Principal Names) als UPN's (User Principal Names).

Zie het Access Control-model in Azure Data Lake Storage voor meer informatie.

Volgende stappen