Повышение производительности потока данных

Свойство MaxConcurrentExecutables является свойством самого пакета. Оно определяет число одновременно работающих задач. По умолчанию оно имеет значение –1, что означает число физических или логических процессоров +2.

Чтобы понять работу этого свойства, рассмотрим образец пакета, в котором есть три задачи потока данных. Если задать для свойства MaxConcurrentExecutables значение 3, то все три задачи потока данных смогут выполняться одновременно. Однако предположим, что каждая задача потока данных имеет 10 деревьев выполнения «источник-назначение». Если свойство MaxConcurrentExecutables имеет значение 3, то нельзя гарантировать, что деревья выполнения внутри каждой задачи потока данных будут работать параллельно.

Свойство EngineThreads является свойство задачи потока данных. Это свойство определяет число потоков, которое подсистема обработки потока данных может создать и выполнять параллельно. Свойство EngineThreads применяется одинаково как к потокам источника, которые подсистема обработки потока данных создает для источников, так и к потокам исполнителя, которые подсистема создает для преобразований и назначений. Таким образом, если свойство EngineThreads имеет значение 10, подсистема может создавать до десяти потоков источника и до десяти потоков исполнителя.

Чтобы понять работу этого свойства, рассмотрим образец пакета с тремя задачами потока данных. Каждая задача потока данных содержит десять деревьев выполнения «источник-назначение». Если свойство EngineThreads для каждой задачи потока данных имеет значение 10, все 30 деревьев выполнения потенциально могут выполняться одновременно.

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

Многие компоненты потока данных используют запросы как для извлечения данных из источников, так и для операций поиска, чтобы создать ссылочные таблицы. По умолчанию запрос использует синтаксис SELECT * FROM <Имя таблицы>. Этот тип запроса возвращает все столбцы исходной таблицы. Так как все столбцы доступны во время разработки, можно выбрать любой столбец в качестве столбца поиска, сквозного или исходного столбца. Однако после выбора используемых столбцов следует изменить запрос таким образом, чтобы в него были включены только выбранные столбцы. Удаление неиспользуемых столбцов делает поток данных пакета более эффективным, так как чем меньше столбцов, тем меньше создаваемая строка. А чем короче строка, тем больше строк может быть загружено в один буфер и тем меньше усилий потребует обработка всех строк набора данных.

Запрос можно создать путем ввода или с помощью построителя запросов.

Примечание

При запуске пакета в среде Business Intelligence Development Studio на вкладке «Ход выполнения» конструктора служб SSIS отображаются предупреждения. Они включают обнаружение любых столбцов данных, которые источник делает доступными для потока данных, но которые впоследствии не используются нисходящими компонентами потока данных. Для автоматического удаления таких столбцов можно использовать свойство RunInOptimizedMode.

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

Иногда источник данных уже упорядочен до использования нисходящим компонентом. Такая предварительная сортировка может происходить при использовании запроса SELECT с предложением ORDER BY, а также при вставке данных в источник в порядке сортировки. Для подобных, предварительно отсортированных исходных данных можно предоставить подсказку о том, что эти данные уже отсортированы, чтобы избежать использования преобразования «Сортировка» в соответствии с требованиями определенных нисходящих преобразований. Например, для преобразования «Слияние» и «Соединение слиянием» требуются отсортированные входные данные. Чтобы предоставить подсказку о том, что данные отсортированы, необходимо выполнить следующие задачи.

• Присвойте значение True свойству IsSorted на выходе из вышестоящего компонента потока данных.

• Укажите ключевые столбцы, по которым отсортированы данные.

Дополнительные сведения см. в разделе Как отсортировать данные для преобразований «Слияние» и «Соединение слиянием».

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

Дополнительные сведения см. в разделах Преобразование «Сортировка», Преобразование «Слияние», Преобразование «Соединение слиянием» и Преобразование «Многоадресная доставка».

При получении данных из представления с помощью источника OLE DB выберите режим доступа к данным «Команда SQL» и введите инструкцию SELECT. Обращение к данным с помощью инструкции SELECT дает более высокую производительность, чем при выборе режима доступа к данным «Таблица или представление».

Преобразование «Статистическая обработка» содержит свойства Keys, KeysScale, CountDistinctKeys и CountDistinctScale. Эти свойства улучшают производительность, позволяя преобразованию предварительно выделять память в размере, необходимом для кэширования данных. Если известно точное или приблизительное число групп, которые будут являться результатом операции Группировать по, задайте свойства Keys и KeysScale соответственно. Если известно точное или приблизительное число различающихся значений, которые будут являться результатом операции Подсчет различных объектов, задайте свойства CountDistinctKeys и CountDistinctScale соответственно.

