Приветствую, не так давно вышла первая статья с общим описанием нашей самописной BI. А сегодня хотелось бы подробнее поговорить про технический концепт этого инструмента. Если интересно, прошу под кат.

Давайте начнем немного издалека и вместе порассуждаем о том, как можно было бы создать нужную нам систему, исходя из повседневных потребностей в качественной аналитике.

Пользователи

Для начала подумаем, каков портрет нашего целевого пользователя и что в первую очередь важно для него в целевой BI-системе? Основной костяк пользователей, под которых будет разрабатываться система, это руководители верхнего уровня Домклик и других подразделений Сбера, которым будет выдан доступ к инструменту. Люди эти занятые, принимающие очень важные и дорогостоящие решения. Что будет главным для таких пользователей? Скорее всего, надежность, качество, простота и стабильность инструмента. А также возможность его кроссплатформенного использования. Хочет ли пользователь посмотреть отчётность со своего телефона в дороге, пока есть свободная минутка, или же показать его на экране большого телевизора в переговорке на важном совещании, — у него должна быть такая возможность.

Визуализация

При этом сверхкрутые и навороченные способы визуализации могут быть даже недостатком. Каждый человек имеет свойство привыкать считывать информацию в каком-то привычном ему формате. Особенно если годами получал информацию из презентаций PowerPoint и Excel. На первых порах будет достаточно простых графиков — гистограмм, линий и областей в разных комбинациях, — таблиц и тому подобного. Резкая смена привычного уклада визуализации нам ни к чему, это станет для конечного потребителя ненужной нагрузкой. По итогу визуальные BI-навороты — не главный целевой критерий, и их внедрение может быть постепенным как для системы, так и для самих пользователей.

Сначала сделаем стандартный джентельменский набор: веб-интерфейс для виджетов и бэкенд для доступа к разным подключаемым источникам данных с возможностью расширения. А что же дальше? Какие стандартные проблемы могут возникнуть, когда BI-инструмент будет расти и развиваться?

Скрипты

Первое, что приходит на ум — жизненный цикл скриптов, с помощью которых будут рисоваться графики. Это очень важно, от момента создания скрипта до его удаления, будь то SQL-скрипты или другие скрипты запроса данных. В первую очередь у всего должен быть владелец и ответственный. И желательно один. «У семи нянек дитя без глазу» — гласит народная мудрость, и стоит к ней чаще прислушиваться. Как мы это сделаем?

Давайте создадим реестр всех скриптов, которые будут существовать в рамках нашей системы. Каждый скрипт будет иметь ответственного автора, который будет его поддерживать, актуализировать, проверять актуальность данных и реагировать на нештатные ситуации, если скрипт вдруг по какой-то причине «отвалится».

Теперь, когда у нас есть такой реестр, он может стать публичным для всей команды аналитиков в компании. И скрипты можно будет переиспользовать. Если другому аналитику поступит задача сделать дашборд с определённой отчётностью, он может не писать всё с нуля, а проверить реестр на наличие уже готовых скриптов, из которых он сможет сделать необходимые виджеты.

Но зачем работать при создании виджетов только с одним скриптом? А если данные будут в нескольких скриптах? Давайте создадим реестр метрик, которые возвращают эти скрипты. И будем предоставлять доступ при создании виджетов именно к метрикам, которые автор нового виджета сможет просто добавлять в виджет одним нажатием. А если же данные лежат в разных скриптах или источниках, то ничего страшного, мы сами под капотом объедим их и отрисуем, словно это единый набор данных из одного источника.

А если кто-то захочет удалить метрики из скрипта, который уже используется в каких-то виджетах? Пользователь на следующее утро увидит разломанный виджет, в котором пропали какие-то данные? Лучше не стоит такого допускать. Давайте будем отслеживать через наши реестры, где и какие метрики и скрипты используются. И если автор скрипта захочет удалить данные, которые в настоящий момент видят пользователи, ему придётся пройти процесс проверки изменений. Все заинтересованные авторы виджетов на основе его скрипта получат уведомления на почту и смогут открыть интерфейс проверки изменений наподобие всем нам знакомых интерфейсов систем контроля версий. И там смогут отклонить или принять эти изменения и оперативно исправить свои виджеты, чтобы пользователи всегда видели только актуальные данные. Если на проверке будут приняты несовместимые изменения, то системы сама почистит виджет и предложит восстановить его, скрыв предварительно специальной шторкой от пользователей и не давая им видеть неактуальные или некорректные виджеты.

