Хранят ли объединения на нескольких столбцах декартово произведение? - PullRequest
0 голосов
/ 23 мая 2018

Я транслитерировал скрипт из 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 минут без выброса хранилища.

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

1 Ответ

0 голосов
/ 23 мая 2018

U-SQL применяет некоторую эвристику переупорядочения соединений (хотя я не знаю, как она справляется с очевидным самосоединением).Я сомневаюсь, что это связано с тем, что вы используете несколько столбцов в предикате соединения.Я предполагаю, что наша эвристика может быть выключена.Можете ли вы подать заявку на инцидент или отправить мне ссылку на работу на [usql] на microsoft dot com?Таким образом, мы можем выяснить, что заставляет оптимизатор выбрать худший план.

До тех пор разбиение объединений на два оператора и, следовательно, наложение лучшего порядка соединения - лучший обходной путь.

...