#snowflake-cloud-data-platform
Вопрос:
В Snowflake я выполняю базовую инструкцию merge для обновления набора строк в таблице. Таблица содержит 1B строк и составляет 160 ГБ. Таблица кластеризуется с использованием столбца TenantId в качестве ключа кластеризации. Этот столбец содержит 10 тысяч различных значений с довольно равномерным распределением.
Данные, которые я объединяю, являются просто обновлениями и включают 1 млн записей, предназначенных для подмножества этих идентификаторов арендаторов (~500). Слияние соединяет этот источник с целью на основе TenantId (ключа кластера цели) и идентификатора записи.
В результате слияния правильно указано количество строк, которые были обновлены, но это занимает больше времени, чем я ожидал. Если я посмотрю на детали выполнения запроса, я увижу, что операция слияния в плане (которая занимает почти все время по сравнению со сканированием / объединением таблиц) содержит «Отсканированные байты» и «Записанные байты», которые равны размеру моей таблицы 160 ГБ.
Написанные байты, похоже, касаются там. Есть ли способ заставить его фокусировать записи на микропересекциях, имеющих отношение к затрагиваемым записям? Не похоже, что для этого нужно писать полный размер таблицы.
Глубина кластера для таблицы: 1.0208
Информация о кластере для таблицы: { «cluster_by_keys» : «ЛИНЕЙНЫЙ(TENANTID)», «total_partition_count» : 29827, «total_constant_partition_count» : 29646, «average_overlaps» : 0,0323, «average_depth» : 1,0208, «partition_depth_histogram» : { «00000» : 0, «00001» : 29643, «00002» : 19, «00003» : 49, «00004» : 55, «00005» : 17, «00006» : 9, «00007» : 25, «00008» : 5, «00009» : 5, «00010» : 0, «00011» : 0, «00012» : 0, «00013» : 0, «00014» : 0, «00015» : 0, «00016» : 0 } }
Комментарии:
1. Под «разделенным по TenantId» я предполагаю, что это означает, что на нем определен ключ кластеризации. Можете ли вы поделиться определением ключа кластеризации и выводом system$clustering_информации?
2. Да, это был ключ к кластеризации. Обновил вопрос, чтобы уточнить это и включить информацию о кластеризации.
3. Снова запустил запрос, и у него была лучшая производительность и записано меньше байтов. Байты, записанные сейчас, составляют ~65 ГБ, а входные данные включали 500 из 10 тыс. арендаторов. Я думаю, что отличие от моего первого запуска в том, что, возможно, с тех пор произошло затворничество. Это лучше, но все еще записывает 40% таблицы, когда я обновил 1% строк и коснулся 5% своих значений ключа кластера.
4. Группировка на столе выглядит очень хорошо. Вы, вероятно, уже знаете, что, поскольку хранилище объектов является неизменяемым, обновление одной строки в микропересекции требует полной перезаписи микропересекции. Если только 5% идентификатора TenantId имеют обновления, но это влияет на 40% байтов таблицы, это, вероятно, связано с тем, что некоторые значения идентификатора TenantId содержат намного больше строк, чем другие, и заполняют несколько микропересекций. Обновления этих строк TenantId могут повлиять на множество микропересекций.
5. Я подозревал, что это относится к обновлению полных микро-разделов, но спасибо за подтверждение. Что касается распределения данных, то на самом деле это просто настройка POC, в настоящее время у каждого арендатора одинаковое количество записей. Так что все еще удивляюсь количеству затронутых микросекций.
Ответ №1:
Вы должны понять, что происходит внизу и как работают микропересекции, чтобы понять, что происходит.
Таблицы снежинок кажутся изменяемыми (допускают обновления), но под ними находятся неизменяемые файлы. При выполнении обновления существующей записи файлы, представляющие эту запись, записываются в time time travel как запись в ее предыдущем состоянии до обновления. И новая запись записывается в активные микропересекции; правильно, обновление создаст микропересекания, которые видны активным микропересекам, а существующие предназначены для путешествий во времени.
Вот почему парадигмы моделирования и архитектуры только для вставки намного эффективнее, чем те, которые позволяют обновлять. Обновления даже в традиционных СУБД являются дорогостоящими операциями, а на платформах больших данных это практически невозможно.
Да, Snowflake поддерживает обновления, но от вас зависит эффективное использование платформы, и да, это даже включает в себя то, как вы моделируете на платформе.
Комментарии:
1. Спасибо, в этом есть смысл. Я предполагаю, что мне не хватает того, почему затрагивается такой высокий процент микропересекций (и, следовательно, полностью заменяется), учитывая кластеризацию и тот факт, что обновления нацелены на небольшое подмножество ключа кластера.