Хэштеги для быстрого поиска по разделам:

#дайджест

#clickhouse
#data_governance
#databasedesign
#dwh
#etl
#greenplum
#null
#snowflake
#soft_skills
#sql
#документация
#оконные_функции
#проектирование
#системный_анализ

Коротко о Snowflake

— Облачное хранилище данных и аналитическая платформа
— Трёхслойная архитектура: хранение, вычисление и сервисы
— Масштабируемость и производительность
— Лёгкая управляемость
— Высокая доступность и отказоустойчивость
— Автоматическая организация и сжатие данных
— Экономическая эффективность
— Колоночное хранение
— Snowflake SQL соответствует ANSI SQL и в целом очень похож на PostgreSQL

#snowflake

Краткий обзор архитектуры Snowflake для начинающих

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

Архитектура Snowflake представляет собой гибрид традиционных баз данных с shared-nothing архитектурой.

Три независимых уровня:
1. Общий уровень хранения — служит основой, где хранятся данные. Автоматически организует и уменьшает размер данных для быстрого доступа и анализа.

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

3. Слой облачных сервисов — управляет важными службами, такими как оптимизация запросов, безопасность и метаданные, обеспечивая согласованную и безопасную среду данных. Этот уровень предназначен для быстрого, безопасного и надежного взаимодействия с пользователем.

Эта архитектура обеспечивает оптимальное использование ресурсов, хранение и обработку данных. При этом компоненты архитектуры работают без взаимной зависимости.

Преимущества архитектуры:
— производительность
— улучшенная масштабируемость
— оптимизация затрат

Архитектура Snowflake создана для эффективной и удобной обработки данных. Это делает Snowflake многофункциональным решением для сложных запросов в области аналитики данных.

#snowflake

Snowflake pricing: стоимость хранения и обработки данных

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

Snowflake не требует покупки или аренды физического оборудования. Это облачное решение, где вы платите за потребляемые ресурсы — модель pay-as-you-go. Это одно из его основных преимуществ, которое легко может превратиться в недостаток, если использовать хранилище как попало. Наша задача не просто загружать и обновлять данные, строить витрины, но и делать это максимально экономно. Про особенности оплаты хорошо описано в доках, но всё-таки подчеркну здесь основные моменты.

Snowflake берет плату за хранение данных в зависимости от региона и облачного провайдера (AWS, Azure или GCP). Оплата идет за терабайт в месяц и бывает двух типов:
• On-demand storage — платим только за фактический объем данных.
• Capacity storage — предоплата за объем на год вперёд с возможной экономией до 30%. Однако неиспользованный объем никак не компенсируется.
При этом стоит упомянуть, что в любом из вариантов загружаемые данные автоматически сжимаются, что снижает оплачиваемый объем.

Теперь про обработку данных и тут начинается самое интересное. Вычислительные мощности Snowflake — это виртуальные склады (warehouses). Они обрабатывают запросы и выполняют преобразования данных. Оплата идет в кредитах, и вот как это работает:
• Snowflake предлагает разные размеры warehouses. Чем он больше, тем выше его вычислительная мощность и тем больше кредитов он потребляет в час.
• При этом мы платим только за время, когда warehouse активен. Если он простаивает несколько минут, то автоматически приостанавливается.
• Стоимость кредита зависит от выбранного плана и облачного провайдера.

С передачей данных все просто: внутри одного региона она бесплатна. Но есть нюансы:
• межрегиональная передача между дата-центрами облачных провайдеров оплачивается отдельно и стоит несколько центов за гигабайт;
• выгрузка данных во внешние системы — доп.плата;
• межоблачная передача (например, между AWS и GCP) также оплачивается.

Как оптимизировать расходы?
1. Настроить быстрое «засыпание» warehouses после выполнения пачки задач.
2. Группировать выполнение системных задач.
3. Разделить warehouses для тех. процессов и задач аналитики, правильно подобрав размер под каждый тип задач. Большой warehouse работает быстрее, но и стоит дороже.
4. Использовать автоматическое масштабирование там, где это необходимо — Snowflake может автоматически увеличивать и уменьшать размер warehouse в зависимости от нагрузки.
5. Оптимизировать запросы, ведь неэффективные запросы — прямой путь к лишним расходам.
6. Использовать кэширование результатов — Snowflake кэширует результаты запросов, т.е. если запрос повторяется, результат берется из кэша, что экономит ресурсы.
7. Ну и, конечно, мониторить использование. Snowflake предоставляет подробные отчеты, и хорошо бы регулярно проверять их, чтобы понимать, где можно оптимизировать затраты.

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

#snowflake

Обожаю Snowflake за множество классных функций, делающих sql-код более читабельным. При этом специально "переучиваться" для работы в снежке не нужно, так как он поддерживает всем знакомый (ну я надеюсь) стандарт ANSI SQL. Просто каждый раз в работе (или листая документацию) ты находишь прикольные фишки, которые хочется использовать.

Например, как бы вы посчитали, сколько задач разработчиков завершено до дедлайна, а сколько — нет? Обычно пришлось бы писать что-то вроде:

SELECT 
    developer,
    SUM(CASE WHEN completion_date <= deadline THEN 1 ELSE 0 END) AS on_time_tasks,
    SUM(CASE WHEN completion_date > deadline THEN 1 ELSE 0 END) AS late_tasks
FROM tasks
GROUP BY developer;

В Snowflake этот подсчёт выглядит куда лаконичнее:

SELECT 
    developer,
    COUNT_IF(completion_date <= deadline) AS on_time_tasks,
    COUNT_IF(completion_date > deadline) AS late_tasks
FROM tasks
GROUP BY developer;

Кажется, что это незначительная мелочь? Но насколько приятнее и понятнее становится разбирать тысячи строк какого-нибудь сложного аналитического запроса. Краткость — сила!

#snowflake #sql