Как вырваться из закостенелых парадигм и сделать нечто, отличное от всего, что вы знали?

Привет, Хабр. Я, Гибадуллина Алсу — владелец продукта In-DAP, и сегодня я расскажу о том, почему мы решили «изобрести велосипед» и какие концептуальные идеи использовали. Иначе говоря, расскажу о том, как устроен модуль In-DAP Indicators с функциональной точки зрения и почему мы им гордимся.

В начале пути перед нашей командой встала задача создать систему управления показателями, достаточно гибкую и при этом простую и удобную, которая подходила бы под специфические требования госсектора (как позже выяснилось, такие же требования часто возникают и у бизнеса).

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

Высокая степень изменчивости структуры показателей наталкивает на мысль, что обычный для такого класса систем подход «ТРЕБОВАНИЯ — ТЗ — РАЗРАБОТКА — СДАЧА — КОРРЕКТИРОВКА» крайне неудобен. Это не только длинный, но и дорогой процесс.

В то же время перед глазами стоял вездесущий и всемогущий Excel: его любят, его понимают, его осваивают и, несмотря на все недостатки, используют очень активно.

И мы решили пойти «своим путем».

Вспомним, в чем же состоят критичные для нас минусы традиционных OLAP‑систем:

1. Необходимость тщательного проектирования перед созданием структуры показателей.

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

2. Задержки в обновлении витрины данных для OLAP‑систем.

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

3. Более оперативна технология ROLAP, которая берет данные из первоисточников, делает расчеты «на лету» и предоставляет актуальные данные по запросу пользователя. Однако, эта технология требует больших вычислительных мощностей, и имеет практически те же минусы, которые описаны в п.1.

Конечно, OLAP\ROLAP — обкатанная технология, которая де‑факто является основной технологией BI систем. Но нам нужно было немного другое.

Чего же хотели мы?

Простоты и функциональности. И еще раз простоты.

Конечные пользователи обожают Еxcel. Они добиваются достаточно неплохих результатов, осваивая этот инструмент. Почему же BI не может быть столь же простым и функциональным? Нет неразрешимых задач, есть вызовы, с которыми мы готовы справится.

Итак, что нас ждет:

1. Унификация — полная. Нет больше исходных таблиц в качестве источников данных, в которых отдельные поля — это либо измерения, либо разные показатели, либо непонятно что. Один показатель — одна таблица в базе данных. Без вариантов. Даже план и факт — отдельные таблицы. То есть каждый показатель — это отдельный «кубик лего» или «пазлинка». Показатели, по большому счету, отличаются только составом «Измерений».

Показатель — это количественная или качественная характеристика, которая используется для измерения, оценки или описания какого‑либо аспекта объекта, процесса, свойства или явления. Он позволяет судить о состоянии, развитии, ходе чего‑либо, а также используется для сравнения и анализа. 

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

Что нам это дает?

• Предсказуемость. Пользователь видит папки в общем реестре, а в них показатели, которые устроены примерно одинаково. Таким образом степень понимания пользователем системы многократно возрастает.

• Безопасность. Нет опасности что‑нибудь испортить. Показатель всегда можно добавить или убрать с глаз долой. При этом пользователь никак не повлияет на уже существующие показатели, запросы и дашборды.

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

• Разделяй и властвуй: возможность стандартизации подходов к управлению правами доступа. Об этом подробнее расскажем в следующих материалах.

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

Что нам это дает?

• Нет необходимости знать исходную схему данных, сверяться с ER диаграммой и изучать документацию. Можем собрать представления из совершенно не связанных между собой кубиков, при этом можно использовать кубики сколько угодно раз. Например, в одной форме собирать данные по доходам в ручном режиме, данные по расходам загрузить из внешней системы. Сводные данные по обоим показателям согласовать в третьей форме.

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

• Выборки данных без SQL. Drag‑n-drop: для создания запроса (представления данных или формы сбора) достаточно просто перетащить необходимые показатели из реестра в так называемый запрос. Это просто и интуитивно понятно. Система сама посмотрит, какие есть измерения у показателя и построит одну большую таблицу со всеми показатели. После этого можно изменить форму представления данных — например сделать различного варианта сводные таблицы или визуализировать данные.

3. Самое интересное — формулы расчета. Поскольку каждый показатель — это отдельная сущность, то формула может выглядеть еще проще, чем в Excel:

 Показатель_А=(Показатель_Б-Показатель_В)/Показатель_Г.

Например: Средняя_прибыль_по_филиалам=(Доходы-Расходы)/Количество_филиалов.

Что нам это дает?

• Интуитивно понятные формулы без излишних деталей. Формулы выглядят так, как пользователь написал бы ее в техническом задании. Написать подобную формулу для показателей из разных кубов для традиционной OLAP требует гораздо более значительных усилий.

