TGViewer
КУМБА! Low-code инжиниринг данных КУМБА! Low-code инжиниринг данных @bi_cumba · 649 subscribers
Post #267 454
И так, мое мнение о работе с РПИ.

Основа моих проектов по внедрению аналитических решений - это генератор моделей данных. Простой способ сводить к топологии "Звезда" любой набор таблиц с любыми связями между ними. Первоначально работало для 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, что через месяц вы и сами не найдете там концов.

Так что если ваши данные не используются только в рамках одной аналитической системы, РПИ будет вам определенно полезен. (речь конечно про РПИ которые реально генерирует витрины, а не является листиком со списком показателей, который устареет еще до того, как вы закончите его заполнять).
  • 👍 4
  • 🔥 3
More from @bi_cumba
  1. Sep 9, 2026Уже завтра в 15:00 (МСК) — третья часть серии вебинаров: «Не заставляйте сотрудников думат…
  2. Sep 8, 2026Уже сегодня в 15:00 (МСК) — вторая часть вебинара «Превращаем гипотезу в инструмент роста…
  3. Sep 3, 2026Уже завтра начинаем серию из трёх вебинаров о том, как пройти путь от обнаруженной проблем…
  4. Aug 10, 2026КУМБА! Low-code инжиниринг данных pinned a photo
  5. Aug 10, 2026Мы с нашими партнёрами подготовили для вас кое-что особенное — серию онлайн-вебинаров. Экс…
  6. Jun 21, 2026На прошедшем Loginom Tech Day выступал с темой "JS-вайбкодинг в Loginom: Повышаем гибкость…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →