[Перевод] DWH: История поиска альтернативы PostgreSQL и Snowflake. Часть 111.04.2025 19:46

Snowflake, Timescale, Amazon Redshift, ClickHouse, Google Cloud BigQuery, Apache Druid, Apache Cassandra, Firebolt… Выбор подходящего облачного хранилища данных может оказаться довольно сложной задачей — доступных вариантов целое множество. И недавно мне довелось руководить масштабным внутренним исследованием, в рамках которого мы в Agritask сравнивали ведущие облачные хранилища данных. Мы хотели определить, какая платформа лучше всего подходит для выполнения сложных запросов над миллиардами записей с высоким уровнем параллелизма и низкой задержкой, обеспечивая при этом оптимальное соотношение цены и производительности. Процесс исследования включал тщательное тестирование на нескольких системах, чтобы выявить их сильные и слабые стороны, а также измерить контрольные показатели производительности. Учитывая глубину и масштаб наших выводов, я с радостью поделюсь ими, чтобы помочь вам, коллегам data‑инженерам, облегчить сложность выбора подходящего для ваших нужд хранилища.

В этой статье я затрону:

1. Юзкейс, под который мы подбирали хранилище

2. Технические требования

3. Оценку хранилищ данных: Snowflake, Timescale, Amazon Redshift, ClickHouse, Google Cloud BigQuery, Apache Druid, Apache Cassandra, Firebolt

4. Результаты нашего исследования

5. Сравнение вендоров

6. Проблемы и извлеченные уроки

7. Советы коллегам‑инженерам

Юзкейс, под который мы подбирали хранилище

Компания Agritask разработала инновационную SaaS‑платформу, которая обеспечивает наглядное представление о предсказуемости и устойчивости поставок сельскохозяйственных культур для предприятий пищевой промышленности и производства напитков. Используя дополненные агрономические данные, машинное обучение и аналитику, Agritask предлагает предприятиям ценные сведения и современные инструменты для оптимизации процессов снабжения в разнообразных экосистемах, которые расположены по всему миру: от небольших хозяйств до крупных корпоративных фермерских комплексов. Наша платформа предлагает такие функции, как управление урожаем, профилирование затрат, анализ урожайности, соблюдение нормативных требований и оценку выбросов углерода. Непосредственная связь предприятий с производителями и поставщиками, которые находятся у истоков их цепочки создания ценности, позволяет компании Agritask играть ключевую роль в повышении устойчивости как самих предприятий, так и их цепочек поставок.

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

Наша текущая архитектура, состоящая из десятков горизонтально распределенных баз данных PostgreSQL и центрального хранилища данных Snowflake, успешно функционирует уже более десяти лет. Она обеспечивает хорошую горизонтальную масштабируемость, позволяя обслуживать практически неограниченное количество клиентов. Однако в рамках одного клиента возможности горизонтальной масштабируемости ограничены, а вертикальное масштабирование представляет собой сложную задачу. Когда объем данных в конкретном экземпляре базы данных PostgreSQL превышает миллиард записей, вертикальное масштабирование становится все более дорогостоящим. Мы хотим перенести всю тяжелую работу из PostgreSQL в облако, сохранив при этом возможность обслуживания наших приложений для обработки интерактивных данных. Наша цель — обрабатывать огромные объемы данных с низкой задержкой и высоким уровнем параллелизма. Именно в этой ситуации PostgreSQL и Snowflake оказались не совсем подходящими для наших нужд (более подробно об этом я расскажу ниже), поэтому мы начали искать дополнительные или альтернативные решения.

Мы рассмотрели несколько вариантов: заменить PostgreSQL, заменить Snowflake или добавить кэш поверх Snowflake. Некоторые из предложенных решений могли бы заменить PostgreSQL, другие могли бы служить кэшем, а некоторые могли бы полностью заменить Snowflake. Мы тщательно изучили все возможные варианты, чтобы выбрать наилучший. Забегая вперед, скажу, что в итоге мы остановились на решении добавить кэш поверх Snowflake, чтобы иметь возможность полностью заменить Snowflake в будущем. Однако мы сохранили PostgreSQL, чтобы избежать полного рефакторинга всей системы. Мы просто перенесли всю тяжелую работу из PostgreSQL в облако.

