Блог компании Dodo Pizza Engineering
IT-инфраструктура
Big Data
Хранение данных
Data Engineering
Комментарии 23
+1
Интересная статья, спасибо. Но есть ощущение, что не полностью раскрыт рабочий процесс при использовании нового подхода с data mesh.

Из того, что сразу приходит на ум: к примеру, одна продуктовая команда — например, CRM, становится ответственной за «домен» CRM внутри data lake. При подходе data mesh эта команда самостоятельно вносит изменения в структуры данных и логику загрузки этих данных в data lake — то есть полностью управляет данными своей области. Но в большинстве случаев потребителям данных (скажем, для аналитических отчетов), нужны не только данные из CRM, но и из других областей тоже (к примеру, из биллинговой системы — чтобы посчитать выручку по каждой пиццерии). В таком случае, потребитель отчета уже оказывается «завязан» на две продуктовые команды. И если любая из этих команд внесет изменения в данные в своем домене, не учтя все возможные последствия этого изменения, то отчет скорее всего работать перестанет. А в любой крупной компании таких зависимостей между данными разных систем будет очень и очень много, соответственно и разделить ответственность между продуктовыми командами будет непросто — все равно нужен «надсмотрщик», который будет разруливать зависимости и контролировать изменения. Что в некоторой степени возвращает к «классической» модели с единой командой, отвественной за весь data lake.

Сталкивались ли с подобным? Или как планирует решать?
+1
Но есть ощущение, что не полностью раскрыт рабочий процесс при использовании нового подхода с data mesh.

Ну поскольку мы только начинаем его строить — раскрыть полностью процесс очень сложно в одной статье. Очень сложно раскрыть то, что полностью пока не сформировалось :) Сейчас мы итеративно выстраиваем процесс работы с данными внутри команды Data Engeneering, что-бы потом переносить его (естественно адаптирую) на всю компанию.
А в любой крупной компании таких зависимостей между данными разных систем будет очень и очень много, соответственно и разделить ответственность между продуктовыми командами будет непросто — все равно нужен «надсмотрщик», который будет разруливать зависимости и контролировать изменения.

На мой взгляд тут ситуация похожа с API микросервисов. Если API опубликован — в нем нельзя делать breaking changes. То же самое с опубликованными схемами данных. Как это форсировать и контролировать? Мы сейчас думаем про автоматические тесты, которые не дадут накатить миграцию если в ней есть breaking changes.
0
На мой взгляд тут ситуация похожа с API микросервисов. Если API опубликован — в нем нельзя делать breaking changes. То же самое с опубликованными схемами данных. Как это форсировать и контролировать? Мы сейчас думаем про автоматические тесты, которые не дадут накатить миграцию если в ней есть breaking changes.

Мне кажется, тут будет довольно сложно определить, что означает breaking change. Очевидно, изменения в структуре данных, такие как удаление колонки в таблице или изменение типа данных в колонке — это breaking change.

Но как быть с изменениями в логике данных? Простой пример: раньше в столбце «сумма чека» хранилась сумма без НДС, а потом в операционной системе что-то поменяли и стала храниться сумма уже с включенным НДС. С точки зрения продуктовой команды — это необходимое изменение, но при этом все потребители, которые опирались на этот показатель в data lake, сразу прибегут и скажут что у них сломались расчеты. Для написания тестов, которые будут проверять все возможные подобные случаи, надо будет потратить кучу времени — для каждой метрики или атрибута продумать возможные варианты использования, написать тесты, убедиться что они корректно работают при всех возможных раскладах и т.п.

Я искренне желаю чтобы у вас все получилось :) но из моего опыта часто при разделении ответственности за данные между разными командами начинается хаос. В основном потому, что каждой команде проще встать в позицию «моя хата с краю» и не думать про последствия изменений, которые они вносят. Также начинается дублирование данных в data lake, так как часто отдельной команде срочно необходимы какие-то данные и им проще рассчитать их заново, нежели искать, не сделал ли кто-то это уже ранее.
+1
Но как быть с изменениями в логике данных? Простой пример: раньше в столбце «сумма чека» хранилась сумма без НДС, а потом в операционной системе что-то поменяли и стала храниться сумма уже с включенным НДС. С точки зрения продуктовой команды — это необходимое изменение, но при этом все потребители, которые опирались на этот показатель в data lake, сразу прибегут и скажут что у них сломались расчеты.

