Snowflake, Timescale, Amazon Redshift, ClickHouse, Google Cloud BigQuery, Apache Druid, Apache Cassandra, Firebolt… Выбор подходящего облачного хранилища данных может оказаться довольно сложной задачей — доступных вариантов целое множество. И недавно мне довелось руководить масштабным внутренним исследованием, в рамках которого мы в Agritask сравнивали ведущие облачные хранилища данных. Мы хотели определить, какая платформа лучше всего подходит для выполнения сложных запросов над миллиардами записей с высоким уровнем параллелизма и низкой задержкой, обеспечивая при этом оптимальное соотношение цены и производительности. Процесс исследования включал тщательное тестирование на нескольких системах, чтобы выявить их сильные и слабые стороны, а также измерить контрольные показатели производительности. Учитывая глубину и масштаб наших выводов, я с радостью поделюсь ими, чтобы помочь вам, коллегам data-инженерам, облегчить сложность выбора подходящего для ваших нужд хранилища.
Clickhouse
Нам порекомендовали Clickhouse как невероятно масштабируемую in-memory базу данных, способную обрабатывать петабайты данных в продакшене и обслуживать высоко параллельные запросы с низкой задержкой. Кроме того, у нее есть как управляемые облачные, так и бесплатные варианты для локального размещения, что также было очень привлекательным.
Плюсы
Скорость загрузки данных: Во время наших тестов мы смогли загрузить в нее сотни миллионов записей всего за несколько минут, что невероятно быстро и выгодно для сред с высокой пропускной способностью.
Высокая производительность при выполнении конкретных запросов: В сценариях, где Clickhouse мог бы продемонстрировать свои сильные стороны, таких как простые аналитические запросы без объединений, она показала очень высокую производительность, эффективно обрабатывая большие объемы данных.
Потребление дискового пространства: Clickhouse использует значительно меньше дискового пространства по сравнению с PostgreSQL — на два порядка меньше. Можно предположить, что это также относится ко всем колоночным базам данных.
Минусы:
Проблемы со сложными запросами: Несмотря на свои сильные стороны в приеме данных и простых запросах, Clickhouse сталкивалась с заметными трудностями при выполнении более сложных запросов, особенно с теми, которые включают объединения. На тех же (относительно небольших) объемах данных PostgreSQL выполнял те же запросы более чем в 10 раз быстрее, чем Clickhouse.
Надежность выполнения запросов: Мы заметили, что Clickhouse не всегда может последовательно обрабатывать сложные SQL-запросы, которые PostgreSQL способен выполнить за миллисекунды. В некоторых случаях запросы, включающие иерархические структуры данных или несколько объединений, не завершались и зависали.
На недавней конференции AWS я общался с представителями Clickhouse, и они сказали, что активно работают над улучшением планировщика запросов и объединений.
Из-за проблем со сложными SQL-запросами, мы решили не проводить тесты на параллелизм и двинуться дальше.
Google Cloud BigQuery
Несмотря на то, что нас меньше интересовало использование хранилищ данных, которые не размещаются на AWS, мы решили рассмотреть Google Cloud BigQuery, так как слышали положительные отзывы о ее производительности.
Плюсы:
Эффективность пакетной обработки и бизнес-аналитики: BigQuery продемонстрировала высокую производительность в крупномасштабных задачах пакетной обработки и бизнес-аналитике.
Прием данных: Одной из ключевых особенностей BigQuery является ее производительность при загрузке данных. В ходе наших тестов мы смогли быстро и надежно загружать большие объемы данных, что крайне важно для поддержания актуальной аналитики.
Бессерверная архитектура: Как полностью управляемое бессерверное решение, BigQuery устраняет большую часть накладных расходов, связанных с традиционными решениями для хранения данных.
Минусы:
Совместимые типы данных: Автоматическое определение форматов данных столбцов может сделать процесс извлечения данных из неструктурированных форматов, таких как CSV, весьма затруднительным, а иногда и вовсе невозможным. Переход на формат Parquet значительно облегчает эту задачу.
Затраты: BigQuery может стать довольно дорогостоящим решением, особенно по мере увеличения нагрузки запросов. В ходе нашего исследования мы обнаружили, что операционные расходы могут стремительно возрасти, что делает ее менее привлекательным вариантом с учетом наших бюджетных ограничений.
Проблемы с задержкой: BigQuery, являясь аналитической базой данных, демонстрирует высокую производительность для сложных запросов, обрабатывающих огромные объемы данных. Однако она не так хорошо подходит для запросов с низкой задержкой, необходимых для приложений, работающих с интерактивными данными.
Интеграция с существующей инфраструктурой: Наша текущая инфраструктура в основном ориентирована на AWS, и интеграция BigQuery, облачного продукта Google Cloud, привела бы к дополнительным сложностям и потенциальным задержкам из-за необходимости перемещать данные между облачными платформами.
Apache Druid (Imply)
Изначально мы не планировали оценивать Apache Druid, так как ее автономный вариант требует значительных усилий по настройке и обслуживанию. Но как только мы узнали о ее облачном варианте, предлагаемом компанией Imply, мы решили дать ей шанс. В итоге она занял заслуженное второе место в наших оценках.
Плюсы:
Высокая производительность при работе с данными временных рядов: Apache Druid демонстрирует впечатляющую производительность при работе с данными временных рядов, что делает ее идеальным решением для наших задач, связанных с хронологическим анализом информации. Хотя на ранних этапах тестирования сложных SQL-запросов время выполнения оставляло желать лучшего, совместная работа с командой технической поддержки позволила нам оптимизировать форматы данных, индексы и запросы, что в итоге привело к значительным улучшениям в производительности.
Высокий уровень параллелизма: В наших тестах Druid продемонстрировала очень хорошие результаты по параллелизму, опередив большинство других решений (стоит отметить, что некоторые из перечисленных решений, такие как Clickhouse, не дошли до стадии тестирования параллелизма, поэтому мы не сравниваем их здесь).
Автономная версия: Хотя нашей целью было облачное решение, доступен и этот вариант развертывания.
Оперативная поддержка: Мы были приятно удивлены скоростью и эффективностью работы команды Imply. Они оперативно реагировали на наши технические вопросы, что позволило нам быстро их решать.
Хорошая совместимость с SQL: несмотря на некоторые особенности при создании таблиц и определении типов данных столбцов, синтаксис SQL-запросов был в достаточной степени совместим с PostgreSQL.
Расширенные сопутствующие инструменты: Облачное решение включает в себя интегрированный инструмент визуализации данных (аналогичный Tableau). Это является значительным преимуществом.
Минусы:
Ограничения схемы и индексации: Схема базы данных и способ индексации таблиц в Apache Druid отличаются от более традиционных баз данных SQL. Это различие может привести к проблемам совместимости с существующими моделями данных и может потребовать корректировки процессов приема данных и запросов.
Неоднозначные результаты производительности запросов: Хотя Apache Druid способна демонстрировать высокую производительность, в нашем случае часто требовалась тщательная настройка и консультации со службой поддержки.
Одной из главных проблем, с которыми столкнулась наша команда, стали отличия от привычных нам реляционных баз данных, таких как Snowflake и PostgreSQL. Необходимость оптимизации структур данных и запросов стала серьезным испытанием для нас. Однако, несмотря на эти сложности, производительность и масштабируемость Apache Druid произвели на нас большое впечатление.
Apache Cassandra
Apache Cassandra — это база данных для обработки данных временных рядов, и она была одним из первых кандидатов, которые мы рассмотрели. Однако после серии консультаций с поддержкой облачного решения Cassandra мы пришли к выводу, что использование этой системы потребует полной перестройки нашей схемы и запросов, чего мы стремились избежать. Поэтому мы не стали проводить тестирование Apache Cassandra.
Во время изучения Apache Cassandra мы обратили внимание на ScyllaDB, которая еще известна как “Cassandra на стероидах”. Она выглядит многообещающе с точки зрения производительности и потребления ресурсов, но пока не подходит для нашего юзкейса.
Firebolt
Firebolt не входила в первоначальный список решений, которые мы планировали оценить, но в какой-то момент разные люди начали рекомендовать ее. Хотя процесс оценки был уже на финальных стадиях, мы решили включить ее в список и были приятно удивлены результатами.
Firebolt стала нашим выбором, так как она предлагает идеальное сочетание производительности, масштабируемости, совместимости, затрат и простоты использования.
Мы даже подумываем о том, чтобы в будущем полностью перейти на Firebolt вместо Snowflake, учитывая их схожие функции, совместимость с SQL и общий подход к работе. Однако стоит отметить, что Firebolt не поддерживает геопространственные возможности, которые есть у Snowflake.
Плюсы:
Производительность при работе с большими объемами данных: Firebolt продемонстрировала выдающуюся производительность при обработке больших объемов информации, выполняя многие из наших сложных запросов всего за десятки миллисекунд. Что самое важное, он обеспечивал высокую производительность без необходимости адаптации наших структур данных и с минимальными изменениями SQL-запросов или вообще без них.
Масштабируемость и гибкость: Одной из главных преимуществ Firebolt является ее способность к масштабированию, что позволяет эффективно управлять возрастающими объемами данных без заметного снижения производительности. В одном из наших тестов, при увеличении набора данных в 10 раз, среднее время выполнения запроса на том же оборудовании увеличилось всего на 25-30%, что является весьма впечатляющим результатом.
Экономичность при масштабировании: По сравнению с другими решениями, которые мы тестировали, Firebolt предлагает более экономичный подход к масштабированию. Архитектура Firebolt позволяет гибко изменять размеры движка без прерывания обслуживания, что способствует оптимизации затрат и эффективному преодолению пиковых нагрузок.
Высокий уровень параллелизма: Firebolt поддерживает более высокий уровень параллелизма, чем многие другие базы данных, которые мы оценивали. Это особенно важно для нашей операционной модели, которая требует обработки множества одновременных запросов от приложений, работающих с интерактивными данными.
Оперативная поддержка: Команда поддержки Firebolt проявила исключительную отзывчивость и готовность помочь в процессе адаптации, получения тестовых данных и анализа производительности запросов. В какой-то момент мы обнаружили незначительную несовместимость синтаксиса SQL PostgreSQL, но смогли быстро адаптироваться к ней. Команда Firebolt оперативно исправила эту ошибку на своей стороне.
Минусы:
Потоковая передача не поддерживается: Firebolt демонстрирует хорошую производительность при работе с большими объемами данных, однако в настоящее время потоковая передача не поддерживается. Чтобы удовлетворить нашу потребность в данных, близких к реальному времени, мы использовали микропакетный (micro-batch) прием данных.
Только для AWS: Firebolt работает исключительно на AWS, что не стало для нас проблемой, поскольку наша существующая инфраструктура в первую очередь ориентирована на AWS.
Стек данных, к которому мы стремились
Эта диаграмма представляет собой упрощенный вариант, чтобы продемонстрировать ключевые элементы базы данных. Она не включает в себя геопространственную обработку, ETL, обработку агрегации и другие детали, касающиеся Kafka.
В этой схеме Firebolt выступает в роли быстрого кэша между серверами приложений и хранилищем данных. Он обеспечивает низкую задержку и высокий уровень параллелизма при запросах данных для визуализаций. Благодаря своей универсальности и способности обрабатывать большие объемы данных, Firebolt может в будущем заменить Snowflake, что упростит нашу архитектуру.
Результаты исследования
Мы сравнили производительность каждого вендора с нашей существующей базой данных PostgreSQL. Чтобы сделать тесты более объективными, мы извлекли образцы SQL-запросов из наших производственных логов. Каждый из этих примеров содержал различные объединения, условия фильтрации и операции агрегирования.
Мы также подготовили два набора данных для тестирования: один с общим количеством записей 150 миллионов, а другой — с общим количеством записей 966 миллионов. В приведенной ниже таблице представлены некоторые результаты сравнительного анализа производительности Firebolt по сравнению с нашей текущей платформой.
Результаты оценки Firebolt по сравнению с нашей существующей платформой PostgreSQL для 150 миллионов записей:
Результаты оценки Firebolt для 966 миллионов записей:
Сравнение остальных вендоров
Представленная ниже таблица носит субъективный характер и отражает опыт нашей команды в нашем конкретном юзкейсе. В других случаях оценки могут распределяться иначе.
Показатели производительности запросов и задержки также не следует воспринимать как единый критерий оценки производительности конкретного решения. Например, низкая производительность запросов в случае с Clickhouse не означает, что Clickhouse работает медленно — при правильном использовании он может быть чрезвычайно быстрым. Однако в нашем случае он оказался неподходящим для выполнения запросов, включающих множество объединений и несколько условий фильтрации.
Производительность запросов характеризует способность базы данных обрабатывать сложные запросы (подобные тем, которые мы использовали) за относительно короткое время — примерно 100 мс или меньше, в идеале — за десятки мс.
Задержка, с другой стороны, определяет, насколько быстро система реагирует на быстрые запросы (с учетом времени, необходимого для передачи данных по сети). Например, Snowflake может отлично справляться с интенсивными нагрузками, но его задержка делает его непригодным для выполнения запросов в реальном времени.
То же самое касается и “совместимости с SQL” — только TimescaleDB заслуживает здесь 5 звезд, потому что это практически тот же движок PostgreSQL. Все другие решения могут быть очень близки, но не на 100%. Мы здесь не говорим об объективном стандарте SQL:20xx. Это субъективный показатель количества проблем, с которыми мы сталкиваемся при попытке выполнить наши запросы к определенной базе данных.
Например, у нас были проблемы с использованием непостоянных значений в правой части LIKE, с “$” в именах столбцов, с иерархическими запросами, с типами данных столбцов, с нулевыми значениями и т.д.
Проблемы и извлеченные уроки
Ключевым выводом нашего исследования стало понимание необходимости адаптации возможностей хранилища к нашим специфическим структурам данных и требованиям к запросам. Каждая платформа имеет свои преимущества, но также и ограничения, которые иногда становятся очевидными только в реальных условиях нагрузки. Мы тщательно сбалансировали стоимость, производительность и масштабируемость, осознавая, что идеального решения может не существовать и нам придется идти на компромиссы.
Firebolt стал нашим выбором благодаря своей способности анализировать большие объемы данных с низкой задержкой и удобному интерфейсу SQL.
Советы коллегам-инженерам
При проведении подобного исследования документируйте каждое открытие, даже если оно незначительное. Это поможет вам глубже понять не только сильные стороны, но и ограничения каждой технологии.
Определите четкие требования, рабочие характеристики и способы их тестирования перед началом исследования.
Не стесняйтесь обращаться в службу поддержки вендоров. Их отзывчивость и опыт могут быть неоценимы. Они помогут вам с первоначальным вводом данных и адаптацией, а также решат проблемы с производительностью ваших запросов.
Наконец, будьте готовы рассмотреть разные варианты. В итоге мы выбрали и Firebolt, и Snowflake для разных задач. Иногда лучшим решением является комбинация технологий, адаптированных к вашим конкретным требованиям.
Если вы работаете с аналитикой данных и параллельно следите за тем, как развивается инфраструктура — возможно, вас заинтересует открытый урок «Docker в действии: как контейнеризация меняет аналитику данных?». Разберём реальные кейсы, где контейнеризация упрощает работу с большими объёмами данных, ускоряет деплой аналитических пайплайнов и помогает масштабировать систему без боли. Урок пройдёт 24 апреля, участие бесплатное.
