Выручка в CRM не равна выручке в 1С
Сделка закрыта в CRM, но счёт не оплачен; в 1С есть отгрузка, которой нет в CRM. Каждый отчёт считает по своему источнику, и на совещании обсуждают не решение, а расхождение в 12%.
Хранилище данных
Хранилище данных, в котором отчёты сходятся между собой
Проектируем модель данных, собираем источники в один контур и отдаём бизнесу витрины, где выручка, клиенты и запасы считаются одинаково — и в дашборде, и в выгрузке для бухгалтерии.
Или сразу: +7 (962) 368-39-51 Telegram
raw → mart
слои с понятной ответственностью
SCD2
история изменений справочников
ClickHouse
быстрые запросы по сотням миллионов строк
SLA
свежесть витрин под расписание бизнеса
Что происходит, когда хранилища нет
Данные есть в каждой системе по отдельности. Проблема начинается там, где их нужно свести в одну цифру.
Вместо витрин — выгрузки в Excel
Аналитик каждую неделю собирает отчёт вручную из выгрузок, копирует формулы и правит числа. Ошибка в одной ячейке живёт в отчёте месяцами, а восстановить логику расчёта по файлу невозможно.
Тяжёлый отчёт кладёт рабочую систему
Аналитический запрос с агрегацией по всей истории выполняется поверх операционной базы и блокирует таблицы. Продажи ждут, пока маркетинг считает воронку за три года.
Справочники перезаписываются
Менеджер переименовал клиента, категорию товара перевели в другую группу, а регион у поставщика указали заново. Старые отчёты при этом меняют прошлые цифры, и отчётность перестаёт быть воспроизводимой.
Непонятно, откуда взялась цифра
Показатель на дашборде расходится с ожиданием руководителя, и никто не может объяснить путь от исходной записи до готового числа. На разбор уходит день работы аналитика.
Данные выросли, а подход остался прежним
Таблица событий перевалила за сто миллионов строк, и прежние запросы стали занимать минуты. Выборки по сырым таблицам без партиционирования и агрегатов дальше не масштабируются.
Из чего состоит проект хранилища
Работу можно начать с одного домена — например, продажи и клиенты — и расширять по мере пользы.
Модель данных и слои
Проектируем структуру, в которой каждая таблица имеет одну ответственность и предсказуемую гранулярность.
- Слои raw, stage, core и mart с разными правилами доступа
- Схема «звезда» для витрин и нормализованное ядро для консистентности
- Историчность SCD2 для клиентов, товаров, договоров и тарифов
- Определение гранулярности факта: заказ, позиция заказа или отгрузка
Хранилище и производительность
Выбираем движок под характер запросов и объём данных, а не под привычку команды.
- PostgreSQL для ядра и небольших витрин с транзакционной загрузкой
- ClickHouse с движком MergeTree для событий и быстрых агрегатов
- Объектное хранилище с Iceberg или Delta Lake для длинной истории
- Партиционирование по датам, материализованные представления и TTL
Загрузка и витрины
Наполняем хранилище предсказуемо и превращаем его в готовые наборы данных для отчётов и моделей.
- Интеграции с 1С, CRM, сайтом, маркетплейсами и рекламными кабинетами
- dbt-модели с тестами на уникальность, ссылочную целостность и допустимые значения
- Витрины продаж, клиентов, логистики, маркетинга и финансов
- Единый слой определений метрик, чтобы выручка считалась одинаково везде
Эксплуатация и порядок в данных
Хранилище — это система, которая работает годами, поэтому отдельно занимаемся её обслуживанием.
- Мониторинг загрузок, алерты на срыв SLA по свежести данных
- Резервное копирование и проверка восстановления витрин
- Права доступа по ролям и разграничение персональных данных
- Документация моделей, родословная данных и контроль стоимости ресурсов
Как мы строим хранилище
Идём итерациями: после каждого этапа у бизнеса появляется рабочий отчёт, а не только архитектурная схема.
-
01 1–2 недели
Аудит источников и метрик
Разбираем системы, ключи, справочники и расхождения в цифрах. Собираем список показателей с определениями и владельцами.
-
02 2–4 недели
Модель и первый домен
Проектируем слои и согласуем модель данных. Поднимаем загрузку двух-трёх ключевых источников и собираем первую витрину.
-
03 6–12 недель
Масштабирование
Подключаем остальные источники, переносим расчёты из Excel, выводим витрины под отчётность и модели, ставим тесты качества данных.
-
04 2–3 недели, далее по SLA
Передача и поддержка
Документируем модель и регламенты, обучаем аналитиков, передаём дежурство по загрузкам или берём поддержку на себя.
Зачем нужны слои raw, core и mart
Слои разделяют ответственность и делают систему поддерживаемой. В raw данные лежат ровно в том виде, в каком пришли из источника: это точка восстановления, позволяющая пересобрать всё дальше без повторной выгрузки. В core данные очищены, приведены к единым ключам и обогащены историчностью. В mart лежат уже узкие витрины под конкретную задачу — отчёт по продажам, воронка маркетинга, взаиморасчёты.
Такое разделение экономит месяцы работы. Когда в источнике меняется поле или обнаруживается ошибка в расчёте, пересобирается нужный слой, а не вся аналитика. Кроме того, на каждом слое можно поставить свои тесты качества и понять, где именно испортились данные, — на входе или в преобразовании.
PostgreSQL или ClickHouse: как выбрать
PostgreSQL удобен как ядро хранилища: строгая схема, транзакции, привычный SQL, развитые средства разграничения доступа. Он хорошо держит десятки миллионов строк и сложные соединения, если запросы типовые, а не аналитические «на всю историю».
ClickHouse выигрывает там, где нужны агрегаты по сотням миллионов событий за секунды: логи, показы, клики, статусы заказов, телеметрия. Колоночное хранение, партиционирование по дате и материализованные представления дают скорость, недостижимую в построчных СУБД, но требуют аккуратности в проектировании ключей сортировки. На практике эти системы часто работают вместе: PostgreSQL отвечает за ядро и справочники, ClickHouse — за событийные витрины и тяжёлые агрегаты.
Как понять, что хранилище внедрено успешно
Есть несколько объективных признаков. Бизнес перестал спорить о цифрах: расхождения если и возникают, то разбираются по конкретной записи, а не по всему отчёту. Аналитик тратит время на разбор задач, а не на сборку выгрузок: девять из десяти вопросов закрываются готовой витриной. Отчёт за прошлый месяц можно воспроизвести через полгода и получить ту же цифру.
Технически это означает, что загрузки проходят по расписанию с алертами, тесты качества данных настроены на ключевые таблицы, у моделей есть описание и владелец, а изменение в источнике не приводит к тихой порче данных в витрине. Именно эти свойства мы считаем критерием сдачи проекта, а не факт наличия схемы в документации.
Частые вопросы
Часто достаточно облегчённого варианта: PostgreSQL, несколько витрин и dbt-модели поверх двух-трёх источников. Такой контур обходится без отдельного кластера и решает главную проблему — расхождение цифр между системами. Тяжёлые решения вроде ClickHouse или озера данных подключаем позже, когда появляется реальный объём событий.
Первая витрина по двум-трём источникам появляется через две-четыре недели после аудита данных. Полный контур с историчностью, тестами качества и основными доменами — от двух до четырёх месяцев. Срок определяется не технологией, а количеством источников и качеством ключей в них: интеграция с 1С и разбор справочников обычно занимают больше времени, чем настройка самого хранилища.
Мы не ломаем привычный процесс сразу. Сначала воспроизводим самые нагруженные отчёты в витринах и сверяем результаты с текущими файлами — расхождения разбираем как ошибки в данных или логике. Когда отчёт из хранилища совпадает и обновляется сам, файл выводим из обращения. Так переход проходит без остановки отчётности.
Хранилище — это фундамент: BI-системы, прогнозные модели и операционные алерты читают одни и те же витрины. Поэтому определения метрик задаются один раз на уровне модели данных, а не переписываются в каждом дашборде. Если позже добавляется новый инструмент визуализации или модель, она подключается к готовому слою и сразу использует согласованные цифры.
Data Science: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Нужен единый источник правды по данным?
Пришлите список систем и показателей, которые расходятся, — предложим архитектуру и план первого этапа.