Data Mesh: стоит ли попробовать это дома?

Централизовать или распределить управление данными? Этот вопрос стоял на переднем крае с тех пор, как ведомственные миникомпьютеры вторглись на предприятие, а затем, еще более подрывно, ПК и локальные сети вошли через черный ход. И с тех пор общепринятая точка зрения колебалась взад и вперед. Системы рабочих групп или подразделений, чтобы сделать данные доступными, а затем консолидировать корпоративные базы данных, чтобы избавиться от дублирования.

Помните, когда озеро данных должно было стать конечным состоянием? Как и в случае с корпоративным хранилищем данных до него, идея о том, что все данные могут быть собраны в одном месте, чтобы существовал только один источник правды, к которому могли получить доступ все слои общества на предприятии. нереально. Связность Интернета, кажущаяся дешевизна хранилища и бесконечная масштабируемость облака, взрывной рост количества интеллектуальных устройств и данных Интернета вещей угрожает настолько трудоемким перегрузкой хранилищ данных и озер данных настраивать.

Озера данных в последнее время появились, чтобы объединить лучшее из обоих миров, в то время как фабрики данных и интеллектуальные центры данных оптимизируют компромисс между виртуализацией и репликацией данных.

Было бы бессмысленно утверждать, что любая из этих альтернатив предлагает окончательное решение проблемы.

Введите сетку данных

За последний год появилась новая теория, признающая тщетность нисходящих или монолитных подходов к управлению данными: сетка данных. Хотя в последнее время основное внимание уделяется искусственному интеллекту и машинному обучению, в мире данных меньше тем, которые привлечение большего количества дискуссий чем сетка данных. Просто посмотрите на данные Google Trends за последние 90 дней: число поисковых запросов по Data Mesh намного превышает количество запросов по Data Lakehouse.

Он был создан Жамак Дехгани, директор инкубатора следующих технологий в Мысльтворкс Северная Америка, через обширный набор работ, начиная с введения еще в 2019 году, углубленное изучение принципов и логической архитектуры. в конце 2020 года, это скоро достигнет кульминации в книге (если вы заинтересованы, Данные о звездообразованиях предлагает краткий обзор). Сетки данных часто по сравнению с фабриками данных, но внимательное прочтение работы Дегани показывает, что речь идет больше о процессе, чем о технологии, как правильно заметил Джеймс Серра, руководитель архитектуры в EY, а ранее работавший в Microsoft. в сообщении в блоге. Тем не менее, тема сеток данных (которые представляют собой распределенные представления массива данных) по сравнению с. фабрики данных (которые применяют более централизованные подходы) заслуживают отдельного поста, поскольку интерес как к было очень похоже.

Проще говоря, если это возможно, сетка данных нет технологический стек или физическая архитектура. Сетка данных — это процессный и архитектурный подход, который делегирует ответственность за конкретные наборы данных доменам или областям деятельности. компания, обладающая необходимыми знаниями в предметной области, чтобы знать, что должны представлять данные и как они должны быть использовал.

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

Помимо внешнего регулирования или политики корпоративного управления, домены являются причиной сбора конкретных наборов данных. Но дьявол кроется в деталях, а их очень много.

Таким образом, сетка данных не определяется хранилищем данных, озером данных или озером данных, где данные физически находятся. Он также не определяется средствами объединения данных, интеграции данных, механизма запросов или каталогизации, которые заполняют и аннотируют эти хранилища данных. Конечно, это не остановило поставщиков технологий от промывка сетки данных их продукты. В течение следующего года мы, вероятно, увидим, как поставщики каталогов, механизмов запросов, конвейеров данных и управления будут рисовать свои инструменты или платформы в свете сетки данных. Но, видя маркетинговые сообщения, помните, что сетки данных связаны с процессом и тем, как вы реализуете технологию. Например, механизм федеративных запросов — это просто инструмент, который может помочь команде в реализации, но сам по себе не превращает массив данных внезапно в сетку данных.

Основные принципы

Data Mesh — сложная концепция, но лучший способ начать — понять принципы, лежащие в ее основе.

Первый принцип касается владение данными – он должен быть локальным и принадлежать команде, ответственной за сбор и/или использование данных. Если и существует главный принцип сеток данных, так это он: контроль над данными должен перейти к домену, который ими владеет. Думайте о домене как о расширении знаний о предметной области — это организационная единица или группа людей, которые понимают, что такое данные и как они связаны с бизнесом. Это сущность, которая знает, почему собирается набор данных; как он потребляется и кем; и как им следует управлять на протяжении всего его жизненного цикла.

Ситуация становится немного сложнее с данными, которые совместно используются несколькими доменами или когда данные в одном домене зависят от данных или API из других доменов. Добро пожаловать в реальный мир, где данные редко являются островом. Это одно из мест, где реализация сеток может оказаться затруднительной.

Второй принцип заключается в том, что данные следует рассматривать как продукт. По сути, это более широкое представление о том, что включает в себя объект данных, поскольку это нечто большее, чем просто часть данных. данные или конкретный набор данных и в большей степени учитывает жизненный цикл того, как данные могут и должны обслуживаться и потребляется. Частью определения продукта является формальная цель уровня обслуживания, которая может относиться к факторам такие как производительность, надежность и надежность, качество данных, правила авторизации, связанные с безопасностью, и т. д. на. Это обещание, которое домен, которому принадлежат данные, дает организации.

В частности, продукт данных выходит за рамки набора данных или объекта данных и включает в себя код для конвейеров данных, необходимых для генерации и/или преобразования данных; связанные метаданные (которые, конечно, могут включать в себя все: от определения схемы до соответствующего бизнеса). термины глоссария, модели потребления или формы, такие как реляционные таблицы, события, пакетные файлы, формы, графики, и т. д.); и инфраструктура (как и где данные хранятся и обрабатываются). Это имеет серьезные организационные последствия, учитывая, что построение конвейеров данных часто представляет собой трудную задачу. разрозненная деятельность, выполняемая независимо специалистами-практиками, такими как инженеры по обработке данных и Разработчики. По крайней мере, в контексте матрицы они должны быть частью предметной области или бизнес-команды, владеющей данными, или быть связаны с ней.

Кстати, этот информационный продукт должен удовлетворять некоторым ключевым требованиям. Данные должны быть легко обнаруживаемый; Наверное, для этого и нужны каталоги. Это также должно быть исследуемый, позволяя пользователям углубляться в детали. И это должно быть адресный; здесь Дегани упоминает, что данные должны иметь уникальные канонические адреса, что звучит как абстракция более высокого уровня, которую представляет собой остаток семантической сети, классический Ури. Наконец, данные должны быть понятно(Дегани предлагает «самоописываемую семантику и синтаксис»); заслуживающий доверия; и безопасный. Давайте не будем забывать, что, поскольку предполагается, что это будет охватывать несколько областей, потребуются усилия по гармонизации данных.

Хотя сетка данных не определяется технологией, в реальном мире конкретные инженерные группы будут владеть базовой платформой данных, будь то база данных, озеро данных и/или механизм потоковой передачи. Это применимо независимо от того, внедряет ли организация эти платформы локально или использует службу управляемой базы данных в облаке, и, что более вероятно, в обоих местах. Кто-то должен владеть базовой платформой, и эти платформы тоже будут считаться продуктами по большому счету.

Третий принцип – необходимость доступа к данным через платформа данных самообслуживания как показано выше. Конечно, самообслуживание стало лозунгом более широкого доступа к данным, поскольку это единственный способ сделать данные доступными. расходуется по мере расширения массива данных, учитывая, что ИТ-ресурсы ограничены, особенно среди инженеров по обработке данных, которые редки и драгоценный. То, что она здесь описывает, не следует путать с платформами самообслуживания для визуализации данных или специалистами по данным; это больше для разработчиков инфраструктуры и продуктов.

Эта платформа может иметь, как называет Дегани, разные планы (или оболочки), которые обслуживают разные группы практиков. Примеры могут включать плоскость предоставления инфраструктуры, которая занимается всей уродливой физической механикой маршалинга данных (например, предоставлением хранилища; настройка контроля доступа; и механизм запросов); опыт разработки продуктов, обеспечивающий декларативный интерфейс для управления жизненным циклом данных; и плоскость наблюдения, которая управляет продуктами данных. Дегани получает гораздо более подробную информацию о том, что должна поддерживать платформа данных самообслуживания, и вот список.

Наконец, ни один подход к управлению данными не будет полным без управления. Это четвертый принцип, и Дегани называет его федеративное вычислительное управление. Это подтверждает тот факт, что в распределенной среде будет существовать множество взаимозависимых продуктов данных, которые должны взаимодействовать и при этом поддерживать мандаты на суверенитет данных и сопутствующие правила хранения и доступ. Потребуется полностью понимать и отслеживать происхождение данных.

