Обычно дашборды характеризуют какой-то бизнес-процесс (далее слово «процесс» без «бизнес»), например эффективность рекламы, складские остатки, продажи и т. д. Есть еще важные характеристики дашбордов:
не является «простыней цифр»;
показывает, где возникла проблема, но не дает ответа на вопрос почему.
Часто велико искушение сделать огромную простыню цифр, закрывающую все аспекты бизнеса. И я понимаю владельцев/менеджеров компаний на старте проекта по построению внутренней аналитической системы всегда хочется большего. Я наблюдал это и в Ozon.ru, и в Ostrovok.ru. К слову, эти строки написаны по мотивам письма, которое я писал восемь лет назад операционному директору Ostrovok.ru, он хотел получить от аналитиков ту самую «простыню». А я считаю такое цифровым «микроменеджментом», в нем легко запутаться, самые важные показатели похоронены среди второстепенных. С первого взгляда будет сложно понять, где возникла проблема, а это основная функция дашбордов. Бороться с этим можно, например, через внедрение OKR цели и ключевые результаты (Objectives and Key Results) [13] или системы сбалансированных показателей (Balanced Scorecard). В этой книге я не буду подробно останавливаться на этих методиках, но рекомендую вам с ними ознакомиться. Также можно чаще пользоваться графическими элементами, например, добавив на график линию тренда (с помощью семиточечного скользящего среднего, чтобы убрать недельную сезонность), будет легче заметить восходящий или нисходящий тренд.
Дашборд отвечает на вопрос, где есть проблема, а не почему она возникла. Может возникнуть искушение сделать огромный детальный отчет, чтобы быстро найти причину, но тогда ваш дашборд превратится в простыню цифр, о которой я писал выше. В нем не будет интерактивности, и нужно будет «провалиться» внутрь этих цифр, чтобы проанализировать их, а для этого понадобятся совсем другие инструменты. Когда вам в следующий раз захочется это сделать, вспомните, удавалось ли вам хоть раз найти причину проблемы с помощью дашборда.
Никакой дашборд не заменит интерактивный анализ, для которого нужны соответствующая аналитическая система (SQL, OLAP, Google Data Studio, Tableau) и знание контекста. Мы никогда не сможем придумать ограниченный набор отчетов, которые будут отвечать на вопрос «почему». Максимум, что мы можем сделать, наращивать (но не слишком) объем правильных метрик, исходя из инцидентов, за которыми будем следить.
Поэтому я всегда за лаконичные автоматические отчеты, которые будут отвечать на два вопроса: есть ли проблема и где она возникла. Если проблема есть, нужно лезть в интерактивные системы анализа данных.
Разработка дашбордов это одна из самых нелюбимых работ у тех, кто занимается анализом данных. Когда я обсуждал этот вопрос с Ди Джеем Патилом, отметив, что 50 % времени аналитического отдела занимает работа над отчетностью, он сказал, что у них в LinkedIn тоже периодически накапливался пул таких задач и приходилось их закрывать. И взгрустнул. Но дашборды очень нужны они помогают контролировать общее здоровье вашей системы вверенных вам серверов и сетей, если вы системный администратор, или всей компании, если вы генеральный директор.
Артефакты машинного обучения
Раньше компьютером можно было управлять только с помощью прямых команд или инструкций: поверни сюда, дай назад, сложи и т. д. Это обычное, так называемое детерминированное программирование для нас понятен алгоритм в виде инструкций, мы его описали, и компьютер подчиняется ему. Машинное обучение предполагает совершенно другой подход к программированию обучение на примерах. Здесь мы показываем системе что-то с помощью примеров, тем самым избавляем себя от самостоятельного написания инструкций, что бывает совсем не просто. Это становится работой по обучению алгоритма ML.
Для меня машинное обучение отличается от программирования так же, как квантовая физика отличается от классической. Там мы точно можем определить, где находятся планеты Солнечной системы, а в квантовой механике все есть вероятность мы получим только вероятность нахождения электрона. Так и в машинном обучении вы будете работать с вероятностями например, модель будет предсказывать вероятность того, что на фотографии кошка. Под моделью я подразумеваю компьютерную программу (далее программный код), который обладает рядом признаков.
Функция обучения (train), в которую можно отправить данные для обучения признаки (они же фичи, независимые предикторы, независимые переменные) и правильный ответ (output). Сам результат обучения сохраняется внутри модели.
Функция предсказания (predict), которая предсказывает результат для новых примеров.
Поясню на примере одной задачи. У нас есть много фотографий собак и кошек, и нам нужно их разделить: в одну папку сложить файлы с фотографиями кошек, в другую фото собак. Фотографий очень много миллионы, вручную не сделать. У вас есть размеченный набор данных для обучения тысяча фотографий, для каждой указано, кошка там или собака. Вы берете нужную модель, «скармливаете» ей в функцию train набор с размеченными данными, и она учится на них. Сама модель выглядит для нас как черный ящик. Конечно, в него можно заглянуть, что мы и сделаем в главе про машинное обучение. Как только модель обучится, мы уже начинаем одна за другой скармливать ей фотографии, которые нужно разделить. Для каждой фотографии модель вернет нам вероятность того, кошка там или собака. Используя эти цифры, уже несложно разделить фотографии.
Этот пример я видел вживую, когда глубокое обучение нейронных сетей (Deep Learning) только набирало оборот. На одном из конкурсов Kaggle.com была точно такая же задача [14]. Чтобы поиграть с этой задачей, я нашел код в интернете, который не использовал нейронные сети. Естественно, ничего не получилось, мой алгоритм был настолько плох, что проще было бросить монетку и получить такой же результат. Первые места заняли исследователи, у которых результат был близок в 99 % (точность угадывания). Их модель была основана на сверточных нейронных сетях. Меня тогда поразил результат. Глубокое обучение нейронных сетей еще не было популярным, а ведь это было всего лишь в 2013 году. Вот так быстро меняются технологии!
Следующий постулат: данные, на которых обучена модель, это часть кода. Это еще одно серьезное отличие от классического программирования. Чтобы сделать «тиражирование» программного кода, его текст можно опубликовать в Сети. Эта программа будет работать везде одинаково. Если вы захотите «поделиться» своей обученный моделью, то вам придется отправить не только код, но и весь получившийся черный ящик. Именно так исследователи и делятся своими обученными моделями. Например, модель нейронной сети Resnet 50 [15] была обучена на миллионах изображений. Она уже полностью готова к работе; просто показывая ей разные фотографии, вы получите названия предметов, которые там изображены.
Артефакты инженерии
Ничего нельзя сделать без инженерии аналитической системы. Даже для самых простых вещей «на коленке» нужно продумывать следующие вопросы:
Откуда и с какой периодичностью брать данные и как туда получить доступ?
Какова нагрузочная способность источников данных, чтобы и бизнес работал без сбоев, и данные как можно быстрее были доступны для анализа?
Какую архитектуру хранилища сделать? Или, может, не делать его вовсе?
Какую аналитическую систему выбрать?
Как использовать в процессах обученную модель машинного обучения (далее ML-модель)?
Таких вопросов может быть очень много. Эти вопросы должны решаться и автоматизироваться. Артефактами инженерии будут:
Архитектура аналитической системы.
Программный код, который обеспечивает работу системы.
Если все сделано идеально, то этих двух артефактов достаточно, чтобы развернуть (подготовить) аналитическую систему за минимальное время. В крутых реализациях это можно сделать автоматически, нажатием одной кнопки. Это очень важно для устойчивой работоспособности аналитической системы. К сожалению, работа людей, которые этим занимаются (администраторы, инженеры), почти незаметна, особенно когда все хорошо работает. Их почти не замечают, не понимают, чем они занимаются, и поэтому часто не ценят.
Архитектура аналитической системы состоит из нескольких уровней:
Физический серверы и каналы связи между ними.
Данные хранилища данных.
Приложения программы, с помощью которых пользователи получают доступ к данным, а также публикуют модели ML.
За физический уровень отвечают системные администраторы. Они занимаются «железом», чтобы система была отказоустойчивой. Также администраторы постоянно мониторят здоровье системы. Знаете, как определить, что у вас хорошая система и администраторы? Вы о работе администраторов ничего не слышите, а система работает без серьезных сбоев.
За уровень данных отвечают инженеры данных (Data Engineers или ETL Engineers): их основная задача сделать так, чтобы данные доставлялись от источников данных и сохранялись в хранилищах данных. Часто они же отвечают за предобработку данных и развертывание BI-систем (OLAP-кубы и отчетные системы).