Azure Data Explorer översikt över datainmatning

Datainmatning är den process som används för att läsa in dataposter från en eller flera källor till en tabell i Azure Data Explorer. När data har matats in blir de tillgängliga för frågor.

Diagrammet nedan visar flödet från slutet till slut för att arbeta i Azure Data Explorer visar olika inmatningsmetoder.

Översiktsschema för datainmatning och hantering.

Den Azure Data Explorer datahanteringstjänsten, som ansvarar för datainmatning, implementerar följande process:

Azure Data Explorer hämtar data från en extern källa och läser begäranden från en väntande Azure-kö. Data batchas eller strömmas till Data Manager. Batchdata som flödar till samma databas och tabell är optimerade för datainmatning. Azure Data Explorer verifierar inledande data och konverterar dataformat vid behov. Ytterligare datamanipulering omfattar matchande schema, organisering, indexering, kodning och komprimering av data. Data bevaras i lagringen enligt den konfigurerade kvarhållningsprincipen. Data Data Manager sedan indata i motorn, där de är tillgängliga för frågor.

Dataformat, egenskaper och behörigheter som stöds

  • Dataformat som stöds

  • Inmatningsegenskaper:De egenskaper som påverkar hur data kommer att matas in (till exempel taggning, mappning, skapandetid).

  • Behörigheter:För att mata in data kräver processen behörigheter på databasnivå. Andra åtgärder, till exempel fråga, kan kräva databasadministratörs-, databasanvändare- eller tabelladministratörsbehörigheter.

Batchbearbetning jämfört med strömningsinmatning

  • Batchbearbetningsinmatning gör databatchbearbetning och är optimerad för högt dataflöde för datainmatning. Den här metoden är den bästa och mest effektiva typen av inmatning. Data batchas enligt inmatningsegenskaper. Små databatchar sammanfogas sedan och optimeras för snabba frågeresultat. Batchbearbetningsprincipen för inmatning kan anges för databaser eller tabeller. Som standard är det maximala batchvärdet 5 minuter, 1 000 objekt eller en total storlek på 1 GB. Datastorleksgränsen för ett kommando för batchinmatning är 4 GB.

  • Strömningsinmatning är pågående datainmatning från en strömningskälla. Strömningsinmatning möjliggör svarstider i nära realtid för små uppsättningar data per tabell. Data matas först in i radlagret och flyttas sedan till kolumnlagers omfattningar. Strömningsinmatning kan göras med hjälp av ett Azure Data Explorer-klientbibliotek eller någon av de datapipelines som stöds.

Inmatningsmetoder och verktyg

Azure Data Explorer stöder flera inmatningsmetoder, var och en med sina egna målscenarier. Dessa metoder omfattar inmatningsverktyg, anslutningsappar och plugin-program för olika tjänster, hanterade pipelines, programmatisk inmatning med HJÄLP av SDK:er och direkt åtkomst till inmatning.

Inmatning med hanterade pipelines

För organisationer som vill ha hantering (begränsning, återförsök, övervakare, aviseringar med mera) som utförs av en extern tjänst är användning av en anslutningsapp förmodligen den lämpligaste lösningen. Köad inmatning är lämplig för stora datavolymer. Azure Data Explorer stöder följande Azure Pipelines:

Inmatning med anslutningsappar och plugin-program

Programmatisk inmatning med HJÄLP av SDK:er

Azure Data Explorer innehåller DEDK:er som kan användas för fråge- och datainmatning. Programmatisk inmatning är optimerad för att minska inmatningskostnader (KSG) genom att minimera lagringstransaktioner under och efter inmatningsprocessen.

Tillgängliga SDK:er och projekt med öppen källkod

Verktyg

  • Inmatning med ett klick:Gör att du snabbt kan mata in data genom att skapa och justera tabeller från en mängd olika källtyper. Inmatning med ett klick föreslår automatiskt tabeller och mappningsstrukturer baserat på datakällan i Azure Data Explorer. Inmatning med ett klick kan användas för inmatning en gång eller för att definiera kontinuerlig inmatning via Event Grid på containern som data matades in till.

  • LightIngest:Ett kommandoradsverktyg för ad hoc-datainmatning till Azure Data Explorer. Verktyget kan hämta källdata från en lokal mapp eller från en Azure Blob Storage-container.

