Omówienie zasad aktualizacji

Przełącz usługi przy użyciu rozwijanej listy Wersja. Dowiedz się więcej o nawigacji.
Dotyczy: ✅ Microsoft Fabric ✅ Azure Data Explorer

Zasady aktualizacji to mechanizmy automatyzacji wyzwalane, gdy nowe dane są zapisywane w tabeli. Eliminują one potrzebę specjalnej aranżacji, uruchamiając zapytanie, aby przekształcić pozyskane dane i zapisać wynik w tabeli docelowej. Wiele zasad aktualizacji można zdefiniować w jednej tabeli, co pozwala na różne przekształcenia i zapisywanie danych w wielu tabelach jednocześnie. Tabele docelowe mogą mieć inny schemat, zasady przechowywania i inne zasady z tabeli źródłowej.

Na przykład tabela źródłowa śledzenia o wysokiej szybkości może zawierać dane sformatowane jako kolumna wolnego tekstu. Tabela docelowa może zawierać określone wiersze śledzenia z dobrze ustrukturyzowanym schematem wygenerowanym na podstawie przekształcenia danych beztekstowych tabeli źródłowej przy użyciu operatora analizy. Aby uzyskać więcej informacji, typowe scenariusze.

Na poniższym diagramie przedstawiono ogólny widok zasad aktualizacji. Zostaną wyświetlone dwie zasady aktualizacji, które są wyzwalane po dodaniu danych do drugiej tabeli źródłowej. Po wyzwoleniu przekształcone dane są dodawane do dwóch tabel docelowych.

Aktualizowanie zapytania zasad

Jeśli zasady aktualizacji są zdefiniowane w tabeli docelowej, wiele zapytań może być uruchamianych na danych pozyskanych do tabeli źródłowej. Jeśli istnieje wiele zasad aktualizacji, kolejność wykonywania nie musi być znana.

Ograniczenia zapytań

Podczas odwoływania Source się do tabeli w Query części zasad lub w funkcjach, do których odwołuje się Query część:

Obiekt zasad aktualizacji

Tabela może mieć skojarzone z nim zero lub więcej obiektów zasad aktualizacji. Każdy taki obiekt jest reprezentowany jako torba właściwości JSON ze zdefiniowanymi następującymi właściwościami.

.alter table TargetTable policy update
```
[
    {
        "IsEnabled": true,
        "Source": "ExternalDeltaTable",
        "Query": "ExternalDeltaTable | project Timestamp, Value",
        "IsTransactional": false,
        "PropagateIngestionProperties": false
    }
]
```

materialized_table("TargetTableName")

.alter table TargetTable policy update
```
[
    {
        "IsEnabled": true,
        "Source": "ExternalDeltaTable",
        "Query": "ExternalDeltaTable | project Timestamp, Value",
        "IsTransactional": false,
        "PropagateIngestionProperties": false
    }
]
```

materialized_table("TargetTableName")

Polecenia zarządzania

Polecenia zarządzania zasadami aktualizacji obejmują:

• .show table *TableName* policy update wyświetla bieżące zasady aktualizacji tabeli.
• .alter table *TableName* policy update definiuje bieżące zasady aktualizacji tabeli.
• .alter-merge table *TableName* policy update Dołącza definicje do bieżących zasad aktualizacji tabeli.
• .delete table *TableName* policy update Usuwa bieżące zasady aktualizacji tabeli.

Zasady aktualizacji są inicjowane po pozyskiwaniu

Zasady aktualizacji zaczynają obowiązywać, gdy dane są pozyskiwane lub przenoszone do tabeli źródłowej lub zakresy są tworzone w tabeli źródłowej. Te akcje można wykonać przy użyciu dowolnego z następujących poleceń:

• pozyskiwanie (ściąganie)
• .ingest (wbudowany)
• .set | .append | .set-or-append | .set-or-replace
• .move extents
• .replace extents
  • Polecenie PropagateIngestionProperties ma zastosowanie tylko w operacjach pozyskiwania. Po wyzwoleniu zasad aktualizacji w ramach .move extents polecenia lub .replace extents ta opcja nie ma wpływu.

Aktualizowanie zasad za pomocą wzorca z symbolami wieloznacznymi tabeli źródłowej

