Один из игроков — я, Кирилл Красновид, тимлид BI-команды в Профи.ру. Наша задача — делать так, чтобы каждый быстро и удобно получал нужную информацию без лишней суеты и ожиданий.
Поэтому мы стараемся все автоматизировать и оптимизировать. Сегодня расскажу, как решаем эти задачи, а ещё про собственные хранилища аналитиков и bus-фактор.
Bus-фактор показывает, не провалится ли проект, если кого-то из членов команды собьёт автобус. Чем выше фактор, тем меньше в этом случае пострадает работа. Например, если вся информация по проекту лежит в голове одного человека и никто не знает, чем занимается этот коллега, bus-фактор = 1. Сотрудник выпадёт из работы, и она остановится. Лучше, когда показатель равен хотя бы пяти. |
Главное, чтобы всем было удобно
Сейчас в нашей BI-команде шесть человек: четыре дата-инженера, один архитектор данных и BI-аналитик. Мы не сторонники жёсткой специализации, но по естественному стечению обстоятельств — у каждого своё направление. Например, один человек занимается хранилищем: задаёт стандарты, формализует продуктовые требования и на их основе формирует подходы к фильтрации данных. Кто-то занимается A/B-платформой и тестами, кто-то — BI и визуализацией.
Но бывает и так, что вся команда в рамках одного спринта делает один проект. В результате нет такого, что «работает специалист по A/B-платформе и он никогда голову из неё не высовывает». Нет, лучше, когда команда делится экспертизой внутри. Это улучшает и настроение, и bus-фактор.
Вшестером мы решаем задачи от аналитиков. Раньше они сами копались в копии (aka реплике) мастер-базы продукта, иногда перегружали систему. Да и в целом мастер-база крайне плохо подходит для аналитических исследований. Для таких задачи сильно эффективнее использовать специальные СУБД.
Сейчас мы делаем так, чтобы нужные аналитикам данные уже были загружены, структурированы и задокументированы на начало рабочего дня, а наша помощь требовалась только при нештатных ситуациях
Мы не просто так строим удобную систему для аналитиков. Когда они ждут данные месяцами, то начинают делать свои «мини-хранилища». Ничего другого им не остается.
Личные хранилища аналитиков дублируют основную систему и создают хаос. Повышают риски:
Вся экспертиза остается у одного человека. Часто нет ни документации, ни исходного кода. Если специалист уходит — данные и логика расчётов теряются. Вспоминаем про bus-фактор.
Такие расчёты не резервируются как положено. Риск потери данных выше, чем при работе через штатные механизмы загрузки.
Чтобы этого не происходило и аналитики не томились в ожидании, мы максимально автоматизировали постановку задач. После каждого спринта коллегам приходит сообщение: «Накидывайте задачи BI-команде на следующий спринт».
Люди оставляют запросы. В течение текущего спринта мы в фоновом режиме внимательно всё читаем и задаём уточняющие вопросы. Это нужно, чтобы к началу следующего спринта задача была чётко сформулирована и готова к разработке.
Стандартные задачи идут в спринт по обычному процессу. Глобальные запросы, например, внедрение новых инструментов, концептуальные изменения или просто ресурсоемкие задачи, мы обсуждаем отдельно.
Как работает на практике в потоковой аналитике. Аналитики уведомляют нас об отправке продуктовых событий — нажатиях кнопок, показах экранов. Мы проводим ревью изменений в конфигурации. Данные поступают в базу и появляются на витринах. Больше нашего участия в процессе нет. Аналитики сами решают, как работать с информацией.
Но коммуникация между командами — половина дела. Вторая часть — техническая. Мы построили систему, она уже неплохо работает. Теперь хотим делать её лучше: снижать вычислительную нагрузку, предоставлять данные и вносить изменения быстрее, быть готовыми к кратному росту количества данных. Сейчас расскажу, как к этому идём.
Что есть сейчас и что планируем
У нас в BI-команде две СУБД. Первая — Greenplum. Её используем для сложных джоинов. В ближайшем будущем будем переходить на CloudberryDB. Вторая — ClickHouse. Она лучше справляется с одной широкой таблицей и быстрыми агрегациями.
Данные собираем из разных источников: объединённой продуктовой базы, потоковой аналитики (в режиме реального времени и по расписанию), внешних источников, статических данных, а также через ручной ввод пользователями.
Всё складывается слоями: сначала поступают сырые данные. Затем мы формируем трансформационный слой — очищаем данные от тестовых и ошибочных записей, структурируем их. В исходном виде с ними не всегда удобно работать. Затем формируем слой витрин данных для аналитиков. Получается три слоя: исходные данные, фильтрованные сущности и готовые витрины.
Благодаря такой архитектуре аналитики могут не ходить в исходные данные. Всё уже структурировано, данные размечены, и коллеги видят нормальные колонки с готовыми метриками.
Витрины данных формируются на основе таблиц, часть из которых обновляются целиком. Там, где это возможно, мы уже реализуем инкрементальную загрузку — забираем только новые или изменённые записи. Однако универсального и надежного инструмента такой работы со всеми сущностями сейчас нет.
Есть проблема историзации данных. История изменений параметров сущностей важна и для аналитики, и для расследования инцидентов. Сейчас, если в источнике данных не предусмотрено хранение истории изменений атрибутов (SCD1), мы со своей стороны можем лишь делать слепки состояний на определенные моменты времени. Но нас это не устраивает по двум причинам:
Между моментами снятия слепков происходит множество изменений. Они остаются незамеченными.
Невозможно сделать слепок всех атрибутов всех сущностей на один момент времени. Зачем это нужно? Вот пример: есть две связанные сущности. Данные по первой сущности извлекаются в момент времени Т1, а по второй — в момент Т2. Данные по первой сущности к моменту Т2 могли претерпеть изменения. Из-за этого связность данных может нарушиться.
Мы хотим обойти все ограничения и сделать так, чтобы работа с витринами данных шла быстрее. Для этого внедряем механизм наполнения слоя сырых данных с помощью Change Data Capture или CDC — захвата изменения информации.
Так мы сможем в реальном времени получать все факты изменения данных в мастер-базе и из них восстанавливать таблицы. Не нужно будет повторно читать всю информацию, обработка будет происходить только для новых значений. Мы будем получать максимально детальную историю изменения любых сущностей.
После внедрения CDC в слой сырых данных мы сможем формировать инкрементально и следующие слои. В отдельных случаях даже работать с ними в режиме реального времени.
Есть ещё один вопрос — о вычислительных ресурсах. Пересчитывать витрины напрямую — долго и дорого. Поэтому мы планируем добавить промежуточные слои. Одно из решений — activity schema. В ней все события, от размещения заказов до действий специалистов, будут собираться в несколько больших широких таблиц по ключевым сущностям. Это снизит нагрузку, так как избавит от тяжёлых джоинов, а также упростит написание кода запросов для аналитиков.
Звучит как утопия. На самом деле есть и минусы. Такие решения, как правило, требуют большего объема дискового пространства, причём диски должны быть быстрыми. Но для нас покупать диски все равно оказывается дешевле.
Мы нашли такое решение, но с радостью почитаем и про другие практики. Ваш ход, читатели — ждём комментарии.