Еще смущает такое количество витрин. Какие критерии используются: по отраслям, направлениям и т.д.?
Авито – огромная data driver компания, где трудятся более 10к сотрудников, из которых более 1500 каждый месяц работают с SQL, более 8000 каждый месяц работают с BI. Применений данных в компании невероятное количество: операционная и продуктовая аналитика (в Авито сотни разных продуктов), антифрод, crm, ab, сотни интеграций в продукт Авито и многое другое. На таких масштабах витрины решают специфичные задачи специфичных команд.
Люди, ну хоть почитайте об инструменте и как с ним работать прежде как принимать решение об использовании.
Боюсь, историй масштабов Авито на глобальном рынке не очень много. С удовольствием почитаем вашу.
Такой подход уже как лет 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. Их масштабы и успех внушают уверенность в том, что сторадж не столь важен – даже топорный медленный блоб сторадж подойдет. Но по факту выясняется, что для этого необходимо сильно поработать над движом – максимально сократив обращения в топорный сторадж. Просто об этом мало пишут.
Не совсем понял, о каких конкретно проблемах Vertica в контексте ETL вы говорите. Если вы только про таблицы с сотнями колонок, то речь была про clickstream. В Авито на текущий момент кликстрим - более 60млрд строк в день и более 2500 колонок. Большая часть колонок - поля в разных событиях. Когда-то давно, когда кликстрим был раза в 3 меньше, мы грузили его в Vertica. Почему в Vertica? Потому что все данные мы хранили в одном месте. Vertica отлично справлялась с миллиардами строк, но вот с сотнями колонок - плохо. Все потому что бай дизайн все таблицы в Vertica обязаны быть отсортированы, а сортировка сотен колонок в ее движке реализована не самым эффективным образом. Вот и были проблемы. Однако решили мы их миграцией кликстрима в ClickHouse и написав свой движок в вертике для прямого обращения в ClickHouse (об этом мы рассказывали в предыдущей статье, на которую даём ссылку в начале текущей статьи). На сегодняшний день он отлично справляется с 60 миллиардами событий и 2500+ колонок в день. А в рамках данной статьи мы лишь подчеркнули, что и Трино мог бы справиться с задачей вставки такого числа колонок - потому что он не требует пересортировки данных (если в таблице ее нет)
Однако ничего лучше в качестве shared storage с теми же свойствами отказоустойчивости, масштабируемости, открытости и доступности для разных клиентов пока не изобретено. Если вам известно, расскажите пожалуйста. Будет особенно здорово, если у вас получится подкрепить примерами успешных инсталляций больших масштабов.
Мы не выбирали Ceph, это он выбрал нас )) Ceph используется в Авито уже много лет и предоставляется отдельной командой как сервис. Если я правильно помню, в свое время от minio отказались в пользу Ceph потому что minio не масштабировался. Но здесь речь про масштабы Авито.
Тем не менее, за рынком S3-решений мы активно следим и пока для наших масштабов ничего лучше Ceph не нашли.
minio, кстати, закрылся, они теперь AIStor, а репо на github перешла в maintenance mode.
Было бы очень интересно посмотреть на то, как каждый сравниваемый вами движок справится с нагрузкой близкой к продовой – когда в параллель выполняется множество запросов разного характера.
Также не хватает продолжительного теста, когда в какой-то момент S3 может по неведомым для вас причинам отвечать сильно медленнее, чем раньше. И в таком приближенном к реальности тесте очень ярко бы себя показали локальные кэши в Трино (которые вы тоже не использовали в тесте, хотя кх с локлаьными дисками сравнивали). Предоставляют ли другие движки из коробки такую возможность? Сегодня ни одно современное облачное решение (напр. Snowflake, Yellowbrick, Clickhouse, Starburst) не обходится без агрессивного кэширования. Объектные хранилища просто не работают как локальная файловая система, сколько бы мы этого от них не хотели.
Только Spark может предложить полное реальное работающее обслуживание iceberg формата.
Спасибо за наводку) Пока проблем без Spark не испытываем – все существующие задачи отлично решались через Trino. Про внедрение Iceberg обязательно расскажем в следующих статьях
Минусы 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 ощущения невероятные)
сам clickhouse не подходит для построения dwh общего назначения – не умеет джоины в общем случае, плохо упраляет ресурсами (выполняет запросы на все деньги).
clickhouse хорошо подходит для кейсов аналитики одной таблицы, чем мы активно и пользуемся в нескольких сценариях, один из которых кликстрим (до 60млн событий в минуту)
Ух ты! А поделитесь своим кейсом? Что именно дает вынос RGW и MON на отдельные сервера? С какой проблемой столкнулись? Какие метрики и на сколько улучшились? Будем рады использовать ваш опыт!
Здорово, что вы об этом знали! Жаль, не поделились с комьюнити Ceph раньше – в самом Ceph такая конфигурация не являлась рекомендованной до 24/25 года, кажется.
Что касается NVMe vs SATA – отличное замечание! Спасибо, что подметили) Однако, важным моментом в нашем сетапе является то, что наша задача – построить дешевое бесконечное хранилище для аналитики. Боюсь, что NVMe диски стоят в несколько раз дороже, поэтому мы не рассматриваем их как основное хранилище.
любые синтетические бенчмарки (tpc-ds и тп) имеют мало общего с реальностью. они примерно как тест на IQ – показывают как хорошо движок проходит тест =) мы тестировали запросы типичные в нашем окружении с нашей спецификой. в статье даже есть дисклеймер: "Тестирование проводилось в 2022 году и отражает состояние технологий и экосистем на тот момент, а также наш конкретный юзкейс. Результаты не являются универсальной рекомендацией и, разумеется, не являются публичной офертой."
что касается Impala, он не подходил под наши критерии, о которых я написал выше – "современные, активно развивающиеся и активно применяемые в мировых биг техах решения", "которое сможем развивать своими силами"
Производительность движка в первую очередь определяется не языком программирования, на котором он написан. Его архитектура и реализованные оптимизации играют куда более важную роль. "Медленная джава" – это всего лишь предубеждение. Мы видим своими глазами, как трино работает не хуже вертики, а где-то и превосходит ее, хотя она написана на "быстрых сях". Выбирая движок, мы в первую очередь смотрели современные, активно развивающиеся и активно применяемые в мировых биг техах решения. Мы искали решение, которое сможем развивать своими силами – на наших масштабах работающих "коробок" не существует. Trino/Presto используют и активно развивают все топовые биг техи мира. Он показал себя отлично на тестах. Он отлично показывает себя в продакшне на наших масштабах. Все изначально обозначенные проблемы уже решены.
Во второй главе статьи про это как раз написано "Основной формат хранения у нас – Hive, хотя мы активно используем и Iceberg". Формат файлов мы используем ORC (почему – в предыдущей статье https://habr.com/ru/companies/avito/articles/979836/)
Авито – огромная data driver компания, где трудятся более 10к сотрудников, из которых более 1500 каждый месяц работают с SQL, более 8000 каждый месяц работают с BI. Применений данных в компании невероятное количество: операционная и продуктовая аналитика (в Авито сотни разных продуктов), антифрод, crm, ab, сотни интеграций в продукт Авито и многое другое. На таких масштабах витрины решают специфичные задачи специфичных команд.
Боюсь, историй масштабов Авито на глобальном рынке не очень много. С удовольствием почитаем вашу.
Смело заявляю, что подход живее всех живых и кейс Авито тому прямое подтверждение. Мы загружаем данные из 4000+ источников в 20000+ таблиц используя один лишь SQL в Vertica и это работает. Расчеты витрин (которые некоторые тоже записывают в ETL) у нас также написаны на чистом SQL – их более 5000.
Но главное тут то, что весь ETL и витрины у нас описывают наши пользователи - аналитики, разработчики и ds. Никаких дата инженеров, системных аналитиков и т.п. для написания ETL и витрин, полный self service. Весь пайплайн (от источника до целевой таблицы и код витрин) описывается с помощью sql и/или sql-like DSL. Это снижает порог входа, благодаря чему не инженеры могут поддерживать пайплайны самостоятельно. Они самостоятельно вносят тысячи изменений в неделю. В ином случае нам бы пришлось иметь армию дата инженеров, но у нас на одного дата инженера приходится больше 6 аналитиков – это большая редкость на нашем рынке.
Проблемы, о которых мы писали, вообще не были связаны с SQL движком. Проблемы были в сторадже – он не переваривает такую нагрузку без дополнительных приседаний. Как бы вы не загружали данные, узким горлом скорее всего будет S3.
Чудесно! Мы строили наш ETL таким образом с самого начала. OLAP не приспособлен к delete/update, поэтому мы их не используем:
источник -> staging слой – append only
staging слой -> детальный слой – append only
расчет витрин – инкрементально (подневно)
Правильно подобранная модель данных и архитектура ETL/витрин позволяет делать все, что нужно внутри OLAP БД.
Snowflake, Databricks, Starburst, Vertica EON, Dremio, Yellowbrick, Clickhouse Cloud построены поверх S3. Их масштабы и успех внушают уверенность в том, что сторадж не столь важен – даже топорный медленный блоб сторадж подойдет. Но по факту выясняется, что для этого необходимо сильно поработать над движом – максимально сократив обращения в топорный сторадж. Просто об этом мало пишут.
Не совсем понял, о каких конкретно проблемах Vertica в контексте ETL вы говорите. Если вы только про таблицы с сотнями колонок, то речь была про clickstream. В Авито на текущий момент кликстрим - более 60млрд строк в день и более 2500 колонок. Большая часть колонок - поля в разных событиях. Когда-то давно, когда кликстрим был раза в 3 меньше, мы грузили его в Vertica. Почему в Vertica? Потому что все данные мы хранили в одном месте. Vertica отлично справлялась с миллиардами строк, но вот с сотнями колонок - плохо. Все потому что бай дизайн все таблицы в Vertica обязаны быть отсортированы, а сортировка сотен колонок в ее движке реализована не самым эффективным образом. Вот и были проблемы. Однако решили мы их миграцией кликстрима в ClickHouse и написав свой движок в вертике для прямого обращения в ClickHouse (об этом мы рассказывали в предыдущей статье, на которую даём ссылку в начале текущей статьи). На сегодняшний день он отлично справляется с 60 миллиардами событий и 2500+ колонок в день. А в рамках данной статьи мы лишь подчеркнули, что и Трино мог бы справиться с задачей вставки такого числа колонок - потому что он не требует пересортировки данных (если в таблице ее нет)
Весь мир смущается. И мы смущается =)
Однако ничего лучше в качестве shared storage с теми же свойствами отказоустойчивости, масштабируемости, открытости и доступности для разных клиентов пока не изобретено. Если вам известно, расскажите пожалуйста. Будет особенно здорово, если у вас получится подкрепить примерами успешных инсталляций больших масштабов.
Мы не выбирали Ceph, это он выбрал нас ))
Ceph используется в Авито уже много лет и предоставляется отдельной командой как сервис. Если я правильно помню, в свое время от minio отказались в пользу Ceph потому что minio не масштабировался. Но здесь речь про масштабы Авито.
Тем не менее, за рынком S3-решений мы активно следим и пока для наших масштабов ничего лучше Ceph не нашли.
minio, кстати, закрылся, они теперь AIStor, а репо на github перешла в maintenance mode.
Было бы очень интересно посмотреть на то, как каждый сравниваемый вами движок справится с нагрузкой близкой к продовой – когда в параллель выполняется множество запросов разного характера.
Также не хватает продолжительного теста, когда в какой-то момент S3 может по неведомым для вас причинам отвечать сильно медленнее, чем раньше. И в таком приближенном к реальности тесте очень ярко бы себя показали локальные кэши в Трино (которые вы тоже не использовали в тесте, хотя кх с локлаьными дисками сравнивали). Предоставляют ли другие движки из коробки такую возможность? Сегодня ни одно современное облачное решение (напр. Snowflake, Yellowbrick, Clickhouse, Starburst) не обходится без агрессивного кэширования. Объектные хранилища просто не работают как локальная файловая система, сколько бы мы этого от них не хотели.
Спасибо за наводку) Пока проблем без Spark не испытываем – все существующие задачи отлично решались через Trino. Про внедрение Iceberg обязательно расскажем в следующих статьях
Вы все правильно говорите. Лично я с такими же мыслями скептически относился к Trino, когда мы выбирали движок. Однако на наших prod like тестах Trino показал себя не хуже Vertica еще 3 года назад. При миграции платформы аб наша UDF в Трино на Java работала не хуже UDF в Vertica на C++. А буквально сейчас p90 отклик Trino в адхок сценариях 1-к-1, как в Vertica на локальных данных – 38 сек.
Поэтому я утверждаю, что несмотря на фундаментальные ограничения Java движок может себя показать не хуже нативных движков на масштабах Авито. Поверьте, я удивлен не меньше вашего =)
Каждый выбирает критерии для себя сам. Для нас критичным было то, что Impala создавалась компанией Cloudera для мира Hadoop. Мы скептически смотрели на Hadoop еще в 2013 году, когда Авито только начинал строить DWH. Также скептически мы смотрим на все, что связано с Hadoop и сегодня.
Для нас важно, как движок развивается, как отвечает современным вызовам, кто его использует, кто развивает. Мир больших данных изменился за последние 10 лет до неузнаваемости и, кажется, не собирает останавливаться.
Как часто выходят релизы движка? Какие мировые биг техи используют его в проде и в каких сценариях? Предоставляют ли облачные провайдеры движок как сервис? Большое ли комьюнити у движка? Помогает ли комьюнити решать проблемы с движком и как быстро? Ответы на эти вопросы могут помочь понять, не умрет ли движок через пару лет, не отстанет ли от мировых трендов, легко ли будет его поддерживать и развивать.
Мой поинт в том, что оценивать работу движка будут не по сухим цифрам из бенчмарков, а по тому как он работает в продакшн. Причем, работа в проде – это далеко не только скорость выполнения запросов. Во многом это про сложность поддержки и развития решения.
Конечный пользователь просто не заметит разницы в том, выполнился запрос за 30 сек или за 40 сек. А вот отсутствие привычной для него фичи он заметит моментально.
Наш опыт показывает, что все проблемы, которые возникли у нас при работе с Трино мы смогли решить самостоятельно – подобрав настройки, написав плагин или пропатчив сам Трино. Мы уже достаточно хорошо ориентируемся в кодовой базе Трино, код написан очень качественно, с ним приятно работать, его легко дебажить, он расширяемый.
Наконец, Трино дает такое количество данных для monitoring, observability и debug, о каком мы не могли и мечтать. После Vertica ощущения невероятные)
clickhouse мы используем уже больше 6 лет. подробнее про это написано в статье про эволюцию dwh в Авито https://habr.com/ru/companies/avito/articles/600053/ и немного даже в этой статье.
сам clickhouse не подходит для построения dwh общего назначения – не умеет джоины в общем случае, плохо упраляет ресурсами (выполняет запросы на все деньги).
clickhouse хорошо подходит для кейсов аналитики одной таблицы, чем мы активно и пользуемся в нескольких сценариях, один из которых кликстрим (до 60млн событий в минуту)
Ух ты! А поделитесь своим кейсом? Что именно дает вынос RGW и MON на отдельные сервера? С какой проблемой столкнулись? Какие метрики и на сколько улучшились? Будем рады использовать ваш опыт!
Здорово, что вы об этом знали! Жаль, не поделились с комьюнити Ceph раньше – в самом Ceph такая конфигурация не являлась рекомендованной до 24/25 года, кажется.
Что касается NVMe vs SATA – отличное замечание! Спасибо, что подметили) Однако, важным моментом в нашем сетапе является то, что наша задача – построить дешевое бесконечное хранилище для аналитики. Боюсь, что NVMe диски стоят в несколько раз дороже, поэтому мы не рассматриваем их как основное хранилище.
любые синтетические бенчмарки (tpc-ds и тп) имеют мало общего с реальностью. они примерно как тест на IQ – показывают как хорошо движок проходит тест =)
мы тестировали запросы типичные в нашем окружении с нашей спецификой. в статье даже есть дисклеймер: "Тестирование проводилось в 2022 году и отражает состояние технологий и экосистем на тот момент, а также наш конкретный юзкейс. Результаты не являются универсальной рекомендацией и, разумеется, не являются публичной офертой."
что касается Impala, он не подходил под наши критерии, о которых я написал выше – "современные, активно развивающиеся и активно применяемые в мировых биг техах решения", "которое сможем развивать своими силами"
Производительность движка в первую очередь определяется не языком программирования, на котором он написан. Его архитектура и реализованные оптимизации играют куда более важную роль.
"Медленная джава" – это всего лишь предубеждение. Мы видим своими глазами, как трино работает не хуже вертики, а где-то и превосходит ее, хотя она написана на "быстрых сях".
Выбирая движок, мы в первую очередь смотрели современные, активно развивающиеся и активно применяемые в мировых биг техах решения. Мы искали решение, которое сможем развивать своими силами – на наших масштабах работающих "коробок" не существует.
Trino/Presto используют и активно развивают все топовые биг техи мира. Он показал себя отлично на тестах. Он отлично показывает себя в продакшне на наших масштабах. Все изначально обозначенные проблемы уже решены.
речь про платформу аб-тестов и метрик – https://trisigma.io/
она расчитывает классические olap-кубы с десятками разрезов – 30+ млрд метрик в день. подробнее можно посмотреть тут: https://youtu.be/wsjVP2nNpsM?si=dGpwORzO_ImwrmW_
Во второй главе статьи про это как раз написано "Основной формат хранения у нас – Hive, хотя мы активно используем и Iceberg". Формат файлов мы используем ORC (почему – в предыдущей статье https://habr.com/ru/companies/avito/articles/979836/)
Приятно слышать, что кто-то находит наш опыт полезным)