Azure Data Lake Storage belangrijke overwegingen

  • Artikel

Meer informatie over belangrijke opslagoverwegingen voor uw Azure Data Lakes.

Levenscyclusbeheer

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

  • Hot: Geoptimaliseerd voor het opslaan van gegevens die regelmatig worden geopend.
  • Cool: Geoptimaliseerd voor het opslaan van gegevens die niet vaak worden gebruikt. Gegevens worden ten minste 30 dagen opgeslagen.
  • Koude laag: Geoptimaliseerd voor het opslaan van gegevens die niet vaak worden geopend of gewijzigd. Gegevens worden ten minste 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 gedurende ten minste 180 dagen opgeslagen met flexibele latentievereisten, in de orde van uren.

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

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

  • De lagen Dynamisch, Statisch en Archief kunnen allemaal worden ingesteld op blobniveau tijdens het uploaden of na het uploaden.

  • Gegevens in de statische laag hebben een iets lagere beschikbaarheid, maar bieden dezelfde hoge duurzaamheid, latentie bij ophalen en doorvoer als dynamische gegevenslaag. Voor gegevens in de statische laag kunnen iets lagere beschikbaarheid en hogere toegangskosten acceptabel zijn voor lagere totale opslagkosten in vergelijking met de dynamische laag.

  • Archiefopslag slaat gegevens offline op en biedt de laagste opslagkosten. Het brengt echter ook de hoogste kosten voor gegevensrehydratatie en toegang met zich mee.

Zie Dynamische, statische en archieftoegangslagen voor blobgegevens voor meer informatie.

Waarschuwing

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 door gebruikers detecteerbare gegevens naar statische opslag.

Verplaats alleen secties van uw data lake naar de statische laag voor goed begrijpende 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 voor virtuele netwerken. Deze verbinding biedt een optimale oplossing vanuit zowel het oogpunt van kosten als toegangsbeheer.

Zie Privé-eindpunten en gegevensbeheerlandingszone naar gegevenslandingszone voor meer informatie.

Belangrijk

Gegevens uit een gegevenslandingszone kunnen worden geopend vanuit een andere gegevenslandingszone via peering van virtuele netwerken tussen de zones. Dit wordt gedaan 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 gegevenslandingszones 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 door u gekozen tijd 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 biedt geen bescherming tegen het verwijderen van opslagaccounts, alleen tegen het verwijderen van containers in een account. Als u een opslagaccount wilt beschermen tegen verwijdering, configureert u een vergrendeling voor de resource van het opslagaccount. Zie Resources vergrendelen om onverwachte wijzigingen te voorkomen voor meer informatie over het vergrendelen van Azure Resource Manager-resources.

Bewaking

In een gegevenslandingszone moet alle bewaking worden verzonden naar uw beheerabonnement op ondernemingsniveau 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 aanvragen worden gedaan op basis van het service-eindpunt. De typen geverifieerde aanvragen die worden 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 klassegegevens 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 worden 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 beheerabonnement op ondernemingsniveau.

Volgende stappen