Ö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 avintervalBetweenRuns
=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
.
- 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
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 minstaExportedTo
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.
- Filtrera på
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:
- 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 jobb för kontinuerlig export.
- Använd personifieringsautentisering för den externa tabell som data exporteras till.
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:
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.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:
- Följande format tillåts i måltabeller:
CSV
,TSV
,JSON
ochParquet
. - 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 bara läggs till och aldrig uppdateras.
- Det går inte att skapa kontinuerlig export på uppföljningsdatabaser eftersom uppföljningsdatabaser är skrivskyddade och kontinuerlig export kräver skrivåtgärder.
- Poster i källtabellen måste matas in till tabellen direkt, med hjälp av en uppdateringsprincip eller matas in från frågekommandon. Om poster flyttas till tabellen med hjälp av .move-utrymmen eller med hjälp av .rename-tabellen, kanske kontinuerlig export inte bearbetar dessa poster. Se begränsningarna som beskrivs på sidan Databasmarkörer .
- Om artefakterna som används av kontinuerlig export är avsedda att utlösa Event Grid-meddelanden läser du avsnittet om kända problem i Event Grid-dokumentationen.
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:
- Kontinuerlig export kan inte aktiveras i en tabell med en 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
Feedback
https://aka.ms/ContentUserFeedback.
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i:Skicka och visa feedback för