За уровень данных отвечают инженеры данных (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 потом писали мне, что им очень не хватает этих аналитических решений в других компаниях. К хорошему быстро привыкаешь.
Идеальная кнопка
До Физтеха я вообще не знал английского в школе у меня был немецкий, о чем я очень жалел. На Физтехе принято учить английский язык, поэтому сразу на первом курсе была сформирована группа начинающих, в которую попали всего 4 человека. На протяжении трех курсов у нас проходило 2 занятия в неделю. Это был один из самых моих любимых предметов, и он здорово мне пригодился. На четвертом курсе я устроился подрабатывать переводчиком книги с английского языка на русский. Это была книга о программе анализа данных STATISTICA компании StatSoft. Я устроился туда стажером, переводил книгу, помню норматив 15 000 знаков в день, от которого к вечеру пухла голова. Постепенно я втянулся и стал заниматься более интересными вещами: преподавал клиентам компании, проводил презентации для продаж, ездил в командировки и т. д. Тогда я постоянно консультировал клиентов и понял одну важную вещь: многие клиенты хотят получить кнопку и желательно на стуле садишься на нее, а она делает всю твою работу.
Кроме того, заказчику чаще всего лень вдаваться в детали, и он готов платить огромные деньги просто за яркую обертку. Этот феномен очень хорошо эксплуатируется продавцами IT-решений, консультантами всех мастей. Я наблюдал его, когда Ozon.ru выбирал решение для веб-аналитики между Omniture SiteCatalyst и Webtrends. Обе команды продавцов активно рассказывали о «светлом» будущем. Так как никто из принимающих решения не был особенно в теме (я, кстати, тоже), то выбрали тех, кто «поет» лучше. Презентация Omniture выглядела эффектней, они нам подарили радиоуправляемые машинки и всякие подарки. Поэтому выбор был сделан в их пользу, хотя я нахожу системы равнозначными, и стоили они почти одинаково. В продолжение истории когда я пришел в Wikimart.ru, мне уже было понятно, что нужно пользователям от веб-аналитики. Я быстро накатал техническое задание, его реализовали разработчики, и через два месяца после моего прихода в компании была своя система веб-аналитики, ничуть не хуже Omniture. И экономия составляла порядка 100 тысяч долларов в год.
Я не утверждаю, что продавцы и консультанты плохи, я призываю вас самих не лениться. Прочитайте книгу, а лучше две по теме, дочитайте их до конца. Ищите независимых экспертов, которым сможете доверять. Главное это погружаться в детали, именно там кроются и все проблемы, и их решения. Будьте скептичны по отношению к своим эмоциям. Будьте скептичны к докладам на конференциях, они часто однобоки и слишком позитивны, чтобы быть правдой. Там есть интересные вещи, но мало кто рассказывает, чего стоило то или иное решение.
Продать аналитику внутри компании
Для меня это очень непростой вопрос. В разделе «Кто анализирует данные» я упоминал, что аналитическую систему мне удалось поднять за два месяца (причем я работал тогда два дня в неделю). «Продажа» ее пользователям заняла гораздо больше времени, и только спустя 4 месяца системой начали более-менее пользоваться. Причем kick-off-презентацию я делал сразу после запуска: пригласил туда всех значимых сотрудников компании, включая основателей.
Мне легче работать на индивидуальном уровне: поговорить за обедом, обменяться парой фраз у кулера с водой, поинтересоваться чужими задачами, копнуть глубже. Затем представить в уме схему решения что есть и чего не хватает. Прислать решение человеку, показать его лично. Приучать людей к новой системе лучше не навязывая, а обучая так пользователи постепенно поймут, как она может ускорить решение их задач.
В Retail Rocket мы так внедряли аналитику на базе ClickHouse. Ранее данные были доступны только в SQL-интерфейсе к вычислительному кластеру на базе Spark/Hadoop (эти технологии мы обсудим в главе о хранилищах), Hive. Подобная схема используется в компании Facebook, они так дают доступ к данным внутри своей компании. Проблема этой технологии заключается в том, что она медленно считает, запросы выполнялись до 30 минут, а данные доступны только до вчерашних суток. Пользовались этой системой только сотрудники технической поддержки. В одном из проектов мы попробовали аналитическую базу данных ClickHouse от Яндекса. Нам она понравилась: быстро считала, большая часть запросов это секунды, можно было сделать систему, близкую к реальному времени. Вначале пересадили на нее техническую поддержку, а в Retail Rocket это одно из самых сильных подразделений. Они очень быстро полюбили эту технологию за скорость и отказались от использования медленного Hive. Далее мы начали предлагать новую систему пользователям внутри компании. После обучающих презентаций многие сотрудники зарегистрировались в системе, но не стали ею пользоваться. Тогда мы пошли другим путем: все входящие задачи от сотрудников, которые можно было решить с помощью этой системы, начали раз за разом «отфутболивать» возвращать под соусом «сделай сам», демонстрируя возможности системы. И часть пользователей стала работать с системой самостоятельно! Там многое еще можно сделать, но то, что уже сделано, я считаю успехом.
Вообще, если абстрагироваться от продаж аналитики внутри компании, в структуре бизнеса часто не хватает такой роли, как руководитель внутреннего продукта. Задачей которого было бы помогать сотрудникам работать эффективнее, лучше автоматизировать внутреннюю деятельность, избавляться от неэффективного «мартышкиного» труда. В компаниях часто любят внедрять процессы, чтобы забюрократизировать работу, но мало кто думает о внутреннем продукте, чтобы целенаправленно облегчить работу своим сотрудникам. Я думаю, причина в том, что сложно посчитать, сколько заработает на этом компания. Но на самом деле это очень важная роль. И если она есть продажа аналитики внутри компании происходит естественным образом.
Конфликт исследователя и бизнеса
Работая уже много лет в области анализа данных, я заметил конфликт интересов, который в некотором роде похож на конфликт отцов и детей: молодые и дерзкие аналитики и инженеры хотят создать если не памятник, то что-то действительно значимое и красивое, о чем можно поведать миру, чем можно поднять самооценку или написать красивую строчку в резюме. Многие из них одержимы идеей применять машинное обучение в реальной жизни там, где это нужно и не нужно. Но в отличие от исследователей, у бизнеса менее романтические цели в первую очередь это, как ни крути, деньги: в уставе почти любого российского ООО написано: «Целью деятельности Общества является достижение максимальной экономической эффективности и прибыльности».