В нашей компании исторически сложилась децентрализованная модель управления данными. Каждая из бизнес-вертикалей развивала собственные аналитические системы и хранилища, выбирая технологии и инфраструктуру независимо. В результате сформировался ландшафт из разрозненных решений с дублирующей функциональностью и растущим числом физических кластеров. На момент принятия решения о переходе в облако инфраструктура насчитывала более 10 отдельных железных кластеров под Airflow, Hadoop и смежные технологии. Совокупный объём аналитических данных достиг 0,5+ эксабайта (EB). 

Такая архитектура создавала не только технические, но и бизнес-ограничения. Обмен данными между вертикалями был затруднён: мешали как различия в инфраструктуре, так и юридические тонкости, связанные с оформлением доступа. Поддерживать такой ландшафт становилось всё сложнее. Поэтому в компании решили построить единую платформу для работы с данными, чтобы увеличить скорость и качество принятия решений на основе данных как в runtime, так и в отчётности и А/Б-тестах. 

Я Василий Ципиди, операционный руководитель OneDWH VK. Вместе с техническим руководителем OneDWH VK – Олегом Виноградовым расскажем сегодня о том, как мы подошли к миграции 0,5+ EB данных на единый облачный стек, какие архитектурные решения выбрали, чтобы обеспечить целостность данных и как перестроили процессы, чтобы гарантировать предсказуемость SLA на новых мощностях.

Почему независимые кластеры стали проблемой

Разрозненная инфраструктура создавала технический шум и формировала системные ограничения, которые проявлялись на трёх уровнях: 

• утилизация ресурсов

• затраты на сопровождение 

• и самое критичное — работа с данными

Ресурсный дисбаланс. Вычислительные мощности распределялись между продуктами неравномерно. Пока один кластер упирался в CPU, соседний простаивал на 50% — именно такой была средняя загрузка существовавших Hadoop-инсталляций. Перебросить свободные мощности между бизнес-юнитами было невозможно: каждый кластер представлял собой изолированный контур со своей командой эксплуатации, правилами квотирования и очередями задач. Эластичность отсутствовала, а буфер простаивающих ресурсов не давал возможности покрыть пиковые нагрузки соседей.

Дублирование экспертности. Сопровождение каждого крупного направления требовало до десяти инженеров. Эти команды выполняли идентичную работу: обновляли компоненты, реагировали на инциденты, управляли доступом и мигрировали ETL-пайплайны при смене версий СУБД. С ростом числа продуктов увеличивалась и команда поддержки. 

Главный барьер — работа с данными. Представьте задачу: одной команде требуются атрибуты контента, которые уже рассчитывает другая команда. Чтобы их получить, нужно:

• найти владельца объекта

• выяснить структуру схем и логику расчётов

• согласовать цель обработки и преодолеть юридические вопросы

• организовать физическую передачу данных между системами

На практике это выливалось в создание отдельной копии объекта с собственным ETL-процессом для перемещения. Данные дублировались, версии начинали расходиться, и через несколько итераций уже никто не мог гарантировать, что копия соответствует оригиналу.

Пока аналитикой занимались несколько команд, расхождения можно было разрешать прямыми договорённостями. Но когда число специалистов перевалило за сотню, а количество кросс-запросов стало исчисляться тысячами в месяц, этот подход перестал масштабироваться.

Стало очевидно: объединять нужно не только кластеры. Нужна единая платформа с унифицированными правилами работы с данными — от момента сбора до финальной витрины. 

Выбор решения и компоненты

Решение — создать единую платформу хранения, обработки, каталогизации, навигации и доступов OneDWH VK. И перенести туда все данные. Мы понимали, что просто скопировать существующие data-объекты, скрипты и права доступа на новую площадку — значит аллоцировать туда же все проблемы: дублирующиеся data-объекты, непрозрачные межобъектные зависимости и несовместимые схемы. Разрозненность останется, просто сменив физический носитель.

Мы выделили четыре ключевых задачи, которые должна была решать платформа:

• Единая инфраструктура при изоляции. Обеспечить общую вычислительную среду для 35 бизнес-вертикалей, но сохранить независимость их контуров — чтобы команда одного сервиса не влияла на производительность другого

• Отказ от копирования. Дать возможность использовать данные смежных команд без постоянного создания физических копий data-объектов. Данные должны храниться в единственном экземпляре, а доступ — предоставляться по запросу

• Прозрачность. Сделать видимыми владельцев данных, их назначение, периодичность обновления и качество. Без каталогизации любой data-объект в наших масштабах становится не ресурсом, а неизведанной территорией

• Автоматизация рутины. Сократить число ручных действий — от запроса доступа до промышленного запуска нового расчёта. Это напрямую влияло на наш целевой показатель: сокращение времени от нескольких дней до пары часов

Кроме ключевых задач, в платформе важна сценарная гибкость. Мы должны поддерживать не только классическую пакетную обработку, но и сценарии без задержки. Вертикали используют данные по-своему: отчётность может ждать обновления сутки, а рекомендации и рекламные модели требуют актуальности в реальном времени. Это означало, что архитектура должна одинаково эффективно работать и с batch, и с near real-time процессами.

