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

  • Статья

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

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

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

На схеме показан обзор политики обновления.

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

Примечание

  • Исходная и целевая таблицы должны находиться в одной базе данных.
  • Схема функции политики обновления и схема целевой таблицы должны совпадать в именах столбцов, типах и порядке.

Прием форматированных данных повышает производительность, и csv-файл является предпочтительным из-за четко определенного формата. Однако иногда вы не можете контролировать формат данных или хотите обогатить принятые данные, например путем объединения записей со статической таблицей измерений в базе данных.

Запрос политики обновления

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

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

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

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

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

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

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

  • Не используйте полное имя таблицы. Вместо этого используйте TableName.
  • Не используйте database("DatabaseName").TableName или cluster("ClusterName").database("DatabaseName").TableName.

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

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

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

Примечание

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

Примечание

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

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

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

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

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

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

При вызове политики обновления в рамках команды данные в производных таблицах .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:falseпо умолчанию , данные по-прежнему могут приниматься в исходную таблицу, даже если политика не выполняется.

Установка IsTransactional:true гарантирует согласованность между данными в исходной и целевой таблицах. Однако если условия политики завершаются сбоем, данные не будут приниматься в исходную таблицу. Кроме того, в зависимости от условий иногда данные помечаются в исходную таблицу, но не в целевую. Однако если политика определена неправильно или имеется несоответствие схемы, данные не будут приниматься в исходную или целевую таблицу. Например, несоответствие между выходной схемой запроса и целевой таблицей может быть вызвано удалением столбца из целевой таблицы.

Сбои можно просмотреть с помощью .show ingestion failures команды .

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

Лечение сбоев

Политика nontransactional

Если задано значение IsTransactional:false, любой сбой при выполнении политики игнорируется. Повторный прием не выполняется автоматически. Вы можете повторить прием вручную.

Политика транзакций

Если задано значение IsTransactional:true, если методом приема является pull, используется служба Управление данными, и прием автоматически выполняется повторно в соответствии со следующими условиями:

  • Повторные попытки выполняются до тех пор, пока не будет достигнут один из следующих настраиваемых параметров ограничения: DataImporterMaximumRetryPeriod или DataImporterMaximumRetryAttempts
  • По умолчанию DataImporterMaximumRetryPeriod значение параметра составляет два дня, а DataImporterMaximumRetryAttempts— 10
  • Период задержки начинается с 2 минут и удваивается. Таким образом, ожидание начинается с 2 минут, затем увеличивается до 4 минут, до 8 минут, до 16 минут и так далее.

В любом другом случае вы можете повторить прием вручную.

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

Параметры политики обновления можно использовать для извлечения, преобразования, загрузки (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. Чтобы очистить исходную таблицу после приема данных в целевую таблицу, определите политику хранения в исходной таблице, чтобы в качестве SoftDeletePeriodзначения были заданы значения 0 .

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

См. также