К нам обратился один из крупнейших строительных холдингов России (ГК компаний из 10+ юридических лиц) с потребностью в сборе всех данных с филиалом, анализе и визуализации на дашбордах.
При входе на проект аналитической инфраструктуры у компании почти не было, только множество учетных систем без централизованного хранилища данных. Объем проекта был непонятен, «аппетит приходит во время еды». Важная особенность проекта – полностью закрытый контур с доступом через терминальные решения.
Было решение выбрать архитектуру Data Lakehouse на open source стеке, основой которого стали - kafka, dagster, s3+iceberg, trino, clickhouse и DBT. В результате получилось более 1000 моделей DBT, 1 тб сжатых данных, и объем продолжает расти.
Из потребителей данных – бизнес системы, Power BI отчеты, аналитики и дата-инженеры, веб-приложения, MDX-кубы.
Методология ведения проекта Scrum, команда DWH-инженеров 11 человек и greenfield-разработка.
Рассмотрим архитектурную схему:
Слева мы видим источники данных: множество конфигураций 1С (ЗУП, бухгалтерия, комплексная автоматизация). Огромное количество Excel-данных, здесь мы решили использовать, разработанный нами сервис Формы ввода. Он автоматизирует процесс сбора данных Excel.
Для интеграции используется Kafka, как раз для удобной масштабируемой интеграции всех 1С.
Как это происходит?
Пишется план обмена данными с 1С, раскатывается, тестируется. 1С отправляет HTTP запросы в Kafka Rest, мы их принимаем, далее перекладываем трансформируя по слоям хранилища.
Этот подход очень удобный, позволяет быстро масштабироваться под разные задачи.
Слои данных и само хранилище построено на базе Trino с использование открытых форматов хранения – Iceberg tables и объектного хранилища на базе Minio S3. Стандартный набор слоев
STAGE для сырых данных в режиме append-only
ODS с очисткой и дедубликацией
DDS с детализированными моделями
DM с готовыми витринами
Слой витрин выгружается в ClickHouse, который является единой точкой доступа к данным для бизнес-пользователей и различных бизнес-приложений.
Emondrian – нужен для бизнес-пользователей, который привыкли работать в Excel, крутить сводные таблички на OLAP-кубах – могли делать это в нашей архитектуре. Задача сервиса переводить MDX-запросы от Excel в SQL к витринам ClickHouse в режим реального времени.
Все сервисы развернуты в кластере Kubernetes, для deploy мы используем Argo CD, Gitlab и Harbor. Для мониторинга – Locker, Prometheus, Grafana.
Как мы уже упомянули, очень плотно работаем с DBT, на схеме видно, что все переходы от компонента к компоненту осуществляются с его помощью. Основным каталогом данных является dbt.docs.
Elementary – надстройка над DBT, позволяет мониторить результаты выполнения тестов и отклонения, вести статистику по тестам, видеть проливки различных сущностей и моделей.
Kafka – зачем нужна?
Она является основной шиной для интеграции различных 1С-платформ. В том числе ее можно использовать для разных систем и источников, что позволяет разграничить ответственность между хранилищем и источником.
Источник в этом случаем сам отправляет сообщения и отвечает за ритмичность и качество их загрузки. В своем подходе мы используем kafka Schema Registry, которая позволяет нам обеспечить Data Contract. Каждое сообщение при входе валидируется на соответствие схемы. Все топики kafka мы видим через Trino, как обычную таблицу и можем работать с ней, описывая модель непосредственно в DBT.
Dagster. Почему не Airflow?
Было принято использовать Dagster из-за его бесшовной интеграции с DBT, делать это очень удобно и быстро. Управление зависимостями на уровне ассетов, немного другой подход нежели в Airflow. Удобный функциональный интерфейс, в целом захотелось чего-то нового, так как во всех проектах использовали Airflow и Dagster стал глотком свежего воздуха для дата-инженеров.
Trino
Единый SQL-движок, обеспечивающий передачу и трансформацию данных между узлами хранилища. Имеет множество интеграция, как с реляционными, так и с нереляционными источниками и прекрасно работает с DBT, так как DBT имеет адаптер к Trino. В последней версии есть поддержка микробатчинга, что на самом деле очень нам помогает.
ClickHouse
Колоночная база, предназначенная для быстрых селектов и агрегация, отлично подходит для BI-систем. Также подключается к Trino, как каталог, и в нашем случае является источником для MDX-запросов, Olap-кубов.
DBT (Double 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 при запуске будет проверять и типы, и наличие всех колонок, соблюдение схемы. Мы описываем инкрементальную стратегию, которая будет использоваться, aliases, бизнес-ключи и другие параметры.
DBT генерирует HTML-документ, его можно развернуть у себя и предоставить пользователям для быстрого поиска необходимой информации по вашей базе. Дополнительно в ней можно видеть от чего зависят модели, какие используют макросы, видеть код.
DBT Lineage - это то, что позволяет нам, разработчикам и аналитикам, быстро вникать в суть происходящего в хранилищ. Понимать от чего зависят данные, как строится витрина 9из каких источников. Можно нажать на необходимую модель и посмотреть детальную реализацию.
Сборка проекта:
Как работаю макросы в DBT?
Макросы в DBT — это мощный инструмент повторного использования SQL-логики, позволяя избежать дублирования, упрощают поддержку кода и делают его более гибким.
Возьмем, к примеру, макрос columns.as.yaml, который мы используем в наших проектах. Это инструмент повторного использования SQL-логики, когда надоедает писать один и тот же код, стоит использовать макросы.
Можно посмотреть слева Jinja-код слева, а справа yaml-описание макроса для документации.
Как вызывается макрос – в фигурных скобочках мы пишем наименование макроса, в данном случаем макрос использует yaml-файл, парсит его, смотрит, какие есть колонки в файле, и какие типы они имеют. Этот макрос типизирует колонки на выходе в финальном селекте.
Макросы могут вызывать другие макросы, состоять из большого количества, образовывать каскад, формируя фреймворки для работы с моделями и подходами, позволяя быстро сконфигурировать, например, ODS-слой.
На сайте DBT существует множество packages (наборы макросов), можно использовать их в работе, можно написать свои.
Возможности:
Гибкая настройка модели в зависимости от методики моделирования DWH
Приведение вложенных структур к плоской таблице
Типизация
Исключение дублей
Генерация hash
Реализация SCD2
Отслеживание удалённых записей на источнике
Подробнее разбор примеров в видеоролике
Моделирование DDS слоя по методологии Data Vault
Многие знаю, что такое Data Vault и его преимущества. Однако, есть и недостатки, один из них – довольно сложная концептуальная реализация. Для успешного внедрения и работы с ним необходимо использовать внешние инструменты, automate.db и DBT помогают реализовать это.
Unit-tests
Используя большое количество макросов DBT, стоит задуматься о том, чтобы их тестировать, потому что они содержать в себе огромное количество логики. При изменении и доработках нужно следить за тем, что ожидаемый результат не меняется. В своем подходе при разработке unit-тестов мы используем отдельные среды. В CD-пайплайне мы запускаем тесты, которые поднимают изолированную среду (Docker) – со своим мини-Trino, со своим DBT-проектом, подтягивая макросы из основного репозитория. Тем самым мы гарантируем воспроизводимость и изолированность среды.
Пример тестирования макроса:
Рекомендации
Регламенты, документация и “how to do”
Метрики в grafana, Алерты в ТГ и JIRA тикеты
Iceberg таблицы требуют обслуживания и настройки
Код-стайл, линтеры в CI, форматирование скомпилированного кода
Процесс код-ревью
DryRun запуски проекта dbt в CI
Unit тесты макросов в CI