Архитектура сети данных (data mesh) распределяет владение данными среди команд из разных предметных областей, с федеративным управлением и децентрализованными продуктами по обработке данных. Сеть данных отличается от других аналогичных архитектур именно своей высокой децентрализацией: она распределена, а не централизована.

Наблюдения

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

Предложение ориентировочного проекта сети

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

Большое предприятие располагает к строгому владению данными

Ведение учета данных именно там, где эти данные производятся – очень хорошая черта сети данных, и она мне по-настоящему нравится. В таком случае происходит децентрализация ответственности за данные, а учет их действительно ведется примерно там же, где они порождаются. Такое соотнесение полностью оправдано, поскольку именно те, кто производит данные, являются экспертами по этим данным. Они знают, как спроектированы эти системы, управление какими именно данными происходит внутри этих систем. Часто эксперты при работе плотно взаимодействуют с конечными пользователями и бизнес-аналитиками и, следовательно, знают, какое качество данных считается «хорошим» с точки зрения потребителя этих данных. Когда вы раздаете владение данными и обозначаете предметные области, рекомендую смотреть шире, чем просто на приложения и системы. Рассматривайте всю область применения и понимайте пространства тех бизнес-проблем, которые вы пытаетесь решить. Такой анализ распространяется на данные, процессы, организацию и технологии в рамках конкретного контекста, соотносится со стратегическими бизнес-целями и устремлениями вашей организации. Обрисовывая предметные области, добейтесь, чтобы их границы были явными и выраженными. Это очень важно, поскольку разные команды могут пытаться заявлять право владения одними и теми же приложениями и данными.

Продукт-ориентированные мышление в данном случае очень уместно

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

Почему к децентрализации относятся настороженно

Когда заходит речь о том, чтобы оснастить команды специалистов-предметников инженерными инструментами для решения задач по производству продуктов данных и владению платформой, предприятия идут на разные компромиссы. Не в каждой организации не найдется 500+ инженеров по работе с данными. Не все такие команды знакомы со сложными техниками моделирования данных, захватом изменяющихся данных, работой с Kubernetes и блокнотами Python. В компаниях предъявляются различные требования в зависимости от размера компании, бизнес-потребностей и имеющейся архитектуры.

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

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

Справочная модель с пониженной децентрализацией

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

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

Решение, позволяющее спроектировать такую архитектуру, могло бы выглядеть так:

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

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

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

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

Более высокая степень централизации, применяемая в данной модели, направлена на решение таких проблем как; 1) обход больших исторически накопленных наборов данных без необходимости переноса данных из одной предметной области в другую 2) возможность проверять степень логической связанности и взаимной согласованности данных 3) обеспечение большей эффективности при управлении ведущими данными 4) снижение издержек путем совместного использования вычислительных ресурсов сразу несколькими командами. В то же время, здесь применяется сразу несколько наилучших практик, связанных с сетью данных, например, представление о данных как о продукте, предметная ориентированность при владении данных, функция самообслуживания данных и правильное управление ими.

Заключение

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

• Обратите внимание, сейчас проходит Распродажа от издательства «Питер».