Как стать автором
Обновить
87.77
Sminex
Создаём комфортную среду для жизни и работы

Бизнес-сериал: формируем BI-систему в строительстве почти в прямом эфире. Часть I

Уровень сложностиСредний
Время на прочтение4 мин
Количество просмотров1.6K

Сейчас мы строим и проектируем 820 тыс. кв. м жилой и коммерческой недвижимости в высших ценовых сегментах. Это 13 девелоперских проектов в престижных районах Москвы. Помимо прочего, это колоссальный объём данных от разных подразделений: от продуктологов до менеджеров по продажам. Чтобы систематизировать эту информацию и управлять бизнес-процессами, мы реализуем BI-систему для сбора, хранения, анализа и наглядного отображения данных. В этой серии статей рассказываем о том, как мы выстраиваем её в девелоперской компании.

Как сейчас?

Имеем:

  1. Источники данных: 1C (Управленческий учет, CRM, ЗУП), Microsoft Project, Jira, Zabbix, BIM-модели, СКУД, несколько десятков справочников, несколько внешних источников с данными о реализации недвижимости и несколько xlsx-файлов, которые ведутся пользователями (есть свет в конце Экселя);

  2. Отчётность: более 30 разных отчётов, разделённых на 5 групп по административному признаку. Это отчёты Коммерческого блока, отчёты Блока строительства и подобные. Документы сложные, охватывают несколько метрик каждый. И запрос на разработку новых или доработку старых метрик не снижается;

  3. Хранилище данных: СУБД — MS SQL и Clickhouse. Само хранилище представляет собой набор денормализованных таблиц, собранных из источников. Обновление данных выполняется в среднем 1 раз в сутки и 1 раз в неделю для внешних источников. Значимых трансформаций с данными не проводится. Большая часть вычислительных операций осуществляется на уровне отчёта с помощью DAX.

Итак, некоторый образ BI-системы у нас есть, но он не решает ряд обязательных задач:

  • Данные остаются несогласованными между разными системами-источниками и пользовательскими файлами, что приводит к расхождениям в отчётности;

  • У хранилища нет гибкости. Любое изменение структуры данных, особенно частое в данных управленческого учета и строительства, приводит к работам по переписыванию скриптов и пересозданию таблиц;

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

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

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

Постановка задачи

Проведя kick-off встречи с представителями различных подразделений, мы выделили некоторые общие требования к разрабатываемой BI-системе:

  1. Отчёты отображают верные данные, им можно верить без дополнительных проверок;

  2. Отчёты отображают актуальные данные;

  3. Отчёты, объединённые одной группой, имеют общий стиль и структуру;

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

  5. Изменение структуры данных не парализует BI-систему, необходимые доработки выполняются в течение 1 рабочего дня.

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

Выбор архитектуры и технологического стека

Чтобы подобрать приемлемый стек нужно провести несколько несложных измерений. Мы выбрали следующие:

  • Общий объем хранимых данных составляет около полутерабайта. Однако нужно учитывать, что текущая модель хранения во многом избыточна. И это место может быть сокращено;

  • Ежедневный инкремент. Так как сейчас инкрементального обновления нет в принципе, в порядке эксперимента стали фиксировать размер таблиц за каждый день и таким образом смогли вычислить разницу. Она получилась около 300 мегабайт в день, с ростом до одного гигабайта в конце недели, когда подгружаются данные из внешнего источника;

  • Актуальность. По этому вопросу разброс от 1 недели до 2 часов. Ориентируемся на самый высокий запрос, то есть «сейчас — 2 часа».

В качестве рабочего варианта мы выбрали следующее:

  • Miner — набор методов извлечения данных из источников;

  • Cleaner — набор методов очистки данных от грубых ошибок;

  • Validator — набор методов проверки качества данных;

  • Data Warehouse — корпоративное хранилище данных.

Более подробно про Miner, Cleaner и Validator мы расскажем в последующих публикациях. На текущем этапе имеет смысл остановиться на архитектуре DWH — Data Warehouse.

На её выбор влияют такие особенности:

  • Разнородный перечень источников, есть несистемные источники;

  • Количество самостоятельных сущностей около 40, при этом у большей части из них свыше 20 атрибутов и много связей с другими объектами;

  • Много справочников, связанных со спецификой отрасли;

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

С учетом измерений, описанных выше, и этих особенностей, архитектура хранилища данных приняла следующий вид:

Clickhouse будет использоваться для сбора информации со всех источников без каких-либо трансформаций и объединений. Также его выбор обоснован минимальными требованиями к обслуживанию и более высоким уровнем оптимизации для интеграции с Apache Kafka по сравнению с PostgreSQL.

Основным местом хранения данных обо всех объектах будет ODS с архитектурой Anchor Modeling и DDS с архитектурой «Снежинка». Для слоя ODS выбран PostgreSQL с расширением Citus, обеспечивающим колоночное хранение данных. Для слоя DDS выбран ванильный PostgreSQL, так как там планируется хранить данные по изолированным направлениям работы компании, которые не обладают изменчивой структурой. В целом PostgreSQL, как с Citus, так и без него, обеспечивает высокую производительность, в том числе для аналитических нагрузок.

Слои PDM и DM предназначены для упрощения жизни аналитиков и BI-разработчиков. Там будут создаваться витрины данных для использования в отчетах и в анализе данных.

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

Вместо заключения

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

Теги:
Хабы:
Всего голосов 2: ↑2 и ↓0+2
Комментарии6

Публикации

Информация

Сайт
sminex.com
Дата регистрации
Дата основания
2007
Численность
1 001–5 000 человек
Местоположение
Россия