Обмен данными между компаниями-партнерами при реализации совместных проектов — стандартная практика. Но часто есть сценарии, которые требуют особого подхода — например, из-за необходимости подстраивать формат отображения данных под специфику работы с информацией на стороне партнера. Более специфической такая задача становится, если готовых решений под такие запросы нет. С подобной ситуацией сталкивались и мы в VK.
Меня зовут Елена Климанова. Я ведущий дата-аналитик в компании VK. В этой статье расскажу, как и почему мы прошли путь от использования excel-файлов при работе с внешними партнерами-вендорами до создания собственного продукта.
Немного о сути задачи
Компания VK сотрудничает с рядом зарубежных производителей мобильных устройств, среди них Xiaomi, Oppo, Realme, Transsion и т. д., которые предустанавливают на свои устройства наши основные мобильные приложения:
VK Видео;
Одноклассники;
Облако;
VK Музыка;
Дзен.
С нашей стороны партнерам предоставляется статистика по первым запускам приложения на устройствах.
Для сбора статистики мы используем MyTracker — мультиплатформенную систему аналитики и атрибуции для мобильных приложений и сайтов.
По трекингу предустановок в MyTracker используем два способа:
PAI (Google Play Auto Install) — вендору передается источник перехода.
System Properties — вендору передается ключ.
Изначально мы выгружали статистику в excel-таблицы, но со временем партнеры запросили:
постоянный доступ к данным (без ожидания ежемесячной выгрузки);
гибкие отчеты с возможностью менять периоды, строить графики, анализировать динамику;
автоматические дашборды для визуализации данных;
выгрузку в разных форматах (xlsx, pdf).
Ручная работа с Excel перестала масштабироваться, и нам потребовалось новое решение. Соответственно, перед нами встала задача — заменить excel-файлы на какую-нибудь реализацию, отвечающую новым запросам.
Первый вызов
Предоставить вендорам доступ к статистике трекинга предустановок не получилось, так как в личном кабинете, как и в некоторых других системах веб-аналитики, например Google Analytics, нет возможности ограничить количество доступных метрик в рамках кампании. В связи с этим мы начали исследовать другие способы безопасного обмена данными и разрабатывать собственное решение. Параллельно с этим мы обратились к команде MyTracker с запросом. Она откликнулась и сообщила о том, что разработка нового функционала, который позволит предоставить ограниченный доступ не только для конкретного личного кабинета, но и для конкретной метрики и среза, пока планируется к реализации.
Построение первой реализации
Чтобы построить нужное нам решение с минимальными издержками и без привлечения команды разработчиков, мы собрали «конструктор» из готовых сервисов и инструментов. Среди них:
планировщик задач Microsoft;
MyTracker (наш сервис аналитики);
Google Sheets — онлайн-редактор для создания электронных таблиц;
Looker Studio — онлайн-инструмент для преобразования данных в настраиваемые отчеты и дашборды.
На основе этих компонентов мы настроили следующий пайплайн:
В 9:00 планировщик задач Microsoft запускает скрипт на Python.
Скрипт обращается к MyTracker и запрашивает данные по активациям мобильных приложений.
По API эти данные передаются в Google Sheets.
Из Google Sheets данные поступают в Looker Studio.
В Looker Studio данные преобразуются и передаются в разные дашборды.
На дашборд выводится вся актуальная информация по устройствам, активированным приложениям и времени активации. Причем все данные можно фильтровать, отслеживать по периодам и в динамике. Кроме того, отчеты из дашборда можно выгрузить в xlsx или pdf.
Таким образом в этой реализации:
Автоматизация сбора статистики на уровне физической машины.
Разные дашборды для каждого партнера.
Гибкие отчеты без ручных выгрузок.
Снова вызов
Пайплайн работает стабильно и решает поставленные задачи. Поэтому в теории можно довольствоваться текущей реализацией.
Если бы не одно но — часть реализации завязана на решениях зарубежных вендоров, и это создает определенные трудности. Например, Looker Studio уже не работает без VPN, а корпоративные сервисы Google и вовсе заблокированы на территории РФ. Дополнительно у партнеров появилась потребность получать исторические данные с учетом обновлений.
В связи с этим нам потребовалось найти новое решение для сбора, хранения и визуализации данных в дашбордах.
Таким образом мы пришли к реализации MVP v2.
Переход ко второй реализации
Чтобы уйти от существующих ограничений и минимизировать риски ужесточения vendor lock-in, мы решили начать постепенный переход к новой реализации на основе доступных нам инструментов, а именно — сервисов на платформе VK Cloud.
Так, в рамках новой реализации мы решили применить:
MyTracker (наш сервис аналитики);
Cloud Airflow (в составе Cloud Big Data) — решение, которое используется для разработки, оркестрации, планирования и мониторинга сложных ETL-процессов;
ClickHouse — управляемую и масштабируемую СУБД для быстрой аналитики данных;
Metabase или Redash (из магазина приложений VK Cloud) в качестве основной BI-системы.
Алгоритм работы на основе этих компонентов будет следующий:
Cloud Airflow будет забирать данные из MyTracker и передавать в ClickHouse;
из ClickHouse данные будут поступать в BI;
в BI данные будут выгружаться в нужные дашборды (отдельно для каждого партнера-вендора).
В такой реализации мы сможем уйти от рисков vendor lock, преобразовывать и отдавать партнерам данные с заданной частотой в нужном формате.
Мы уже работаем над построением этого пайплайна. Так, к февралю 2025 года мы:
Развернули четыре виртуальные машины с внутренними и внешними IP-адресами: для базы данных ClickHouse, для Redash, две ВМ под Kubernetes для Airflow.
Подключили Redash к БД ClickHouse. Создали тестовый дашборд и запустили тестирование разных видов доступа к данным.
В рамках проверки гипотезы развернули альтернативный сервис дашбордов Metabase. Сейчас идет тестирование разных видов доступа к данным.
Создан контейнер для данных Kubernetes, необходимый для установки AirFlow.
При этом во время тестов Redash и Metabase показали свои узкие места в контексте нашего кейса:
Redash недостаточно гибкий в контексте настройки функционала и разграничения доступов. Так, мы хотим иметь единую базу данных и предоставлять партнерам доступ только к отдельным ее строкам или колонкам. А в Redash «из коробки» сделать это сложно — данные надо разбивать на отдельные таблицы еще на стороне ClickHouse, что усложняет весь пайплайн. Более того, если мы на своей стороне запрещаем доступ ко всей БД, то конечные пользователи не могут выгрузить данные из таблицы.
Бесплатная версия Metabase, так же как и Redash, не поддерживает RLS (Row-Level Security) — механизм разграничения прав доступа к отдельным строкам данных. Нет расширенных алертов (например, на основе условий). Нет официального лимита на число пользователей, но производительность зависит от мощности сервера. При большом количестве пользователей могут потребоваться оптимизация или переход на платную версию. Это создает риски недостаточной масштабируемости и нехватки вычислительных ресурсов.
Поэтому сейчас мы также заняты проработкой возможности использования Superset — инструмент позволяет более гибко управлять правами доступа и настраивать дашборды, а у нас есть опыт работы с ним (в маркетплейсе VK Cloud есть доработанная версия Суперсет ТА).
Что в итоге
Умение быстро адаптироваться к новым требованиям и вызовам — один из ключевых навыков ИТ-команд. В этом на своем опыте убедилась и наша команда аналитики.
Безусловно, такая трансформация на лету создает дополнительные издержки, в том числе часто подразумевает получение компетенций в работе с новыми инструментами. Но при правильном подходе издержки можно свести к минимуму — например, мы этого достигли благодаря применению технологий, с которыми знакомы, и использованию облачных сервисов, которые не нужно самостоятельно развертывать, настраивать и администрировать.
Сейчас мы продолжаем работу над новой реализацией на основе сервисов VK Cloud — к концу 2025 года планируем полностью перейти на нее. О том, как продвигается разработка и что получится в итоге, мы обязательно расскажем в одной из следующих статей.