Проверяем популярные движки вычислений на задаче BI-доступа с помощью теста ClickBench

В сегодняшней публикации мы попробуем разобраться в производительности популярных MPP-движков в специализированной задаче ХД – предоставлении доступа к денормализованной витрине данных. Также ответим на вопрос: нужен ли ClickHouse в аналитическом ландшафте, спроектированном по принципу Lakehouse-платформ? Для этого будем использовать бенчмарк ClickBench.

ClickBench появился не так давно, в 2022 году. Методика создана и поддерживается командой ClickHouse. Авторы позиционируют его следующим образом -  «Этот бенчмарк представляет типичную рабочую нагрузку в следующих областях: анализ потоков кликов и трафика, веб-аналитика, машинно-генерируемые данные, структурированные журналы и данные о событиях. Он охватывает типичные запросы в ad-hoc аналитике и дашбордах реального времени». Последний сценарий вызывает у нас особый интерес, ведь редко встретишь архитектурный дизайн аналитического ландшафта, где не было бы решения на базе ClickHouse именно для этой цели, на вершине пирамиды тракта данных от источника до потребителя. 

О методике

Бенчмарк включает:

• Набор данных, содержащий плоскую таблицу (да, именно одну табл��цу) ровно с 99 997 497 записями;

• 43 SQL-запроса, охватывающие ряд сценариев использования аналитики в рамках чтения одной таблицы (запускаются последовательно);

• Страница в сети;

• Github.

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

• Своей узкой специализированности аналитики над одной таблицей без JOIN-операций (по мнению авторов «типичные запросы в ad-hoc аналитике и дашбордах реального времени» именно такие);

• Отсутствия конкурентной нагрузки.

Но стадарт есть стандарт, и давайте будем его придерживаться.

Тестовое окружение

• Все тесты выполняются в Яндекс.Облаке;

• Данные размещены в Managed S3 хранилище;

• Формат данных parquet ZSTD Compression level 3, структура DDL полностью соответствуют методике теста;

• 4 worker-узла, 32 vCores – каждый, и 320 Gb памяти для каждого движка;

• ClickHouse в режиме работы над S3 использовал те же типы worker’ов.

Для теста ClickHouse c локальными дисками:

• 4 узла;

• 32 vCores 320 Gb RAM;

• 1 Tb SSD-диск (самая быстрая дисковая подсистема в Яндекс.Облаке);

• Формат данных MergreTree cо сжатием LZ4;

• 4 distributed шарда по ключу WatchID.

Базовые версии движков:

• ClickHouse 25.11.1.558;

• Data Ocean Nova 2025.07:

  • StarRocks core 3.5.5;

  • Impala core 4.5;

  • Trino core 476.

Результаты

Результаты в табличном виде в разрезе каждого запроса и движка

Посмотрим на агрегированные результаты на диаграмме

Нам показалось, что 100 млн записей в витрине данных – это мало. Мы решили усложнить себе задачу, так как всегда ориентированы на действительно большие данные, а не на «тест на калькуляторах», и провести еще две итерации с увеличенным объемом датасета в 50 и 100 раз, а только потом переходить к выводам. Зря мы что ли аж 4 worker-узла поднимали?

Оригинальный dataset был размножен достаточно примитивным способом – через insert-операцию оригинального датасета, но с генерацией уникальных ключей. После получения целевого объема датасета над витриной проводилась финальная операция перезаписи через Insert table overwrite as select.. Для каждого процессингового движка после этого собиралась статистика:

• В итерации х50 получилось 4 999 874 850 строк (~5 млрд);

• Для х100 – 9 999 749 700 строк (~10 мрд).

Давайте оценим, как объем повлиял на результаты.

Выведем результаты на диаграмму, но для удобства масштабирования исключим аутсайдера (ClickHouse, работающий над S3-датасетом).

С детализацией запросов для объема данных x50 и x100 можно ознакомиться в приложении в конце статьи.

Выводы

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

