Миграция с 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 демонстрирует эту архитектуру:

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

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

Различия

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

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

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

• Кеш запросов ClickHouse Cloud в настоящее время специфичен для узла, в отличие от кеша Snowflake, который реализован на сервисном уровне и не зависит от конкретного warehouse. Согласно бенчмаркам, кеш узлов ClickHouse Cloud превосходит кеш Snowflake по производительности.

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

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

Real-time analytics

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

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

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

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

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