Comments 9
Спасибо, очень полезные заметки!
Спасибо! Насчет пересоздания view: в мире SQL Server считается плохой практикой писать SELECT * во вьюшках, как раз из-за необходимости их пересоздавать. Может быть, и в Snowflake надо указывать конкретные колонки в SELECT вместо *?
SELECT * - это скорее самый доступный пример того, что может сломать VIEW. Действительно, лучше избегать этой конструкции, независимо от СУБД.
На практике чаще видим ситуации, когда есть цепочка из нескольких VIEW, и ломается что-то посередине. Например, переименовали таблицу / колонку / функцию, поменяли тип данных.
Да, точно, сломать вьюшки можно по-разному. У RedGate в SQL Prompt есть Find Invalid Objects - так можно найти сломанные view, sp, функции и т. д.
А в Snowflake можно посмотреть цепочку зависимостей?
Давно работаете со Snowflake? Пишите ещё.
Любопытно, но поле "invalid" можно увидеть у команды SHOW MATERIALIZED VIEWS, но не у обычной SHOW VIEWS. Судя по всему, в текущей модели Snowflake сам точно не знает, какие стандартные VIEW стали невалидны до первого запроса к ним. Надеюсь, со временем это исправят.
Цепочку зависимостей посмотреть можно, но дьявол в деталях:
Табличная функция GET_OBJECT_REFERENCES(), показывает не всё, требует активный WAREHOUSE и тратит деньги.
View OBJECT_DEPENDENCIES, обновляется с задержкой до 3ч (!), тратит деньги.
После перебора всех вариантов получается, что проверка всех VIEW через .describe() - самое простое и дешёвое решение на текущий момент.
Со Snowflake работаю недавно, но очень много опыта с другими DWH на больших объёмах. Уже знаю, на что смотреть, и почему не стоит слепо доверять документации и советам вендора. :)
А как же допустимость дубликатов ID при объявлении PRIMARY KEY? Когда я только начал работать со снежинкой, для меня это было неприятным открытием.
https://docs.snowflake.com/en/sql-reference/constraints-overview.html
Snowflake supports defining and maintaining constraints, but does not enforce them, except for NOT NULL constraints, which are always enforced.
Это достаточно частая история для OLAP DWH. Из-за того, как они устроены внутри, проверка PRIMARY KEY обычно потребует обход всех блоков или микро-партиций. Скорость импорта упадет в несколько раз. Есть разные хитрые решения, вроде ReplacingMergeTree в ClickHouse, но это скорее исключение.
А главное, предположим, что нашли дубль при вставке новых данных. Какие наши действия? Упасть с ошибкой и лежать? Удалить старый ряд в таблице? Почистить входящие данные?
Всё это можно сделать через MERGE со вложенным COPY INTO, и тонко настроить его под конкретный use case. Отсутствие constraints enforcement - это немного неудобно после работы с OLTP DWH, но не критично.
Любопытные и неочевидные особенности при работе со Snowflake