Меня зовут Женя, в Авито я руковожу юнитом DWH. Мы отвечаем за работу с аналитическим хранилищем, которое помогает нашим сотрудникам принимать решения, основанные на данных. 

В статье расскажу, как продуктовый взгляд помогает нам развивать DWH и быть полезнее для пользователей. Речь пойдёт про появление платформенных инструментов и рост проникновения аналитики в компании, а также про реорганизацию команды и перераспределение задач. Будет больше о процессах и практиках, чем о хардкорных технологиях. Но и технологии немного затрону.  

Зарождение аналитики в Авито

Аналитика в Авито начала активно развиваться в 2013 году. Мы хотели сделать расширяемую BI-платформу, чтобы растить бизнес на основе данных. Ключевым требованием к платформе стала практически неограниченная расширяемость — как по объёмам и скорости сбора, хранения и обработки данных, так и по их сложности.

Начали с сочетания Vertica и Tableau, чтобы осуществить быстрый старт. На тот момент у нас было порядка 50 Tb данных, 6 дата-инженеров и 25 пользователей-аналитиков. Подробнее почитать про задачи и выбор решения можно в кейсе Vertica. 

Две типовые задачи, которые решала DWH-команда — это построение витрин и загрузка данных (ETL). 

Витрины. Задачи на построение витрин выглядели как описание структуры отчёта, который хотелось получить. Нужно было разобраться с бизнес-логикой, закодить её на SQL и Python, и дальше внедрить это в прод. Такие задачи занимали достаточно много времени: заказчикам приходилось ждать спринтов разработки, а нам — заниматься рутиной. 

ETL. Аналогичные тенденции прослеживались и в ETL-задачах, связанных с загрузкой данных. В них тоже описывалась бизнес-логика: что и куда загрузить. Команде DWH приходилось писать типовой код, чтобы реализовать требуемую раскладку данных в хранилище. 

Платформизация

На первом этапе перед нами встали два вопроса: 

• Как справиться с ростом задач, если Авито и его аналитика активно растут?

• Как не погрязнуть в рутине?

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

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

После внедрения платформенных инструментов, решения типовых задач стали выглядеть иначе. 

Витрины. Задачи, связанные с витринами, стали представлять из себя пул-реквесты. Пользователь-аналитик может создать пул-реквест сам, написав код на SQL. Чтобы расчёт новой витрины не нарушил работоспособность всего хранилища, появились автотесты, которые проверяют стандарты кода, оптимальность запросов, потребление технических ресурсов и тому подобное. Если тесты прошли, то мы в команде DWH мёржим реквест, и он встаёт на регулярный расчёт. 

Через механизм пул-реквестов удалось создать больше 800 ежедневных расчётов. Также мы создали инструмент оркестрации, который позволяет управлять зависимостями расчётов и считать их в оптимальном порядке. 

ETL. Для решения ETL-задач мы сделали механизм, с помощью которого аналитики могут делать раскладку данных самостоятельно. В таске в Jira фиксируется наименование сервиса, бизнес-смысл данных и сценарии их использования. А сама бизнес-логика реализуется в пул-реквесте, он также проходит тесты и мёржится в прод. 

В пул-реквесте нужно описать внешний источник, как экстрактить данные и как раскладывать их в хранилище. Все загрузки строятся в SQL, можно прозрачно видеть, что куда раскладывается и управлять версиями в Git.  

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

Продуктовый подход к DWH

Продукт — это то, у чего есть целевая аудитория и что приносит этой аудитории ценность. Основные пользователи DWH — это аналитики, инженеры и менеджеры продукта. Верхнеуровневая ценность нашей команды для них в том, что мы помогаем принимать решения на данных. Это важная задача, поскольку Авито — data-driven компания. Мы используем данные и метрики для решений в продукте и постановки целей всех команд. 

Для взгляда на DWH как продукт мы использовали две практики: user story mapping и customer development.  

User story mapping. Эта практика помогла нам визуализировать и лучше представить продукт и задачи, которые мы решаем. Мы составили карту, где отразили всё, что делают наши пользователи. В Miro для этого есть классный плагин. 

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

1. Найти данные. 

2. Провалидировать их. 

3. Понять, как ими пользоваться. 

4. Получить ответ на изначальный вопрос. 

5. Поделиться результатами.

По каждой части задачи мы накидывали идеи о том, как её сейчас решают пользователи и как можно её реализовать, если готового инструмента ещё нет.  

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

