Частые проблемы data mesh ⛔️

Вы, конечно, можете нарезать компанию на домены, красиво всё расписать по ролям…

А потом поймёте, что аналитиков не хватает, data-инженеров ещё меньше, а половина сотрудников не поняла, что вообще происходит.

Дальше будет классика жанра:
— сопротивление новым процессам
— «велосипеды» в каждом домене
— зоопарк технологий
— и повышенный порог входа, когда аналитик внезапно становится всем — от инженера до тестировщика

В общем, Data Mesh — штука хорошая, но только если вы готовы к человеческой стороне вопроса.

Как раз о ней — в новом видео 🎥

💻 Чем dbt лучше хранимых процедур?

Тут недавно вышла статья в блоге dbt – сравнение хранимых процедур и dbt. И мне она совершенно не понравилась. Тезисы выстроены для мало разбирающихся менеджеров:
- вы не внедрите AI в хранимки (а зачем?)
- кандидаты будут выбирать других работодателей ведь хранимки – это прошлый век
- хранимки – legacy (но не объясняется почему)

Хранимые процедуры – неотъемлемая часть любого среднестатистического хранилища данных. Раньше нельзя было представить себе DWH без «хранимок». Но они действительно постепенно уходят в прошлое. Я постараюсь получше и без маркетинговых уловок объяснить, почему dbt лучше «хранимок».

🔹 В dbt все DML операции спрятаны
В хранимой процедуре потребуется вручную прописывать логику INSERT, UPDATE, DELETE. В то время как в dbt из коробки доступны разные стратегии обновления, которые эту «обвязку» сделают за вас.

Да, в хранимых процедурах вы больше контролируете логику, зато с dbt вы гораздо меньше времени тратите на рутину. Ведь логика обновления данных у 90% объектов одинаковая – добавь новые данные (append), проставь новую версию.

Если вам требуется своя кастомная логика обновления – в dbt вы можете добавить свою стратегию обновления, написав ее в jinja.
Это кстати то, что мы сейчас делаем в нашем новом продукте dbtPro – добавляем множество своих стратегий обновления. А то в dbt их слишком уж мало.

🔹 Тяжело поддерживать
В статье об этом тоже говорится, единственный хороший тезис. Хранимые процедуры ой как сложно поддерживать. Особенно, если одна зависит от другой, а другая зависит от третьей. Чаще всего никакой документации к ним нет; сотрудники, которые их делали давно уволились; не дай бог, в процедуре обновляется сразу несколько таблиц. И вот вы сидите и тратите уйму времени, чтобы внести мизерное изменение в этот ворох.

Dbt гораздо прозрачнее в этом плане. Есть встроенный функционал документации, можно фиксировать зависимости, один файл dbt – одна таблица. А главное – только SELECT-запросы внутри файлов, а не ворох непонятных DML-операций.

🔹 Кросс-функциональность
Удивительно, что dbt в своей статье забыли упомянуть эту киллер-фичу – dbt умеет работать со множеством СУБД. И при переезде на новую, вам не потребуется переписывать ворох DML-операций на новый синтаксис.

Да, сами SQL-запросы возможно переписать потребуется, но их «обвязка» в виде вставок и обновлений данных – это dbt берет на себя.

🔹 Нет Git
Да, хранимки конечно можно сохранить в текстовый файл и залить в Git. Но в какой-то момент вы обновите в DWH хранимку и забудете скопировать исправления в файл и закомитить в Git. Любые дополнительные действия без проверки исполнения, в итоге забываются. И вы 100% получите рассинхрон Git с актуальной версией хранимки.

В dbt вся SQL логика изначально хранится в файле. И грех не комитить этот файл в Git.

🔹 Хранимые процедуры - сложно
Ну и конечно, главный минус хранимых процедуры – они сложны в реализации. Я не сомневаюсь, что вы, читатель, несомненно крутой SQL-специалист. Но помимо вас есть еще огромное количество аналитиков, 90% которых не сможет написать хранимую процедуру.

А вот какой-нибудь SELECT аналитик уже написать сможет.

Мое скромное мнение – хранимые процедуры проигрывают битву за DWH и постепенно будут заменены на dbt и подобные аналоги.

