Обзор политики обновления

Область применения: ✅Microsoft Fabric✅Azure Data Explorer

Политики обновления — это механизмы автоматизации, активируются при записи новых данных в таблицу. Они устраняют необходимость специальной оркестрации путем выполнения запроса для преобразования принятых данных и сохранения результата в целевую таблицу. В одной таблице можно определить несколько политик обновления, что позволяет одновременно сохранять данные в несколько таблиц и сохранять данные в несколько таблиц. Целевые таблицы могут иметь другую схему, политику хранения и другие политики из исходной таблицы.

Например, таблица источника трассировки с высокой скоростью может содержать данные, отформатированные как свободный текстовый столбец. Целевая таблица может включать определенные строки трассировки с хорошо структурированной схемой, созданной из преобразования данных свободного текста исходной таблицы с помощью оператора синтаксического анализа. Дополнительные сведения см . в распространенных сценариях.

На следующей схеме показано высокоуровневое представление политики обновления. В нем показаны две политики обновления, которые активируются при добавлении данных во вторую исходную таблицу. После активации преобразованные данные добавляются в две целевые таблицы.

Политика обновления применяется к тем же ограничениям и рекомендациям, что и регулярное прием. Политика масштабируется в соответствии с размером Eventhouse и более эффективна при обработке массового приема.

Примечание.

• Исходная и целевая таблица должны находиться в одной базе данных.
• Схема функции политики обновления и целевая схема таблицы должны соответствовать именам столбцов, типам и порядкам.
• Функция политики обновления может ссылаться на таблицы в других базах данных. Для этого политика обновления должна быть определена свойством ManagedIdentity , а управляемое удостоверение должно иметь viewerроль в базах данных, на которые ссылается ссылка. Прием отформатированных данных повышает производительность, и CSV-файл предпочтительнее, так как это хорошо определенный формат. Однако иногда у вас нет контроля над форматом данных или вы хотите расширить прием данных, например путем объединения записей со статической таблицей измерений в базе данных.

Обновление запроса политики

Если политика обновления определена в целевой таблице, несколько запросов могут выполняться при приеме данных в исходную таблицу. Если существует несколько политик обновления, порядок выполнения не обязательно известен.

Ограничения запросов

• Запрос, связанный с политикой, может вызывать хранимые функции, но:
  • Он не может выполнять межсерийные запросы.
  • Он не может получить доступ к внешним данным или внешним таблицам.
  • Не удается сделать выноски (с помощью подключаемого модуля).
• Запрос не имеет доступа на чтение к таблицам с включенным политикой RestrictedViewAccess.
• По умолчанию политика приема потоковой передачи включена для всех таблиц в хранилище событий. Чтобы использовать функции с оператором join в политике обновления, необходимо отключить политику приема потоковой передачи. Используйте команду .altertableTableNamepolicystreamingingestionPolicyObject, чтобы отключить ее.

Предупреждение

Неправильный запрос может предотвратить прием данных в исходную таблицу. Важно отметить, что ограничения, а также совместимость результатов запроса и схемы исходных и целевых таблиц могут привести к неправильному запросу, чтобы предотвратить прием данных в исходную таблицу.

Эти ограничения проверяются во время создания и выполнения политики, но не при произвольных хранимых функциях, на которые может ссылаться запрос. Поэтому важно внести любые изменения с осторожностью, чтобы убедиться, что политика обновления остается нетронутой.

При ссылке Source на таблицу в Query части политики или в функциях, на которые ссылается Query часть:

• Не используйте полное имя таблицы. Используйте TableName.
• Не используйте database("<DatabaseName>").TableName или cluster("<EventhouseName>").database("<DatabaseName>").TableName.

Объект политики обновления

Таблица может содержать нулевые или более объекты политики обновления, связанные с ней. Каждый такой объект представлен в виде контейнера свойств JSON со следующими свойствами.

Свойство	Type	Описание
IsEnabled	bool	Состояния, если политика обновления имеет значение true , включена или false — отключена
Исходный код	string	Имя таблицы, которая активирует вызов политики обновления
Query	string	Запрос, используемый для создания данных для обновления
IsTransactional	bool	Указывает, является ли политика обновления транзакционной или нет, значение по умолчанию равно false. Если политика транзакционная, а политика обновления завершается ошибкой, исходная таблица не обновляется.
РаспространениеIngestionProperties	bool	Указывает, если свойства, указанные во время приема в исходную таблицу, например теги экстентов и время создания, применяются к целевой таблице.
Управляемоеудостоверение	string	Управляемое удостоверение, от имени которого выполняется политика обновления. Управляемое удостоверение может быть идентификатором объекта или зарезервированным словом system . Политика обновления должна быть настроена с управляемым удостоверением, если запрос ссылается на таблицы в других базах данных или таблицах с включенной политикой безопасности на уровне строк. Дополнительные сведения см. в статье "Использование управляемого удостоверения для запуска политики обновления".

Примечание.

В рабочих системах задайте IsTransactionalзначение :true , чтобы целевая таблица не потеряла данные в временных сбоях.