Kommandon för inmatningskontroll

Använd kommandon för att mata in data direkt till motorn. Den här metoden kringgår Datahantering tjänster och bör därför endast användas för utforskning och prototyper. Använd inte den här metoden i produktionsscenarier eller scenarier med stora volymer.

  • Infogade datainmatning:Ett kontrollkommando . infogade skickas till motorn, där de data som ska matas in är en del av själva kommandotexten. Den här metoden är avsedd för testsyften.

  • Mata in från fråga:Ett kontrollkommando för .set, .append, .set-or-append eller .set-or-replace skickas till motorn, med de data som anges indirekt som resultatet av en fråga eller ett kommando.

  • Mata in från lagring (pull):Ett kontrollkommando .ingest i skickas till motorn med data som lagras i en extern lagring (till exempel Azure Blob Storage) som kan nås av motorn och pekas på av kommandot .

Jämföra inmatningsmetoder och verktyg

Datainmatningsnamn Datatyp Maximal filstorlek Direktuppspelning, batchbearbetning, direkt De vanligaste scenarierna Överväganden
Inmatning med ett klick *sv, JSON 1 GB okomprimerad (se anmärkning) Batchbearbetning till container, lokal fil och blob i direkt inmatning One-off, create table schema, definition of continuous ingestion with event grid, bulk ingestion with container (up to 5,000 blobs; no limit when using historical ingestion)
LightIngest Alla format som stöds 1 GB okomprimerad (se anmärkning) Batchbearbetning via DM eller direkt inmatning till motor Datamigrering, historiska data med justerade tidsstämplar för inmatning, massinmatning (ingen storleksbegränsning) Fallkänsligt, utrymmeskänsligt
ADX Kafka Avro, ApacheAvro, JSON, CSV, Parquet och ORC Obegränsad. Ärver Java-begränsningar. Batchbearbetning, strömning Befintlig pipeline, hög volymförbrukning från källan. Inställningen kan fastställas av vilken tjänst för "flera tillverkare/konsument" som redan används eller hur hanterad en tjänst önskas.
ADX till Apache Spark Alla format som stöds av Spark-miljön Obegränsat Batchbearbetning Befintlig pipeline, förbearbetning på Spark före inmatning, snabbt sätt att skapa en säker strömningspipeline (Spark) från de olika källor som Spark-miljön stöder. Överväg kostnaden för Spark-kluster. För batchskrivning jämför du med Azure Data Explorer dataanslutning för Event Grid. För Spark-strömning jämför du med dataanslutningen för Händelsehubb.
LogStash JSON Obegränsad. Ärver Java-begränsningar. Indata till anslutningsappen är Logstash-händelser och anslutningsappen matar ut till Kusto med batchinmatning. Befintlig pipeline utnyttjar Logstashs mogna, öppna källkod för hög volymförbrukning från indata. Inställningen kan fastställas av vilken tjänst för "flera tillverkare/konsument" som redan används eller hur hanterad en tjänst önskas.
Azure Data Factory (ADF) Dataformat som stöds Obegränsat *(per ADF-begränsningar) Batchbearbetning eller per ADF-utlösare Stöder format som vanligtvis inte stöds, stora filer, kan kopiera från över 90 källor, från perm till molnet Den här metoden tar relativt lång tid tills data matas in. ADF laddar upp alla data till minnet och börjar sedan mata in.
Power Automate Alla format som stöds 1 GB okomprimerad (se anmärkning) Batchbearbetning Inmatningskommandon som en del av flödet. Används för att automatisera pipelines.
Logic Apps Alla format som stöds 1 GB okomprimerad (se anmärkning) Batchbearbetning Används för att automatisera pipelines
IoT Hub Dataformat som stöds Ej tillämpligt Batchbearbetning, strömning IoT-meddelanden, IoT-händelser, IoT-egenskaper
Händelsehubb Dataformat som stöds Ej tillämpligt Batchbearbetning, strömning Meddelanden, händelser
Event Grid Dataformat som stöds 1 GB okomprimerad Batchbearbetning Kontinuerlig inmatning från Azure Storage, externa data i Azure Storage Inmatning kan utlösas av blobbyte eller åtgärder för att skapa blob
.NET SDK Alla format som stöds 1 GB okomprimerad (se anmärkning) Batchbearbetning, strömning, direkt Skriv din egen kod enligt organisationens behov
Python Alla format som stöds 1 GB okomprimerad (se anmärkning) Batchbearbetning, strömning, direkt Skriv din egen kod enligt organisationens behov
Node.js Alla format som stöds 1 GB okomprimerad (se anmärkning Batchbearbetning, strömning, direkt Skriv din egen kod enligt organisationens behov
Java Alla format som stöds 1 GB okomprimerad (se anmärkning) Batchbearbetning, strömning, direkt Skriv din egen kod enligt organisationens behov
REST Alla format som stöds 1 GB okomprimerad (se anmärkning) Batchbearbetning, strömning, direkt Skriv din egen kod enligt organisationens behov
Go Alla format som stöds 1 GB okomprimerad (se anmärkning) Batchbearbetning, strömning, direkt Skriv din egen kod enligt organisationens behov

Anteckning

När det refereras till i tabellen ovan stöder inmatning en maximal filstorlek på 4 GB. Rekommendationen är att mata in filer mellan 100 MB och 1 GB.

Inmatningsprocess

När du har valt den lämpligaste inmatningsmetoden för dina behov gör du följande:

  1. Ange batchbearbetningsprincip (valfritt)

    Batchbearbetningshanteraren batchar inmatningsdata baserat på batchbearbetningsprincipen för inmatning. Definiera en batchbearbetningsprincip före inmatning. Se metodtips för inmatning – optimera för dataflöde. Det kan ta upp till 5 minuter innan principändringar i batchbearbetning ska gälla. Principen anger batchgränser enligt tre faktorer: förfluten tid sedan batchskapande, ackumulerat antal objekt (blobar) eller total batchstorlek. Som standard är inställningarna 5 minuter/1 000 blobar/1 GB, där gränsen först har nåtts. Därför är det vanligtvis 5 minuters fördröjning när du köar exempeldata för inmatning.

  2. Ange bevarandeprincip

    Data som matas in i en Azure Data Explorer är föremål för tabellens gällande bevarandeprincip. Den gällande kvarhållningsprincipen härleds från databasens kvarhållningsprincip såvida den inte anges explicit för en tabell. Varm kvarhållning är en funktion för klusterstorlek och din kvarhållningsprincip. Inmatning av mer data än vad du har tillgängligt utrymme tvingar den första datan att kall kvarhållning.

    Kontrollera att databasens kvarhållningsprincip är lämplig för dina behov. Annars ska du åsidosätta den explicit på tabellnivå. Mer information finns i kvarhållningsprincip.

  3. Skapa en tabell

    För att kunna mata in data måste en tabell skapas i förväg. Välj ett av följande alternativ:

    Anteckning

    Om en post är ofullständig eller om ett fält inte kan parsas som nödvändig datatyp fylls motsvarande tabellkolumner i med null-värden.

  4. Skapa schemamappning

    Schemamappning hjälper till att binda källdatafält till måltabellkolumner. Med mappning kan du ta data från olika källor till samma tabell, baserat på de definierade attributen. Olika typer av mappningar stöds, både radorienterade (CSV, JSON och AVRO) och kolumnorienterade (Parquet). I de flesta metoder kan mappningar också skapas i förväg i tabellen och refereras från parametern för inmatningskommandot.

  5. Ange uppdateringsprincip (valfritt)

    Några av dataformatmappningarna (Parquet, JSON och Avro) stöder enkla och användbara inmatningstidsomvandlar. Om scenariot kräver mer komplex bearbetning vid inmatning justerar du uppdateringsprincipen ,som stöder förenklad bearbetning med hjälp av frågekommandon. Uppdateringsprincipen kör automatiskt extrahering och omvandlingar på in matade data i den ursprungliga tabellen och matar in resulterande data i en eller flera måltabeller.

Nästa steg