Один пост не сможет передать эту тему должным образом. Рискуя исказить идею, это означает, что объединение информационных продуктов и данных Владельцы продуктов платформы создают и обеспечивают соблюдение глобального набора правил, применимых ко всем продуктам данных и интерфейсы. Чего здесь не хватает, так это того, что необходимо предусмотреть положение для высшего руководства, когда речь идет о политике и мандатах в масштабе всего предприятия; Дегани делает такой вывод (надеюсь, ее книга станет более конкретной). По сути, Дегани заявляет о том, что сегодня, вероятно, является неформальной практикой, когда множество специальных решений по управлению уже принимается на местном уровне.

Так стоит ли попробовать это дома?

Лишь немногие темы привлекли столько внимания в мире данных за последний год, как сетка данных. Одним из триггеров является то, что в мире, который становится все более ориентированным на облака, где приложения и бизнес-логика разлагаются на микросервисы, почему бы не относиться к данным таким же образом?

Ответ легче сказать, чем сделать. Например, хотя монолитные системы могут быть жесткими и громоздкими, распределенные системы привносят свои сложности, добро пожаловать или нет. Существует риск создания новых разрозненностей, не говоря уже о хаосе, если расширение прав и возможностей на местном уровне не будет должным образом продумано.

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

Распределение управления жизненным циклом данных может быть полезным, но в большинстве организаций, вероятно, будет множество случаев, когда право собственности на данные не четко определено для сценариев, когда несколько групп заинтересованных сторон либо совместно используют данные, либо когда данные получены от кого-то другого. данные. Дегани признает это, отмечая, что домены обычно получают данные из нескольких источников, и в В свою очередь, разные домены могут дублировать данные (и преобразовывать их по-разному) для своих собственных нужд. потребление.

Сетки данных как концепции находятся в стадии разработки. В своем вступительном посте Дегани обращается к ключевому подходу к обеспечению доступности данных: через то, что она называет «самоописанной семантикой». Но ее описание кратко, что указывает на то, что использование «хорошо описанного синтаксиса» в сочетании с примерами наборов данных и спецификациями схемы является хорошей отправной точкой — для инженера по обработке данных, а не для бизнеса. аналитик. Мы хотели бы увидеть ее воплощение в ее будущей книге.

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

Тем не менее, есть веские причины, по которым мы проводим эту дискуссию. Имеются разногласия с данными, и многие проблемы вряд ли новы. Централизованная архитектура, такая как корпоративное хранилище данных, озеро данных или хранилище данных, не может оправдать себя в многоязычном мире. С другой стороны, можно привести аргументы в пользу подхода, основанного на фабрике данных, который утверждает, что более централизованный подход к управлению метаданными и обнаружению данных будет более эффективным. Также есть основания полагать, что гибридный подход, использующий возможности унифицированных метаданных, управление фабрикой данных может использоваться в качестве логической объединительной платы для доменов для создания и владения своими данными. продукты.

Еще одна проблема заключается в том, что процессы обработки данных на каждом этапе их жизненного цикла часто не пересекаются. инженеры по обработке данных или разработчики приложений, создающие конвейеры, могут быть отделены от линейных организаций, в которых обрабатываются данные. служит. Самообслуживание стало популярным среди бизнес-аналитиков для визуализации, а также для специалистов по обработке данных при разработке моделей ML и их внедрении в производство. Есть хороший повод распространить это на управление жизненным циклом данных на команды, которые по всей логике должны владеть данными.

Но не будем забегать вперед. Это очень амбициозная вещь. Как упоминалось ранее, когда дело доходит до распределения управления и владения информационными ресурсами, дьявол кроется в деталях. И есть много деталей, которые еще предстоит прояснить. Мы еще не убеждены в том, что такие восходящие подходы к владению данными будут масштабироваться по всему корпоративному массиву данных, и что возможно, нам следует нацелиться на более скромные взгляды: ограничить сетку частями организации со связанными или взаимозависимыми домены.

Мы видим несколько постов где клиенты преждевременно заявляют о победе. Но эта почта утверждает, что то, что ваша организация внедрила уровень интегрированных запросов или сегментирует свои озера данных, не превращает ее развертывание в сетку данных. На этом этапе внедрение сетки данных со всем ее распределенным управлением следует рассматривать как доказательство концепции.