Архитектура Snowflake простыми словами и для чего он нужен

Архитектура Snowflake делит платформу данных на три слоя, которые масштабируются независимо: хранение, вычисления (так называемые виртуальные warehouses) и слой облачных сервисов, который всё координирует. Компании используют Snowflake как облачное хранилище данных для отчётности и аналитики, а всё чаще и как место для обмена данными, запуска Python и построения AI на управляемых данных.

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

Я работал со Snowflake в программах по созданию платформ данных в производстве и оборонной отрасли. Картина, которую я вижу часто: руководители покупают его ради аналитики, а потом обнаруживают, что архитектурные решения (сколько warehouses, какая редакция, где лежат данные) определяют и счёт, и положение с соответствием требованиям. Этот материал для CIO, CDO или архитектора, которому нужно понять эти решения до подписания.

Snowflake представляет собой полностью управляемую платформу данных, которая работает на Amazon Web Services, Microsoft Azure и Google Cloud. Вы не устанавливаете его, не накатываете исправления и не настраиваете индексы. Вы загружаете данные, пишете SQL (или Python) и платите за хранение и вычисления раздельно.

Snowflake описывает своё устройство как гибрид архитектур shared-disk и shared-nothing: одно центральное хранилище данных, которое запрашивают независимые вычислительные кластеры. Для покупателей из оборонной отрасли один факт важен с самого начала: согласно собственному руководству Snowflake по ключевым понятиям и архитектуре, его нельзя установить на локальную инфраструктуру или инфраструктуру частного облака.

Вот стек, снизу вверх.

1. 03Облачные сервисыБезопасность, управление доступом, метаданные, оптимизация запросов и транзакции
2. 02ВычисленияВиртуальные warehouses: независимые кластеры, которые выполняют SQL и Python и расходуют кредиты, пока работают
3. 01ХранениеСжатые колоночные микропартиции в облачном объектном хранилище, оплата за терабайт

Хранение

Когда вы загружаете данные, Snowflake реорганизует их в сжатый колоночный формат и хранит в облачном объектном хранилище. Он делит каждую таблицу на микропартиции (micro-partitions), каждая из которых содержит от 50 МБ до 500 МБ несжатых данных. Для каждой из них Snowflake записывает метаданные, например диапазон значений в каждом столбце.

Самое хитрое как раз в этих метаданных. Запрос с фильтром по производственным заказам за прошлый месяц пропускает каждую микропартицию, диапазон дат которой не может совпасть.

Это называется отсечением (pruning), и именно поэтому Snowflake работает хорошо без индексов. Это также означает, что способ поступления данных (отсортированы по дате или заводу либо вперемешку) влияет на затраты для очень больших таблиц.

Вычисления: виртуальные warehouses

Виртуальный warehouse представляет собой вычислительный кластер, который выполняет запросы и код. Каждый из них независим. Финансовые отчёты на закрытии месяца могут работать на одном warehouse, пока data science выполняет тяжёлые задания на другом, и ни один не замедляет другой.

Warehouses бывают размеров, как у футболок, и расходуют кредиты только пока работают. Они могут автоматически приостанавливаться при простое. Большие размеры ускоряют отдельные тяжёлые запросы.

Больше кластеров обслуживают больше пользователей одновременно, и именно это делают multi-cluster warehouses: в редакции Enterprise и выше warehouse может автоматически добавлять кластеры, когда запросы начинают выстраиваться в очередь, и убирать их, когда нагрузка падает. Snowflake прямо говорит, что multi-cluster помогает параллельности, а не одному медленному запросу. Для этого нужно менять размер.

Моё руководство по кредитам Snowflake и тому, что определяет счёт, подробно разбирает сторону затрат.

Облачные сервисы

Верхний слой отвечает за аутентификацию, управление доступом, метаданные, оптимизацию запросов и транзакции. Time Travel и клонирование являются в основном операциями с метаданными, поэтому их делает возможными именно этот слой. Вы редко о нём думаете, и в этом весь смысл.

Интересные возможности не прикручены сбоку. Они следуют из устройства хранения и метаданных.

