Привет! Сегодня я продолжаю тему сравнения систем и движков массивных параллельных вычислений. В прошлой публикации я раскрыл основные принципы проведения тестирования, которыми руководствуется наша команда, и привел результаты как реальных промышленных сценариев, так и синтетических тестов. Материал вызвал интерес и дискуссию: значит, он актуальный и полезный. Для кого-то факты стали убедительными, а кто-то усомнился в объективности результатов, поэтому, как и было обещано, я делюсь материалами сравнительного тестирования, выполненного по общепринятому стандарту TPC-DS. Сегодня вы узнаете, повлияла ли смена методики на результаты.

Введение

TPC-DS (Transaction Processing Performance Council – Decision Support) — это стандартный отраслевой эталон для измерения производительности систем поддержки принятия решений (Decision Support Systems, DSS). Проще говоря, это тест, который показывает, насколько хорошо та или иная система (например, база данных или платформа для больших данных) справляется со сложными аналитическими запросами в условиях, приближенных к реальным.

Данный стандарт разработан организацией Transaction Processing Performance Council (TPC) для оценки систем, работающих с большими объемами данных и выполняющих комплексные аналитические задачи. TPC-DS моделирует деятельность ритейл компании, включая продажи, запасы и маркетинг, и использует эту модель для генерации набора данных и запросов.

Ключевые характеристики TPC-DS

Реалистичный сценарий: Считается, что TPC-DS имитирует рабочую нагрузку аналитической системы, близкую к реальной. Это делает результаты теста более показательными для оценки поведения систем в промышленной эксплуатации.

Комплексные вариативные запросы: Методика включает 99 различных аналитических SQL-запросов, которые варьируются по сложности. Среди них есть запросы на создание отчетов, интерактивный анализ (OLAP) и задачи так называемого интеллектуального анализа данных (Data Mining). Эти запросы проверяют способность системы обрабатывать объединения таблиц, агрегации и фильтрацию данных.

Большой объем данных: TPC-DS может генерировать наборы данных различного масштаба — от нескольких гигабайт до сотен терабайт, что позволяет тестировать системы под различные настройки стендов с точки зрения адекватности соотношения исходного объема и аппаратных ресурсов экспериментального окружения.

Почему TPC-DS важна?

TPC-DS считается объективным и стандартизированным способом сравнения производительности различных платформ для анализа данных. Большинство поставщиков систем и баз данных используют результаты этого эталона для демонстрации возможностей своих продуктов. Вариативность SQL-запросов, входящих в стандарт, часто позволяет выявить сильные и слабые стороны не только самой системы, но и ее основных функциональных компонентов, таких как оптимизатор запросов, модуль расчета необходимых ресурсов (так называемый estimator) и так далее. Поэтому многие вендоры используют эталоны TPC-DS во внутренних тестах на отдельных запросах, например, прорабатывая стратегии оптимизатора или внося другие изменения в работу движка процессинга.

Чем распространеннее методика и чем большим количеством участников она поддерживается, тем больше она вызывает доверия.

Недостатки методики

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

Следующий недостаток, по моему мнению, заключается в том, что стандарт ориентирован больше на сценарии BI, ROLAP, adhoc, небольшой и средний ETL (относительно самого размера данных соответствующего scale-фактора), и меньше — на тяжелый ETL, для которого помимо сложности запроса еще характерна материализация результата работы.

Описание тестового окружения

• Испытания проводились в Яндекс Облаке

• Использовались managed-сервисы:

  • S3 Storage

  • Managed Kubernetes, в котором разворачивались compute-движки lakehouse-платформы

• TPC-DS scale-factor 10000 (~10 ТБ до сжатия)

• Генерация данных выполнялась через Spark

• Файловый формат parquet, сжатие ZSTD Compression Ratio 3, табличный формат Iceberg

• Целевой объем данных в сжатом виде ~2 ТБ

• Данные были секционированы

• Версия ядра Impala 4.5

• Версия ядра Trino 459