Так они у нас и текущим DataMonolith прибегают регулярно. Плюс мы сами чиним переливки в текущее аналитическое хранилище тк фича команда может удалить столбец без объявления войны :) Вообщем с монолитом еще хуже :)


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

Ну тут наверное подход будет похожим на TDD — сначала пишем тесты на требования, при нахождении багов — тесты на баги. Так хотя-бы не будем чинить одно и то-же дважды.


Мы понимаем что нет серебряной пули, но нам кажется что эти инструменты упростят нам жизнь.


Я искренне желаю чтобы у вас все получилось :) но из моего опыта часто при разделении ответственности за данные между разными командами начинается хаос. В основном потому, что каждой команде проще встать в позицию «моя хата с краю» и не думать про последствия изменений, которые они вносят.

Спасибо за теплые пожелания :) Мы приложим все силы что-бы получилось. Ну а хаос будет всегда — в наших силах только попытаться минимизировать ущерб от него через инструментарий и процесс :)

+1

Похоже и НСИ придется разделять между доменами, а значит — частично дублировать их, синхронизировать и тд.

0
Возможно вы правы. Но честно говоря я не вижу сильных проблем в дублировании, если оно не несет за собой проблемы другого рода (рассинхрон данных например). Если будет нести — придется наверное выделить НСИ в отдельный домен. В принципе за НСИ в операционной системе сейчас отвечает отдельный микросервис. Так что выделение их в отдельный домен вполне возможно.
0
Для статичных НСИ все хорошо, а для достаточно динамичных (например производственные спецификации) рано или поздно встанет вопрос о распределенной транзакции, чтобы в процессе корректировки справочника никто не провел цепочку документов. Мне кажется проще не выделять НСИ и допустить рассинхрон между доменами — это более соответствует подходу. А что делать с рассинхроном — думать уже в отчетах, есть же свертка по нестрогому соответствию, или что-то вроде того.
0
Распределенные транзакции — это все-таки про операционную деятельность. В аналитической мы стараемся иметь дело с набором случившихся фактов. Так что пока мы не видим необходимости в транзакциях. Хотя факты конечно могут (и будут) разезжаться если сопоставлять их по времени. Так что мы сейчас думаем как сопоставлять факты по foregin key.
+1
Не пойму, зачем пиццерии Big Data и нейросети? Или пиццерия это только прикрытие?
0
Когда у тебя одна пиццерия, то можно и без Big Data обойтись. Но когда у тебя 545 пиццерий в 13 странах мира (связанных единой системой управления), каждую минуту обрабатывается 120-180 заказов, тысячи отслеживаемых метрик и т.д. и т.д., то тут уж без неё никак.
+1
Спасибо за статью, возникло несколько вопросов:
1. Как боретесь с дублированием данных в разных доменах? Как организовано их переиспользование? На первый взгляд создавать одинаковые датасеты для разных команд в режиме изоляции не выглядит оптимальным.
2. Датасеты BI команды строятся на данных из доменов продуктовых команд?
3. Расскажите больше о том, как команды управляются внутри своих доменов. Используют airflow для etl задач? Кто пишет джобы? Как делят ресурсы?
4. Почему бы просто не раздать/обучить для каждой команды по data инженеру используя классический data lake подход? Насколько я понял, по сути, к этому все и пришло.
0

Почитав ваши вопросы, мне показалось, что вам кажется что все что описано — внедрено внутри компании. Это пока не так :) Сейчас мы на примере одной команды разрабатываем процесс и инструменты для внедрения 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. Подход не про технологии, а про организацию работы людей.

0
Не совсем. Например уже на этапе проектирования нам понадобился датасет который включает факты опубликованные несколькими сервисами. В данном конкретном случае — логика мерджа была сложная и использовалась в нескольких отчетах. Мы вынесли ее в отдельный домен.


