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

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

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

• Область применения системы/движка и роль в ландшафте Не бывает хороших или плохих систем как таковых.  . Какие-то — лучше проявляют себя в конкурентном BI-доступе или сложном ad-hoc, какие-то — в задачах сложной последовательной трансформации данных, какие-то — хорошо справляются со всеми задачами современного хранилища или озера данных.

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

• Получение метрик для прогнозирования целевого сайзинга системы

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

Ставя цели, мы предъявляем требования к методике тестирования. Я предлагаю обсуждать методику от обратного: определить признаки плохого подхода к тестированию.

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

• Объем тестового набора данных в несколько раз меньше, чем суммарный объем оперативной памяти системы;

• Тестовые запросы выполняются по очереди: запустил запрос, записал в excel-таблицу результат, перешел к следующему и повторил действия;

• Одни и те же тестовые запросы запускаются без изменяемых параметров и без предварительного сброса результирующего кэша или кэша файловой системы;

• Физическая модель подготавливается заранее под согласованный ограниченный набор тестовых запросов (индексы/проекции/сортировки под конкретные запросы);

• Операторы выборки используются без операторов записи (только select без insert/create);

Указанные признаки должны вас насторожить. Есть ли тут непонимание требований, которые предъявляются к современной аналитической системе в реальном использовании в продуктивной эксплуатации, или это преднамеренная манипуляция вендора и интегратора?

Признаки хорошего тестирования:

• Объем тестового набора данных в несколько раз больше суммарного объема оперативной памяти. Идеальное соотношение памяти и набора данных – не менее, чем 1 к 5;

• Как минимум одна из итераций тестирования проводится без оптимизации физической модели данных под конкретные запросы;

• Тестирование проходит в режиме конкурентной нагрузки. Несколько разноплановых запросов запускаются одновременно, либо один и тот же запрос запускается группой с разными предикатами, чтобы исключить чтение кэша. Сам кэш сбрасывается перед каждой итерацией;

• “Zerg Rush” – десятки и сотни разнородных запросов поступают одновременно или группами в течение длительного периода времени.

Почему мы предъявляем такие требования?

Во время реальной эксплуатации система всегда очень нагружена. Зачастую она обрабатывает десятки или даже сотни запросов одновременно и это не обязательно только DML запросы и уж точно не только SELECT. Часто даже статистика может быть не собрана совсем, собрана частично или “сэмплированно” (поэтому я иногда рекомендую проводить и отдельные дополнительные итерации без статистики или на разряженном фрагментированном наборе данных, который “забыли” обслужить). Неверно проводить испытания только в тепличных условиях “овертюнинга” который в продуктивной среде зачастую недостижим.

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

Необходимо исходить из максимально неблагоприятного сценария, когда никто заранее не построил индексы, проекции, материализованные представления, не отсортировал данные. Проектирование дополнительных структур всегда несет накладные расходы в объеме, во времени записи в таблицу и требует дополнительных навыков проектирования. Если ставится цель – проверить техники оптимизации, то лучше планировать две итерации тестирования: первую – до оптимизации ФМД, вторую – с оптимизацией ФМД и обязательной фиксацией накладных расходов. Ведь всегда приходится платить за выигрыш в производительности на конкретных запросах и проверять, насколько замедлились операции записи данных или насколько вырос объем данных за счет создания дополнительных структур и т. д.

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

Выбор методики 

Релевантность методики должна исходить из клиентских сценариев и данных. 

Вариант 1. Реальные данные клиента достаточного объема с вариативным набором запросов – самое лучшее, что можно предложить. Но главная проблема в том, что часто заказчик не может предоставить такой набор данных необходимого объема или у него в моменте нет достаточной вариативности запросов и сценариев тестирования.