Концепцию того, как можно это сделать, я подсмотрел у Джеффа Паттона. При нарезании возникают вопросы с тем, какого объёма должна быть каждая часть предстоящей работы. Мне понравилась аналогия с тем, чтобы вместо свадебного торта делать капкейки. Финальные задачи должны представлять собой ценные части продукта, которые сами по себе полезны, но изготовляются гораздо быстрее, чем весь продукт в целом. Используя такую аналогию, можно декомпозировать истории и структурировать продуктовый бэклог.      

Customer development. Практику customer development мы использовали, чтобы понять, как люди пользуются DWH, лучше понять их потребности, проверить свои гипотезы и собрать обратную связь. 

Идея состоит в том, что мы задаём пользователям определённые вопросы. Они помогают понять, в чём люди видят ценность продукта. Вот несколько примеров таких вопросов: 

• В чём для вас главная ценность продукта?

• Что изменится, если продукта не будет?

• Какой продукт служит альтернативой? 

• Есть ли факторы, которые мешают вам пользоваться текущим решением? 

Несколько советов по проведению интервью с пользователями:

• Нужно заранее представлять, что мы хотим получить от встречи. В этом поможет предварительно написанный сценарий или хотя бы канва разговора. 

• Все вопросы должны быть открытыми, ведь прежде всего мы хотим услышать развёрнутый ответ. 

• Бывает полезно уточнить, правильно ли мы поняли респондента. Поможет формулировка «правильно ли я понимаю, что?»

• Важно задавать вопросы про прошлое, а не про будущее. 

• Мы интересуемся фактами, а не мнениями и оценками.  

• Полезная практика — «5 почему», чтобы докопаться до сути проблемы. 

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

Решение проблем пользователей

Во время общения с пользователями мы выявили ряд проблем, которые начали постепенно решать. Приведу пару примеров. 

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

Данные искать сложно. Чаще всего приходится искать человека, который знает, где что лежит и как работает.

Регулярно приходится обращаться в чаты в Слаке, чтобы понять, есть ли та или иная информация в Вертике. Мне кажется, очень не хватает описания ДДС-таблиц.

Мы хотели упростить работу с хранилищем и упростить процесс валидации данных. Так появилась система поиска dwh-docs.  

Cистема позволяет: 

• Искать таблицы и отчёты по поисковому запросу. Dwh-docs ищет по данным из документации, Jira-задачам, коду витрин, названиям таблиц и колонок.

• Документировать свои таблицы и отчёты.

• Видеть некоторые аномалии в данных. Это помогает пользователям понять, что теми или иными данными сейчас, возможно, не стоит пользоваться, потому что в них есть известная проблема. 

• Подписываться на объекты. Подписка позволяет получить пуш-уведомление, если что-то произошло с твоими данными. 

Проблема DBeaver. Другая проблема, с которой сталкивались наши пользователи, была связана с созданием запросов и вообще порогом входа в хранилище. Мы использовали бесплатный SQL-клиент DBeaver, который стал неудобен с появлением высокоуровневых бизнес-пользователей.

Интерфейс неудобный, сложные настройки, после обновления периодически ломается, например, работа с параметрами. Трудно настраивать клиент самому, аналитик помогал выбрать драйвер и ещё что-то. Не так много документации в интернете.

DBeaver достаточно сложно настраивать. Мы ставили себе вызов демократизировать аналитику и делать её доступной всё более широкому кругу пользователей. Решить этот вызов с использованием готового инструмента было проблематично. Мы решили создать свой SQL-клиент в браузере и поддержать в нём все нужные базы данных: Vertica, ClickHouse, PostgreSQL. За основу взяли sqlpad.io и кастомизировали под себя.

Новый клиент позволяет нам шарить запросы. Приведу пример. Менеджер продукта, у которого возникает вопрос по данным, обычно идёт к аналитику. Аналитик пишет запрос и отправляет ссылку на этот запрос продакту. По ссылке тот может увидеть и сам запрос, и его результаты. В будущем менеджер продукта может поменять какие-то параметры (например, дату) и ответить на вопрос уже самостоятельно. Эта штука действительно сработала, и нам удалось понизить порог входа к данным.

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

Аналогично тестам на витрины, в sqlpad мы добавили проверки планов adhoc-запросов. Таким образом мы страхуемся от того, что пользователь обрушит работу хранилища плохим запросом. Также мы можем делать подсказки, как улучшить производительность запроса.