Zasady aktualizacji obsługują pozyskiwanie z wielu tabel źródłowych, które współdzielą ten sam wzorzec, przy użyciu tego samego zapytania co zapytanie zasad aktualizacji. Jest to przydatne, jeśli masz kilka tabel źródłowych, zwykle współużytkując ten sam schemat (lub podzbiór kolumn, które współużytkują wspólny schemat), i chcesz wyzwolić pozyskiwanie do pojedynczej tabeli docelowej podczas pozyskiwania do jednej z tych tabel. W takim przypadku zamiast definiować wiele zasad aktualizacji, z których każda dla pojedynczej tabeli źródłowej, można zdefiniować pojedyncze zasady aktualizacji z symbolami wieloznacznymi jako Source. Zasady Query aktualizacji muszą być zgodne ze wszystkimi tabelami źródłowymi zgodnymi ze wzorcem. Aby odwołać się do tabeli źródłowej w zapytaniu zasad aktualizacji, można użyć specjalnego symbolu o nazwie $source_table. Zobacz przykładowe zasady aktualizacji symboli wieloznanych.

Usuwanie danych z tabeli źródłowej

Po pozyskiwaniu danych do tabeli docelowej możesz opcjonalnie usunąć je z tabeli źródłowej. Ustaw okres usuwania nietrwałego 0sec (lub 00:00:00) w zasadach przechowywania tabeli źródłowej i zasady aktualizacji jako transakcyjne. Należy uwzględnić następujące warunki:

• Dane źródłowe nie są możliwe do wykonywania zapytań z tabeli źródłowej
• Dane źródłowe nie są utrwalane w trwałym magazynie w ramach operacji pozyskiwania
• Wydajność operacyjna poprawia się. Zasoby po pozyskiwaniu są zmniejszane w przypadku operacji pielęgnacji w tle w zakresach w tabeli źródłowej.

Wpływ na wydajność

Zasady aktualizacji mogą mieć wpływ na wydajność, a pozyskiwanie zakresów danych jest mnożone przez liczbę tabel docelowych. Ważne jest, aby zoptymalizować zapytanie związane z zasadami. Możesz przetestować wpływ zasad aktualizacji na wydajność, wywołując zasady w już istniejących zakresach, przed utworzeniem lub zmianą zasad lub na funkcję używaną z zapytaniem.

Ocena użycia zasobów

Użyj polecenia .show queries, aby ocenić użycie zasobów (procesor CPU, pamięć itd.) przy użyciu następujących parametrów:

• Source Ustaw właściwość , nazwę tabeli źródłowej jakoMySourceTable
• Query Ustawianie właściwości w celu wywołania funkcji o nazwieMyFunction()

// '_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

Ustawienia transakcyjne

Ustawienie zasad IsTransactional aktualizacji określa, czy zasady aktualizacji są transakcyjne i mogą mieć wpływ na zachowanie aktualizacji zasad w następujący sposób:

• IsTransactional:false: Jeśli wartość jest ustawiona na wartość domyślną, false, zasady aktualizacji nie gwarantują spójności między danymi w tabeli źródłowej i docelowej. Jeśli zasady aktualizacji nie powiedzą się, dane są pozyskiwane tylko do tabeli źródłowej, a nie do tabeli docelowej. W tym scenariuszu operacja pozyskiwania zakończyła się pomyślnie.
• IsTransactional:true: Jeśli wartość jest ustawiona na true, ustawienie gwarantuje spójność między danymi w tabelach źródłowych i docelowych. Jeśli zasady aktualizacji nie powiedzą się, dane nie są pozyskiwane do tabeli źródłowej ani docelowej. W tym scenariuszu operacja pozyskiwania nie powiedzie się.

Obsługa błędów

Gdy aktualizacje zasad kończą się niepowodzeniem, są obsługiwane inaczej w zależności od tego IsTransactional , czy ustawienie ma true wartość , czy false. Typowe przyczyny błędów zasad aktualizacji to:

• Niezgodność między schematem danych wyjściowych zapytania a tabelą docelową.
• Dowolny błąd zapytania.

Błędy aktualizacji zasad można wyświetlić przy użyciu .show ingestion failures polecenia z następującym poleceniem: W każdym innym przypadku można ręcznie ponowić próbę pozyskiwania.

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