1. В подавляющем большинстве случаев при использовании современных BI-движков поверх объектного хранилища данных можно получить время отклика, сопоставимое (а часто и лучше) с временем отклика «короля bi-запросов» – ClickHouse, который использует свой внутренний формат хранения на локальной дисковой подсистеме. При этом важно помнить, что в данном тесте мы играли по правилам, придуманным ClickHouse на его, если можно так сказать, домашнем поле. Очевидно, что если правила нарушить и разбавить нагрузку запросами, содержащими JOIN-операции, то ClickHouse такие сценарии просто провалит;

2. Trino как вычислительная технология для быстрого доступа к денормализованной витрине данных пока выглядит наименее привлекательным среди представленных в тесте движков;

3. Использование S3 c ClickHouse все еще сопряжено с большими проблемами. Прежде всего, связанными с тем, что в S3 отсутствует привычное для ClickHouse шардирование. Открытые форматы данных требуют от разраб��тчиков изменить подход к работе движка, на что требуется значительное время (чем собственно команда ClickHouse и занимается).

Данные выводы не отменяют того факта, что ClickHouse с локальным хранением – чемпион в сценарии доступа к денормализованным данным. Однако наличие отдельно стоящего ClickHouse рядом с Lakehouse-платформой, предлагающей в качестве вычислительных технологий StarRocks или Impala, показывающих превосходный результат над S3 в данной задаче, может быть экономически и функционально не оправдано. К тому же доступность данных в витрине будет хуже, так как на перекладывание данных из S3 в ClickHouse потребуется дополнительное время и ресурсы. Да и сценарии применения ограничены из-за отсутствия нормально работающих JOIN-операций.

Данное утверждение справедливо не только для сочетания Lakehouse+ClickHousе, но и для ставшей привычной на нашем рынке связки GreenPlum+ClickHouse. Такая парадигма существовала только потому, что первая система плохо справлялась с задачами второй и наоборот. Все это привело к ухудшению доступности сервисов и увеличению общей стоимости владения. 

И последнее. Если Lakehouse-платформа данных представлена только одним Trino, и вам необходим BI-доступ к плоской витрине с минимальным откликом, то избежать подселения в зоопарк дополнительной технологии пока не представляется возможным.

Не будет лишним еще раз напомнить: выбирать Lakehouse-движок для сценариев общего применения на основании только результатов ClickBench – ошибка, так как тест имеет исключительно узкоспециализированную направленность. Держите эту мысль всегда в голове, когда изучаете маркетинговые материалы. Требуются комбинированный подход и сочетание проверочных методик тестирования.

Заключение

Мы собираемся продолжать делиться результатами функциональных и нагрузочных испытаний популярных технологий вычислений. Несмотря на то, что мы публикуем только результаты движков, используемых в платформе Data Ocean Nova с учетом доработок и изменений, мы также уделяем внимание и другим популярным MPP-технологиям, например, Doris. Однако воздерживаемся пока от публикаций и ожидаем, что другие игроки на российском рынке Big Data, разрабатывающие и предлагающие платформы данных и обладающие большой экспертизой, насмотренностью и опытом, поделятся с сообществом своими результатами.

Если у вас есть идеи, как можно разбавить ClickBench для получения более реалистичных сценариев работы (например, добавить конкурентности или расширить список запросов, среди которых будет доступ по ключу), то напишите нам, пожалуйста, в комментарии через телеграм-канал Data Sapience. Мы всегда открыты к диалогу.

Предыдущие материалы по теме нагрузочных тестирований (в порядке публикации):

• Тестирование систем и движков массивно-параллельных вычислений. Сравнение Impala, Trino и GreenPlum;

• Тестирование систем и движков массивно-параллельных вычислений. Часть II. TPC-DS;

• Тестирование движков массивно-параллельных вычислений: StarRocks, Trino, Spark. Spark – с DataFusion Comet и Impala;

• Бенчмарк бенчмарка Lakehouse-движков, в котором побеждает объективная реальность.

Приложение. Детализация времени работы запросов на увеличенном объеме данных