И так, мое мнение о работе с РПИ.
Основа моих проектов по внедрению аналитических решений - это генератор моделей данных. Простой способ сводить к топологии "Звезда" любой набор таблиц с любыми связями между ними. Первоначально работало для Qlik, а теперь для любой BI, которая может брать данные из Clickhouse.
Этого казалось достаточным для того чтобы закрывать любые сценарии - ведь данные уложены в модели очень понятным способом, все что может быть связанным - связано. Модель работает одинаково в любых системах. А значит, можно спокойно отдать написание выражений показателей на откуп системам-потребителям.
Однако в текущих реалиях, такой подход работает все меньше, потому что:
1) У данных становится все больше систем-потребителей. Люди хотят не просто выгрузки из BI в Excel, они хотят сами коннектиться к данным собственными инструментами. В одной компании запросто сочетается несколько BI-инструментов. Метрики должны выводиться в клиентских продуктах. Тем же ЛЛМкам нужно давать максимально готовые данные. Значения метрик должны заливаться в другие системы, чтобы там с ними происходило что-то. Мы явно хотим чтобы во всех этих местах числа сходились.
2) Громоздкая бизнес-логика. А почему показатели могут не сходиться? Да потому что в зависимости от структуры данных, на базе пары полей модель может быть посчитано 10+ показателей. Если потребитель забирает себе модель, то показатели он будет заводить сам в своем инструменте. Если забирает витрину - там уже все посчитано.
3) Зависимости метрик сводят с ума. Если инструмент визуализации в синтаксисе выражений не поддерживает ссылки на введенные ранее метрики, (как в примере Выручка = sum(Revenue), Валовая прибыль = sum(Gross_profit), Себестоимость = [Выручка]-[Валовая прибыль]), то при смене логики расчета показателя Выручка, если не вспомнить и не поменять все формулы зависимых показателях - они останутся считаться в старой логике. И что еще интересно - если в визуализаторе такой функционал есть, иногда им не пользуются, потому что в моменте так проще.
4) Риски недопонимания на стороне подрядчиков. 18 мая я написал, как при заполнении РПИ 4 показателя волшебным образом превратились в 32. Отчасти это происходит потому, что к обычным базовым показателям добавляются всякие модификаторы, за прошлый год, за прошлый месяц и т.д. Стоит ли так разгонять число показателей? Ну вот я прикинул: у меня в РПИ есть показатель - сумма остатков на каждый месяц. Витрина с этим показателем должна уйти подрядчику, который будет делать отчет. Можно сказать ему что: "вот тут выводится последний остаток из поля [Сумма остатков]". А дальше думать, как он эту установку поймет, и как реализует (захардкодит месяц в формуле? будет брать последний месяц в витрине? будет брать текущей месяц?). А можно один раз прописать это в РПИ и никогда не думать о том, что это будет неправильно понято.
5) Риски недопонимания на стороне бизнес-заказчиков. РПИ - отличный инструмент для коммуникации между бизнесом и разработкой аналитики. Вас просят добавить в отчет выручку, а вы спрашиваете: какую из 5? Ах, нужной выручки здесь нет? Тогда добавляем в РПИ шестой вариант, и имеем полную прозрачность насчет того, какие методики расчетов в каких отчетах применяются.
6) Перегрузка ETL бизнес-логикой. Гибкие инструменты ETL соблазняют максимально преподсчитывать данные в хранилище, чтобы, минимизировать телодвижения при написании формул. Хорошая концепция, но у нее есть свои лимиты. Во-первых, бизнес-логика показателей может затрагивать несколько таблиц КХД и других показателей, и попытка считать их "заранее" перегрузит ETL. Во-вторых, если вы не супер-концентрированный человек дождя, то скорее всего бизнес-логика сложных показателей окажется так размазана по ETL, что через месяц вы и сами не найдете там концов.
Так что если ваши данные не используются только в рамках одной аналитической системы, РПИ будет вам определенно полезен. (речь конечно про РПИ которые реально генерирует витрины, а не является листиком со списком показателей, который устареет еще до того, как вы закончите его заполнять).
Регистрация по ссылке
