Комментарии 14
В чем вы рисовали эти классные картинки, сопровождающие статью?
Привет, спасибо, мы тоже любим стилистику изображений в статьях
Нам для блога все изображения рисует иллюстратор, если интересно, можем у него поинтересоваться
Для собственного использования, могу порекомендовать excalidraw очень нравятся, возможность получить быстро схему или архитектуру, которая опрятно выглядит
В России не используете Kestra? Вроде как продукт вырос в Леруа.
Мне не известно про использование, наш тех стек можно посмотреть тут https://lemanatech.ru/stack/table/
А вы у себя используете Kestra или только присматриваетесь? Как он вам?
Спасибо за статью! Приятно почитать успешную историю.
Среди моего окружения встречала такие сценарии
для дата-меш нам бы надобыло нанять дата-инженеров в доменные команды - ДОРОГО.
есть дата-инженер в одной доменной команде(вырос из бизнес-юзера),но епт, он там такого наворотил. *Это самый частый сценарий
Обычные софтвэр-инженеры играют роль дата-инженеров(чтоб сэкономить деньги) и упускают что данные это продукт и качество данных соответствующее(низкое)
Очень нужны enterprise архитекторы и enterprise data architects- весь этот зоопарк дирижировать.
Имхо, будущее за дата-меш, надо только научиться делать его правильно
Спасибо за ценные наблюдения. Мы тоже сталкиваемся с похожими ситуациями.
Поиск дата инженеров в доменные команды действительно требует инвестиций, но в долгосрочной перспективе это окупается за счет автономии и скорости создания новых продуктов.
Случаи, когда специалисты из бизнеса берутся за технические задачи, подтверждают важность обучения и наличия четких стандартов по разработке продуктов, так и подходов по описанию данных и понимания критериев качества данных. Без этого даже опытные специалисты в децентрализованной среде могут столкнуться с рисками, о которых вы упомянули. Мы скорее поощряем инициативы, но стараемся быть во главе, например недавно рассказывали про BI, как проводим обучения внутри.
Что касается случаев, когда backend/frontend разработчики примеряют на себя роль инженеров данных - здесь полезно формировать культуру "данные как продукт". И что помогает нам, мы упростили и автоматизировали самые популярные процессы в платформе данных, и закрыли по возможности все автотестами.
Кстати, обратил внимание, что у всех data mesh свой, и интерпретируют и имплементируют его компании по разному :)
Спасибо за статью! Одна из проблем Data Mesh в том, что отдельные процессы работы с данными становятся сильно завязанными на одного конкретного дата инженера домена и в случае его ухода его обычно некем заменить. Были ли у вас такие проблемы и как вы их решали?
Думаю, с этим сталкиваются многие. Часто приводят аналогию: "Централизация проще: ушел один специалист - и задачи распределены между остальными".
У нас в компании поощряется подход к T-shaped специалистам (например, аналитики данных/BI-специалисты могут частично выполнять задачи инженеров данных), это с одной стороны. С другой, мы используем коммунальную платформу данных, что позволяет при уходе инженера из одного домена оперативно подключить специалиста из смежного домена (ближайшего по бизнес-логике). Технические процессы унифицированы, остается освоить предметную область.
Для случаев, когда команды создают собственную дата-инфраструктуру, спасает регулярная оценка. Относительно недавно запустили процесс "maturity matrix" по всем продуктам, что позволяет отслеживать наличие документации, качество метаданных, вопросы связанные с ИБ, и другие аспекты. Это позволяет в моменте доработать продукт, чтобы снизить тех.долг, а в перспективе снижает зависимость от уникальной экспертизы и избавляет от необходимости перестраивать решения с нуля.
Петр, приветствую!
Спасибо за интересную статью.
Зачастую Data Mesh подразумевает использование каталога данных, вы что-то используете? Да, насчет доменов данных: мне надо посчитать, сколько оплат пришло по товарам, которые собрал сотрудник. И какой тут домен? Под меня отдельный собирать, или дать доступ к 3м доменам?
Георгий
Георгий, добрый день
Что касается каталога данных? мы прошли несколько этапов развития. Сначала использовали wiki/confluence, затем внедряли коммерческое решение collibra, а последние два года развиваем собственное внутреннее решение. Главное не сам инструмент, а процессы поддержания актуальности контента и доверия к каталогу данных. Самописное решение позволяет гибко адаптироваться под внутренние процессы, хотя старт с ним медленнее, чем с готовыми платформами.
В компании деление на домены («Товары», «Стоки» и т.д.) организовано как структурное, поэтому для нас и создание нового домена это добавление новых команд. И получается так, что у нас каждая команда отвечает за создание и управление данными в своем домене и так же предоставление данных как продукта в DWH. Например для метрики «сколько оплат пришло по товарам, которые собрал сотрудник» упрощенно процесс выглядит так:
-> Новая метрика заносится в каталог данных (<- на этом этапе и становится понятно какой домен ее заказ, так как заносит ее заказчик)
-> Владелец валидирует источники данных
-> Валидируется формула расчета
-> Архитектор или Дата Стюарт согласовывают метрику и проверяют что она не дублирует другую
-> Передают в разработку
Теоретически возможна ситуация, когда для пересечения данных из разных доменов создается отдельная команда. Например, если требуется аналитика на стыке большого количество доменов и заказчиком не является ни один из владельцев источников данных. Однако важно, чтобы за каждым объектом, метрикой и данными был четкий владелец. Это избегает хаоса в децентрализованной архитектуре.
Если остались вопросы, всегда готов уточнить :)
Спасибо! Да, я у вас в карте технологий увидел Data Catalog - судя по всему, вы за основу взяли Open Metadata?
Вот я тоже, с одной, стороны, за Data Mesh подход, который говорит "по возможности оставляем данные в системах, выгружая только необходимую для анализа информацию, чтобы не плодить сущности". С другой - там именно домены данных, а это сильно уменьшает возможности Data-Driven аналитики, когда мы можем в дашборд набросать любые данные из разных доменов, чтобы проверить ту или иную теорию.
Опять же, Каталог данных как раз и призван разрешить данное противоречие, так что очень интересно посмотреть практический опыт.
Да, а вы ведете реестр отчетов? Обычно его ведут для переиспользования.
А Бизнес-глоссарий и список KPI с методикой расчета ведете где-нибудь?
С Уважением, Георгий
Каталог, полностью внутреннее решение, за основу не брали никакой опенсорс каталог данных (но естественно вдохновлялись возможностями различных решений), про него коллега рассказывал на конференции в прошлом году, но к сожалению публично не выкладывали запись
Когда запускали новую платформу данных, наоборот было правило, все данные должны быть доступны в dwh, для старта идеальный подход. Выстроить аналитику по использованию данных в dwh. И дальше можно смело переходить в другой подход, забирать и хранить только нужные данные, так как стоимость хранения начинает расти, но тогда T2M для интеграции данных должна быть быстрыми(дни, а не недели).
Из всех BI-платформ собираются метаданные и отгружаются в каталог даных. В каталоге хранится и бизнес-глоссарий и формулы расчета метрик, в данный момент связи между объектами поддерживаются вручную.
Думаю когда нибудь команда BI подробнее расскажет про процессы ревью и сертификации отчетов, потому что в формате комментария сложно ответить на то как устроены эти процессы, а главное как итеративно к ним пришли ( @rinathabib бери на заметку востребованную тему для статьи)
Спасибо, круто! С @rinathabib тоже хорошо знакомы :)
Статья про ревью уже почти готова, скоро опубликуем 😉
Data Mesh: ожидания vs реальность