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

Как из такого состояния перевезти 400 петабайтов логов в единую систему и не уронить работу сервисов, расскажем в статье совместно с экспертом.

Точка кипения — технический тупик

Исторически сложилось, что часть бизнес-юнитов VK развивались со своими техническими стеками, процессами и культурой работы с данными. Со временем продолжали рождаться новые продукты. Это неизбежно вело к децентрализации. В масштабах экосистемы, объединяющей десятки продуктов, такая автономность выражалась в том числе в жесткой фрагментации на уровне работы с данными и инфраструктуры.

Проблема разрозненности данных становится критической, когда количество команд, занимающихся аналитикой, превышает возможности их прямой координации. Пока работает один отдел до 50 человек, выстроить единую платформу относительно просто. Когда же их становится больше сотни, задача усложняется.

До старта проекта OneData в ключевых подразделениях компании — Почте Mail.ru, Одноклассниках, ВКонтакте, VK Рекламе и поиске — параллельно работало пять отдельных крупных инсталляций Hadoop. Существовавший ландшафт порождал серьезную неэффективность. Суммарные вычислительные мощности использовались в среднем лишь на 50% по CPU. При этом каждый кластер требовал выделенной команды администраторов: до 10 высококвалифицированных инженеров на каждый бизнес-юнит. Фактически десятки специалистов выполняли дублирующие задачи по поддержке идентичного стека. Расходы на железо (CAPEX) и эксплуатацию (OPEX) множились, не принося добавочной ценности.

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

Выбор технологического ядра

При проектировании фундамента единой платформы данных перед командой стоял выбор между тремя способами устройства инфраструктуры.

Первый вариант — классический Hadoop (HDFS). От него решили отказаться из-за плохой масштабируемости по количеству файлов (проблемы NameNode) и сложности адаптации под современные облачные подходы. Кроме того, поиск и найм специалистов по глубокой поддержке Hadoop становился все более сложной задачей.

Второй вариант — объектное хранилище (S3). Техническая база для построения огромного S3 в компании существовала, но этот путь признали подходящим скорее для долгосрочного архива. Главным минусом S3 стала невозможность эффективной работы в режиме near real-time (NRT). Для рекомендательных систем и рекламы, где данные должны обновляться практически мгновенно, задержки S3 были неприемлемы.

В итоге выбор пал на YTsaurus . Эта технология позволила построить гибкую систему, поддерживающую и батчевую, и потоковую обработку данных. Она работает на commodity-железе, что позволило эффективно переиспользовать серверы, оставшиеся от старых Hadoop-кластеров. В реализации OneData режим NRT работает бесшовно: в зависимости от бизнес-задачи используется либо микробатчинг, либо прямой стриминг из Kafka в таблицы.

Основным интерфейсом для работы с платформой стал YQL — SQL-подобный язык запросов. Это позволило снизить порог входа: 80% повседневных задач аналитики решают с помощью знакомого синтаксиса. Для тяжелых вычислений и ML-трансформаций в платформу интегрированы Python, SPYT (Spark над YT) и CHYT (аналитический слой ClickHouse над YT), который обеспечивает минимальные задержки при доступе к витринам.

Архитектура: от сырых логов до витрин

Процесс структурирования данных разбит на несколько строго регламентированных этапов. Источниками служат Kafka, PostgreSQL и внешние системы. Для доставки данных используется LogFather — унифицированный инструмент, работающий на двух уровнях: сбор миллионов мелких событий в реальном времени и репликация целых таблиц из рабочих баз без написания ETL-кода вручную.

Внутри выстроена слоистая архитектура, обеспечивающая чистоту данных:

• RAW (Сырые данные). Здесь информация хранится в первозданном виде. В этом подспорье платформы: если в алгоритмах расчета обнаружится ошибка, наличие сырых данных позволит пересчитать все показатели с нуля за любой период.

• ODS (Operational Data Store). На этом этапе происходит первичная очистка, типизация и, что самое важное, проверка схем (Schema Validation). Если сервис-источник внезапно изменит формат лога (например, заменит числовое поле строковым), импорт в единую платформу данных будет заблокирован. Это защищает хранилище от каскадных падений и замусоривания невалидными данными.

• DDS (Detail Data Store). Слой нормализованных данных, приведенных к единому корпоративному стандарту.

• DM (Data Marts). Финальные витрины, оптимизированные под конкретные бизнес-отчеты. Благодаря ранее упомянутому CHYT, аналитики получают доступ к этим данным практически мгновенно.

Решение проблемы зоопарка идентификаторов

Одной из самых сложных инженерных задач стало приведение к общему знаменателю пользовательских идентификаторов. У каждого продукта была своя логика: в Почте это был uid, в Одноклассниках — userID, в Дзене — guid. Чтобы собрать единый профиль пользователя для сквозной аналитики, раньше требовались недели ручного маппинга и согласований.

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

Надежность данных: SLA и роль Data Owner

