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

В ноябре 2025 года мы начали внедрение новой системы на базе ClickHouse и XLTable.  Это был не просто перенос данных из одного хранилища в другое. При подготовке к внедрению мы пересмотрели саму архитектуру аналитического контура: откуда брать данные, где их хранить, как обрабатывать и как представить конечному пользователю.

В результате за время работы над новой архитектурой удалось:

• сократить объем данных за год со 100 до 20 ГБ;

• уменьшить время выполнения ETL-процессов с 6–7 часов до 1 часа;

• увеличить частоту обновления аналитических данных с 1 до 6 раз в день;

• сделать аналитическую модель прозрачнее для разработки и сопровождения.

В статье расскажу, почему мы не стали просто оптимизировать старую систему, как построили новый контур на ClickHouse и XLTable и что произошло после перехода.

Архитектура до изменений

До миграции корпоративное DWH для аналитических целей было построено на отдельной базе PostgreSQL. В общем контуре загрузки и подготовки данных использовались Apache Airflow, а источником данных была SQL-база 1С.

На стороне 1С формировались большие представления, из которых Apache Airflow по расписанию забирал данные и загружал их в PostgreSQL. Далее в PostgreSQL выполнялась значительная часть обработки: использовались процедуры, функции, промежуточные таблицы и дополнительные преобразования. Отдельной особенностью старой системы было формирование и выгрузка аналитических данных через Excel-макросы (VBA). Полученные данные использовались для дальнейшей аналитики и отчетов. В результате получалась довольно длинная и долгая цепочка обработки данных с большим количеством взаимозависимых компонентов.

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

Техническая сложность напрямую влияла на бизнес. В DWH хранились данные, необходимые для расчета ключевых показателей: выручки, оборота, маржинальности, чистой прибыли и других метрик. Но наличие данных еще не означает наличие понятной аналитической модели. Когда нужно было разобраться с показателем, важно было не только найти нужное конечное представление. Нужно было понять весь путь данных и бизнес-логику, которая стояла за расчётом. Получалось, что техническая структура хранилища начинала влиять на скорость работы с бизнес-вопросами.

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

Архитектура после изменений

Первой мыслью могло быть: «Почему бы нам не перенести существующую структуру в новую систему, а потом постепенно оптимизировать?». Но в этом случае мы бы перенесли не только данные, но и архитектурный долг. Если бы мы сохранили прежний подход, то вместе с таблицами переехали бы:

• сложные зависимости;

• большое количество промежуточных сущностей;

• процедуры и функции;

• распределённая бизнес-логика;

• трудности с пониманием происхождения показателей.

Поэтому мы решили использовать миграцию не просто как перенос данных, а как возможность пересобрать аналитический контур.

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

Перед проектированием архитектуры мы рассмотрели несколько вариантов семантического слоя, в том числе SQL Server Analysis Services (SSAS) и XLTable. Сравнивали их по функциональности, интеграции с Excel, требованиям к инфраструктуре, разработке и сопровождению, а также стоимости. 

SSAS — зрелая аналитическая платформа Microsoft. Она поддерживает Tabular и Multidimensional модели, сложные вычисления, роли и разграничение доступа и хорошо интегрируется с продуктами экосистемы Microsoft, включая Excel. При этом для работы SSAS требуется соответствующая серверная инфраструктура, а лицензирование связано с SQL Server. 

XLTable от BR Systems — XMLA-совместимый OLAP-семантический слой, который работает поверх аналитического хранилища. Он также поддерживает работу с Excel PivotTable и позволяет описывать метрики, измерения, иерархии и правила доступа. Является коммерческим продуктом, что также предполагает покупку лицензии. 

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

В этом сценарии XLTable оказался удобным вариантом. Он не хранит отдельную копию аналитических данных, а работает поверх хранилища, используя его возможности для выполнения запросов. Определения аналитической модели можно хранить в Git и изменять силами существующей команды. При этом у XLTable есть достаточно подробная и доступная документация, что позволяет разработчикам самостоятельно разбираться в возможностях системы и вносить изменения в определения аналитического куба. Кроме этого пользователи продолжают работать с привычным Excel и сводными таблицами.

После сравнения вариантов мы выбрали XLTable для работы с аналитическими данными, а ClickHouse — в качестве отдельного хранилища для аналитической нагрузки. Подготовленные данные из нашей шины регулярно передаются в ClickHouse, где используются для последующих расчётов и анализа. 

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

