Дима пишет | Дмитрий Смотров: заметки с тегом DataWarehouse

Пробился на хабр

Tue, 02 Dec 2025 19:23:53 +0300

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

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

Почитать можно тут — https://habr.com/ru/companies/astralinux/articles/972328/ . Там как раз есть пара спорных моментов, на мой взгляд, с удовольствием подхвачу накидывание на вентилятор. Так что задавайте ваши вопросы :)

Я тут проект под ключ реализовал

Mon, 02 Jun 2025 23:58:08 +0300

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

С декабря месяца я взялся поднимать функциональность аналитики и отчетности в АСМ(это продукт, разработкой которого я занимаюсь). План был прост:
1) Собрать команду
2) Разобраться в устройстве корпоративных хранилищ данных, ведь аналитика и отчетность строится на каких-то данных, а данные еще нужно сложить и подготовить для отображения(привет data engineering).
3) Разобраться в моделирование бизнес-процессов для подготовки аналитических данных.
4) Сделать хранилище и смоделировать один бизнес процесс для обкатки выбранных подходов и инструментов.
5) Сделать отображение данных в графиках и таблицах.

И тут в целом можно было вспомнить, что я так-то бекенд разработчик, чем я тут вообще занимаюсь. Но вспоминать было некогда — работы вагон и еще три состава:
— Вместо одного бизнес процесса моделировать пришлось 5. Два месяца я засыпал и просыпался я в обнимку с томиком Кимбалла.
— Параллельно происходил ресерч и обоснование выбранных технологий для построения ETL-процессов и отображения данных, ресурсов на разработку собственных решений за отведенное время нет.
— Команда собрана. Нас пятеро друзей Оушена.
— Мы соответствуем РБПО, поэтому выбранные инструменты затянуты к себе и взяты на поддержку.
— Были подняты стенды для дев и целевой среды, так на свет родились deb-пакеты для Airflow и Superset, несуществовавшие в природе до этого. CI часть этого всего — это почти еще один продукт :)
— Разработаны ETL-процессы. Полностью. С нуля.
— Разработаны предустановленные отображения для данных. 6 страниц с кучей данных и переходами между друг другом, связанные общими фильтрами.
— Мы разворачиваемся у клиента с минимальными махинациями в админках используемых инструментов — так в dag-скриптах появились env’ы с подключением к БД и автоматический импорт дашбордов.
— Документация. Мы еще даже рассказываем, как при желании сделать собственные страницы с отчетами и как у нас там данные лежат.

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

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

Сделано столько работы, а это будто лишь начало пути.

SqlAlchemy в ETL процессах

Wed, 28 May 2025 21:30:10 +0300

На прошлой неделе затягивал алхимию в dag-скрипты для airflow. Так как AF не хостится на нашей стороне, а доставляется до заказчика, хотелось обойтись без использования внутренних соединений с БД(я про connections внутри AF) и написания SQL-запросов в plain-тексте дабы сохранить единообразие кодовой базы с обычными нашими сервисами по максимуму.

По мимо того, что вместо второй версии пришлось использовать 1.4, а это потянуло за собой использование более старых версий mypy и затягивания плагинов для алхимии, ну и переписывание моделей на старый лад, столкнулся с интересным приколом: alembic начал ругаться на то, что у меня для одной метадаты в нескольких моделях одинаковые названия таблиц.

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

Можно было решить эту проблему в лоб и переместить папку с миграциями поближе к коду, но это так ужасно выглядело, что нужно было бы еще рефачить структуру файлов в проекте, в общем запара.

В итоге, разделив базовый класс для моделей(и соответственно разделив инстанс метадаты для этих классов), я добавил больше логического разделения и починил проблему с дублированием метадаты.

Дешевое и приятное решение, почаще бы таких :)