Миграция с Snowflake на ClickHouse

Этот документ содержит введение в миграцию данных из Snowflake в ClickHouse.

Snowflake — это облачное хранилище данных, основное назначение которого — перенос легаси-нагрузок локальных (on‑premise) хранилищ данных в облако. Оно хорошо оптимизировано для выполнения долгих отчётных запросов в масштабах крупных нагрузок. По мере того как наборы данных мигрируют в облако, владельцы данных начинают задумываться о том, как ещё можно извлечь из них ценность, в том числе использовать эти датасеты для построения приложений реального времени для внутренних и внешних сценариев. В этот момент они часто понимают, что им нужна база данных, оптимизированная для аналитики в реальном времени, такая как ClickHouse.

Сравнение

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

Сходства

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

Архитектура Snowflake описывается как гибрид между архитектурой с общим хранилищем (shared-disk) и архитектурой shared-nothing. Архитектура с общим хранилищем — это подход, при котором данные доступны со всех вычислительных узлов с использованием объектных хранилищ, таких как S3. Архитектура shared-nothing — это подход, при котором каждый вычислительный узел хранит локально часть всего набора данных для обработки запросов. Теоретически это дает лучшее из обоих миров: простоту архитектуры shared-disk и масштабируемость архитектуры shared-nothing.

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

Изображение ниже с сайта docs.snowflake.com показывает эту архитектуру:

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

По этой причине ClickHouse Cloud использует архитектуру с общим хранилищем, концептуально схожую со Snowflake. Данные хранятся один раз в объектном хранилище (единственная копия), таком как S3 или GCS, что обеспечивает практически неограниченный объем хранения с высокими гарантиями надежности. Каждый узел имеет доступ к этой единственной копии данных, а также к собственным локальным SSD для целей кэширования. Узлы, в свою очередь, могут масштабироваться для предоставления дополнительных ресурсов CPU и памяти по мере необходимости. Как и в случае со Snowflake, свойства масштабируемости S3 устраняют классическое ограничение архитектур shared-disk (узкие места по дисковому I/O и сети), обеспечивая, что доступная текущим узлам в кластере пропускная способность I/O не ухудшается по мере добавления новых узлов.

Отличия

Помимо различий в используемых форматах хранения и движках запросов, эти архитектуры отличаются ещё и несколькими менее очевидными аспектами:

• Вычислительные ресурсы в Snowflake предоставляются через концепцию warehouses (хранилищ). Они состоят из определённого количества узлов фиксированного размера. Хотя Snowflake не публикует подробную архитектуру своих warehouses, общепринято считается, что каждый узел включает 8 vCPU, 16 GiB и 200 GB локального хранилища (для кэша). Количество узлов определяется по типу размера (t-shirt size), например, x-small содержит один узел, small — 2, medium — 4, large — 8 и т.д. Эти warehouses независимы от данных и могут использоваться для выполнения запросов к любой базе данных, расположенной в объектном хранилище. При отсутствии активности и нагрузки запросов warehouses приостанавливаются и возобновляются при поступлении запроса. При этом стоимость хранения всегда учитывается в биллинге, а warehouses тарифицируются только в активном состоянии.

• ClickHouse Cloud использует похожий принцип узлов с локальным кэширующим хранилищем. Вместо t-shirt размеров пользователи разворачивают сервис с заданным общим объёмом вычислительных ресурсов и доступной RAM. Далее он прозрачно автоматически масштабируется (в заданных пределах) в зависимости от нагрузки запросов — вертикально, увеличивая (или уменьшая) ресурсы на узел, или горизонтально, изменяя общее количество узлов. Узлы ClickHouse Cloud имеют фиксированное соотношение CPU к памяти, отличающееся от Snowflake. Хотя более слабое разделение сервисов и данных возможно, на практике сервисы привязаны к данным, в отличие от warehouses в Snowflake. Узлы также могут приостанавливаться при простое и возобновлять работу при появлении запросов. Пользователи при необходимости могут вручную изменять размер сервисов.

• Кэш запросов ClickHouse Cloud привязан к конкретному узлу, в отличие от Snowflake, где он реализован на уровне сервиса и не зависит от конкретного warehouse. По результатам бенчмарков кэш узла в ClickHouse Cloud превосходит кэш Snowflake.

