Роман с Data Science. Как монетизировать большие данные

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

• Откуда и с какой периодичностью брать данные и как туда получить доступ?

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

• Какую архитектуру хранилища сделать? Или, может, не делать его вовсе?

• Какую аналитическую систему выбрать?

• Как использовать в процессах обученную модель машинного обучения (далее ML-модель)?

Таких вопросов может быть очень много. Эти вопросы должны решаться и автоматизироваться. Артефактами инженерии будут:

• Архитектура аналитической системы.

• Программный код, который обеспечивает работу системы.

Если все сделано идеально, то этих двух артефактов достаточно, чтобы развернуть (подготовить) аналитическую систему за минимальное время. В крутых реализациях это можно сделать автоматически, нажатием одной кнопки. Это очень важно для устойчивой работоспособности аналитической системы. К сожалению, работа людей, которые этим занимаются (администраторы, инженеры), почти незаметна, особенно когда все хорошо работает. Их почти не замечают, не понимают, чем они занимаются, и поэтому часто не ценят.

Архитектура аналитической системы состоит из нескольких уровней:

• Физический – серверы и каналы связи между ними.

• Данные – хранилища данных.

• Приложения – программы, с помощью которых пользователи получают доступ к данным, а также публикуют модели ML.

За физический уровень отвечают системные администраторы. Они занимаются «железом», чтобы система была отказоустойчивой. Также администраторы постоянно мониторят здоровье системы. Знаете, как определить, что у вас хорошая система и администраторы? Вы о работе администраторов ничего не слышите, а система работает без серьезных сбоев.

За уровень данных отвечают инженеры данных (Data Engineers или ETL Engineers): их основная задача – сделать так, чтобы данные доставлялись от источников данных и сохранялись в хранилищах данных. Часто они же отвечают за предобработку данных и развертывание BI-систем (OLAP-кубы и отчетные системы).

За уровень приложений отвечают инженеры машинного обучения (ML engineers) и аналитики данных (data scientists). ML-инженеры занимаются созданием ML-моделей и иногда – их развертыванием, чтобы они работали на благо вашего бизнеса (хотя в больших компаниях развертыванием моделей «в бою» часто занимаются другие инженеры). Аналитики данных занимаются тестированием моделей и их оценкой. В небольших компаниях эти две роли часто совмещаются. Однажды я проходил собеседование в офисе компании Quora.com (социальная сеть) в Пало-Альто (Калифорния, США) и там выяснил, что местные ML-инженеры как раз и занимаются разработкой ML-моделей, а аналитики данных занимаются метриками, анализом данных и прочим, но не ML-моделями.

Кто анализирует данные

Чем ближе анализ данных к точке принятия решений – тем лучше. Если вопрос возник у руководителя и у него есть полное понимание бизнес-контекста (какие события были и т. д.), а аналитическая система обладает хорошей интерактивностью, то большинство вопросов решаются на раз-два-три. До 80 % вопросов (вспомните правило Парето), если быть точным. В чем плюсы такого решения? Нет посредников – выше скорость! Пользователь даже может не иметь четко сформулированного вопроса, который точно понадобится, если ставить задачу аналитикам. Для этого очень важно внутри компании «продавать» аналитический подход и регулярно обучать пользователей.

Если бизнес-контекст размытый, находится вне компетенций или вопрос заказчика слишком сложный, то тут подключают в работу аналитика. Обычно я рекомендую в отделах, департаментах держать собственного «децентрализованного» аналитика, который в курсе дел этого департамента, то есть владеет бизнес-контекстом и при этом обладает развитыми аналитическими и техническими навыками. Это вторая линия обороны. Такой «карманный» аналитик сможет решать вопросы внутри отдела/департамента быстрее центрального просто потому, что у него нет других задач.

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

• задача требует изменения ядра системы;

• задача технически сложна для аналитика какого-то отдела;

• требуется большая коллаборация между отделами для ее решения.

В Ozon.ru я не полностью ее реализовал, но уже в Wikimart.ru была сделана такая система: интерактивный анализ данных в OLAP-кубах дал возможность пользователям быстро решать свои вопросы, аналитики отделов решали проблемы анализа данных отделов, а центральный отдел создавал ядро всей аналитической системы. Кстати, многие бывшие пользователи OLAP-кубов в Ozon.ru потом писали мне, что им очень не хватает этих аналитических решений в других компаниях. К хорошему быстро привыкаешь.

Идеальная кнопка