Если в потоке данных необходимо создать несколько статистических выражений, попробуйте использовать одно преобразование «Статистическая обработка» вместо создания нескольких преобразований. Такой подход, в частности, повысит производительность, если статистическая обработка является подмножеством другой статистической обработки, поскольку преобразование сможет оптимизировать внутреннее хранилище и просматривать входящие данные только один раз. Например, если статистическое выражение использует предложение GROUP BY и статистическое выражение AVG, объединение их в одно преобразование может повысить производительность. Однако выполнение нескольких статистических выражений в пределах одного преобразования «Статистическая обработка» сериализует операции статистической обработки, и таким образом производительность может не повышаться при независимом вычислении нескольких статистических выражений.

Дополнительные сведения см. в разделе Преобразование «Статистическая обработка».

Сведения по оптимизации производительности преобразований «Нечеткий уточняющий запрос» и «Нечеткое группирование» см. в технической документации Преобразования «Нечеткий уточняющий запрос» и «Нечеткое группирование» в службах SQL Server Integration Services 2005.

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

Преобразование соединения баз данных слиянием включает свойство MaxBuffersPerInput, которое задает максимальное количество буферов, которые могут быть активны для каждого входного потока одновременно. Можно использовать это свойство для настройки объема памяти для буферов преобразования, и, следовательно, для настройки производительности преобразования. Чем большее количество буферов и памяти используется для преобразования, тем выше производительность. Значение по умолчанию для MaxBuffersPerInput равно 5. Такое количество буферов хорошо работает в большинстве сценариев. Для настройки производительности, возможно, понадобится немного изменить это число и попробовать значение 4 или 6. По возможности следует избегать использования слишком маленького количества буферов. Например, установка параметра MaxBuffersPerInput в 1 вместо 5 значительно повлияет на производительность. Кроме того, не следует присваивать параметру MaxBuffersPerInput значение 0 или меньше. Этот диапазон значений означает, что регулировка отсутствует, поэтому, в зависимости от загрузки данных и количества доступной памяти, пакет может не завершиться.

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

Дополнительные сведения см. в разделе Преобразование «Соединение слиянием».

Мастер медленно изменяющихся измерений и преобразование «Медленно изменяющееся измерение» являются средствами общего назначения, удовлетворяющими запросам большинства пользователей. Однако поток данных, формируемый мастером, не оптимизирован по производительности.

Как правило, самые медленные компоненты преобразования «Медленно изменяющееся измерение» — преобразования «Команда OLE DB», выполняющие инструкции UPDATE одновременно только для одной строки. Таким образом, самым эффективным способом повысить производительность преобразования «Медленно изменяющееся измерение» — замена преобразований «Команда OLE DB». Эти преобразования можно заменить целевыми компонентами, сохраняющими все строки для обновления в промежуточной таблице. Затем можно добавить задачу «Выполнение SQL», которая выполняет одну инструкцию Transact-SQL UPDATE одновременно для всех строк.

Опытные пользователи могут сконструировать пользовательский поток данных для обработки медленно изменяющегося измерения, оптимизированного для больших измерений. Обсуждение и примеры по решению этой задачи см. в разделе «Сценарий уникального измерения» в техническом документе Проект REAL. Рекомендации по разработке ETL-решений для бизнес-аналитики (на английском языке).

Когда пакет загружает данные в экземпляр SQL Server на этом же компьютере, используйте назначение SQL Server. Это назначение оптимизировано для высокоскоростной массовой загрузки.

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

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

При включении события PipelineComponentTime службы Integration Services записывают в журнал одно сообщение для каждого шага обработки, выполненного каждым компонентом. Следующие записи журнала показывают подмножество сообщений, которое регистрирует образец пакета CalculatedColumns служб Integration Services.

The component "Calculate LineItemTotalCost" (3522) spent 356 milliseconds in ProcessInput.

The component "Sum Quantity and LineItemTotalCost" (3619) spent 79 milliseconds in ProcessInput.

The component "Calculate Average Cost" (3662) spent 16 milliseconds in ProcessInput.

The component "Sort by ProductID" (3717) spent 125 milliseconds in ProcessInput.

The component "Load Data" (3773) spent 0 milliseconds in ProcessInput.

The component "Extract Data" (3869) spent 688 milliseconds in PrimeOutput filling buffers on output "OLE DB Source Output" (3879).

The component "Sum Quantity and LineItemTotalCost" (3619) spent 141 milliseconds in PrimeOutput filling buffers on output "Aggregate Output 1" (3621).

The component "Sort by ProductID" (3717) spent 16 milliseconds in PrimeOutput filling buffers on output "Sort Output" (3719).

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

• Источник OLE DB с именем «Извлечение данных» затратил 688 мс на загрузку данных.

• Преобразование «Производный столбец» с именем «Вычисление LineItemTotalCost» затратил 356 мс на вычисление входящих строк.

• Преобразование «Статистическая обработка» с именем «Сложение Quantity и LineItemTotalCost» затратило в общей сложности 220 мс (141 на шаге PrimeOutput и 79 на шаге ProcessInput) на вычисление и передачу данных следующему преобразованию.