Роман с Data Science. Как монетизировать большие данные - читать онлайн книгу. Автор: Роман Зыков cтр.№ 32

Опишу типичную ситуацию, которая возникает при запуске аналитической системы. В компании Х появляется хранилище данных и аналитическая система к нему. Аналитики проводят первое общее собрание, показывают систему, демонстрируют, какие данные доступны. Самые любознательные сотрудники (берегите их), которым этого не хватало, начинают работать с новым хранилищем и системой, и вскоре от них начинают сыпаться комментарии: это неудобно, тут тормозит, здесь не хватает данных. Поговорим о минимальных требованиях к отчетной системе, которые я встречал на практике.

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

Любой отчет, или дашборд, состоит из блоков: таблиц и графиков. Блоки часто бывают независимы друг от друга, но связаны общими параметрами. Отличный пример такого параметра – дата и время. Атрибут практически любого отчета – период, который этот отчет охватывает. В хорошей отчетной системе этот параметр несложно «пробросить» на все блоки. Как это выглядит для пользователя: пользователь открывает в браузере нужный отчет, вводит период (дата начала и конца), ждет некоторое время и получает результат. Как это выглядит для разработчика: разработчик собирает несколько блоков в отчет, указывает имена общих параметров в каждом блоке, указывает имена параметров в общем отчете и публикует отчет. Выглядит просто, но не во всех отчетных системах это сделано удобно. Мой недавний пример из Retail Rocket: для хранилища на ClickHouse вначале выбрали SuperSet. Столкнулись с огромным количеством неудобств в параметрах. В итоги перешли на Metabase, где подобные параметрические отчеты делаются намного проще. Обе системы полностью бесплатны, с открытым исходным кодом.

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

Администрирование пользователей удобно, когда есть единая система учета. В таком случае пользователям не нужно помнить множество паролей, а администраторам легко регулировать доступ. По своему опыту скажу, что если компания использует, например, G Suite для бизнеса от Google, то система отчетности, которая может использовать ту же самую авторизацию, будет удобнее, чем не использующая. Например, тот же Metabase [47] позволяет авторизоваться через Google, а SuperSet [48] нет.

Рассылка отчетов бывает периодической, когда она происходит по часам или определенным дням, и триггерной – в ответ на появление какого-либо события или изменения показателя. Триггерные рассылки часто используются в ИТ, например, чтобы поймать момент, когда падает какая-либо система или критически поднимается нагрузка. Для этого на определенный показатель системы выставляется пороговое значение, при превышении которого высылается соответствующее письмо. В бизнесе сложнее – там показатели не так быстро меняются: в интернет-магазине, например, можно поставить пороговые значения на количество заказов за последний час или трафик, чтобы как можно быстрее узнать о проблеме и избежать большой потери выручки. Отчеты могут присылаться в теле письма, что удобнее (вы сразу увидите результат), в приложенных файлах, например в формате Excel, или краткий отчет в теле письма, а расширенный доступен по ссылке. Удобство отчетов по электронной почте зависит от задач: если нужно быстро взглянуть на графики в мобильном телефоне, то лучше, когда отчет в теле письма; если с цифрами нужно будет работать – файл с электронной таблицей будет идеальным вариантом.

Что будет, если отчет запустить несколько раз подряд? Например, несколько пользователей с разницей в одну минуту запросят один и тот же отчет. Ждать очередные пять минут, пока он считается? Это зависит от схемы кэширования – в хорошей системе она есть. При публикации отчета выставляется период кэширования или сохранения прошлых результатов. Например, если выставить период в 30 минут, то после расчета данные отчета будут сохранены для последующих запросов ровно на 30 минут. И все последующие отчеты будут уже использовать их. Это очень полезно для тяжелых вычислений, пусть при кэшировании данные в отчете могут отставать от хранилища. В Ozon.ru одно время в системе back-office был отчет с текущими результатами дня. Отчет очень часто обновляли сотрудники из азарта. Это привело к DoS (Denial of Service – отказ в обслуживании) – атаке, которая ухудшила производительность. Кэширование отчета на определенное время остудило пыл азартных любителей цифр и разгрузило систему приема заказов.

Интерактивный анализ – это когда вы исследуете данные, проваливаясь вглубь цифр и метрик; он де-факто считается стандартом любой аналитической системы. Есть графический тип анализа, хороший пример – Google Analytics: практически все тут можно сделать мышью. Второй тип – сводные таблицы. Я больше склонен именно к такому типу анализа. Делаю выборку данных, копирую ее в любую электронную таблицу, включаю анализ сводных таблиц (pivot table), а далее уже в интерфейсе «кручу» данные. На самом деле почти всегда, когда мы работаем с интерактивным анализом данных, мы работаем со сводными таблицами.

Если вкратце, то мои минимальные требования к отчетной системе такие:

• авторизация пользователей, желательно завязанная на корпоративную систему доступа;

• тонкий клиент, доступ через веб-браузер;

• возможность просмотра отчета, полученного по электронной почте, сразу на экране;

• несложная параметризация большого отчета, состоящего из множества блоков;

• кэширование результатов.

Сводные таблицы (pivot tables) – это самое лучшее, что было изобретено в разведочном анализе данных. Если аналитик хорошо владеет сводными таблицами, он всегда заработает на хлеб с маслом. Сводная таблица избавляет нас от огромного числа бесполезных запросов к данным, когда нужно просто найти хоть какую-то зацепку. Я уже писал выше про свой личный шаблон интерактивного анализа данных: сделать выборку данных, скопировать данные в электронные таблицы, построить сводную таблицу и работать с ней. Этот способ сэкономил мне годы по сравнению с прямыми методами – подсчетом описательных статистик, построением простых графиков, то есть стандартными операциями анализа данных для любых аналитических инструментов. А теперь разберем по пунктам, как работать со сводными таблицами.