Übersicht über die Updaterichtlinie

Updaterichtlinien sind Automatisierungsmechanismen, die ausgelöst werden, wenn neue Daten in eine Tabelle geschrieben werden. Sie machen die Notwendigkeit einer speziellen Orchestrierung überflüssig, indem sie eine Abfrage ausführen, um die erfassten Daten zu transformieren und das Ergebnis in einer Zieltabelle zu speichern. Für eine einzelne Tabelle können mehrere Updaterichtlinien definiert werden, sodass unterschiedliche Transformationen möglich sind und Daten gleichzeitig in mehreren Tabellen gespeichert werden können. Die Zieltabellen können ein anderes Schema, eine andere Aufbewahrungsrichtlinie und andere Richtlinien als die Quelltabelle aufweisen.

Beispielsweise kann eine High-Rate-Trace-Quelltabelle Daten enthalten, die als Freitextspalte formatiert sind. Die Zieltabelle kann bestimmte Verfolgungszeilen mit einem ein gut strukturierten Schema enthalten, das aus einer Transformation der Freitextdaten der Quelltabelle mithilfe des Analyseoperators erstellt wurde. Weitere Informationen finden Sie in gängigen Szenarien.

Das folgende Diagramm zeigt eine allgemeine Ansicht einer Updaterichtlinie. Es werden zwei Updaterichtlinien angezeigt, die ausgelöst werden, wenn Daten in der zweiten Quelltabelle hinzugefügt werden, und führt dazu, dass den beiden Zieltabellen transformierte Daten hinzugefügt werden.

Das Diagramm zeigt eine Übersicht über die Updaterichtlinie.

Eine Updaterichtlinie unterliegt den gleichen Einschränkungen und bewährten Methoden wie die reguläre Erfassung. Die Richtlinie wird entsprechend der Clustergröße hochskaliert und ist bei der Verarbeitung der Massenerfassung effizienter.

Hinweis

  • Quell- und Zieltabelle müssen sich in derselben Datenbank befinden.
  • Das Updaterichtlinienfunktionsschema und das Zieltabellenschema müssen in ihren Spaltennamen, -typen und -reihenfolge übereinstimmen.

Die Erfassung formatierter Daten verbessert die Leistung, und CSV wird bevorzugt, da es sich um ein klar definiertes Format handelt. Manchmal haben Sie jedoch keine Kontrolle über das Format der Daten, oder Sie möchten die erfassten Daten anreichern, z. B. indem Sie Datensätze mit einer statischen Dimensionstabelle in Ihrer Datenbank verknüpfen.

Aktualisieren der Richtlinienabfrage

Wenn die Updaterichtlinie für die Zieltabelle definiert ist, können mehrere Abfragen für daten ausgeführt werden, die in einer Quelltabelle erfasst wurden. Wenn mehrere Updaterichtlinien vorhanden sind, ist die Reihenfolge der Ausführung nicht unbedingt bekannt.

Abfrageeinschränkungen

  • Die richtlinienbezogene Abfrage kann gespeicherte Funktionen aufrufen, aber:
    • Es kann keine clusterübergreifenden Abfragen ausführen.
    • Sie kann nicht auf externe Daten oder externe Tabellen zugreifen.
    • Es kann keine Beschriftungen (mithilfe eines Plug-Ins) machen.
  • Die Abfrage hat keinen Lesezugriff auf Tabellen, für die die Richtlinie RestrictedViewAccess aktiviert ist.
  • Informationen zu Updaterichtlinienbeschränkungen bei der Streamingerfassung finden Sie unter Einschränkungen der Streamingerfassung.

Warnung

Eine falsche Abfrage kann die Datenerfassung in der Quelltabelle verhindern. Es ist wichtig zu beachten, dass Einschränkungen sowie die Kompatibilität zwischen den Abfrageergebnissen und dem Schema der Quell- und Zieltabellen zu einer falschen Abfrage führen können, um die Datenerfassung in der Quelltabelle zu verhindern.

Diese Einschränkungen werden während der Erstellung und Ausführung der Richtlinie überprüft, aber nicht, wenn beliebige gespeicherte Funktionen aktualisiert werden, auf die die Abfrage möglicherweise verweist. Daher ist es wichtig, alle Änderungen mit Vorsicht vorzunehmen, um sicherzustellen, dass die Updaterichtlinie intakt bleibt.

Wenn Sie auf die Source Tabelle im Teil der Query Richtlinie oder in Funktionen verweisen, auf die Query vom Teil verwiesen wird:

  • Verwenden Sie nicht den qualifizierten Namen der Tabelle. Verwenden Sie stattdessen TableName.
  • Verwenden Sie nicht database("DatabaseName").TableName oder cluster("ClusterName").database("DatabaseName").TableName.

Das Updaterichtlinienobjekt

Einer Tabelle können null oder mehr Updaterichtlinienobjekte zugeordnet sein. Jedes dieser Objekte wird als JSON-Eigenschaftenbehälter dargestellt, wobei die folgenden Eigenschaften definiert sind.

