Почему Polybase работает медленно с большими сжатыми файлами, охватывающими 1 миллиард записей?

Что может привести к снижению производительности Polybase при запросе больших наборов данных для вставки записей в хранилище данных Azure из хранилища BLOB-объектов?

Например, несколько тысяч сжатых (.gz) файлов CSV с заголовками, разделенными на несколько часов в день на данные за 6 месяцев. Запросы этих файлов из внешней таблицы в SSMS не совсем оптимальны и очень медленны.

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

Какие варианты оптимизации Polybase доступны здесь? Дождаться запроса или постепенно загружать данные после каждой загрузки в хранилище BLOB-объектов?


azure azure-storage-blobs polybase azure-sqldw sql-data-warehouse
person Fastidious    schedule 20.02.2017    source источник
comment
Когда вы имеете в виду деградацию - вы имеете в виду стать медленнее со временем или просто медленнее в целом?   -  person Murray Foxcroft    schedule 20.02.2017
comment
Какой класс ресурсов вы используете? Рассмотрите возможность использования largec для повышения производительности за счет уменьшения параллелизма. Если вы подключены как пользователь-администратор по умолчанию, их класс ресурсов по умолчанию будет небольшим и не может быть изменен. DWU400 довольно низок для того, чтобы что-либо делать, почему бы временно не 1000, 2000 или 6000, а затем уменьшить его, когда ваш CTAS будет готов? Это одна из действительно полезных функций хранилища данных SQL Azure, наряду с функцией паузы.   -  person wBob    schedule 21.02.2017
comment
Мы на сайте xlarge. Мы на собственном опыте выяснили, что администратор был маленьким (почему?). В рамках бесплатного кредита мы ограничены 400 DWU. Мы пытаемся это исправить, но теперь нам нужно воссоздать, чтобы использовать текущую оплату. Мы попытаемся это сделать, чтобы увидеть, повлияет ли масштабирование до 6000 DWU.   -  person Fastidious    schedule 22.02.2017
comment
Некоторые другие передовые методы: не иметь нескольких файлов на zip-файл, количество файлов должно быть больше или равно общему количеству читателей для вашего целевого уровня обслуживания. На DWU400 максимальное количество внешних считывателей составляет 32. На DWU6000 максимальное количество внешних считывателей составляет 480. Вы также можете поэкспериментировать с mediumrc для потенциально увеличенного параллелизма. Пожалуйста, сообщайте о любых полученных вами результатах, так как они будут полезны для обсуждения!   -  person wBob    schedule 23.02.2017

Ответы (1)


arrow_upward
1
arrow_downward

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

Хранилище BLOB-объектов Azure (в настоящее время) достигает максимальной скорости около 1250 МБ / с, поэтому, если ваша пропускная способность не близка к максимальной, лучший способ повысить производительность - обновить DWU в хранилище данных SQL. . В фоновом режиме это распределит вашу рабочую нагрузку по большему кластеру (большему количеству серверов). DWU хранилища данных SQL можно масштабировать вверх и вниз за считанные минуты.

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

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

Вы также можете рассмотреть возможность использования фабрики данных Azure для выполнения этой работы. См. Здесь поддерживаемые форматы файлов. GZip поддерживается. Используйте действие копирования для копирования из хранилища BLOB-объектов в SQL DW.

Также загляните в:

  1. CTAS (создать таблицу как выбранную), самый быстрый способ перемещения данных из внешних таблиц во внутреннее хранилище в хранилище данных Azure.
  2. Создание статистики для ваших внешних таблиц, если вы собираетесь запрашивать их повторно. Хранилище данных SQL не создает статистику автоматически, как SQL Server, и вам нужно сделать это самостоятельно.
person Murray Foxcroft    schedule 20.02.2017
comment
Может, я не совсем понимаю. Чтобы загрузить данные в Azure, мне нужно добавить файлы в хранилище BLOB-объектов. Я делаю это с помощью Azcopy. Попав в хранилище, я настраиваю ключи API в Azure и создаю внешнюю таблицу для файлов. Тогда единственный способ загрузить данные - правильно запросить внешнюю таблицу во внутреннюю? Есть ли другой способ? Я предполагаю, что мой единственный вариант - масштабировать DWU, о чем я не знал, что повлияло на Polybase. И мне сказали, что Gzip быстрее запрашивает, но похоже, что это может быть неверно для больших наборов данных. - person Fastidious; 20.02.2017
comment
Мой DWU на момент этого запроса составляет 400 DWU для справки. - person Fastidious; 20.02.2017
comment
Gzip добавляет дополнительный уровень служебных данных, его необходимо распаковать перед обработкой. Стоимость хранилища дешевая, а вычислительные ресурсы дороги, поэтому я бы загрузил в Azure в формате CSV (через запятую или вертикальную черту). Polybase «проще» с ними справиться, и вы увидите улучшенную производительность. Помните, что внешние таблицы - это просто файлы, которые считываются механизмом хранилища данных, не ожидайте, что они будут работать так же хорошо, как собственные таблицы. Вы можете написать свой собственный код для вставки непосредственно из локальной среды в Azure DW или использовать SSIS, многие из старых инструментов работают нормально, и DW отлично работает с использованием стандартной строки подключения. - person Murray Foxcroft; 20.02.2017
comment
Также см. Мое добавление к ответу об использовании CTAS msdn.microsoft.com/en- us / library / mt204041.aspx - person Murray Foxcroft; 20.02.2017
comment
Данные находятся в корзине с другой платформы. Например, он не поступает из локального хранилища данных и уже сжат. Я могу попробовать распаковать данные, когда они попадут в сеть. Я предполагаю, что нет способа декомпрессировать данные в большом двоичном объекте, когда они там, верно? - person Fastidious; 20.02.2017
comment
Кажется, мне придется скачать, разархивировать и повторно загрузить. Вздох. Спасибо за информацию! Я одобряю это как ответ, который заключается в использовании DWU и распаковке данных для уменьшения накладных расходов. - person Fastidious; 20.02.2017
comment
Спасибо. Если у вас огромные тома и медленный Интернет, было бы проще установить виртуальную машину в Azure и выполнить распаковку там. - person Murray Foxcroft; 20.02.2017
comment
Да, это то, что я сделал здесь, чтобы получить данные из другого облачного хранилища, отличного от Amazon S3. Загрузите на виртуальную машину Ubuntu, Azcopy и загрузите все данные. Но, я думаю, это слишком много данных для 400 DWU. - person Fastidious; 21.02.2017
comment
Маловероятно, что вычислительные ресурсы - ваше узкое место. У вас есть только 1 читатель на каждый сжатый файл. Есть некоторые накладные расходы на вычисления, но если ваш экземпляр DW уже не привязан к вычислениям, узким местом, скорее всего, будет количество читателей. Как отмечалось выше, DWU400 дает вам 32 считывателя. Это означает, что несколько тысяч файлов, сжатых или нет, проходят по 32 каналам. Почти наверняка не привязка вычислений. Протестируйте тот же набор файлов на самом высоком DWU и RC, который вы можете сэкономить, и посмотрите, как это будет происходить, прежде чем начинать предварительную обработку файлов. - person SQLmojoe; 25.02.2017