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

Этот документ представляет собой введение в миграцию данных из Snowflake в ClickHouse.

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

Сравнение

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

Сходства

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

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

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

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

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

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

Различия

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

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

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

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

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

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

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

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

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

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

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

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