2016-03-28 4 views
2

Каковы руководящие принципы или где мы можем найти рекомендации по разработке системы для оптимального параллелизма. Я понимаю, что данные разделяются по отдельным узлам и оптимизированы для этого.Оптимизация для максимальной степени параллелизма в Azure Data Lake

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

Однако я не вижу такого уровня параллелизма в графике работы. Он показывает MDOP, но не таким образом, который кажется оптимальным. У меня есть 4 разных расчета, которые выполняются независимо от клиента, сайта, продукта. Он сравнивается с 4 расчетами, но делает это на всем наборе данных. Когда на самом деле это должно быть в состоянии развернуть его, где говорят, что 10 узлов получают по 1 клиента каждый, тогда каждый из этих узлов может развернуть свои вычисления до еще четырех узлов. (номера примечаний здесь просто, например, масштаб данных намного больше).

Как оптимизировать макет файлов или логику U-SQL для поощрения большего количества MDOP?

ответ

1

Ваши данные поступают из неструктурированных файлов или таблиц U-SQL? Сколько данных вы обрабатываете (для получения параллелизма требуется не более 250 МБ в несегментированном файле).

Если данные поступают из файлов, вы можете разбить файлы и использовать наборы файлов и подсказки ROWCOUNT для улучшения параллелизма.

Если данные хранятся в таблицах U-SQL, вы можете использовать разбиение таблиц и кластеризацию столбцов, чтобы повлиять на распараллеливание.

Также, на каком уровне вы смотрите на распараллеливание? Обратите внимание, что график заданий показывает вам супер вершины (SV), которые показывают группу вершин, выполняющих ту же работу. Каждая вершина внутри (если данных достаточно) будет выполняться параллельно на фрагменте данных. И - если возможно - будет передано другим вершинам с минимальным перетасовкой.

+0

Да, это неструктурированные файлы. В настоящее время мы имеем 89 файлов в месяц, с 15 месяцами файлов = 1350 файлов, которые составляют от 48 до 227 МБ каждый. Мы могли бы объединить эти CVS в отдельные файлы в месяц, если бы это повысило эффективность. –

+0

Итак, где-то около 1,5 млрд записей записей. Вы говорите о разделении файлов, подразумеваете ли вы, что группы компаний попадают в отдельные файлы? Можете ли вы указать любую информацию о наборах файлов и подсказки ROWCOUNT? Хотя кажется, что загрузка этого в секционированную таблицу может быть лучшим решением. –

+0

Наборы файлов находятся в документации по U-SQL по адресу http://aka.ms/usql_reference. Хотя вы уже разбиваете данные на файлы, кажется. вы можете добавить подсказку в конце выражения запроса, например, SELECT * FROM @rs WHERE предикат OPTION (ROWCOUNT = 50000); Но использование секционированной таблицы может быть лучшим подходом. –

Смежные вопросы