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

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

Общие сведения о политике обновления в Azure обозреватель данных.

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

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

Примечание

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

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

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

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

  • Запрос может вызывать хранимые функции, но не может включать запросы между базами данных и между кластерами.
  • Запрос, который выполняется как часть политики обновления, не имеет доступа на чтение к таблицам с включенной политикой рестриктедвиевакцесс или с включенной политикой безопасность на уровне строк .
  • При ссылке на Source таблицу в Query части политики или в функции, на которые ссылается Query часть:
    • Не используйте полное имя таблицы. Вместо этого используйте TableName.
    • Не используйте database("DatabaseName").TableName или cluster("ClusterName").database("DatabaseName").TableName .
  • Сведения об ограничениях политики обновления при приеме потоковой передачи см. в разделе потоковая политика приема потоков.

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

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

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

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

Свойство Тип Описание
IsEnabled bool Указывает, включена ли политика обновления (true) или отключена (false)
Источник string Имя таблицы, которая активирует вызов политики обновления
Запрос string Запрос Kusto CSL, который используется для получения данных для обновления.
IsTransactional bool Указывает, является ли политика обновления транзакционной или нет (значение по умолчанию — false). Не удалось запустить политику обновления транзакций, так как исходная таблица не обновляется новыми данными
пропагатеинжестионпропертиес bool Указывает, что свойства приема (Теги экстентов и время создания), заданные во время приема в исходной таблице, также должны применяться к тем, которые относятся к производной таблице.

Примечание

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

Примечание

Каскадные обновления разрешены ( TableATableBTableC → >...).

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

Команды политики обновления

Ниже приведены команды для управления политикой обновления.

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

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

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

  • Когда политика обновления вызывается как часть .set-or-replace команды, поведение по умолчанию заключается в том, что данные в производных таблицах заменяются так же, как и в исходной таблице.
    • Это может привести к утрате данных во всех таблицах, имеющих связь политики обновления с этой таблицей, если replace часть выполняется.
    • Рекомендуется использовать .set-or-append вместо этого, если такое поведение не требуется.

Обычное получение с помощью политики обновления

Политика обновления будет вести себя как обычное приема, если выполняются следующие условия.

  • Исходная таблица является высокоскоростной таблицей трассировки с интересными данными в виде свободного текстового столбца.
  • Целевая таблица, в которой определена политика обновления, принимает только определенные строки трассировки.
  • Таблица имеет хорошо структурированную схему, которая является преобразованием исходных произвольных текстовых данных, созданных оператором Parse.

Нулевое хранение в исходной таблице

Иногда данные поступают в исходную таблицу только в качестве пошагового камень в целевую таблицу, и вы не хотите оставаться необработанными данными в исходной таблице. Задайте период обратимого удаления 0sec (или 00:00:00 ) в политике храненияисходной таблицы и задайте для политики обновления значение "транзакционная". В этом случае:

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

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

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

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

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

  • Имя исходной таблицы ( Source свойство политики обновления) имеет значение MySourceTable .
  • QueryСвойство политики обновления вызывает функцию с именем MyFunction() .
.show table MySourceTable extents;
// The following line provides the extent ID for the not-yet-merged extent in the source table which has the most records
let extentId = $command_results | where MaxCreatedOn > ago(1hr) and MinCreatedOn == MaxCreatedOn | top 1 by RowCount desc | project ExtentId;
let MySourceTable = MySourceTable | where extent_id() == toscalar(extentId);
MyFunction()

Сбои

По умолчанию сбой запуска политики обновления не влияет на прием данных в исходную таблицу. Однако если политика обновления определена как IsTransactional true, сбой запуска политики принудительно приводит к сбою приема данных в исходной таблице. В некоторых случаях прием данных в исходную таблицу завершается успешно, но во время приема в целевую таблицу произошел сбой политики обновления.

Ошибки, возникающие при обновлении политик, можно получить с помощью .show ingestion failures команды.

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

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

Нетранзакционная политика

Ошибка игнорируется Kusto. Любая повторная попытка является обязанностью владельца процесса приема данных.

Транзакционная политика

Исходная операция приема, вызвавшая обновление, также завершится ошибкой. Исходная таблица и база данных не будут изменены новыми данными. Если метод приема равен pull (служба управление данными Kusto участвует в процессе приема), то существует автоматическая повторная попытка для всей операции приема, управляемой управление данными службой Kusto, в соответствии со следующей логикой:

  • Повторные попытки выполняются до тех пор, пока не будет достигнуто самое раннее между DataImporterMaximumRetryPeriod (по умолчанию — 2 дня) и DataImporterMaximumRetryAttempts (значение по умолчанию — 10).
  • Оба указанных выше параметра можно изменить в конфигурации службы Управление данными.
  • Период отсрочки начинается с 2 минут и растет экспоненциально (2-> 4-> 8-> 16... тезис

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