Сейчас мы строим и проектируем 820 тыс. кв. м жилой и коммерческой недвижимости в высших ценовых сегментах. Это 13 девелоперских проектов в престижных районах Москвы. Помимо прочего, это колоссальный объём данных от разных подразделений: от продуктологов до менеджеров по продажам. Чтобы систематизировать эту информацию и управлять бизнес-процессами, мы реализуем BI-систему для сбора, хранения, анализа и наглядного отображения данных. В этой серии статей рассказываем о том, как мы выстраиваем её в девелоперской компании.
Как сейчас?
Имеем:
Источники данных: 1C (Управленческий учет, CRM, ЗУП), Microsoft Project, Jira, Zabbix, BIM-модели, СКУД, несколько десятков справочников, несколько внешних источников с данными о реализации недвижимости и несколько xlsx-файлов, которые ведутся пользователями (есть свет в конце Экселя);
Отчётность: более 30 разных отчётов, разделённых на 5 групп по административному признаку. Это отчёты Коммерческого блока, отчёты Блока строительства и подобные. Документы сложные, охватывают несколько метрик каждый. И запрос на разработку новых или доработку старых метрик не снижается;
Хранилище данных: СУБД — MS SQL и Clickhouse. Само хранилище представляет собой набор денормализованных таблиц, собранных из источников. Обновление данных выполняется в среднем 1 раз в сутки и 1 раз в неделю для внешних источников. Значимых трансформаций с данными не проводится. Большая часть вычислительных операций осуществляется на уровне отчёта с помощью DAX.
Итак, некоторый образ BI-системы у нас есть, но он не решает ряд обязательных задач:
Данные остаются несогласованными между разными системами-источниками и пользовательскими файлами, что приводит к расхождениям в отчётности;
У хранилища нет гибкости. Любое изменение структуры данных, особенно частое в данных управленческого учета и строительства, приводит к работам по переписыванию скриптов и пересозданию таблиц;
Нет инкрементального обновления. Каждый раз приходится забирать все данные, очищать таблицу и вносить их снова. Нет устойчивости и историчности;
Нет возможности ускорить процесс получения, обработки и отображения данных.
Вот именно из этих задач мы и будем формировать целевой образ BI-системы, которая сможет удовлетворять запросам бизнеса.
Постановка задачи
Проведя kick-off встречи с представителями различных подразделений, мы выделили некоторые общие требования к разрабатываемой BI-системе:
Отчёты отображают верные данные, им можно верить без дополнительных проверок;
Отчёты отображают актуальные данные;
Отчёты, объединённые одной группой, имеют общий стиль и структуру;
Есть возможность работать с данными самостоятельно, например, выполнять разведочный анализ, проводить проверку гипотез и выполнять Adhoc-запросы;
Изменение структуры данных не парализует 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.
