Таблица SQL Azure SQL не использует все распределения на вычислительных узлах для хранения данных

Question

Одна из таблиц Fact в нашем SQL Azure SQL DW (хранит данные телеметрии поезда) создается в виде распределенной таблицы HASH (ключ HASH - VehicleDimId - целочисленное поле, ссылающееся на таблицу размеров транспортных средств).Общее количество записей в таблице составляет ок.1.3 миллиарда.

В таблице имеется 60 уникальных значений VehicleDimId (т.е. у нас есть данные для 60 уникальных транспортных средств), что означает, что у них также есть 60 уникальных хеш-ключей.Исходя из моего понимания, я ожидаю, что записи, соответствующие этим 60 уникальным хеш-ключам VehicleDimId, должны быть распределены по 60 доступным распределениям (1 хеш-ключ для 1 распределения).

Однако в настоящее время все данные распределены только по 36 дистрибутивам, а в остальных 24 дистрибутивах записи отсутствуют.По сути, это всего лишь 60% использования доступных вычислительных узлов.Изменение масштаба хранилища данных не оказывает никакого влияния, так как число распределений остается неизменным до 60. В настоящее время мы используем SQL DW на уровне DW400.Ниже приведено количество записей таблицы на уровне вычислительных узлов.

Вы можете видеть, что данные распределяются неравномерно по вычислительным узлам (что связано с неравномерным распределением данных по базовым распределениям),

Я пытаюсь понять, что мне нужно сделать, чтобы SQL DW использовал все дистрибутивы, а не только 60% из них.

Answer 1

Другой вариант - создать объединенный ключ соединения, который может быть объединением двух разных ключей, что создаст большую мощность, чем та, что у вас есть сейчас с 60 x новой строкой, как правило, должно быть в тысячах или больше.Предостережение заключается в том, что на ключ необходимо ссылаться в каждом соединении, чтобы работа выполнялась по одному на каждый узел.Затем, когда вы хешируете этот ключ, вы получите более равномерный спред.

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

Answer 2

Хеш-распределение принимает хеш двоичного представления вашего ключа распределения, а затем детерминистически отправляет строку в назначенный дистрибутив.Как правило, значение int 999 попадает в один и тот же дистрибутив в каждом Azure SQL DW.Он не смотрит на ваши конкретные 60 уникальных идентификаторов транспортных средств и равномерно их разделяет.

Лучше всего выбирать поле (лучше всего, если оно используется в объединениях или групповых или разных счетах), которое имеет не менее 600 (в 10 раз больше распределений) достаточно равномерно используемых значений.Существуют ли другие поля, которые соответствуют этому критерию?

Чтобы процитировать из этой статьи добавление некоторого акцента:

Имеет много уникальных значений.Столбец может иметь несколько повторяющихся значений.Однако все строки с одним и тем же значением присваиваются одному и тому же распределению.Поскольку существует 60 распределений, столбец должен иметь не менее 60 уникальных значений.Обычно число уникальных значений значительно больше .

Если у вас есть только 60 различных значений, вероятность того, что вы получите равномерное распределение, очень мала.Чем в 10 раз больше значений, тем выше вероятность достижения равномерного распределения.

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

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

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