Таким образом, техническая реализация и пользовательский сценарий разделены: ClickHouse занимается хранением и обработкой аналитических данных, XLTable — представлением этой информации в виде понятной бизнес-модели.

PostgreSQL и ClickHouse решают разные задачи

Отдельно стоит сказать о выборе ClickHouse. Здесь вопрос не в том, какая база «лучше». Вопрос в том, какая база лучше соответствует конкретной задаче.

PostgreSQL — отличная универсальная реляционная база данных. Она является OLTP-системой и хорошо подходит для транзакционных систем, для типичных приложений, где есть большое количество операций чтения и записи отдельных записей: создать заказ, изменить статус, обновить клиента, сохранить платёж.

Но аналитическое DWH решает другую задачу. Здесь основной сценарий — взять большой объём данных, отфильтровать его, сгруппировать и рассчитать показатели. Именно под такие нагрузки ClickHouse подходит особенно хорошо. Для него характерны другие запросы: обработать миллионы или сотни миллионов строк, отфильтровать данные, выполнить агрегацию и получить результат по группам.

Одна из ключевых особенностей ClickHouse — колоночное хранение данных. В то время как в PostgreSQL данные традиционно организованы построчно. Если аналитическому запросу нужно посчитать оборот по регионам, ему интересны в первую очередь сумма, бренд, подразделение, дата. В колоночной СУБД значения разных колонок хранятся отдельно. Поэтому при выполнении аналитического запроса можно читать только необходимые колонки, не обрабатывая все остальные данные. На небольшом объеме разница может быть не принципиальной. Но когда таблица содержит десятки или сотни миллионов строк, объем данных, который необходимо прочитать и обработать, становится критичным фактором. Дополнительно ClickHouse использует эффективное сжатие данных и векторизованную обработку, что хорошо подходит для массовых операций над большими наборами однотипных данных.

Например, аналитический запрос:

SELECT
    brand,
    sum(amount)
FROM sales
WHERE date >= '2026-01-01'
GROUP BY brand;

для ClickHouse является типичной OLAP-задачей: прочитать нужные данные, отфильтровать их и выполнить агрегацию по большому количеству строк. Именно на таких операциях преимущества аналитической архитектуры становятся особенно заметны.

Но дело не только в скорости. Для нас переход на ClickHouse был важен не потому, что ClickHouse быстрее PostgreSQL. Гораздо важнее было подобрать хранилище под характер нагрузки. Старая система одновременно пыталась решать несколько задач: хранить данные, выполнять сложные преобразования, рассчитывать бизнес-логику и обслуживать аналитические запросы. В новой архитектуре ответственность стала более разделённой:

• транзакционные системы продолжают выполнять свою основную работу;

• данные из существующего корпоративного потока используются для формирования аналитического контура;

• ClickHouse отвечает за аналитическое хранение и обработку;

• XLTable отвечает за семантическую модель;

• пользователь работает уже с подготовленной аналитикой. 

Это важнее простого сравнения производительности двух баз. Мы перестали использовать одну технологию как универсальное решение для задач с принципиально разными требованиями.

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

Кроме того, определения кубов в XLTable можно хранить как код: они представлены SQL-файлами, которые можно держать в Git, просматривать через pull request и включать в существующий CI/CD-процесс. Для команды разработки это оказалось важным преимуществом. Аналитическая модель перестала быть чем-то, что существует отдельно от разработки.

Результаты изменений

Для меня как для тимлида и разработчика самым заметным изменением стала простота понимания и поддержки системы. Нам теперь не нужно восстанавливать длинную цепочку ETL зависимостей между источниками, представлениями, промежуточными таблицами, процедурами и функциями, чтобы понять происхождение показателя. Чтобы изменить расчет показателя или добавить новое поле, не нужно тратить дни: в зависимости от объема доработки занимают не более нескольких часов. 

Но есть и не менее важные изменения, такие как:

• объем данных — за год сократился примерно на 80%, со ~100 ГБ до ~20 ГБ;

• частота обновления — раньше аналитические данные обновлялись только один раз в день, в ночное время, чтобы не создавать дополнительную нагрузку на системы, задействованные в процессе. После перехода мы можем обновлять данные хоть каждый час, но такой частоты нам не требуется. Поэтому сейчас данные обновляются 6 раз в течение рабочего дня, что существенно повышает их актуальность для пользователей;

