В целом согласен. А сейчас с ними что не так? Я обратил внимание только на какой-то невероятный расход токенов (или урезание лимитов) при использовании семейства Opus. А вот урезания качества как раз не заметил. Может только один раз, когда Claude в упор не видел фундаментальную проблему в Python-скрипте, а ChatGPT ее моментально нашел
Есть какое-то систематизированное описание этого понятия? Может онтология, концепция и т.п. Это как-то можно "притянуть" к МетаТеории связей? Также есть понятие Алгебра процессов (process algebra), но это тоже видимо "не сюда".
Про «алгебру операций над данными»: я использовал термин в широком неформальном смысле – обозначая набор операций rapeed над источниками (справочники как виртуальные поля, связи между источниками разной гранулярности, агрегации поверх них). Публичного формализованного описания я у вендора в открытых материалах не встречал.
Как это пересекается с инструментами Качество данных \ Управление данными?
Про пересечение Области связей с Качеством данных и Управлением данными: прямого пересечения нет. Это инструмент data discovery – визуального исследования модели данных, которую пользователь собрал в rapeed. С DQ пересечение косвенное: аномалии в иерархиях Область связей подсвечивает попутно, но это побочный эффект, а не результат проверки правил.
Уже сталкивался с "бессрочными лицензиями". Схема простая - выпускаем продукт с новой версией - доплатите за апгрейд, а старый прекращает поддержку и обновления. Лицензии, к слову, на сайте не нашел в доступе.
Задал вопрос вендору, получил прямой ответ: в бессрочную лицензию входит доступ к обновлениям и техподдержке на 1 год, дальше продление платное. То есть схема ровно такая, как вы описали: купил – через год либо платишь за продление, либо сидишь на версии, которая у тебя есть, без обновлений и поддержки. Это, к слову, стандартная модель для российского (и не только) enterprise-софта – так работает подавляющее большинство вендоров с «бессрочной» лицензией. Важно учитывать при расчёте TCO на 3–5 лет, а не ориентироваться только на цену первого года. Цены на сайте действительно публично не выложены, в статье это отмечено.
Проприетарный сам инструмент.
Оговорка справедливая. Формулировка "никаких проприетарных хранилищ" в статье относилась именно к слою данных: они лежат в стандартной СУБД, и физически ничто не держит клиента в Modus – хранилище можно забрать и подключить к чему угодно. Сам движок ETL, портал и метаданные, конечно, проприетарны – как и у любого коммерческого BI.
Это не инкрементальная загрузка, это обновление заданного периода.
По инкрементальной загрузке – здесь комментарий по делу. В подразделе действительно слиплись два разных механизма. Работа с параметрами периода – это не инкремент, а перезагрузка указанного диапазона, тут всё верно. Настоящий инкремент в Modus реализован через планы обмена 1С – этот абзац в статье есть сразу под параметрами. Заголовок подраздела «Работа с параметрами и инкрементальная загрузка» действительно вводит в заблуждение. Учту в будущих статьях.
На сайте также указано, что витрины данных являются запросами/представлениями... Отчеты лягут под нагрузкой при большом количестве соединений.
По витринам как представлениям – вопрос по делу, тут есть архитектурный нюанс. Да, если витрина оформлена как SQL-представление со сложными джойнами, под нагрузкой она будет пересчитываться на каждый запрос к дашборду – это справедливо для любого BI, не только для Modus. Лечится это стандартными средствами: материализованные таблицы вместо views, правильный выбор СУБД под витрины, предагрегаты. В WorkFlow конечный блок «приёмник» как раз пишет результат в таблицу, то есть инструмент для материализации штатный. Вопрос проектирования, а не ограничение продукта.
По timestamp – в таблицах КХД поля имеют ровно ту размерность, какую задали при настройке приёмника. Это вопрос к проектированию витрины, а не к инструменту.
И зачем джойнить на источнике?
По LEFT JOIN – у нас в статье есть установочный абзац: «После загрузки сырых данных в КХД начинается этап трансформации. Modus ETL предлагает два подхода. Первый – WorkFlow». И первый шаг примера: «Берём источник (таблицу из КХД)». То есть «источник» в WorkFlow – это не живая база 1С, а таблица уже внутри хранилища. JOIN идёт между двумя таблицами КХД, на родном SQL-диалекте этой СУБД (PostgreSQL, ClickHouse и т.д.). Это и есть ELT-подход: Extract+Load выполняется агентом ETL отдельно, Transform – это следующий этап, уже внутри КХД. Признаю, что недопонимание возникло по моей вине, так как слово “источник” в статье используется в двух разных смыслах – как внешняя система (1С, PostgreSQL клиента, файлы) и как элемент пайплайна. В следующих статья учту этот момент.
Спасибо за комментарий с разбором! Отвечу по пунктам.
"Жесткий вендор-лок"
Цитата из статьи относится к разделу про COM-коннектор, который в статье прямо назван legacy-решением. Основной способ подключения к 1С в Modus ETL – это HTTP-адаптер ETL-1С. Он встраивается расширением в базу клиента и не требует совпадения версий платформы между ETL-сервером и источником. Отдельно в блоке “Что вызывало вопросы” я отразил требование минимальной версии 8.3.21 и обходной путь через отдельный инстанс 1С под ETL. Назвать это классическим вендор-локом сложном: привязка к поставщику – это скорее про невозможность забрать данные к другому вендор: а здесь речь скорее про совместимость версий платформы 1С. Ведь данные у клиента по-прежнему лежат в стандартной СУБД и в любой момент доступны вне Modus.
Я сам плотно использую ИИ и в работе, и в жизни – Cursor, ChatGPT, Claude, всё это знакомо :) Прекрасно понимаю, какие чудеса можно творить с такими бюджетами. Но всё равно было бы очень интересно почитать про реальный опыт – пишите, жду поста про BI для малоимущих!
"Как я потерял семью и сон, настраивая Metabase или Apache Superset + Apache NiFi + ClickHouse". Может, когда-нибудь напишу :)
Если серьёзно — в исследовании рассматриваю коммерческие отечественные решения, где вендор берёт на себя поддержку, обновления и хоть какую-то гарантию, что продукт будет жить. Для МСБ это часто важнее, чем нулевая стоимость лицензии. Но идея хорошая, беру на вооружение!
Отличная статья! Не знал что так много можно выжать из этой системы. Использовали ли вы стандартные плоские таблицы в Visiology? Когда я последний раз работал в этой системе, там, к сожалению, не было возможности даже итоги в таблице включить.
Верно, не учитывает. Если у клиента появится требование, в котором расчет прогноза должен будет производиться с учетом сезонности, то это мы тоже сможем реализовать.
Добрый день! На связи разработчик Белого кода. В случае с аптечными сетям, данные мы вытягиваем из Смарт-Аптеки, как правило, это единственный источник. Если у клиента есть планы в Excel, то их можно подгрузить в Google-Таблицу и тянуть оттуда, чтобы каждый месяц руками не загружать эксель в систему. Прогноз у нас линейный, вычисляем сами.
Тут больше вопросы к вендору. Мы не вендор, но передали ему ваши вопросы.
В целом согласен. А сейчас с ними что не так? Я обратил внимание только на какой-то невероятный расход токенов (или урезание лимитов) при использовании семейства Opus. А вот урезания качества как раз не заметил.
Может только один раз, когда Claude в упор не видел фундаментальную проблему в Python-скрипте, а ChatGPT ее моментально нашел
А что дали Антропик, чего не дали OpenAI?
Про «алгебру операций над данными»: я использовал термин в широком неформальном смысле – обозначая набор операций rapeed над источниками (справочники как виртуальные поля, связи между источниками разной гранулярности, агрегации поверх них). Публичного формализованного описания я у вендора в открытых материалах не встречал.
Про пересечение Области связей с Качеством данных и Управлением данными: прямого пересечения нет. Это инструмент data discovery – визуального исследования модели данных, которую пользователь собрал в rapeed. С DQ пересечение косвенное: аномалии в иерархиях Область связей подсвечивает попутно, но это побочный эффект, а не результат проверки правил.
Задал вопрос вендору, получил прямой ответ: в бессрочную лицензию входит доступ к обновлениям и техподдержке на 1 год, дальше продление платное. То есть схема ровно такая, как вы описали: купил – через год либо платишь за продление, либо сидишь на версии, которая у тебя есть, без обновлений и поддержки.
Это, к слову, стандартная модель для российского (и не только) enterprise-софта – так работает подавляющее большинство вендоров с «бессрочной» лицензией. Важно учитывать при расчёте TCO на 3–5 лет, а не ориентироваться только на цену первого года.
Цены на сайте действительно публично не выложены, в статье это отмечено.
Оговорка справедливая. Формулировка "никаких проприетарных хранилищ" в статье относилась именно к слою данных: они лежат в стандартной СУБД, и физически ничто не держит клиента в Modus – хранилище можно забрать и подключить к чему угодно.
Сам движок ETL, портал и метаданные, конечно, проприетарны – как и у любого коммерческого BI.
По инкрементальной загрузке – здесь комментарий по делу. В подразделе действительно слиплись два разных механизма. Работа с параметрами периода – это не инкремент, а перезагрузка указанного диапазона, тут всё верно. Настоящий инкремент в Modus реализован через планы обмена 1С – этот абзац в статье есть сразу под параметрами. Заголовок подраздела «Работа с параметрами и инкрементальная загрузка» действительно вводит в заблуждение. Учту в будущих статьях.
По витринам как представлениям – вопрос по делу, тут есть архитектурный нюанс. Да, если витрина оформлена как SQL-представление со сложными джойнами, под нагрузкой она будет пересчитываться на каждый запрос к дашборду – это справедливо для любого BI, не только для Modus. Лечится это стандартными средствами: материализованные таблицы вместо views, правильный выбор СУБД под витрины, предагрегаты. В WorkFlow конечный блок «приёмник» как раз пишет результат в таблицу, то есть инструмент для материализации штатный. Вопрос проектирования, а не ограничение продукта.
По timestamp – в таблицах КХД поля имеют ровно ту размерность, какую задали при настройке приёмника. Это вопрос к проектированию витрины, а не к инструменту.
По LEFT JOIN – у нас в статье есть установочный абзац: «После загрузки сырых данных в КХД начинается этап трансформации. Modus ETL предлагает два подхода. Первый – WorkFlow». И первый шаг примера: «Берём источник (таблицу из КХД)». То есть «источник» в WorkFlow – это не живая база 1С, а таблица уже внутри хранилища. JOIN идёт между двумя таблицами КХД, на родном SQL-диалекте этой СУБД (PostgreSQL, ClickHouse и т.д.). Это и есть ELT-подход: Extract+Load выполняется агентом ETL отдельно, Transform – это следующий этап, уже внутри КХД.
Признаю, что недопонимание возникло по моей вине, так как слово “источник” в статье используется в двух разных смыслах – как внешняя система (1С, PostgreSQL клиента, файлы) и как элемент пайплайна. В следующих статья учту этот момент.
Спасибо за комментарий с разбором! Отвечу по пунктам.
Цитата из статьи относится к разделу про COM-коннектор, который в статье прямо назван legacy-решением. Основной способ подключения к 1С в Modus ETL – это HTTP-адаптер ETL-1С. Он встраивается расширением в базу клиента и не требует совпадения версий платформы между ETL-сервером и источником. Отдельно в блоке “Что вызывало вопросы” я отразил требование минимальной версии 8.3.21 и обходной путь через отдельный инстанс 1С под ETL. Назвать это классическим вендор-локом сложном: привязка к поставщику – это скорее про невозможность забрать данные к другому вендор: а здесь речь скорее про совместимость версий платформы 1С. Ведь данные у клиента по-прежнему лежат в стандартной СУБД и в любой момент доступны вне Modus.
Я сам плотно использую ИИ и в работе, и в жизни – Cursor, ChatGPT, Claude, всё это знакомо :) Прекрасно понимаю, какие чудеса можно творить с такими бюджетами. Но всё равно было бы очень интересно почитать про реальный опыт – пишите, жду поста про BI для малоимущих!
"Как я потерял семью и сон, настраивая Metabase или Apache Superset + Apache NiFi + ClickHouse". Может, когда-нибудь напишу :)
Если серьёзно — в исследовании рассматриваю коммерческие отечественные решения, где вендор берёт на себя поддержку, обновления и хоть какую-то гарантию, что продукт будет жить. Для МСБ это часто важнее, чем нулевая стоимость лицензии.
Но идея хорошая, беру на вооружение!
Отличная статья! Не знал что так много можно выжать из этой системы. Использовали ли вы стандартные плоские таблицы в Visiology? Когда я последний раз работал в этой системе, там, к сожалению, не было возможности даже итоги в таблице включить.
Верно, не учитывает. Если у клиента появится требование, в котором расчет прогноза должен будет производиться с учетом сезонности, то это мы тоже сможем реализовать.
Добрый день! На связи разработчик Белого кода. В случае с аптечными сетям, данные мы вытягиваем из Смарт-Аптеки, как правило, это единственный источник. Если у клиента есть планы в Excel, то их можно подгрузить в Google-Таблицу и тянуть оттуда, чтобы каждый месяц руками не загружать эксель в систему. Прогноз у нас линейный, вычисляем сами.