Стратегия миграции. Ещё одно критическое требование — поэтапный переезд. Остановить десятки продуктов и единовременно переписать тысячи ETL-процессов было невозможно. Поэтому новая и старая инфраструктуры должны были функционировать параллельно, пока команды постепенно переносили данные и переключали потребителей на новые источники.

С этим набором требований мы перешли к выбору технологического стека. Компания решила перейти от разрозненных железных кластеров к централизованной облачной инфраструктуре One-cloud и создать self-service среду для аналитиков, data-инженеров и ML-команд. 

Ключевым архитектурным принципом OneDWH VK стала унификация доступа. Аналитики, ML-команды и часто бэкенд-разработчики получают визуальное представление унифицированного доступа данным — независимо от того, в какой вертикали эти данные были изначально созданы. Это решает сразу несколько проблем: 

• исчезает необходимость в ручной стыковке между разными системами, данные больше не нужно перекладывать из одного кластера в другой для смежного использования

• снижается порог входа — команда, которая раньше работала с ClickHouse, может без дополнительного обучения получить доступ к данным через унифицированный слой. 

Постепенно формируется единое пространство данных, где исчезает понятие «данные команды А» и «данные команды Б» — остаются данные компании, у которых есть владелец, описание и уровень доступа.

Параллельно с инженерной частью мы выстроили систему управления данными. Изначально мы договорились, что это не опциональный бонус, а обязательная часть платформы. Без неё даже самый производительный кластер быстро превращается в свалку data-объектов с непонятными названиями и устаревшими полями. На платформе разворачивается централизованный каталог данных:

• поисковая система по всем data-объектам компании с фильтрацией по вертикалям, тегам и владельцам

• система data-контрактов, которая становится обязательным условием для того, чтобы data-объект считался производственным и мог использоваться другими командами

• стандартизация описаний с едиными правилами именования схемы и унифицированным словарём бизнес-терминов 

Каждый data-объект перед публикацией в общий доступ проходит процедуру заполнения метаданных: указывается владелец, глоссарий, схема данных и инструкция по использованию. Такой подход позволяет не просто хранить данные, а управлять их жизненным циклом — от момента создания до архивного хранения, с понятным владельцем и прозрачными правилами использования для всех участников.

В итоге вместо разрозненных контуров мы получили единую мультитенантную платформу, вместо ручных запросов на доступ — self-service с прозрачными правилами, а вместо непонятных data-объектов — каталогизированное пространство с data-контрактами и ответственными владельцами. 

Почему миграция оказалась сложнее создания платформы

Построить платформу — это полдела. Настоящий вызов начался, когда мы приступили к переносу данных. На тот момент инфраструктура насчитывала более 30 тысяч уникальных data-объектов (без учёта партиций) общим объёмом свыше 0,5 EB, и миграция должна была затронуть более 2 000 сотрудников из 35 бизнес-вертикалей. Но ключевая сложность была не в объёме. Мы сознательно отказались от подхода «перенести как есть» — просто скопировать data-объекты, скрипты и права доступа на новую площадку. 

Вместо этого мы выбрали качественную трансформацию, и именно она превратила миграцию в масштабный организационный процесс, сравнимый по сложности с созданием самой платформы.

1. Каждый data-объект нужно было описать заново. Для каждого data-объекта требовалось зафиксировать:

• схему данных и набор событий

• бизнес-смысл и источники происхождения

• владельцев и потребителей

• метаинформацию о критичности влияния на компанию, сенситивности данных и SLA (например, время доступности Т-1)

Параллельно мы реализовали механизмы валидации схемы, проверки полноты, соответствия data-контракту и отсутствия дублей по источникам — базовые DQ-алерты теперь приходят из коробки на каждый новый data-объект. Без такого описания данные остаются просто набором байтов, использовать который вслепую невозможно.

2. Консолидация и дедупликация. В старой архитектуре нередко встречались ситуации, когда несколько вертикалей хранили одни и те же данные, но с разным набором параметров. Мы устанавливали единое владение для каждого объекта и производили дедупликацию, оставляя объект с наиболее богатой схемой, а менее полные версии выводили из эксплуатации. В некоторых сценариях параллельно проводилась оптимизация пайплайнов под целевой стек — это требовало глубокого погружения в логику расчётов каждой команды.

3. Процесс миграции как воронка из 10 укрупнённых этапов. Сам переезд мы выстроили как детализированную последовательность шагов для каждого объекта — будь то data-объект, ETL-процесс или внешний источник. Каждый этап мы проходили совместно с бизнес-юнитами: от аудита текущего состояния до финального переключения потребителей на новый источник. Такой подход исключал сюрпризы, но требовал колоссальной координации.

4. Перестройка модели доступа. Мы частично отказались от ручных заявок на персональный доступ к данным — в части вертикалей этот процесс уже заменён на ролевую модель. У каждого набора данных появились владелец и потребители, а также основной мастер-заказчик, который отвечает за консолидацию требований. Это исключает ситуации, когда сторонние команды могут случайно изменить или сломать чужие витрины. Взаимодействие между поставщиками и потребителями выстроено через систему контрактов: потребители формируют требования, а владельцы принимают решение о доработках. При этом сами данные не дублируются — изменения проходят через утверждения владельца либо мастер-заказчика.

