Udostępnij za pośrednictwem

Omówienie zasad aktualizacji

  • Artykuł

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.

Diagram przedstawia przegląd 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.
  • Funkcja zasad aktualizacji może odwoływać się do tabel w innych bazach danych. W tym celu zasady aktualizacji muszą być zdefiniowane za pomocą ManagedIdentity właściwości, a tożsamość zarządzana musi mieć viewerrolę w bazach danych, do których odwołuje się odwołanie.

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 nie musi być 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ń (za pomocą wtyczki).
  • Zapytanie nie ma dostępu do odczytu do tabel, które mają włączone zasady funkcji RestrictedViewAccess.
  • Aby uzyskać informacje o ograniczeniach zasad aktualizacji w pozyskiwaniu danych przesyłanych strumieniowo, 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, mogą 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. W związku z tym ważne jest, aby wszelkie zmiany były ze ostrożnością, aby zapewnić, ż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 się Query część:

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

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.

Właściwość Type Opis
IsEnabled bool Stany, jeśli zasady aktualizacji mają wartość true — włączone lub false — wyłączone
Źródło string Nazwa tabeli, która wyzwala wywołanie zasad aktualizacji
Query 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 i zasady aktualizacji nie powiedzie się, 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 słowem zarezerwowanym 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 utraci 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. Te akcje można wykonać przy użyciu dowolnego z następujących poleceń:

Ostrzeżenie

Gdy zasady aktualizacji są wywoływane jako część .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 jest wywoływane replace 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. 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.

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. 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:

.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

Powiązana zawartość