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

извлечение;
преобразование;
загрузка.

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

Благодарности

Благодарим Томаса Кейзера (Thomas Kejser) за участие в подготовке материала для серии — Службы SSIS: проектирование и настройка для повышения производительности (серия видеороликов по SQL Server). Этот видеоролик второй в серии.

Благодарим Карлу Саботту (Carla Sabotta) и Дугласа Лауденшлягера (Douglas Laudenschlager) за рекомендации и ценные отзывы.

Текст видеоролика

Временная метка видеоролика	Звук
00:00	Здравствуйте, меня зовут Дэвид Ноор, я старший разработчик служб SQL Server Integration Services в корпорации Майкрософт. Наш видеоролик посвящен настройке потока данных в пакете служб SSIS в выпуске Enterprise Edition. Это вторая часть серии видеороликов, озаглавленной Службы SSIS: проектирование и настройка для повышения производительности. В первой части серии Денни показал, как лучше всего выполнить измерение производительности пакетов служб SSIS и интерпретировать полученные результаты. Здесь, опираясь на данные первой части, мы рассмотрим вопросы повышения производительности потока данных в пакетах служб SSIS. Сначала мы определим общие составляющие, присутствующие во всех потоках данных, и покажем, с каких компонентов потока данных следует начинать работу по повышению производительности. После выявления проблем с производительностью можно вносить в поток данных разнообразные изменения, которые позволят ускорить работу и повысить эффективность. Мы рассмотрим ряд советов, предназначенных для этапов проектирования, разработки и выполнения потока данных. Начнем! Большинство задач потока данных в пакетах занимаются извлечением, преобразованием и загрузкой важных данных. Такие операции часто рассматриваются совместно. Настройка потоков данных заключается в настройке каждого из таких этапов потока данных: извлечения, преобразования и загрузки. Для задач извлечения данных мы рассмотрим настройку компонентов-источников служб SSIS и выполняемые ими запросы, которые обеспечивают лучшую производительность и минимальное воздействие на исходные системы. Для настройки преобразований в потоке данных анализируется выполняемый объем работы и выбирается оптимальный метод действий путем исключения необязательных этапов. Иногда операции преобразования помещаются в исходные запросы. Наконец, для настройки компонента потока данных, выполняющего загрузку, необходимо настроить компоненты-назначения служб SSIS, сети, механизм блокировки и другие факторы, которые могут помешать выполнению потока данных в ходе загрузки данных в назначение. В этом видеоролике мы дадим практические советы по настройке различных составляющих потока данных на всех трех этапах. Перед подробным разбором советов важно заметить, что для проблем производительности обычно не находится универсального решения. Маловероятно, что какой-то из приведенных здесь советов подойдет к любым проблемам с производительностью потока данных. Эти советы хорошо действуют в распространенных ситуациях, однако решение проблемы — это не слепое применение всех возможных рекомендаций. Для достижения оптимального результата следует всегда понимать назначение задач потока данных и проектировать их в соответствии с этим назначением, измерять текущую производительность и последовательно вносить изменения в поток данных, повторяя на каждом шаге процедуру измерения для определения влияния на производительность. В процессе анализа проблемы с производительностью легко увлечься подробностями, относящимися к определенной технологии или отдельному компоненту, иногда по причине хорошего знакомства с технологией или кодом. Однако в любом случае нужно представлять поток данных в контексте экосистемы в целом, состоящей, скорее всего, из нескольких реляционных баз данных, сети, операционных систем, файловых систем — множества компонентов. Чем больше известно об экосистеме в целом, тем более полным будет представление о реальных проблемах производительности, стоящих перед отдельным компонентом, что позволит более эффективно и с меньшей степенью риска вносить изменения.
03:38	Сначала рассмотрим операцию извлечения, с которой начинается поток данных. Если в качестве источника используется SQL Server или любая другая база данных с интерфейсом массовых операций, следует подобрать увеличенный размер пакета. В обычных ситуациях хорошо работает установленное в SQL Server значение по умолчанию (4096), но, поскольку в ходе извлечения будут перемещаться данные большого объема, увеличение этого параметра должно помочь. Чтобы увеличенный размер пакета оказал влияние на работу, нужно попросить сетевого администратора включить в сети крупные кадры. При этом следует проверить воздействие таких изменений на пакет. Если для массовых операций и однострочных операций используется один диспетчер соединений (например, источник OLE DB и команда OLE DB command), рекомендуется создать второй диспетчер соединений для команд OLE DB и использовать в нем пакеты меньшего размера. Как уже отмечалось, если операции извлечения, преобразования и загрузки выполняются в Windows 2008 на многоядерном компьютере с несколькими сетевыми адаптерами, то можно несколько повысить производительность сети, привязав сетевые адаптеры к разным ядрам. Дополнительные сведения см. в сообщении в блоге Масштабирование объемного сетевого трафика в Windows на веб-узле MSDN (на английском языке). В ходе настройки извлечения данных проще всего заниматься настройкой применяемых запросов. Часто выглядит весьма заманчивым выбрать таблицу для извлечения и разрешить выборку всех столбцов, однако, если выбирать только действительно необходимые столбцы, результаты окажутся заметно лучше. Это не только снизит объем сетевого трафика и используемой памяти, но также заметно уменьшит число операций ввода-вывода, выполняемых сервером для обработки запроса. Здесь показано, как для SQL Server можно с помощью подсказки указать, что в операции выбора не нужно применять совмещаемые блокировки, поэтому запрос потенциально может считывать незафиксированные или «грязные» данные. Используйте такой метод только в случаях, когда действительно необходима максимальная производительность и считывание «грязных» данных не вызовет проблем с операциями извлечения, преобразования и загрузки. Уточняющие запросы можно считать извлечением или преобразованием, но в любом случае следует применять принципы, показанные на предыдущем слайде. Здесь еще более важно выбирать только необходимые столбцы, поскольку наряду с оптимизацией сети это позволит оптимизировать кэш в памяти. Если используется SQL Server 2008, одной из новых функций, отлично подходящих для настройки производительности, является новый общий кэш уточняющих запросов. Общий доступ к кэшу уточняющих запросов позволяет один раз получать эталонные данные и использовать их в нескольких операциях уточняющего запроса в рамках пакета или даже в различных пакетах, сохранив кэш в файле. Если несколько компонентов «Уточняющий запрос» ссылаются на одну таблицу, следует обратиться к этой новой функции, чтобы существенно повысить скорость пакетов. Она используется очень просто: создайте в пакете диспетчер соединений с кэшем, заполните кэш с помощью нового преобразования «Кэш», а затем измените уточняющие запросы так, чтобы они обращались за эталонными данными к этому соединению с кэшем.
06:29	Переходим ко второму этапу: преобразование данных. В процессе преобразования работа идет с данными, уже загруженными в поток данных, чтобы придать им нужную структуру перед загрузкой в систему. В службах SSIS каждое преобразование представляется объектом, который можно перетащить в схему пакета, однако не все преобразования одинаковы. Рассмотрим три типа преобразований, существующие в службах SSIS. Синхронные (построчные) преобразования работают с буферами данных на месте. Они не создают копии буферов и строк данных в ходе потока, а непосредственно преобразуют данные в буфере. В результате синхронные преобразования выполняются относительно быстро. Примерами синхронных преобразований являются преобразования «Конвертация данных», «Производный столбец» и «Уточняющий запрос». Частично блокирующие, асинхронные преобразования работают иначе. Когда данные поступают в такие преобразования, для выполнения работы преобразование должно удерживать данные. Для этого создается копия входных данных во внутренних буферах. На это расходуется память, иногда значительный объем памяти. Когда поток данных продолжается, преобразование может приступить к записи выходных данных. В ходе этой операции освобождается зарезервированная внутренняя память. После завершения потока данных преобразования освобождают всю занятую память, но до этого момента обычно обрабатывается заметный объем данных. Примерами преобразований такого типа служат «Слияние», «Соединение слиянием» и «Объединить все». Если в поток данных входят преобразования этого типа, следует найти пути оптимизации. Присутствуют ли лишние копии таких преобразований? Есть ли преобразования «Соединение слиянием» или «Объединение», которые можно перенести в исходную систему? Мне встречались пакеты, где вместо операции JOIN в исходном запросе выполнялась выборка всех данных из двух таблиц с помощью источников OLE DB, а затем в пакете выполнялось преобразование «Соединение слиянием», хотя можно было просто написать соединение SQL в источнике, и это позволило бы сильно ускорить процесс за счет оптимизации этого запроса средствами базы данных. Учитывайте подобные возможности для консолидации и сокращения числа асинхронных преобразований. В SQL Server 2008 проделана большая работа с планировщиком задач потока данных, чтобы повысить производительность сложных потоков данных и лучше задействовать доступные ЦП. Если работа со службами SSIS велась в версии SQL Server 2005, то в поток данных могло добавляться преобразование «Объединить все» для искусственного разделения и параллельной обработки деревьев выполнения. Теперь так поступать не нужно. Новые возможности SQL Server 2008 позволяют отказаться от таких преобразований. Удаление таких искусственных компонентов «Объединить все» обычно приводит к повышению производительности. Третью группу составляют блокирующие асинхронные преобразования. Это предельная версия преобразований предыдущей группы — им необходимо удерживать в памяти ВСЕ входные данные перед началом записи выходных данных. Применение таких преобразований в потоках данных с большими пакетами часто вызывает значительное замедление потока данных. Если подобные преобразования присутствуют в потоках данных большого объема, убедитесь, что отсутствуют лишние копии преобразований. Если в одном потоке с одними и теми же данными два раза выполняется статистическая обработка или сортировка, переделайте пакет так, чтобы обойтись одним преобразованием. После основных принципов перейдем к более специализированным советам. В потоках данных часто бывает необходимо преобразовать тип данных столбца. Постарайтесь выполнять преобразование только один раз и использовать самые компактные типы, чтобы сохранить минимальный размер буферов данных. Приведение типов данных занимает ресурсы процессора, и, если во всем потоке данных можно использовать один тип для заданного столбца, рекомендуется привести столбец к этому типу в источнике данных с помощью функций SQL CAST, CONVERT или их эквивалентов в диалекте SQL, используемом в базах данных. Я отмечал на одном из предыдущих слайдов, что для оптимизации преобразований следует тщательно продумывать место их размещения и свободно пользоваться средствами SQL в источниках. Например, если выполняется сортировка исходных данных, рекомендуется реализовать эту операцию предложениями ORDER BY на языке SQL в источнике. База данных может возвращать отсортированные данные намного более эффективно, чем поток данных. Компонент сортировки следует использовать только в случаях, когда нужно отсортировать данные, полученные в результате слияния из нескольких источников. Аналогично некоторые операции статистической обработки будут выполняться быстрее в источнике с помощью GROUP BY и статистических функций SQL. Если в SQL Server 2008 используется медленно изменяющееся измерение, обратите внимание на новую функцию MERGE в SQL Server. Функция MERGE может выполнять большинство задач, выполняемых медленно изменяющимся измерением, со значительно меньшим объемом передачи по сети. Также не забывайте о пользе функции SQL INSERT INTO. В простом потоке данных, когда источник и назначение лежат в одном экземпляре базы данных, перемещение данных можно сильно ускорить, выполнив единственную инструкцию SQL, чтобы перемещение данных выполнялось в пределах базы данных. В таких случаях инструкция INSERT INTO будет работать на порядок быстрее, чем поток данных, поскольку данным не нужно будет покидать сервер. Наконец, если выполняется добавочная загрузка, в качестве альтернативы рассмотрите простую перезагрузку данных. Я видел системы, в которых много времени затрачивалось на выявление разности, чтобы избежать перезагрузки данных, однако на это уходило столько ресурсов ввода-вывода и процессора, что в результате работа выполнялась медленнее, чем в случае собственно перезагрузки.
11:59	Переходим к этапу загрузки данных. В процессе загрузки в SQL Server есть два способа повышения производительности. Первая возможность — параметр «Назначение SQL Server». Этот компонент использует общую память для потока данных и ядра СУБД, чтобы быстро загружать данные. Однако он работает только в случае, когда поток данных все время работает на одном компьютере с экземпляром SQL Server. Кроме того, назначение SQL Server обладает некоторыми документированными ограничениями, относящимися к обработке ошибок. Другим вариантом быстрой загрузки данных в SQL Server является назначение «OLE DB», которое часто работает почти так же быстро, как назначение «SQL». Во всех этих случаях установка нулевого фиксируемого размера позволит максимально ускорить загрузку. Весьма распространенной практикой является удаление индексов в системе назначения при загрузке больших объемов данных, однако это следует делать на основе разумных рекомендаций. Например, удаление индексов часто выбирается в зависимости от процентного увеличения ожидаемой нагрузки и типов индексов, построенных на таблице. Если на таблице построен единственный кластеризованный индекс, не удаляйте его. Данные в таблице упорядочены по этому ключу, и время на его удаление, вставку и перестроение практически никогда не будет меньше, чем время на загрузку данных с кластеризованным индексом. Если на таблице построен единственный некластеризованный индекс, рекомендуется удалить его, если нагрузка повлечет примерно стопроцентный рост объема данных. Это не точное значение, а практическая рекомендация, однако если размер таблицы не вырастет вдвое, то будет вряд ли разумным заниматься удалением и перестроением индекса. Если на таблице построено несколько индексов, то дать общую рекомендацию сложно. Я привык мыслить категориями 10-процентного увеличения. Например, для нагрузок меньше 10 % текущего объема, вероятно, стоит оставить индексы, однако лучше всего самостоятельно попробовать различные варианты и судить по практическим результатам. Если данные загружаются в таблицу, с которой выполняются другие операции, понадобится выработать определенную стратегию. Операции массовой загрузки, скорее всего, заблокируют большую часть целевой таблицы (или всю таблицу), и если блокировка нежелательна, то следует применить секционирование. Если нужно выполнять загрузку в рабочую базу данных, может потребоваться организация секции для загрузки, чтобы сохранить активность рабочих данных. Если нагрузка обрабатывается медленно, следует проверить, какие другие операции выполняются с таблицей или секцией, и убедиться, что не возникает конфликт. Прекрасное руководство по повышению производительности массовой загрузки данных и работе с секциями содержится в статье SQLCAT Руководство по производительности загрузки данных, доступной на веб-узле MSDN (на английском языке). Кроме того, в случае повторной загрузки для очистки данных используйте команду TRUNCATE, а не DELETE, чтобы удаление не выполнялось посредством транзакций. Назначения, которые используют сетевое подключение, также подвержены сетевым проблемам, описанным раньше. Следите за ростом размера пакетов и включите в сети крупные кадры, чтобы добиться оптимальной производительности во время загрузки.
15:02	На этом мы завершим вторую часть серии материалов, посвященных производительности. Выражаю особую благодарность Томасу за все ценные сведения, ставшие основой этой серии видеороликов, а также Карле и Дугласу за помощь в создании серии. Дополнительные сведения по этим темам см. в статье 10 рекомендаций по службам SQL Server Integration Services. Спасибо за внимание. Непременно ознакомьтесь с остальными тремя частями серии Службы SSIS: проектирование и настройка для повышения производительности. Надеемся, что эта информация оказалась полезной, и будем искренне рады получить ваши отзывы. Ссылка, позволяющая оценить материал и оставить отзыв, находится в правом верхнем углу на странице видеороликов.

Share via

Настройка потока данных в пакете служб SSIS в выпуске Enterprise Edition (видеоматериал по SQL Server)

Краткое содержание видеоролика

Благодарности

Текст видеоролика

См. также

Другие ресурсы

Справка и информация

Дополнительные ресурсы