Eigenschaft Typ BESCHREIBUNG
isEnabled bool Gibt an, ob die Updaterichtlinie "true " (aktiviert oder "false ") deaktiviert ist.
Quelle string Name der Tabelle, die den Aufruf der Updaterichtlinie auslöst
Abfrage string Eine Abfrage, die zum Erstellen von Daten für das Update verwendet wird
IsTransactional bool Gibt an, ob die Updaterichtlinie transaktional ist oder nicht, ist der Standardwert false. Wenn die Richtlinie transaktional ist und die Updaterichtlinie fehlschlägt, wird die Quelltabelle nicht aktualisiert.
PropagateIngestionProperties bool Gibt an, wenn eigenschaften, die während der Erfassung für die Quelltabelle angegeben wurden, z. B . Erweiterungstags und Erstellungszeit, auf die Zieltabelle angewendet werden.
ManagedIdentity string Die verwaltete Identität, für die die Updaterichtlinie ausgeführt wird. Die verwaltete Identität kann eine Objekt-ID oder das reservierte system Wort sein. Die Updaterichtlinie muss mit einer verwalteten Identität konfiguriert werden, wenn die Abfrage auf Tabellen in anderen Datenbanken oder Tabellen mit aktivierter Sicherheitsrichtlinie auf Zeilenebene verweist. Weitere Informationen finden Sie unter Verwenden einer verwalteten Identität zum Ausführen einer Updaterichtlinie.

Hinweis

Legen Sie in Produktionssystemen :true festIsTransactional, um sicherzustellen, dass die Zieltabelle bei vorübergehenden Fehlern keine Daten verliert.

Hinweis

Kaskadierende Aktualisierungen sind zulässig, z. B. von Tabelle A über Tabelle B bis zu Tabelle C. Wenn Updaterichtlinien jedoch zirkulär definiert werden, wird dies zur Laufzeit erkannt, und die Kette der Updates wird unterbrochen. Daten werden nur einmal für jede Tabelle in der Kette erfasst.

Befehle für Verwaltung

Zu den Befehlen für die Updaterichtlinienverwaltung gehören:

Die Updaterichtlinie wird nach der Erfassung initiiert.

Updaterichtlinien werden wirksam, wenn Daten erfasst oder in eine Quelltabelle verschoben werden oder Blöcke in einer Quelltabelle mit einem der folgenden Befehle erstellt werden:

Warnung

Wenn die Updaterichtlinie als Teil eines .set-or-replace Befehls aufgerufen wird, werden Daten in abgeleiteten Tabellen standardmäßig auf die gleiche Weise wie in der Quelltabelle ersetzt. Daten gehen möglicherweise in allen Tabellen mit einer Updaterichtlinienbeziehung verloren, wenn der replace Befehl aufgerufen wird. Verwenden Sie stattdessen .set-or-append.

Entfernen von Daten aus der Quelltabelle

Nachdem Sie Daten in der Zieltabelle erfasst haben, können Sie sie optional aus der Quelltabelle entfernen. Legen Sie den Zeitraum für vorläufiges Löschen ( 0sec oder 00:00:00) in der Aufbewahrungsrichtlinie der Quelltabelle und die Updaterichtlinie als transaktional fest. Die folgenden Bedingungen gelten:

  • Die Quelldaten können nicht aus der Quelltabelle abfragt werden.
  • Die Quelldaten werden im Rahmen des Erfassungsvorgangs nicht im permanenten Speicher beibehalten.
  • Die Betriebsleistung verbessert sich. Die Ressourcen nach der Erfassung werden für Hintergrundbereinigungsvorgänge für Blöcke in der Quelltabelle reduziert.

Hinweis

Wenn die Quelltabelle den Zeitraum für vorläufiges 0sec Löschen (oder 00:00:00) aufweist, muss jede Updaterichtlinie, die auf diese Tabelle verweist, transaktional sein.

Auswirkungen auf die Leistung

Updaterichtlinien können sich auf die Clusterleistung auswirken, und die Erfassung von Datenblöcken wird mit der Anzahl der Zieltabellen multipliziert. Es ist wichtig, die richtlinienbezogene Abfrage zu optimieren. Sie können die Auswirkungen auf die Leistung einer Updaterichtlinie testen, indem Sie die Richtlinie für bereits vorhandene Blöcke aufrufen, bevor Sie die Richtlinie erstellen oder ändern, oder auf die Funktion, die mit der Abfrage verwendet wird.

Auswerten der Ressourcennutzung

Verwenden Sie .show queries, um die Ressourcenauslastung (CPU, Arbeitsspeicher usw.) mit den folgenden Parametern auszuwerten:

  • Legen Sie die Source -Eigenschaft und den Namen der Quelltabelle als fest. MySourceTable
  • Legen Sie die Query -Eigenschaft fest, um eine Funktion namens aufzurufen. MyFunction()
