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

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

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

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

Было принято решение использовать архитектуру Data Lakehouse на основе открытого исходного кода.

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

·        Apache Kafka

·        Dagster

·        S3 + Iceber

·        Trino

·        ClickHouse

·        DBT.

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

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

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

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

Слева на схеме представлены источники данных: несколько конфигураций 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С;

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

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

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

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

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

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

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

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

Trino

Единый SQL-движок, обеспечивающий передачу и трансформацию данных между узлами хранилища. Имеет множество интеграций, как с реляционными, так и с не реляционными источниками и прекрасно работает с DBT (DBT имеет адаптер к Trino). В версии 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-file (описание этой модели). Оба этих файла образуют модель DBT. В Yml-file мы полностью описываем нашу модель и передаём необходимые инструкции для её исполнения, из каких она состоит колонок, описание этих колонок, типы данных, вид материализации и прочие атрибуты. 

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

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

Сборка проекта:

Как работаю макросы в 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) прозрачно сравниваются

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

О чем нужно помнить:

·        Регламенты, документация и статьи для разработчиков “how to do”.

·        Метрики в grafana, алерты в ТГ и JIRA тикеты.

·        Iceberg таблицы требуют обслуживания и настройки.

·        Code-style, линтеры в CI, форматирование скомпилированного кода.

·        Процесс code-review.

·        DryRun запуски проекта DBT в CI.

·        Unit тесты макросов в CI.