Нет опасений что таким образом у вас получится просто гигантское кол-во доменов с крайне разрозненными (в плохом смысле слова) данными? Как следствие может появится несколько велосипедов которые каждый по своему изощренно дергают источник и дают на выходе весьма похожие датасеты. Какова вообще логика напилки доменов? Per team, per user, per db object?

Подход не про технологии, а про организацию работы людей.


Ну вот поэтому мне и вдвойне интересно :) Сейчас наблюдаем схожую с описанной в посте проблему и хорошего + быстрого и не ресурсоемкого решения пока на горизонте обнаружено не было.
+1

Данные должны быть целостными, доступными и не должно быть партиционирования.


/Закопали CAP.

0
Заметил что каждый раз когда выкапывают CAP — где-то что-то тормозит, не дистрибьютит или не может обеспечить заявленного. По крайней мере таков личный опыт :)

Что в целом не отменяет вашей правоты.
0

У бухгалтеров такое часто бывает. Куда-то делось 100500 денег, приходится законы арифметики выкапывать.

0
Нее в терминах CAP мы хотим построить CP систему. A в терминах CAP мы не гарантируем A но хотим стремится к минимальным простоям по доступности.
+1
Не очень понятно как при таком подходе будет обеспечивтаться сквозная аналитика всего хранилища. Получается, что все данные будут жить в своих silos и аналитика будет происходить на уровне каждого silos независимо.

В одной из моих предыдущих компаний был такой подход: данные хранились и обрабатывались централизованно, однако у каждого data set был свой владелец (фича-команда), которые отвечал за наполнение этого сета свежими данными, а так же за публикации актуальной спецификации структуры данных. Спецификация хранилась в центральном репозитории в формате Protobuf.
0
Не очень понятно как при таком подходе будет обеспечивтаться сквозная аналитика всего хранилища. Получается, что все данные будут жить в своих silos и аналитика будет происходить на уровне каждого silos независимо.

Мы пока думаем как это сделать. И надо ли это делать вообще. Ведь вполне можно создать домен для ad-hook аналитики, с помощью которого можно решить 80% вопросов. А если задача не попадает под 80% стандартных — ну что-ж надо создавать узкий домен.


В одной из моих предыдущих компаний был такой подход: данные хранились и обрабатывались централизованно, однако у каждого data set был свой владелец (фича-команда), которые отвечал за наполнение этого сета свежими данными, а так же за публикации актуальной спецификации структуры данных. Спецификация хранилась в центральном репозитории в формате Protobuf.

Это тоже Data Mesh в нашем понимании. Основная идея для нас — чтобы не было господа-бога-данных, без которого нельзя решить ни один вопрос, касающийся данных.

0
Да, я говорю про DevOps подход, где команда определяет, как нужно разворачивать продукт, который они создают.
Великий здравый смысл, с чего вы решили, что DevOps практики это про зоопарк велосипедов?
0

Мы понимаем DevOps как набор практик, с помощью которых фичакоманда может доставить свой продукт до конечного потребителя. Если кто-то делает это через зоопарк велосипедов (и это работает) — кто мы такие что-бы запрещать ковыряться в носу :)
У нас самих зоопарка если что нет :) k8s — наше все :)

+1

Хотелось бы точно понимать, в каком отношении этот подход находится к микросервисной архитектуре. Микросервисы — подход к созданию приложений, и связанные с ним (им вдохновленные, естественные или необходимые в его рамках и пр.) подходы к работе с данными, быть может, довольно беспроблемны при работе с application data. Но еnterprise data — это не application data.


Мне в статье на сайте Фаулера показались ничем не обеспеченными заявления о том, что данные при таком подходе внезапно обретают самоописания и семантику и отдельные домены перестают быть data silos. По-моему, это то, что при использовании такого подхода должно быть решено в первую очередь, а не то, что им решается. Вот про НСИ в комментариях выше писали, например.


В чем отличие концепции Data Mesh от гартнеровской концепции Data Fabric? Может быть, в том, что во второй эти проблемы осознаются и как-то решаются?

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