Проект МТО начался с понятной цели: холдинг должен управлять своими запасами. Нужно было навести порядок в хранении, сократить объём лишних запасов, разобраться, кто за что отвечает, и получить инструмент, чтобы оперативно видеть, что происходит. Задача пришла от проектного офиса, а мне предстояло превратить всё это в дашборды.

Первая мысль была простой: данные уже есть в 1С, значит надо просто подключиться и забрать то, что нужно. Источников было два: 1С УХ и 1С УПП. На словах всё выглядело элементарно.

На практике первым препятствием оказалась даже не производительность, а сама структура данных. Открыв физические таблицы 1С, я увидел вместо понятных названий конструкции вроде _Document456, _Reference123, _AccumRg901, а поля внутри носили такие же технические имена. По названию можно было понять тип объекта, но чтобы восстановить реальные связи и понять, где лежит нужная бизнес-информация, нужно было знать структуру конкретной конфигурации.

Мне уже доводилось пытаться разобраться с подобной задачей самостоятельно. Я смотрел таблицы, искал связи, сопоставлял поля и рисовал схемы в draw.io, по сути восстанавливая модель данных снизу вверх. Это было долго и больно, хотя и имело свои успехи. Довольно быстро стало понятно: без человека, который хорошо знает конкретную конфигурацию, такой путь превращается в археологию. Между тем, как бизнес называет объект (“Запасы”, “Номенклатура”, “Остатки”), и тем, как он физически лежит в базе, оказался целый слой метаданных, который ещё предстояло научиться читать.

Но даже если разобраться со структурой, оставался другой вопрос: а стоит ли вообще постоянно ходить за аналитикой напрямую в 1С? 1С УХ и УПП были рабочими транзакционными системами, в них постоянно работали сотни пользователей, создавали документы, проводили операции. Запускать поверх такой базы тяжёлые аналитические запросы ради дашбордов уже не выглядело безобидной идеей. Система должна в первую очередь выполнять свою основную работу, а не обслуживать наши отчёты.

Поэтому в архитектуре потребовались две вещи: инструмент, который умеет доставать нужные данные из 1С, и отдельный слой сырых данных в аналитической базе. Экстрактор уже был частью решения со стороны 1С-специалистов, а в качестве аналитической БЛ уже выбрали ClickHouse, и теперь данные мы решили разделить на слои.

Экстрактор это промежуточный механизм между 1С и аналитикой: он забирает данные из 1С и передаёт их дальше, чтобы не приходилось постоянно читать рабочую базу напрямую. Он умел выгружать таблицы, запросы и документы, а затем загружать результат в ClickHouse.

Выгрузка запускалась в определённое время, отдельно от работы пользователей с 1С, что не создавало лишней нагрузки на рабочую базу. При этом у него была особенность: независимо от исходного типа поля, данные при выгрузке приводились к универсальному формату Nullable(String). Для универсального инструмента это понятное решение: не нужно заранее знать тип каждого поля в каждой конфигурации, достаточно забрать значение и передать дальше. Что я с этим дальше делал, рассказывал в предыдущем посте.

В итоге получилось разделение ответственности: 1С осталась системой, в которой работает бизнес, экстрактор занимался доставкой данных, а ClickHouse стал местом, где можно было спокойно строить аналитику, не превращая каждую витрину в запрос к рабочей системе.

Признаюсь, в тот момент я ещё не знал, какие слои должны быть в DWH и по каким принципам его вообще стоит строить. Но по тому, сколько источников, форматов и нюансов уже приходилось учитывать на этом этапе, было видно: это не разовая выгрузка для одного дашборда, а система, с которой придётся жить и которую придётся развивать дальше. Это и стало отправной точкой для дальнейших поисков.

Что и почему получалось на практике дальше, расскажу в следующих постах про этот проект.