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

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

Мы с нашими партнёрами подготовили для вас кое-что особенное — серию онлайн-вебинаров. Эксперт Евгений Стучалкин, архитектор аналитических решений и автор концепции универсальной модели для бизнес-аналитики, вместе с командами Loginom, Easy Report и AW BI покажет, как превратить аналитику в инструмент для управленческих решений. Где бизнес теряет прибыль — и как найти причины за 15 минут? 3 сентября в 15:00 проведём вебинар на платформе Pruffme. Разберём: • как быстро находить отклонения от плана и оценивать их влияние на финансовые результаты; • какие факторы действительно влияют на прибыль; • как AI помогает выявлять слабые места и находить точки роста; • почему один дашборд может заменить десятки отчётов. Это первый вебинар из серии о том, как построить систему управления, в которой аналитика помогает принимать решения и действовать быстрее. 👉Регистрация по ссылке #мероприятие

На прошедшем 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()) обозначаем как !ТекущийМесяц!, и в формулах используем его) - Работа оконных функций (например расчет накопительных итогов из оборотов) - Работа вложенных оконных функций (например расчет скользящего среднего по остаткам, рассчитанным из оборотов). - Генерация справочной таблицы для каждой витрины с расширенным описанием показателей (к описанию показателя добавляются описания используемых сокращений). Чуть позже напишу какие ощущения у меня от перехода построения витрин на РПИ)

Loginom Tech 2026 — технический митап ‼️ Москва | 4 июня | Офлайн Практика, архитектура, реальные кейсы и технические детали работы с данными и ИИ. В программе: — 5 технических докладов от экспертов Loginom; — новые возможности Loginom 7.4; — практические подходы к работе с данными и автоматизации аналитики; — круглый стол про ИИ в аналитике: ограничения, риски и реальные сценарии применения. Митап пройдёт без онлайн-трансляции — только очное участие. 👉 Регистрация по ссылке #LoginomTech2026

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

Запись вебинара «Как потратить бюджет на ИИ и не добиться ничего». Разобрали, почему проекты на базе LLM часто не дают ожидаемого бизнес‑эффекта: ограничения связаны не только с моделями, но и с качеством данных, их структурой и контекстом использования. На примерах показали, как эти факторы влияют на результат в аналитике, и поделились конкретными подходами, которые помогают повысить отдачу от ИИ в реальных задачах бизнеса — с разбором кейсов. ▶️ Запись доступна по ссылке #мероприятие

Подключайтесь на вебинар про MCP в Loginom прямо сейчас) Вебинар "Как потратить бюджет на ИИ и не добиться ничего" Время: 16 апр. 2026 15:00 Москва Подключиться к конференции Zoom https://us02web.zoom.us/j/87525304413?pwd=8p83Irtazb08raFYJA7ajzal1PDJ8O.1 Идентификатор конференции: 875 2530 4413 Код доступа: 799599

Вспомнил сюжет Планеты обезьян (книги, не кинца)). Кто не в курсе, там на другой планете жили человеки, которые придумали упростить себе быт, обучив макак всякому. Со временем макаки брали на себя все больше и больше, а человеки утратили способность к сложной когнитивной деятельности (потому что макаки начинали с принеси-подай, а потом учились подражать все более сложным процессам) и деграднули до животных в кустах. Макаки же заняли их место в социуме. Однако спустя 20 000 лет, макаки так никуда особо не продвинулись с точки зрения научного и цивилизационного прогресса, потому что их деятельность была продвинутым подражанием, а с генерацией нового у них было не особо. А человеков показывали в зоопарках) Что-то мне это все напоминает)))

Вебинар: Как потратить бюджет на ИИ и не добиться ничего 📍16 апреля (четверг), 15:00 | Онлайн (Zoom) Компании активно инвестируют в ИИ, но многие проекты так и не дают бизнес-эффекта. Чаще всего причина — не в технологии, а в данных и подходе к аналитике. На вебинаре покажем, как использовать ИИ так, чтобы он приносил результат. В программе: — как защитить инвестиции в ИИ; — как получать достоверные результаты; — где LLM (большие языковые модели) действительно работают. Спикеры: Алексей Арустамов — CEO Loginom Company Евгений Стучалкин — архитектор аналитических систем, разработчик Data Monetization Pack 👉Регистрация по ссылке #мероприятие

ну и раз сегодня день DataForge) Коллеги опубликовали у себя в канале пост, с выводом на скрине: Т.к. в чат на их канале у меня нет доступа, отвечу тут) На самом деле, от разделения бизнес логики на условный ETL и "фронт" никуда не деться. Просто потому, что на уровне ETL можно рассчитать такие вещи, которые на фронте не возможны по причине производительности, или по техническим возможностям фронта. Просто ETL нужно максимально систематизировать через КХД-проект, чтобы каждый аналитик не ETLил под себя. С другой стороны, часть бизнес-логики крутится вокруг вариантов показателей, где на базе 3-х полей из КХД может существовать 20 вариантов показателей, в т.ч. неаддитивных. И зашить их на уровень ETL просто нереалистично. Для таких решений и нужен DataForge - легковесный инструмент для описания показателей со сложной структурой (в т.ч. состоящих из других показателей), потому что не смотря на то что по дата-инженерной сложности такие показатели составляют условно 10%, в плане управленческого хаоса они генерируют все 90%.

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

Рубрика "я люблю ИИ". (я просил сгенерить список филиалов в городах РФ, основываясь на данных по выручке. Чем больше выручка, тем больше город должен быть)

Одно из преимуществ low-code - то, что это всё-таки code. Т.е. возможность пользователям создавать собственные функции. И без привлечения программистов, потому что code всё-таки low). Активно используем эти подходы в библиотеке построения КХД Data Monetization Pack, чтобы лучше интегрироваться в существующий ИТ-ландшафт клиента. Вот пример. Как известно, ETL-процессы не относятся к вещам из серии "один раз настроил и забыл". После того как все успешно запустилось, нужно продолжать мониторить работоспособность системы, чтобы своевременно реагировать на проблемы (например, БД-источник не ответила, или API зависло, или кто-то просто удалил нужный файл с данными). Для этого нужно парсить логи, выделять из них задачи планировщика, которые завершились с ошибкой. И куда-то сообщать об этом. В библиотеке DMP для парсинга логов есть готовый компонент. Одна из его функций - выводить логи, которые появились с момента предыдущей активации компонента. Т.е. можно поставить его на расписание, и при каждом запуске он будет анализировать только новые записи логов. К этому компоненту дописан шаблон сценария, который вычленяет из записей ошибки планировщика, и формирует по каждой из них отчет. Отчет дальше отправляется через клиентского телеграм-бота ответственному лицу. Схема хороша за счет того что быстро и просто поднимается, позволяет оперативно реагировать на проблему. Но всетаки, Телеграм - это не всегда приемлемый способ получения оповещений такого рода. Как быть? В рамках проектной работы или силами специалиста заказчика, наш шаблон может быть кастомизирован, чтобы передавать оповещения куда-то еще. Например, просто записывать их в таблицу БД, где о каждой новой записи будет сообщать уже какая-то система. При этом, у всех "родных" компонентов шаблона сохраняется связь с исходной библиотекой, и все обновления этих узлов в библиотеке также появятся в измененном шаблоне клиента. При этом его часть сценария останется неизменной. За счет этого, Loginom и библиотеку DMP можно легко интегрировать с существующими ресурсами компании, а также внешними инстурментами управления. В значительном количестве случаев, знаний языков программирования для этого не нужно.

Channel name was changed to «КУМБА! Low-code инжиниринг данных»