Comments 6
«Ключевое ограничение — жёсткая зависимость от версии платформы: версия 1С на стороне ETL должна точно совпадать с версией платформы в базе‑источнике.»
Жесткий вендор-лок.
Берём второй источник, добавляем соединение (LEFT JOIN), настраиваем ключи – и видим объединённые данные. Каждый шаг прозрачен: можно посмотреть и SQL-запрос, и предварительный результат.
Интересно, как два поля timestamp лягут в БД ) И зачем джойнить на источнике?
На сайте также указано, что витрины данных являются запросами/представлениями... Отчеты лягут под нагрузкой при большом количестве соединений.
ELT-подход с внешним КХД – данные хранятся в стандартной СУБД (PostgreSQL, ClickHouse и др.), трансформации на нативном SQL. Никаких проприетарных хранилищ.
Проприетарный сам инструмент.
Уже сталкивался с "бессрочными лицензиями". Схема простая - выпускаем продукт с новой версией - доплатите за апгрейд, а старый прекращает поддержку и обновления. Лицензии, к слову, на сайте не нашел в доступе.
Работа с параметрами и инкрементальная загрузка
Для больших баз предусмотрена работа с параметрами: можно задать дату начала и конца периода, и система будет забирать данные только за указанный диапазон.
Это не инкрементальная загрузка, это обновление заданного периода.
Спасибо за комментарий с разбором! Отвечу по пунктам.
"Жесткий вендор-лок"
Цитата из статьи относится к разделу про COM-коннектор, который в статье прямо назван legacy-решением. Основной способ подключения к 1С в Modus ETL – это HTTP-адаптер ETL-1С. Он встраивается расширением в базу клиента и не требует совпадения версий платформы между ETL-сервером и источником. Отдельно в блоке “Что вызывало вопросы” я отразил требование минимальной версии 8.3.21 и обходной путь через отдельный инстанс 1С под ETL. Назвать это классическим вендор-локом сложном: привязка к поставщику – это скорее про невозможность забрать данные к другому вендор: а здесь речь скорее про совместимость версий платформы 1С. Ведь данные у клиента по-прежнему лежат в стандартной СУБД и в любой момент доступны вне Modus.
Интересно, как два поля timestamp лягут в БД )
По timestamp – в таблицах КХД поля имеют ровно ту размерность, какую задали при настройке приёмника. Это вопрос к проектированию витрины, а не к инструменту.
И зачем джойнить на источнике?
По LEFT JOIN – у нас в статье есть установочный абзац: «После загрузки сырых данных в КХД начинается этап трансформации. Modus ETL предлагает два подхода. Первый – WorkFlow». И первый шаг примера: «Берём источник (таблицу из КХД)». То есть «источник» в WorkFlow – это не живая база 1С, а таблица уже внутри хранилища. JOIN идёт между двумя таблицами КХД, на родном SQL-диалекте этой СУБД (PostgreSQL, ClickHouse и т.д.). Это и есть ELT-подход: Extract+Load выполняется агентом ETL отдельно, Transform – это следующий этап, уже внутри КХД.
Признаю, что недопонимание возникло по моей вине, так как слово “источник” в статье используется в двух разных смыслах – как внешняя система (1С, PostgreSQL клиента, файлы) и как элемент пайплайна. В следующих статья учту этот момент.
На сайте также указано, что витрины данных являются запросами/представлениями... Отчеты лягут под нагрузкой при большом количестве соединений.
По витринам как представлениям – вопрос по делу, тут есть архитектурный нюанс. Да, если витрина оформлена как SQL-представление со сложными джойнами, под нагрузкой она будет пересчитываться на каждый запрос к дашборду – это справедливо для любого BI, не только для Modus. Лечится это стандартными средствами: материализованные таблицы вместо views, правильный выбор СУБД под витрины, предагрегаты. В WorkFlow конечный блок «приёмник» как раз пишет результат в таблицу, то есть инструмент для материализации штатный. Вопрос проектирования, а не ограничение продукта.
Это не инкрементальная загрузка, это обновление заданного периода.
По инкрементальной загрузке – здесь комментарий по делу. В подразделе действительно слиплись два разных механизма. Работа с параметрами периода – это не инкремент, а перезагрузка указанного диапазона, тут всё верно. Настоящий инкремент в Modus реализован через планы обмена 1С – этот абзац в статье есть сразу под параметрами. Заголовок подраздела «Работа с параметрами и инкрементальная загрузка» действительно вводит в заблуждение. Учту в будущих статьях.
Уже сталкивался с "бессрочными лицензиями". Схема простая - выпускаем продукт с новой версией - доплатите за апгрейд, а старый прекращает поддержку и обновления. Лицензии, к слову, на сайте не нашел в доступе.
Задал вопрос вендору, получил прямой ответ: в бессрочную лицензию входит доступ к обновлениям и техподдержке на 1 год, дальше продление платное. То есть схема ровно такая, как вы описали: купил – через год либо платишь за продление, либо сидишь на версии, которая у тебя есть, без обновлений и поддержки.
Это, к слову, стандартная модель для российского (и не только) enterprise-софта – так работает подавляющее большинство вендоров с «бессрочной» лицензией. Важно учитывать при расчёте TCO на 3–5 лет, а не ориентироваться только на цену первого года.
Цены на сайте действительно публично не выложены, в статье это отмечено.
Проприетарный сам инструмент.
Оговорка справедливая. Формулировка "никаких проприетарных хранилищ" в статье относилась именно к слою данных: они лежат в стандартной СУБД, и физически ничто не держит клиента в Modus – хранилище можно забрать и подключить к чему угодно.
Сам движок ETL, портал и метаданные, конечно, проприетарны – как и у любого коммерческого BI.
Можно ли запустить корпоративную BI+ETL-систему за 1,5 млн рублей? Часть 2: Modus ETL & Modus BI