Почему «Лаборатория»? 🔎

Всё началось с DataDesc AI — системы автоматического описания объектов DWH и BI, которая помогает data-командам сократить объём ручной документации и привести метаданные в понятный бизнес-формат.

За последний год внутри BI-направления Lasmart многое изменилось. Мы развиваем несколько продуктовых направлений, запускаем MVP, тестируем гипотезы, проводим кастдевы и создаем новые инструменты для корпоративной аналитики.

🧪 По сути, мы работаем как продуктовая лаборатория: исследуем задачи рынка, проектируем решения и проверяем их на практике.

Нам стало тесно говорить только об одном инструменте. Поэтому канал будет посвящён не только DataDesc, а более широкой теме — созданию и развитию решений для управления корпоративными данными.

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

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

Почему Data Governance подходит далеко не всем компаниям 💼

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

В статье:
⚙️ разбираем реальные причины для внедрения,
⚙️ отделяем абстрактные «боли» от измеримых потерь,
⚙️ рассматриваем ключевые инструменты: data catalog, MDM, data quality, lineage,
⚙️ и показываем, как автоматизация помогает сократить трудозатраты.

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

🔗 Читать по ссылке

Внедрить Data Catalog — не самая сложная задача 📊

Сложнее сделать так, чтобы им реально пользовались

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

Почему так происходит?

Кому каталог действительно нужен, а кому — нет?

И какие ошибки почти гарантированно убивают пользу от внедрения?

В новой статье систематизируем основные ошибки внедрения и разбираем, как их избежать 🔽

🔗 Читать по ссылке

Боремся с деградацией: системный подход к оптимизации баз данных ⚙️

В крупных корпоративных системах деградация СУБД редко происходит внезапно. Сначала замедляются регламентные процедуры, затем растет нагрузка, появляются блокировки, проседает SLA — и команда начинает работать в режиме постоянного реагирования.

📆 17 марта в 11:00 (онлайн) приглашаем на бесплатный вебинар «Боремся с деградацией: системный подход к оптимизации баз данных», где подробно разберем работу и оптимизацию MSSQL.

👨‍💻 Спикер: Руслан Абдуллин — архитектор БД и интеграции, разработчик Lasmart. Практик аудитов и оптимизации MSSQL для Hoff Tech, «Аптечная сеть 36,6» и ГК «ЭркаФарм».

В программе вебинара:
— почему MSSQL деградирует в корпоративной среде и как отличить симптом от первопричины;
— системный подход к аудиту: инфраструктура → конфигурация → схема данных → SQL-уровень;
— типовые ошибки, которые повторяются из проекта в проект;
— разбор кейса автоматизированного аудита и рекомендации по оптимизации;
— как перейти от реактивного «тушения» к проактивному управлению производительностью.

Кому будет полезно:
DBA, DevOps, Data Engineer, Backend-разработчикам, а также руководителям ИТ / CTO / CDO, которые отвечают за стабильность и производительность баз данных.

🔗 Регистрация по ссылке

Как использовать AI для анализа метаданных в СУБД и BI: практика применения LLM и RAG 🤖

Во многих компаниях data catalog уже внедрен, но не работает как инструмент. Метаданные устаревают, доверие к данным падает, аналитики продолжают искать информацию вручную, а команда DWH остается перегруженной.

📆 9 апреля в 11:00 (МСК) приглашаем на бесплатный онлайн-вебинар «Как использовать AI для анализа метаданных в СУБД и BI: практика применения LLM и RAG», где разберем, как изменить этот подход с помощью AI.

👨‍💻 Спикер: Павел Хамрин — руководитель AI-направления Lasmart. Более 10 лет в аналитике и DWH.

В программе вебинара:
— почему data catalog не работает на практике: неактуальные метаданные, отсутствие доверия, перегрузка команды;
— как LLM автоматизирует описание таблиц, дашбордов и бизнес-логики без ручной поддержки;
— как работает RAG для поиска данных, контекста и анализа связей (data lineage);
— архитектура решения и roadmap внедрения без перестройки текущих систем.

Кому будет полезно:
Data-инженерам, CTO, CDO, Head of BI и DWH, Data-аналитикам и Data Scientist

🔗 Регистрация по ссылке

6 ошибок при проектировании DWH, которые ломают систему ещё до запуска 📉

Большинство проблем с хранилищем данных начинаются задолго до первой строки кода. На этапе проектирования закладываются решения, которые потом определяют скорость отчетов, сложность поддержки и доверие к данным.

Мы собрали 6 типовых ошибок, с которыми регулярно сталкиваемся на практике, и которые в итоге превращают DWH в дорогую и неуправляемую систему 🔽

1️⃣ Отсутствие бизнес-целей при проектировании
Когда команда начинает с вопроса «какие данные есть», а не «что нужно анализировать», хранилище быстро превращается в «свалку данных». Значительная часть информации не используется, но при этом замедляет систему и увеличивает стоимость инфраструктуры.

2️⃣ Выбор архитектуры без учета требований
Архитектура определяется по привычке или под влиянием трендов, а не исходя из требований проект. В результате система оказывается либо избыточно сложной, либо не справляется с нагрузкой и требованиями бизнеса.

3️⃣ Некорректная работа с колоночными СУБД
Перенос практик из строковых баз приводит к перекосу данных, неэффективным соединениям и просадке производительности в MPP-хранилищах.

4️⃣ Отсутствие модели разграничения доступа на этапе проектирования
Без заранее продуманной системы прав доступов возникает зависимость от конкретных сотрудников и повышаются риски утечек данных.

5️⃣ Отсутствие CI/CD и автоматизированного тестирования
Ручное управление изменениями приводит к накоплению ошибок, страху релизов и отсутствию контроля качества данных.

6️⃣ Отсутствие документации системы
Когда знания остаются в коде и в головах разработчиков, любые изменения требуют полного погружения, а онбординг новых сотрудников становится долгим и дорогим.

⚠️ Главное: первые две ошибки могут критически повлиять на проект ещё до начала разработки.

Остальные — постепенно делают систему неуправляемой и увеличивают стоимость изменений.

Почему проблемы производительности БД сложно выявить ⚙️

Когда база данных начинает «тормозить», кажется, что причина где-то на поверхности: не хватает ресурсов, плохие запросы или выросла нагрузка. На практике всё сложнее — деградация почти никогда не возникает в одном месте.

⚠️ Проблемы накапливаются слоями. Инфраструктура, настройки СУБД, модель данных и SQL — каждый уровень может вносить свой вклад. В итоге симптомы проявляются в одном месте, а причина находится совсем в другом.

Из-за этого команды часто «лечат» не то:
⚙️ добавляют ресурсы вместо оптимизации запросов,
⚙️ переписывают код вместо настройки конфигурации,
⚙️ или месяцами ищут проблему, которая лежит в устаревшей статистике.

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

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

Рабочий подход здесь только один — системный.

Смотреть на базу не как на «чёрный ящик», а как на набор уровней:
🔹 инфраструктура и ресурсы
🔹 конфигурация СУБД
🔹 модель данных и индексы
🔹 SQL-запросы

Только такая декомпозиция позволяет понять, где именно возникает узкое место, и не тратить время на ложные гипотезы.

И именно поэтому ручной аудит всё чаще заменяется автоматизированным мониторингом:
когда система постоянно отслеживает состояние базы, находит отклонения и показывает не симптомы, а причины.