Przykład wyodrębniania, przekształcania, ładowania

Za pomocą ustawień zasad aktualizacji można wykonywać wyodrębnianie, przekształcanie, ładowanie (ETL).

W tym przykładzie użyj zasad aktualizacji z prostą funkcją do wykonania etL. Najpierw tworzymy dwie tabele:

• Tabela źródłowa — zawiera pojedynczą kolumnę typu ciąg, w której pozyskiwane są dane.
• Tabela docelowa — zawiera żądany schemat. Zasady aktualizacji są zdefiniowane w tej tabeli.

1. Utwórzmy tabelę źródłową:

   .create table MySourceTable (OriginalRecord:string)
   

2. Następnie utwórz tabelę docelową:

   .create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)
   

3. Następnie utwórz funkcję w celu wyodrębnienia danych:

   .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. Teraz ustaw zasady aktualizacji, aby wywołać utworzoną funkcję:

   .alter table MyTargetTable policy update
   @'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'
   

5. Aby opróżnić tabelę źródłową po pozyskiwaniu danych do tabeli docelowej, zdefiniuj zasady przechowywania w tabeli źródłowej, aby mieć wartość 0s jako wartość SoftDeletePeriod.

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

Przykład zasad aktualizacji symboli wieloznanych

Poniższy przykład tworzy zasady aktualizacji z pojedynczym wpisem w tabeli TargetTable. Zasady odwołują się do wszystkich tabel pasujących do wzorca SourceTable* jako źródła. Każde pozyskiwanie do tabeli zgodnej ze wzorcem (w lokalnej bazie danych) spowoduje wyzwolenie zasad aktualizacji i pozyskanie danych do TargetTable, na podstawie zapytania zasad aktualizacji.

1. Utwórz dwie tabele źródłowe:

   .create table SourceTable1(Id:long, Value:string)
   

   .create table SourceTable2(Id:long, Value:string)
   

2. Utwórz tabelę docelową:

   .create table TargetTable(Id:long, Value:string, Source:string)
   

3. Utwórz funkcję, która będzie służyć jako Query zasady aktualizacji. Funkcja używa symbolu $source_table do odwołowania Source się do zasad aktualizacji. Użyj polecenia skipValidation=true , aby pominąć walidację podczas tworzenia funkcji, ponieważ $source_table jest znany tylko podczas wykonywania zasad aktualizacji. Funkcja jest weryfikowana w następnym kroku podczas zmiany zasad aktualizacji.

   .create function with(skipValidation=true) IngestToTarget()
   {
       $source_table 
       | parse Value with "I'm from table " Source
       | project Id, Value, Source
   }
   

4. Utwórz zasady aktualizacji w witrynie TargetTable. Zasady odwołują się do wszystkich tabel pasujących do wzorca SourceTable* jako źródła.

       .alter table TargetTable policy update
       ```[{ 
               "IsEnabled": true, 
               "Source": "SourceTable*", 
               "SourceIsWildCard" : true,
               "Query": "IngestToTarget()",
               "IsTransactional": true,
               "PropagateIngestionProperties": true
       }]```
   
   

5. Pozyskiwanie do tabel źródłowych. Oba pozyskiwania wyzwalają zasady aktualizacji:

   .set-or-append SourceTable1 <| 
       datatable (Id:long, Value:string)
       [
           1, "I'm from table SourceTable1",
           2, "I'm from table SourceTable1"
       ]
   

   .set-or-append SourceTable2 <| 
       datatable (Id:long, Value:string)
       [
           3, "I'm from table SourceTable2",
           4, "I'm from table SourceTable2"
       ]
   

6. Zapytanie TargetTable:

    TargetTable
   

   Id	Wartość	Źródło
   1	Jestem z tabeli SourceTable1	SourceTable1
   2	Jestem z tabeli SourceTable1	SourceTable1
   3	Jestem z tabeli SourceTable2	SourceTable2
   4	Jestem z tabeli SourceTable2	SourceTable2

Powiązana zawartość

• Typowe scenariusze używania zasad aktualizacji tabel
• Samouczek: kierowanie danych przy użyciu zasad aktualizacji tabeli