Почему политика обновления в Azure Data Explorer применяется к комбинации экстентов в исходной таблице? Можем ли мы ограничить это запуском в одном экстенте одновременно?

ProgramBox

Почему политика обновления в Azure Data Explorer применяется к комбинации экстентов в исходной таблице? Можем ли мы ограничить это запуском в одном экстенте одновременно?

Post author:admin
Запись опубликована:17 марта, 2023
Post category:Вопросы по программированию

#azure-data-explorer

Вопрос:

Запрос в политике обновления, которую мы используем, имеет ограничение, заключающееся в том, что он отлично работает только с небольшим количеством строк. Скорость поступления в эту исходную таблицу контролируется соответствующим образом. Кроме того, отредактировали политику сегментирования, чтобы разрешить только ограниченное количество строк. Однако обновление начинает завершаться сбоем, когда политика обновления применяется к нескольким экстентам одновременно.

 Failed to invoke update policy. Target Table = 'settings', Query = 'let raw_config3 = 
__table("raw_config3", 'All', 'AllButRowStore') 
| where extent_id() in (guid(58b4a126-8ff2-4c04-a8f8-d6be2629c865), guid(10d66fec-5146-4d63-b3db-d15ba52244b9), guid(8bc99805-9dcd-43ed-8133-402ba77eb566), guid(8127f67e-8d20-4096-bf46-f3736c77ecd5));
getBiosSettings()': Semantic error: 'let raw_config3 = 
__table("raw_config3", 'All', 'AllButRowStore') 
| where extent_id() in (guid(58b4a126-8ff2-4c04-a8f8-d6be2629c865), guid(10d66fec-5146-4d63-b3db-d15ba52244b9), guid(8bc99805-9dcd-43ed-8133-402ba77eb566), guid(8127f67e-8d20-4096-bf46-f3736c77ecd5));
getBiosSettings()' has the following semantic error: SEM0100: 'summarize' operator: Failed to resolve scalar expression named 'Path'.

Является ли ожидаемый сценарий применения политики обновления к комбинации экстентов? Можно ли это настроить каким-либо образом?

Редактировать 1 — Добавление некоторого контекста к тому, чего мы пытаемся достичь. У нас есть многоуровневые XML-данные, выгруженные в виде одного поля в исходной таблице. Политика обновления использует запрос для извлечения некоторой информации из этого поля и сохранения ее в виде отдельных строк в целевой таблице. Поскольку XML-данные имеют глубину в несколько уровней и содержат поля массива, нам нужно использовать mv expand и bag unpack в указанном запросе. Это прерывается, когда входные данные превышают определенную величину.

Пытался ограничить размер экстента для исходной таблицы с помощью MaxRowCount. Однако политика обновления применяет запрос к нескольким экстентам вместе. Есть ли способ настроить это поведение?

Является ли плохой практикой наличие сложного запроса (как описано выше) в политике обновления?

Редактировать 2 —————————————————————-

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

Существует исходная таблица «Источник», мы вводим данные в нее каждые 10 минут партиями по 5 записей. Существует политика обновления, настроенная для простого копирования ее в целевую таблицу с именем Target . И существует политика обновления для записи количества данных, с которыми политика выполняется каждый раз, и то же самое сохраняется в Target2.

Учитывая, что мы отправляем одинаковый объем данных каждые 10 минут, я ожидал увидеть постоянное значение в Target2, и для каждой уникальной строки, которую мы отправляем, я ожидаю одну запись в Target2.

Команды установки —

 .create table Source(Turn : string, Batch: string, Data: string )

.create table Target(Turn : string, Batch: string, Data: string )

.create table Target2(Count: long )

.create function copySource(){ Source }

.alter table Target policy update 
@'[{"IsEnabled": true,  "Source": "Source", "Query": "copySource()", "IsTransactional": false}]'

.create function copySourceWithCount() { Source | count  }

.alter table Target2 policy update 
@'[{"IsEnabled": true,  "Source": "Source", "Query": "copySourceWithCount()", "IsTransactional": false}]'

Количество записей, для которых выполняется политика обновления, продолжает регулярно увеличиваться вместо того, чтобы быть постоянным-

 Target2 
| extend ingestion_time()
| order by $IngestionTime asc

 
Count   $IngestionTime
    5   2020-09-27T10:03:50.3236393Z
    10  2020-09-27T10:26:52.8994856Z
    15  2020-09-27T10:37:04.2836551Z
    20  2020-09-27T10:47:05.638047Z

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

 Target