1. Time Travel. Вы можете запросить, клонировать или восстановить данные в том виде, в каком они были в определённый момент в прошлом. Редакция Standard хранит 1 день. Enterprise и выше могут хранить до 90 дней для постоянных таблиц, как описано в документации по Time Travel.
2. Fail-safe. После истечения Time Travel данные постоянных таблиц переходят в 7-дневный период Fail-safe. Восстановить их может только Snowflake. Считайте это аварийным восстановлением, а не резервной копией, которую контролируете вы.
3. Клонирование без копирования (zero-copy cloning). Клон таблицы, схемы или базы данных при создании не занимает дополнительного места, потому что указывает на те же микропартиции. Вы платите только за данные, которые потом изменятся. Так команды за минуты поднимают полноразмерные тестовые среды.
4. Безопасный обмен данными. Поставщик данных открывает живые таблицы другой учётной записи Snowflake, и никакие данные не копируются. Потребитель платит только за вычисления, которые использует для запросов. Прямые shares работают внутри одного региона; межрегиональный обмен идёт через листинги с автоматическим исполнением (auto-fulfilment).
5. Snowflake Marketplace. Листинги позволяют публиковать продукты данных для конкретных партнёров или публично, включая сторонние данные, например о погоде или рыночных индексах.
6. Snowpark. Библиотеки для Python, Java и Scala, которые переносят обработку внутрь Snowflake вместо того, чтобы вытаскивать данные наружу. Snowpark Container Services, который запускает контейнерные приложения рядом с данными, общедоступен во всех трёх облаках в коммерческих регионах.

Для производителя безопасный обмен данными стоит попробовать в пилоте. Будьте реалистичны насчёт отправной точки: большая часть обмена данными с поставщиками, которую я вижу, всё ещё идёт через передачу файлов.

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

Раньше Snowflake означал «ваши данные в формате Snowflake». Это изменилось, как и названия. Текущий статус, октябрь 2026 года:

Возможность	Что делает	Статус (октябрь 2026 года)
Таблицы Apache Iceberg	Данные хранятся в открытом формате Iceberg, в вашем облачном хранилище или в хранилище Snowflake	GA с июня 2024 года; вариант хранения под управлением Snowflake GA с июня 2026 года (коммерческие AWS и Azure)
Snowflake Horizon Catalog	Управление и каталог на основе Apache Polaris; внешние движки читают управляемые Snowflake таблицы Iceberg через Iceberg REST API	Рекомендуется новым клиентам
Snowflake Open Catalog	Управляемый сервис Apache Polaris (ранее Polaris Catalog)	GA, но закрыт для новых клиентов; существующие пользователи могут продолжать
Гибридные таблицы (Unistore)	Строковые таблицы для транзакционных поисков с низкой задержкой рядом с аналитикой	GA только в коммерческих регионах AWS и Azure
Snowflake Postgres	Полностью управляемый PostgreSQL внутри платформы Snowflake	GA с 24 февраля 2026 года, на AWS и Azure

Практический вывод: таблицы Iceberg позволяют Spark, Databricks или другим движкам работать с теми же файлами, которые запрашивает Snowflake, что снижает привязку к поставщику. В обзоре Open Catalog Snowflake теперь советует новым клиентам использовать вместо него Horizon Catalog.

Прочитайте ограничения гибридных таблиц, прежде чем кто-то предложит их как операционную базу данных. Каждая база данных ограничена 2 ТБ данных гибридных таблиц, и они не поддерживают Fail-safe, обмен данными, репликацию и streams. Для таблицы поиска в приложении они подходят.

Операционной базой данных они не являются. Если приложению она нужна рядом с аналитикой, Snowflake Postgres стал общедоступным в феврале 2026 года и подходит честнее.

Snowflake продаёт четыре редакции: Standard, Enterprise, Business Critical и Virtual Private Snowflake (VPS). Редакция определяет, какие функции безопасности вы получаете, и цена кредита растёт вместе с ней.

Функция	Standard	Enterprise	Business Critical	VPS
Time Travel	1 день	До 90 дней	До 90 дней	До 90 дней
Multi-cluster warehouses	Нет	Да	Да	Да
Tri-Secret Secure (ключ, управляемый клиентом)	Нет	Нет	Да	Да
Частное подключение (AWS PrivateLink, Azure Private Link, Google Private Service Connect)	Нет	Нет	Да	Да
Поддержка HIPAA и PCI DSS	Нет	Нет	Да	Да
Выделенная среда, без общего оборудования	Нет	Нет	Нет	Да

Tri-Secret Secure объединяет ключ Snowflake с ключом, который вы держите в сервисе управления ключами вашего облачного провайдера. Отзовите свой ключ, и Snowflake больше не сможет расшифровать ваши данные. Для поставщиков оборонной и аэрокосмической отрасли этот контроль важнее любой аналитической функции.

Для работы с правительством США Snowflake предоставляет регионы SnowGov на AWS GovCloud и Azure Government, открытые для государственных клиентов и подрядчиков США. На странице поддерживаемых регионов Snowflake для этих регионов указаны FedRAMP High, Impact Level 4 и поддержка ITAR, Impact Level 5 в одном регионе AWS, и требуется редакция Business Critical или выше. Проверяйте доступность функций регион за регионом: Open Catalog, гибридные таблицы и части Snowpark Container Services доступны не во всех государственных регионах.

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

Для данных, которые должны оставаться в вашем собственном здании, он ответить не может. Секретным нагрузкам или нагрузкам под экспортным контролем, требующим обработки on-premises, нужна другая платформа, а Snowflake берёт на себя несекретную часть.

