Best practices voor het gebruik van Azure Data Lake Storage Gen2
Dit artikel bevat best practice richtlijnen waarmee u de prestaties kunt optimaliseren, de kosten kunt verlagen en uw Data Lake Storage Gen2-account Azure Storage beveiligen.
Documentatie zoeken
Azure Data Lake Storage Gen2 is geen toegewezen service of accounttype. Het is een set mogelijkheden die ondersteuning bieden voor analyseworkloads met hoge doorvoer. De Data Lake Storage Gen2-documentatie bevat best practices en richtlijnen voor het gebruik van deze mogelijkheden. Raadpleeg de documentatie-inhoud van Blob Storage voor alle andere aspecten van accountbeheer, zoals het instellen van netwerkbeveiliging, ontwerpen voor hoge beschikbaarheid en herstel na noodherstel.
Ondersteuning van functies en bekende problemen evalueren
Gebruik het volgende patroon wanneer u uw account configureert voor het gebruik van Blob Storage-functies.
Lees het artikel Ondersteuning Storage Blob-functies in Azure Storage accounts om te bepalen of een functie volledig wordt ondersteund in uw account. Sommige functies worden nog niet ondersteund of bieden gedeeltelijke ondersteuning in Data Lake Storage Gen2-accounts. Ondersteuning voor functies wordt altijd uitgebreid. Lees daarom regelmatig dit artikel voor updates.
Lees het artikel Known issues with Azure Data Lake Storage Gen2 (Bekende problemen met Azure Data Lake Storage Gen2) om te zien of er beperkingen of speciale richtlijnen zijn voor de functie die u wilt gebruiken.
Scan functieartikelen voor richtlijnen die specifiek zijn voor Data Lake Storage Gen2-accounts.
Inzicht in de termen die worden gebruikt in de documentatie
Als u tussen inhoudssets gaat, ziet u enkele kleine terminologieverschillen. Voor inhoud die bijvoorbeeld wordt vermeld in de documentatie voor Blob Storage,wordt de term blob gebruikt in plaats van bestand. Technisch gezien worden de bestanden die u opslibt in uw opslagaccount blobs in uw account. Daarom is de term juist. Dit kan echter verwarring veroorzaken als u het termbestand gebruikt. U ziet ook de term container die wordt gebruikt om te verwijzen naar een bestandssysteem. U kunt deze termen beschouwen als synoniemen.
Premium overwegen
Als uw workloads een lage consistente latentie vereisen en/of een groot aantal invoeruitvoerbewerkingen per seconde (IOP) vereisen, kunt u overwegen een premium blok-blobopslagaccount te gebruiken. Dit type account maakt gegevens beschikbaar via krachtige hardware. Gegevens worden opgeslagen op SOLID-state drives (SSD's) die zijn geoptimaliseerd voor lage latentie. SSD's bieden een hogere doorvoer in vergelijking met traditionele harde schijven. De opslagkosten van Premium-prestaties zijn hoger, maar de transactiekosten zijn lager, dus als uw workloads een groot aantal transacties uitvoeren, kan een blob-account met premium-prestaties voordelig zijn.
Als uw opslagaccount wordt gebruikt voor analyse, raden we u ten zeerste aan Azure Data Lake Storage Gen2 te gebruiken, samen met een premium blok-blobopslagaccount. Deze combinatie van het gebruik van Premium blok-blobopslagaccounts en een Data Lake Storage ingeschakeld account wordt de Premium-laag voor Azure Data Lake Storage.
Optimaliseren voor gegevensingestie
Bij het opnemen van gegevens uit een bronsysteem kunnen de bronhardware, bronnetwerkhardware of de netwerkverbinding met uw opslagaccount een knelpunt vormen.
Bronhardware
Of u nu on-premises machines of Virtual Machines (VM's) in Azure gebruikt, zorg ervoor dat u zorgvuldig de juiste hardware selecteert. Voor schijfhardware kunt u ssd-schijven (Solid State Drives) gebruiken en schijfhardware kiezen met snellere a spindles. Gebruik voor netwerkhardware de snelste netwerkinterfacecontrollers (NIC) mogelijk. In Azure raden we Azure D14-VM's aan, die de juiste krachtige schijf- en netwerkhardware hebben.
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 toegewezen koppeling met Azure ExpressRoute. Als uw brongegevens zich in Azure, zijn de prestaties het beste wanneer de gegevens zich in dezelfde Azure-regio als uw Data Lake Storage Gen2-account.
Hulpprogramma's voor gegevensopname configureren voor maximale parallellisering
Voor de beste prestaties gebruikt u alle beschikbare doorvoer door zoveel mogelijk lees- en schrijfprestaties parallel uit te voeren.
De volgende tabel bevat een overzicht van de belangrijkste instellingen voor verschillende populaire opnamehulpprogramma's.
| Hulpprogramma | Instellingen |
|---|---|
| DistCp | -m (mapper) |
| Azure Data Factory | parallelCopies |
| Sqoop | fs.azure.block.size, -m (mapper) |
Notitie
De algehele prestaties van uw opnamebewerkingen zijn afhankelijk van andere factoren die specifiek zijn voor het hulpprogramma dat u gebruikt om gegevens op te nemen. Zie de documentatie voor elk hulpprogramma dat u wilt gebruiken voor de beste up-to-date richtlijnen.
Uw account kan worden geschaald om de benodigde doorvoer voor alle analysescenario's te bieden. Een Data Lake Storage Gen2-account biedt standaard voldoende doorvoer in de standaardconfiguratie om te voldoen aan de behoeften van een brede categorie use cases. Als u tegen de standaardlimiet aan komt, kan het account worden geconfigureerd om meer doorvoer te bieden door contact op te nemen met Ondersteuning voor Azure.
Gegevenssets structureren
Overweeg de structuur van uw gegevens vooraf te plannen. Bestandsindeling, bestandsgrootte en mapstructuur kunnen allemaal van invloed zijn op de prestaties en kosten.
Bestandsindelingen
Gegevens kunnen worden opgenomen 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 ook in verschillende grootten worden gebruikt. Gegevens kunnen bestaan uit grote bestanden (een paar terabytes), zoals gegevens uit een export van een SQL tabel van uw on-premises systemen. Gegevens kunnen ook worden gebruikt in de vorm van een groot aantal kleine bestanden (een paar kilobytes), zoals gegevens van realtime gebeurtenissen uit 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. Enkele algemene indelingen zijn avro-, Parquet- en ORC-indelingen (Optimized Row Columnar). Al deze indelingen zijn voor machines leesbare binaire bestandsindelingen. Ze worden gecomprimeerd om u te helpen bij het beheren van de bestandsgrootte. Ze hebben een schema dat in elk bestand is ingesloten, waardoor ze zichzelf beschrijvend maken. Het verschil tussen deze indelingen zit hem in de manier waarop gegevens worden opgeslagen. Avro slaat gegevens op in een op rijen gebaseerde indeling en de Parquet- en ORC-indelingen slaan gegevens op in een kolomindeling.
Overweeg het gebruik van de Avro-bestandsindeling in gevallen waarin uw I/O-patronen veel schrijfwerk hebben, of als de querypatronen de voorkeur geven aan het ophalen van meerdere rijen records in hun geheel. De Avro-indeling werkt bijvoorbeeld goed met een berichtenbus zoals Event Hub of Kafka die meerdere gebeurtenissen/berichten achter elkaar schrijven.
Overweeg Parquet- en ORC-bestandsindelingen wanneer de I/O-patronen meer lezen 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 open source-bestandsindeling die is geoptimaliseerd voor pijplijnen met leeszware analyses. Met de kolomopslagstructuur van Parquet kunt u niet-relevante gegevens overslaan. Uw query's zijn veel efficiënter omdat ze een beperkt bereik kunnen hebben van de gegevens die vanuit de opslag naar de analyse-engine moeten worden verzendt. Omdat vergelijkbare gegevenstypen (voor een kolom) samen worden opgeslagen, ondersteunt Parquet 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 native functionaliteit die gebruik kan maken 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 toegang en het uitvoeren van verschillende bewerkingen met metagegevens. Als u uw gegevens zo veel kleine bestanden opgeslagen, kan dit een negatieve invloed hebben op de prestaties. In het algemeen organiseert u uw gegevens in grotere bestanden voor betere prestaties (256 MB tot 100 GB). Sommige engines en toepassingen kunnen problemen hebben 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 MB, zodat de bewerking in rekening wordt gebracht, ongeacht of het bestand 4 MB of slechts enkele kilobytes bevat. Zie Prijzen voor Azure Data Lake Storage prijsinformatie.
Soms hebben gegevenspijplijnen beperkte controle over de onbewerkte gegevens, die veel kleine bestanden bevatten. Over het algemeen raden we aan dat uw systeem een soort proces heeft voor het samenvoegen van kleine bestanden 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 in samenwerking met een berichtenbroker (zoals Event Hub of Apache Kafka) om uw gegevens als grotere bestanden op te slaan. Wanneer u kleine bestanden in grotere bestanden aggregatiet, kunt u deze opslaan in een voor lees geoptimaliseerde indeling, zoals Apache Parquet, voor downstreamverwerking.
Mapstructuur
Elke workload heeft verschillende vereisten voor de manier waarop de gegevens worden gebruikt, maar dit zijn enkele algemene indelingen om rekening mee te houden bij het werken met Internet of Things (IoT), batchscenario's of bij het optimaliseren van tijdreeksgegevens.
IoT-structuur
In IoT-workloads kunnen er veel gegevens worden opgenomen die verschillende producten, apparaten, organisaties en klanten omvat. Het is belangrijk om de indeling van de directory vooraf te plannen voor de organisatie, beveiliging en efficiënte verwerking van de gegevens voor downstream-gebruikers. Een algemene sjabloon die u kunt overwegen, kan de volgende indeling hebben:
*{Region}/{SubjectMatter(s)}/{yyyy}/{mm}/{dd}/{hh}/*
Zo kan de landingstelemetrie voor een vliegtuigmotor in het VK er als volgt uitzien:
*UK/Planes/BA1293/Engine1/2017/08/11/12/*
In dit voorbeeld kunt u met de datum aan het einde van de directorystructuur ACL's gebruiken om regio's en onderwerpen gemakkelijker te beveiligen voor specifieke gebruikers en groepen. Als u de gegevensstructuur aan het begin zet, is het veel moeilijker om deze regio's en onderwerpen te beveiligen. Als u bijvoorbeeld alleen toegang wilt verlenen tot uk-gegevens of bepaalde vlakken, moet u een afzonderlijke machtiging toepassen voor talloze directory's in de map elk uur. Deze structuur zou ook het aantal directories exponentieel verhogen naarmate de tijd verhoog.
Structuur van Batch-taken
Een veelgebruikte benadering bij batchverwerking is het plaatsen van gegevens in een 'in'-map. Zodra de gegevens zijn verwerkt, zet u de nieuwe gegevens in een out-map die downstreamprocessen kunnen gebruiken. Deze mapstructuur wordt soms gebruikt voor taken waarvoor verwerking van afzonderlijke bestanden is vereist en waarvoor mogelijk geen massively parallel verwerking via grote gegevenssets nodig is. Net als de hierboven aanbevolen IoT-structuur heeft een goede directorystructuur de mappen op bovenliggend niveau voor zaken als regio en onderwerp (bijvoorbeeld organisatie, product of producent). Houd rekening met 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 mislukt de bestandsverwerking vanwege beschadiging van gegevens of onverwachte indelingen. In dergelijke gevallen kan een mapstructuur profiteren van een /bad-map om de bestanden naar te verplaatsen voor verdere inspectie. De batch-taak kan ook de rapportage of melding van deze slechte 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}/*\
*{Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/*
Een marketingbedrijf ontvangt bijvoorbeeld dagelijkse gegevensextracten van klantupdates van hun klanten in Noord-Amerika. Dit kan lijken op het volgende codefragment 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 veelvoorkomende geval dat batchgegevens rechtstreeks worden verwerkt in databases zoals Hive of traditionele SQL-databases, is er geen /in- of /out-map nodig omdat de uitvoer al naar een afzonderlijke map voor de Hive-tabel of externe database gaat. Dagelijkse extracten van klanten komen bijvoorbeeld terecht in hun respectieve directories. Vervolgens activeert een service zoals Azure Data Factory, Apache Oozieof Apache Airflow een dagelijkse Hive- of Spark-taak om de gegevens te verwerken en naar een Hive-tabel te schrijven.
Tijdreeksgegevensstructuur
Voor Hive-workloads kan het verwijderen van partities van tijdreeksgegevens sommige query's helpen om slechts 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\YYYY\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 algemeen 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 worden geoptimaliseerd voor de grotere bestandsgrootten en een redelijk aantal bestanden in elke map.
Beveiliging instellen
Bekijk eerst de aanbevelingen in het artikel Beveiligingsaanbevelingen voor Blob Storage. U vindt hier best practice over het beveiligen van uw gegevens tegen onbedoelde of schadelijke verwijdering, het beveiligen van gegevens achter een firewall en het gebruik van Azure Active Directory (Azure AD) als basis voor identiteitsbeheer.
Lees vervolgens het artikel Access control model in Azure Data Lake Storage Gen2 (Toegangsbeheermodel in Azure Data Lake Storage Gen2) voor richtlijnen die specifiek zijn voor Data Lake Storage Gen2-accounts. Dit artikel helpt u te begrijpen hoe u azure RBAC-rollen (op rollen gebaseerd toegangsbeheer) kunt gebruiken samen met toegangsbeheerlijsten (ACL's) om beveiligingsmachtigingen af te dwingen voor mappen en bestanden in uw hiërarchische bestandssysteem.
Opnemen, verwerken en analyseren
Er zijn veel verschillende gegevensbronnen en verschillende manieren waarop die gegevens kunnen worden opgenomen in een Data Lake Storage Gen2-account.
U kunt bijvoorbeeld grote sets gegevens opnemen uit HDInsight- en Hadoop-clusters of kleinere sets ad-hocgegevens voor het maken van prototypetoepassingen. U kunt gestreamde gegevens opnemen die worden gegenereerd door verschillende bronnen, zoals toepassingen, apparaten en sensoren. Voor dit type gegevens kunt u hulpprogramma's gebruiken om de gegevens per gebeurtenis in realtime vast te leggen en te verwerken en vervolgens de gebeurtenissen in batches naar uw account te schrijven. U kunt ook een webserver opnemen die informatie bevat, 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 onderdeel voor het uploaden van gegevens op te nemen 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.
De volgende tabel raadt hulpprogramma's aan die u kunt gebruiken om gegevens op te nemen, te analyseren, te visualiseren en te downloaden. Gebruik de koppelingen in deze tabel voor hulp bij het configureren en gebruiken van elk hulpprogramma.
Notitie
Deze tabel geeft niet de volledige lijst met Azure-services weer die ondersteuning bieden voor Data Lake Storage Gen2. Zie Azure-services die ondersteuning bieden voor Azure Data Lake Storage Gen2 voor een lijst met ondersteunde Azure-services en hun ondersteuningsniveau.
Telemetrie bewaken
Het bewaken van het gebruik en de prestaties is een belangrijk onderdeel van het operationeel maken van uw service. Voorbeelden zijn frequente bewerkingen, bewerkingen met hoge latentie of bewerkingen die beperking aan de servicezijde veroorzaken.
Alle telemetrie voor uw opslagaccount is beschikbaar via Azure Storage logboeken in Azure Monitor. Deze functie integreert uw opslagaccount met Log Analytics en Event Hubs, terwijl u ook logboeken naar een ander opslagaccount kunt archiveren. Zie bewakingsgegevensverwijzing voor de volledige lijst met metrische gegevens en resourceslogboeken en het bijbehorende schema Azure Storage bewakingsgegevens.
Waar u uw logboeken wilt opslaan, is afhankelijk van hoe u ze wilt openen. Als u bijvoorbeeld bijna in realtime toegang wilt krijgen tot uw logboeken en gebeurtenissen in logboeken wilt correleren met andere metrische gegevens van Azure Monitor, kunt u uw logboeken opslaan in een Log Analytics-werkruimte. Hiermee kunt u query's uitvoeren op uw logboeken met behulp van KQL en query's maken, waarmee de tabel StorageBlobLogs in uw werkruimte wordt opgevraagd.
Als u uw logboeken wilt opslaan voor zowel bijna realtime query's als langetermijnretentie, kunt u uw diagnostische instellingen configureren voor het verzenden van logboeken naar zowel een Log Analytics-werkruimte als een opslagaccount.
Als u toegang wilt tot uw logboeken via een andere query-engine, zoals Splunk, kunt u uw diagnostische instellingen configureren voor het verzenden van logboeken naar een Event Hub en het opnemen van logboeken van de Event Hub naar de door u gekozen bestemming.
Azure Storage logboeken in Azure Monitor kunnen worden ingeschakeld via de Azure Portal-, PowerShell-, Azure CLI- en Azure Resource Manager sjablonen. Voor implementaties op schaal kunnen Azure Policy worden gebruikt met volledige ondersteuning voor hersteltaken. Zie Azure/Community-Policy en ciphertxt/AzureStoragePolicy voor meer informatie.