Вариант 2. Использование открытой методики тестирования. К таким можно отнести, например, TPC-DS или TPC-H. Обе методики подходят, но важно адаптировать их под свои релевантные сценарии. Нужно помнить, что неверно делать выводы о системе, запустив все 99 запросов TPC-DS по очереди и зафиксировав результат. Изначально тот же TPC-DS был придуман как функциональный тест проверки ANSI SQL совместимости: “запустится ли запрос без переписывания”. Если по какой-то причине предложенные методики не подходят (например, не соответствуют характеру бизнеса или предметной области), можно разработать свою методику. Главное, чтобы она соответствовала критериям и целям.

Вариант 3. Комбинирование варианта 1 и варианта 2 для добавления сценариев тестирования, которые в настоящий момент заказчик не может предоставить на своих данных.

Давайте попробуем составить план идеального тестирования. Последовательность действий:

• Сгенерировать набор тестовых данных в объеме (при отсутствии продуктивного репрезентативного), превышающем суммарный объем оперативной памяти (желательно раз в 5);

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

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

• Настроить систему на режим конкурентной работы;

• Замерить время выполнения сценариев и при необходимости вывести показатель “среднее число запросов в час или другую единицу времени”;

• Дополнительно можно разбавить методику решением различных аналитических задач или построением материализованных витрин данных;

• Составить протокол по результатам.

Во время проведения испытаний нужно фиксировать утилизацию аппаратных ресурсов. Это пригодится для проектирования целевого сайзинга. Необходимо понимать, к каким ресурсам решение требовательно: все системы и движки ввиду различий в архитектуре требуют разных аппаратных ресурсов. Без анализа утилизации невозможно сделать вывод: насколько эффективно и какие именно ресурсы потребляются, какие “узкие горлышки” есть или могут быть в целевом решении и самое главное: настроена ли система в данной итерации теста на максимальную пропускную способность или из нее еще можно выжать дополнительные соки. Без этого знания невозможно спрогнозировать подходящий целевой сайзинг. Правильный сайзинг гарантирует ожидаемую производительность с поправкой на рост и обеспечивает оптимальные затраты на оборудование и лицензионное обеспечение, которое очень часто является производной от метрик оборудования.

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

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

• какие запросы и операторы благоприятны для движка, а какие могут вызывать проблемы;

• какие алгоритмы сжатия применялись и какую степень сжатия продемонстрировали относительно сырых данных (это ведь тоже влияет на сайзинг и расчет стоимости владения).

При проведении повторных итераций с оптимизацией ФМД нужно не забыть зафиксировать в протоколе, какой объем на дисковой подсистеме занимают оптимизированные структуры и какое влияние они оказывают на скорость записи данных.

Сравнение результатов

Если используется одинаковое оборудование, выделенное для системы, сравнить  результаты просто. Сухие цифры и ничего кроме. А что делать, если  системы тестировались на разном аппаратном окружении или имеют настолько разный архитектурный подход что были установлены на разном типе оборудования и в разной топологии? Или если тесты проводились в облачном окружении? В этом случае правильно вводить показатель стоимости вычислений: сколько в денежном эквиваленте стоит выполнение сценария (или прохождение всего теста от начала до конца). В облаке данные цифры получить очень просто, применив данные биллинга или облачный калькулятор который предоставляет каждый провайдер. Провайдер в биллинг закладывает все расходы, которые могут быть не очевидны на первый взгляд , и поэтому такое сравнение самое точное и честное.

В on-premise окружении такой расчет можно будет сделать, только если знать закупочную и эксплуатационную стоимости оборудования или отдельного вычислительного кванта оборудования (для инфраструктуры частного облака часто вводится такая метрика для аллокации расходов на потребителей внутри предприятия).

Сравнительное тестирование производительности Trino и Impala

Разобравшись с теорией, пора переходить к практике и результатам. В платформе данных Data Ocean Nova есть два процессинговых SQL-движка: Impala и Trino. Два часто задаваемых вопроса на которые мне приходится отвечать в рамках клиентских активностей — “почему у вас два движка” и “какой из них быстрее”. На первый я отвечал в предыдущей публикации, поэтому давайте сосредоточимся на втором. Ознакомимся с результатами внутреннего тестирования. 

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

• Облачное окружение c managed k8s и managed s3;

