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

Следующие ограничения и известные проблемы применимы к выпуску Elastic transform версии 7.17.28. Ограничения сгруппированы по следующим категориям:

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

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

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

Если преобразование содержит скрипты Painless, использующие устаревший синтаксис, при предварительном просмотре или запуске преобразования отображаются предупреждения об устаревании. Однако проверить предупреждения об устаревании для всех преобразований как объединённое действие невозможно, так как выполнение необходимых запросов может быть ресурсоёмким процессом. Поэтому предупреждения об устаревании из-за устаревшего синтаксиса Painless недоступны в помощнике по обновлению.

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

Непрерывное преобразование периодически проверяет изменения в исходных данных. Функциональность планировщика в настоящее время ограничена простым периодическим таймером, который может находиться в диапазоне frequency от 1 секунды до 1 часа. По умолчанию — 1 минута. Это предназначено для частых небольших запусков. При выборе frequency для этого таймера учитывайте скорость загрузки данных, а также влияние операций поиска/индексирования преобразования на других пользователей в вашем кластере. Также обратите внимание, что повторы происходят через frequency интервал.

Если ваш кластер содержит узлы смешанных версий, например, во время постепенного обновления с 7.2 или 7.3 до более новой версии, преобразования, узлы которых остановлены, не будут перераспределены до завершения обновления. После обновления преобразования возобновятся автоматически; никаких действий не требуется.

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

Вы можете просмотреть выведенные соответствия, используя API предварительного просмотра преобразования. См. объект generated_dest_index в ответе API.

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

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

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

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

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

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

При удалении преобразования с помощью DELETE _transform/index не удаляются ни целевой индекс, ни шаблон индекса Kibana, если таковой был создан. Эти объекты необходимо удалить отдельно.

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

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

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

Преобразование извлекает данные по частям, что означает, что оно вычисляет несколько корзин одновременно. По умолчанию это 500 корзин на операцию поиска/индексирования. Значение по умолчанию можно изменить с помощью max_page_search_size, а минимальное значение — 10. Если ошибки всё ещё возникают после того, как количество запрашиваемых корзин уменьшено до минимума, преобразование перейдёт в состояние ошибки.

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

Страница size определяется max_page_search_size, которая также используется для определения количества корзин, возвращаемых поиском агрегации в составе. Значение по умолчанию — 500, минимум — 10.

Настройка индекса index.max_terms_count определяет максимальное количество терминов, которые могут быть использованы в запросе терминов. Значение по умолчанию — 65536. Если max_page_search_size превышает index.max_terms_count, преобразование завершится ошибкой.

Использование меньших значений для max_page_search_size может привести к увеличению продолжительности завершения контрольной точки преобразования.

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

При удалении неисправного преобразования с помощью API, сначала остановите его с помощью _stop?force=true, а затем удалите.

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

Непрерывное преобразование периодически проверяет изменения сущностей в промежутке времени между последней проверкой и now минус sync.time.delay. Этот временной интервал перемещается без перекрытия. Если метка времени недавно индексированного документа попадает в этот временной интервал, но документ еще недоступен для поиска, то эта сущность не будет обновлена.

Если используется sync.time.field, представляющий время получения данных, и используется нулевое или очень небольшое значение sync.time.delay, то вероятность возникновения этой проблемы выше.

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

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

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

Если вы используете ILM для индексов с временной привязкой, рассмотрите использование имени индекса с датой вместо этого. Обработчик работает без дублирования документов, если ваше преобразование содержит group_by, основанное на date_histogram.

Пространства позволяют организовать исходные и целевые индексы и другие сохраненные объекты в Kibana и видеть только объекты, принадлежащие вашему пространству. Однако преобразование — это долговременная задача, управляемая на уровне кластера, и поэтому не ограничена определёнными пространствами. Учёт пространств может быть реализован для представления данных в Управление стеком > Kibana, что позволяет управлять привилегиями доступа к целевому индексу преобразования.

Если ваш кластер содержит узлы смешанных версий, например, во время поэтапного обновления с 7.2 до более новой версии, и преобразования были созданы в 7.2, пользовательский интерфейс преобразований (предыдущий интерфейс с табличками) не будет работать. Пожалуйста, дождитесь, пока все узлы не будут обновлены до новой версии, прежде чем использовать пользовательский интерфейс преобразований.

Страница управления преобразованиями в Kibana отображает до 1000 преобразований.

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