Share via


Översikt över kontinuerlig dataexport

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 i klustret. Kontinuerlig export är inte utformat för dataströmmar med låg latens från klustret.

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

I vissa fall måste du använda en hanterad identitet för att konfigurera ett jobb för kontinuerlig export. Mer information finns i Använda en hanterad identitet för att köra ett jobb för kontinuerlig export.

Behörigheter

Alla kommandon för kontinuerlig export kräver minst behörigheter för databas Admin.

Riktlinjer för löpande export

  • Utdataschema:

    • Exportfrågans utdataschema måste matcha schemat för den externa tabell som du exporterar till.
  • Frekvens:

    • Kontinuerlig export körs enligt den tidsperiod som har konfigurerats för den intervalBetweenRuns i egenskapen . 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.

      Anteckning

      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. Till exempel fungerar inte en konfiguration av intervalBetweenRuns=1h med en aggregering per timme (T | summarize by bin(Timestamp, 1h)) 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 exportiteration 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 i befintliga. Därför beror antalet exporterade filer också på hur ofta den kontinuerliga exporten körs. Frequency-parametern är intervalBetweenRuns.
  • Externa tabelllagringskonton:

    • För bästa prestanda bör klustret och lagringskontona samplaceras i samma Azure-region.
    • Kontinuerlig export fungerar på ett distribuerat sätt, så att alla noder i klustret exporteras samtidigt. I stora kluster och om den exporterade datavolymen är stor kan det leda till lagringsbegränsning. Vi rekommenderar att du konfigurerar flera lagringskonton för den externa tabellen. Mer information finns i Lagringsfel under exportkommandon .

Exakt en gång export

För att garantera "exakt en gång"-export använder kontinuerlig export databasmarkörer. Frågan för 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. Om du lägger till ett tidsstämpelfilter i frågan kan det leda till att data saknas i exporterade data.

IngestionTime-principen 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 kommandot visa exporterade artefakter. Kontinuerlig export garanterar inte att varje post bara skrivs en gång till den externa tabellen. Om ett fel inträffar när 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. Användning av de exporterade filerna med garanterar show exported artifacts command 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 vilka som inte är begränsade (dimension). Mer information finns i parametern over i kommandot create .

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, kommer poster för respektive nycklar antingen att missas eller innehålla null-värden för dimensionskolumnerna i de exporterade filerna. Att returnera 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 samtidigt för matchande poster.

Anteckning

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

Övervaka kontinuerlig export

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

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

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

Varning

Om en kontinuerlig export misslyckas i mer än 7 dagar på grund av ett permanent fel inaktiveras exporten automatiskt av systemet. Permanenta fel är: det gick inte att hitta den externa tabellen, 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 kommandot .enable continuous export .

Resursförbrukning

  • Effekten av den kontinuerliga exporten på klustret 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 klustrets dataexportkapacitet. Mer information finns i Begränsning av hanteringskommandon. Om klustret inte har tillräckligt med kapacitet för att hantera alla kontinuerliga exporter börjar vissa släpa efter.
  • Kommandot show commands-and-queries kan användas för att beräkna resursförbrukningen.
    • Filtrera på | where ClientActivityId startswith "RunContinuousExports" för att visa de kommandon och frågor som är associerade med kontinuerlig export.

Exportera historiska data

Kontinuerlig export börjar endast exportera data när de skapas. Poster som matats in före den tiden bör exporteras separat med hjälp av kommandot för 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 kommandot show continuous export och export registrerar where cursor_before_or_at endast markörvärdet. Exempel:

.show continuous-export MyExport | project StartCursor
StartCursor
636751928823156645

Följt av:

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

Löpande 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 en säkerhetsprincip på radnivå måste du:

Löpande export till deltatabell – förhandsversion

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

Viktigt

Deltatabellpartitionering stöds inte vid kontinuerlig dataexport.

Kusto skriver inte till befintliga deltatabeller om deltaprotokollskrivarversionen ä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.

    Anteckning

    Om schemat inte anges försöker Kusto härleda det automatiskt om det redan finns en deltatabell definierad i mållagringscontainern.
    Deltatabellpartitionering stöds inte.

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

    Viktigt

    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:

Korsdatabaser och korskluster:

  • Kontinuerlig export stöder inte korsklusteranrop.
  • Kontinuerlig export stöder endast anrop mellan databaser för dimensionstabeller. Alla faktatabeller måste finnas i den lokala databasen. Mer information finns i Exportera från fakta- och dimensionstabeller.
  • Om den kontinuerliga exporten omfattar anrop mellan databaser måste den konfigureras med en hanterad identitet.

Principer: