Översikt över kontinuerlig dataexport

Gäller för: ✅Microsoft Fabric✅Azure Data Explorer

I den här artikeln beskrivs kontinuerlig export av data från Kusto till en extern tabell med en fråga som körs regelbundet. Resultaten lagras i den externa tabellen, som definierar målet, till exempel Azure Blob Storage, och schemat för exporterade data. Den här processen garanterar att alla poster exporteras "exakt en gång", med vissa undantag.

Som standard körs kontinuerlig export i ett distribuerat läge, där alla noder exporteras samtidigt, så antalet artefakter beror på antalet noder. Kontinuerlig export är inte utformat för strömmande data med låg fördröjning.

Om du vill aktivera kontinuerlig dataexport skapa en extern tabell och sedan skapa en definition för kontinuerlig export som pekar på den externa tabellen.

Behörigheter

Alla kontinuerliga exportkommandon kräver minst databasadministratör behörigheter.

Riktlinjer för kontinuerlig export

• utdataschema:

  • Utdataschemat för exportfrågan måste matcha schemat för den externa tabell som du exporterar till.

• Frekvens:

  • Kontinuerlig export körs enligt den tidsperiod som konfigurerats för den i egenskapen intervalBetweenRuns. Det rekommenderade värdet för det här intervallet är minst flera minuter, beroende på de svarstider som du är villig att acceptera. Tidsintervallet kan vara så lågt som en minut om inmatningshastigheten är hög.

    Not

    intervalBetweenRuns fungerar endast som en rekommendation och är inte garanterad att vara exakt. Kontinuerlig export lämpar sig inte för export av periodiska aggregeringar. En konfiguration av intervalBetweenRuns=1h med en aggregering per timme (T | summarize by bin(Timestamp, 1h)) fungerar till exempel inte som förväntat, eftersom den kontinuerliga exporten inte körs exakt på timmen. Därför tar varje intervall varje timme emot flera poster i exporterade data.

• Antal filer:

  • Antalet filer som exporteras i varje kontinuerlig export-iteration beror på hur den externa tabellen partitioneras. Mer information finns i exportera till externt tabellkommando. Varje iteration för kontinuerlig export skriver alltid till nya filer och lägger aldrig till befintliga filer. Därför beror antalet exporterade filer också på hur ofta den kontinuerliga exporten körs. Frekvensparametern är intervalBetweenRuns.

• externa tabelllagringskonton:

  • För bästa prestanda bör databasen och lagringskontona samallokeras i samma Azure-region.
  • Kontinuerlig export fungerar på ett distribuerat sätt, så att alla noder exporteras samtidigt. Om den exporterade datavolymen är stor i stora databaser kan det leda till lagringsbegränsning. Rekommendationen är att konfigurera flera lagringskonton för den externa tabellen. Mer information finns i lagringsfel under exportkommandon.

Exakt när exporten har exporterats

För att garantera "exakt en gång"-export använder kontinuerlig export databasmarkörer. Frågan om kontinuerlig export bör inte innehålla ett tidsstämpelfilter – mekanismen för databasmarkörer säkerställer att poster inte bearbetas mer än en gång. Att lägga till ett tidsstämpelfilter i frågan kan leda till att data saknas i exporterade data.

IngestionTime-princip måste vara aktiverad för alla tabeller som refereras i frågan som ska bearbetas "exakt en gång" i exporten. Principen är aktiverad som standard för alla nyligen skapade tabeller.

Garantin för "exakt en gång"-export gäller endast för filer som rapporteras i visa kommandot exporterade artefakter. Kontinuerlig export garanterar inte att varje post skrivs bara en gång till den externa tabellen. Om ett fel inträffar efter att exporten har påbörjats och några av artefakterna redan har skrivits till den externa tabellen kan den externa tabellen innehålla dubbletter. Om en skrivåtgärd avbröts före slutförandet kan den externa tabellen innehålla skadade filer. I sådana fall tas artefakter inte bort från den externa tabellen, men de rapporteras inte i kommandot visa exporterade artefakter. Om du använder de exporterade filerna med hjälp av show exported artifacts command garanteras inga dupliceringar och inga skador.

Exportera från fakta- och dimensionstabeller

Som standard antas alla tabeller som refereras i exportfrågan vara faktatabeller. Därför är de begränsade till databasmarkören. Syntaxen deklarerar uttryckligen vilka tabeller som är begränsade (fakta) och som inte är begränsade (dimension). Mer information finns i parametern over i kommandot skapa.

Exportfrågan innehåller endast de poster som har anslutits sedan den tidigare exportkörningen. Exportfrågan kan innehålla dimensionstabeller där alla poster i dimensionstabellen ingår i alla exportfrågor. När du använder kopplingar mellan fakta- och dimensionstabeller i kontinuerlig export bör du tänka på att poster i faktatabellen endast bearbetas en gång. Om exporten körs medan poster i dimensionstabellerna saknas för vissa nycklar, missas poster för respektive nycklar eller innehåller null-värden för dimensionskolumnerna i de exporterade filerna. Om du returnerar missade eller null-poster beror på om frågan använder inre eller yttre koppling. Egenskapen forcedLatency i definitionen för kontinuerlig export kan vara användbar i sådana fall, där fakta- och dimensionstabellerna matas in under samma tid för matchande poster.

Not

Kontinuerlig export av endast dimensionstabeller stöds inte. Exportfrågan måste innehålla minst en faktatabell.

Övervaka kontinuerlig export

Övervaka hälsotillståndet för dina kontinuerliga exportjobb med hjälp av följande exportera mått:

• Continuous export max lateness – Maximal fördröjning (i minuter) av kontinuerlig export i databasen. Det här är tiden mellan nu och den minsta ExportedTo tiden för alla kontinuerliga exportjobb i databasen. Mer information finns i kommandot .show continuous export.
• Continuous export result – Resultat av lyckade/misslyckade resultat för varje kontinuerlig exportkörning. Det här måttet kan delas upp med namnet på den kontinuerliga exporten.

Använd kommandot .show continuous export failures för att se de specifika felen för ett kontinuerligt exportjobb.

Varning

Om en kontinuerlig export misslyckas i över 7 dagar på grund av ett permanent fel inaktiveras exporten automatiskt av systemet. Permanenta fel är: den externa tabellen hittades inte, matchningsfel mellan schemat för kontinuerlig exportfråga och externt tabellschema, lagringskontot är inte tillgängligt. När felet har åtgärdats kan du återaktivera den kontinuerliga exporten med hjälp av kommandot .enable continuous export.

Resursförbrukning

• Effekten av den kontinuerliga exporten på databasen beror på frågan som den kontinuerliga exporten körs på. De flesta resurser, till exempel CPU och minne, förbrukas av frågekörningen.
• Antalet exportåtgärder som kan köras samtidigt begränsas av databasens dataexportkapacitet. Mer information finns i Management-kommandon som begränsar. Om databasen inte har tillräckligt med kapacitet för att hantera alla kontinuerliga exporter börjar vissa släpa efter.
• Kommandot visa kommandon och frågor kan användas för att beräkna resursförbrukningen.
  • Filtrera på | where ClientActivityId startswith "RunContinuousExports" för att visa kommandon och frågor som är associerade med kontinuerlig export.

Exportera historiska data

Kontinuerlig export börjar endast exportera data från den tidpunkt då de skapades. Poster som matas in före den tiden ska exporteras separat med hjälp av kommandot icke-kontinuerlig export. Historiska data kan vara för stora för att exporteras i ett enda exportkommando. Om det behövs partitionerar du frågan i flera mindre batchar.

Om du vill undvika dubbletter med data som exporteras genom kontinuerlig export använder du StartCursor som returneras av visa kommandot kontinuerlig export och exportera endast poster where cursor_before_or_at markörens värde. Till exempel:

.show continuous-export MyExport | project StartCursor

StartCursor
636751928823156645

Följt av:

.export async to table ExternalBlob
<| T | where cursor_before_or_at("636751928823156645")

Kontinuerlig export från en tabell med säkerhet på radnivå

Om du vill skapa ett kontinuerligt exportjobb med en fråga som refererar till en tabell med säkerhetsprincip på radnivåmåste du:

• Ange en hanterad identitet som en del av konfigurationen för kontinuerlig export. Mer information finns i Använda en hanterad identitet för att köra ett kontinuerligt exportjobb.
• Använd personifiering autentisering för den externa tabell som data exporteras till.

Kontinuerlig export till deltatabell – förhandsversion

Kontinuerlig export till en deltatabell är för närvarande i förhandsversion.

Viktig

Deltatabellpartitionering stöds inte vid kontinuerlig dataexport.

Kusto skriver inte till befintliga deltatabeller om deltaprotokollskrivare är högre än 1.

Utför följande steg för att definiera kontinuerlig export till en deltatabell:

1. Skapa en extern deltatabell enligt beskrivningen i Skapa och ändra externa deltatabeller i Azure Storage.

   Not

   Om schemat inte anges försöker Kusto dra slutsatsen automatiskt om det redan finns en deltatabell som definierats i mållagringscontainern.
   Deltatabellpartitionering stöds inte.

2. Definiera kontinuerlig export till den här tabellen med hjälp av kommandona som beskrivs i Skapa eller ändra kontinuerlig export.

   Viktig

   Schemat för deltatabellen måste vara synkroniserat med frågan om kontinuerlig export. Om den underliggande deltatabellen ändras kan exporten börja misslyckas med oväntat beteende.

Begränsningar

Allmänt:

• Följande format tillåts i måltabeller: CSV, TSV, JSONoch Parquet.
• Kontinuerlig export är inte utformat för att fungera över materialiserade vyer, eftersom en materialiserad vy kan uppdateras, medan data som exporteras till lagring alltid läggs till och uppdateras aldrig.
• Kontinuerlig export kan inte skapas på efterföljardatabaser eftersom efterföljardatabaser är skrivskyddade och kontinuerlig export kräver skrivåtgärder.
• Poster i källtabellen måste matas in direkt till tabellen med hjälp av en uppdateringsprincipeller mata in från frågekommandon. Om poster flyttas till tabellen med hjälp av .move-omfattningar eller med hjälp av .rename-tabell, kanske kontinuerlig export inte bearbetar dessa poster. Se begränsningarna som beskrivs på sidan databasmarkörer.
• Om artefakterna som används vid kontinuerlig export är avsedda att utlösa Event Grid-meddelanden läser du avsnittet kända problem i Event Grid-dokumentationen.

Cross-database och cross-Eventhouse:

• Kontinuerlig export stöder inte korshändelseanrop.
• Kontinuerlig export stöder endast korsdatabasanrop för dimensionstabeller. Alla faktatabeller måste finnas i den lokala databasen. Mer information finns i Exportera från fakta- och dimensionstabeller.

principer:

• Kontinuerlig export kan inte aktiveras i en tabell med säkerhetsprincip på radnivå om inte specifika villkor uppfylls. Mer information finns i Kontinuerlig export från en tabell med säkerhet på radnivå.
• Kontinuerlig export kan inte konfigureras i en tabell med åtkomstprincip för begränsad vy.

Relaterat innehåll

• .create eller alter continuous-export
• externa tabeller