Вопрос безопасности потребовал отдельной проработки. Платформа позволяет организовать кросс-использование данных между вертикалями с изоляцией на уровне групп пользователей и групп объектов. Например, бизнес-юнит 1 может предоставить данные бизнес-юниту 2 для получения новых атрибутов контента, но доступ будет ограничен конкретной группой пользователей и конкретным набором объектов. При этом учтены требования информационной безопасности: доступ к персональным данным регулируется жёсткими ограничениями.

5. Глубокая автоматизация процессов. В платформу были заложены инструменты для массового создания директорий, переноса прав и исторических данных. Всего автоматизировано более двадцати ключевых операций — без них миграция такого объёма была бы просто невозможна.

6. Отказоустойчивость с приоритетами. Благодаря проделанной работе по описанию данных, мы теперь понимаем критичность каждого процесса и его SLA. Изначально мы хотели обеспечить возможность переключения на второй кластер в случае инцидентов на Primary, но реплицировать абсолютно все процессы было бы крайне затратно с точки зрения вычислительных мощностей и объёма хранения. Поэтому мы отрастили «вторую ногу» только для критичных процессов всех вертикалей. Secondary кластер находится в режиме репликации и в случае инцидента позволяет произвести лёгкое переключение по кнопке без снижения SLA и тем более без потери данных — в OneDWH уже введена теория и обкатывается MVP политики Zero Data Loss.

7. Инструменты для пользователей. Важную роль в адаптации сыграл Data Copilot, который объединяет функции data-каталога, поиска и навигации по данным и документации YT, а также генерации YQL и CHYT-запросов. Он позволяет быстро находить нужные датасеты, понимать их структуру и получать готовые, отвалидированные запросы, которые сразу возвращают результат. До его релиза поток запросов к разработчикам мог достигать более 80 в день. Data Copilot снизил эту нагрузку на порядок, позволив командам самостоятельно исследовать данные и формировать запросы без участия инженеров.

В итоге миграция 0,5+ EB данных на новую платформу сегодня охватывает более 90% всех аналитических данных в VK. Но главный результат даже не в цифрах — мы построили процесс, в котором данные стали общим, прозрачным и контролируемым активом компании.

Что дальше

Сегодня OneDWH VK вышла на операционную зрелость — это уже не проект в стадии строительства, а работающая система, на которую переехало более 90% всех аналитических данных компании.

Главный результат — появление единой точки доступа к данным, которая полностью закрывает batch-сценарии. Аналитики, ML-инженеры и разработчики из 35 вертикалей работают в унифицированной среде: не нужно выяснять, где лежат данные и как к ним подключиться, всё доступно через единый интерфейс. Это касается как классической BI-отчётности, так и тяжёлых задач машинного обучения, включая рекомендательные системы и runtime-сервисы.

Второе важное достижение — кросс-использование данных между бизнес-юнитами перестало быть архитектурным барьером. Раньше для получения данных из соседней вертикали нужно было пройти многоступенчатый процесс согласования, теперь это рутина в рамках ролевой модели. Данные свободно используются для обогащения и построения новых признаков, что напрямую влияет на качество рекламных алгоритмов и рекомендаций во всех сервисах компании.

Целевой показатель «с нескольких дней до пары часов» для многих сценариев уже достигнут. Пользователь получает доступ через self-service в течение нескольких секунд, а не после поиска владельца, согласований и организации физической передачи данных. Каждый data-объект описан метаданными, у него есть владелец и data-контракт — пользователь перед началом работы видит структуру, периодичность обновления и степень достоверности данных, а DQ-оповещения и валидация схем работают автоматически.

Следующий шаг — развитие real-time слоя. Batch-обработка закрывает большинство потребностей, но есть сценарии, где данные нужны не с задержкой, а здесь и сейчас. Мы уже реализуем near real-time DWH (NRT DWH) с целевой задержкой менее 30 секунд. Он позволит обогащать большие объёмы данных в режиме, близком к реальному времени, использовать их для онлайн-обучения ML-моделей и генерации признаков в Feature Flow для runtime-сервисов. NRT DWH станет следующим этапом эволюции платформы, превращая OneDWH из хранилища исторических данных в единый центр обработки данных любого типа — от архивных до потоковых.

На основе этого опыта можно сформулировать несколько рекомендаций для компаний, которые сталкиваются с похожими задачами. Централизованная платформа оправдана в тех случаях, когда бизнес-процессы и сценарии использования данных относительно однородны. Если же требования сильно различаются — например, из-за регуляторных ограничений или разнообразия продуктов, — необходимо закладывать в архитектуру гибкость и возможность децентрализации. В противном случае единая система может быстро обрастать сложными доработками под каждый отдельный кейс.

Главный вывод заключается в том, что построение единого DWH — это не только технологический, но и организационный проект. Его успех определяется не столько выбором стека, сколько способностью компании договориться о единых правилах работы с данными.