Хм, шторка? Хорошая идея, давайте будем помогать нашим аналитикам и команде, ответственной за слой данных. Если наш виджет не будет отрабатывать, мы закроем его с понятным и прозрачным для пользователей сообщением, а ответственным лицам сразу разошлём уведомления об этом событии. Добавим ручной режим выставления шторки, чтобы наши аналитики могли сами её установить, если с данными, которые уже видят пользователи, ещё нужно поработать.

Всегда помним, что лучше не показывать никаких данных с объяснением «почему», чем показывать неактуальные или неправильные данные.

Дашборды

У нас есть виджеты и скрипты. Теперь нам нужны сами дашборды, и сверху можно объединить их в категории и разделы. Получится трёхуровневая структура. Но кто, что и как сможет видеть? Обязательно нужна система доступов. Дадим возможность ответственным лицам выставлять пользователям роли на каждый уровень, с возможностью гибкого комбинирования разных ролей и доступов. Теперь каждый пользователь будет видеть свой вариант системы, в котором отображается только доступная ему аналитика.

Виджеты

Начнём создавать виджеты в дашбордах. Создали по виджету в одном, втором, третьем дашборде. А что, если нужен новый дашборд для определённой группы пользователей, но готовые виджеты уже есть? Догадались? Конечно — давайте создадим единый реестр всех виджетов в системе. У каждого виджета также будет ответственный. И виджеты будет можно свободно переиспользовать и они будут создаваться специально для этого реестра, а в дашборды попадать уже из него. Уменьшаем дублирование, повышаем контроль и надёжность. Как раз то, что нам нужно, верно? При переиспользовании виджеты будут ссылками на один и тот же экземпляр, а не копиями оригинального виджета. А следовательно, будут всегда оставатся актуальными при изменении оригинала. Любые изменения будут автоматически тиражироваться на все дашборды, куда был добавлен виджет. А ещё потом давайте добавим возможность сделать копию виджета, если нам нужно будет на базе готового создать другой.

Быстродействие

У нас есть дашборды, виджеты и скрипты. Теперь подумаем о разумных ограничениях, которые мы бы хотели установить на их быстродействие. Скрипты должны быть достаточно быстрыми по времени исполнения, добавим возможность ограничивать время их загрузки. Скрипты, отрабатывающие слишком долго, мы просто не дадим добавить в нашу систему. В то же время достаточно быстрыми должны быть и дашборды, и виджеты. Если внезапно данных в виджетах будет становиться слишком много из-за постоянно прирастающего ретро, то могут начаться проблемы. Сделаем гибкую и регулируемую систему ограничений на количество данных в конкретных типах виджетов и на количество виджетов в дашбордах. И будем дополнительно каждый день проверять систему в автоматическом режиме на соответствие нашим ограничениям с оповещением ответственных об отклонениях. Данные должны быть доступны достаточно быстро, мы думаем о времени наших пользователей.

Востребованность виджетов

Система работает, пользователи смотрят данные. Но как часто они используют конкретные виджеты? Сколько в реестрах неиспользуемых скриптов и виджетов?
Давайте сделаем системный мониторинг пользовательских активностей. Будем отслеживать, что они смотрят и как часто, чем пользуются в нашем инструменте. И если в системе будут появляться неактуальные виджеты и неиспользуемые скрипты, то будем их архивировать. Тоже автоматически. Мы же ведь любим автоматизацию, верно? На всякий случай дадим нашим аналитикам доступ к архивам. Если они захотят что-то восстановить, то смогут это сделать в пару кликов.

Лента новостей

Мы всё добавляем и добавляем интересные фичи в нашу BI, но как пользователи будут узнавать об этом? Давайте сделаем систему новостей, расширим систему уведомлений и будем генерировать новости о наших релизах, а заодно и о самых разных активностях внутри инструмента: новости и уведомления об изменениях в дашбордах, об ошибках загрузки скриптов и всём остальном, что будет отслеживаться, станут приходить нашим пользователям. И раз уж так, давайте им дадим возможность самим выбирать, на что бы они хотели подписаться: добавим систему управляемых подписок, чтобы каждый мог гибко настроить свои уведомления.

