Metodtips för att använda Azure Data Lake Storage Gen2

Den här artikeln innehåller riktlinjer för bästa praxis som hjälper dig att optimera prestanda, minska kostnaderna och skydda ditt Data Lake Storage Gen2-Azure Storage konto.

Hitta dokumentation

Azure Data Lake Storage Gen2 är inte en dedikerad tjänst eller kontotyp. Det är en uppsättning funktioner som stöder analytiska arbetsbelastningar med högt dataflöde. Dokumentationen för Data Lake Storage Gen2 innehåller metodtips och vägledning för att använda dessa funktioner. Läs dokumentationen om Blob Storage för alla andra aspekter av kontohanteringen, till exempel att konfigurera nätverkssäkerhet, designa för hög tillgänglighet och haveriberedskap.

Utvärdera funktioner och kända problem

Använd följande mönster när du konfigurerar ditt konto för att använda Blob Storage-funktioner.

1. Läs artikeln stöd Storage blob-Azure Storage för att avgöra om en funktion stöds fullt ut i ditt konto. Vissa funktioner stöds inte ännu eller har delvis stöd i Data Lake Storage Gen2-aktiverade konton. Funktionsstöd utökas alltid, så se till att regelbundet granska den här artikeln för uppdateringar.

2. Läs artikeln Known issues with Azure Data Lake Storage Gen2 (Kända problem med Azure Data Lake Storage Gen2) för att se om det finns några begränsningar eller särskild vägledning kring den funktion som du tänker använda.

3. Sök igenom funktionsartiklar för all vägledning som är specifik för Data Lake Storage Gen2-aktiverade konton.

Förstå de termer som används i dokumentationen

När du flyttar mellan innehållsuppsättningar ser du några små skillnader i terminologin. Innehåll som finns i bloblagringsdokumentationen användertill exempel termen blob i stället för filen. Tekniskt sett blir de filer som du matar in till ditt lagringskonto blobar i ditt konto. Därför är termen korrekt. Detta kan dock orsaka förvirring om du använder termen fil. Du ser även termen container som används för att referera till ett filsystem. De här termerna är synonyma.

Överväg premium

Om dina arbetsbelastningar kräver en låg konsekvent svarstid och/eller kräver ett stort antal indatautdataåtgärder per sekund (IOP) bör du överväga att använda ett premiumkonto för blockbloblagring. Den här typen av konto gör data tillgängliga via högpresterande maskinvara. Data lagras på SSD-enheter (Solid State Drives) som är optimerade för korta svarstider. SSD:er ger högre dataflöde jämfört med traditionella hårddiskar. Lagringskostnaderna för premiumprestanda är högre, men transaktionskostnaderna är lägre, så om dina arbetsbelastningar kör ett stort antal transaktioner kan ett blockblobkonto med premiumprestanda vara ekonomiskt.

Om ditt lagringskonto ska användas för analys rekommenderar vi starkt att du använder Azure Data Lake Storage Gen2 tillsammans med ett premiumkonto för blockbloblagring. Den här kombinationen av att använda premium-blockbloblagringskonton tillsammans med ett Data Lake Storage-aktiverat konto kallas premiumnivånför Azure Data Lake Storage .

Optimera för datainmatning

När du matar in data från ett källsystem kan källmaskinvaran, källnätverksmaskinvaran eller nätverksanslutningen till ditt lagringskonto vara en flaskhals.

Källmaskinvara

Oavsett om du använder lokala datorer eller Virtual Machines (VM) i Azure måste du noga välja lämplig maskinvara. För diskmaskinvara kan du överväga att använda SSD-enheter (Solid State Drives) och välja diskmaskinvara som har snabbare axlar. För nätverksmaskinvara använder du de snabbaste nätverkskorten (NIC) som möjligt. På Azure rekommenderar vi virtuella Azure D14-datorer som har rätt kraftfull disk- och nätverksmaskinvara.

Nätverksanslutning till lagringskontot

Nätverksanslutningen mellan dina källdata och ditt lagringskonto kan ibland vara en flaskhals. När dina källdata är lokala bör du överväga att använda en dedikerad länk med Azure ExpressRoute. Om dina källdata finns i Azure är prestandan bäst när data finns i samma Azure-region som ditt Data Lake Storage Gen2-aktiverat konto.

Konfigurera datainmatningsverktyg för maximal parallellisering