Технические требования

• Структура таблиц и SQL совместимые с PostgreSQL: Чтобы минимизировать рефакторинг существующих внутренних компонентов, мы стремимся сохранить структуру таблиц как можно ближе к оригинальной структуре PostgreSQL. Это означает, что одни и те же SQL‑запросы (с минимальными автоматическими изменениями) должны выполняться как для «локального» хранилища данных PostgreSQL, так и для «удаленного» облачного хранилища данных.

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

• Обработка неструктурированных данных: Структура данных может значительно различаться — от простых числовых значений до сложных JSON‑структур. Например, показания датчика могут быть представлены в виде простого числа (17 °C). Список отсканированных контейнеров может храниться в виде массива идентификаторов. Набор полей только созданного объекта сохраняется в виде JSON‑структуры. Записи, полученные на местах, могут быть связаны с материалами, оборудованием и содержать ссылки на изображения или документы в файловом хранилище.

• Динамические и сложные запросы: Из‑за разнородного характера данных возникает необходимость в гибкости поддерживаемых запросов. Это требование также повлияло на структуру таблицы и требования к совместимости с SQL.

• Объемы данных: В настоящее время в нашем распоряжении 15–20 горизонтально масштабируемых серверов PostgreSQL, на которых установлено хранилище данных Snowflake. Эти серверы обрабатывают более 2 миллиардов записей. Наша цель — увеличить этот объем до более чем 1 триллиона записей.

• Высокая степень параллелизма: Наша система должна быть способна обрабатывать от 50 до 100 одновременных запросов в секунду. И мы стремимся значительно увеличить эти показатели с учетом будущих потребностей без ущерба для производительности.

• Низкая задержка: Чтобы наше хранилище данных было целесообразным, оно должно обеспечивать время отклика на оперативные запросы в доли секунды. Наша главная цель — запустить интерактивные приложения для обработки данных на основе этого хранилища.

• Затраты: У нас есть строгий бюджет, который мы не можем превысить. В рамках нашего тестирования мы оценивали затраты на различные платформы.

• Облачное решение: Мы искали управляемое решение, которое поможет разгрузить наших data‑инженеров и DevOps.

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

Процесс оценки

В нашу оценку были включены как популярные, так и недавно появившиеся облачные хранилища данных. Некоторые из них мы отобрали самостоятельно, другие же были рекомендованы нам консультантами. Поскольку мы не могли протестировать все доступные хранилища данных в мире, мы сосредоточились на тех, которые, по нашему мнению, могли бы хорошо подойти для нашего юзкейса. Конечно, в нашем выборе есть определенная предвзятость, так как некоторые потенциальные кандидаты (например, Oracle и MS SQL Server) нами даже не рассматривались.

Процесс оценки для большинства платформ включал следующие этапы:

1. Загрузка 100–200 млн записей и запуск тестового набора SQL‑запросов. Этот шаг позволил оценить простоту использования и совместимость с SQL.
   Чтобы тесты были репрезентативными для нашего юзкейса, мы извлекли ряд типичных SQL‑запросов из наших производственных логов. Каждый из этих примеров запросов включал различные объединения, условия фильтрации и операции агрегирования.

2. Загрузка около 1 млрд записей и выполнение того же набора тестовых SQL‑запросов. Этот шаг продемонстрировал, насколько хорошо хранилище данных может масштабироваться для наших данных и запросов. Кроме того, на этом этапе мы косвенно оценили эффективность обработки данных.

3. Запуск 1–50 одновременных запросов из Java‑клиента, каждый с выбранным SQL‑запросом. Это был последний этап нашего оценочного процесса, который показал, способно ли хранилище данных обслуживать наши интерактивные приложения.

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

