Comments 23
Из того, что сразу приходит на ум: к примеру, одна продуктовая команда — например, CRM, становится ответственной за «домен» CRM внутри data lake. При подходе data mesh эта команда самостоятельно вносит изменения в структуры данных и логику загрузки этих данных в data lake — то есть полностью управляет данными своей области. Но в большинстве случаев потребителям данных (скажем, для аналитических отчетов), нужны не только данные из CRM, но и из других областей тоже (к примеру, из биллинговой системы — чтобы посчитать выручку по каждой пиццерии). В таком случае, потребитель отчета уже оказывается «завязан» на две продуктовые команды. И если любая из этих команд внесет изменения в данные в своем домене, не учтя все возможные последствия этого изменения, то отчет скорее всего работать перестанет. А в любой крупной компании таких зависимостей между данными разных систем будет очень и очень много, соответственно и разделить ответственность между продуктовыми командами будет непросто — все равно нужен «надсмотрщик», который будет разруливать зависимости и контролировать изменения. Что в некоторой степени возвращает к «классической» модели с единой командой, отвественной за весь data lake.
Сталкивались ли с подобным? Или как планирует решать?
Но есть ощущение, что не полностью раскрыт рабочий процесс при использовании нового подхода с data mesh.
Ну поскольку мы только начинаем его строить — раскрыть полностью процесс очень сложно в одной статье. Очень сложно раскрыть то, что полностью пока не сформировалось :) Сейчас мы итеративно выстраиваем процесс работы с данными внутри команды Data Engeneering, что-бы потом переносить его (естественно адаптирую) на всю компанию.
А в любой крупной компании таких зависимостей между данными разных систем будет очень и очень много, соответственно и разделить ответственность между продуктовыми командами будет непросто — все равно нужен «надсмотрщик», который будет разруливать зависимости и контролировать изменения.
На мой взгляд тут ситуация похожа с API микросервисов. Если API опубликован — в нем нельзя делать breaking changes. То же самое с опубликованными схемами данных. Как это форсировать и контролировать? Мы сейчас думаем про автоматические тесты, которые не дадут накатить миграцию если в ней есть breaking changes.
На мой взгляд тут ситуация похожа с API микросервисов. Если API опубликован — в нем нельзя делать breaking changes. То же самое с опубликованными схемами данных. Как это форсировать и контролировать? Мы сейчас думаем про автоматические тесты, которые не дадут накатить миграцию если в ней есть breaking changes.
Мне кажется, тут будет довольно сложно определить, что означает breaking change. Очевидно, изменения в структуре данных, такие как удаление колонки в таблице или изменение типа данных в колонке — это breaking change.
Но как быть с изменениями в логике данных? Простой пример: раньше в столбце «сумма чека» хранилась сумма без НДС, а потом в операционной системе что-то поменяли и стала храниться сумма уже с включенным НДС. С точки зрения продуктовой команды — это необходимое изменение, но при этом все потребители, которые опирались на этот показатель в data lake, сразу прибегут и скажут что у них сломались расчеты. Для написания тестов, которые будут проверять все возможные подобные случаи, надо будет потратить кучу времени — для каждой метрики или атрибута продумать возможные варианты использования, написать тесты, убедиться что они корректно работают при всех возможных раскладах и т.п.
Я искренне желаю чтобы у вас все получилось :) но из моего опыта часто при разделении ответственности за данные между разными командами начинается хаос. В основном потому, что каждой команде проще встать в позицию «моя хата с краю» и не думать про последствия изменений, которые они вносят. Также начинается дублирование данных в data lake, так как часто отдельной команде срочно необходимы какие-то данные и им проще рассчитать их заново, нежели искать, не сделал ли кто-то это уже ранее.
Но как быть с изменениями в логике данных? Простой пример: раньше в столбце «сумма чека» хранилась сумма без НДС, а потом в операционной системе что-то поменяли и стала храниться сумма уже с включенным НДС. С точки зрения продуктовой команды — это необходимое изменение, но при этом все потребители, которые опирались на этот показатель в data lake, сразу прибегут и скажут что у них сломались расчеты.
Так они у нас и текущим DataMonolith прибегают регулярно. Плюс мы сами чиним переливки в текущее аналитическое хранилище тк фича команда может удалить столбец без объявления войны :) Вообщем с монолитом еще хуже :)
Для написания тестов, которые будут проверять все возможные подобные случаи, надо будет потратить кучу времени — для каждой метрики или атрибута продумать возможные варианты использования, написать тесты, убедиться что они корректно работают при всех возможных раскладах и т.п.
Ну тут наверное подход будет похожим на TDD — сначала пишем тесты на требования, при нахождении багов — тесты на баги. Так хотя-бы не будем чинить одно и то-же дважды.
Мы понимаем что нет серебряной пули, но нам кажется что эти инструменты упростят нам жизнь.
Я искренне желаю чтобы у вас все получилось :) но из моего опыта часто при разделении ответственности за данные между разными командами начинается хаос. В основном потому, что каждой команде проще встать в позицию «моя хата с краю» и не думать про последствия изменений, которые они вносят.
Спасибо за теплые пожелания :) Мы приложим все силы что-бы получилось. Ну а хаос будет всегда — в наших силах только попытаться минимизировать ущерб от него через инструментарий и процесс :)
1. Как боретесь с дублированием данных в разных доменах? Как организовано их переиспользование? На первый взгляд создавать одинаковые датасеты для разных команд в режиме изоляции не выглядит оптимальным.
2. Датасеты BI команды строятся на данных из доменов продуктовых команд?
3. Расскажите больше о том, как команды управляются внутри своих доменов. Используют airflow для etl задач? Кто пишет джобы? Как делят ресурсы?
4. Почему бы просто не раздать/обучить для каждой команды по data инженеру используя классический data lake подход? Насколько я понял, по сути, к этому все и пришло.
Почитав ваши вопросы, мне показалось, что вам кажется что все что описано — внедрено внутри компании. Это пока не так :) Сейчас мы на примере одной команды разрабатываем процесс и инструменты для внедрения Data Mesh в Додо. Так что мои ответы будут основываться на том, как мы видим конечный результат внедрения сейчас, а не на рабочем процессе.
1 Как боретесь с дублированием данных в разных доменах? Как организовано их переиспользование? На первый взгляд создавать одинаковые датасеты для разных команд в режиме изоляции не выглядит оптимальным.
Никак. У нас нет такой задачи. Если это будет неоптимальным в будущем — будем думать. Как вариант — выносить в отдельный домен данных которым будет владеть команда Data Engeneering.
2 Датасеты BI команды строятся на данных из доменов продуктовых команд?
Не совсем. Например уже на этапе проектирования нам понадобился датасет который включает факты опубликованные несколькими сервисами. В данном конкретном случае — логика мерджа была сложная и использовалась в нескольких отчетах. Мы вынесли ее в отдельный домен.
3 Расскажите больше о том, как команды управляются внутри своих доменов. Используют airflow для etl задач? Кто пишет джобы? Как делят ресурсы?
Технически мы используем Azure Kusto и его Kql для ETL. Он очень быстрый и нам хватает его возможностей. Данные в Kusto попадают через публикацию сообщений в Event Hub.
4 Почему бы просто не раздать/обучить для каждой команды по data инженеру используя классический data lake подход? Насколько я понял, по сути, к этому все и пришло.
Пока не пришло :) Еще идем. Классический Data Lake подразумевает что есть команда, которая отвечает за всю аналитическую схему данных в компании. Даже если все в итоге будет длится в 1 Mysql (который будет Data Lake) но ответственность за схему будет делится между фичакомандами — это уже Data mesh. Подход не про технологии, а про организацию работы людей.
Не совсем. Например уже на этапе проектирования нам понадобился датасет который включает факты опубликованные несколькими сервисами. В данном конкретном случае — логика мерджа была сложная и использовалась в нескольких отчетах. Мы вынесли ее в отдельный домен.
Нет опасений что таким образом у вас получится просто гигантское кол-во доменов с крайне разрозненными (в плохом смысле слова) данными? Как следствие может появится несколько велосипедов которые каждый по своему изощренно дергают источник и дают на выходе весьма похожие датасеты. Какова вообще логика напилки доменов? Per team, per user, per db object?
Подход не про технологии, а про организацию работы людей.
Ну вот поэтому мне и вдвойне интересно :) Сейчас наблюдаем схожую с описанной в посте проблему и хорошего + быстрого и не ресурсоемкого решения пока на горизонте обнаружено не было.
Данные должны быть целостными, доступными и не должно быть партиционирования.
/Закопали CAP.
Что в целом не отменяет вашей правоты.
В одной из моих предыдущих компаний был такой подход: данные хранились и обрабатывались централизованно, однако у каждого data set был свой владелец (фича-команда), которые отвечал за наполнение этого сета свежими данными, а так же за публикации актуальной спецификации структуры данных. Спецификация хранилась в центральном репозитории в формате Protobuf.
Не очень понятно как при таком подходе будет обеспечивтаться сквозная аналитика всего хранилища. Получается, что все данные будут жить в своих silos и аналитика будет происходить на уровне каждого silos независимо.
Мы пока думаем как это сделать. И надо ли это делать вообще. Ведь вполне можно создать домен для ad-hook аналитики, с помощью которого можно решить 80% вопросов. А если задача не попадает под 80% стандартных — ну что-ж надо создавать узкий домен.
В одной из моих предыдущих компаний был такой подход: данные хранились и обрабатывались централизованно, однако у каждого data set был свой владелец (фича-команда), которые отвечал за наполнение этого сета свежими данными, а так же за публикации актуальной спецификации структуры данных. Спецификация хранилась в центральном репозитории в формате Protobuf.
Это тоже Data Mesh в нашем понимании. Основная идея для нас — чтобы не было господа-бога-данных, без которого нельзя решить ни один вопрос, касающийся данных.
Да, я говорю про DevOps подход, где команда определяет, как нужно разворачивать продукт, который они создают.
Великий здравый смысл, с чего вы решили, что DevOps практики это про зоопарк велосипедов?
Хотелось бы точно понимать, в каком отношении этот подход находится к микросервисной архитектуре. Микросервисы — подход к созданию приложений, и связанные с ним (им вдохновленные, естественные или необходимые в его рамках и пр.) подходы к работе с данными, быть может, довольно беспроблемны при работе с application data. Но еnterprise data — это не application data.
Мне в статье на сайте Фаулера показались ничем не обеспеченными заявления о том, что данные при таком подходе внезапно обретают самоописания и семантику и отдельные домены перестают быть data silos. По-моему, это то, что при использовании такого подхода должно быть решено в первую очередь, а не то, что им решается. Вот про НСИ в комментариях выше писали, например.
В чем отличие концепции Data Mesh от гартнеровской концепции Data Fabric? Может быть, в том, что во второй эти проблемы осознаются и как-то решаются?
Data Mesh: как работать с данными без монолита