Загрузка данных Azure SQL DW занимает много времени

Я пытаюсь загрузить данные из своих внешних таблиц во внутренние таблицы SQL DW. У меня есть хранилища данных в сжатом формате в хранилище BLOB, а внешние таблицы указывают на расположение хранилища BLOB.

У меня есть около 24 файлов, размер которых составляет около 22 ГБ, и я пытаюсь загрузить данные из внешней таблицы во внутреннюю таблицу на 300 DWU с более крупной учетной записью службы/пользователя класса ресурсов.

Моя вставка в выписку (которая очень прямолинейна) выполняется более 10 часов. вставить в Trxdata.Details_data выбрать * из Trxdata.Stage_External_Table_details_data;

Я также пробовал с приведенным ниже заявлением, которое также работает более 10 часов. CREATE TABLE Trxdata.Details_data12 WITH (DISTRIBUTION = ROUND_ROBIN) AS SELECT * FROM Trxdata.Stage_External_Table_details_data;

Я вижу - оба SQL выполняются со статусом ACTIVE в "sys". "dm_pdw_exec_requests" [я думал, что это может быть проблема со слотом параллелизма, и у него нет слотов параллелизма для запуска, но это не так]

и я надеялся, что увеличение/увеличение DWU может улучшить производительность. но, глядя на использование DWU на портале.azure.com, я не уверен, что стоит увеличивать DWU, потому что на диаграмме использования DWU показано ‹50DWU за последние 12 часов.

График использования DWU

Итак, я пытаюсь понять, как я могу найти, что занимает так много времени. Как я могу повысить производительность загрузки данных?


person Aravind    schedule 19.08.2016    source источник
comment
Еще одна краткая статистика, которой можно поделиться. Когда я попытался обработать 7 сжатых файлов [формат LZ4] размером 6,63 ГБ, содержащих 455 миллионов записей, завершенных за 115 минут [400 DWU, класс ресурсов большего размера, работающий через SSMS, используется оператор вставки, работающий из Windows Виртуальная машина Azure, расположенная в том же месте, что и хранилище больших двоичных объектов, и хранилище данных SQL, хранилище больших двоичных объектов + SQL + виртуальная машина находятся в том же месте в Azure.]   -  person Aravind    schedule 20.08.2016


Ответы (3)


Я подозреваю, что ваша проблема заключается в сжатии файлов. Во многих лазурных документах указано, что вы получите только одно средство чтения для каждого сжатого файла. В качестве теста я бы посоветовал вам распаковать ваши данные и попробовать загрузить и посмотреть, будет ли распаковка/загрузка быстрее, чем 10 часов загрузки сжатых данных, которые вы сейчас видите. Мне также повезло с несколькими файлами, а не с одним большим файлом, если это вариант для вашей системы.

person user2565762    schedule 22.09.2016

Пожалуйста, ознакомьтесь с приведенным ниже блогом SQL CAT об оптимизации загрузки данных. https://blogs.msdn.microsoft.com/sqlcat/2016/02/06/azure-sql-data-warehouse-loading-patterns-and-strategies/

Основываясь на предоставленной информации, следует принять во внимание несколько вещей:

1) Расположение файлов BLOB-объектов по сравнению с экземпляром DW. Убедитесь, что они находятся в одном регионе. 2) Clustered Columnstore включен по умолчанию. Если вы загружаете 22 ГБ данных, загрузка HEAP может работать лучше (но также не уверена в количестве строк). Так:

CREATE TABLE Trxdata.Details_data12 
WITH (HEAP, DISTRIBUTION = ROUND_ROBIN)
AS SELECT * FROM Trxdata.Stage_External_Table_details_data ;

Если проблема не устранена, отправьте запрос в службу поддержки: https://azure.microsoft.com/en-us/documentation/articles/sql-data-warehouse-get-started-create-support-ticket./

person Ron Ortloff    schedule 19.08.2016
comment
Привет Рон. 1. Да, BLOB и SQL DW находятся в одном месте (ЗАПАД США). 2. Ожидается, что сжатые файлы объемом 22 ГБ будут содержать около 1,1 миллиарда записей. Я инициировал загрузку сейчас, дайте мне посмотреть, как это происходит. - person Aravind; 20.08.2016
comment
Я также попытался запустить CREATE TABLE WITH HEAP, но безуспешно, INSERT INTO заняло (в таблицу хранилища столбцов) - заняло 4 часа 27 минут, тогда как CREATE WITH HEAP заняло 4 часа 50 минут. - person Aravind; 20.08.2016

Вы упомянули, что данные в сжатом формате. В скольких сжатых файлах хранятся данные? Для сжатых файлов вы добьетесь большего параллелизма и, следовательно, лучшей производительности, когда данные распределены по многим файлам. Наличие данных в нескольких файлах не требуется для несжатых файлов для повышения производительности, поэтому еще один способ проверить, является ли это вашей проблемой производительности, — распаковать ваши файлы.

person Sonya Marshall    schedule 20.08.2016
comment
Привет, Соня, Один файл в одном сжатом файле (в сжатом формате LZ4). Всего в моих 24 файлах содержится 1,1 млрд записей. и распаковка каждого файла занимает немного больше времени, так как у меня всего 512 файлов (я начал с 24 файлов, чтобы оценить производительность), и каждый файл имеет размер около 1 ГБ, а несжатый размер каждого файла будет около 10 ГБ. - person Aravind; 20.08.2016
comment
Это может помочь просмотреть статью azure .microsoft.com/en-us/documentation/articles/, чтобы проверить длительный этап, которым, предположительно, будет HadoopRoundRobinMoveOperation, и убедиться, что все устройства чтения и записи DMS (sys.dm_pdw_dms_workers) используют одинаковую сумму. времени, что у вас нет какого-то перекоса обработки. Если вы можете, было бы хорошим тестом распаковать файлы, чтобы увидеть, получите ли вы существенно другую производительность. - person Sonya Marshall; 20.08.2016
comment
Еще одна вещь, которая может повлиять на производительность, — это определение столбцов намного шире, чем они должны быть. azure.microsoft.com/en-us/documentation/articles/ - person Sonya Marshall; 20.08.2016
comment
Благодарю. типы данных/точность не намного шире. На данный момент мы продолжаем загружать форматы LZ4 напрямую во внутреннюю таблицу SQL DW (что занимает много времени), но все же у меня есть любопытный вопрос: почему диаграмма единиц DWU не ВЫСОКАЯ, даже когда я пытаюсь загрузить огромные данные, и загрузка данных занимает много времени - person Aravind; 26.08.2016