Чтобы платформа не превратилась в неуправляемое «болото данных», в ее архитектуру интегрированы механизмы контроля качества (Data Quality). На текущий момент в OneData полноценно функционируют два ключевых направления.

1. Контроль своевременности (SLA). Автоматизированный мониторинг в реальном времени непрерывно отслеживает график поступления информации в хранилище. В случае задержки обновления любой критически важной таблицы система в автоматическом режиме генерирует инцидент, который направляется команде владельца данных (Data Owner). Это решение выходит за рамки простой технической надстройки: для обеспечения бесперебойности приоритетных потоков данных в компании организованы дежурства в режиме 24/7.
2. Содержательный контроль (DQ-чеки). Специализированные алгоритмы-чекеры анализируют входящие потоки на предмет дублей, пропусков и различных статистических аномалий. Важной архитектурной особенностью является работа этих проверок в режиме уведомлений. Они не прерывают выполнение расчетов, чтобы не парализовать работу бизнес-юнитов, но при этом мгновенно оповещают потребителей о возникновении проблем в конкретной витрине. Такой подход позволяет сохранить непрерывность бизнес-процессов, одновременно информируя аналитиков о качестве доступных цифр.

Параллельно ведется подготовка к внедрению системы oneEtl. В перспективе этот механизм обеспечит полную прозрачность всей цепочки вычислений, позволяя проследить путь любой цифры в финальном отчете до самого первого лога в слое RAW. Реализация этого компонента призвана окончательно снять вопросы к качеству данных и значительно упростить поиск причин при расхождении метрик в разных отчетах.

Организационный вызов: песочницы и учения

Миграция более 400 ПБ данных из пяти разрозненных кластеров в единую платформу данных стала не только техническим, но и сложнейшим управленческим испытанием. Команды на местах часто сопротивлялись переезду. Юниты боялись потери контроля над своими процессами и не хотели тратить дефицитный ресурс разработчиков на переписывание старых скриптов с Hadoop.

Для преодоления барьера команда инфраструктуры использовала тактику учений. Заранее объявлялись даты физического вывода из эксплуатации старых Hadoop-кластеров, и проводились пробные кратковременные отключения. Это стало лучшим стимулом для бизнес-юнитов завершить миграцию в установленные сроки. Чтобы облегчить процесс, была организована масштабная поддержка: видеокурсы, чаты с экспертами и запуск ИИ-помощника Data Copilot. Основную нагрузку по переносу кода взяли на себя DWH-аналитики, что позволило продуктовым командам не останавливать разработку фич.

Для безопасного сосуществования 35 юнитов в одном контуре были внедрены песочницы (Unit Sandboxes). Каждый продукт работает в своем изолированном сегменте, имея доступ к общим справочникам и возможность делиться своими данными с другими командами внутри группы. Изменение данных в общих критических слоях требует обязательного ревью от Data Owner. Также внедрена строгая ролевая модель доступа: права выдаются персонально под задачу, а системы безопасности мониторят подозрительные паттерны активности (например, попытки выгрузки больших объемов данных за пределы контура).

Результаты для бизнеса: DevEx и A/B-тестирование

Главным итогом создания единой платформы данных стало кратное ускорение работы с данными (Time-to-Insight).

Благодаря автоматизации и внедрению Self-Service инструментов, скорость работы аналитиков с кросс-данными выросла в разы. Сегодня создание тестовой таблицы в песочнице для проверки гипотезы занимает около 1 часа. Вывод полноценного кода в продакшн с учетом всех доступов, автоматических проверок, ревью и постановки на расписание, сократился до 1–2 дней. Раньше этот процесс мог растягиваться на недели из-за межкомандных взаимодействий.

На базе платформы была развернута единая А/В-платформа. Это позволило внедрить общую методологию экспериментов по всей группе компаний. Теперь менеджеры продуктов могут корректно оценивать сквозные эффекты: например, как изменение алгоритма в одном сервисе влияет на вовлеченность пользователей в другом.

Будущее платформы: ИИ и глобальная дедупликация

Процесс развития OneData продолжается. Главная цель на ближайшее время — завершение миграции крупнейших проектов, включая ВКонтакте. Полный вывод из эксплуатации (EOL) всех старых разрозненных хранилищ Hadoop намечен на конец 2026 года.

За счет устранения дублирования данных и отказа от избыточного хранения объем информации только в рекламном контуре должен сократиться в три раза — со 100 ПБ до 30 ПБ. При этом платформа уже сегодня эффективно оперирует объемами в сотни петабайт.

Важным направлением станет интеграция ИИ в работу с данными. Чат-бот Data Copilot уже помогает аналитикам ориентироваться в тысячах таблиц и генерировать рабочий YQL-код по текстовому запросу, опираясь на внутренние метаданные о структуре платформы данных. В планах — интеграция этого функционала напрямую в интерфейсы разработки (IDE), что позволит еще сильнее сократить путь от бизнес-гипотезы до конкретных показателей.

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