• Возможность использовать в формулах как исходные, так и расчетные показатели любого уровня сколько угодно раз. Но, конечно, желтые шарики сложить с колючими ежами не получится. И это хорошо и правильно. Но можно поделить, например, количество продаж по филиалам на количество продаж по компании в целом, чтобы узнать долю каждого филиала в общем котле эффективности.

• Наш любимый drag-n-drop. Можно перетащить показатели из реестра в область редактирования формулы и далее вносить правки.

• Прозрачность. Мы знаем все зависимости между показателями и можем их визуализировать. Можно раскрутить показатель до самого первого исходного показателя. Это опять-таки помогает пользователям понимать структуру показателей.

• Версии формул. Очень часто методика расчета может измениться, но мы готовы к такому повороту событий. Таким образом, можем настроить различные формулы расчета на различные периоды.

4. «Агрегаты». Агрегатами называют агрегированные по определенным условиям исходные значения показателей. Обычно под агрегацией понимается любая процедура формирования меньшего количества значений (агрегатов) на основании большего количества исходных значений. Тоже являются самостоятельными показателями. Чтобы создать такой агрегат нужно создать показатель и внести в него формулы расчета.

Например: Доход_компании = АГРСУММА (Доход_филиала).

Что нам это дает?

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

• Можем не хранить агрегат, а сразу использовать функцию агрегации в формуле расчета. Например: Средняя_прибыль_по_филиалам = ( АГРСУММА (Доход_филиала) - АГРСУММА(Расход_филиала)) / Количество_филиалов

• Минусы: на этом этапе появляется дополнительная трудоемкость по созданию агрегатов, однако этот процесс в будущем можно будет облегчить специальной функцией – массового создания требуемых агрегатов.

5. Расчеты сразу после изменения исходного показателя. Задание на перерасчет уходит в соответствующий сервис сразу после подтверждения изменений. Таким образом, пересчитываются все значения вверх по дереву зависимостей. После завершения расчета значение показателя помечается как актуальное, что означает, что именно это значение было использовано во всех расчетных показателях, связанных от исходного.

Что на�� это дает?

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

• Относительная оперативность обновления расчетных данных — как минимум по сравнению с OLAP.

• Снижение нагрузки на вычислительные ресурсы при подготовке дашборда — не нужно делать расчеты «на лету» если сравнивать с ROLAP технологией.

• Минусы: в случае больших объемов вводимых данных и значительных агрегациях возможно снижение производительности по вводу в систему новых значений. То есть, перерасчет будет длиться несколько дольше, однако это не заблокирует работу оператора. Он продолжит работу по вводу данных без задержек. Почему, я расскажу в следующем разделе.

6. «Версионирование» значений показателя. Мы можем хранить несколько вариантов значений показателей на один и тот же набор измерений. И сохранять в привязке к каждому варианту (версии) значения исходных показателей, на основании которых был произведен расчет. При этом, у значения показателя может быть только одна актуальная версия — она же используется в расчетах, в визуальных представлениях и отчетных формах.

Что нам это дает?

Это решение позволяет обеспечить ту самую консистентность данных без остановки работы пользователя. Пока фоном идут расчеты, пользователь вводит новые данные или работает с расчетными данными. По тому, с какой скоростью актуализируются его данные, пользователь понимает, как протекает процесс перерасчета – это повышает прозрачность работы системы в целом.

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

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

И последнее на сегодня:

7. Возможность фиксации значения показателя. Это функция позволяет закрепить версию значения показателя в ее актуальном состоянии для того, чтобы уже больше никто не исправил значение. Зафиксировать можно любое значение показателя, как исходное, так и расчетное/агрегированное. Эта процедура блокирует возможность актуализации новых исходных показателей, если они участвовали в расчетах зафиксированных значений.

Что нам это дает?

• Данные в системе, на основе которых пользователь сформировал и отправил отчет, всегда будут соответствовать цифрам в отчете.

• Возможность навешивания процессов согласования и утверждения показателей в формах сбора данных, в отчетных формах с одновременной фиксацией значения.

• Минусы: реальность меняется чаще, чем всем бы хотелось. На деле, приходится часто снимать фиксацию, чтобы залить новые данные уже для другого отчета. И по факту данные в системе с отправленными отчетами не всегда совпадают.

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

Помимо перечисленных в статье решений, у In-DAP Indicators есть много достаточно интересных фич, как в части реализации дашбордов, так и в других процессах работы с показателями и анализом данных. К сожалению, в одной статье нельзя рассказать сразу обо всем.

Будем рады, если вы поделитесь своими впечатлениями и\или сомнениями, вопросами. И, возможно, мы сформулируем тему следующей статьи. Заранее спасибо за ваше мнение!

Больше о возможностях In‑DAP Indicators → на нашем сайте

Читайте также о принципах построении KPI с использованием In-DAP Indicators в статье на Хабр.