Aanbevolen procedures voor het gebruik van Azure Data Lake Storage

Dit artikel bevat richtlijnen voor best practices waarmee u de prestaties kunt optimaliseren, kosten kunt verlagen en uw Azure Storage-account met Data Lake Storage kunt beveiligen.

Documentatie zoeken

Azure Data Lake Storage is geen toegewezen service of accounttype. Het is een set mogelijkheden die ondersteuning bieden voor analyseworkloads met hoge doorvoer. De Data Lake Storage-documentatie bevat aanbevolen procedures en richtlijnen voor het gebruik van deze mogelijkheden. Zie de documentatie-inhoud voor Blob Storage voor alle andere aspecten van accountbeheer, zoals het instellen van netwerkbeveiliging, ontwerpen voor hoge beschikbaarheid en herstel na noodgevallen.

Functieondersteuning en bekende problemen evalueren

Gebruik het volgende patroon wanneer u uw account configureert voor het gebruik van Blob Storage-functies.

1. Raadpleeg het artikel over de ondersteuning van Blob Storage-functies in Azure Storage-accounts om te bepalen of een functie volledig wordt ondersteund in uw account. Sommige functies worden nog niet ondersteund of hebben gedeeltelijke ondersteuning in accounts met Data Lake Storage. Functieondersteuning wordt altijd uitgebreid, dus zorg ervoor dat u dit artikel regelmatig bekijkt voor updates.

2. Raadpleeg het artikel Bekende problemen met Azure Data Lake Storage om te zien of er beperkingen of speciale richtlijnen zijn voor de functie die u wilt gebruiken.

3. Scan feature-artikelen voor richtlijnen die specifiek zijn voor accounts met Data Lake Storage.

Meer informatie over de termen die worden gebruikt in documentatie

Wanneer u tussen inhoudssets navigeert, ziet u enkele kleine terminologieverschillen. Inhoud die wordt aanbevolen in de documentatie voor Blob Storage, maakt bijvoorbeeld gebruik van de term blob in plaats van bestand. Technisch gezien worden de bestanden die u uploadt naar uw opslagaccount blobs in uw account. Daarom is de term juist. De term blob kan echter verwarring veroorzaken als u gewend bent aan de term bestand. U ziet ook de term container die wordt gebruikt om te verwijzen naar een bestandssysteem. Beschouw deze termen als synoniem.

Overweeg premium

Als uw workloads een constant lage latentie of een groot aantal I/O-bewerkingen per seconde (IOPS) vereisen, overweeg dan een premium-opslagaccount voor blok-blobs te gebruiken. Dit type account maakt gegevens beschikbaar via krachtige hardware. Gegevens worden opgeslagen op SSD's (Solid State Drives), die zijn geoptimaliseerd voor lage latentie. SSD's bieden een hogere doorvoer in vergelijking met traditionele harde schijven. De opslagkosten van premiumprestaties zijn hoger, maar transactiekosten zijn lager. Als uw workloads daarom een groot aantal transacties uitvoeren, kan een Premium Performance Block Blob-account voordelig zijn.

Als uw opslagaccount wordt gebruikt voor analyse, raden we u ten zeerste aan Azure Data Lake Storage te gebruiken samen met een premium blok-blob-opslagaccount. Deze combinatie van premium blok-blob-opslagaccounts samen met een Data Lake Storage-account wordt de Premium-laag voor Azure Data Lake Storage genoemd.

Optimaliseren voor datainvoer

Wanneer u gegevens uit een bronsysteem opneemt, kunnen de bronhardware, de bronnetwerkhardware of de netwerkverbinding met uw opslagaccount knelpunten maken.

Hardwarebronnen

