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