Ответственные за дашборды

Хм, у нас есть ответственные за виджеты и за скрипты, но нет системы ответственности за дашборды, категории дашбордов и разделы. Давайте это исправим и позволим пользователям с расширенными правами в системе назначать на автоматическую подписку нужных людей на нужные сущности. Теперь за каждой сущностью будет кто-то следить и получать все системные уведомления о том, что с ней происходит, и станет поддерживать всё в должном порядке. И заодно давайте подумаем над тем, что будет, если кто-то из ответственных окажется недоступен по каким-то причинам или что-то проморгает. Добавим в нашу систему ещё один уровень отказоустойчивости и создадим специальные роли старших аналитиков, которые будут получать в обязательном порядке весь пул системно-значимых уведомлений и будут иметь расширенные права на редактирование контента, созданного другими аналитиками.

Обратная связь

А как передаётся обратная связь от пользователей к ответственным за предоставляемую аналитику? Например, как оперативно связаться с автором виджета? Особенно если пользователь может находиться на другом конце нашей страны. Таски в Jira? Нет, как-то слишком долго и муторно. Давайте попробуем сделать что-то более интересное. Позволим нашим пользователям оставлять комментарии прямо под виджетами, тегать нужных людей и получать обратную связь на месте. Полноценная социальная составляющая. Также дадим нашим ответственным возможность помечать заданные вопросы как решённые, чтобы пользователи могли видеть, какие темы ещё в работе, а какие уже не актуальны. И, конечно, всё это будет подключено к системе уведомлений.

Профиль

Раз уж пошла такая история, давайте расширим наши социальные возможности. Дадим пользователям всем знакомые лайки и дизлайки в сообщениях. А так как мы отслеживаем, кто и когда смотрит виджеты, то выведем это на экран. Каждый сможет посмотреть, кто и чем сейчас интересуется, какая активность происходит на каждой странице.

Далее расширим профиль наших пользователей. Выведем туда все их активности, просмотры, комментарии. Аналитика как социальная сеть? Почему нет. И пока мы всё ещё занимаемся профилем, давайте добавим полезную кнопку, которая позволит передать всё, за что ответственен человек, другому пользователю системы — на постоянной основе или временно, всего за пару кликов. «У "Голландца" всегда должен быть капитан», и назначить нового будет максимально просто.

Отчётность, поиск и избранное

Ещё у нас есть Excel-отчётность, которая загружается автоматически отдельным сервисом или вручную аналитиками. Сделаем отдельный раздел и необходимую функциональность, чтобы пользователи могли скачивать и загружать наши файлы, тоже строго согласно ролевой модели.

Теперь представим, что прошло немного времени и наша система растёт, контента в ней всё больше, и бывает сложно вспомнить, где же находится нужный виджет с отчётностью. Давайте добавим пользователям возможность поиска по нашему приложению, чтобы он мог найти нужную категорию, дашборд или виджет.

Хм, а если пользователь хочет не просто искать виджеты, а желает сразу собрать из них свою доску, в которой будет для него всё самое критически важное и актуальное в данный момент? Сделаем избранное для пользователей, где каждый сможет создать свою структуру, добавить туда все необходимые виджеты и мониторить их в более удобном для себя формате.

Итог

Вот таким получился костяк желаемого нами продукта, и таким продуктом является наша самописная BI-система, в которой мы максимально следим за актуальностью и работоспособностью всех её элементов. Система самоочищается от старого и неактуального контента. В ней нельзя просто так сломать то, что пользователи уже видят и за чем активно следят. Здесь у каждого «Летучего Голландца» есть свой капитан, который несёт за него всю полноту ответственности и поддерживает его на плаву. А сверху всё это немного приправлено приятными элементами социальной сети. И, как вы могли заметить, главный упор в системе сделан не на возможности какого-то исследования данных средствами BI, а на стабильное предоставление уже готовых и проверенных данных конечным потребителям. Здесь особенно важную роль играет гибкая и безопасная ролевая модель доступа к отчётам, дашбордам, виджетам и любому другому контенту.

Это ещё не все возможности, которые предоставляет наше решение. Но описанное выше — его ядро, которое мы активно развиваем. Впереди ещё много интересного в нашем бэклоге. Ведь, как и любая актуальная система, инструмент развивается, перерабатывается и расширяется в соответствии с потребностями наших пользователей.