Создание Data Lakehouse системы: кейс строительного холдинга

31 июля, 2025

Проекты

Один из ведущих строительных холдингов Российской Федерации обратился к нам с запросом на разработку перспективной дата-платформы, предназначенной для сбора, анализа и консолидации данных из различных учетных систем и файловых источников.

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

На старте проекта у компании отсутствовала аналитическая инфраструктура. Имелся довольно внушительный набор учетных систем без централизованного хранилища данных. Объём проекта до конца не был понятен, и всё осложнялось полностью закрытым контуром заказчика с доступом к виртуальным машинам только через терминальные решения.

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

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

· Apache Kafka

· Dagster

· S3 + Iceberg

· Trino

· ClickHouse

· DBT.

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

Потребителями данных являются бизнес-системы, отчеты Power BI, веб-приложения и MDX-кубы, аналитики и специалисты по работе с данными.

Проект реализован с нуля (greenfield-разработка) по методологии управления Scrum. В команду разработки вошли 11 специалистов по проектированию и разработке хранилищ данных (DWH-инженеры, системные аналитики и DevOps-инженеры).

Рассмотрим архитектурную схему:

Слева на схеме представлены источники данных: несколько конфигураций 1С (15 баз - 1С ЗУП, 3 базы - 1С бухгалтерия и 1 база - 1С комплексная автоматизация). Для интеграции огромного количества Excel-данных, мы решили использовать, разработанный нами сервис «Формы ввода». Он автоматизирует процесс сбора и загрузки как данных ручного ввода, так и данных из Excel файлов.

Для интеграции всех баз 1С используется apache Kafka, обеспечивая удобный, легко масштабируемый процесс.

Как это происходит?

Разрабатывается план обмена данными на 1С, раскатывается и тестируется. В созданном расширении реализуется подписка на события создания и изменения объектов 1С с записью в очередь на отправку. Отправка реализует http запросы в Kafka Rest, где они валидируются при помощи kafka schema registry и записываются в соответствующие топики, откуда данные перекладываются в хранилище.

Удобство подхода:

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

2. обеспечивает хорошую производительность,

3. закрепляет ответственность за отправку данных и соблюдение дата-контракта за источником.

Слои данных и само хранилище построено на базе Trino с использованием открытых форматов хранения – Iceberg tables и объектного хранилища на базе Minio S3.

Стандартный набор слоев:

• STAGE - для загрузки сырых данных в режиме append-only

• ODS - для очистки, дедубликации и типизации

• DDS - детальный слой хранения данных

• DM - для формирования витрин данных

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

В данной архитектуре компонент eMondrian предназначен для бизнес-пользователей, привыкших работать в Microsoft Excel и создавать сводные таблицы на основе многомерных кубов OLAP. Основная функция данного компонента заключается в преобразовании MDX-запросов из Excel в SQL-запросы, которые затем направляются к витринам данных ClickHouse. Этот процесс осуществляется в режиме реального времени, обеспечивая пользователям возможность оперативного доступа к аналитической информации.

Все сервисы развернуты в кластере Kubernetes, для процесса ci/cd мы используем Argo CD, Gitlab и Harbor. Для мониторинга – Loki, Prometheus, Grafana.

Важнейшим компонентом представленного подхода является DBT (Data Build Tool), на схеме видно, что все переходы от компонента к компоненту осуществляются с его помощью.

Elementary – надстройка над DBT, позволяет собирать и визуализировать статистику по запускам DBT проекта, выполнению тестов и времени материализации моделей.

Kafka – зачем нужна?

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

• Обеспечивает получение и хранение данных от большого количества баз 1С;

• Позволяет оперативно масштабировать систему, интегрируя новые базы 1С с идентичной конфигурацией;

• Гарантирует корректную обработку и соответствие принятых данных зарегистрированной схеме данных;

• Поддерживает формат Avro, что позволяет эффективно обрабатывать и сохранять большие объемы данных;

• Обеспечивает простую и удобную интеграцию с Trino;

• Trino обладает возможностью чтения Avro-топиков, при этом происходит развертывание и типизация всей вложенной структуры данных, исключая необходимость преобразования в формат JSON;

• Топики Kafka могут служить источником (source) данных для DBT.

Dagster: почему не Airflow?

