• Архитектура аналитической системы.
• Программный код, который обеспечивает работу системы.
Если все сделано идеально, то этих двух артефактов достаточно, чтобы развернуть (подготовить) аналитическую систему за минимальное время. В крутых реализациях это можно сделать автоматически, нажатием одной кнопки. Это очень важно для устойчивой работоспособности аналитической системы. К сожалению, работа людей, которые этим занимаются (администраторы, инженеры), почти незаметна, особенно когда все хорошо работает. Их почти не замечают, не понимают, чем они занимаются, и поэтому часто не ценят.
Архитектура аналитической системы состоит из нескольких уровней:
• Физический – серверы и каналы связи между ними.
• Данные – хранилища данных.
• Приложения – программы, с помощью которых пользователи получают доступ к данным, а также публикуют модели 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 потом писали мне, что им очень не хватает этих аналитических решений в других компаниях. К хорошему быстро привыкаешь.
До Физтеха я вообще не знал английского – в школе у меня был немецкий, о чем я очень жалел. На Физтехе принято учить английский язык, поэтому сразу на первом курсе была сформирована группа начинающих, в которую попали всего 4 человека. На протяжении трех курсов у нас проходило 2 занятия в неделю. Это был один из самых моих любимых предметов, и он здорово мне пригодился. На четвертом курсе я устроился подрабатывать переводчиком книги с английского языка на русский. Это была книга о программе анализа данных STATISTICA компании StatSoft. Я устроился туда стажером, переводил книгу, помню норматив – 15 000 знаков в день, от которого к вечеру пухла голова. Постепенно я втянулся и стал заниматься более интересными вещами: преподавал клиентам компании, проводил презентации для продаж, ездил в командировки и т. д. Тогда я постоянно консультировал клиентов и понял одну важную вещь: многие клиенты хотят получить кнопку и желательно на стуле – садишься на нее, а она делает всю твою работу.
Читать дальше
Конец ознакомительного отрывка
Купить книгу