IngestionBatching-Richtlinie

  • Artikel

Überblick

Während der Erfassung in die Warteschlange optimiert der Dienst den Durchsatz, indem kleine Eingangsdatenblöcke vor der Erfassung in Batches zusammengefasst werden. Die Batchverarbeitung reduziert die Ressourcen, die vom Erfassungsprozess in der Warteschlange verbraucht werden, und es sind keine Ressourcen nach der Erfassung erforderlich, um die kleinen Datenshards zu optimieren, die bei der Nicht-Batcherfassung erzeugt werden.

Der Nachteil der Batchverarbeitung vor der Erfassung ist die erzwungene Verzögerung. Daher ist die End-to-End-Zeit von der Anforderung der Datenerfassung bis zur Abfrage bereit.

Wenn Sie die IngestionBatching Richtlinie definieren, müssen Sie ein Gleichgewicht zwischen der Optimierung des Durchsatzes und der Zeitverzögerung finden. Diese Richtlinie gilt für die Erfassung in der Warteschlange. Es definiert die maximale erzwungene Verzögerung, die beim Batching kleiner Blobs zulässig ist. Weitere Informationen zur Verwendung von Batchverarbeitungsrichtlinienbefehlen und zur Optimierung des Durchsatzes finden Sie unter:

Versiegeln einer Charge

Es gibt eine optimale Größe von etwa 1 GB an nicht komprimierten Daten für die Massenerfassung. Die Erfassung von Blobs mit viel weniger Daten ist suboptimal, sodass der Dienst bei der Erfassung in der Warteschlange kleine Blobs in Batches zusammengibt.

Die folgende Liste zeigt die grundlegenden Batchverarbeitungsrichtlinientrigger zum Versiegeln eines Batches. Ein Batch wird versiegelt und erfasst, wenn die erste Bedingung erfüllt ist:

  • Size: Batchgrößenlimit erreicht oder überschritten
  • Count: Grenzwert für Batchdateinummern erreicht
  • Time: Die Batchverarbeitungszeit ist abgelaufen.

Die IngestionBatching Richtlinie kann für Datenbanken oder Tabellen festgelegt werden. Die Standardwerte sind wie folgt: maximale Verzögerungszeit von 5 Minuten , 1000 Elemente, Gesamtgröße von 1 GB.

Wichtig

Die Auswirkung der Festlegung dieser Richtlinie auf sehr kleine Werte ist eine Erhöhung der COGS (Cost of Goods Selling) des Clusters und eine verringerte Leistung. Darüber hinaus kann die Verringerung der Batchverarbeitungsrichtlinienwerte tatsächlich zu einer höheren effektiven End-to-End-Erfassungslatenz führen, da mehrere Erfassungsprozesse parallel verwaltet werden müssen.

Die folgende Liste zeigt Bedingungen zum Versiegeln von Batches im Zusammenhang mit der Erfassung einzelner Blobs. Ein Batch wird versiegelt und erfasst, wenn die Bedingungen erfüllt sind:

  • SingleBlob_FlushImmediately: Erfassen eines einzelnen Blobs, da "FlushImmediately" festgelegt wurde
  • SingleBlob_IngestIfNotExists: Erfassen eines einzelnen Blobs, da "IngestIfNotExists" festgelegt wurde
  • SingleBlob_IngestByTag: Erfassen eines einzelnen Blobs, da "ingest-by" festgelegt wurde
  • SingleBlob_SizeUnknown: Erfassen eines einzelnen Blobs, da die Blobgröße unbekannt ist

Wenn die SystemFlush Bedingung festgelegt ist, wird ein Batch versiegelt, wenn eine Systemleerung ausgelöst wird. Wenn der SystemFlush Parameter festgelegt ist, leert das System die Daten, z. B. aufgrund der Clusterskalierung oder des internen Zurücksetzens von Systemkomponenten.

Standardwerte und Grenzwerte

type Eigenschaft Standard Einstellung für niedrige Latenz Mindestwert Maximalwert
Anzahl von Elementen MaximumNumberOfItems 500 500 1 25,000
Datengröße (MB) MaximumRawDataSizeMB 1024 1024 100 4096
Zeit (in Sek.) MaximumBatchingTimeSpan 300 20 - 30 10 1800

Die effektivste Möglichkeit, die End-to-End-Latenz mithilfe einer Batchverarbeitungsrichtlinie für die Erfassung zu steuern, besteht darin, die Zeitgrenze auf Tabellen - oder Datenbankebene entsprechend den Anforderungen an höhere Latenzgrenzen zu ändern. Eine Richtlinie auf Datenbankebene wirkt sich auf alle Tabellen in dieser Datenbank aus, für die die Richtlinie auf Tabellenebene nicht definiert ist, sowie alle neu erstellten Tabellen.

Wichtig

Wenn Sie die Zeitgrenze der Batchverarbeitungsrichtlinie für die Erfassung für Tabellen mit geringem Eingang zu niedrig festlegen, kann es zu zusätzlicher Compute- und Speicherarbeit kommen, wenn der Cluster versucht, die neu erstellten Datenshards zu optimieren. Weitere Informationen zu Datenshards finden Sie unter Erweiterungen.

Batchdatengröße

Die Datengröße der Batchverarbeitungsrichtlinie wird für unkomprimierte Daten festgelegt. Für Parquet-, AVRO- und ORC-Dateien wird eine Schätzung basierend auf der Dateigröße berechnet. Bei komprimierten Daten wird die unkomprimierte Datengröße wie folgt in absteigender Reihenfolge der Genauigkeit ausgewertet:

  1. Wenn die unkomprimierte Größe in den Optionen für die Erfassungsquelle angegeben wird, wird dieser Wert verwendet.
  2. Beim Erfassen lokaler Dateien mithilfe von SDKs werden ZIP-Archive und gzip-Streams überprüft, um deren Rohgröße zu bewerten.
  3. Wenn die vorherigen Optionen keine Datengröße angeben, wird ein Faktor auf die komprimierte Datengröße angewendet, um die unkomprimierte Datengröße zu schätzen.

Batchverarbeitungslatenz

Latenzen können aus vielen Ursachen resultieren, die mithilfe von Batchingrichtlinieneinstellungen behoben werden können.

Ursache Lösung
Die Datenlatenz stimmt mit der time Einstellung überein, mit zu wenig Daten, um den size Grenzwert oder count zu erreichen. Reduzieren des Grenzwerts time
Ineffizientes Batching aufgrund einer großen Anzahl sehr kleiner Dateien Erhöhen Sie die Größe der Quelldateien. Wenn Sie die Kafka-Senke verwenden, konfigurieren Sie sie so, dass Daten in Blöcken von ca. 100 KB oder höher gesendet werden. Wenn Sie über viele kleine Dateien verfügen, erhöhen Sie die count (bis zu 2000) in der Datenbank- oder Tabellenerfassungsrichtlinie.
Batchverarbeitung einer großen Menge an unkomprimierten Daten Dies ist beim Erfassen von Parquet-Dateien üblich. Verringern Sie size inkrementell für die Batchverarbeitungsrichtlinie für Tabellen oder Datenbanken auf 250 MB, und überprüfen Sie, ob sie verbessert werden.
Backlog, weil der Cluster unter skaliert ist Akzeptieren Sie alle Vorschläge von Azure Advisor, um Ihren Cluster beiseite zu skalieren oder hochzuskalieren. Alternativ können Sie Ihren Cluster manuell skalieren, um festzustellen, ob das Backlog geschlossen ist. Wenn diese Optionen nicht funktionieren, wenden Sie sich an den Support, um Unterstützung zu erhalten.