• время обработки данных — до миграции обмен данными с SQL-базой 1С и расчеты на стороне PostgreSQL занимали 6–7 часов. После перехода весь процесс обмена данными занимает около 1 часа — вместо практически целого рабочего дня.

Любую миграцию можно успешно завершить технически. Но есть не менее интересный вопрос: Пользуются ли системой после того, как разработчики закончили работу? Поэтому после запуска мы начали смотреть на фактическое использование нового контура и на основе журнала веб-сервера IIS (полный период) и журнала приложения XLTable и получили следующие результаты.

Сервис встроен в регулярные рабочие процессы: 98,7% запросов выполняется в будние дни и 97,7% — в рабочие часы; активность фиксируется практически каждый рабочий день (60 из 65 будних дней за последние 90 дней). Это профиль ежедневного рабочего инструмента.

Сформировано устойчивое ядро пользователей: 9 сотрудников используют сервис регулярно, из них пять — практически ежедневно на протяжении многих месяцев (48–77 активных дней). Текущая бизнес-отчётность этих сотрудников построена на кубах XLTable, и прекращение работы сервиса потребовало бы перестройки их рабочих процессов.

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

Текущая нагрузка стабильна: в среднем около 670 запросов в рабочий день за последние 90 дней; снижение летних объемов соответствует сезону отпусков и не затронуло регулярность использования ядром пользователей.

Мы также собрали обратную связь от пользователей, которые регулярно работают с аналитикой через привычный им Excel. Нам было важно оценить не только технические характеристики новой системы, но и то, насколько она удобна в повседневной работе и помогает получать данные, соответствующие реальной ситуации в компании. Для пользователей основной задачей перехода на куб стало создание удобной системы аналитики, которая использует актуальные данные из внутренних программ компании, в первую очередь из 1С.

По отзывам, после перехода повысилась скорость работы со сводными таблицами Excel: все необходимые фильтры работают стабильно, поиск по полям и параметрам стал удобнее, а сама система перестала «вылетать». Отдельно отметили более понятный набор полей: оставили только те параметры, которыми действительно пользуются сотрудники. Раньше их было значительно больше, и пользователям не всегда было понятно, какие из них актуальны. В кубе также появилась отдельная категория «Товары в пути» — товар уже выехал от поставщика и его можно учитывать при планировании и бронировании под продажи.

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

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

При этом переход на куб не означает, что пользователи сразу отказались от привычек, сформировавшихся за годы работы со старой системой аналитики. Ее использовали много лет, поэтому сотрудники успели хорошо изучить ее особенности и построить вокруг них свои рабочие сценарии. Например, раньше месяц был зашит непосредственно в год и выбирался в одном поле, а в кубе год и месяц представлены как отдельные поля. С точки зрения модели данных это более понятно и гибко, но пользователям потребовалось время, чтобы привыкнуть к новому интерфейсу.

На основе анализа статистики использования, отзывов пользователей и обратной связи от разработчиков мы считаем переход на новые технологии и архитектуру успешным. Нам удалось не только сократить объем данных и время их обработки, но и сделать аналитическую систему более актуальной, понятной и удобной для пользователей. При этом новая архитектура упростила дальнейшее развитие и масштабируемость системы.

Несмотря на то, что новая архитектура уже стала рабочей частью аналитического контура компании и используется в ежедневной работе, доработка системы продолжается — остаются задачи по подключению новых источников и дальнейшему развитию аналитической модели.

На текущем этапе мы подключаем и тестируем ИИ-модель для работы с аналитическими данными через MCP XLTable. AI-ассистент может обращаться к описанным аналитическим кубам, работать с их измерениями и показателями и выполнять агрегированные запросы к данным на естественном языке. При этом модель взаимодействует с тем же семантическим слоем, который используется в Excel, поэтому результаты строятся на единых определениях показателей и актуальных данных.

В перспективе такая система может стать не только инструментом подготовки отчетности, но и дополнительным интерфейсом для взаимодействия с данными: вместо ручного поиска показателей пользователь сможет сформулировать вопрос обычным языком и получить результат на основе корпоративной аналитической модели.

Полезные ссылки

• Официальный сайт XLTable

• Документация XLTable