Почему мы ограничились 50 запросами? Производительность большинства тестируемых хранилищ данных быстро снизилась, и лишь немногие смогли эффективно обрабатывать даже 50 одновременных запросов (учитывая затраты и ограничения емкости). Поэтому мы остановились на 50 и просто оценили затраты на запуск кластера, который пропорционально масштабируется до необходимого нам уровня параллелизма.

Оценка облачных хранилищ данных

PostgreSQL

Следует отметить, что PostgreSQL — это превосходная база данных с открытым исходным кодом. Она демонстрирует высокую производительность, позволяя выполнять сложные SQL‑запросы на одном сервере, зачастую превосходя многие облачные базы данных. Благодаря хорошей модели данных PostgreSQL способен обрабатывать миллиарды записей данных. Эта система характеризуется многофункциональностью, гибкостью, стабильностью и проверенной надежностью. Она с легкостью поддерживает структурированные, неструктурированные и геопространственные данные.

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

Snowflake

Мы начали рассматривать Snowflake как первый вариант, так как уже используем его для бизнес‑аналитики, и нашу команду по обработке данных он вполне устраивает. Однако мы быстро исключили его из списка из‑за задержек и ограничений в параллелизме. В ходе общения с консультантами мы узнали, что клиенты с похожими на наш юзкейсами переходят к использованию Apache Cassandra в качестве кэша поверх Snowflake (абсолютно по тем же причинам).

Плюсы:

• Простота использования: Snowflake пользуется популярностью благодаря своему удобному интерфейсу и совместим с SQL‑запросами, которые используются нашим текущим бэкендом.

• Простота управления: Будучи облачным решением, Snowflake избавляет от необходимости сложного управления базами данных и их обслуживания, предлагая масштабируемую архитектуру без необходимости управления физической инфраструктурой.

• Особенности: Snowflake поддерживает структуры и обработку геопространственных данных, что особенно важно для нашего юзкейса.

• Простая миграция: Snowflake уже готова к использованию, включая всю необходимую ETL‑инфраструктуру.

Минусы:

• Высокая задержка выполнения запросов: Даже с самыми дорогими движками, которые определенно превышают наш бюджет, задержка на выполнение запроса не может быть снижена до показателя ниже одной секунды, что не соответствует требованиям к операциям в реальном времени.

• Параллелизм: Snowflake не предназначена для высоко параллельных запросов, поэтому требуется кластеризация, а это значительно увеличивает затраты.

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

TimescaleDB

Это был второй идеальный кандидат из‑за простоты миграции — она похож на PostgreSQL, но с расширенными возможностями.

TimescaleDB использует так называемые «гипертаблицы» для повышения масштабируемости. Гипертаблицы обеспечивают эффективное разделение данных и масштабирование запросов, что крайне важно для динамического управления большими объемами информации. динамического управления большими объемами информации. Следует отметить, что существует два различных формата разделов гипертаблиц. Стандартным является формат на основе строк, который напоминает стандартное разбиение таблиц в PostgreSQL. Однако есть и другой формат — колоночный, который занимает гораздо меньше дискового пространства, но имеет совершенно иные характеристики производительности и накладывает ограничения на модификацию данных.

Плюсы:

• 100% совместимость с PostgreSQL — важно для нашего юзкейса, потому что это позволило бы выполнить простую миграцию и минимизировать количество требуемого рефакторинга на нашем бэкенде.

• Производительность при выполнении большинства запросов: TimescaleDB продемонстрировала высокую производительность при выполнении множества запросов с преобразованием данных временных рядов в строковые гипертаблицы.

• «Холодный запуск» с высокой производительностью: TimescaleDB демонстрирует отличную производительность при первом выполнении запросов с гипертаблицами. Это хорошо известная проблема в PostgreSQL и многих других базах данных, заключающаяся в том, что выполнение запросов занимает много времени, пока не будет заполнен дисковый кэш. Однако TimescaleDB, похоже, успешно решает эту задачу.

• На выбор есть бесплатные автономные и облачные решения.

Минусы:

