Сейчас мы строим и проектируем 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.