Я транслитерировал скрипт из T-SQL в U-SQL и столкнулся с проблемой запуска задания, а именно с тем, что он, похоже, «завис» на одном из этапов - через 2,5 часа график задания показал, что он прочитал200 МБ и написал более 3 ТБ, но не было почти готово.(Не сделал снимок экрана, извините.)
Я проследил его до одного из запросов, соединяющих таблицу с 34 миллионами строк дважды к таблице с 1600 строками:
@ProblemQuery =
SELECT
gp.[Group], // 16 groups
gp.[Percentile], // 1-100
my_fn(lt1.[Value], lt2.[Value], gp.[Value]) AS CalculatedNumber
FROM
@LargeTable AS lt1
INNER JOIN @GroupPercent AS gp
ON lt1.[Group] == gp.[Group]
AND lt1.[Row ID] == gp.[Row ID 1]
INNER JOIN @Large Table AS lt2
ON gp.[Group] == lt2.[Group]
AND gp.[Row ID 2] == lt2.[Row ID]
;
Кажется, что полный декартовой продукт (~ 2e18 строк) сохраняется во время обработки, а не только отфильтрованные 1600 строк.Моей первой мыслью было, что это может быть использование AND
, а не &&
, но изменение не имело значения.
Мне удалось обойти эту проблему, разделив один запрос с двумя объединениями вдва запроса с одним соединением каждый, и вся работа была выполнена менее чем за 15 минут без выброса хранилища.
Но мне не ясно, является ли это полностью ожидаемым поведением, когда в соединении используются несколько столбцов, или ошибкаи есть ли лучший подход к такого рода вещам.У меня есть еще один подобный запрос, который нужно разделить (с большим количеством объединений и большим количеством столбцов в условии соединения), и я не могу помочь, но чувствую, что должен быть менее грязный способ сделать это.