Blob Storage och Azure Data Lake Gen2-utdata från Azure Stream Analytics
Data Lake Storage Gen2 gör Azure Storage till grunden för att skapa företagsdatasjöar i Azure. Data Lake Storage Gen2 har utformats från början till att betjäna flera petabyte med information och samtidigt upprätthålla hundratals gigabit dataflöde, så att du enkelt kan hantera enorma mängder data. En grundläggande del av Data Lake Storage Gen2 är att lägga till ett hierarkiskt namnområde i Blob Storage.
Azure 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
Mer 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 Azure 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 bloblagringen. |
| 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 Azure Blob-tjänsten. När du laddar upp en blob till blobtjänsten måste du ange en container för bloben. 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 dynamiskt fält kan du definiera det i frågan med inbyggda strängfunktioner som CONCAT, LTRIM osv. |
| Format för serialisering av händelser | Serialiseringsformat 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 event 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. |
| Skrivläge | Skrivläge styr hur Azure Stream Analytics skriver till utdatafilen. Exakt en gång sker leverans endast när skrivläge ä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 event 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:
Med den här funktionen kan du använda anpassade konfigurationer för datum/tid-formatspecificerare i sökvägen. Anpassade datum- och tidsformat måste anges en i taget, som omges av nyckelordet {datetime:<specifier>}. Tillåtna indata för <specificeraren> är åååå, MM, M, dd, d, d, HH, H, mm, m, ss eller s. Nyckelordet {datetime:<specifier>} kan användas flera gånger i sökvägen för att skapa anpassade datum-/tidskonfigurationer. Exempel:
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: {Mönster för sökvägsprefix}/schemaHashcode_Guid_Number.extension Här representerar Guid den unika identifierare som tilldelats en intern skrivare som skapas för att skriva till en blobfil. Talet representerar indexet för blobblocket. Exempel på utdatafiler:
Mer information om den här funktionen finns i Azure Stream Analytics-partitionering av anpassade blobutdata. |
| Datumformat | Krävs när event serialiseringsformatet är Delta lake. Om datumtoken används i prefixsökvägen kan du välja det datumformat som filerna är ordnade i. Exempel: ÅÅÅÅ/MM/DD |
| Tidsformat | Krävs när event 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 en 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. |
Exakt en gång leverans (offentlig förhandsversion)
Från slutpunkt till slutpunkt exakt en gång när du läser strömmande indata innebär att bearbetade data skrivs till Azure 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 senaste utdatatid. Det förenklar din strömningspipeline avsevärt genom att du inte behöver implementera och felsöka dedupliceringslogik.
Skrivläge
Det finns två sätt som Stream Analytics skriver till ditt Blob Storage- eller ADLS Gen2-konto. Det ena är att lägga till resultat antingen i samma fil eller till en sekvens med filer när resultaten kommer in. Den andra är att skriva efter alla resultat för tidspartitionen när alla data för tidspartitionen är tillgängliga. Exakt när leveransen är aktiverad när skrivläget är En gång.
Det finns inget alternativ för skrivläge för Delta Lake. Men Delta Lake-utdata ger också exakt en gång garantier med hjälp av deltaloggen. Det kräver inte tidspartition och skulle skriva resultat kontinuerligt baserat på de batchparametrar som användaren definierade.
Kommentar
Om du föredrar att inte använda förhandsgranskningsfunktionen för exakt en gång leverans väljer du Lägg till när resultatet anländer.
Konfiguration
För att få leverans exakt en gång för ditt Blob Storage- eller ADLS 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} angivna.
- Ange datumformat och tidsformat.
Begränsningar
- Underström stöds inte.
- Sökvägsmönster 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 risk för att filen skrivs över. När tidsformatet till exempel är HH genereras filen varje timme. Om du stoppar jobbet klockan 8:15 och startar om jobbet klockan 8:30 omfattar 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 maximala tillåtna antalet block utan att nå den maximala 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 ett fast schema (CSV, Avro, 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 att använda PARTITION BY, eller den inbyggda parallelliseringen 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 du {date} och {time} token från händelsefälten i sökvägsmönstret. Välj datumformat, till exempel ÅÅÅÅ/MM/DD, DD/MM/ÅÅÅÅ ELLER MM-DD-ÅÅÅÅÅ. 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 blobbockar är 50 000.
Begränsningar
- Om en snedstreckssymbol
/används i sökvägsmönstret (t.ex. /folder2/folder3) skapas tomma mappar och de visas inte i Storage Explorer - Azure 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 Event Grid har konfigurerats för att utlösas vid blobfiluppdatering.
- Azure Stream Analytics lägger till 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 tid partitionerade utdata. I vissa fall, till exempel en oren omstart, är det möjligt att den avslutande "]" för json-matrisen saknas.