Привет, меня зовут Владимир, я работаю во Flocktory дата-инженером и расскажу о том, как мы в процессе переезда с одного облака на другое построили фиче-стор, управленческую отчетность и о проблемах, с которыми мы столкнулись.
В 2022 году у нас появилась задача — нужно было перебраться на новое облако, перетащить порядка петабайта данных и начать использовать новые инструменты. И на фоне этого были еще две задачи:
Построить фиче-стор для обслуживания 100 миллионов пользователей, который поддерживал бы исполнение ML-моделей в реальном времени и имел офлайн-хранилище для обучения моделей. И при этом всем отвечал менее, чем за 80 миллисекунд.
Создать централизованную управленческую отчетность. Внутри команды мы назвали ее слайсер. Она должна была отвечать менее, чем за 3 секунды при запросе отчета за год по любому из доступных срезов. Это подразумевало обработку порядка 200−600 гигабайт входящих данных и 20−30 гигабайт получающихся агрегатов. Данные хранились бы по срезам, таким как продукты, партнеры, компании, баннеры. И из метрик, например, лендинги, показы, аксепты, gross revenue.
Почему пришлось перебираться на новое облако
Причина банальна — из-за смены ценовой политики прошлого провайдера оставаться там стало экономически нецелесообразно.
Вопрос миграции возник в 2022 году и вышло так, что выбора в сущности не оказалось. Только Яндекс Клауд подошел нам по инструментам, которые уже использовала data-команда. Немаловажным фактором также стала совместимость API некоторых сервисов.
Что было в начале
У нас были backend-сервисы, которые писали данные в оперативные базы и в Kafka. Далее с помощью Airflow мы запускали spark-кластеры, которые раскидывали эти данные по S3 в формате Hudi. Параллельно получали от внешних систем данные и тоже отправляли их на S3.
Данные оттуда агрегировались и складывались в Vertica, а дашборды строились на MS SQL. Аналитики напрямую ходили в Vertica и в MS SQL, а к данным на S3 они обращались с помощью Hive Presto подобного SQL интерфейса.
Проблемы на старте
Нам нужно было перенести DWH с одного облака на другое. А это рутинная работа, на которую уходит много времени: взять датасет, перенести его в новое облако, проверить на целостность, перенести пайплайн нового наполнения на новые инструменты в новом облаке, проверить. Далее, если все прекрасно, удалить его из прошлого облака, повторить этот процесс. Очень классно, если получается это сделать в рамках одного датасета — но так не бывает, и всегда приходится переносить гораздо больше, а это кратно увеличивает объем рутинной работы.
Если говорить о миграции, то это одна из самых заметных трудностей, но она не приходит одна. У нас также имелось несколько аналитических хранилищ, и они все использовались аналитиками. Также у нас были расхождения в данных. Я о них умолчал вначале, но дело в том, что сервисы у нас писали не только в Kafka и в операционные базы, а еще и в аналитическую Vertica напрямую и это порождало расхождение.
Это головная боль, от которой нам только предстояло избавиться. Плюс мы хотели забрать с собой из старого облака в новое только то, что нам нужно. А узнать, что нам действительно нужно, это тоже задача, и вновь рутинная. При этом мы хотели, чтобы переход был бесшовным. Сразу скажу — не получилось. В процессе перехода пайплайны тянули данные из двух облаков.
Мы хотели отказаться в первую очередь от поставки данных backend-сервисами в аналитические базы. Данные от них должны были поступать строго через Kafka. Мы хотели заменить уже имеющийся у нас Hive Presto на Trino для простоты и заменить формат хранения данных на S3 с Hudi на Iceberg.
Почему мы выбрали Iceberg
Он показал себя более стабильным, чем использовавшиеся на тот момент у нас версии Hudi.
У Hudi часто портились метаданные, а Iceberg этим не страдал. Далее отказаться от аналитических хранилищ, которые у нас были, в пользу собственно Trino и Clickhouse. Trino бы обеспечила аналитикам доступ и возможность делать запросы к данным на практически неограниченном объеме данных, а Clickhouse бы обеспечил быстрый доступ к построенным дашбордам, которые бы визуализировались далее с помощью DataLens.
Как создавали фиче-стор
В первой итерации модели работали хуже, чем ожидалось, и причиной тому стала невозможность получения данных на момент события. Мы этого не предусмотрели и могли получать изначально только данные на текущий момент времени, то есть самые свежие. Это приводило к тому, что для обучения нужно было тянуть данных гораздо больше, чем требовалось, и результат обучения отличался от ожидаемого.
Clickhouse терял в скорости ответа при одновременной записи в таблице. Для нас это было неприемлемо, потому что приводило к нарушению нами SLA. И масштабировать его оказалось гораздо сложнее, нежели YDB, который мы решили использовать впоследствии.
Каким образом мы решали проблемы
Начали с того, что избавились от старой цепочки поставки данных. Новая — это Kafka, offline, онлайн-хранилище. И мы создали историческое offline-хранилище с использованием SCD2. На всякий случай скажу, SCD2 — это Slowly Changing Dimension. Мы сделали это, чтобы была возможность получать доступ к событиям, на интересующие нас моменты времени.
Также мы отказались от Clickhouse, используя YDB, но в основном потому, что он значительно меньше страдал, а впоследствии и вовсе перестал страдать от потери скорости ответа при одновременной записи данных в таблице. Плюсом стала легкость его масштабирования.
Проблемы со слайсером
Первая итерация слайсера оказалась неидеальной. Основная проблема была в том, что он был построен на множестве датасетов и пайплайнов, которые мы из старого облака затянули в новое. Однако это породило большое количество зависимостей и сильно усложнило его. Вносить изменения, зачастую весьма специфические, в такую структуру было практически невозможно —логика для управленческой отчетности не всегда совпадала с логикой для классических аналитических датасетов.
Несмотря на все минусы, слайсер был востребован и свою функцию выполнял. Каким образом мы все это улучшали? После ревизии первой итерации сократили требуемые ресурсы для поддержания, снизили сложность внесения туда изменений.
Для слайсера выделили независимый пайплайн. Это, конечно, не идеальное решение, потому что оно породило частичное дублирование данных, но все же оказалось лучше, чем получавшаяся ранее паутина.
Результаты
Структура во многом сохранилась, но солидная часть запланированных изменений была реализована. Например, мы смогли полностью отказаться от msql. От Vertica полностью не получилось из-за того, что команда аналитики не хочет от нее отказываться. Они к ней очень привыкли, и нам все еще предстоит их убеждать. Данные на S3 у нас большинство хранятся в новом формате, в формате Iceberg.
Дашборды благополучно сливаются в Clickhouse и визуализируются с помощью DataLens. Скоростью ответов аналитики очень довольны. Фиче-стор вместо Clickhouse использует YDB.
Целевых показателей достичь удалось, но улучшать их мы не заканчиваем. Clickhouse можно заставить работать быстрее или сократить стоимость хранения данных, доступ к которым осуществляется не очень часто.
И о планах: нам еще предстоит окончательно отказаться от Vertica, адаптировать существующую архитектуру под возможности новых инструментов и при этом учесть наши планы по внедрению data quality, для точной аналитики, data lineage для работы с актуальными данными и потенциальному переходу на лямбда-архитектуру.