Omówienie zasad aktualizacji

  • Artykuł

Zasady aktualizacji są mechanizmami automatyzacji wyzwalanymi po zapisaniu nowych danych do tabeli. Eliminują 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 umożliwia jednoczesne przekształcanie i zapisywanie danych w wielu tabelach. 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 linie śledzenia z dobrze ustrukturyzowanym schematem wygenerowanym na podstawie przekształcenia danych wolnego tekstu 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. Pokazuje ona dwie zasady aktualizacji wyzwalane po dodaniu danych do drugiej tabeli źródłowej i powoduje dodanie przekształconych danych do dwóch tabel docelowych.

Diagram przedstawia omówienie zasad aktualizacji.

Zasady aktualizacji podlegają tym samym ograniczeniom i najlepszym rozwiązaniom co regularne pozyskiwanie. Zasady są skalowane w poziomie zgodnie z rozmiarem klastra i są bardziej wydajne podczas obsługi pozyskiwania zbiorczego.

Uwaga

  • Tabela źródłowa i docelowa musi znajdować się w tej samej bazie danych.
  • Schemat funkcji zasad aktualizacji i schemat tabeli docelowej muszą być zgodne w nazwach kolumn, typach i kolejności.

Pozyskiwanie sformatowanych danych zwiększa wydajność, a plik CSV jest preferowany ze względu na dobrze zdefiniowany format. Czasami jednak nie masz kontroli nad formatem danych lub chcesz wzbogacić pozyskane dane, na przykład łącząc rekordy ze statyczną tabelą wymiarów w bazie danych.

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 niekoniecznie jest znana.

Ograniczenia zapytań

  • Zapytanie związane z zasadami może wywoływać przechowywane funkcje, ale:
    • Nie może wykonywać zapytań między klastrami.
    • Nie może uzyskać dostępu do danych zewnętrznych ani tabel zewnętrznych.
    • Nie może wykonywać wywołań (przy użyciu wtyczki).
  • Zapytanie nie ma dostępu do odczytu do tabel z włączonymi zasadami Funkcji RestrictedViewAccess .
  • Aby uzyskać ograniczenia zasad aktualizacji w pozyskiwaniu przesyłania strumieniowego, zobacz Ograniczenia pozyskiwania przesyłania strumieniowego.

Ostrzeżenie

Nieprawidłowe zapytanie może uniemożliwić pozyskiwanie danych do tabeli źródłowej. Należy pamiętać, że ograniczenia, a także zgodność między wynikami zapytania a schematem tabel źródłowych i docelowych, może spowodować nieprawidłowe zapytanie, aby zapobiec pozyskiwaniu danych do tabeli źródłowej.

Te ograniczenia są weryfikowane podczas tworzenia i wykonywania zasad, ale nie w przypadku zaktualizowania dowolnych przechowywanych funkcji, do których może się odwoływać zapytanie. Dlatego ważne jest, aby wszelkie zmiany były ostrożnie wprowadzane w celu zapewnienia, że zasady aktualizacji pozostają nienaruszone.

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

  • Nie używaj kwalifikowanej nazwy tabeli. Zamiast tego użyj polecenia TableName.
  • Nie używaj ani database("DatabaseName").TableNamecluster("ClusterName").database("DatabaseName").TableName.

Obiekt zasad aktualizacji

Tabela może zawierać co najmniej zero obiektów zasad aktualizacji skojarzonych z nią. Każdy taki obiekt jest reprezentowany jako torba właściwości JSON z następującymi właściwościami zdefiniowanymi.

Właściwość Typ Opis
IsEnabled bool Stany, jeśli zasady aktualizacji są prawdziwe — włączone lub false — wyłączone
Source string Nazwa tabeli, która wyzwala wywołanie zasad aktualizacji
Zapytanie string Zapytanie używane do tworzenia danych dla aktualizacji
Istransactional bool Stany, jeśli zasady aktualizacji są transakcyjne lub nie, wartość domyślna to false. Jeśli zasady są transakcyjne, a zasady aktualizacji kończą się niepowodzeniem, tabela źródłowa nie zostanie zaktualizowana.
PropagacjaingestionProperties bool Stany, jeśli właściwości określone podczas pozyskiwania do tabeli źródłowej, takie jak tagi zakresu i czas tworzenia, mają zastosowanie do tabeli docelowej.
ManagedIdentity string Tożsamość zarządzana, w imieniu której są uruchamiane zasady aktualizacji. Tożsamość zarządzana może być identyfikatorem obiektu lub zarezerwowanym wyrazem system . Zasady aktualizacji należy skonfigurować przy użyciu tożsamości zarządzanej, gdy zapytanie odwołuje się do tabel w innych bazach danych lub tabelach z włączonymi zasadami zabezpieczeń na poziomie wiersza. Aby uzyskać więcej informacji, zobacz Używanie tożsamości zarządzanej do uruchamiania zasad aktualizacji.