Было принято решение использовать Dagster из-за его бесшовной интеграции с DBT. Немного другой подход нежели в Airflow, управление зависимостями на уровне ассетов. Удобный функциональный интерфейс, в целом захотелось чего-то нового, так как во всех проектах использовали Airflow. Dagster стал глотком свежего воздуха для дата-инженеров.

Trino

Единый SQL-движок, обеспечивающий передачу и трансформацию данных между узлами хранилища. Имеет множество интеграций как с реляционными, так и с нереляционными источниками, а также прекрасно работает с DBT (DBT имеет адаптер к Trino). В версии dbt-core 1.9 появилась поддержка стратегии microbatch, что очень помогает экономить ресурсы при работе с большими таблицами.

ClickHouse

Колоночная база, предназначенная для быстрых селектов и агрегаций, отлично подходит для BI-систем, использующих прямые запросы к БД. Также подключается к Trino, как каталог, и в нашем случае является источником для eMondrian.

DBT (Data build tool)

В основе DBT подход Create Table As Select (CTAS). Все моделирование данных и процесс преобразования реализуются через код. Использование инкрементальных стратегий, переиспользование кода, версионность через GIT, автоматизация документации, тесты и дата-контракты – это всё то, за что мы любим и ценим DBT.

Из чего состоит DBT-проект?

· Модели dbt (sql скрипты и yml файлы) – описывающие сущности

· Sources – описание источников (source.yml)

· Макросы – sql скрипты с шаблонизацией jinja

· Seeds – csv файлы, на которые можно ссылаться в моделях

· Tests – пользовательские тесты

· dbt_project.yml – описывает полностью весь проект

· profiles.yml – описывает подключение к базе

Что такое модели DBT?

Это обычные SQL-запросы в виде CTE. Ниже можно увидеть достаточно обширную модель DM-слоя и Yml-файл (описание этой модели). Оба этих файла образуют модель DBT. В Yml-файле мы полностью описываем нашу модель и передаём необходимые инструкции для её исполнения: из каких она состоит колонок, описание этих колонок, типы данных, вид материализации и прочие атрибуты.

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

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

Сборка проекта dbt происходит в три фазы:

Как работают макросы в DBT?

Макросы в DBT — это мощный инструмент повторного использования SQL-логики. Он позволяет избежать дублирования, упрощает поддержку кода и делает его более гибким.

Возьмем, к примеру, макрос columns_as_yaml, который мы часто используем в наших проектах.

На скриншоте представлен Jinja-код, и yaml-описание макроса, которое будет использоваться в документации.

Как вызывается макрос: в фигурных скобках мы пишем наименование макроса, в данном случаем макрос использует yaml-файл модели, парсит его, определяет, какие используются колонки в файле, и какие типы они имеют. Данный макрос типизирует колонки на выходе в финальном селекте.

Макросы могут вызывать другие макросы, образовывать каскады, формируя фреймворки для работы с моделями.

На сайте DBT существует множество packages (наборы макросов), которые можно использовать в своей работе, но можно написать и свои.

Как пример, наш package, который мы используем для построения ODS слоя.

Возможности:

· Гибкая настройка модели в зависимости от методики моделирования DWH

· Приведение вложенных структур к плоской таблице

· Типизация

· Исключение дублей

· Генерация hash

· Реализация SCD2

· Отслеживание удалённых записей на источнике

Подробный разбор примеров в видеоролике: https://vk.com/video-147838266_456239849

Моделирование DDS слоя по методологии Data Vault

Многие знают, что такое Data Vault и его преимущества. Однако, есть и недостатки, один из них – довольно сложная концептуальная реализация. Для успешного внедрения и работы с ним необходимо использовать внешние инструменты и фреймворки, и один из них package automate_dv и DBT.

Unit-tests

Используя большое количество макросов DBT, стоит задуматься о том, как их тестировать, потому что они содержат в себе огромное количество логики. При изменении и доработках нужно следить за тем, что ожидаемый результат не меняется. В нашем подходе тесты макросов реализованы в отдельном изолированном проекте. Среда создаётся через Docker, используется тестовая база данных, а также набор фикстур для валидации результатов.

Преимущества отдельной среды:

• Изоляция: тесты не зависят от прода

• Воспроизводимость: Docker дает одинаковую среду для тестов

• Повторное использование: макрос один, кейсов много

• Контроль: фикстуры (input/output) прозрачно сравниваются

Пример тестирования макроса: