Dela via

Azure Blob Storage- och Data Lake Storage Gen2-utdata från Stream Analytics

  • Artikel

Azure Data Lake Storage Gen2 gör Azure Storage till grunden för att skapa företagsdatasjöar i Azure. Data Lake Storage Gen2 är utformat för att betjäna flera petabyte med information samtidigt som hundratals gigabit dataflöde bibehålls. Du kan använda den för att enkelt hantera enorma mängder data. En grundläggande del av Data Lake Storage Gen2 är att lägga till ett hierarkiskt namnområde i Azure Blob Storage.

Blob Storage erbjuder en kostnadseffektiv och skalbar lösning för lagring av stora mängder ostrukturerade data i molnet. En introduktion till Blob Storage och dess användning finns i Ladda upp, ladda ned och lista blobar med Azure-portalen.

Kommentar

Information om de beteenden som är specifika för Avro- och Parquet-formaten finns i de relaterade avsnitten i översikten.

Utdatakonfiguration

I följande tabell visas egenskapsnamnen och deras beskrivningar för att skapa en blob eller Data Lake Storage Gen2-utdata.

Egenskapsnamn beskrivning
Utdataalias Ett eget namn som används i frågor för att dirigera frågeutdata till den här bloben.
Lagringskonto Namnet på lagringskontot där du skickar dina utdata.
Lagringskontonyckel Den hemliga nyckel som är associerad med lagringskontot.
Container En logisk gruppering för blobar som lagras i Blob Storage. När du laddar upp en blob till Blob Storage måste du ange en container för den bloben.

Ett dynamiskt containernamn är valfritt. Den stöder en och endast en dynamisk {field} i containernamnet. Fältet måste finnas i utdata och följa principen för containernamn.

Fältdatatypen måste vara string. Om du vill använda flera dynamiska fält eller kombinera statisk text tillsammans med ett dynamiskt fält kan du definiera det i frågan med inbyggda strängfunktioner som CONCAT och LTRIM.
Format för serialisering av händelser Serialiseringsformatet för utdata. JSON, CSV, Avro och Parquet stöds. Delta Lake visas som ett alternativ här. Data är i Parquet-format om Delta Lake har valts. Läs mer om Delta Lake.
Namn på deltasökväg Krävs när händelse serialiseringsformatet är Delta Lake. Sökvägen som används för att skriva Delta Lake-tabellen i den angivna containern. Den innehåller tabellnamnet. Mer information och exempel finns i Skriva till en Delta Lake-tabell.
Write mode Skrivläge styr hur Azure Stream Analytics skriver till en utdatafil. Leverans exakt en gång sker bara när skrivläget är En gång. Mer information finns i nästa avsnitt.
Partitionskolumn Valfritt. Namnet {field} från dina utdata till partition. Endast en partitionskolumn stöds.
Sökvägsmönster Krävs när händelse serialiseringsformatet är Delta Lake. Det filsökvägsmönster som används för att skriva dina blobar i den angivna containern.

I sökvägsmönstret kan du välja att använda en eller flera instanser av datum- och tidsvariablerna för att ange hur ofta blobar skrivs: {date}, {time}.

Om skrivläget är Once (En gång) måste du använda både {date} och {time}.

Du kan använda anpassad blobpartitionering för att ange ett anpassat {field} namn från dina händelsedata för att partitionera blobar. Fältnamnet är alfanumeriskt och kan innehålla blanksteg, bindestreck och understreck. Begränsningar för anpassade fält omfattar följande:
  • Inget dynamiskt anpassat {field} namn tillåts om skrivläget är En gång.
  • Fältnamn är inte skiftlägeskänsliga. Tjänsten kan till exempel inte skilja mellan kolumn ID och kolumn id.
  • Kapslade fält tillåts inte. Använd i stället ett alias i jobbfrågan för att "platta ut" fältet.
  • Uttryck kan inte användas som fältnamn.

Med den här funktionen kan du använda anpassade konfigurationer för datum/tid-formatspecificerare i sökvägen. Anpassade datum-/tidsformat måste anges en i taget och omges av nyckelordet {datetime:\<specifier>} . Tillåtna indata för \<specifier> är yyyy, MM, M, dd, d, HH, H, mm, m, , sseller s. Nyckelordet {datetime:\<specifier>} kan användas flera gånger i sökvägen för att skapa anpassade datum-/tidskonfigurationer.

Exempel:
  • Exempel 1: cluster1/logs/{date}/{time}
  • Exempel 2: cluster1/logs/{date}
  • Exempel 3: cluster1/{client_id}/{date}/{time}
  • Exempel 4: cluster1/{datetime:ss}/{myField} var frågan är SELECT data.myField AS myField FROM Input;
  • Exempel 5: cluster1/year={datetime:yyyy}/month={datetime:MM}/day={datetime:dd}

Tidsstämpeln för den skapade mappstrukturen följer UTC och inte lokal tid. System.Timestamp är den tid som används för all tidsbaserad partitionering.

Filnamngivning använder följande konvention:

{Path Prefix Pattern}/schemaHashcode_Guid_Number.extension

Guid Här representerar den unika identifierare som tilldelats en intern skrivare som skapats för att skriva till en blobfil. Talet representerar indexet för blobblocket.

Exempel på utdatafiler:
  • Myoutput/20170901/00/45434_gguid_1.csv
  • Myoutput/20170901/01/45434_gguid_1.csv

Mer information om den här funktionen finns i Azure Stream Analytics-partitionering av anpassade blobutdata.
Datumformat Krävs när händelse serialiseringsformatet är Delta Lake. Om datumtoken används i prefixsökvägen kan du välja det datumformat som filerna är ordnade i. Ett exempel är YYYY/MM/DD.
Tidsformat Krävs när händelse serialiseringsformatet är Delta Lake. Om tidstoken används i prefixsökvägen anger du det tidsformat som filerna är ordnade i.
Minsta antal rader Antalet minsta rader per batch. För Parquet skapar varje batch en ny fil. Det aktuella standardvärdet är 2 000 rader och det högsta tillåtna värdet är 10 000 rader.
Maximal tid Maximal väntetid per batch. Efter den här tiden skrivs batchen till utdata även om minimikravet för rader inte uppfylls. Det aktuella standardvärdet är 1 minut och det tillåtna maxvärdet är 2 timmar. Om blobutdata har sökvägsmönsterfrekvens kan väntetiden inte vara högre än partitionens tidsintervall.
Encoding Om du använder CSV- eller JSON-format måste kodning anges. UTF-8 är det enda kodningsformat som stöds just nu.
Delimiter Gäller endast för CSV-serialisering. Stream Analytics stöder många vanliga avgränsare för serialisering av CSV-data. Värden som stöds är kommatecken, semikolon, blanksteg, flik och lodrät stapel.
Format Gäller endast för JSON-serialisering. Radavgränsad anger att utdata formateras genom att varje JSON-objekt avgränsas med en ny rad. Om du väljer Radavgränsad läss JSON ett objekt i taget. Hela innehållet i sig skulle inte vara en giltig JSON. Matrisen anger att utdata formateras som en matris med JSON-objekt. Den här matrisen stängs endast när jobbet stoppas eller Stream Analytics har gått vidare till nästa tidsfönster. I allmänhet är det bättre att använda radavgränsad JSON eftersom det inte kräver någon särskild hantering medan utdatafilen fortfarande skrivs till.

Leverans exakt en gång (offentlig förhandsversion)

Leverans från slutpunkt till slutpunkt exakt en gång vid läsning av strömmande indata innebär att bearbetade data skrivs till Data Lake Storage Gen2-utdata en gång utan dubbletter. När funktionen är aktiverad garanterar Stream Analytics-jobbet ingen dataförlust och inga dubbletter skapas som utdata, över användarinitierad omstart från den senaste utdatatiden. Det förenklar din strömningspipeline genom att inte behöva implementera och felsöka dedupliceringslogik.

Write mode

Det finns två sätt som Stream Analytics skriver till ditt Blob Storage- eller Data Lake Storage Gen2-konto. Ett sätt är att lägga till resultat antingen i samma fil eller till en sekvens med filer när resultaten kommer in. Det andra sättet är att skriva efter alla resultat för tidspartitionen, när alla data för tidspartitionen är tillgängliga. Leverans exakt en gång aktiveras när skrivläget är En gång.