Du får bästa möjliga prestanda genom att använda alla tillgängliga dataflöden genom att utföra så många läsningar och skrivningar parallellt som möjligt.

I följande tabell sammanfattas nyckelinställningarna för flera populära inmatningsverktyg.

Ditt konto kan skalas för att tillhandahålla det nödvändiga dataflödet för alla analysscenarier. Som standard ger ett Data Lake Storage Gen2-aktiverat konto tillräckligt dataflöde i standardkonfigurationen för att uppfylla behoven i en bred kategori av användningsfall. Om du får en standardgräns kan kontot konfigureras för att ge mer dataflöde genom att kontakta Azure Support.

Strukturera datauppsättningar

Överväg att planera strukturen för dina data i förväg. Filformat, filstorlek och katalogstruktur kan påverka prestanda och kostnader.

Filformat

Data kan matas in i olika format. Data kan visas i läsbara format som JSON, CSV eller XML eller som komprimerade binära format som .tar.gz . Data kan även komma i olika storlekar. Data kan bestå av stora filer (några terabyte), till exempel data från en export av en SQL-tabell från dina lokala system. Data kan också komma i form av ett stort antal små filer (några kilobyte), till exempel data från realtidshändelser från en IoT-lösning (Sakernas Internet). Du kan optimera effektiviteten och kostnaderna genom att välja ett lämpligt filformat och en lämplig filstorlek.

Hadoop stöder en uppsättning filformat som är optimerade för att lagra och bearbeta strukturerade data. Några vanliga format är Avro-, Parquet- och Optimized Row Columnar-format (ORC). Alla dessa format är maskinläsbara binära filformat. De komprimeras för att hjälpa dig att hantera filstorleken. De har ett schema inbäddat i varje fil, vilket gör dem självbeskrivande. Skillnaden mellan dessa format är hur data lagras. Avro lagrar data i ett radbaserat format och Parquet- och ORC-formaten lagrar data i kolumnformat.

Överväg att använda Avro-filformatet om dina I/O-mönster är mer skrivtunga, eller om frågemönstren är bra att hämta flera rader med poster i sin helhet. Avro-formatet fungerar till exempel bra med en meddelandebuss som Event Hub eller Kafka som skriver flera händelser/meddelanden i följd.

Överväg Parquet- och ORC-filformat när I/O-mönstren är mer lästa eller när frågemönstren fokuserar på en delmängd av kolumnerna i posterna. Lästransaktioner kan optimeras för att hämta specifika kolumner i stället för att läsa hela posten.

Apache Parquet är ett filformat med öppen källkod som är optimerat för lästunga analyspipelines. Med den kolumnbaserade lagringsstrukturen i Parquet kan du hoppa över icke-relevanta data. Dina frågor är mycket effektivare eftersom de kan begränsa omfånget för vilka data som ska skickas från lagringen till analysmotorn. Eftersom liknande datatyper (för en kolumn) lagras tillsammans stöder Parquet effektiv datakomprimering och kodningsscheman som kan sänka kostnaderna för datalagring. Tjänster som Azure Synapse Analytics, Azure Databricks och Azure Data Factory har inbyggda funktioner som utnyttjar Parquet-filformat.

Filstorlek

Större filer leder till bättre prestanda och lägre kostnader.

Vanligtvis har analysmotorer som HDInsight ett extra arbete per fil som omfattar uppgifter som att lista, kontrollera åtkomst och utföra olika metadataåtgärder. Om du lagrar dina data så många små filer kan detta påverka prestanda negativt. I allmänhet kan du ordna dina data i större filer för bättre prestanda (256 MB till 100 GB i storlek). Vissa motorer och program kan ha problem med att effektivt bearbeta filer som är större än 100 GB.

Att öka filstorleken kan också minska transaktionskostnaderna. Läs- och skrivåtgärder faktureras i steg om 4 megabyte, så du debiteras för åtgärden oavsett om filen innehåller 4 megabyte eller bara några få kilobyte. Prisinformation finns i Azure Data Lake Storage priser.

Ibland har datapipelines begränsad kontroll över rådata, som har många små filer. I allmänhet rekommenderar vi att systemet har någon typ av process för att aggregera små filer till större filer för användning av underordnade program. Om du bearbetar data i realtid kan du använda en strömningsmotor i realtid (till exempel Azure Stream Analytics eller Spark Streaming)tillsammans med en meddelandekoordinator (till exempel Event Hub eller Apache Kafka) för att lagra dina data som större filer. När du aggregerar små filer i större bör du spara dem i ett läsoptimerat format, till exempel Apache Parquet för bearbetning nedströms.

