Бенчмаркинг хранилища данных SQL DWU

Question

Я собираю несколько простых анализов для оценки влияния DWU на чтение и запись на основе выражения CTAS.

Запрос объединяет таблицу строк 1.7b в таблицу из 993 тысяч строк. Исходные и конечные таблицы распределены по схеме "круговой прием" (источник не будет RR долгосрочным, будет перемещен в HASH), запрос примерно такой:

create table CTAS_My_DWU_Test 
with (distribution = round_robin) 
as
select TableKey1, TableKey2, 
SumCcolumn=SUM(SalesAmt), 
MaxQuantity=MAX(SalesQty), 
MinQuantity=MIN(SalesQty)
from FactSales
group by TableKey1, TableKey2
option (label='MyDWUTest');

Я анализирую производительность через DMV sys.dm_pdw_dms_workers, получая среднее значение bytes_per_second по каждому распределению как для type=DIRECT_READER, так и для type=WRITER.

Мой процесс состоит в том, чтобы изменить DWU, удалить CTAS, воссоздать его и проанализировать данные в DMV.

Я не вижу постоянного улучшения производительности, поскольку я увеличиваю DWU. Моя цель - найти четкое доказательство увеличения вычислений, однако иногда более высокий DWU медленнее и возвращает меньше bytes_per_sec, чем меньший DWU.

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

Нужна помощь в процессе, основанном на одной таблице, и вы хотите, чтобы на данный момент движение / объединение данных не входило в уравнение.

Answer 1

Хороший вопрос! Архитектура хранилища данных SQL Azure является более производительной при меньшем перемещении данных. Я рекомендую выполнить шаги, описанные в этой статье, чтобы определить, какой шаг замедляет процесс: https://azure.microsoft.com/en-us/documentation/articles/sql-data-warehouse-manage-monitor/

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

Что касается 10-кратной производительности при повторном запуске, это связано с внутренним кэшированием в нашей системе.

Сообщите нам, что вы найдете в плане запроса, плане выполнения и т. Д.