| summarize count() by Turn, Batch, Data
| where Turn contains "b"
| order by count_ desc

 Turn Batch Data Count
    b   0   0   5
    b   0   1   5
    b   0   2   5
    b   0   3   5
    b   0   4   5
    b   1   0   4
    b   1   1   4
    b   1   2   4
    b   1   3   4
    b   1   4   4
    b   2   0   3
    b   2   1   3
    b   2   2   3
    b   2   3   3
    b   2   4   3
    b   3   0   2
    b   3   1   2
    b   3   2   2
    b   3   3   2
    b   3   4   2
    b   4   0   1
    b   4   1   1
    b   4   2   1
    b   4   3   1
    b   4   4   1

Из этого, похоже, политика обновления выполняется для одних и тех же данных несколько раз. Ожидается ли это?

Ответ №1:

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

В зависимости от количества записей в этом пакете и от значения MaxRowCount свойства в действующей политике сегментирования.
Этот пакет может охватывать более 1 фрагмента данных (экстента).
Однако, если в вашем запросе не сделано предположение о количестве входных экстентов (чего не должно быть), это не должно приводить к каким-либо сбоям.

На первый взгляд, семантическая ошибка, показанная в вашем исходном сообщении, относится не к количеству исходных экстентов, а к самому запросу — Failed to resolve scalar expression named 'Path'. .

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

1. Используемый нами запрос включал использование плагина bag_unpack пару раз, и это прерывается, когда входные данные превышают определенную величину.

2. Отредактировал вопрос, чтобы добавить некоторый контекст к тому, чего мы пытаемся достичь. Повторяя вопрос здесь, является ли плохой практикой иметь сложный запрос в политике обновления?

3. Ошибка, которую вы написали, является семантической ошибкой, которая возникает в результате сочетания логики в вашем запросе на обновление и динамического содержимого / схемы ваших данных. Уменьшение объема данных за операцию приема вряд ли решит проблему — вы должны убедиться, что логика в вашей функции работает на «стабильной» схеме вывода и не делает предположений о содержимом исходных данных, которые могут меняться от одного пакета приема к другому.

4. Я понимаю, что могу отредактировать запрос, чтобы сделать его более надежным. Однако я проверил, что запрос выполняется нормально для 10 записей данных и прерывается на 20 записях одних и тех же данных [одни и те же строки, отправленные повторно]. Плагин bag_unpack прерывается, и это, вероятно, связано с тем, что при наличии больших входных данных существует УСЛОВИЕ LOW_MEOMORY. Учитывая размер данных в строке и требуемую обработку, я пытаюсь попробовать это с меньшим объемом входных данных.

5. Также я подозреваю, что входные данные становятся больше, чем ожидалось, по какой-то причине политика обновления работает. Следовательно, пытаюсь это понять. Добавили к вопросу сценарий, в котором политика обновления заставляет запрос выполняться с одними и теми же данными несколько раз и, следовательно, с большим объемом данных, чем ожидалось. Можете ли вы взглянуть и сообщить мне, является ли это ожидаемым поведением?

Ответ №2:

Как писал Yoni, ошибка, которую вы получаете, не связана с тем фактом, что несколько экстентов обрабатываются вместе как часть политики обновления.

Ошибка гласит 'summarize' operator: Failed to resolve scalar expression named 'Path' . Из того, что я понимаю из вашего вопроса, иногда вы получаете эту ошибку, а иногда нет. Это означает, что схема вашего запроса не является детерминированной, потому что у вас есть evaluate pivot evaluate bag_unpack или что-то подобное в вашем запросе, и в некоторых случаях Path столбец не создается.

Если это проблема с загружаемыми данными, вам придется ее исправить. Однако, если ожидается, что иногда столбца Path там не будет, тогда вы можете использовать column_ifexists(Path, "DefaultValue") .

1. Спасибо, запрос использует bag_unpack и прерывается, когда объем входных данных превышает определенную величину, что приводит к этой ошибке. Итак, я пытался ограничить входные данные, используя MaxRowCount в политике сегментирования. Мы отправляем данные с контролируемой медленной скоростью. Но похоже, что политика обновления применяется к нескольким экстентам одновременно. И это означает, что большие данные и тогда запрос прерывается