Все запросы запускались as is из методики без внесения изменений в текст запроса. Процессинговые движки настраивались на максимальную производительность и максимальную утилизацию всех доступных аппаратных ресурсов. Между разными итерациями система перезапускалась для сброса локального кэширования. Каждым движком индивидуально выполнялся сбор и анализ статистики.

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

Для worker-узлов использовалась следующая конфигурация: 32 vCores, 256 ГБ памяти, локальный 100 ГБ SSD-диск для spill и cache операций. Суммарно 4 worker-узла. Суммарное количество compute-ресурсов: 128 vCores, 1024 ГБ памяти. В случае Trino был еще выделенный узел координатора, но мы не будем учитывать его ресурсы. Impala прекрасно работает без выделенного координатора до определенной нагрузки, к которой, к слову, мы в данном тесте не приблизились.

Итерация 1

В первой итерации тестирования запускался однопоточный режим работы, при котором все 99 запросов выполняются последовательно. Результаты такого теста нельзя применять для оценки реальной производительности, но он полезен для первичной «пристрелки», устранения шероховатостей настройки.

Полная таблица со всеми запросами по порядку приведена в конце статьи. Для удобства анализа разобьем запросы на три группы: «Простые запросы», которые исполняются до 10 секунд, «Средние» — от 10 до 100 секунд, «Тяжелые» — работающие свыше 100 секунд.
 

Таблица. Время работы “Простые запросы”

Таблица. Запросы “средней сложности”

 Таблица. “Сложные” запросы.

Таблица. Оценка эффективности

Стоимость вычислений определялась по калькулятору Яндекс.Облака как стоимость аренды четырех compute-узлов / 30 дней / 3600 сек * на время длительности теста в секундах. Выделенный координатор Trino в расчете стоимости не учитывался.

Итерация 2

Результаты получены. Можно ли подводить итоги? Конечно, нет. Следуя своим же принципам, мы делаем выводы только на основе сценариев, приближенных к промышленной эксплуатации — конкурентная нагрузка. Для второй итерации мы провели испытания TPC-DS в два потока, которые запускаются одновременно. Потоки и порядок SQL-запросов формировались в соответствии с описанием в методике. Основная идея, заложенная в ней, — запросы в потоках должны запускаться так, чтобы симулировалась работа пользователей, исполняющих разные запросы над различными данными, а не выполнялся один и тот же запрос одновременно, но в нескольких сессиях.

Общее время прохождения теста определялось как разница от начала выполнения теста до времени завершения работы самого последнего запроса в двух потоках обработки. Так как оба движка функционировали в условиях конкурентной нагрузки, то для такой задачи в несколько итераций запуска подбирались оптимальные ресурсные очереди и параметры кластеров, чтобы тест выполнялся минимальное время при отсутствии отказов и падений хотя бы одного запроса из 198. Если регистрировалось падение хотя бы одного запроса, то результат не засчитывался и продолжалась настройка устойчивой конфигурации. Для Trino выполнялась тонкая настройка параметров retry_policy, query_max_total_memory, query_max_memory_per_node, query_max_memory в нескольких итерациях. Вычислительные мощности compute-кластера не изменялись и были такими же, как в испытаниях в 1 поток. Для Impala использовались настройки - mem_limit, mt_dop.

Таблица. Оценка эффективности. 2 потока 

С увеличением нагрузки движки повели себя по разному. У Impala мы наблюдаем деградацию примерно в два раза, Trino же — в 2,7 раза относительно теста в 1 поток.

Итерация 3.

Продолжаем увеличивать нагрузку на систему и выполняем тестирование в 4 потока на той же конфигурации оборудования. На входе системе подается 396 запросов. Действуют те же принципы фиксации результата - тест считается пройденным только в том случае, если все 396 запросов выполняются без ошибок и падений.

Таблица. Оценка эффективности. 4 потока 

Impala деградирует пропорционально нагрузке в 4 раза,  Trino уже в 8 раз.

Давайте попробуем представить, что наш кластер вычислений должен регламентно выполнять этот объем работы в течение года - ровно 365 запусков по одной итерации раз в день. Какая будет накопленная стоимость вычислений?

