Перейти к основному содержанию
В этом документе приводится краткое введение в миграцию данных из Snowflake в ClickHouse.
Snowflake — это облачное хранилище данных, в первую очередь ориентированное на перенос устаревших рабочих нагрузок хранилищ данных из собственной инфраструктуры в облако. Оно хорошо оптимизировано для выполнения длительных отчетных запросов в крупном масштабе. По мере переноса наборов данных в облако владельцы данных начинают задумываться, как еще можно извлечь из них пользу, в том числе использовать эти наборы данных для приложений, работающих в реальном времени, во внутренних и внешних сценариях. Когда это происходит, они часто понимают, что им нужна база данных, оптимизированная для Real-time аналитики, такая как ClickHouse.

​
Сравнение

В этом разделе мы сравним основные возможности ClickHouse и Snowflake.

​
Сходства

Snowflake — это облачная платформа хранилища данных, которая предоставляет масштабируемое и эффективное решение для хранения, обработки и анализа больших объемов данных. Как и ClickHouse, Snowflake не построена на существующих технологиях, а использует собственный движок SQL-запросов и специализированную архитектуру. Архитектуру Snowflake описывают как гибрид архитектуры с общим хранилищем (shared-disk) и архитектуры shared-nothing. Архитектура с общим хранилищем — это архитектура, в которой данные доступны всем вычислительным узлам через объектные хранилища, такие как S3. Архитектура shared-nothing — это архитектура, в которой каждый вычислительный узел хранит локально часть общего набора данных для выполнения запросов. Это, в теории, дает лучшее от обеих моделей: простоту архитектуры shared-disk и масштабируемость архитектуры shared-nothing. В основе этой архитектуры лежит Объектное хранилище как основная среда хранения, которое масштабируется почти бесконечно при одновременном доступе, обеспечивая при этом высокую отказоустойчивость и масштабируемую пропускную способность. Изображение ниже с docs.snowflake.com показывает эту архитектуру: В отличие от Snowflake, ClickHouse как продукт с открытым исходным кодом и облачным размещением можно развернуть как в архитектуре shared-disk, так и в архитектуре shared-nothing. Последняя типична для самоуправляемых развертываний. Хотя такой подход позволяет легко масштабировать CPU и память, конфигурации shared-nothing создают классические проблемы управления данными и дополнительные издержки на репликацию данных, особенно при изменении состава узлов. По этой причине ClickHouse Cloud использует архитектуру с общим хранилищем, которая концептуально похожа на Snowflake. Данные хранятся в Объектном хранилище (в единственном экземпляре), таком как S3 или GCS, что обеспечивает практически неограниченный объем хранения и высокую отказоустойчивость. Каждый узел имеет доступ к этой единственной копии данных, а также к собственным локальным SSD, используемым в качестве кэша. Узлы, в свою очередь, можно масштабировать, чтобы при необходимости добавлять ресурсы CPU и памяти. Как и в Snowflake, свойства масштабируемости S3 устраняют классическое ограничение архитектур shared-disk (узкие места дискового ввода-вывода и сети), гарантируя, что пропускная способность ввода-вывода, доступная текущим узлам в cluster, не снижается при добавлении новых узлов.

​
Различия

Помимо форматов нижележащего хранилища и движков выполнения запросов, эти архитектуры различаются ещё несколькими неочевидными деталями:
  • Вычислительные ресурсы в Snowflake предоставляются через концепцию хранилищ. Они состоят из некоторого числа узлов фиксированного размера. Хотя Snowflake не публикует точную архитектуру своих хранилищ, обычно считается, что каждый узел включает 8 vCPU, 16 GiB и 200 GB локального хранилища (для кэша). Число узлов зависит от условного размера: например, x-small имеет один узел, small — 2, medium — 4, large — 8 и т. д. Эти хранилища не привязаны к данным и могут использоваться для выполнения запросов к любой базе данных, размещённой в Объектном хранилище. Когда хранилище простаивает и не получает запросной нагрузки, оно приостанавливается и возобновляет работу при поступлении запроса. Хотя расходы на хранение всегда учитываются в тарификации, за хранилища взимается плата только во время их активности.
  • ClickHouse Cloud использует похожий подход с узлами и локальным кэшем. Вместо условных размеров пользователи развёртывают сервис с общим объёмом вычислительных ресурсов и доступной оперативной памяти. Затем он прозрачно автоматически масштабируется (в заданных пределах) в зависимости от нагрузки запросов — либо вертикально, увеличивая (или уменьшая) ресурсы каждого узла, либо горизонтально, увеличивая или уменьшая общее число узлов. Узлы ClickHouse Cloud имеют соотношение CPU к памяти 1:1, в отличие от Snowflake. Хотя возможна и более слабая связность, сервисы привязаны к данным, в отличие от хранилищ Snowflake. Узлы также приостанавливаются в состоянии простоя и возобновляют работу при поступлении запросов. При необходимости вы также можете вручную изменять размер сервисов.
  • Кэш запросов в ClickHouse Cloud привязан к конкретному узлу, в отличие от Snowflake, где он реализован на уровне сервиса независимо от хранилища. Согласно бенчмаркам, кэш узлов ClickHouse Cloud превосходит кэш Snowflake.
  • Snowflake и ClickHouse Cloud по-разному подходят к масштабированию для увеличения параллелизма запросов. Snowflake решает эту задачу с помощью возможности, известной как multi-cluster warehouses. Эта возможность позволяет добавлять кластеры в хранилище. Хотя это не даёт снижения задержки выполнения запросов, это обеспечивает дополнительный параллелизм и позволяет увеличить число одновременно выполняемых запросов. ClickHouse достигает этого, добавляя сервису больше памяти и CPU за счёт вертикального или горизонтального масштабирования. В этом блоге мы не рассматриваем возможности этих сервисов по масштабированию до более высокого параллелизма, а сосредотачиваемся вместо этого на задержке, но признаём, что такую работу следует выполнить для полноценного сравнения. Тем не менее, мы ожидаем, что ClickHouse покажет себя хорошо в любом тесте на параллелизм, тогда как Snowflake явно ограничивает число одновременных запросов, разрешённых для хранилища по умолчанию до 8. Для сравнения, ClickHouse Cloud позволяет выполнять до 1000 запросов на узел.
  • Возможность Snowflake менять объём вычислительных ресурсов для набора данных в сочетании с быстрым возобновлением работы хранилищ делает её отличным решением для ad hoc запросов. Для сценариев хранилищ данных и озёр данных это даёт преимущество перед другими системами.

