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