Разница: ~ 4 млн 307 тыс руб. на обработке 10 Тб RAW данных на четырех compute-узлах. Теперь мысленно представьте, какая будет разница если данных будет 100 Тб, а число узлов будет 40.

А что же GreenPlum?

С движками lakehouse-платформы разобрались, теперь дошла очередь и до GreenPlum. Но для начала нам нужно пересобрать стенд, ведь GreenPlum — это традиционная shared-nothing MPP система, размещаемая не поверх объектного хранилища, а на выделенных локальных дисках. Для объективного сравнения, все сервисы lakehouse-системы тоже должны быть размещены без использования облачных сервисов. Так будет честнее и более приближено к реальности on-premise инсталляции. 

Таблица. Аппаратное обеспечение GreenPlum

Второй мастер GreenPlum для теста НТ нам не нужен. В расчетах он все равно участия не принимает, а деньги тратит.

Таблица. Аппаратное обеспечение Data Ocean Nova

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

Data Ocean Nova была установлена на виртуальной инфраструктуре ЯО по схеме decoupled-архитектуры: изолированный кластер S3 на базе MinIO и изолированный compute-кластер, в котором была развернута Impala 4.4.1. Главное, чтобы число и тип дисков, используемых для подсистемы хранения, точно совпадали, и чтобы эти диски были наиболее производительными из всех, которые способен предоставить облачный оператор. GreenPlum был развернут на виртуальных машинах ЯО также с использованием высокопроизводительных дисковых накопителей.

Параметры теста:

• TPC-DS scale-factor 10000 (~10 Tb несжатых данных)

• GreenPlum настраивался на максимальную производительность

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

  • Настройка ресурсного менеджмента на конкурентную работу

• Для Impala данные, как и в предыдущих тестах, были в формате parquet + iceberg с компрессией ZSTD

Условия успешности прохождения теста не менялись: при нагрузке в 1 поток все 99 запросов должны успешно завершиться, при режиме запуска в четыре потока - 396 запросов должны завершиться без ошибок и падений.

Таблица. Результаты тестирования.

Стоимость вычислений определена по той же методике: стоимость аренды узлов IaaS в Яндекс.Облака (открытый прайс лист) в течение месяца / 30 дней / 24 часа / 3600 сек * длительность расчета сек 

В очередной раз на практике мы убеждаемся, что lakehouse-система Data Ocean Nova, даже с физическим разделением хранения и вычислений, с точки зрения стоимости показывает себя как минимум в 6 раз эффективнее, чем GreenPlum. Перевод производительности в стоимость демонстрирует разницу в стоимости владения такой системой с точки зрения капитальных затрат на оборудование. В реальности различие будет еще выше, так как поддержка и лицензионное обеспечение являются производными от аппаратного сайзинга. Да и эксплуатационные расходы такой системы тоже будут кратно больше. Она ведь и места в ЦОДе занимает значительно больше, и энергопотребление имеет высокое. MPP-системы, работающие по принципу full table scan, к сожалению, безнадежно устарели десятилетие назад.

Теперь давайте сравним по той же методике стоимость вычислений в течение года. Представим, что наш compute-кластер должен регламентно выполнять этот объем работы в течение 12 месяцев — ровно 365 запусков. Какая будет накопленная стоимость вычислений?

Разница: ~ 16 млн 807 тыс руб.  

Разница выглядит ощутимо, но что она дает? Можно сэкономить 16.8 млн рублей от общего бюджета  на ФОТ (фонд оплаты труда) на Data-команду всего-то на обработке 10 ТБ данных, и это на маленьком кластере в 4 узла, который позволит получить больший объем функционала и с попаданием в сроки. 

Пользуясь случаем, анонсирую масштабный интересный материал по нагрузочному тестированию GreenPlum 6.X, GreenPlum 7.X и Cloudberry, которое провели мои коллеги, и совсем скоро его опубликуют. Обещаю, что там будет много интересного, например ответ на вопрос — можно ли взбодрить технологию шардированного Postgres, просто добавив новые features вроде BRIN-индекса или подняв версию ядра Postgres.

