Omówienie zasad aktualizacji
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.
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.
Zasady aktualizacji podlegają tym samym ograniczeniom i najlepszym rozwiązaniom co regularne pozyskiwanie. Zasady są skalowane w poziomie zgodnie z rozmiarem usługi Eventhouse 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ćviewer
rolę 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.
- Zapytanie związane z zasadami może wywoływać przechowywane funkcje, ale:
- Nie może wykonywać zapytań między magazynami zdarzeń.
- 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.
- Domyślnie zasady pozyskiwania przesyłania strumieniowego są włączone dla wszystkich tabel w usłudze Eventhouse. Aby używać funkcji z operatorem
join
w zasadach aktualizacji, zasady pozyskiwania przesyłania strumieniowego muszą być wyłączone. Aby go wyłączyć, użyj polecenia.alter
table
TableNamepolicy
streamingingestion
PolicyObject.
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
anicluster("<ClusterName>").database("<DatabaseName>").TableName
.
- Nie używaj kwalifikowanej nazwy tabeli. Zamiast tego użyj polecenia
TableName
. - Nie używaj
database("<DatabaseName>").TableName
anicluster("<EventhouseName>").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ą:
-
.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.
- Polecenie
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ść, 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.
Utwórzmy tabelę źródłową:
.create table MySourceTable (OriginalRecord:string)
Następnie utwórz tabelę docelową:
.create table MyTargetTable (Timestamp:datetime, ThreadId:int, ProcessId:int, TimeSinceStartup:timespan, Message:string)
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 }
Teraz ustaw zasady aktualizacji, aby wywołać utworzoną funkcję:
.alter table MyTargetTable policy update @'[{ "IsEnabled": true, "Source": "MySourceTable", "Query": "ExtractMyLogs()", "IsTransactional": true, "PropagateIngestionProperties": false}]'
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