Det finns inget alternativ för skrivläge för Delta Lake. Delta Lake-utdata ger dock också garantier exakt en gång med hjälp av Delta-loggen. Det kräver inte tidspartition och skriver resultat kontinuerligt baserat på de batchparametrar som användaren definierade.

Kommentar

Om du föredrar att inte använda förhandsgranskningsfunktionen för leverans exakt en gång väljer du Lägg till som resultat.

Konfiguration

För att få leverans exakt en gång för ditt Blob Storage- eller Data Lake Storage Gen2-konto måste du konfigurera följande inställningar:

  • Välj En gång när alla resultat av tidspartitionen är tillgängliga för ditt skrivläge.
  • Ange sökvägsmönster med både {date} och {time} angivet.
  • Ange datumformat och tidsformat.

Begränsningar

  • Underström stöds inte.
  • Path Pattern blir en obligatorisk egenskap och måste innehålla både {date} och {time}. Inget dynamiskt anpassat {field} namn tillåts. Läs mer om mönster för anpassad sökväg.
  • Om jobbet startas vid en anpassad tidpunkt före eller efter den senaste utdatatiden finns det en risk att filen skrivs över. När tidsformatet till exempel är inställt på HH genereras filen varje timme. Om du stoppar jobbet 08:15 och startar om jobbet kl. 08:30 täcker filen som genereras mellan 08:00 och 09:00 endast data från 08:30 till 09:00. Data från 08:00 till 08:15 går förlorade när de skrivs över.

Blobutdatafiler

När du använder Blob Storage som utdata skapas en ny fil i bloben i följande fall:

  • Filen överskrider det maximala antalet tillåtna block (för närvarande 50 000). Du kan nå det högsta tillåtna antalet block utan att nå den högsta tillåtna blobstorleken. Om utdatafrekvensen till exempel är hög kan du se fler byte per block och filstorleken är större. Om utdatahastigheten är låg har varje block mindre data och filstorleken är mindre.
  • Det finns en schemaändring i utdata och utdataformatet kräver fast schema (CSV, Avro eller Parquet).
  • Ett jobb startas om, antingen externt av en användare som stoppar det och startar det eller internt för systemunderhåll eller felåterställning.
  • Frågan är helt partitionerad och en ny fil skapas för varje utdatapartition. Det kommer från användning PARTITION BY eller den inbyggda parallellisering som introducerades i kompatibilitetsnivå 1.2.
  • Användaren tar bort en fil eller en container för lagringskontot.
  • Utdata partitioneras med hjälp av sökvägsprefixmönstret och en ny blob används när frågan flyttas till nästa timme.
  • Utdata partitioneras av ett anpassat fält och en ny blob skapas per partitionsnyckel om den inte finns.
  • Utdata partitioneras av ett anpassat fält där kardinaliteten för partitionsnyckeln överskrider 8 000 och en ny blob skapas per partitionsnyckel.

Partitionering

För partitionsnyckel använder {date} du och {time} token från händelsefälten i sökvägsmönstret. Välj datumformat, till exempel YYYY/MM/DD, DD/MM/YYYYeller MM-DD-YYYY. HH används för tidsformatet. Blobutdata kan partitioneras med ett enda anpassat händelseattribut {fieldname} eller {datetime:\<specifier>}. Antalet utdataskrivare följer indatapartitioneringen för fullständigt parallelliserbara frågor.

Batchstorlek för utdata

Den maximala meddelandestorleken finns i Azure Storage-gränser. Den maximala blobblockstorleken är 4 MB och det maximala antalet blobblock är 50 000.

Begränsningar

  • Om en snedstreckssymbol (/) används i sökvägsmönstret (till exempel /folder2/folder3), skapas tomma mappar och de visas inte i Storage Explorer.
  • Stream Analytics lägger till i samma fil i fall där en ny blobfil inte behövs. Det kan leda till att fler utlösare genereras om Azure-tjänster som Azure Event Grid har konfigurerats för att utlösas i en blobfiluppdatering.
  • Stream Analytics lägger till i en blob som standard. När utdataformatet är en JSON-matris slutförs filen vid avstängning eller när utdata flyttas till nästa gång partitionen för tidspartitionerade utdata. I vissa fall, till exempel en oren omstart, är det möjligt att den avslutande hakparentesen (]) för JSON-matrisen saknas.

Relaterat innehåll