Какие еще общепринятые методики тестирования есть и стоит ли на них ориентироваться?

Какие другие открытые методики тестирования можно использовать для задачи конкурентного нагрузочного тестирования кроме TPC-DS? Один из вариантов — TPC-H. Но, несмотря на то что методика TPC-H также предназначена для проверки аналитических систем, она имеет ряд недостатков по сравнению с TPC-DS:

• Более простая модель данных: 

  • Использует простую «звезду» с меньшим количеством таблиц, а не «снежинку», как TPC-DS

• Ограниченное количество запросов: 

  • Содержит всего 22 запроса, которые, хотя и являются аналитическими, менее сложны и разнообразны по сравнению с TPC-DS

• Меньшие требования к оптимизатору: 

  • Считается, что TPC-H менее требователен к оптимизатору из-за относительной простоты запросов, поэтому может не в полной мере раскрыть возможности сложных оптимизаторов запросов в современных MPP-системах

В последнее время мне часто встречаются сравнительные результаты тестирования систем и движков по методике ClickBench. Это собственный тест производительности, разработанный командой ClickHouse. Он использует реальный набор данных и относительно простые запросы, характерные для области применения ClickHouse.

ClickBench очень хорош для оценки производительности ClickHouse в сценариях, для которых он изначально создавался — быстрый доступ к данным с фильтрацией и агрегацией в рамках одного объекта. Но тесты ClickBench не рекомендуется использовать для выбора основного движка платформы. На 42 SQL-запроса нет ни одного хотя бы с одним соединением (JOIN)!

Дальнейшие планы по тестированию

Сейчас мы проводим тестирование процессингового движка StarRocks, также входящего в нашу платформу данных Data Ocean Nova. Кроме того, мы планируем провести тестирование и сравнение Spark 4 vs Spark 3.5 и их производительности относительно других MPP SQL-движков lakehouse-платформы в задачах ELT-pipeline.

Дополнительно мы прорабатываем методику объективного нагрузочного тестирования движков в задаче «быстрого доступа к материализованной витрине данных на чтение». Если у вас есть идеи, то предлагайте!

Обращение к читателям и сообществу

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

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

Телеграм канал Data Sapience

Справка о продукте: 

Data Ocean Nova – универсальная Lakehouse-платформа данных нового поколения, представленная вендором Data Sapience. Продукт решает комплексные задачи массивно-параллельной обработки данных. В том числе позволяет создавать и масштабировать оперативные слои данных в реальном времени, бесшовно работать с CRM- и ML-платформами, предоставлять федеративный доступ к базам данных и выступает в качестве виртуального хранилища. Поддерживает on-premise инсталляцию, частное облако и гибридный сценарий использования, а также Multi-tenant развертывание для создания изолированных сред на базе общей инфраструктуры.

К преимуществам решения относятся: объединение подходов Data Warehouse и Data Lake при реализации аналитического хранилища; лучшая производительность на рынке при сравнительно низкой стоимости владения; возможность не переплачивать за «избыточные» мощности при росте данных или из-за устаревших технологий; низкий порог входа для пользователей и совместимость с прикладными системами, такими как Business Intelligence, MLOps, аналитический CRM, MDX\OLAP, ODBC\JDBC\ADBC клиентские приложения, Data Governance решения; встроенные процессы автоматического обслуживания данных; AI-функционал помощи разработчику и администратору.

Справка о компании: 

Data Sapience — российский вендор, разработчик ИТ-решений для бизнеса. Входит в группу компаний GlowByte. Разработкой продуктов занимается команда с 15-летним опытом работы в консалтинге и с ведущими вендорами. Продукты организации состоят в Реестре отечественного ПО: CM Ocean – платформа CVM-маркетинга; TALYS Ocean – платформа интегрированного управления рисками; Kolmogorov AI — платформа аналитики данных, машинного обучения и MLOps; Data Ocean Governance – платформа управления данными организации; Data Ocean – универсальная Lakehouse-платформа данных.

Приложение

Таблица: Время работы запросов TPC-DS. 1 поток. В соответствии с порядком запроса в методике.