Katalogstruktur

Varje arbetsbelastning har olika krav på hur data används, men det här är några vanliga layouter att tänka på när du arbetar med Sakernas Internet (IoT), batchscenarier eller när du optimerar för tidsseriedata.

IoT-struktur

I IoT-arbetsbelastningar kan det finnas mycket data som matas in över flera produkter, enheter, organisationer och kunder. Det är viktigt att planera kataloglayouten i förväg för organisation, säkerhet och effektiv bearbetning av data för nedströmskonsumenter. En allmän mall att överväga kan vara följande layout:

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

Landningstelemetri för en flygplansmotor i Storbritannien kan till exempel se ut som följande struktur:

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

I det här exemplet kan du använda ACL:er för att enklare skydda regioner och ämnesfrågor för specifika användare och grupper genom att lägga till datumet i slutet av katalogstrukturen. Om du sätter datastrukturen i början skulle det vara mycket svårare att skydda dessa regioner och ämnesområden. Om du till exempel bara vill ge åtkomst till storbritanniens data eller vissa plan måste du tillämpa en separat behörighet för flera kataloger under varje timmes katalog. Den här strukturen skulle också exponentiellt öka antalet kataloger allt eftersom tiden gick.

Struktur för Batch-jobb

En vanlig metod vid batchbearbetning är att placera data i en "i"-katalog. När data har bearbetats lägger du sedan de nya data i en "out"-katalog som underordnade processer kan använda. Den här katalogstrukturen används ibland för jobb som kräver bearbetning på enskilda filer och som kanske inte kräver massivt parallell bearbetning över stora datamängder. Precis som IoT-strukturen som rekommenderas ovan har en bra katalogstruktur katalogerna på överordnad nivå för sådant som region och ämne (till exempel organisation, produkt eller producent). Överväg datum och tid i strukturen för att ge bättre organisation, filtrerade sökningar, säkerhet och automatisering i bearbetningen. Detaljnivån för datumstrukturen bestäms av det intervall då data laddas upp eller bearbetas, till exempel varje timme, varje dag eller till och med varje månad.

Ibland misslyckas filbearbetningen på grund av skadade data eller oväntade format. I sådana fall kan en katalogstruktur dra nytta av en /bad-mapp för att flytta filerna till för ytterligare granskning. Batchjobbet kan också hantera rapportering eller meddelanden om dessa dåliga filer för manuella åtgärder. Tänk på följande mallstruktur:

