Всем привет! Меня зовут Дмитрий Рейман, я техлид аналитической платформы Авито.
Последний раз мы подробно писали о нашей платформе почти четыре года назад – в статье «Эволюция хранилища данных в Авито». С тех пор аналитическая платформа сильно изменилась и по масштабу, и по сложности.
Мы строим систему общего назначения, которая одновременно обслуживает ETL, витрины, BI, ad-hoc аналитику и продуктовые платформы.
Сегодня аналитическая платформа Авито это:
объём хранилища около 2 ПБ;
обработка более 3 ПБ данных в сутки и порядка 2 млн запросов;
поток входящих событий до 60 млн событий в минуту;
ежедневная загрузка данных из 4000 источников в 20 000 таблиц детального слоя;
ежедневный расчёт 5000 витрин, 700 A/B-тестов и 30 млрд метрик;
800 ежедневных пользователей ad-hoc и 5000 пользователей BI.
В какой-то момент мы столкнулись с неприятным эффектом: объём данных начал расти заметно быстрее, чем органический рост, на который мы ориентировались раньше.
Модель классического on-prem DWH перестала масштабироваться линейно: борьба за ресурсы мешала давать гарантии готовности данных; локальные оптимизации давали всё меньший эффект; любой рост требовал масштабирования “по месту” и приводил к длительным простоям аналитики.
Стало понятно, что дальнейший рост в рамках прежней архитектуры будет только усиливать эти эффекты. В этот момент фокус сместился с «допиливать и оптимизировать» на поиск архитектурного решения, которое позволит предсказуемо масштабироваться, изолировать нагрузки и расти за счёт вычислений, а не постоянного расширения монолитного кластера.
Именно так мы пришли к необходимости сменить базовую парадигму хранилища и начать движение в сторону Lakehouse-архитектуры.
Эта статья – первая в серии про миграцию аналитической платформы Авито из классического DWH в Lakehouse.
Здесь разберём:
предпосылки миграции;
ограничения, с которыми мы столкнулись;
первые практические шаги и архитектурные решения.
В следующих статьях расскажем:
почему замена движка оказалась лишь началом, и нам пришлось строить целую экосистему вокруг нового ядра платформы;
как объектное хранилище из «фонового компонента» превратилось в ключевой источник проблем и инженерных решений.
Если коротко: это история не про смену технологий, а про то, как на больших масштабах архитектура начинает диктовать правила.
С чего все началось?
Все началось в 2022 году. Хранилище Авито было построено на Vertica. Фактически это 50 независимых нод, которые хранят кусочек данных своего шарда, плюс кусочек данных своего соседа, чтобы обеспечить отказоустойчивость. Каждая нода выполняет две роли. Первая – координация запросов. Координатор спланирует этот запрос и отправит задание на выполнение на все ноды, которые есть в кластере. Вторая роль – выполнение маленьких тасочек, из которых состоит запрос (execution).
Все это фактически существует в рамках одной ноды, одного процесса – а данные, соответственно, лежат локально. Каждая нода имеет связь со всеми соседями и может обмениваться информацией для того, чтобы в конце транзакции закоммитить ее.
За время существования ландшафт Vertica значительно пополнился. Кроме Vertica, в которой мы хранили большую часть данных, у нас также появился ClickHouse (данные о действиях пользователей) и Ceph (архивные данные). Тем не менее, и Ceph, и ClickHouse доступны через Vertica с помощью механизмов коннекторов – фактически в качестве точки входа в хранилище использовалась именно Vertica. В рамках хранилища мы имели дело приблизительно с 150 интеграциями с продуктовыми сервисами, 200 пользователей и миллионом запросов. Представляете как работает нагрузка на кластер? На этом масштабе проблемы роста становятся особенно заметны.
Аналитическое хранилище критически важно: его используют не только аналитики, но и системы антифрода, продакшн-сервисы, а также другие платформы, построенные поверх него. И все в какой-то момент начали страдать: нас много, а Vertica одна. В пиковые часы (с 03:00 до 15:00) нагрузка была настолько высока, что нам перестало хватать ресурсов, чтобы обслужить все запросы. Даже с учетом проведенных оптимизаций.
Также у Vertica есть особенность: она очень долго поднимается при падении. Падение од��ой ноды мы еще могли пережить. А вот, если упали все ноды, кластер сложился, то фактически мы оставались без аналитической инфраструктуры примерно на час.
Проблему борьбы за ресурсы можно было бы решить простым горизонтальным масштабированием. Закидывайте ресурсами постоянно – и все, будет вам счастье. Только проблема в том, что в случае Vertica при добавлении новых нод нужно ребалансировать все данные. Ребалансировка данных (при объеме в 1 ПБ) происходит примерно неделю и блокирует другие процессы внутри Vertica. После этого нужно добавить еще одну неделю на сокращение отставаний, все загрузки и т.д.. Практически две недели мы оставались без актуальных данных, что, конечно, очень плохо. А я напомню, что там порядка петабайта данных, и, соответственно, это происходит совершенно не быстро.
Что мы хотели на самом деле?
Если обобщить, мы столкнулись с ситуацией, в которой объем данных начинал расти заметно быстрее, чем органический рост, на который мы ориентировались раньше. Построив прогноз на несколько лет вперед, стало понятно, что наша модель обойдется слишком дорого – как с точки зрения ресурсов, так и с точки зрения операционной устойчивости. Уже существующие проблемы с гарантиями готовности данных, конкуренцией за ресурсы в одном адресном пространстве и масштабируемостью начинали возникать чаще и проявляться сильнее.
В какой-то момент стало ясно, что дальнейший рост только усугубит эти эффекты. Чем быстрее росли данные, тем чаще мы сталкивались с деградацией платформы и тем хуже становилось итоговое состояние системы. В такой ситуации цель сместилась с локальных оптимизаций на поиск архитектурного решения: мы хотели прийти к платформе, которая работает стабильнее и масштабируется, по возможности, за счёт вычислений, а не объёма данных.
Мы сознательно не рассматривали здесь весь набор приёмов, которые использовали раньше: сокращение нагрузки, реплики, изменения моделей данных, вынос отдельных расчётов и другие точечные оптимизации. Этот этап уже был пройден. На тот момент было важнее посмотреть на архитектуру целиком и перейти к подходу, в котором проблемы роста решаются не постоянными ручными улучшениями, а за счёт смены базовой парадигмы хранилища.
Именно это и привело нас к необходимости искать новый движок и новую СУБД – решение, которое позволит повысить стабильность платформы и масштабироваться независимо от роста объема данных, не связывая каждое увеличение данных с обязательным расширением вычислительного кластера.
Мы смотрели на рынок свежим взглядом. Мы искали:
разделение compute и storage (чтобы была возможность масштабировать вычисления независимо от данных);
предсказуемую производительность;
возможность изолировать нагрузки (например, чтобы A/B-тесты не убивали CRM-рассылки).
Почему Trino?
Первым делом мы, конечно, посмотрели на родное решение – Vertica Eon Mode. Это облачный режим, где данные выгружаются в S3, а вычислительные кластеры работают поверх них. Архитектурно – это прямой путь решения наших проблем. Но в один день наши контакты прервались и пришлось искать дальше.
Мы рассматривали разные варианты и подходы: классические MPP-решения вроде Greenplum, экосистемы вокруг Apache Spark и Databricks, проекты по ускорению Spark за счёт нативного исполнения – Gluten и Velox, движки, в первую очередь Trino, а также более новые на тот момент – StarRocks и Dremio.
В 2022 году, во время миграции между дата-центрами, у нас освободилось 20 серверов (стандартная конфигурация: 72 ядра, 512 ГБ RAM, 10 GbE). Мы решили провести испытания разных движков на реальных данных.
Тестирование мы проводили спринтами: в рамках одного спринта брали один движок и доводили его до состояния, в котором он способен выполнять наши запросы. Нужно было развернуть инфраструктуру, загрузить данные, обеспечить выполнение SQL и немного поднастроить конфигурацию, чтобы получить не запуск в вакууме, а результаты, близкие к реальности. Спринты были двухнедельными, но фактически на каждый этап уходило по одному-двум дням.
В первую очередь мы смотрели на время выполнения запросов и потребление ресурсов. Дополнительно нас интересовало наличие фич, к которым мы привыкли в Vertica.
Для сравнения мы выбрали около десятка типовых расчётов, которые ежедневно считаются в Vertica. Это запросы с большим количеством джойнов, оконных функций и агрегаций, работающие с таблицами объёмом от сотен миллионов до миллиардов строк.
Коротко о результатах:
GaussDB: тестировали на внешнем стенде, интерполировали результаты. Даже с поправкой – неприемлемая производительность;
Spark: кратно медленнее на наших аналитических запросах;
StarRocks: показал лучшую, чем Vertica, производительность почти на каждом запросе. Но профиль потребления ресурсов на наших объемах не подходил. Он использует все ресурсы на каждый запрос. При параллельной нагрузке в 15-20 запросов он бы не справился;
Trino: показал паритет с Vertica по скорости, изначально заточен на параллельное выполнение множества запросов + выводы подтверждаются независимым исследован��ем, где сравнивали Vertica и Presto (бывшее название Trino).
Дисклеймер. Тестирование проводилось в 2022 году и отражает состояние технологий и экосистем на тот момент, а также наш конкретный юзкейс. Результаты не являются универсальной рекомендацией и, разумеется, не являются публичной офертой.
В процессе тестирования мы поняли, что уже жили в Lakehouse, просто не признавали этого. Почему бы не попробовать решение, которое изначально спроектировано для работы в этой парадигме?
В итоге мы остановились на Trino как на основе для построения новой платформы.
От теории к практике. Первые шаги внедрения Trino
Начнём с базового устройства Trino: он состоит из нескольких достаточно простых и понятных компонентов.
Данные хранятся во внешнем storage – в нашем случае это S3-совместимое хранилище, куда мы выгружаем данные из Vertica или генерируем их напрямую. Метаданные лежат в отдельном метасторе.
Сам Trino состоит из координатора и воркеров. Координатор принимает SQL-запрос от пользователя, парсит его, обращается к метастору, чтобы понять, какие данные и партиции нужны для выполнения, разбивает запрос на задачи и отправляет их воркерам. Воркеры выполняют эти задачи и возвращают результаты. Архитектура достаточно прозрачная и хорошо читается.
После того как мы разобрались с базовой моделью, мы решили попробовать использовать Trino на практике и посмотреть, как он поведёт себя на наших данных и запросах.
Основной проблемой, с которой мы боролись в Vertica, была конкуренция за ресурсы. Мы решили детально посмотреть, кто именно потребляет ресурсы Vertica, и довольно быстро увидели, что две платформы, построенные поверх аналитического хранилища, в сумме съедают больше трети всех ресурсов за день.
Важный нюанс: они являются листовыми расчетами – используют данные всего хранилища, но их результаты уже не используются другими процессами. Это делает их идеальными кандидатами для переноса.
Следующий вопрос: как технически всё это запустить. Мы сознательно выбрали самый простой и предсказуемый путь.
В качестве хранилища данных мы использовали S3-совместимый storage Ceph, который уже применяется в Авито. Форматом хранения выбрали ORC – с ним мы давно работаем, хорошо понимаем его особенности и уже используем для архивных данных. Все это позволило опираться на уже существующую инфраструктуру и опыт.
Vertica умеет выгружать данные в ORC стандартными средствами, поэтому базовый сценарий выглядел просто: данные регулярно выгружаются из Vertica в Ceph. На небольших объёмах этого было бы достаточно, но на наших масштабах стандартные механизмы оказались недостаточно эффективными. В результате мы дописали собственные расширения для выгрузки, чтобы лучше контролировать процесс и поддерживать гибридный режим, в котором данные одновременно используются и в Vertica, и в Trino. При этом сама схема осталась максимально простой, без дополнительных промежуточных систем.
На первый взгляд связка Vertica + ORC выглядела удачно, но довольно быстро проявились ограничения. Vertica действительно умеет читать ORC, однако даже простой запрос, который аналитики используют, чтобы посмотреть глубину хранения данных в таблице, мог забирать половину ресурсов кластера и выполняться десятки минут.
Вторая проблема была связана с партиционированием. В Vertica мы активно используем партиционирование по выражению. При выгрузке данных в ORC и попытке перейти к Hive-партиционированию возник конфликт моделей: нужно было либо отказаться от старого подхода, либо как-то совместить его с новой схемой так, чтобы старые запросы продолжали работать в Vertica, а новые эффективно фильтровали данные в Trino.
Третья проблема касалась оптимизации чтения данных. У нас есть таблицы с десятками миллиардов строк в день, и запросы к ним уже написаны с большим количеством фильтров. Однако в стандартной реализации ORC, используемой Vertica, на этапе чтения данных фактически применяется только фильтр по партиции. Все остальные условия отрабатывают уже после чтения, из-за чего система обрабатывает значительно больше данных, чем требуется.
Чтобы решить эти проблемы, мы приняли решение написать собственный коннектор для работы с ORC-данными в Vertica. Это дало нам полный контроль над процессом выгрузки, позволило аналитикам работать с ORC без деградации Vertica и заложило основу для дальнейших изменений в архитектуре.
После того как данные оказались в Ceph в формате ORC, следующим шагом было сделать их доступными в Trino. Для этого мы использовали стандартный Hive-коннектор. Технически всё свелось к созданию внешних таблиц: мы указывали путь к данным, синхронизировали партиции и загружали метаданные в метастор.
На практике это означало две операции: обновление метаданных и сбор статистики. Полную статистику по всем колонкам мы сознательно не собирали – это слишком дорого и долго на наших объемах. Мы ограничились статистикой по колонкам партиционирования, чтобы Trino мог принимать адекватные решения при планировании запросов.
После этого данные становились полноценными таблицами, с которыми можно работать в Trino. На этом этапе запуск, по сути, был завершён. Никаких дополнительных сервисов или сложных интеграций не потребовалось.
Кейс по миграции платформы CRM-рассылок
Теперь перейдём к практическому кейсу: миграции платформы CRM-рассылок.
Она отвечает за подготовку и запуск коммуникаций с пользователями. Команда маркетинга формирует аудитории и запускает рассылки: сообщения, push-уведомления и другие каналы коммуникации. В 2023 году, на момент начала миграции, ежедневно запускалось порядка 600 таких кампаний в разных вертикалях и с разными условиями отбора аудитории.
Подготовка CRM-рассылок создавала заметную нагрузку на аналитическое хранилище – около 7% всей дневной нагрузки Vertica. При этом для расчетов используются практически все доступные данные: крупные витрины, широкие таблицы, детальный слой. В запросах активно применяются join’ы, аналитические функции и агрегации, и фактически маркетологи никак не ограничены в сложности SQL, который они могут написать.
Типовой процесс выглядит так: маркетолог готовит SQL-скрипт, сохраняет его в CRM-платформе, после чего планировщик запускает этот расчёт на регулярной основе.
Выбор конфигурации Trino-кластера
Для миграции CRM-платформы мы развернули отдельный Trino-кластер из шести воркеров. Размер кластера выбирали максимально прагматично. Мы посчитали суммарное количество CPU-ядер в Vertica-кластере, умножили его на долю нагрузки, которую создает CRM-платформа, и получили конфигурацию из шести серверов по 56 ядер. Объём памяти в этом сетапе оказался даже больше, чем тот, который CRM-рассылки использовали в Vertica.
Мы убедились, что такой кластер способен выдерживать текущую нагрузку, и перешли к следующему этапу.
Пользовательский опыт и SQL
При переходе на новый движок для нас было критично не ухудшить пользовательский опыт. Trino, как и Vertica, поддерживает ANSI SQL, поэтому сам язык запросов оказался знакомым. Да, в Vertica есть синтаксический сахар и динамическая типизация, которых нет в Trino, и это потребовало небольших изменений в запросах, но в целом различия оказались некритичными.
Существенной проблемой стало отсутствие временных таблиц, а в CRM-рассылках этот паттерн применяется довольно часто.
Мы решили эту проблему следующим образом: создали отдельную схему, указали ее в качестве дефолтной. Все таблицы, создаваемые без явного указания схемы, попадают туда. Чтобы пользователям не приходилось думать об этом механизме, создание схемы было вынесено на уровень SQL-клиента, через который осуществляется доступ к хранилищу. С точки зрения пользователя процесс остался практически таким же, как в Vertica.
Отдельно мы сохранили привычный нейминг таблиц. Имена таблиц остались прежними, менялся только синтаксис запросов. По отзывам маркетологов и аналитиков, которые занимались переводом кампаний, процесс оказался удобным и не потребовал значительных усилий.
Чтобы ускорить миграцию, мы написали простой транслятор SQL с Vertica на Trino на регулярных выражениях. В результате маркетолог или аналитик получали почти готовый скрипт, который нужно лишь немного доработать. В таком режиме скорость миграции достигала примерно шести расчётов в день на одного человека.
Стабильность и работа с памятью
Стабильность – критичный параметр для платформы CRM-рассылок. Именно ради её повышения команда согласилась стать первой, кто переезжает на Trino.
По мере переноса всё большего числа кампаний мы начали сталкиваться с ошибками вида Cluster Out of Memory. Анализ показал, что причина почти всегда одна и та же: отдельные запросы, которые потребляют всю доступную память кластера, вызывая эффект домино.
В одном из случаев запрос выполнял distinct, count distinct, group by – в общем, все, что только можно, по таблице с сотнями миллиардов строк без фильтра по дате. Такие запросы невозможно стабильно выполнять ни на каком кластере. Объема памяти для них просто не существует.
Первым шагом мы включили настройку, запрещающую выполнение запросов к партиционированным таблицам без фильтра по партиции. Это решило часть проблем, но не все, так как не все таблицы у нас партиционированы.
Дальнейший анализ показал, что многие запросы в целом написаны неэффективно: избыточные distinct, лишние операции, неоптимальные агрегации. В Vertica такие запросы работали за счёт механизма spill – выгрузки промежуточных данных на диск. В Trino spill существует, но он не поддерживает ключевые для нас сценарии, в том числе count distinct, и сами разработчики Trino не рекомендуют полагаться на этот механизм.
Мы приняли решение отключить spill, установить ограничение в 20 ГБ памяти на ноду и сфокусироваться на оптимизации запросов. Для этого мы подготовили небольшую инструкцию с простыми правилами оптимизации и встроили её в процесс миграции. Если запрос изначально написан неэффективно, это становится видно сразу, и он исправляется до переноса.
Изоляция окружений
Последним шагом стало разделение окружений. Мы развернули два изолированных Trino-кластера: один для продакшен-запросов, которые уже проверены и безопасны для регулярного выполнения, второй для разработки и экспериментов. Это позволило полностью изолировать потенциальные падения и нестабильные запросы от продакшена.
В итоге мы смогли добиться стабильной работы CRM-платформы, используя относительно простые и понятные решения.
Кейс миграции платформы A/B-тестов
A/B-тесты – это способ проверить эффект изменений в продукте до раскатки на всех пользователей. Пользователи делятся на группы, которым показываются разные варианты функциональности, после чего сравниваются заранее выбранные метрики. На основе этих метрик принимается решение, можно ли выкатывать изменение в продакшен.
В 2023 году, на момент начала миграции, в Авито ежедневно обсчитывалось порядка 200 A/B-тестов для разных продуктов и вертикалей. Одни и те же пользователи могут одновременно участвовать в разных экспериментах. В рамках этих тестов мы считали около 20 миллиардов метрик в день. В сумме платформа A/B-метрик потребляла примерно четверть всех доступных ресурсов Vertica, что являлось значительной нагрузкой как для самой платформы, так и для всего хранилища в целом.
Для пользователей платформы – продуктовых команд и аналитиков – результат A/B-теста выглядит достаточно просто: отчёты с прокрасами и непрокрасами метрик, сравнением перформанса вариантов и поведением пользователей в разных разрезах. Однако за этими отчетами стоит крайне ресурсоемкий вычислительный процесс.
Отдельно стоит отметить, что команда, развивающая платформу A/B-метрик, уже вывела ее на рынок как отдельный продукт – Trisigma.
Конфигурация Trino-кластера для A/B-метрик
Для расчётов A/B-метрик мы развернули отдельный Trino-кластер из 22 воркеров. Размер кластера, как и в предыдущих случаях, выбирался простой арифметикой: мы оценили нагрузку, которую платформа создавала в Vertica, и подобрали эквивалентную конфигурацию по количеству CPU-ядер. Никаких сложных моделей или бенчмарков на этом этапе не использовалось.
Как считаются A/B-метрики
Объём данных в A/B-метриках очень большой – десятки миллиардов значений, которые считаются в разных разрезах. Это включает счётчики, уникальные значения и агрегаты. Реализовать такие расчёты на чистом SQL на больших объёмах данных и нужной нам производительностью практически невозможно.
Поэтому ранее мы написали собственное расширение для Vertica, ориентированное на эффективный расчёт метрик за минимальное число проходов по данным. Это расширение реализовано на C++, что логично, так как сама Vertica написана на C++.
При переходе на Trino возник вопрос: как перенести эту логику. Trino написан на Java, и первым вариантом, который мы рассмотрели, было использование JNI (Java Native Interface) для вызова C++-кода из Java. Однако на практике выигрыш в производительности оказался незначительным, а сложность и количество проблем, связанных с JNI, перевешивали потенциальные преимущества.
В результате мы приняли решение реализовать расчёт целиком на Java и постараться сделать его максимально эффективным. Для этого мы использовали табличные функции Trino, так как формат входящих и выходящих данных отличается от стандартных. Реализация была оформлена в виде UDF, корректность расчетов мы проверили – результаты полностью совпадали с Vertica.
Проблемы с производительностью и планированием
При этом время выполнения нас изначально не устроило. Мы начали разбираться и обнаружили проблему в шедулинге задач. Партиции данных, на которые разбивается исходный датасет, начинали обрабатываться не одновременно. В результате в середине выполнения запроса оставались один-два воркера, которые продолжали работу, тогда как остальные простаивали.
Мы пробовали управлять параметрами параллелизма, настраивали concurrency задач и экспериментировали с количеством партиций. Это позволило частично сгладить проблему, но полностью её не решило. При этом мы понимали, что в Trino есть дополнительные настройки, связанные с планированием и шедулингом, которые потенциально позволяют это исправить. Однако на данном этапе это не являлось критичной задачей.
По итогам работы оказалось, что реализация расчёта A/B-метрик в Trino работала быстрее, чем существующая реализация в Vertica. Разница не была кратной, но оказалась ощутимой и стабильной. Это стало для нас важным подтверждением того, что в Trino можно писать эффективную обработку больших объёмов данных, даже для сложных и нестандартных вычислений.
Утилизация ресурсов и эффективность
После запуска расчетов мы посмотрели на графики потребления CPU и нагрузки на кластер и увидели характерную проблему: нагрузка распределялась крайне неравномерно. Для тех, кто давно работает с MPP-системами, это знакомая ситуация – наиболее эффективная обработка достигается тогда, когда все воркеры нагружены примерно одинаково. В нашем случае это было не так.
Мы разобрались с настройками и смогли выровнять профиль нагрузки. В результате удалось добиться равномерной утилизации ресурсов, и сделали мы это достаточно простыми шагами.
Во всех кейсах, где наблюдалась неравномерная нагрузка, основной причиной оказывался неэффективный shuffle данных. В части случаев это происходило из-за отсутствия статистики: оптимизатор выбирал неоптимальный план выполнения и неоптимальный порядок join’ов, из-за чего данные перераспределялись между воркерами в тех местах, где этого можно было избежать.
В других случаях узким местом оказывались буферы обмена данными между стадиями выполнения. Дефолтные значения этих буферов в Trino рассчитаны на сравнительно небольшие объёмы данных. Когда же между стадиями передаются сотни гигабайт или терабайты данных, такие буферы быстро становятся бутылочным горлышком.
Для исправления ситуации мы увеличили размеры буферов, а также подняли лимиты на размер таблиц, которые можно использовать для broadcast join. В результате это позволило устранить лишний shuffle и добиться ровного, предсказуемого профиля нагрузки на воркерах.
Неожиданный бонус Trino
В процессе оптимизации мы обнаружили приятную особенность Trino. Он позволяет достаточно быстро вставлять данные в очень широкие таблицы с сотнями колонок. Для нас это важно в сценариях, где используется большое количество фич.
В Vertica такой подход работает значительно хуже, так как вставка в широкую таблицу требует пересортировки данных. Сортировка большого объёма с сотнями колонок — это дорогая и трудоёмкая операция, которая быстро начинает доминировать по времени и ресурсам. В Trino этой проблемы нет, что оказалось полезным побочным эффектом.
В итоге мы пришли к очевидному, но важному выводу: оптимизацию никто не отменял. Да, с запросами и настройками приходится посидеть и разобраться, но это не выглядит чем-то чрезмерно сложным или нестабильным.
Где мы находимся сейчас и что дальше
С начала миграции прошло более двух лет. За это время аналитическая платформа заметно изменилась – не только технологически, но и по профилю нагрузки и возможностям.
На текущий момент у нас уже есть ощутимые результаты:
платформа A/B-тестов и платформа CRM-рассылок полностью переехали в Trino – мы повысили их стабильность и смогли вырасти примерно в два раза, не увеличив нагрузку на аналитическую платформу в целом;
более 2500 витрин (около 50%) ежедневно считаются в Trino;
более 500 пользователей ежедневно работают в Trino – это порядка 70% активной аудитории платформы;
7 продуктовых платформ запущены напрямую на Trino – ранее такие сценарии в рамках классического DWH были практически нерешаемы.
Для нас это важный рубеж: Trino перестал быть экспериментом и стал рабочим вычислительным ядром платформы.
Следующий шаг – сделать Trino единой точкой входа в аналитическое хранилище.
Мы хотим, чтобы аналитики, сервисы и продуктовые платформы работали напрямую через него, а Vertica постепенно перестала быть вычислительным центром системы. Это означает продолжение поэтапной миграции.
При этом мы хорошо понимаем, что смена движка – лишь часть задачи. По мере выноса вычислений данные остаются во внешнем сторидже, и вопросы эффективного чтения, изоляции нагрузок и эксплуатационной устойчивости выходят на первый план.
На этом можно подвести промежуточный итог. Опыт показывает, что жизнь после Vertica существует – но она начинается не с переезда, а с переосмысления архитектуры и её пределов.
В следующих статьях мы подробно расскажем:
почему замена движка оказалась лишь началом и нам пришлось строить целую экосистему вокруг нового вычислительного ядра платформы;
как объектное хранилище из «фонового компонента» превратилось в ключевой источник архитектурных ограничений, проблем и инженерных решений.
А если хотите вместе с нами адаптироваться в мире стремительно развивающихся технологий — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.