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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Настройка индекса index.max_terms_count определяет максимальное количество терминов, которые могут быть использованы в запросе terms. Значение по умолчанию — 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, что предоставляет привилегии на целевой индекс трансформера.

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

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