Устраните слишком долгую инициализацию в конвейерах

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

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

Замечание

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

Когда следует рассмотреть возможность разделения конвейера

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

• Этапы INITIALIZING и SETTING_UP_TABLES занимают больше времени, чем вы ожидаете, что влияет на общее время конвейера. Если процесс занимает более 5 минут, это часто можно улучшить путем разделения потока обработки данных.
• Драйвер, управляющий кластером, может стать узким местом при операциях с многими (более 30-40) потоковыми таблицами в одном потоке. Если драйвер не отвечает, длительность потоковых запросов увеличивается, что влияет на общее время обновления.
• Триггерный конвейер, имеющий несколько потоков таблицы, может быть не в состоянии выполнять все потоковые обновления параллельно.

Сведения о проблемах с производительностью

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

Узкие места на этапах инициализации и настройки таблиц

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

Этап ИНИЦИАЛИЗАЦИИ

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

этап SETTING_UP_TABLES

На этом этапе выполняются следующие процессы на основе планов, созданных на предыдущем этапе:

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

Почему инициализация и настройка таблиц могут занять больше времени

Большие конвейеры с большим количеством потоков для многих наборов данных могут занять больше времени по нескольким причинам:

• Для конвейеров с большим количеством потоков и сложными зависимостями эти этапы могут занять больше времени из-за объема работы.
• Сложные преобразования, включая Auto CDC преобразования, могут привести к ограничению производительности вследствие необходимости выполнения операций для материализации таблиц на основе определённых преобразований.
• Существуют также сценарии, в которых значительное количество потоков может привести к замедлению, даже если эти потоки не являются частью обновления. Например, рассмотрим конвейер с более чем 700 потоками, из которых менее 50 обновляются для каждого триггера на основе конфигурации. В этом примере каждый запуск должен пройти некоторые шаги для всех 700 таблиц, получить кадры данных, а затем выбрать их для выполнения.

Узкие места в драйвере

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

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

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

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

Компромиссы с разделением конвейеров

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

• Зависимости У вас может быть подчиненный конвейер, который зависит от нескольких вышестоящих конвейеров (вместо одного). Например, если у вас есть три конвейера: pipeline_A, pipeline_B и pipeline_C, и pipeline_C зависит от обоих pipeline_A и pipeline_B, вы хотите, чтобы pipeline_C обновлялся только после того, как pipeline_A и pipeline_B завершат обновления. Одним из способов решения этой проблемы является оркестрация зависимостей путем представления каждого конвейера в виде задачи в задании с учетом зависимостей, поэтому pipeline_C обновляется только после того, как и pipeline_A, и pipeline_B завершены.

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

Планирование разделения конвейеров

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

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

Разделение потока без полной перезагрузки данных

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

Дополнительные сведения см. в разделе "Перемещение таблиц между конвейерами".

Существуют некоторые ограничения, связанные с этим подходом:

• Трубопроводы должны быть в каталоге Unity.
• Исходные и конечные конвейеры должны находиться в одной рабочей области. Перемещение между рабочими областями не поддерживается.
• Целевой конвейер необходимо создать и запустить по крайней мере один раз (даже если выполнение завершается сбоем) перед перемещением.
• Нельзя переместить таблицу из конвейера, использующего режим публикации по умолчанию, в тот, который использует устаревший режим публикации. Дополнительные сведения см. в схеме LIVE (устаревшая версия).