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

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

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

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

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

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

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