КУМБА! Low-code инжиниринг данных

На прошедшем Loginom Tech Day выступал с темой "JS-вайбкодинг в Loginom: Повышаем гибкость сценариев, не погребая себя под непонятным кодом".

В зале сидел некто Сергей Г., который позже признался, что пощадил меня и не стал валить вопросом "зачем вообще нужен Loginom, когда есть вайб код". А жаль) Вопрос-то хороший на самом деле.

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

- Быстрая: чтобы люди не закипали в ожидании пока отчет отработает / функция сформируется;

- Надежная: согласованность, прозрачность бизнес-логики, безопасность, простота обслуживания;

- Масштабируемая: как все будет работать, если объемы данных вырастут кратно? Или на порядки;

- Гибкая: как сделать, чтобы новые вводные, о которых сегодня ничего не известно, не потребовали переделывать все что создано до этого?

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

Свой опыт я вложил в библиотеку "Пакет монетизации данных" для Loginom, и на выходе мы получаем коробочное решение со следующими характеристиками:

1. Сверх-низкий порог входа. Базовое техническое требование к полноценной работе со стеком - компьютерная грамотность. Люди без ИТ опыта строят MVP и до водят их до инфраструктуры. Особенно актуально для людей от бизнеса, которые хотят серьезно войти в аналитику, но опыта программирования за плечами нет. LLM-ки не снижают порог входа для сложных проектов, они поднимают производительность для тех кто уже хорошо разбирается в теме.

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

3. Экономия токенов. Зачем тратить токены на вещи, которые прекрасно алгоритмизируются без LLM? Потратьте токены на генерацию дашбордов в стиле Гибли. Ну и честно мое мнение - завязывать критические бизнес-системы на наличие / стоимость расходников (чем и являются токены) - это бред.

4. Независимость от доступности LLM. Любимая ЛЛМка забанила вас / стала стоить как крыло от боинга / прекратила свое существование? Ну и ладно, потому что ядро инфраструктуры от нее не зависит, как и ваши возможности понимать что в нем происходит и вносить изменения.

При этом за работу с большими объемами данных отвечает у нас отвечает Clickhouse, но разработчику не нужно в нем разбираться - все тяготы общения с ним берет на себя Пакет монетизации данных.

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

И так, мое мнение о работе с РПИ.

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

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

Всем привет! В Пакете монетизации данных для Loginom появился новый функционал - интеграция с РПИ (реестр показателей и измерений). Источник РПИ может быть любым (хоть Excel, хоть дата-каталог). Главная функция интеграции - создавать витрины поверх моделей данных с предрасчитанными показателями, таким образом унифицируя бизнес-логику в разных системах-потребителях.

Требования к выражениям:
- синтаксис формул должен быть валидным для Clickhouse
- выражения строятся на базе моделей данных, которые готовит ПМД.

Возможности интеграции:
- Использование производных выражений с любой глубиной вложенности (Выручка = sum(Revenue), Валовая прибыль = sum(Gross_profit), Себестоимость = [Выручка]-[Валовая прибыль])

- Использование макроподстановок в формулах (например, выражение toYYMMMM(Дата)=toYYMMMM(today()) обозначаем как !ТекущийМесяц!, и в формулах используем его)

- Работа оконных функций (например расчет накопительных итогов из оборотов)

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

- Генерация справочной таблицы для каждой витрины с расширенным описанием показателей (к описанию показателя добавляются описания используемых сокращений).

Чуть позже напишу какие ощущения у меня от перехода построения витрин на РПИ)

Магия реестра показателей и измерений - при описании 4 показателя превращаются в 32

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

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

Однако спустя 20 000 лет, макаки так никуда особо не продвинулись с точки зрения научного и цивилизационного прогресса, потому что их деятельность была продвинутым подражанием, а с генерацией нового у них было не особо. А человеков показывали в зоопарках)

Что-то мне это все напоминает)))