Комментарии 9
В двухмесячной давности «Hype Cycle for Data Management, 2022» Data Mesh помечен как «obsolete before plateau». Да и Benefit Rating у него «Low».
Иное дело Data Fabric :-).
Партнёрскую ссылку от одного вендора на полную версию гартнеровского отчёта в личку послал.
я читал дискуссии на эту тему, включая эту, мне они не кажутся очень продуктивными. слишком рано объявлять, что какой-то подход мертв или победил, да и в любом случае в каждой организации свои особенности, которые нужно учитывать при формировании дата-культуры и дата-архитектуры. некоторые принципы дата меш мне близки, и это уже делает более глубокое ознакомление небесполезным
data fabric про централизацию, а data mesh про децентрализацию. У каждого подхода есть минусы и плюсы, стоит ориентироваться на Вашу компанию
Но для поддержки всего этого добра нужна выделенная (и обычно немаленькая) команда дата-инженеров с особым набором скиллов, при росте количества источников и разнообразия данных становится всё сложнее обеспечивать их бизнес-качество, пайплайны по трансформации становятся всё сложнее и сложнее.
На первый взгляд, решение вот этой проблемы никак не следует из приведенных принципов. Если разбить данные на домены — с чего вдруг размеры и нужные скиллы команды поддержки станут меньше? Если число источников не изменилось — с чего им уменьшаться-то? Более того, как только возникают связи между доменами — возникают накладные расходы на их поддержание. Не бывает в жизни чудес — когда код разбивается на модули, на поддержание связи между модулями уходят ресурсы. Почему с данными вдруг будет как-то иначе?
Ну то есть, мысль что данные это продукт — она конечно интересная, но на то чтобы сделать их продуктом, тоже нужны ресурсы. А их всегда не хватает. Впрочем, у вас это написано.
Сейчас у нас накоплено почти 100 терабайт медицинских исследований, но количество данных абсолютно не важно
Хм. Понимаете какая штука… у вас 100 терабайт накоплено, а у нас есть источники, где одна таблица базы в сутки приносит нам 10 терабайт обновлений. Или скажем миллиарды строк. И количество данных очень даже важно зачастую, потому что на простое перекладывание этих данных всего из одного источника пожирает все доступные ресурсы, наращивание которых безгранично невозможно. Настолько все, что остатков может не хватать скажем на технический контроль качества данных.
В итоге мы делим данные на домены, потому что например упираемся в пределы масштабирования Hadoop как продукта, а не потому что нам так хочется (ну и поэтому тоже). Но это разделение совершенно очевидно приносит с собой свои проблемы разного рода.
Ну то есть я это к чему — не к тому что идея неверная, а скорее к тому, что у нее наблюдаются очевидные ограничения, при неочевидном профите. И не очевидно, как это будет масштабироваться за определенные границы.
я это вижу так - уменьшается количество людей, которым требуется знание узкоспециализированных скиллов, и устраняется боттлнек. например, у нас сейчас есть совсем небольшая дата-платформенная команда, при этом за качество доменных данных отвечают ML-щики в продуктовых ML-командах, и отдельный дата-инженер с глубоким знанием БД, Airflow, кубика и т.д. в этих командах не нужен
да, я полностью осознаю, что наш кейс весьма специфичный, и не ко всем ситуациям мои размышления подходят. но при этом мне всё равно кажется полезным принцип отношения к данным как к продукту, особенно в ML-core доменах
Как я понимаю, тут главное в ответственности команд производящих данные.
На мою централизованную команду платформы данных раньше часто сваливали и отвественность за поиск семантики данных из источника что из этого PHI, какие связи между доменами(на вопросы про которые не архитектора ни аналитики сами не могли ответить). А в одном из источников был такой Вавилон, что часто разработчики сами не знали что у них в БД лежит, нажитое за десятилетия эволюции их системы. Что мне понравилось в Agoda - это что продуктовые команды сами отвественны за поддержку метаинформации в схемах данных и пишут тесты для метрик, что передают в центарлизованный Hadoop и аналитические хранилища рядом с ним.
Концепция Data Mesh. Принципы, идеи, применение на практике