​
Real-time аналитика

Согласно общедоступным данным бенчмарка, ClickHouse превосходит Snowflake в сценариях Real-time аналитики в следующих аспектах:
  • Задержка запросов: У Snowflake задержка запросов выше даже при использовании кластеризации таблиц для оптимизации производительности. В наших тестах Snowflake требуется более чем вдвое больше вычислительных ресурсов, чтобы достичь производительности, сопоставимой с ClickHouse, на запросах, где применяется фильтр, входящий в ключ кластеризации Snowflake или primary key ClickHouse. Хотя persistent кэш запросов Snowflake частично компенсирует эти проблемы с задержкой, он неэффективен в случаях, когда критерии фильтра более разнообразны. Эффективность этого кэша запросов также может дополнительно снижаться из-за изменений в исходных данных, поскольку записи кэша инвалидируются при изменении таблицы. Хотя в бенчмарке для нашего приложения это не так, в реальном развертывании потребовалась бы вставка новых, более свежих данных. Обратите внимание, что кэш запросов ClickHouse привязан к конкретному узлу и не является транзакционно согласованным, что лучше подходит для Real-time аналитики. Пользователи также получают детальный контроль над его использованием: можно управлять им для каждого запроса отдельно, задавать его точный размер, определять, кэшируется ли запрос (с ограничениями по длительности или минимальному числу выполнений), а также указывать, должен ли он использоваться только пассивно.
  • Более низкая стоимость: Хранилища Snowflake можно настроить на приостановку после периода отсутствия активности запросов. После приостановки плата не взимается. На практике этот порог неактивности можно снизить только до 60 с. Хранилища автоматически возобновляют работу в течение нескольких секунд после получения запроса. Поскольку Snowflake взимает плату за ресурсы только тогда, когда хранилище используется, такое поведение подходит для рабочих нагрузок, которые часто простаивают, например для ad-hoc запросов. Однако многие рабочие нагрузки Real-time аналитики требуют непрерывной ингестии данных в реальном времени и частого выполнения запросов, для которых режим простоя не дает преимуществ (например, клиентские панели мониторинга). Это означает, что хранилища часто должны оставаться полностью активными, а значит, за них будет начисляться плата. Это сводит на нет экономическую выгоду режима простоя, а также любое преимущество в производительности, которое может быть связано со способностью Snowflake быстрее альтернатив возвращаться в рабочее состояние. Это требование постоянного активного состояния в сочетании с более низкой посекундной стоимостью активного состояния в ClickHouse Cloud приводит к тому, что ClickHouse Cloud обеспечивает значительно более низкую совокупную стоимость для таких видов рабочих нагрузок.
  • Предсказуемая стоимость возможностей: Такие возможности, как materialized view и кластеризация (эквивалент ORDER BY в ClickHouse), необходимы для достижения максимального уровня производительности в сценариях использования Real-time аналитики. Эти возможности в Snowflake требуют дополнительных расходов, поскольку нужен не только более высокий уровень, что увеличивает стоимость за кредит в 1,5 раза, но и непредсказуемые фоновые затраты. Например, materialized view влечет за собой фоновые расходы на обслуживание, как и кластеризация, и их трудно предсказать до начала использования. В отличие от этого, в ClickHouse Cloud эти возможности не требуют дополнительных затрат, кроме дополнительного использования CPU и памяти во время вставки, что обычно пренебрежимо мало вне сценариев с высокой нагрузкой на вставку. В нашем бенчмарке мы наблюдали, что эти различия наряду с меньшей задержкой запросов и более высоким сжатием приводят к значительно более низкой стоимости при использовании ClickHouse.
Последнее изменение 10 июня 2026 г.