// '_extentId' is the ID of a recently created extent, that likely hasn't been merged yet.
let _extentId = toscalar(
    MySourceTable
    | project ExtentId = extent_id(), IngestionTime = ingestion_time()
    | where IngestionTime > ago(10m)
    | top 1 by IngestionTime desc
    | project ExtentId
);
// This scopes the source table to the single recent extent.
let MySourceTable =
    MySourceTable
    | where ingestion_time() > ago(10m) and extent_id() == _extentId;
// This invokes the function in the update policy (that internally references `MySourceTable`).
MyFunction

Fehler

Mit der Standardeinstellung können IsTransactional:falseDaten weiterhin in der Quelltabelle erfasst werden, auch wenn die Richtlinie nicht ausgeführt wird.

Das Festlegen IsTransactional:true garantiert die Konsistenz zwischen Daten in der Quell- und Der Zieltabelle. Wenn die Richtlinienbedingungen jedoch fehlschlagen, werden keine Daten in der Quelltabelle erfasst. Je nach Bedingungen werden manchmal Daten für die Quelltabelle, aber nicht für die Zieltabelle erfasst. Wenn Ihre Richtlinie jedoch falsch definiert ist oder ein Schemakonflikt vorliegt, werden daten nicht in der Quell- oder Zieltabelle erfasst. Beispielsweise kann ein Konflikt zwischen dem Abfrageausgabeschema und der Zieltabelle dadurch verursacht werden, dass eine Spalte aus der Zieltabelle gelöscht wird.

Sie können Fehler mithilfe des .show ingestion failures Befehls anzeigen.

.show ingestion failures
| where FailedOn > ago(1hr) and OriginatesFromUpdatePolicy == true

Behandlung von Fehlern

Nicht transaktionale Richtlinie

Wenn auf IsTransactional:falsefestgelegt ist, wird ein Fehler bei der Ausführung der Richtlinie ignoriert. Die Erfassung wird nicht automatisch wiederholt. Sie können die Erfassung manuell wiederholen.

Transaktionsrichtlinie

Wenn die Erfassungsmethode auf IsTransactional:truefestgelegt ist, ist pullder Datenverwaltung-Dienst beteiligt, und die Erfassung wird gemäß den folgenden Bedingungen automatisch wiederholt:

  • Wiederholungen werden ausgeführt, bis eine der folgenden konfigurierbaren Grenzwerteinstellungen erfüllt ist: DataImporterMaximumRetryPeriod oder DataImporterMaximumRetryAttempts
  • Standardmäßig beträgt die DataImporterMaximumRetryPeriod Einstellung zwei Tage und DataImporterMaximumRetryAttemptsist 10.
  • Der Backoffzeitraum beginnt bei 2 Minuten und verdoppelt sich. Die Wartezeit beginnt also mit 2 Min., erhöht sich dann auf 4 Min., auf 8 min, auf 16 min usw.

In jedem anderen Fall können Sie die Erfassung manuell wiederholen.

Beispiel für Extrahieren, Transformieren, Laden

Sie können die Aktualisierungsrichtlinieneinstellungen verwenden, um ETL (Extrahieren, Transformieren, Laden) durchzuführen.

Verwenden Sie in diesem Beispiel eine Updaterichtlinie mit einer einfachen Funktion, um ETL auszuführen. Zunächst erstellen wir zwei Tabellen:

  • Die Quelltabelle: Enthält eine einzelne Zeichenfolgen-typisierte Spalte, in der Daten erfasst werden.
  • Die Zieltabelle: Enthält das gewünschte Schema. Die Updaterichtlinie ist in dieser Tabelle definiert.
  1. Erstellen Sie nun die Quelltabelle:

    .create table MySourceTable (OriginalRecord:string)
    
  2. Erstellen Sie als Nächstes die Zieltabelle:

    .create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)
    
  3. Erstellen Sie dann eine Funktion zum Extrahieren von Daten:

    .create function
     with (docstring = 'Parses raw records into strongly-typed columns', folder = 'UpdatePolicyFunctions')
         ExtractMyLogs()
        {
        MySourceTable
        | parse OriginalRecord with "[" Timestamp:datetime "] [ThreadId:" ThreadId:int "] [ProcessId:" ProcessId:int "] TimeSinceStartup: " TimeSinceStartup:timespan " Message: " Message:string
        | project-away OriginalRecord
    }
    
  4. Legen Sie nun die Updaterichtlinie so fest, dass die von uns erstellte Funktion aufgerufen wird:

    .alter table MyTargetTable policy update
    @'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'
    
  5. Um die Quelltabelle zu leeren, nachdem Daten in der Zieltabelle erfasst wurden, definieren Sie die Aufbewahrungsrichtlinie für die Quelltabelle, um 0s als zu SoftDeletePeriodenthalten.

     .alter-merge table MySourceTable policy retention softdelete = 0s