Продуктовый аналитик: Путешествие туда и обратно

Глава 2. Кузница оружия

2.2. Алхимия данных: от руды к слитку мифрила

Наставник даёт вам первые инструменты. Здесь, в грохоте ETL-процессов и мерцании строк кода, вы куете своё оружие для будущих битв в загадочном и прекрасном мире аналитики больших данных.
-Data Warehouse (DWH)
-Партицирование
-MapReduce
-Принцип трехслойной архитектуры
-Кто за что отвечает

2.2.1. Data Warehouse (DWH)

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

Data Warehouse (DWH) это структурированное хранилище табличных данных для быстрого чтения и анализа больших объемов данных, то есть идеален для аналитиков. Здесь данные структурированы, оптимизированы для запросов и обогащены. Структура DWH предполагает колоночное хранение данных с жесткой схемой их организации. Среди принципов проектирования DWH есть три, на которые вам, как аналитику, необходимо обратить внимание.

Партицирование

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

Таким образом, партицирование полезно для ускорения запросов и эффективного управления данными (чтение/перезапись только нужных партиций), а также распараллеливания обработки (например, MapReduce). Но не нужно злоупотреблять партицированием, ведь каждая партиция это отдельный файл. Считается оптимальным примерно 10-100 тысяч партиций на таблицу.

MapReduce

Если у вас очень много данных, например 1PB, а одна машина обрабатывает 100MB/сек то у вас уйдет на обработку 10000 секунд (1PB / 100MB/сек). Но если бы 1000 машин работали параллельно, то справились бы с задачей всего за 10 секунд. И это выгоднее, ведь дешевле иметь 1000 слабых машин, объединенных в одну сеть, чем одну супермашину, которая в 1000 раз быстрее. Такая параллельная обработка это и есть фаза «Map». После чего эти собранные кусочки нужно сгруппировать (фаза «Shuffle») и посчитать результат в каждой сформированной группе (фаза «Reduce»). Посчитать результат или пользовательскую функцию, например, сумму чисел, провести трансформацию данных или записать результаты запроса в базу данных.

Вам, как аналитику, необходимо понимать, что каждый ваш SQL-запрос превращается в MapReduce-подобные операции. Самая «тяжелая» стадия из них обычно «Shuffle», поэтому избегайте больших GROUP BY и JOIN. Сейчас MapReduce может быть уже устаревшим инструментом, но понимание его принципов помогает понять, как работают высокоуровневые инструменты BigData.

Принцип трехслойной архитектуры DWH

Слой 1. Staging (сырые данные). Загрузка в DWH точной, но управляемой внутри DWH копии данных из источников. Это только загрузка без внесения бизнес-логики, но с добавлением технических метаданных (время загрузки, источник). Если что-то пошло не так на следующих слоях, вы всегда можете вернуться сюда и все восстановить.

Слой 2. Core (ядро, бизнес-сущности). Сырые данные трансформируются с учетом бизнес-логики:
-объединение и обогащение данных из разных источников,
-обработка ошибок (дедупликация, заполнение пропусков),
-стандартизация (единые форматы, справочники),
-создание согласованных бизнес-сущностей, например, users, sessions, transactions и т.д.
Качество данных в Core критически важно, отсюда идут все аналитические данные.

Слой 3. Mart (витрины, готовые для анализа). Это удобные, оптимизированные таблицы для конкретных бизнес-задач разных команд или дашбордов. Каждая витрина решает свою задачу оптимальным способом. Когда вы создаете такие витрины, продумайте заранее их дальнейшее использование. Помните, что каждая витрина должна иметь владельца и четкую документацию, из которой понятно, как считается каждая метрика, и откуда берется.

2.2.2. Кто за что отвечает

Взаимодействие этих ролей обеспечивает передачу данных от ископаемой руды (логов) к слитку драгоценного мифрила (витрине данных).

Генерация и сбор событий (логирование)
-Аналитик после чтения гейм-дизайнерской документации (ГДД) с описанием, например, новой механики, формулирует бизнес-требования к логированию и ставит на разработчиков задачу (ТЗ).
-Разработчик внедряет код логирования (например, при нажатии кнопки покупки в игре) в соответствии с требованиями. Отвечает за корректность кода и структуру события на выходе (например, JSON-объект).

Доставка данных в DWH (Staging слой)
-Data/Platform Engineer (Инженер данных или платформы), DevOps/SRE Engineer настраивают и поддерживают кластеры брокеров сообщений (Kafka), чтобы все сервисы могли подключиться и отправлять/получать данные.
-Data Engineer (Инженер данных), Analytics Engineer (Аналитический инженер) пишут и поддерживают пайплайны (скрипты по последовательным операциям преобразования данных, часто оркеструются в Airflow), которые забирают данные из Kafka и выгружают в Staging слой DWH в виде партицированных файлов.

Core слой
-Analytics Engineer, Data Analyst очищают сырые данные, соединяют и превращают в бизнес-сущности. Они пишут SQL-трансформации (часто с использованием dbt - data build tool): очистка, объединение (join) сырых событий и создание ключевых бизнес-таблицы (например, sessions, new_users, financial_transactions и т.д.).
-Data Engineer помогает с инфраструктурой (оптимизация DWH, настройка Airflow для запуска пайплайнов).

Mart-слой (аналитические витрины)
Витрины могут создавать Analytics Engineer, Data Analyst и вы как Product Analyst. Важно, что продуктовый аналитик часто сам должен уметь создавать или дорабатывать витрины с помощью того же dbt, если в компании принята культура “self-service”. Только так продуктовый аналитик перестает быть просто пользователем «волшебной» таблицы, которую неизвестно как и кто собрал.

Я абсолютно уверен, что настоящий герой легенд должен уметь самостоятельно писать витрины данных и понимать как устроена система BigData, владеть «алхимией данных».

2.2.3. Алхимия данных

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

-На этапе логирования (Staging) формулируя ТЗ на логирование, сразу думайте, как событие будет выглядеть в виде таблицы. Проектируйте JSON-схему события так, чтобы ключевые параметры (например, item_id, transaction_id) были вынесены на верхний уровень и были атомарными. Это упростит жизнь всем на следующих этапах.

-На этапе Core активно участвуйте в ревью dbt-моделей, которые создают ключевые сущности (например, sessions). Задавайте вопросы: как обрабатываются краевые случаи? Как определяется new_user? Ваше предметное знание игры критически важно для качества этого слоя.

-На этапе Mart создавая витрину, помните о партицировании и избегании тяжелых JOIN. Всегда задавайтесь вопросом: «Кто еще, кроме меня, может использовать эту таблицу?». Документируйте не только метрики, но и их ограничения (например, «метрика считается с 2023-05-10 после фикса логирования»).

-Культура Self-Service. Умение написать производственную dbt-модель - это новый must-have навык современного аналитика в BigTech. Начните с малого: возьмите существующую витрину, изучите ее код, предложите оптимизацию или создайте ее упрощенную копию для своего эксперимента. Data-инженеры не «волшебники», но ваши союзники.

Вы как продуктовый аналитик владеете уникальным контекстом: понимаете и игровую механику, и язык данных. Используйте эту силу! Глубокое понимание стека позволяет вам не просто запрашивать данные, а формировать их, повышая скорость и качество аналитики для всей компании. Ваша ценность вырастет экспоненциально, когда вы переходите от потребления данных к их созданию и управлению. Каждый шаг делает вас незаменимым специалистом в data-driven компании.