Недавно на хабре вышла статья с громким заголовком “Бенчмарк lakehouse-движков, часть 1: StarRocks и Doris падают под нагрузкой, Presto аутсайдер, CedrusData быстрее всех”. В своей статье авторы из Кверифай Лабс выбрали методику TPC-DS, но вместо 99 запросов остановилась на одном, который к тому же запускается на одной машине. Обосновывается это тем, что на одном конкретном запросе нужно разобрать работу оптимизаторов. По результатам исследования делается вывод, что решение, разработанное авторами, является лучшим, в том числе для запуска одного конкретного запроса на одном узле. Давайте попробуем разобраться, действительно ли это так.

В качестве отступления замечу, что данный эксперимент не имеет ничего общего с массивно-параллельными вычислениями и Lakehouse. Архитектура раздельных вычислений предполагает интенсивный сетевой обмен не только между storage и compute, но и между узлами compute-движка. Как заметили в комментариях к оригинальной статье, с тем же успехом можно было включить в тест и MySQL. Складывается впечатление, что методика тестирования была выбрана исключительно из-за заявленных компетенций в области оптимизатора движка, а запрос – исходя из наличия собственных доработок для обработки схожего случая. Главной же целью было на частном выводе убедить аудиторию в общем выводе. Отдадим должное коллегам – они не скрывают субъективность своего отношения к упражнению.

Разбираемся шаг за шагом

В начале статьи заявляется, что индивидуальный тюнинг выполняется только для StarRocks, так как его оптимизатор “не может выбрать оптимальный план”. Что такое тюнинг? Настройка адекватных параметров экземпляра, отличных от заданных по умолчанию? По моему мнению – нет. Когда устанавливаешь Oracle, PGA/SGA и другое множество параметров не остается в исходном состоянии. Когда Postgres с GreenPlum тестируются на НТ,  обычно принимается решение о параметрах отдельного worker’а, сессии, числе сегментов и так далее.

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

Однако не нужно забывать, что, согласно методике TPC-DS, сам запрос не может изменяться.

В Data Sapience мы всегда следуем данному правилу, включая и сегодняшние эксперименты.

“Старушка антилопа”

Начнем с Impala, которая у коллег сразу имеет “неоптимальный план”, “медленно работает с S3” и обладает “ненужным loopback”. Первое, на что мы обратили внимание, смотря схему плана запроса оригинальной статьи, – статистика: либо она не собрана, либо по тем или иным причинам не используется. Без сбора статистики план запроса получается именно таким, каким он и нарисован в статье. 

Если статистика собрана, то план “ванильной” Impala меняется на следующий:

Ожидаемо “неправильный порядок JOIN” пропадает, время работы сокращается почти в два раза до 33 секунд, а потребление памяти падает. Impala сразу врывается в лигу “StarRocks по версии Кверифай Лабс”.

Прикладываю профили и планы запросов ванильной Impala до сбора статистики и после сбора 

План запроса до сбора статистики

Профиль запроса до сбора статистики

План запроса после сбора статистики

Профиль запроса после сбора статистики

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

Удобство и разнообразие инструментов анализа работы кластера, запросов, ресурсных пулов, “эдн-поинтов” мониторинга заслуживают скорее отдельного большого обзорного материала. К тому же они продолжают постоянно развиваться с каждым релизом.

“Как эксперты в области оптимизатора запросов” коллеги, как мне кажется, должны понимать, как влияет отсутствие статистики и дефолтных параметров экземпляра в части работы оптимизатора на оптимальный план запроса и расчет резервирования ресурсов для его исполнения. Но объясняется в материале все довольно просто: Impala – “это legacy-продукт, многие компоненты которого имеют устаревшую архитектуру родом из 90-х”.

Вторая из обозначенных проблем Impala – отсутствие проброса фильтрации на правую ветку плана. Собственно, сам тейк справедливый. Ванильная OSS-сборка действительно так и работает. 

Но команде Data Sapience, предлагающей  “американские legacy-продукты, которые не способна доработать Cloudera”, есть, чем ответить. Тем более что по заявлениям коллег некоторые доработки требуют всего “пару дней рабочего времени квалифицированного инженера ”, а при наличии большой квалифицированной команды разработки это не является проблемой.

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

• Собственный AWS API C++ S3 Reader;

• Оптимизацию, связанную с трансформацией внешнего соединения и пробросом фильтрации в него (в данном случае применяется на store_returns).

Смотрим, что изменилось на плане:

Улучшения видно сразу. Фильтрация в правой ветке теперь работает, и чтение данных уменьшилось на порядок. Время работы запроса – 10,2 секунды.

План запрос Impala Data Sapience

Профиль запроса Impala Data Sapience

И антилопа прыгает прямо сюда

При прямых сравнениях с Greenplum нас постоянно спрашивают: почему наша Lakehouse-платформа данных Data Ocean Nova имеет производительность выше? Иронизируют даже, как вы, наверное, могли заметить в оригинальной публикации, на которую я ссылаюсь. Вот этот случай с Query1 – отличный пример, почему любой процессинговый движок в Data Ocean Nova производительнее, чем любая сборка Greenplum. Проанализируйте профиль запроса и посмотрите, какой объем данных движок вычитал. А потом попробуйте повторить такой же эксперимент с Greenplum. Больше у вас вопросов не возникнет. 