Примечание.

Каскадные обновления разрешены, например из таблицы A, в таблицу B, в таблицу C. Однако если политики обновления определены циклическим образом, это обнаруживается во время выполнения, а цепочка обновлений сокращается. Данные приемируются только один раз в каждую таблицу в цепочке.

Команды управления

К командам управления политиками обновления относятся следующие команды:

• .show table *TableName* policy update отображает текущую политику обновления таблицы.
• .alter table *TableName* policy update определяет текущую политику обновления таблицы.
• .alter-merge table *TableName* policy update добавляет определения в текущую политику обновления таблицы.
• .delete table *TableName* policy update удаляет текущую политику обновления таблицы.

Политика обновления инициируется после приема

Политики обновления вступают в силу при приеме или перемещении данных в исходную таблицу или экстенты создаются в исходной таблице. Эти действия можно выполнить с помощью любой из следующих команд:

• Прием .ingest (pull)
• Прием .ingest (встроенный)
• .set | .append | .set-or-append | .set-or-replace
• Экстенты перемещения
• Экстенты .replace
  • Команда PropagateIngestionProperties действует только в операциях приема. Если политика обновления активируется как часть .move extents или .replace extents команда, этот параметр не действует.

Предупреждение

При вызове политики обновления в рамках .set-or-replace команды данные по умолчанию в производных таблицах заменяются так же, как и в исходной таблице. Данные могут быть потеряны во всех таблицах с отношением политики обновления, если replace вызывается команда. Вместо этого рекомендуется использовать .set-or-append.

Удаление данных из исходной таблицы

После приема данных в целевую таблицу можно дополнительно удалить из исходной таблицы. Задайте период 0sec обратимого удаления (или00:00:00) в политике хранения исходной таблицы и политику обновления как транзакцию. Применяются следующие условия:

• Исходные данные не запрашиваемые из исходной таблицы
• Исходные данные не сохраняются в устойчивом хранилище в рамках операции приема
• Повышение производительности операций. Ресурсы после приема сокращаются для фоновых операций очистки экстентов в исходной таблице.

Примечание.

Если исходная таблица имеет период 0sec обратимого удаления (или 00:00:00), любая политика обновления, ссылающаяся на эту таблицу, должна быть транзакционной.

Влияние на производительность

Политики обновления могут повлиять на производительность и прием экстентов данных умножается на число целевых таблиц. Важно оптимизировать запрос, связанный с политикой. Вы можете проверить влияние политики обновления на производительность, вызвав политику в уже существующих экстентах, прежде чем создавать или изменять политику, или функцию, используемую с запросом.

Оценка использования ресурсов

Используйте .show queries, чтобы оценить использование ресурсов (ЦП, память и т. д.) со следующими параметрами:

• Задайте свойство, имя исходной Source таблицы, как MySourceTable
• Query Задайте свойство для вызова функции с именем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

Параметры транзакций

Параметр политики IsTransactional обновления определяет, является ли политика обновления транзакционной и может повлиять на поведение обновления политики следующим образом:

• IsTransactional:false: если для значения задано значение по умолчанию, значение false, политика обновления не гарантирует согласованность данных в исходной и целевой таблице. Если политика обновления завершается ошибкой, данные будут приема только в исходную таблицу, а не в целевую таблицу. В этом сценарии операция приема выполнена успешно.
• IsTransactional:true: если значение имеет значение true, параметр гарантирует согласованность данных в исходных и целевых таблицах. Если политика обновления завершается ошибкой, данные не будут приема в исходную или целевую таблицу. В этом сценарии операция приема завершается неудачно.

Обработка сбоев

При сбое обновлений политики они обрабатываются по-разному в зависимости от того, является IsTransactional ли true параметр или false. Распространенные причины сбоев политики обновления:

• Несоответствие между выходной схемой запроса и целевой таблицей.
• Любая ошибка запроса.

С помощью команды можно просмотреть ошибки обновления политики с помощью .show ingestion failures следующей команды : в любом другом случае можно вручную повторить прием.

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

Пример извлечения, преобразования, загрузки

Параметры политики обновления можно использовать для выполнения извлечения, преобразования, загрузки (ETL).

В этом примере используйте политику обновления с простой функцией для выполнения ETL. Сначала мы создадим две таблицы:

• Исходная таблица — содержит один строковый столбец, в который вставляется данные.
• Целевая таблица — содержит нужную схему. Политика обновления определена в этой таблице.

1. Создадим исходную таблицу:

   .create table MySourceTable (OriginalRecord:string)
   

2. Затем создайте целевую таблицу:

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

3. Затем создайте функцию для извлечения данных:

   .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. Теперь задайте политику обновления, чтобы вызвать созданную функцию:

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

5. Чтобы очистить исходную таблицу после приема данных в целевую таблицу, определите политику хранения в исходной таблице, чтобы иметь значение 0 в качестве его SoftDeletePeriod.

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

Связанный контент

• Распространенные сценарии использования политик обновления таблиц
• Руководство. Маршрутизация данных с помощью политик обновления таблиц