Оптимальные параметры потока данных SSIS для загрузки в рабочую таблицу в Azure SQL DW

У меня довольно широкая таблица размером 350 МБ с двумя столбцами varchar (2000). Через поток данных SSIS загрузка через пункт назначения «быстрой загрузки» OLEDB в Azure SQL DW занимает 60 минут. Я изменил место назначения в этом потоке данных на назначение Azure Blob (из функции SSIS Azure pack), и тот же поток данных завершился за 1,5 минуты (а Polybase из этого нового плоского файла занимает около 2 минут).

Для другого источника у меня есть уже существующий плоский файл размером 1 ГБ. Поток данных SSIS в пункт назначения OLEDB в Azure SQL DW занимает 90 минут. Скопируйте файл в хранилище BLOB-объектов, и загрузка Polybase займет 5 минут.

SSIS - это SSIS 2014, работающий на виртуальной машине Azure в том же регионе, что и Azure SQL DW. Я знаю, что массовая загрузка выполняется намного медленнее, чем Polybase, поскольку массовая загрузка проходит через управляющий узел, но Polybase распараллеливается на всех вычислительных узлах. Но эти цифры массовой загрузки очень медленные.

Каковы оптимальные настройки потока данных SSIS и места назначения, чтобы как можно быстрее загрузить в промежуточную таблицу Azure SQL DW с помощью массовой загрузки? В частности, меня интересует оптимальное значение для следующих параметров в дополнение к любым другим параметрам, которые я не рассматриваю:

  • Геометрия рабочего стола = HEAP (я считаю, что это самый быстрый)
  • Data flow settings:
    • DefaultBufferMaxRows = ?
    • DefaultBufferSize =?
  • OLEDB destination settings
    • Data access mode = Table or view - fast load
    • Keep Identity = unchecked
    • Оставить нули =?
    • Блокировка стола =?
    • Проверить ограничения =?
    • Строк в партии =?
    • Максимальный размер фиксации вставки =?

ssis azure-sqldw
person GregGalloway    schedule 17.03.2016    source источник

Ответы (1)


arrow_upward
7
arrow_downward

Polybase - это, безусловно, самый быстрый способ загрузки в SQL DW. HEAP, как вы предложили, также является самым быстрым типом назначения. Взгляните на эту статью от команды SQL CAT на рекомендации по загрузке в кластерное хранилище столбцов с использованием служб SSIS. Команда инженеров рекомендует попробовать настроить DefaultBufferMaxRows (по умолчанию 10 КБ), DefaultBufferSize (по умолчанию 10 МБ), Строки на пакет и Максимальный размер фиксации вставки.

Много лет назад я провел обширное тестирование производительности SSIS для нашей локальной версии хранилища данных SQL Azure, PDW, также известного как Parallel Data Warehouse или APS, Appliance Platform System. В этом тестировании я часто обнаруживал, что узким местом был локальный ЦП, особенно одноядерное. Это можно четко увидеть с помощью Perfmon, если вы отслеживаете загрузку ЦП по ядрам.

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

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

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

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

Еще вы можете попробовать сбалансированный распределитель данных SSIS < / а>. BDD - это еще один способ использовать несколько ядер в исходной системе без необходимости запускать несколько одновременных пакетов SSIS.

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

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

Надеюсь, это поможет.

person Sonya Marshall    schedule 26.03.2016
comment
Спасибо, Соня. В потоке данных, который занимал 60 минут, переключение таблицы stage из columnstore в HEAP сделало его в 2–3 раза быстрее, а максимальное значение DefaultBufferSize (что из-за ширины строки привело к появлению 10 000 буферов строк, даже если DefaultBufferMaxRows было 100 000). примерно еще в 2-3 раза быстрее. Так что теперь он работает менее чем за 8 минут. BDD не оказал существенного влияния в этом конкретном тесте (DWU400 с пользователем mediumrc). Другие настройки назначения потока данных, которые я тестировал, также не имели существенного значения. Думаю, мы нашли двух главных виновников. - person GregGalloway; 01.04.2016