Развитие подходов к разработке 👨‍💻

Раньше хранилища строили по классике – долго и с издержками: высокий TTM, узкое горлышко, перегруз центральной дата-команды.

Потом появились новые технологии – они упростили жизнь инженеров и ускорили процессы.

Но Data Mesh меняет не инструменты, а сам подход к разработке. Что будет, если соединить его с технологиями?

Рассказываю в новом видео ▶️

😀 Будущее DWH: куда движется индустрия?

Хочу рассмотреть несколько трендов в сфере DWH, которые сейчас явно прослеживаются.

🔹 Lakehouse
Если мы говорим, про «умопомрачительные» объемы данных и big tech организации, то там конечно сейчас все чаще «выстреливает» гибридная lakehouse архитектура и всякие Delta Lake, Iceberg. Как и любая технология, DWH стремится отойти от монолитной не масштабируемой архитектуры к более эластичным вариантам. Да и к тому же аналитические движки становятся все быстрее: DuckDB заявляют в разы лучше любой MPP базы.

Конечно, 90% компаний до сих пор сидят на MSSQL или PostgreSQL. Потому что у них данных «с гулькин нос».

🔹 ELT
Раньше мы использовали ETL-инструменты, которые вытаскивали данные из источников, преобразовывали их «на лету», а потом вставляли в хранилище.
Сейчас мы повсеместно перешли от этого подхода к подходу – сначала вставь данные, потом трансформируй. А проприетарные ETL-инструменты, которые еще имели невероятно большой ценник, ушли в прошлое. Мы видим явную победу скриптовых ELT-фреймворков.

Главная цель – упрощение работы и прозрачность полученных результатов. Python ELT фреймворки или dbt гораздо легче поддерживаются и гораздо прозрачнее, нежели SSIS или SAS DI с их красивыми стрелочками и блоками.

🔹 Разработка DWH, как приложение
Вот это очень заметный тренд последних 5 лет.
Мне самому всегда было удивительно, почему в разработке приложений и Систем выстроены серьезные процессы: версионирование кода, unit-тесты, релизы, ci/cd – а в DWH ничего подобного нет? Банально корректность полученных метрик в DWH не проверяем.

Сейчас же все потихоньку меняется. К разработке отчетных витрин начинают относится как к разработке полноценного приложения. С приходом скриптовых ELT пришло и версионирование в Git. Появляются фреймворки для проверки качества данных и проведения unit-тестов над таблицами. Data contract-ы для выстраивания взаимодействия различных подразделений, data catalog для документации, разные версии отчетных витрин и релизы.

Раньше DWH-разработчик не считался полноценным разработчиком. Теперь же это такой же специалист и процессы у него «программистские».

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

🔗 Бесплатная регистрация

🎁 Подарки для участников вебинара!

Уже завтра в 11:00 (МСК) пройдёт вебинар «Как за 15 минут сделать бизнес-описание всей базы данных и BI-отчётности с помощью ИИ?»

Каждому зрителю мы дарим таблицу «Сравнение LLM в части формирования документации» — наглядное сравнение моделей по точности бизнес-описаний таблиц, отчётов и процедур.

⌛️ Регистрация закрывается сегодня вечером!
🔗 Успейте забронировать место

⚡️ Уже через час встречаемся на бесплатном вебинаре «Как за 15 минут сделать бизнес-описание всей базы данных и BI-отчётности с помощью ИИ?» ⚡️

Присоединяйтесь!

🔗 Ссылка для входа — https://start.bizon365.ru/room/141460/biznes_opisanie

🚨 Вебинар начнется уже через 15 минут 🚨

Мы на низком старте!

➡️ Подключайтесь по ссылке — https://start.bizon365.ru/room/141460/biznes_opisanie

‼️ Вебинар начался ‼️

📍 Ждём вас — https://start.bizon365.ru/room/141460/biznes_opisanie

Коллеги, вебинар успешно прошел — всем спасибо за участие!

Если у вас остались вопросы — делитесь в комментариях ниже!

⌨️ Пропустили эфир? Мы можем прислать вам запись и презентацию!

Для этого напишите на нашу почту biwebinar@lasmart.ru слово «Вебинар» ✉️