Комментарии 20
Слежу за вашей эпопеей, видео и статьи очень интересные. Есть чему поучиться.
Спасибо, что делитесь знаниями!
А что по формату данных?
Дельта Лейк, айсберг или просто паркеты?
Во второй главе статьи про это как раз написано "Основной формат хранения у нас – Hive, хотя мы активно используем и Iceberg". Формат файлов мы используем ORC (почему – в предыдущей статье https://habr.com/ru/companies/avito/articles/979836/)
Добрый день, заинтересовало 2 момента:
Почему именно Trino? Не вижу (Spark вижу, даже StarRocks вижу) в ваших материалАХ обзора Impala (вычислительная часть которой на быстрых сях в отличии от более медленной trino-джавы)?
Что за гиперкубы? У вас не описано, в интернете не гуглится (не вижу)
Производительность движка в первую очередь определяется не языком программирования, на котором он написан. Его архитектура и реализованные оптимизации играют куда более важную роль.
"Медленная джава" – это всего лишь предубеждение. Мы видим своими глазами, как трино работает не хуже вертики, а где-то и превосходит ее, хотя она написана на "быстрых сях".
Выбирая движок, мы в первую очередь смотрели современные, активно развивающиеся и активно применяемые в мировых биг техах решения. Мы искали решение, которое сможем развивать своими силами – на наших масштабах работающих "коробок" не существует.
Trino/Presto используют и активно развивают все топовые биг техи мира. Он показал себя отлично на тестах. Он отлично показывает себя в продакшне на наших масштабах. Все изначально обозначенные проблемы уже решены.речь про платформу аб-тестов и метрик – https://trisigma.io/
она расчитывает классические olap-кубы с десятками разрезов – 30+ млрд метрик в день. подробнее можно посмотреть тут: https://youtu.be/wsjVP2nNpsM?si=dGpwORzO_ImwrmW_
Вот примеры статей с бенчмарками: trino (имхо ожидаемо) самый медленный из ряда вариантов включающих StarRocks, Impala, Spark:
(то что трино быстрее вертики - это скорее камень в сторону вертики, чем бонус в сторону трино)
Ну, минус StarRocks мне понятен - современный подход - это S3 + Engine, а старрокс это СУБД которой года 4 (слишком молодая) да еще и основанный на устаревшем подходе локального хранения, от которого уже и ClickHouse открестился (см ClickHouse Cloud - причем в открытый доступ SharedMergeTree эти «добрые» люди не выкатили)
Но я также спросил у вас, почему вы (например в вашей прошлой статье: https://habr.com/ru/companies/avito/articles/979836/) вообще не анализировали Impala? Без Impala бенчмарк совсем непоказательный выходит (имхо)
любые синтетические бенчмарки (tpc-ds и тп) имеют мало общего с реальностью. они примерно как тест на IQ – показывают как хорошо движок проходит тест =)
мы тестировали запросы типичные в нашем окружении с нашей спецификой. в статье даже есть дисклеймер: "Тестирование проводилось в 2022 году и отражает состояние технологий и экосистем на тот момент, а также наш конкретный юзкейс. Результаты не являются универсальной рекомендацией и, разумеется, не являются публичной офертой."
что касается Impala, он не подходил под наши критерии, о которых я написал выше – "современные, активно развивающиеся и активно применяемые в мировых биг техах решения", "которое сможем развивать своими силами"
Про бенчмарки я согласен, что это не панацея, спору нет, я поэтому сейчас «прикопался» к вам)
Вот очень интересно, чем именно не подошла Impala:
Не современная?
Не активно применяется в мировых бигтехах?
Не можете развивать своими силами? (Почему?)
Может вы просто не подумали об Impala на тот момент - это вполне понятная история. ClickHouse в свое время вот не подумали об HDFS/S3 (https://habr.com/ru/articles/509540/) и собрали свой велосипед-локальное-хранилище с ReplicatedMergeTree (в последствии уперлись в потолок и перешли на S3: https://clickhouse.com/blog/clickhouse-cloud-boosts-performance-with-sharedmergetree-and-lightweight-updates)
Мы просто сейчас сами выбираем движок, поэтому так докапываюсь. Минусы Java - это не предубеждения, у нее есть масса фундаментальной проблематики которая мешает написанию качественного низкоуровневого движка/СУБД: проблемы интеграции assembler, кривая интеграция SIMD, перегруз ООП-стактрейсом, да и вообще от этого языка не просто так отпочковались Scala/Kotlin, и прочая проблематика связанная с JVM/Heap-memory и пр.
Я вот не так давно анализировал in-memory-databases и на их примерах вижу, что валовая часть хороших продуктов написана на C/C++ и еще Rust набирает популярность сейчас. Садиться на движок который фундаментально сделан на кривом ЯП - ну такое себе.
Если у Impala есть критические минусы над Trino - я бы очень хотел о них знать.
Минусы Java - это не предубеждения, у нее есть масса фундаментальной проблематики которая мешает написанию качественного низкоуровневого движка/СУБД
Вы все правильно говорите. Лично я с такими же мыслями скептически относился к Trino, когда мы выбирали движок. Однако на наших prod like тестах Trino показал себя не хуже Vertica еще 3 года назад. При миграции платформы аб наша UDF в Трино на Java работала не хуже UDF в Vertica на C++. А буквально сейчас p90 отклик Trino в адхок сценариях 1-к-1, как в Vertica на локальных данных – 38 сек.
Поэтому я утверждаю, что несмотря на фундаментальные ограничения Java движок может себя показать не хуже нативных движков на масштабах Авито. Поверьте, я удивлен не меньше вашего =)
Если у Impala есть критические минусы над Trino - я бы очень хотел о них знать.
Каждый выбирает критерии для себя сам. Для нас критичным было то, что Impala создавалась компанией Cloudera для мира Hadoop. Мы скептически смотрели на Hadoop еще в 2013 году, когда Авито только начинал строить DWH. Также скептически мы смотрим на все, что связано с Hadoop и сегодня.
Для нас важно, как движок развивается, как отвечает современным вызовам, кто его использует, кто развивает. Мир больших данных изменился за последние 10 лет до неузнаваемости и, кажется, не собирает останавливаться.
Как часто выходят релизы движка? Какие мировые биг техи используют его в проде и в каких сценариях? Предоставляют ли облачные провайдеры движок как сервис? Большое ли комьюнити у движка? Помогает ли комьюнити решать проблемы с движком и как быстро? Ответы на эти вопросы могут помочь понять, не умрет ли движок через пару лет, не отстанет ли от мировых трендов, легко ли будет его поддерживать и развивать.
Мой поинт в том, что оценивать работу движка будут не по сухим цифрам из бенчмарков, а по тому как он работает в продакшн. Причем, работа в проде – это далеко не только скорость выполнения запросов. Во многом это про сложность поддержки и развития решения.
Конечный пользователь просто не заметит разницы в том, выполнился запрос за 30 сек или за 40 сек. А вот отсутствие привычной для него фичи он заметит моментально.
Наш опыт показывает, что все проблемы, которые возникли у нас при работе с Трино мы смогли решить самостоятельно – подобрав настройки, написав плагин или пропатчив сам Трино. Мы уже достаточно хорошо ориентируемся в кодовой базе Трино, код написан очень качественно, с ним приятно работать, его легко дебажить, он расширяемый.
Наконец, Трино дает такое количество данных для monitoring, observability и debug, о каком мы не могли и мечтать. После Vertica ощущения невероятные)
Какая у вас тут интересная дискуссия получается, коллеги.
Как персона, имеющая прямое отношение у указанным выше ссылкам с полной ответственностью заявляю что смена методики на любую другую не поменяет расклад сил в тестировании. Проверялось неоднократно и на пром данных, и на синтетических тестах и на расчетах ELT и на чем угодно.
Однако, ознакомившись со следующей статье вашего цикла, у меня есть ощущение, что на чем бы вы не обращались к данным, вы упираетесь в инфраструктуру S3. Поэтому, разницы особую можно и не заметить между движками.
Ваш выбор - это ваш выбор. Вы выбирали под своим критерии и значит вам это решение большо подошло. Хоть и переплатили за compute мощности, но зато увереннее себя чувствуете тк можете что то развивать своими силами. Это нормально же.
По поводу Spark. Без него вам нормально пока не выжить, если хотите перейти окончательно на iceberg как на целевой формат. Только Spark может предложить полное реальное работающее обслуживание iceberg формата.
Там еще и третий тест добавили в Click Bench и тч со сравнением ClickHouse, работающим над S3. https://habr.com/ru/companies/datasapience/articles/978430/
В части StarRocks вы правы только от части - он умеет работать над S3, но не все операции с открытыми форматами данных на нем доступны, о чем умалчивают или не понимают некоторые российские вендоры.
Да понятно что сейчас почти все (позиционирующие себя как) современные СУБД имеют какие-то интеграции с S3... и это утверждение (про частичную работу StarRocks с S3) упирается в другой упомянутый мною минус: молодость продукта StarRocks. Да и его (StarRocks) развивают в первую очередь какие-то непонятные китайцы (поправите?), а не Амазоны/Гуглы/etc...
Да и в принципе не понятно, если есть S3, на который и движки ориентируются (Impala/Trino/Spark/подобное) и кликхаусы переходят - зачем жечь время+деньги на проработку локального хранилища? Такое распыление ресурсов - явно бонусом к продукту не идет.
Я вот смотрю на тот же кликхаус, он там с 2009 разрабатывается (почти 2026 на дворе, 17 лет!), а столько всего в нем еще не сделано...
Никакого процедурного PL/SQL
на долгом запросе после потери связи с хостом-источников - продолжает выполнять долгий запрос (ну по ошибке в их http/play интерфейсе отправил огромный запрос - если вручную не убить через KILL - запрос будет работать почти до последнего, оборвется только на переходе со стадии подзапроса SELECT на стадию INSERT)
Оптимизатор запросов на уровне детского сада
И много чего еще там нет...
И в качестве «бонуса» - не выкатывают в open-source SharedMergeTree
Я вот уверен что у StarRocks подобных болезней молодой СУБД тоже будет хоть отбавляй. Еще в качестве не блокирующей, но занозы: разработчики-китайцы... Захочешь в код глянуть - привет иероглифы, будут 146%...
Движок типа Impala хотя бы c 2013 года развивается, и он не палит ресурсы на развитие своего хранилища-велосипеда.
Лично собеседовался пару месяцев назад на проект, где собирались использовать именно StarRocks... Я бы лично не решился сейчас на нем пилить продуктивное хранилище данных.
P.S.: Спасибо за ссылку!
В 2017 году группа китайцев "форкнула" Impala и ушла делать Doris. Мотивация была такой - ходим update delete timeseries? но не хотим идти в Kudu, а хотим в Mesa. Сами разработчики это назвали "идеологическим наследием". В процессе "перехода" перешли на свой собственный формат хранения и оптимизатор и стали shared-nothing СУБД по сути. За эти годы сообщество придумало OTF и они стали стандартом рынка в итоге Дорис начал переобуваться в ОТF форматы и по факту стал теперь догонять Импала в части поддержки открытых форматов.
СтарРокс форкнулся от Дорис в 2020г чтобы тоде уйти в свой формат со своим видением, но чуть раньше чем Дорис поняли что надо ориентироваться на OTF а не свои волшебные форматы.
Очень забавно читать материалы коллег, которые на голубом глазу рассказывают про уникальные векторные вычисления в Старрокс, которые на самом деле он унаследовал от бабушки антилоппы которая их умела в 2013 году.
СтарРокс как движок над S3 в настоящий момент в продакшине можно использовать только на чтение для bi adhoc доступа. ELT точно нет! С локальным стореджем можно жить, но не без приколов.
Было бы очень интересно посмотреть на то, как каждый сравниваемый вами движок справится с нагрузкой близкой к продовой – когда в параллель выполняется множество запросов разного характера.
Также не хватает продолжительного теста, когда в какой-то момент S3 может по неведомым для вас причинам отвечать сильно медленнее, чем раньше. И в таком приближенном к реальности тесте очень ярко бы себя показали локальные кэши в Трино (которые вы тоже не использовали в тесте, хотя кх с локлаьными дисками сравнивали). Предоставляют ли другие движки из коробки такую возможность? Сегодня ни одно современное облачное решение (напр. Snowflake, Yellowbrick, Clickhouse, Starburst) не обходится без агрессивного кэширования. Объектные хранилища просто не работают как локальная файловая система, сколько бы мы этого от них не хотели.
Как аналитик из Авито вставлю еще одну интересную особенность которая была вскользь упомянута в статье. После перехода на Trino аналитикам гораздо проще стало получать доступ к архивным данным. Раньше в Vertica у витрин имелась глубина в зависимости от ее размера, и чтобы получить доступ в архиву приходилось писать запросы к архивной схеме которые очень долго работали. После переезда на Trino и актуальные данные и архивные стали одними и теми же файлами на Ceph, это позволило нам удобно рассчитывать признаки для МЛ-моделей, например. Если получаем от партнера выгрузку за 2023 год, то больше не страдаем, а просто запускаем регламентный расчет признаков на Trino ничего не меняя в запросах и через небольшое время получаем свои признаки на старые даты чтобы делать аналитику)
Уже третий год мы занимаемся миграцией с Vertica на Trino.
Чувствуется. Личный опыт:
2024 год — около 10 просмотров объявлений в неделю, продал 7 товаров.
2025 год — не более 1 просмотра объявления в неделю, продал 1 товар.
Количество объявлений, категории, цены и т.п. — всё примерно одинаково.
ID 86239492. @ddreyman, вы уж там подкрутите что поломали при миграции.
Просто диву даешься как можно было собрать все грабли построения базы данных в одном флаконе! Люди, ну хоть почитайте об инструменте и как с ним работать прежде как принимать решение об использовании. А то потом героически преодолеваем трудности, хотя их могло и не быть изначально выбери другой подход.
весь наш ETL изначально жил внутри SQL-движка
Такой подход уже как лет 20 (а то и больше) не используется в промышленных системах, как не гибкий и не масштабируемый. Значительно удобней вынести в отдельные сервисы и не грузить саму базу.
Я использовал эпохальные инкрементарные измения в 1998 году для обновления данных в OLAPе данных было поменьше, но подход не новый. Тогда обновление базы "в лоб" занимало несколько часов, а инкрементарное - 5 минут.
В следующей статье серии мы подробнее поговорим о сторидже и о том, как объектное хранилище из фонового компонента архитектуры превратилось в один из ключевых факторов, определяющих ограничения, проблемы и инженерные решения Lakehouse-платформы.
С этого нужно начинать, т.к. хранилище - это ключевой компонент любого DWH и по факту под DWH выбирается хранилище.
Люди, ну хоть почитайте об инструменте и как с ним работать прежде как принимать решение об использовании.
Боюсь, историй масштабов Авито на глобальном рынке не очень много. С удовольствием почитаем вашу.
Такой подход уже как лет 20 (а то и больше) не используется в промышленных системах, как не гибкий и не масштабируемый.
Смело заявляю, что подход живее всех живых и кейс Авито тому прямое подтверждение. Мы загружаем данные из 4000+ источников в 20000+ таблиц используя один лишь SQL в Vertica и это работает. Расчеты витрин (которые некоторые тоже записывают в ETL) у нас также написаны на чистом SQL – их более 5000.
Но главное тут то, что весь ETL и витрины у нас описывают наши пользователи - аналитики, разработчики и ds. Никаких дата инженеров, системных аналитиков и т.п. для написания ETL и витрин, полный self service. Весь пайплайн (от источника до целевой таблицы и код витрин) описывается с помощью sql и/или sql-like DSL. Это снижает порог входа, благодаря чему не инженеры могут поддерживать пайплайны самостоятельно. Они самостоятельно вносят тысячи изменений в неделю. В ином случае нам бы пришлось иметь армию дата инженеров, но у нас на одного дата инженера приходится больше 6 аналитиков – это большая редкость на нашем рынке.
Проблемы, о которых мы писали, вообще не были связаны с SQL движком. Проблемы были в сторадже – он не переваривает такую нагрузку без дополнительных приседаний. Как бы вы не загружали данные, узким горлом скорее всего будет S3.
Я использовал эпохальные инкрементарные измения в 1998 году для обновления данных в OLAPе данных было поменьше, но подход не новый. Тогда обновление базы "в лоб" занимало несколько часов, а инкрементарное - 5 минут.
Чудесно! Мы строили наш ETL таким образом с самого начала. OLAP не приспособлен к delete/update, поэтому мы их не используем:
источник -> staging слой – append only
staging слой -> детальный слой – append only
расчет витрин – инкрементально (подневно)
Правильно подобранная модель данных и архитектура ETL/витрин позволяет делать все, что нужно внутри OLAP БД.
С этого нужно начинать, т.к. хранилище - это ключевой компонент любого DWH и по факту под DWH выбирается хранилище.
Snowflake, Databricks, Starburst, Vertica EON, Dremio, Yellowbrick, Clickhouse Cloud построены поверх S3. Их масштабы и успех внушают уверенность в том, что сторадж не столь важен – даже топорный медленный блоб сторадж подойдет. Но по факту выясняется, что для этого необходимо сильно поработать над движом – максимально сократив обращения в топорный сторадж. Просто об этом мало пишут.
Trino в Авито два года спустя: от движка к полноценной экосистеме