Comments 18
Возможно я что-то упустил, но совершенно непонятным остался один аспект. Мы не будем строить монолитное хранилище, а сделаем отдельные домены доступными извне, адресуемыми, снабдим их метаданными, и т.д. и т.п. Прелестно, прелестно. А дальше-то?
Представим, что нам нужен, условно, JOIN с использованием данных из разных доменов. Распределенных, как автор предложил. Кто и где его будет строить? Ресурсы каких процессоров, место на каких носителях, что за код при этом будет выполняться?
Представим, что нам нужен, условно, JOIN с использованием данных из разных доменов. Распределенных, как автор предложил. Кто и где его будет строить? Ресурсы каких процессоров, место на каких носителях, что за код при этом будет выполняться?
0
Прежде всего сделаю оговорку, что не считаю себя экспертом по этой новой архитектуре Data Mesh. Но статью перевёл + изучил все доступные материалы по теме в Интернете (коих пока немного). Поэтому далее моё личное понимание материала.
Значит по поводу того, что делать с join-ами данных из разных доменов.
Ключевое отличие этой архитектуры Data Mesh от предыдущих в том, что у нас теперь действительно не монолитное хранилище (или монолитный Data Lake), а экосистема data-продуктов.
Data-продукты могут быть двух видов (об этом написано в статье):
1. Data-продукты, ориентированные на источник данных — по сути сырые данные, но уже прошедшие через какие-то этапы очистки и, возможно, трансформации формата. В качестве источников данных для таких продуктов выступают информационные системы банка.
2. Data-продукты, ориентированные на потребителя — читай витрины (хотя могут быть и в разных форматах: таблицы, выгрузки в файл, потоковые данные — топики кафка и т.п.). В качестве источников данных для таких продуктов будут уже чаще выступать другие data-продукты. Создаются эти продукты тем доменом, у которого есть потребность в них.
По поводу того где размещать эти продукты. Тут могут быть разные варианты. Автор статьи предлагает использовать централизованную инфраструктурную платформу для всех data-продуктов. Это может быть как единая СУБД, где каждый домен будет иметь свою схему, так и единый для всех кластер hadoop со своими областями для каждого домена. Возможна и федеративная архитектура с собственной вычислительной инфраструктурой у каждого домена. При создании data-продуктов предполагается максимальное использование всех инструментов и фреймворков, предоставленных централизованной инфраструктурной командой.
Значит по поводу того, что делать с join-ами данных из разных доменов.
Ключевое отличие этой архитектуры Data Mesh от предыдущих в том, что у нас теперь действительно не монолитное хранилище (или монолитный Data Lake), а экосистема data-продуктов.
Data-продукты могут быть двух видов (об этом написано в статье):
1. Data-продукты, ориентированные на источник данных — по сути сырые данные, но уже прошедшие через какие-то этапы очистки и, возможно, трансформации формата. В качестве источников данных для таких продуктов выступают информационные системы банка.
2. Data-продукты, ориентированные на потребителя — читай витрины (хотя могут быть и в разных форматах: таблицы, выгрузки в файл, потоковые данные — топики кафка и т.п.). В качестве источников данных для таких продуктов будут уже чаще выступать другие data-продукты. Создаются эти продукты тем доменом, у которого есть потребность в них.
По поводу того где размещать эти продукты. Тут могут быть разные варианты. Автор статьи предлагает использовать централизованную инфраструктурную платформу для всех data-продуктов. Это может быть как единая СУБД, где каждый домен будет иметь свою схему, так и единый для всех кластер hadoop со своими областями для каждого домена. Возможна и федеративная архитектура с собственной вычислительной инфраструктурой у каждого домена. При создании data-продуктов предполагается максимальное использование всех инструментов и фреймворков, предоставленных централизованной инфраструктурной командой.
0
>единый для всех кластер hadoop со своими областями для каждого домена
Ну мне вот почему-то кажется, что для реально больших данных — это чуть ле не единственно практичный вариант.
Вообще, почему мне идея еще сомнительна — потому что «монолитный» Data Lake — это прежде всего монолитная архитектура. Т.е. это хадуп, например, и все данные в хадупе, доступны для например спарка (или упомятуного тут Beam, хотя я совершенно не понял, что автор такого увидела в Beam, чего нет в спарке, продукт как продукт, совершенно не новый, и никакого прорыва, на мой взгляд, не дает вообще).
А распределенные бизнес домены — это как правило разные архитектуры, т.е. где-то в основе оракл, где-то Терадата, где-то еще что-то — и на их интеграцию нужны разработчики, имеющие квалификацию в каждой технологии. И наш опыт четко показывает, что чем больше зоопарка в технологиях — тем больше проблем. Берем тривиально и к ораклу добавляем еще MS SQL — и уже огребаем время от времени.
Ну мне вот почему-то кажется, что для реально больших данных — это чуть ле не единственно практичный вариант.
Вообще, почему мне идея еще сомнительна — потому что «монолитный» Data Lake — это прежде всего монолитная архитектура. Т.е. это хадуп, например, и все данные в хадупе, доступны для например спарка (или упомятуного тут Beam, хотя я совершенно не понял, что автор такого увидела в Beam, чего нет в спарке, продукт как продукт, совершенно не новый, и никакого прорыва, на мой взгляд, не дает вообще).
А распределенные бизнес домены — это как правило разные архитектуры, т.е. где-то в основе оракл, где-то Терадата, где-то еще что-то — и на их интеграцию нужны разработчики, имеющие квалификацию в каждой технологии. И наш опыт четко показывает, что чем больше зоопарка в технологиях — тем больше проблем. Берем тривиально и к ораклу добавляем еще MS SQL — и уже огребаем время от времени.
0
Ну в общем автор так и пишет:
Зоопарка разных технологий, своих для каждого бизнес-домена, не предполагается.
Data Mesh представляет собой распределённую архитектуру, с централизованным управлением и разработанными стандартами, обеспечивающими интегрируемость данных, и с централизованной инфраструктурой, предоставляющей возможность использования в режиме самообслуживания. Я надеюсь читателю достаточно очевидно, что такая архитектура очень далека от набора слабосвязанных хранилищ недоступных данных, независимо разрабатываемых в разных подразделениях.
Зоопарка разных технологий, своих для каждого бизнес-домена, не предполагается.
0
Вообще, в этой архитектуре централизованными остаются немного вещей:
1. Формирование стандартов и практик в отношении создания/сопровождения/предоставления доступов к data-продуктам. Ну и контроль за соблюдением и выполнением этих стандартов и практик
2. Создание и поддержка централизованной инфраструктуры для создания и хранения всех data-продуктов. Здесь же все инструменты для создания data pipelines (ETL процессов), версионирования, шифрования, мониторинга и т.д.
3. Создание и сопровождение инструментов для регистрации продуктов (Data Catalog) и ведения бизнес-глосария. И, соответственно, контроль регистрации data-продуктов и ведения бизнес-глосария
4. Всё!
Лично я не исключаю варианта создания и поддержки некоторых базовых витрин и общих справочников централизованной командой. В случае, если у таких витрин и справочников не очевидна принадлежность к конкретному домену и много потенциальных потребителей из разных доменов.
1. Формирование стандартов и практик в отношении создания/сопровождения/предоставления доступов к data-продуктам. Ну и контроль за соблюдением и выполнением этих стандартов и практик
2. Создание и поддержка централизованной инфраструктуры для создания и хранения всех data-продуктов. Здесь же все инструменты для создания data pipelines (ETL процессов), версионирования, шифрования, мониторинга и т.д.
3. Создание и сопровождение инструментов для регистрации продуктов (Data Catalog) и ведения бизнес-глосария. И, соответственно, контроль регистрации data-продуктов и ведения бизнес-глосария
4. Всё!
Лично я не исключаю варианта создания и поддержки некоторых базовых витрин и общих справочников централизованной командой. В случае, если у таких витрин и справочников не очевидна принадлежность к конкретному домену и много потенциальных потребителей из разных доменов.
0
>2. Создание и поддержка централизованной инфраструктуры для создания и хранения всех data-продуктов. Здесь же все инструменты для создания data pipelines (ETL процессов), версионирования, шифрования, мониторинга и т.д.
Ну мы и так уже к этому пришли. Причем на обычном хадупе. Грубо говоря, вы можете иметь два или больше кластеров — но IPA при этом лучше иметь общую (хотя тут есть проблемы с масштабированием, начиная с некоторых размеров). И еще некоторые инструменты неплохо иметь централизованные. А дальше вполне можно (и даже где-то нужно) жить не на одном большом хадупе, который тоже упирается в масштабирование некоторых компонент, а на нескольких поменьше размером.
Ну мы и так уже к этому пришли. Причем на обычном хадупе. Грубо говоря, вы можете иметь два или больше кластеров — но IPA при этом лучше иметь общую (хотя тут есть проблемы с масштабированием, начиная с некоторых размеров). И еще некоторые инструменты неплохо иметь централизованные. А дальше вполне можно (и даже где-то нужно) жить не на одном большом хадупе, который тоже упирается в масштабирование некоторых компонент, а на нескольких поменьше размером.
0
Тут весь вопрос в том, кто у вас загружает сырые данные из источников и строит специализированные витрины. Если всё это делают централизованные команды, не имеющие понимания ни бизнес-смысла загружаемых данных, ни реальных кейсов их дальнейшего использования, то это не Data Mesh :) Суть новой архитектуры в том, что владение данными (data-продуктами) распределено по бизнес-доменам.
0
не понятно как такое может масштабироваться. имхо основная сложность больших энтерпрайзов не в размере, а то что данные идут с разных систем, разработанных или полученных вместе покупками конкурентов, которые одни и те же понятия по разному оформляют. если каждый источник сгружает данные так как ему удобно то потом каждый потребитель должен будет изобретать какие-то свои мапинги из источника в свои понятия, что бы получить что-то осмысленное. на большом кол-ве источников это быстро превратится в ад. опять же, у источника бизнес процессы меняются. источник добавил колонку is_deleted, теперь тучи потребителей должны переколбашивать свои etl. а что если они не готовы сейчас этим заняться?
то что data owner должен сам рисовать выгрузки я согласен, но без каких-то централизованных структур в крупной организации никак. data owner должен интегрировать свои данные во что-то централизованное, корректно замапив свои понятие на некие общие.
то что data owner должен сам рисовать выгрузки я согласен, но без каких-то централизованных структур в крупной организации никак. data owner должен интегрировать свои данные во что-то централизованное, корректно замапив свои понятие на некие общие.
+1
если каждый источник сгружает данные так как ему удобно то потом каждый потребитель должен будет изобретать какие-то свои мапинги из источника в свои понятия, что бы получить что-то осмысленное. на большом кол-ве источников это быстро превратится в ад.
Всё верно, есть такая проблема. Поэтому, как и написано в статье, необходимо задавать общие правила, стандарты и политики для всех доменов по поводу оформления их data-продуктов. В том числе такие стандарты могут включать в себя правила наименование атрибутов, соответствие бизнес-глосарию и т.д.
опять же, у источника бизнес процессы меняются. источник добавил колонку is_deleted, теперь тучи потребителей должны переколбашивать свои etl. а что если они не готовы сейчас этим заняться?
Data-продукты доменов должны существовать отдельно от данных, хранящихся в БД информационных систем. Должно быть предусмотрено версионирование таких продуктов. Тут всё как с API — отдельные системы не вносят несогласованные со всеми потребителями изменения в свои API.
то что data owner должен сам рисовать выгрузки я согласен, но без каких-то централизованных структур в крупной организации никак. data owner должен интегрировать свои данные во что-то централизованное, корректно замапив свои понятие на некие общие.
В статье же описаны централизованные структуры. Во-первых, централизованная инфраструктура (и централизованная же команда, которая отвечает за эту инфраструктуру).Во-вторых, централизованный Data Governance (стандарты, практики, контроль за их выполнением). В-третьих, централизованная регистрация data-продуктов в системе типа Data Catalog и централизованное же ведение бизнес-глосария (где за разные бизнес-термины отвечают соответствующие домены).
0
Не понимаю, что нового автор предложил. Если эти его "домены" и "дата-продукты" переназвать "базы данных", все остается как есть.
0
По-моему автор высосал из пальца революцию. Нормальные архитектуры и подходы давно выглядят как декомпозиция большой кучи на маленькие с прописанными контрактами
0
Читал эту статью пару месяцев назад. С учётом того, что автор из консалтинга — осталось устойчивое ощущение, что мне пытаются продать свои услуги. Как выше верно подметили про "дата-продкты" и "базы данных". Просто автор пытается выделиться на фоне других консалтингов с помощью красивой обёртки
+2
На протяжении всей статьи пытался увидеть среди плюсов технологии — увеличение производительности при использовании каждого продукта при трансформации существующих мощностей в новую архитектуру.
Ну предположим, что за счет предподготовки части данных в каждом продукте мы получим какой-то выигрышь в производительности, НО — что нам делать с решением вот этой обозначенной проблемы:
К своему сожалению я не просто не увидел за счет чего вдруг у меня нарисуются свободные ресурсы для проверки гипотез НА БОЛЬШИХ ДАННЫХ. Более того, за счет дублирования и частого обновления данных между продуктами сама модель потребует на постоянной основе достаточно много ресурсов на самообслуживание целостности и оперативности данных.
В чем будет реально серьезное увеличение затрат на высокопрофессиональные кадры в объеме куда большем, чем число админов по обслуживанию централизованной системы — из текста очевидно, а вот преимущества — совсем не очевидны.
Те-же вопросы сейчас решаются интеграциями на уровне информационных систем или непосредственно БД и это обходится многократно дешевле, чем содержание кучи DevOps'ов к каждому из которых ещё команда бизнес предметников нужна.
Это всё к вопросу о том, почему я ждал радикального высвобождения ресурсов. Для меня — если технология позволяет мне тратить на железо значительно меньше, чем я мог бы потратить за минусом зарплаты всех необходимых DevOps — то это верный путь.
Если же мы говорим, что мы по всем направлениям получаем только рост затрат — системный рост затрат, потому что растет не только объем данных, но и бизнес, а выигрыш только в качестве данных и (очень сомнительном) сокращении объема технического долга, то надо искать другой путь трансформации централизованных систем.
Может быть я что-то неверно понял в этой части?
Ну предположим, что за счет предподготовки части данных в каждом продукте мы получим какой-то выигрышь в производительности, НО — что нам делать с решением вот этой обозначенной проблемы:
Потребности организаций в инновациях. Необходимость в быстрой проверке гипотез и частых экспериментах ведёт к большому количеству вариантов использования данных.
К своему сожалению я не просто не увидел за счет чего вдруг у меня нарисуются свободные ресурсы для проверки гипотез НА БОЛЬШИХ ДАННЫХ. Более того, за счет дублирования и частого обновления данных между продуктами сама модель потребует на постоянной основе достаточно много ресурсов на самообслуживание целостности и оперативности данных.
В чем будет реально серьезное увеличение затрат на высокопрофессиональные кадры в объеме куда большем, чем число админов по обслуживанию централизованной системы — из текста очевидно, а вот преимущества — совсем не очевидны.
Те-же вопросы сейчас решаются интеграциями на уровне информационных систем или непосредственно БД и это обходится многократно дешевле, чем содержание кучи DevOps'ов к каждому из которых ещё команда бизнес предметников нужна.
Это всё к вопросу о том, почему я ждал радикального высвобождения ресурсов. Для меня — если технология позволяет мне тратить на железо значительно меньше, чем я мог бы потратить за минусом зарплаты всех необходимых DevOps — то это верный путь.
Если же мы говорим, что мы по всем направлениям получаем только рост затрат — системный рост затрат, потому что растет не только объем данных, но и бизнес, а выигрыш только в качестве данных и (очень сомнительном) сокращении объема технического долга, то надо искать другой путь трансформации централизованных систем.
Может быть я что-то неверно понял в этой части?
0
Думаю, подобный подход не надо натягивать на большие данные.
У очень многих компаний нет больших данных, а вот проблемы с возможностью анализировать данные — есть. По причине бардака в данных.
У очень многих компаний нет больших данных, а вот проблемы с возможностью анализировать данные — есть. По причине бардака в данных.
0
1. Даже если не натягивать предлагаемый подход на большие данные, всё равно не видно экономических преимуществ для компании от её внедрения — непонятно откуда возьмутся сокращение затрат на обработку данных или свободные серверные (продуктовые) ресурсы, если взять и просто трансформировать под новый подход существующие ресурсы — т.е. сохранить базу для сравнения.
2. Проблемы в ресурсах у компаний связаны, по большей части, не с бардаком в данных, а с объемом свободных ресурсов под параллельную высоконагруженную обработку при проверке гипотез или отладке, не важно — просто статистики, предсказательной аналитики или AI. Бардак данных может устраняться поэтапно, с учетом имеющихся ресурсов, с сохранением результатов каждого этапа и началом следующего на закомиченных данных после предыдущего. А вот аналитику кусками не пустишь, на качество результата очень сильно влияет.
2. Проблемы в ресурсах у компаний связаны, по большей части, не с бардаком в данных, а с объемом свободных ресурсов под параллельную высоконагруженную обработку при проверке гипотез или отладке, не важно — просто статистики, предсказательной аналитики или AI. Бардак данных может устраняться поэтапно, с учетом имеющихся ресурсов, с сохранением результатов каждого этапа и началом следующего на закомиченных данных после предыдущего. А вот аналитику кусками не пустишь, на качество результата очень сильно влияет.
0
А как соотносятся концепции Data Mesh и Data Fabric?
0
Sign up to leave a comment.
Переход от монолитного Data Lake к распределённой Data Mesh