> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-fix-nav-issues.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > Миграция из Snowflake в ClickHouse # Миграция из Snowflake в ClickHouse export const Image = ({img, alt, size}) => { return {alt} ; }; > В этом документе приводится краткое введение в миграцию данных из 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](https://docs.snowflake.com/en/user-guide/intro-key-concepts) показывает эту архитектуру: Архитектура Snowflake В отличие от Snowflake, ClickHouse как продукт с открытым исходным кодом и облачным размещением можно развернуть как в архитектуре shared-disk, так и в архитектуре shared-nothing. Последняя типична для самоуправляемых развертываний. Хотя такой подход позволяет легко масштабировать CPU и память, конфигурации shared-nothing создают классические проблемы управления данными и дополнительные издержки на репликацию данных, особенно при изменении состава узлов. По этой причине ClickHouse Cloud использует архитектуру с общим хранилищем, которая концептуально похожа на Snowflake. Данные хранятся в Объектном хранилище (в единственном экземпляре), таком как S3 или GCS, что обеспечивает практически неограниченный объем хранения и высокую отказоустойчивость. Каждый узел имеет доступ к этой единственной копии данных, а также к собственным локальным SSD, используемым в качестве кэша. Узлы, в свою очередь, можно масштабировать, чтобы при необходимости добавлять ресурсы CPU и памяти. Как и в Snowflake, свойства масштабируемости S3 устраняют классическое ограничение архитектур shared-disk (узкие места дискового ввода-вывода и сети), гарантируя, что пропускная способность ввода-вывода, доступная текущим узлам в cluster, не снижается при добавлении новых узлов. Архитектура ClickHouse Cloud
### Различия
Помимо форматов нижележащего хранилища и движков выполнения запросов, эти архитектуры различаются ещё несколькими неочевидными деталями: * Вычислительные ресурсы в Snowflake предоставляются через концепцию [хранилищ](https://docs.snowflake.com/en/user-guide/warehouses). Они состоят из некоторого числа узлов фиксированного размера. Хотя Snowflake не публикует точную архитектуру своих хранилищ, обычно [считается](https://select.dev/posts/snowflake-warehouse-sizing), что каждый узел включает 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](https://docs.snowflake.com/en/user-guide/warehouses-multicluster#benefits-of-multi-cluster-warehouses). Эта возможность позволяет добавлять кластеры в хранилище. Хотя это не даёт снижения задержки выполнения запросов, это обеспечивает дополнительный параллелизм и позволяет увеличить число одновременно выполняемых запросов. ClickHouse достигает этого, добавляя сервису больше памяти и CPU за счёт вертикального или горизонтального масштабирования. В этом блоге мы не рассматриваем возможности этих сервисов по масштабированию до более высокого параллелизма, а сосредотачиваемся вместо этого на задержке, но признаём, что такую работу следует выполнить для полноценного сравнения. Тем не менее, мы ожидаем, что ClickHouse покажет себя хорошо в любом тесте на параллелизм, тогда как Snowflake явно ограничивает число одновременных запросов, разрешённых для [хранилища по умолчанию до 8](https://docs.snowflake.com/en/sql-reference/parameters#max-concurrency-level). Для сравнения, ClickHouse Cloud позволяет выполнять до 1000 запросов на узел. * Возможность Snowflake менять объём вычислительных ресурсов для набора данных в сочетании с быстрым возобновлением работы хранилищ делает её отличным решением для ad hoc запросов. Для сценариев хранилищ данных и озёр данных это даёт преимущество перед другими системами.
### Real-time аналитика
Согласно общедоступным данным [бенчмарка](https://benchmark.clickhouse.com/#system=+%E2%98%81w|%EF%B8%8Fr|C%20c|nfe\&type=-\&machine=-ca2|gl|6ax|6ale|3al\&cluster_size=-\&opensource=-\&tuned=+n\&metric=hot\&queries=-), ClickHouse превосходит Snowflake в сценариях Real-time аналитики в следующих аспектах: * **Задержка запросов**: У Snowflake задержка запросов выше даже при использовании кластеризации таблиц для оптимизации производительности. В наших тестах Snowflake требуется более чем вдвое больше вычислительных ресурсов, чтобы достичь производительности, сопоставимой с ClickHouse, на запросах, где применяется фильтр, входящий в ключ кластеризации Snowflake или primary key ClickHouse. Хотя [persistent кэш запросов](https://docs.snowflake.com/en/user-guide/querying-persisted-results) Snowflake частично компенсирует эти проблемы с задержкой, он неэффективен в случаях, когда критерии фильтра более разнообразны. Эффективность этого кэша запросов также может дополнительно снижаться из-за изменений в исходных данных, поскольку записи кэша инвалидируются при изменении таблицы. Хотя в бенчмарке для нашего приложения это не так, в реальном развертывании потребовалась бы вставка новых, более свежих данных. Обратите внимание, что кэш запросов ClickHouse привязан к конкретному узлу и не является [транзакционно согласованным](https://clickhouse.com/blog/introduction-to-the-clickhouse-query-cache-and-design), что [лучше подходит ](https://clickhouse.com/blog/introduction-to-the-clickhouse-query-cache-and-design) для Real-time аналитики. Пользователи также получают детальный контроль над его использованием: можно управлять им [для каждого запроса отдельно](/ru/reference/settings/session-settings#use_query_cache), задавать его [точный размер](/ru/reference/settings/session-settings#query_cache_max_size_in_bytes), определять, [кэшируется ли запрос](/ru/reference/settings/session-settings#enable_writes_to_query_cache) (с ограничениями по длительности или минимальному числу выполнений), а также указывать, должен ли он использоваться только [пассивно](https://clickhouse.com/blog/introduction-to-the-clickhouse-query-cache-and-design#using-logs-and-settings). * **Более низкая стоимость**: Хранилища Snowflake можно настроить на приостановку после периода отсутствия активности запросов. После приостановки плата не взимается. На практике этот порог неактивности [можно снизить только до 60 с](https://docs.snowflake.com/en/sql-reference/sql/alter-warehouse). Хранилища автоматически возобновляют работу в течение нескольких секунд после получения запроса. Поскольку 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.