Время на прочтение: 7 минут

Дата публикации: 25.09.2026

Когда данные компании находятся в 1С, CRM, Excel, Google Таблицах, интернет-магазине и других информационных системах, построить единый отчет становится отдельной технической задачей. В каждой системе свои форматы, справочники, идентификаторы, правила расчета показателей и периодичность обновления. В результате один и тот же показатель в разных отчетах может считаться по-разному, а аналитик тратит время не на поиск закономерностей, а на сверку выгрузок.

Архитектура DWH решает эту проблему за счет единого контура хранения и обработки данных. Корпоративное хранилище собирает информацию из разных источников, приводит ее к согласованной структуре, сохраняет историю изменений и предоставляет данные тем, кто с ними работает: аналитикам, BI-системам, дата-сайентистам и другим потребителям.

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

DWH (Data Warehouse) — корпоративное хранилище данных, в котором объединяется информация из различных систем компании для аналитики, отчетности и других сценариев работы с данными.

Типовая схема выглядит так:

Источниками могут быть учетные системы, CRM, базы данных, файлы, API, веб-сервисы и потоковые источники. Например, в одном проекте в DWH объединяли данные из 1С, Google Таблиц, Excel, XML-выгрузок из MS Project и внутренней информационной системы. Хранилище было реализовано на PostgreSQL, после чего подготовленные данные использовались для аналитики и дашбордов в Apache Superset.

Основная ценность появляется там, где нужно связать данные, которые по отдельности ничего не дают. Например, CRM знает о клиенте, 1С — о его оплатах, рекламная система — о первом касании, а складская система — о заказе. DWH позволяет собрать эти события в единую модель и анализировать уже не отдельный участок, а весь бизнес-процесс.

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

1. Источники данных

На первом уровне находятся системы, в которых данные появляются изначально:

• ERP и учетные системы;
• CRM;
• базы данных;
• Excel и другие файлы;
• внешние API и веб-сервисы;
• объектные хранилища;
• потоковые источники.

У каждого источника своя структура. Один и тот же клиент может иметь разные идентификаторы в CRM и 1С, а справочник товаров — отличающиеся названия и коды.

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

2. Загрузка данных и staging

Следующий уровень отвечает за получение информации из источников. Для этого используются ETL/ELT-процессы (способы извлечения, загрузки и преобразования данных), а оркестрацию загрузок (управление последовательностью и расписанием этих процессов) можно реализовать, например, через Apache Airflow.

Важный вопрос здесь — не только «как забрать данные», но и что именно загружать. Для небольших источников допустима полная загрузка, когда данные каждый раз переносятся целиком. При больших объемах обычно переходят на инкрементальную схему (загрузка только новых или изменившихся данных) или CDC (Change Data Capture — отслеживание изменений в источнике и передача только тех записей, которые были изменены).

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

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

3. DWH Core

В центральном слое формируется согласованная модель данных. Здесь объединяются источники, унифицируются справочники, задаются ключи и правила обработки.

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

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

Автоматизируем сбор данных и освободим команду от ручной аналитики

Сотрудники тратят часы на отчеты?

После формирования Core данные подготавливаются для конкретных задач. Для этого создаются Data Mart — витрины данных.

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

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

В архитектуре DWH есть компоненты, которые пользователь может вообще не видеть, но без них хранилище быстро становится сложным для сопровождения.

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

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

Есть несколько распространенных подходов к проектированию модели. В классическом варианте можно использовать размерную модель Кимбалла, корпоративный подход Инмона или Data Vault.

Кимбалл предполагает движение от отдельных предметных витрин к единой аналитической системе. Подход Инмона строится от корпоративного ядра к витринам. Data Vault делает акцент на хранении бизнес-ключей, связей и истории изменений и особенно полезен там, где источники часто меняются.

Выбор здесь нельзя делать по принципу «какая методология популярнее». Подход зависит от масштаба проекта, стабильности источников, требований к историчности и скорости развития хранилища.

Покажем демо-дашборд и расскажем, как это работает на практике

Один дашборд вместо десятков отчетов

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

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

Поэтому для DWH часто выбирают аналитические СУБД с поддержкой масштабирования и обработки больших объемов данных.

Основная сложность DWH обычно не в создании таблиц, а в согласовании данных и правил бизнеса.
Еще на этапе проектирования нужно определить, какие источники являются мастер-данными, как объединять справочники, какие изменения сохранять в истории, как часто обновлять данные и кто отвечает за определение показателей.

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

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

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

Поэтому при внедрении DWH важно проектировать не только будущие отчеты, но и весь путь данных: от источника и способа загрузки до модели, истории, витрины и конкретного потребителя.

В этом и заключается разница между просто базой с собранными данными и полноценным корпоративным хранилищем. В первом случае информация просто находится в одном месте. Во втором — для нее заранее определены структура, правила обработки, история, качество и способы использования.

Правильно спроектированная архитектура DWH позволяет компании добавлять новые источники и аналитические сценарии без постоянной переделки уже работающего контура. Именно поэтому при внедрении хранилища начинать стоит не с выбора конкретной СУБД или BI-инструмента, а с архитектуры данных, бизнес-логики и требований к будущей системе.

Мы уже реализовали более 127 проектов по настройке BI-аналитики под разные задачи. Проведём бесплатную консультацию и аудит ваших процессов, чтобы предложить оптимальное решение именно для вас.
Запишитесь на бесплатную консультацию, и мы поможем сделать аналитику вашего бизнеса прозрачной и эффективной.