Комментарии 8
Генерация данных выполнялась через Spark
Если у вас есть Spark, то что же его в тест не включили?
Так написал же что сделаем. И Starrocks и Spark. Все в порядке приоритета. Тестирование даже одного движка занимает достаточно много времени, если делать хорошо. Плюс тестированием каждого движка занимается команда этого движка (с привлечением экспертов из консалтинга), а у нее в приоритете, как правило, продуктовые задачи развития и по многим задачам есть срок контрактных обязательств.
Когда сделаем, то фактуру все равно общую дадим общего сравнение чтобы все было в "одной табличке"
У нас импала в проде, ваша синтетика не валидна. Проблемы импалы
1 - не шерит памят между воркерами, трино шерит.
2 - проблема с обновлением метаданных, валит хайв метастор через листерн
3 - залипают дискрипторы, что приводит к зависанию импалы, нужно каждый день перезагружать
4 - драйвера ограничены, только от клоудеры
5 - проблемы с Кириллицей
6 - из-за того, что не шерит память сильно просидает из-за перекосов
а у вас какая-то синтетика, в реальности ваши секунды никому не нужны, нужен стабильный движок и трино отлично с этим справляется.
У меня для вас плохие новости - у нас не ванильная импала. В ней нет проблем о которых вы пишете. Также как у нас и не ванильный HMS и не ванильный каталог импалы, отсутствуют проблемы с кириллицей и очень много других доработок в том числе с кэшированим (наверное про все доработки нужно сделать отдельную публикацию). Но на результаты конкретно TPC-DS они не влияют. В своих внутренних продуктовых тестах мы в том числе проводим НТ на DDL операции и работу каталога.
В целом складывается интересная ситуация - я публикую кейсы работы с промышленными данными в ответ получаю - вы все подстроили , покажите TPC-DS. Показываю TPC-DS - это все синтетика в реальности все не так.
Вы собственно можете верить во все что угодно, но для начала предметного диалога вы можете выложить свое тестирование по TPC-DS в которой ваш Trino пройдет в 2 или 4 потока на указанном объеме ресурсов без падений, и с цифрами близкими к этим, а желательно лучше, а потом можем поговорим про реальность.
Если вы заметили, то по тексту я заранее предупреждаю что выбор остается за пользователем что ему решать что использовать Impala, Trino, StarRocks или Spark. Есть хорошая область применения и сценарии, где Trino отлично справляется и часть наших клиентов сознательно выбирают этот движок, а Impala даже не устанавливают. Задача поставщика - не рассказывать про серебряную пулю (которой ни является ни Impala, ни Starrocks, ни Trino), а правильно сформировать ожидания, что в некоторых сценариях, придется, например, иметь больше одного кластера Trino (под разные группы нагрузки), или объем оперативной памяти для k8s worker'ов нужен бОльший и тд.
PS
Я кстати понимаю, могут быть фантомные боли Impala 2.Х или 3.Х где при очень большой нагрузке (десятки и стони тысяч запросов в сутки) такие проблемы были и остаются тк достаточно много инсталляций CDH и CDP живут в той же РФ без поддержки. Сам через это проходил. Но, даже не внося изменения в код, а делая тонкий тюнинг HMS, делая выделенный координатор или группы координаторов и другие трюки, большинство эксплуатационных проблем решаются в той же 3й версии. Поэтому мне очень интересно будет если вы опишите свой опыт. Вдруг это оракловый BDA с весьма странным выбором под СУБД HMS, странной компоновкой мастер узлов в стойке и тд.
У меня для вас тоже плохие новости - у нас не ванильная импала и dwh на ПТ и проблемы у вас точно такие же. Хабр это не про пресейл, Хабр это про то как вы решили трудную проблему и потратили много времени на исследование и решение. Читать как летают sql-движки абсолютно никому не интересно. Интересно проблемы в проде и как их решили.
Доброго дня. А есть детальная а не агрегированная таблица по сравнению скоростей запросов Impala и Greenplum? Хочется понять где такая разница возникает, всё таки в 6 раз медленнее.
в предыдущей части статьи написал "Системы вроде GreenPlum, работающие на fullscan-операциях и не имеющие современных оптимизационных техник, вроде динамической bloom-фильтрации, фильтрации с применением двухуровневых storage-индексов, крайне неэффективно используют свои аппаратные мощности и проигрывают современным архитектурам и процессинговым движкам. "
и из другой моей статьи "очень селективные чтения за счет использования встроенных в формат Parquet storage и page индексов; активная фильтрация данных на этапе чтения (bloom фильтры, динамические фильтры); управляемый внутриузловой параллелизм (несколько потоков обработки на одном узле для одного оператора). "
Вот ничего это у GreenPlum нет. BockRange индексы (BRIN) обещали еще в 2019г. По факту подвезли только в 2023. На деле оказалось ни о чем с тз производительности и накладных расходов.
В итоге получается что там где Trino, Starrocks или Impala будут читать условно 100Мб с диска, Greenplum будет читать опять таки условно 2Гб. И чем больше условий в join и where будет, тем быстрее современные движки работают относительно full scan движков тк зафильтруют данные до чтения в не после.
Тестирование систем и движков массивно-параллельных вычислений. Часть II. TPC-DS