Внедрив SQL-клиент мы заметили, что доля пользователей DWH среди авитовцев выросла. А новые сотрудники теперь пользуются только sqlpad и забыли про DBeaver.

Проблемы структуры

На этапе, когда мы перешли к созданию единых платформенных инструментов для пользователей аналитики, DWH развивали две команды: dwh-growth и dwh-infra.  

Люди в dwh-growth фокусировались на том, чтобы наращивать скорость решения аналитических задач. Они помогали искать данные, строить отчёты, проверять гипотезы, развивали фреймворки и придумывали, что делать, если фреймворка для конкретной задачи ещё нет. 

Команда dwh-infra отвечала за развитие инфраструктуры. Для работы высокоуровневых инструментов важно, чтобы платформа корректно функционировала, базы быстро отвечали на запросы, а сами данные были качественными и очищенными от ботов. Другая активность инфраструктурной команды была связана с уходом в realtime. 

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

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

Разделение команды

За основу для декомпозиции команд мы взяли высокоуровневые задачи пользователей из user story map. В теории получилась такая организация:

Для каждой команды мы сформировали пул задач, над которыми она будет работать. Туда вошли и пользовательские задачи и декомпозированные внутренние. 

Задачи команды Integration: 

Задачи команды Datamart: 

Задачи команды Usage:

С разделением команд, основанном на высокоуровневых задачах пользователей, мы пришли к тому, что:

• В каждой команде есть и некоторая рутина, и вдохновляющая цель. За счёт того, что есть рутинная часть, есть и стимул к автоматизации и тому, чтобы создавать инструменты, которые позволят упростить решение таких задач. 

• Команда фокусируется на определённом экспертном поле: загрузке данных, построении регулярных отчётов, быстрой проверке гипотез. 

• Распределение задач достаточно прозрачное.

• Получилось поделить взаимодействие с пользователями, и мы можем масштабироваться. 

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

Идея здесь в том, что ответственность за работу команды лежит на команде. Отдавая ребятам возможность выбирать самим, мы покрыли много дополнительных факторов, которые могли не учесть, если бы делили людей самостоятельно. 

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

Выводы и планы

Мы пришли к такому взгляду на DWH как на продукт, у которого есть два типа пользователей: 

1. Те, кто производят данные. Это более технические пользователи — аналитики-контрибьюторы и инженеры, которые загружают данные и строят над ними отчёты.

2. Те, кто используют данные. Менеджеры продукта и аналитики, которые ищут данные, проверяют гипотезы и отвечают на вопросы бизнеса. 

Сейчас мы собираем данные в DWH более чем из сотни внутренних и внешних источников. Наше хранилище выросло до 1 Pb, мы по-прежнему используем Vertica, к которой добавился ClickHouse, куда мы вынесли весь ClickStream. Для визуализации используем Tableau, сейчас в нём порядка 3300 отчётов. У нас 300 внутренних пользователей и около 50 сервисов, которые получают и используют данные из хранилища автоматически.

То, куда мы хотим двигаться дальше, можно описать в двух словах: демократизация аналитики. Мы хотим, сделать так, чтобы работа с данными и принятие решений на данных было как можно проще для высокоуровневых пользователей. Для этого мы будем продолжать развивать и продвигать концепцию self-service и доведём ETL и систему пересчётов до того уровня, чтобы все пользователи могли сделать простую задачу самостоятельно. 

Другая важная проблема связана с доверием к данным. Мы хотим сделать понятный и прозрачный критерий доверия, который будет иметь численное отражение в системе. Третье направление, куда мы идём, связано с realtime-аналитикой. Мы уже очень хорошо умеем строить аналитику T-1, но этого недостаточно. Мы сняли технические блокеры с этой задачи, внедрив ClickHouse, но дальше предстоит внедрение продуктового применения наших решений. 

Мы планируем развивать аналитику под ключ, ведь Авито ещё больше растёт, и у нас появляются всё более крупные бизнес-юниты. У них могут отличаться SLA и они могут требовать своей инфраструктуры. Также хотим развивать внутреннюю IDE для работы с данными, написания запросов и скриптов. А чтобы бороться с проблемами, которые вызывают рост и масштабирование, а также поддерживать отказоустойчивость инфраструктуры, планируем рассмотреть разные облачные решения и работу с холодными данными из других систем.