Как из такого состояния перевезти 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), что позволит еще сильнее сократить путь от бизнес-гипотезы до конкретных показателей.

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

• Легислатура Мэна одобрила LD 307 — первый в США мораторий на выдачу разрешений для дата-центров мощнее 20 МВт. Действует до ноября 2027 года.
• Поводом стали два громких провала: проект на $5 млрд в Wiscasset (жители заблокировали из-за закрытого NDA и размещения на общественной земле) и проект на $300 млн в Lewiston (городской совет единогласно отклонил из-за нагрузки на сеть).
• По данным Data Center Watch, за последние два года по США заблокировано или отложено проектов дата-центров примерно на $64 млрд.
• Сейчас дата-центры потребляют около 4% электричества США; к 2030 году цифра может удвоиться — это давит на тарифы везде, где идёт ИИ-стройка.

Что именно приняли

LD 307 временно запрещает штату и муниципалитетам выдавать разрешения на дата-центры с подключённой мощностью более 20 МВт. 20 МВт — это порог, ниже которого остаются небольшие корпоративные и колокейшен-объекты, но выше него начинается всё, что строят гиперскейлеры под ИИ-нагрузки: кластеры на тысячи GPU уходят за 50–100 МВт легко.

Мораторий действует до 1 ноября 2027 года. За это время новая Data Center Coordination Council должна изучить, как такие объекты влияют на изношенную электросеть штата, и предложить постоянные правила. Губернатор Джанет Миллс (демократ) поддерживает паузу.

«Взять эту паузу сейчас — критически важно», — заявил член палаты представителей Кристофер Кесслер со ссылкой на Maine Public Radio. Застройщик Тони Макдональд назвал новые ограничения «катастрофическими» и пожаловался, что его команда «попала в эту облаву».

Почему именно Мэн

Формально инициатива на уровне штата — но раскатал её конкретный провал в Lewiston. В декабре 2025 года городской совет единогласно зарубил проект дата-центра на $300 млн внутри старого текстильного комплекса Bates Mill. Детали проекта вскрылись за шесть дней до голосования — и жители успели поднять шум вокруг расхода воды и нагрузки на сеть. Показательная деталь: раньше в том же здании сидел колл-центр TD Bank на тысячу с лишним рабочих мест, а дата-центр обещал дать всего около 30.

За месяц до этого в городе Wiscasset так же жёстко слили проект на $5 млрд. Недовольство вызвали закрытое NDA, которое город подписал с застройщиком, и размещение объекта на общественной земле. Также в подвешенном состоянии находятся площадки в Jay (на месте бывшего бумажного комбината), в Sanford и на Loring Air Force Base.

У штата и так один из самых высоких в стране жилых тарифов на электричество — поэтому идея подключать к изношенной сети нагрузку в сотни мегаватт, где один объект жрёт как небольшой город, прозвучала как «за чей счёт банкет». Отсюда и скорость, с которой мораторий прошёл легислатуру.

Не только Мэн: кто ещё тормозит

По данным Data Center Watch, за последние два года по США заблокировано или отложено проектов дата-центров примерно на $64 млрд. Локальные паузы уже ввели округа в Мичигане и Индиане. Города от Денвера до Детройта обсуждают похожие ограничения — и это ещё до того, как мэнский прецедент начнёт раскатываться дальше.

Сейчас дата-центры потребляют около 4% электричества США. Прогнозы сходятся на том, что к 2030 году цифра может удвоиться — в основном за счёт ИИ-нагрузок. Экономист Анирбан Басу назвал решение Мэна «канарейкой в шахте» для сопротивления штатов энергоаппетитам бигтеха.

Что это значит для разработчиков

Прямого эффекта «AWS завтра подорожает» ждать не стоит: Мэн — не главный ИИ-хаб США. Но если прецедент подхватят более жирные штаты (а к этому сейчас движется дискуссия в Вирджинии и Техасе, где сконцентрирована бо́льшая часть американских ЦОДов), сроки запуска нового железа у гиперскейлеров (то есть Google, AWS, Microsoft, Meta и прочих операторов гигаваттных ЦОДов) поедут вправо. Дефицит capacity — это классический триггер для роста цен на облачные инстансы и, особенно, на GPU-мощности для обучения моделей.

Российским командам это косвенно важно по двум линиям. Первая — мировые цены на ИИ-инференс: даже если вы работаете с российскими провайдерами вроде Yandex Cloud, VK Cloud или Cloud.ru, тарифы на GPU формируются под влиянием глобального дефицита H100 и B200. Вторая — локальная повестка: в России тоже регулярно вспыхивают истории про нагрузку ЦОДов на регионы, и мэнский сценарий даёт удобную шпаргалку, чего ждать от публичной дискуссии. Что конкретно стоит начать делать уже сейчас: следить за новостями по Вирджинии и Техасу как по раннему индикатору; закладывать в годовые GPU-бюджеты диапазон неопределённости на случай роста цен; мониторить spot-рынки H100/B200 у российских провайдеров — там первый эффект виден быстрее всего.

Источники: Gadget Review, Bangor Daily News, Data Center Watch.