• Потребление дискового пространства и затраты: Гипертаблицы на основе строк с индексами занимают немного больше места на диске, чем исходные таблицы PostgreSQL. Предполагаемый объем необходимого дискового пространства для хранения 1 млрд записей оказался больше, чем даже максимальный (вне нашего бюджета) план облачного управления, что сразу стало препятствием.

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

• Ограничения на модификацию формата смешанных данных: Использование колоночного формата также усложняет управление изменениями исторических данных, которые иногда требуются по логике приложения.

• Масштабируемость: Как и в PostgreSQL, база данных ограничена одним сервером и может масштабироваться только за счет добавления реплик для повышения параллелизма запросов чтения. Таким образом, масштабируемость ограничена возможностями вертикального масштабирования одного главного сервера.

Amazon Redshift

Amazon Redshift показался наиболее разумным вариантом для AWS, особенно в сочетании с PostgreSQL, размещенным на Amazon RDS.

Плюсы:

• Бессерверная архитектура: Решение Redshift устраняет необходимость в постоянном управлении сервером. Существует также provisioned опция, но мы не рассматривали ее, так как приоритет был отдан непрерывному масштабированию вверх и вниз.

• Совместимость с PostgreSQL: Redshift демонстрирует отличную совместимость с PostgreSQL, включая типы данных и синтаксис запросов. Однако есть несколько особенностей, которые необходимо учитывать. Например, PostgreSQL позволяет хранить тексты размером до 64 Кб в текстовых полях, а Redshift не поддерживает такие большие объемы. Также есть проблема с числовыми значениями NaN, которые Redshift не поддерживает.

• Хорошая масштабируемость данных: Redshift без труда справляется с огромными объемами данных и демонстрирует высокую производительность при массовом приеме.

• Простая интеграция с PostgreSQL, размещенным на Amazon RDS — автоматический ETL и федеративные запросы.

Минусы:

• Нестабильная производительность запросов: В целом, производительность Redshift была лучше, чем у PostgreSQL, во многих (не во всех) запросах, но не так хороша, как у других оцениваемых решений. На мой взгляд, это решение хорошо подходит для сложных задач в области бизнес‑аналитики, но менее эффективно для запросов с низкой задержкой, которые обслуживают интерактивные юзкейсы.

• Проблемы с задержкой: Бессерверная система Redshift, как и PostgreSQL, сталкивается с проблемой холодного запуска. Часто при выполнении первого запроса наблюдались задержки, превышающие допустимые значения. Из‑за гибкости бессерверного подхода Redshift это может стать особенно серьезной проблемой, если определенные запросы перестанут выполняться на некоторое время из‑за повторного разогрева базы данных.

• Ограниченный параллелизм: Redshift с трудом справляется с высокими уровнями параллелизма. Система быстро достигла своего предела, работая менее чем с 10 одновременными запросами. Хотя существуют параметры конфигурации, позволяющие увеличить параллелизм, они пропорционально повышают затраты, а максимально допустимые значения по‑прежнему не позволяют достичь запланированного уровня.

• Проблемы с затратами и масштабируемостью: Бессерверная обработка Redshift может быть очень экономичной для юзкейсов, предполагающих нерегулярную обработку огромных объемов данных. Однако в нашем случае, основываясь на стоимости уже выполненных запросов, прогнозируемые затраты в полностью масштабируемом сценарии оказались выше запланированного бюджета.

В следующей части мы рассмотрим Clickhouse, BigQuery, Apache Druid, Cassandra и Firebolt, а также обсудим результаты исследования.

Если вы работаете с аналитикой данных и параллельно следите за тем, как развивается инфраструктура — возможно, вас заинтересует открытый урок «Docker в действии: как контейнеризация меняет аналитику данных?». Разберём реальные кейсы, где контейнеризация упрощает работу с большими объёмами данных, ускоряет деплой аналитических пайплайнов и помогает масштабировать систему без боли. Урок пройдёт 24 апреля, участие бесплатное.

Список всех открытых уроков можно посмотреть в календаре.