• Движки запускаются на идентичных k8s worker машинах с одинаковыми параметрами;

• Данные загружены в managed s3;

• Оба движка настроены на максимальную пропускную способность (ресурсные очереди, тюнинг параметров для максимальной утилизации ресурсов, настраиваемый параллелизм для каждого сценария, проверка планов запроса и так далее);

• Для trino не использовался fault-tolerance режим, чтобы облегчить ему работу по общению с s3.

Методика

• Синтетический набор данных ≈ 16Tb объема из банковской предметной области, модель “снежинка”;

• Выбираются типовые запросы, характерные для различных задач в области исследования данных и построения аналитических слоев и витрин;

• Запросы, возвращающие большие наборы данных, работают с материализацией результата;

• Все запросы запускаются с конкурентностью 10, при этом набор предикатов подобран таким образом, чтобы каждый запрос в группе читал свой диапазон (для исключения кэширования);

• Сценарии запускаются с применением jmeter, где фиксируется максимальное, минимальное и среднее время в группе;

• Отдельно реализуется сценарий, при котором все запросы из всех групп запускаются в 10 и 20 сессий каждый, создавая нагрузку в 90 и соответственно 180 одномоментных запросов.

Методика была разработана нашим клиентом совместно с одним из вендоров лет 8 назад и хорошо себя зарекомендовала для use case сценариев проверки решения задач аналитического хранилища данных. Методика может быть предоставлена по запросу, если для вас она представляет интерес.

Среди общей картины выбиваются результаты 9-го запроса и он вызывает отдельный интерес. Детально изучив профили запросов, мы пришли к выводу, что в этом запросе Impala, предварительно выбрав диапазон сканирования файлов и блоков при min/max фильтрации на уровне parquet файлов / row groups / pages, при фильтрации на уровне страничных индексов (page indices) выполняет в два раза больше чтений чем Trino, который также использует те же min/max фильтрации по страницам. Причины такого поведения мы на текущий момент исследуем в режиме отладки и рассчитываем поправить.

Давайте попробуем переложить результаты в метрики пропускной способности и стоимостной эффективности. Для этого сравнения используем сценарий запуска 90 и 180 одномоментных запросов.

Стоимость конфигурации рассчитана с помощью биллинг-калькулятора облачного оператора. В данном примере сравнение в деньгах является более честным и показательным, так как мы использовали разные типы и количество K8S worker машин. Пропускная способность же является метрикой только конкретного движка на конкретной конфигурации.

Ниже – пример аналогичного теста в клиентском on-premise окружении. Оба движка были в равных условиях. Набор тестовых данных был увеличен в два раза, до 32 Тб. В качестве S3 используется minIO. Подробнее об окружении можно узнать в видеодокладе (там много интересного, например, про minIO и его метрики производительности). Использовались более свежие версии движков относительно предыдущего тестирования в облаке.

В большинстве сценариев Impala демонстрирует лучшую производительность и пропускную способность. Может, все дело в методике, запросах, данных? 

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

Тестирование проводилось в инфраструктуре частного облака заказчика. Использовались реальные продуктивные данные из области retail. Все запросы для сценариев формировались BI-инструментом,поэтому в соответствии с условиями испытаний запросы запускались без каких-либо изменений (если уж план кривой или хочется подкинуть хинт, то, увы, не получится). Данные были в благоприятном для движков формате хранения iceberg parquet zstd compression level 3. Оба движка были настроены на максимальную производительность (оптимальный внутриузловой параллелизм, максимальное использование выделенных ресурсов compute кластера). Для trino был выключен режим fault-tolerance (благоприятная ситуация для движка с точки зрения производительности). 

Опыт реальной эксплуатации и тестирования обоих движков показал, что в задачах высокой конкурентности и там, где требуется максимальная утилизация всех имеющихся ресурсов, Impala эффективнее, чем Trino – антилопа обгоняет зайца. Причина в том, что Trino: 