*{Region}/{SubjectMatter(s)}/In/{yyyy}/{mm}/{dd}/{hh}/*\ *{Region}/{SubjectMatter(s)}/Out/{yyyy}/{mm}/{dd}/{hh}/*\ *{Region}/{SubjectMatter(s)}/Bad/{yyyy}/{mm}/{dd}/{hh}/*

Ett marknadsföringsföretag tar till exempel emot dagliga data som extraherar kunduppdateringar från sina kunder i Nordamerika. Det kan se ut som följande kodfragment före och efter bearbetningen:

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

När batchdata bearbetas direkt till databaser som Hive eller traditionella SQL-databaser behöver du inte en /in- eller /out-katalog eftersom utdata redan hamnar i en separat mapp för Hive-tabellen eller den externa databasen. Dagliga extrahering från kunder hamnar till exempel i deras respektive kataloger. Sedan utlöser en tjänst som Azure Data Factory, Apache Oozieeller Apache Airflow ett dagligt Hive- eller Spark-jobb för att bearbeta och skriva data till en Hive-tabell.

Datastruktur för tidsserier

För Hive-arbetsbelastningar kan partitionsens rensning av tidsseriedata hjälpa vissa frågor att endast läsa en delmängd av data, vilket förbättrar prestandan.

De pipelines som matar in tidsseriedata placerar ofta sina filer med ett strukturerat namn för filer och mappar. Nedan visas ett vanligt exempel för data som är strukturerade efter datum:

\DataSet\YYYY\MM\DD\datafile_YYYY_MM_DD.tsv

Observera att datetime-informationen visas både som mappar och i filnamnet.

För datum och tid är följande ett vanligt mönster

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

Återigen bör valet du gör med mappen och filorganisationen optimeras för de större filstorlekarna och ett rimligt antal filer i varje mapp.

Konfigurera säkerhet

Börja med att granska rekommendationerna i artikeln Säkerhetsrekommendationer för Blob Storage. Du hittar riktlinjer för bästa praxis om hur du skyddar dina data mot oavsiktlig eller skadlig borttagning, skyddar data bakom en brandvägg och använder Azure Active Directory (Azure AD) som grund för identitetshantering.

Läs sedan artikeln Access control model in Azure Data Lake Storage Gen2 (Åtkomstkontrollmodell i Azure Data Lake Storage Gen2) för vägledning som är specifik för Data Lake Storage Gen2-aktiverade konton. Den här artikeln hjälper dig att förstå hur du använder roller för rollbaserad åtkomstkontroll i Azure (Azure RBAC) tillsammans med åtkomstkontrollistor (ACL: er) för att tillämpa säkerhetsbehörigheter på kataloger och filer i ditt hierarkiska filsystem.

Mata in, bearbeta och analysera

Det finns många olika datakällor och olika sätt på vilka dessa data kan matas in i ett Data Lake Storage Gen2-aktiverat konto.

Du kan till exempel mata in stora mängder data från HDInsight- och Hadoop-kluster eller mindre uppsättningar ad hoc-data för prototypprogram. Du kan mata in strömmade data som genereras av olika källor, till exempel program, enheter och sensorer. För den här typen av data kan du använda verktyg för att samla in och bearbeta data händelse för händelse i realtid och sedan skriva händelserna i batchar till ditt konto. Du kan också mata in webbservern som innehåller information, till exempel historiken för sidbegäranden. För loggdata kan du skriva anpassade skript eller program för att ladda upp dem så att du får flexibiliteten att inkludera komponenten för datauppladdning som en del av ditt större stordataprogram.

När data är tillgängliga i ditt konto kan du köra analyser på dessa data, skapa visualiseringar och till och med ladda ned data till din lokala dator eller till andra lagringsplatsen, till exempel en Azure SQL-databas eller SQL Server-instans.

I följande tabell rekommenderas verktyg som du kan använda för att mata in, analysera, visualisera och ladda ned data. Använd länkarna i den här tabellen för att få vägledning om hur du konfigurerar och använder varje verktyg.

Övervaka telemetri

Övervakning av användning och prestanda är en viktig del av operationalisering av tjänsten. Exempel är frekventa åtgärder, åtgärder med lång svarstid eller åtgärder som orsakar begränsning på tjänstsidan.

All telemetri för ditt lagringskonto är tillgänglig via Azure Storage loggar i Azure Monitor. Den här funktionen integrerar ditt lagringskonto med Log Analytics och Event Hubs, samtidigt som du kan arkivera loggar till ett annat lagringskonto. En fullständig lista över mått- och resursloggar och deras associerade schema finns i Azure Storage referens för övervakningsdata.

Var du väljer att lagra loggarna beror på hur du planerar att komma åt dem. Om du till exempel vill komma åt loggarna nästan i realtid och kunna korrelera händelser i loggar med andra mått från Azure Monitor kan du lagra loggarna på en Log Analytics-arbetsyta. På så sätt kan du köra frågor mot loggarna med hjälp av KQL och skapa frågor, som räknar StorageBlobLogs upp tabellen på din arbetsyta.

Om du vill lagra dina loggar för både frågor i nära realtid och långsiktig kvarhållning kan du konfigurera diagnostikinställningarna så att de skickar loggar till både en Log Analytics-arbetsyta och ett lagringskonto.

Om du vill komma åt loggarna via en annan frågemotor, till exempel Splunk, kan du konfigurera diagnostikinställningarna för att skicka loggar till en händelsehubb och mata in loggar från händelsehubben till det valda målet.

Azure Storage loggar i Azure Monitor aktiveras via Azure Portal, PowerShell, Azure CLI och Azure Resource Manager mallar. För storskaliga distributioner kan Azure Policy användas med fullständigt stöd för reparationsåtgärder. Mer information finns i Azure/Community-Policy och ciphertxt/AzureStoragePolicy.

Se även

• Åtkomstkontrollmodell i Azure Data Lake Storage Gen2
• Hitchhiker-guiden till Data Lake
• Översikt över Azure Data Lake Storage Gen2