🛢 Big data на самом деле не существует!

Решил вспомнить статью, которая вышла еще в далеком 2023-м, но которая актуальна и сейчас.

Главный посыл статьи:

Big data более не существует, а может никогда и не существовало. Большинство компаний имеют в своем хранилище менее 1TB данных и думают, что это много.

Автор, один из создателей Google BigQuery, утверждает: эпоха «больших данных» — это уже прошлое. Проблема давно не в объёмах данных, а в их эффективном использовании. Сегодня инфраструктура и технологии выросли настолько, что масштаб обработки уже не является главным препятствием.

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

❗А самое главное (с чем я на все 100 согласен) — большинство компаний попросту не имеет большого объема данных.

Крупные big tech компании вроде банков или маркетплейсов действительно ворочают десятками петабайт, но ведь эти компании составляют менее 1% от общего числа компаний, которые используют DWH. Чаще всего всего в DWH действительно менее 1 терабайта, с чем справится стандартный PostgreSQL без каких-либо проблем 💻

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

Еще часто компания страдает от того, что хранит устаревшие и ненужные данные, которые более никогда не будет использовать. А еще тащит эти детальные или устаревшие данные в BI, думая, что пользователи дашбордов будут их использовать.

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

Решение же лежит на поверхности — удалить ненужные данные!

🔹 В общем, с текущими технологиями можем обрабатывать действительно много данных, но чаще всего этого не требуется.

Лично мне кажется, что акцент нужно делать не на том, сколько данных и за какое время вы можете обработать. А на качестве этих данных. Гораздо важнее быть уверенным в своих данных, а не иметь большие объемы мусора.

Как Data Mesh помогает повысить производительность аналитики ❗

Data Mesh меняет сам подход к работе с данными: вместо одной централизованной команды — множество доменов, каждый из которых отвечает за свою часть данных и создает полноценные дата-продукты.

В видео — просто о том, как работает децентрализация, зачем нужны доменные команды и почему единая платформа — ключ к эффективности.

🌊 Data lineage в 2025: почему это must-have или как не превратить свой Data lake в Data swamp.

Если пару лет назад про data lineage говорили как про «приятный бонус» к стеку, то сейчас без него сложно представить нормальную работу data-инженеров.

ℹ️ Data lineage — это прослеживаемость данных: откуда они пришли, через какие трансформации прошли и в какие витрины/отчёты попали. Другими словами документация, которая показывает зависимости между таблицами.

И вот почему в 2025 он стал необходимостью:

🔹 Рост количества источников и таблиц
В 2020–2021 мы могли «на глаз» держать в голове, что тянется из CRM в витрины продаж. Сегодня же Kafka + десятки топиков, десятки джоб в Airflow, сотни моделей в dbt и десятки витрин. Без документации все превратится в болото.

🔹 Обслуживание
Без понимания что от чего зависит вы будете тратить много времени на impact-анализ. Как тратил я на заре своей карьеры, копаясь в десятках SQL-прототипах и вручную выписывая зависимости.

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

Мы свои трудозатраты снизили примерно на 20% с использованием data lineage.

Работа с данными все больше походит на разработку ПО: тесты, зависимости, Git, CI/CD. Это конечно все замечательно.
Те, кто продолжают жить по старинке попросту тратят гораздо больше сил и времени на стандартные процессы.

А вы у себя уже внедрили lineage?

Частые проблемы 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