• имеет более высокие накладные расходы как java-приложение, исполняемое в среде JVM. На одном и том же узле Impala будет устойчиво работать при выделенных 90% оперативной памяти, а Trino придется либо сильнее ограничивать конкурентность за счет очереди, либо отрезать ресурсы вплоть до 70% от имеющейся памяти, если хотим получить стабильную работу – это все сказывается негативно на пропускной способности;

• расходует большей оперативной памяти по сравнению с Impala что проявляется как недостаток только при конкурентном доступе

• обладает скорее декларативным ресурсным менеджментом (формально есть, вроде как работает, но под высокой нагрузкой “пробивает” как собственные настройки ресурсной группы, так и лимиты JVM в среде, которой работает).

Все эти факты не отменяют того, что Trino – хороший современный производительный процессинговый SQL-движок, поддерживающий еще и функцию федеративного доступа (у Impala пока федеративный доступ в зачаточном состоянии и поддерживает мало источников). Поэтому Trino входит в состав Data Ocean Nova, и наша команда вносит в него доработки для соответствия общим требованиям, особенно в области информационной безопасности и производительности.  

Да Impala в настоящий момент быстрее, но мы работаем и над Trino на предмет использования native execution для попытки приблизиться к результатам Impala, и над самим движком Impala, меняя на собственные C++ разработки вместо родного legacy java hadoop взаимодействия с S3. Следите за обновлениями.

Сравнение Trino и Impala с GreenPlum

А теперь давайте сравним наши движки с другим популярным на рынке решением – GreenPlum – и посмотрим полный протокол тестирования со всеми участниками.

Lakehouse-решение Data Ocean Nova и на движке Trino, и на Impala в виртуальной инфраструктуре частного облака демонстрирует производительность, сопоставимую с GreenPlum, который имеет на порядок больше аппаратных ресурсов: 45 “железных” сегмент-серверов с дисковой подсистемой, состоящей суммарно из 900 SSD дисков с сетевой связностью 100 Гб/с и объемом оперативной памяти, сопоставимым со всем объемом dataset’а. Решение на GreenPlum, разумеется, спроектировано максимально оптимальным и производительным (равномерный ключ распределения, колокация соединений, секционирование, нужные значения памяти на запрос, отсутствие spill-ов, ресурсные очереди и прочие доступные техники),так как используется в промышленной эксплуатации. Замер в GreenPlum проводился в рамках регулярной (ежедневной) ETL-нагрузки, при которой расчет указанных в тесте витрин утилизирует 80% ресурсов кластера. Но сравнение наглядно показывает, насколько legacy-подход в архитектуре массивных вычислений устарел. Системы вроде GreenPlum, работающие на fullscan-операциях и не имеющие современных оптимизационных техник, вроде динамической bloom-фильтрации, фильтрации с применением двухуровневых storage-индексов, крайне неэффективно используют свои аппаратные мощности и проигрывают современным архитектурам и процессинговым движкам. Показатель “Производительность на стоимость” GreenPlum относительно SQL MPP Lakehouse выглядит  не конкурентным.

Планы на будущее

Приведенные мной результаты тестирования могут не совпадать с вашим мнением или вашим опытом. Если вы не согласны с выводами и наблюдениями, то приглашайте, будем разбираться, проверять вместе с вами, ведь самое лучше тестирование – то, которое вы выполните сами с привлечением экспертов. Тут главное с выбором экспертов не ошибиться.

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

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

• Разбавить TPC-DS сценариями конкурентной нагрузки и сценариями, характерными для задач ETL pipeline обработки вроде массовых DDL-операций (это будет еще и хорошим тестом для мета каталога);

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

• Продемонстрировать производительность третьего SQL MPP процессингового движка, который есть в превью режиме в Data Ocean Nova, относительно Trino и Impala;

• Продолжить прокачивать доработками Trino и Impala в части производительности и делиться результатами.

Наши принципы работы:  

• до клиентов должны доходить только проверенные решения;

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

Предыдущие публикации

• Современная Lakehouse-платформа данных Data Ocean Nova

*****

Lakehouse-платформа данных Data Ocean Nova разработана Data Sapience (входит в группу компаний GlowByte).