Доработки технологий, на которых вы основываете свои продуктовые решения, – это нормальная практика, и она не является эксклюзивной на рынке, как бы вас ни пытались в этом убедить. Наша рекомендация – требуйте у поставщика перечень изменений относительно open source! Вы должны быть уверены, что поставщик способен решить проблемы самостоятельно, а не просто заводить заявки в сообщество и ждать новой версии в репозитории в надежде на исправление или изменение. Если вам интересно узнать о наших изменениях и разработках относительно open source, то оставляйте свой запрос в комментариях к посту.

Перейдем к StarRocks

Все оказалось до банального просто. Дефолтные настройки экземпляра – 23 сек. Собрали статистику, изменили настройки и результаты улучшились до 7 сек. Кстати, на практике мы статистику не собираем, а научили StarRocks понимать внешнюю, которая уже хранится в метасторе и собрана заранее любым из других движков.

Профиль запроса

Таким образом, даже ванильный StarRocks у нас перемещается на первое место и опережает даже Impala от Data Sapience на 3 секунды.

Материализация CTE в нашем тесте была выключена

Подводим промежуточный итог

Конкурентная нагрузка 

Запустим теперь запрос в 16 одновременных сессий на одном узле.

Ничего не отвалилось. Все запросы добежали до конца. Время работы равномерное.

Разрыв между Impala и StarRocks вышел минимальный. Почему? Ведь в нашей недавней публикации те же самые compute-технологии показывали двукратную разницу! Просто тест на одном запросе как частном случае не раскрывает все особенности оптимизатора и движка.

Давайте проведем еще один эксперимент

Включим для Impala опцию, которая актуальна для MPP кластера, работающего с BI/ad-hoc/ROLAP нагрузкой, – кэширование сериализованных повторных чтений для внутреннего формата движка (не S3 read cache!). Такое кэширование работает даже для использования runtime-фильтров в разрезе запроса, чтобы исключить повторные чтения внутри одного запроса, и запустим многострадальный Query1 на одном узле в 16 потоков.

Получаем среднее время работы запроса – 125 секунд.

Профиль запроса

А можно еще лучше? Теперь включим расширение кеша на весь compute-кластер и получаем результат 85 секунд на 16-ти параллельных запросах! Причем этот кэш на локальном диске и не использует оперативную память как в StarRocks, следовательно, будет меньше влиять на пропускную способность системы, так как память в конкурентной нагрузке является самым ценным ресурсом. 

Профиль запроса

StarRocks посрамлен технологиями из 90-х? На самом деле, нет. Этот эксперимент просто в очередной раз показывает бессмысленность конкурентного теста с одним запросом. Именно поэтому в классическом TPC-DS при многопоточном тестировании запросы обязательно идут в разном порядке в параллельных потоках. Именно поэтому и в методике тестирования MPP, про которую я писал в  своей публикации, конкурентные одинаковые запросы читают разные диапазоны данных из объектов. При этом в наших тестых мы не использовали кэширование для достижения более красивых цифр, ведь наш тест – это не соревнование с конкурентами, а помощь в выборе движка под конкретную задачу внутри платформы.

Выводы

В своем материале коллеги из Кверифай Лабс приводят множество доводов, подтверждающих, что некоторые доработки легко выполнить и применить, но никто это не делает. Достается при этом и Presto, и Trino, и Impala. В случае с Presto такое поведение объясняется незаинтересованностью основного разработчика, по Trino комментариев политкорректно не дается, в части Impala объясняется тем, что Cloudera буквально забила на свой продукт. Причем Cloudera вообще подвергается стигматизации. По словам автора, это компания, которая “давно поставила крест на Impala — нет сообщества, нет документации”, “не способна сделать новый оптимизатор” (сама по себе миграция на Calcite – качественное улучшение в движке, но это далеко не значит, что текущий оптимизатор плох и неэффективен). Все эти тезисы легко опровергаются любым, кто способен пользоваться интернетом. Неужели предлагается просто поверить на слово? Откуда такая нелюбовь?

Как же дела обстоят на самом деле в мире open source?

• Trino контролируется и улучшается не сообществом, к наличию которого часто апеллируют при мотивации выбора Trino-based решения, а компанией Starburst, которая и финансирует Trino Foundation и принимает все решения;

• StarRocks де-факто контролируется даже не зонтичной Celerdata, созданной для ведения бизнеса во “внешнем мире”, а китайской материнской компанией, которая отгружает изменения в open source по мере своего видения, что, когда и в каком порядке выдавать;

• Impala контролируется и развивается частной компаний Cloudera;

• ClickHouse после выхода из Yandex продолжает контролироваться одной компанией – Clickhouse inc;

• Этот список можно долго продолжать.

Ни одно из этих решений не застраховано от “эффекта Greenplum”, при котором все красивые графики с числом изменений в OSS, наличием сообщества в телеграм-чате с 1 тыс подписчиков  в одночасье после закрытия исходного кода превратились в маркетинговый булшит и проблему конечного потребителя, которому обещали чудо.

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

Слова благодарности

На самом деле, мы очень благодарны коллегам за то, что они подняли тему “маркетингового булшита” в своем материале, и призываем всех так же скептически относится к заявлениям об ускорении в 40 раз. К сожалению, с уходом западных вендоров некоторые отечественные компании-разработчики продолжают грешить аналогичным образом: просто демонстрируя скриншоты тестов, скопированные с сайтов американских или китайских вендоров, в попытке убедить в своем превосходстве (а некоторые даже рассылают аналитические записки в виде pdf-документов с аналогичным посылом). Не дайте себя ввести в заблуждение и принимайте правильные решения, основанные не на эмоциях, а на фактах и самостоятельном системном анализе.