Большая часть того, что я вижу, укладывается в несколько схем.

1. Корпоративная отчётность и BI. Финансовая, торговая и операционная отчётность по данным ERP (SAP, Oracle или Microsoft Dynamics 365) с Power BI, Tableau или аналогами сверху. Это по-прежнему основное применение. Моё руководство о том, как загрузить данные ERP в Snowflake, разбирает варианты извлечения.
2. Данные производственных операций. Данные заводов и операций, которые я видел загруженными в Snowflake, это данные производственного планирования. Данные историков, MES, качества и обслуживания могут лежать рядом, а полуструктурированные данные датчиков в JSON загружаются нативно.
3. Обмен данными с партнёрами. Поставщики, дистрибьюторы и клиенты могут напрямую запрашивать управляемые таблицы. На практике большая часть обмена с поставщиками, которую я вижу, всё ещё идёт через передачу файлов.
4. Data science и AI на управляемых данных. Python через Snowpark и AI-сервисы Snowflake, о которых я пишу в материале о Snowflake Cortex AI и Snowflake Intelligence.
5. Консолидация после поглощений. Несколько ERP, один слой отчётности и клонирование для безопасных тестовых сред.

Где я бы засомневался:

1. Высоконагруженные транзакционные системы. Гибридные таблицы и Snowflake Postgres помогают, но транзакциям ваших ERP и MES место в их собственных базах данных.
2. Управление оборудованием в реальном времени. Snowflake подходит для минут, а не миллисекунд. Потоковая загрузка данных датчиков в порядке. Замыкание контура управления нет.
3. Строгие требования к on-premises. Варианта установки on-premises не существует.
4. Тяжёлое собственное машинное обучение и инженерия данных на Spark. Это можно сделать, но многим командам естественнее работать в Databricks. Моё сравнение Snowflake и Databricks разбирает этот выбор.

Схема «снежинка» и схема «звезда»: это другое

Люди, которые ищут Snowflake, часто попадают на «snowflake schema», схему «снежинка». Она не имеет никакого отношения к продукту. Схема «снежинка» является шаблоном моделирования данных, в котором таблицы измерений нормализованы в подтаблицы, так что диаграмма ветвится, как снежинка.

Схема «звезда» держит каждое измерение в одной плоской таблице. Любую из этих моделей можно построить в Snowflake или в любом другом хранилище. Большинство команд BI предпочитает схемы «звезда» ради более простых запросов.

Прежде чем подписывать, запишите четыре решения: какая редакция вам нужна с учётом требований соответствия, какое облако и регион, как вы распределите нагрузки по warehouses и останутся ли ваши данные в формате Snowflake или в Iceberg. Попросите поставщика и вашего системного интегратора показать оценку кредитов по каждому warehouse, а не одну годовую цифру. Большинство неожиданностей в затратах на Snowflake являются архитектурными решениями, которые никто не записал.

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

Для чего используется Snowflake?

В основном как облачное хранилище данных для отчётности и аналитики по бизнес-данным, таким как данные ERP, CRM и операционные данные. Компании также используют его для обмена живыми данными с партнёрами, для data science на Python через Snowpark и для создания AI-приложений на управляемых данных.

Какие три слоя у архитектуры Snowflake?

Хранение, вычисления и облачные сервисы. Хранение держит данные в сжатых колоночных микропартициях. Вычисления состоят из виртуальных warehouses, которые выполняют запросы. Облачные сервисы отвечают за безопасность, метаданные, оптимизацию запросов и транзакции. Хранение и вычисления масштабируются и оплачиваются раздельно.

Snowflake это база данных или хранилище данных?

И то и другое, в зависимости от определения. Это SQL-база данных, созданная для аналитических нагрузок, поэтому её обычно называют облачным хранилищем данных. С таблицами Iceberg, гибридными таблицами и Snowflake Postgres она теперь в определённых пределах покрывает и сценарии lakehouse, и некоторые транзакционные сценарии.

Можно ли развернуть Snowflake on-premises?

Нет. Snowflake работает только на AWS, Microsoft Azure и Google Cloud. Для нагрузок правительства США и оборонной отрасли он предлагает регионы SnowGov на AWS GovCloud и Azure Government, которые требуют редакции Business Critical или выше.

Связана ли схема «снежинка» с компанией Snowflake?

Нет. Схема «снежинка» является шаблоном моделирования данных с нормализованными таблицами измерений. Она появилась раньше компании и работает в любом хранилище.

Какая редакция Snowflake нужна регулируемым компаниям?

Обычно Business Critical. Она добавляет Tri-Secret Secure с ключом, управляемым клиентом, частное подключение и поддержку HIPAA и PCI DSS и является минимальной для государственных регионов. Virtual Private Snowflake добавляет выделенную среду без общего оборудования.