Uwaga

W systemach produkcyjnych ustaw wartość IsTransactional:true , aby upewnić się, że tabela docelowa nie traci danych w przejściowych awariach.

Uwaga

Aktualizacje kaskadowe są dozwolone, na przykład z tabeli A, do tabeli B, do tabeli C. Jeśli jednak zasady aktualizacji są definiowane w sposób cykliczny, jest to wykrywane w czasie wykonywania, a łańcuch aktualizacji jest wycinany. Dane są pozyskiwane tylko raz do każdej tabeli w łańcuchu.

Polecenia zarządzania

Polecenia zarządzania zasadami aktualizacji obejmują:

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 przy użyciu dowolnego z następujących poleceń:

Ostrzeżenie

Gdy zasady aktualizacji są wywoływane w ramach .set-or-replace polecenia, domyślnie dane w tabelach pochodnych są zastępowane w taki sam sposób jak w tabeli źródłowej. Dane mogą zostać utracone we wszystkich tabelach z relacją zasad aktualizacji, jeśli replace zostanie wywołane polecenie. Rozważ użycie .set-or-append zamiast tego.

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. Obowiązują następujące warunki:

  • Dane źródłowe nie można wykonywać 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.

Uwaga

Jeśli tabela źródłowa ma okres usuwania nietrwałego 0sec (lub 00:00:00), wszystkie zasady aktualizacji odwołujące się do tej tabeli muszą być transakcyjne.

Wpływ na wydajność

Zasady aktualizacji mogą mieć wpływ na wydajność klastra, a pozyskiwanie zakresów danych jest mnożone przez liczbę tabel docelowych. Ważne jest, aby zoptymalizować zapytanie związane z zasadami. Wpływ zasad aktualizacji na wydajność można przetestować, wywołując zasady w istniejących zakresach, przed utworzeniem lub zmianą zasad albo 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
  • Ustawianie właściwości w Query celu wywołania funkcji o nazwie 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

Błędy

Przy domyślnym IsTransactional:falseustawieniu programu dane mogą być nadal pozyskiwane do tabeli źródłowej, nawet jeśli zasady nie zostaną uruchomione.

Ustawienie IsTransactional:true gwarantuje spójność między danymi w tabeli źródłowej i docelowej. Jeśli jednak warunki zasad nie powiedzą się, dane nie są pozyskiwane do tabeli źródłowej. Alternatywnie, w zależności od warunków, czasami dane są pozyskiwane do tabeli źródłowej, ale nie do tabeli docelowej. Jeśli jednak zasady są zdefiniowane niepoprawnie lub występuje niezgodność schematu, dane nie są pozyskiwane do tabeli źródłowej ani docelowej. Na przykład niezgodność między schematem danych wyjściowych zapytania a tabelą docelową może być spowodowana usunięciem kolumny z tabeli docelowej.

Błędy można wyświetlić przy .show ingestion failures użyciu polecenia .

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

Leczenie niepowodzeń

Zasady nietransakcyjne

Po ustawieniu IsTransactional:falsewartości na wartość wszystkie błędy uruchamiania zasad są ignorowane. Pozyskiwanie nie jest automatycznie ponawiane. Możesz ręcznie ponowić próbę pozyskiwania.

Zasady transakcyjne

W przypadku ustawienia IsTransactional:truewartości , jeśli metoda pozyskiwania ma pullwartość , usługa Zarządzanie danymi jest zaangażowana, a pozyskiwanie jest automatycznie ponawiane zgodnie z następującymi warunkami:

  • Ponowne próby są wykonywane do momentu spełnienia jednego z następujących konfigurowalnych ustawień limitu: DataImporterMaximumRetryPeriod lub DataImporterMaximumRetryAttempts
  • Domyślnie ustawienie to DataImporterMaximumRetryPeriod dwa dni i DataImporterMaximumRetryAttemptswynosi 10
  • Okres wycofywania rozpoczyna się o 2 minuty i podwaja się. Więc oczekiwanie zaczyna się od 2 minut, a następnie zwiększa się do 4 minut, do 8 minut, do 16 minut itd.

W każdym innym przypadku można ręcznie ponowić próbę pozyskiwania.

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 operacji 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 pozyskaniu 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

Zawartość pokrewna