Of u nu on-premises machines of virtuele machines (VM's) in Azure gebruikt, selecteer de juiste hardware zorgvuldig. Voor schijfhardware kunt u ssd's (solid-state drives) gebruiken en schijfhardware kiezen met snellere spindels. Gebruik voor netwerkhardware de snelste netwerkinterfacecontrollers (NIC) die mogelijk zijn. Gebruik in Azure Azure D14-VM's met de juiste krachtige schijf- en netwerkhardware.

Netwerkverbinding met het opslagaccount

De netwerkverbinding tussen uw brongegevens en uw opslagaccount kan soms een knelpunt vormen. Wanneer uw brongegevens on-premises zijn, kunt u overwegen om een speciale koppeling met Azure ExpressRoute te gebruiken. Als uw brongegevens zich in Azure bevinden, kunnen de prestaties het beste worden uitgevoerd wanneer de gegevens zich in dezelfde Azure-regio bevinden als uw Data Lake Storage-account.

Hulpprogramma's voor gegevensopname configureren voor maximale parallelle uitvoering

Gebruik alle beschikbare doorvoer om de beste prestaties te krijgen door zoveel mogelijk lees- en schrijfbewerkingen parallel uit te voeren.

De volgende tabel bevat een overzicht van de belangrijkste instellingen voor verschillende populaire data-ingestietools.

Zie Migratieprogramma's selecteren voor een volledigere lijst met invoertools.

Uw account kan worden geschaald om de benodigde doorvoer voor alle analysescenario's te bieden. Standaard biedt een Data Lake Storage-account voldoende doorvoer in de standaardconfiguratie om te voldoen aan de behoeften van een brede categorie gebruiksvoorbeelden. Als u de standaardlimiet bereikt, neemt u contact op met Azure Ondersteuning om uw account te configureren om meer doorvoer te bieden.

Gestructureerde gegevenssets

Overweeg de structuur van uw gegevens vooraf te plannen. Bestandsindeling, bestandsgrootte en mapstructuur kunnen allemaal van invloed zijn op de prestaties en kosten.

Bestandsindelingen

U kunt gegevens opnemen in verschillende indelingen. Gegevens kunnen worden weergegeven in door mensen leesbare indelingen, zoals JSON, CSV of XML, of als gecomprimeerde binaire indelingen, zoals .tar.gz. Gegevens kunnen in verschillende grootten worden geleverd. Gegevens kunnen bestaan uit grote bestanden (een paar terabytes), zoals gegevens uit een export van een SQL-tabel uit uw on-premises systemen. Gegevens kunnen ook worden geleverd in de vorm van een groot aantal kleine bestanden (een paar kilobytes), zoals gegevens uit realtimegebeurtenissen van een IoT-oplossing (Internet of Things). U kunt de efficiëntie en kosten optimaliseren door een geschikte bestandsindeling en bestandsgrootte te kiezen.

Hadoop ondersteunt een set bestandsindelingen die zijn geoptimaliseerd voor het opslaan en verwerken van gestructureerde gegevens. Sommige veelgebruikte indelingen zijn avro-, Parquet- en ORC-indeling (Optimized Row Columnar). Al deze indelingen zijn machineleesbare binaire bestandsindelingen. Ze worden gecomprimeerd om u te helpen bij het beheren van de bestandsgrootte. Ze hebben een schema dat is ingesloten in elk bestand, waardoor ze zelfbeschrijfd worden. Het verschil tussen deze indelingen is de wijze waarop gegevens worden opgeslagen. Avro slaat gegevens op in een rijindeling en de Parquet- en ORC-indelingen slaan gegevens op in een kolomindeling.

Gebruik de Avro-bestandsindeling wanneer uw I/O-patronen meer schrijfintensief zijn, of de querypatronen geven de voorkeur aan het ophalen van meerdere rijen met records in hun geheel. De Avro-indeling werkt bijvoorbeeld goed met een berichtenbus zoals Event Hubs of Kafka die meerdere gebeurtenissen of berichten achter elkaar schrijven.

Gebruik Parquet- en ORC-bestandsindelingen wanneer de I/O-patronen meer leesintensief zijn of wanneer de querypatronen zijn gericht op een subset van kolommen in de records. Leestransacties kunnen worden geoptimaliseerd om specifieke kolommen op te halen in plaats van de hele record te lezen.

Apache Parquet is een opensource-bestandsindeling die is geoptimaliseerd voor leesintensieve analysepijplijnen. Met de kolomopslagstructuur van Parquet kunt u niet-relevante gegevens overslaan. Uw query's zijn veel efficiënter omdat ze het bereik kunnen beperken van welke gegevens moeten worden verzonden van opslag naar de analyse-engine. Omdat vergelijkbare gegevenstypen (voor een kolom) samen worden opgeslagen, ondersteunt Parquet ook efficiënte gegevenscompressie- en coderingsschema's die de kosten voor gegevensopslag kunnen verlagen. Services zoals Azure Synapse Analytics, Azure Databricks en Azure Data Factory hebben systeemeigen functionaliteit die profiteert van Parquet-bestandsindelingen.

Bestandsgrootte

Grotere bestanden leiden tot betere prestaties en lagere kosten.

Analyse-engines zoals HDInsight hebben doorgaans een overhead per bestand die taken omvat, zoals het weergeven, controleren van de toegang en het uitvoeren van verschillende metagegevensbewerkingen. Als u uw gegevens zo veel kleine bestanden opslaat, kan deze keuze de prestaties negatief beïnvloeden. In het algemeen kunt u uw gegevens ordenen in grotere bestanden voor betere prestaties (256 MB tot 100 GB). Sommige engines en toepassingen kunnen problemen ondervinden bij het efficiënt verwerken van bestanden die groter zijn dan 100 GB.

Het vergroten van de bestandsgrootte kan ook de transactiekosten verlagen. Lees- en schrijfbewerkingen worden gefactureerd in stappen van 4 megabyte, zodat er kosten in rekening worden gebracht voor bewerkingen, ongeacht of het bestand 4 megabytes of slechts een paar kilobytes bevat. Zie Prijzen voor Azure Data Lake Storage voor meer informatie.

Soms hebben gegevenspijplijnen beperkte controle over de onbewerkte gegevens, die veel kleine bestanden bevatten. Over het algemeen moet uw systeem een soort proces hebben om kleine bestanden samen te voegen in grotere bestanden voor gebruik door downstreamtoepassingen. Als u gegevens in realtime verwerkt, kunt u een realtime streaming-engine (zoals Azure Stream Analytics of Spark Streaming) gebruiken met een berichtenbroker (zoals Event Hubs of Apache Kafka) om uw gegevens op te slaan als grotere bestanden. Wanneer u kleine bestanden samenvoegt in grotere bestanden, kunt u deze opslaan in een indeling die is geoptimaliseerd voor lezen, zoals Apache Parquet voor downstreamverwerking.

Mappenstructuur

Elke workload heeft verschillende vereisten voor de manier waarop gegevens worden gebruikt. Houd bij het werken met Internet of Things (IoT), batchscenario's of bij het optimaliseren van tijdreeksgegevens echter rekening met deze algemene indelingen.

IoT-structuur

In IoT-workloads kunt u een grote hoeveelheid gegevens opnemen die talloze producten, apparaten, organisaties en klanten omvat. Plan de indeling van de map vooraf voor de organisatie, beveiliging en efficiënte verwerking van de gegevens voor downstreamgebruikers. Een algemene sjabloon die u moet overwegen, kan de volgende indeling zijn:

• {Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/

Landingstelemetrie voor een vliegtuigmotor in het VERENIGD Koninkrijk kan er bijvoorbeeld uitzien als de volgende structuur:

• UK/Planes/BA1293/Engine1/2017/08/11/12/

In dit voorbeeld kunt u ACL's gebruiken om de datum aan het einde van de adreslijststructuur te plaatsen om regio's gemakkelijker te beveiligen en zaken te onderwerpen aan specifieke gebruikers en groepen. Als u de datumstructuur aan het begin plaatst, is het veel moeilijker om deze regio's en onderwerpen te beveiligen. Als u bijvoorbeeld alleen toegang wilt verlenen tot UK-gegevens of gegevens van bepaalde vliegtuigen, moet u een afzonderlijke machtiging toepassen voor talloze directory's onder elke uur-directory. Deze structuur zou ook het aantal directory's exponentieel verhogen naarmate de tijd verstrijkt.

Structuur batchtaken

Een veelgebruikte benadering in batchverwerking is het plaatsen van gegevens in een map 'in'. Nadat de gegevens zijn verwerkt, plaatst u de nieuwe gegevens in een 'out'-map, zodat vervolgprocessen deze kunnen gebruiken. Deze mapstructuur wordt soms gebruikt voor taken waarvoor verwerking van afzonderlijke bestanden is vereist en die mogelijk geen enorme parallelle verwerking van grote gegevenssets vereisen. Net zoals de hierboven aanbevolen IoT-structuur heeft een goede directory-structuur de directory's op het hoofdniveau voor zaken zoals regio en onderwerp (bijvoorbeeld organisatie, product of producent). Overweeg datum en tijd in de structuur om betere organisatie, gefilterde zoekopdrachten, beveiliging en automatisering in de verwerking mogelijk te maken. Het granulariteitsniveau voor de datumstructuur wordt bepaald door het interval waarop de gegevens worden geüpload of verwerkt, zoals elk uur, dagelijks of zelfs maandelijks.

Soms is bestandsverwerking mislukt vanwege beschadigde gegevens of onverwachte indelingen. In dergelijke gevallen kan een mapstructuur profiteren van een /slecht map om de bestanden voor verdere inspectie naartoe te verplaatsen. De batchtaak kan ook de rapportage of melding van deze ongeldige bestanden verwerken voor handmatige interventie. Houd rekening met de volgende sjabloonstructuur:

• {Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/
• {Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/
• {Regio}/{Onderwerp(en)}/Slecht/{jjjj}/{mm}/{dd}/{uu}/

Een marketingbedrijf ontvangt bijvoorbeeld dagelijkse gegevens van klantupdates van hun klanten in Noord-Amerika. Het kan eruitzien als het volgende fragment voor en na verwerking:

• NA/Extracts/ACMEPaperCo/In/2017/08/14/updates_08142017.csv
• NA/Extracts/ACMEPaperCo/Out/2017/08/14/processed_updates_08142017.csv

In het gebruikelijke geval van batchdata die rechtstreeks naar databases zoals Hive of traditionele SQL-databases worden verwerkt, is er geen in- of out-map nodig, omdat de uitvoer al in een afzonderlijke map voor de Hive-tabel of externe database terechtkomt. Dagelijkse extracten van klanten komen bijvoorbeeld terecht in hun respectieve directory's. Vervolgens activeert een service zoals Azure Data Factory, Apache Oozie of Apache Airflow een dagelijkse Hive- of Spark-taak om de gegevens te verwerken en te schrijven in een Hive-tabel.

Tijdreeksgegevensstructuur

Voor Hive-workloads kan partitionering van tijdreeksgegevens helpen sommige query's alleen een subset van de gegevens te lezen, waardoor de prestaties worden verbeterd.

Deze pijplijnen die tijdreeksgegevens opnemen, plaatsen hun bestanden vaak met een gestructureerde naamgeving voor bestanden en mappen. Hieronder ziet u een algemeen voorbeeld voor gegevens die zijn gestructureerd op datum:

/DataSet/JJJJ/MM/DD/datafile_YYYY_MM_DD.tsv

U ziet dat de datum/tijd-informatie zowel als mappen als in de bestandsnaam wordt weergegeven.

Voor datum en tijd is het volgende een gemeenschappelijk patroon

/DataSet/YYYY/MM/DD/HH/mm/datafile_YYYY_MM_DD_HH_mm.tsv

Nogmaals, de keuze die u maakt met de map en bestandsorganisatie moet optimaliseren voor de grotere bestandsgrootten en een redelijk aantal bestanden in elke map.

Beveiliging instellen

Bekijk eerst de aanbevelingen in het artikel Beveiligingsaanbevelingen voor Blob-opslag. U vindt best practice-richtlijnen voor het beveiligen van uw gegevens tegen onbedoelde of schadelijke verwijdering, het beveiligen van gegevens achter een firewall en het gebruik van Microsoft Entra ID als basis van identiteitsbeheer.

Lees vervolgens het Access Control-model in Azure Data Lake Storage voor richtlijnen die specifiek zijn voor accounts met Data Lake Storage. Dit artikel helpt u inzicht te krijgen in het gebruik van azure RBAC-rollen (op rollen gebaseerd toegangsbeheer) in combinatie met toegangsbeheerlijsten (ACL's) voor het afdwingen van beveiligingsmachtigingen voor mappen en bestanden in uw hiërarchische bestandssysteem.

Opnemen, verwerken en analyseren

U kunt gegevens opnemen in een account met Data Lake Storage ingeschakeld vanuit veel verschillende bronnen en op veel verschillende manieren.

U kunt bijvoorbeeld grote sets gegevens opnemen uit HDInsight- en Hadoop-clusters of kleinere sets met ad-hocgegevens voor prototypetoepassingen. U kunt gestreamde gegevens opnemen die door verschillende bronnen worden gegenereerd, zoals toepassingen, apparaten en sensoren. Gebruik voor dit type gegevens hulpprogramma's om de gegevens in realtime vast te leggen en te verwerken en de gebeurtenissen vervolgens in batches in uw account te schrijven. U kunt ook webserverlogboeken opnemen, die informatie bevatten, zoals de geschiedenis van paginaaanvragen. Voor logboekgegevens kunt u aangepaste scripts of toepassingen schrijven om ze te uploaden, zodat u de flexibiliteit hebt om uw gegevens te uploaden als onderdeel van uw grotere big data-toepassing.

Zodra de gegevens beschikbaar zijn in uw account, kunt u analyses uitvoeren op die gegevens, visualisaties maken en zelfs gegevens downloaden naar uw lokale computer of naar andere opslagplaatsen, zoals een Azure SQL-database of EEN SQL Server-exemplaar.

In de volgende tabel worden hulpprogramma's aanbevolen die u kunt gebruiken voor het opnemen, analyseren, visualiseren en downloaden van gegevens. Gebruik de koppelingen in deze tabel voor hulp bij het configureren en gebruiken van elk hulpprogramma.

Telemetrie bewaken

Het bewaken van het gebruik en de prestaties van uw service is een belangrijk onderdeel van het operationeel maken van uw service. Voorbeelden van telemetrie zijn frequente bewerkingen, bewerkingen met hoge latentie of bewerkingen die leiden tot beperking aan de servicezijde.

U hebt toegang tot alle telemetriegegevens voor uw opslagaccount via Azure Storage logboeken in Azure Monitor. Deze functie integreert uw opslagaccount met Log Analytics en Event Hubs, terwijl u ook logboeken kunt archiveren naar een ander opslagaccount. Als u de volledige lijst met metrische gegevens en resourcelogboeken en het bijbehorende schema wilt bekijken, raadpleegt u Azure Storage naslaginformatie over bewakingsgegevens.

Waar u ervoor kiest om uw logboeken op te slaan, is afhankelijk van hoe u deze wilt openen. Als u bijvoorbeeld in bijna realtime toegang wilt tot uw logboeken en gebeurtenissen in logboeken wilt correleren met andere metrische gegevens uit Azure Monitor, slaat u uw logboeken op in een Log Analytics werkruimte. Voer vervolgens query's uit op uw logboeken met behulp van KQL en ontwerpquery's, waarmee de StorageBlobLogs tabel in uw werkruimte wordt opgesomd.

Als u uw logboeken wilt opslaan voor zowel bijna realtime query's als langetermijnretentie, configureert u uw diagnostische instellingen om logboeken te verzenden naar zowel een Log Analytics werkruimte als een opslagaccount.

Als u uw logboeken wilt openen via een andere query-engine, zoals Splunk, configureert u uw diagnostische instellingen om logboeken naar een Event Hub te verzenden en logboeken op te nemen van de Event Hub naar de door u gekozen bestemming.

U kunt Azure Storage logboeken in Azure Monitor inschakelen via de Azure-portal, PowerShell, de Azure CLI en Azure Resource Manager-sjablonen. Gebruik voor implementaties op schaal Azure Policy met volledige ondersteuning voor hersteltaken. Zie ciphertxt/AzureStoragePolicy voor meer informatie.

Zie ook

• Leidinggevende strategie voor het combineren van uw gegevens
• Toegangsbeheermodel in Azure Data Lake Storage
• Het lifter's handboek voor de Data Lake
• Overzicht van Azure Data Lake Storage