• Snowflake и ClickHouse Cloud по-разному подходят к масштабированию для увеличения числа одновременно выполняемых запросов. Snowflake решает эту задачу с помощью функции, известной как multi-cluster warehouses. Эта возможность позволяет пользователям добавлять кластеры к warehouse. Хотя это не снижает задержку выполнения отдельных запросов, она обеспечивает дополнительную параллелизацию и позволяет обрабатывать больше одновременных запросов. ClickHouse достигает этого, добавляя больше памяти и CPU для сервиса через вертикальное или горизонтальное масштабирование. В этой статье мы не исследуем возможности этих сервисов по масштабированию до высокой степени одновременного выполнения запросов, сосредотачиваясь вместо этого на задержке, но признаём, что такое исследование необходимо для полноценного сравнения. Тем не менее, мы ожидаем, что ClickHouse покажет хорошие результаты в любых тестах на конкуренцию запросов, учитывая, что Snowflake явно ограничивает число одновременных запросов для warehouse по умолчанию до 8. Для сравнения, ClickHouse Cloud позволяет выполнять до 1000 запросов на узел.

• Способность Snowflake изменять размер вычислительных ресурсов для набора данных в сочетании с быстрым возобновлением работы warehouses делает его отличным решением для ad hoc запросов. Для сценариев использования в качестве data warehouse и data lake это даёт преимущество по сравнению с другими системами.

Аналитика в реальном времени

Согласно общедоступным данным бенчмарка, ClickHouse превосходит Snowflake в задачах аналитики в реальном времени по следующим направлениям:

• Задержка запросов: запросы в Snowflake имеют более высокую задержку даже тогда, когда к таблицам применяется кластеризация для оптимизации производительности. В наших тестах Snowflake требует более чем вдвое больше вычислительных ресурсов, чтобы достичь сопоставимой производительности с ClickHouse на запросах, где применяется фильтр, являющийся частью ключа кластеризации Snowflake или первичного ключа ClickHouse. Хотя персистентный кэш запросов Snowflake компенсирует часть этих проблем с задержкой, он малоэффективен в случаях, когда критерии фильтрации более разнообразны. Эффективность этого кэша запросов может дополнительно снижаться из‑за изменений в исходных данных, поскольку записи кэша инвалидируются при изменении таблицы. Хотя в бенчмарке для нашего приложения этого не происходит, в реальном развёртывании потребуется вставлять новые, более актуальные данные. Обратите внимание, что кэш запросов ClickHouse является специфичным для узла и не является транзакционно согласованным, что делает его лучше подходящим для аналитики в реальном времени. Пользователи также имеют тонкий контроль над его использованием: можно управлять его применением для каждого запроса, его точным размером, тем, кэшируется ли запрос (ограничения по длительности или требуемому числу выполнений), а также тем, используется ли он только пассивно.

• Более низкая стоимость: кластеры Snowflake (warehouses) можно сконфигурировать так, чтобы они приостанавливались после периода неактивности запросов. После приостановки плата не взимается. На практике этот интервал неактивности можно понизить только до 60 с. Кластеры автоматически возобновляют работу в течение нескольких секунд после получения запроса. Поскольку Snowflake взимает плату за ресурсы только тогда, когда кластер используется, такое поведение хорошо подходит для нагрузок, которые часто простаивают, например для ad-hoc‑запросов.

  Однако многие рабочие нагрузки аналитики в реальном времени требуют непрерывной ингестии данных в реальном времени и частых запросов, которые не получают выгоды от простоя (например, клиентские дашборды). Это означает, что кластеры часто должны оставаться полностью активными и порождать расходы. Это сводит на нет как выгоду по стоимости от простоя, так и любое преимущество в производительности, которое может быть связано со способностью Snowflake быстрее, чем альтернативы, возвращаться в отзывчивое состояние. Это требование постоянного активного состояния, в сочетании с более низкой посекундной стоимостью активного состояния в ClickHouse Cloud, приводит к тому, что ClickHouse Cloud предлагает существенно более низкую итоговую стоимость для таких типов нагрузок.

• Предсказуемое ценообразование функций: такие функции, как materialized views и кластеризация (эквивалент ORDER BY в ClickHouse), необходимы для достижения максимального уровня производительности в сценариях аналитики в реальном времени. Эти функции порождают дополнительные расходы в Snowflake, требуя не только более высокого тарифа, что увеличивает стоимость за кредит в 1,5 раза, но и непредсказуемых фоновых затрат. Например, materialized views имеют фоновую стоимость на обслуживание, как и кластеризация, и её трудно предсказать до начала использования. Напротив, в ClickHouse Cloud эти функции не приводят к дополнительным затратам, за исключением дополнительного потребления CPU и памяти во время вставки, что обычно пренебрежимо мало за пределами сценариев с высокой нагрузкой на вставку. В нашем бенчмарке мы наблюдали, что эти различия, вместе с меньшей задержкой запросов и более высокой степенью сжатия, приводят к существенно более низким затратам с ClickHouse.