Сценарий финансового учреждения для сетки данных
Этот сценарий предназначен для клиентов, которые хотят использовать облачную аналитику для масштабируемости и архитектуры сетки данных. Он демонстрирует сложный сценарий с посадочными площадками, интеграцией данных и продуктами данных.
Профиль клиента
Вымышленное предприятие, Woodgrove Bank, является крупной компанией финансовых услуг с мировым присутствием. Данные Банка Woodgrove размещаются в локальных и облачных системах развертывания. В архитектуре Банка Woodgrove существует несколько систем хранилища данных для консолидированной маркетинговой и интегрированной отчетности. Эта архитектура включает несколько озер данных для незапланированной аналитики и обнаружения данных. Приложения Woodgrove Bank связаны между собой с помощью шаблонов интеграции приложений, которые в основном основаны на API или на основе событий.
Текущая ситуация
Это сложно для Woodgrove Bank распространять данные в разные места из-за сложности хранения данных. Интеграция новых данных занимает много времени, и это заманчиво дублировать данные. Woodgrove Bank считает, что трудно контролировать комплексный ландшафт данных из-за подключения типа "точка — точка". Банк недооценили спрос на интенсивное потребление данных. Новые варианты использования вводятся быстро, один за другим. Управление данными, например владение данными и качество, и затраты трудно контролировать. Соблюдение актуальных нормативов сложно, потому что Woodgrove Bank точно не знает, где находятся его данные.
Решение архитектуры: сетка данных
За последние несколько лет организации признают, что данные лежат в основе всего. Данные открывают новые возможности для повышения эффективности, стимулируют инновации, открывают новые бизнес-модели и увеличивают удовлетворенность клиентов. Это главный приоритет для компаний, которые используют методы, управляемые данными, например, анализ больших данных.
Достичь стадии, когда более глубокое значение данных доступно всем членам организации является сложной задачей. Устаревшие и тесно взаимосвязанные системы, централизованные монолитные платформы и комплексное управление могут быть значительными барьерами для создания ценности из данных.
Сведения о сетке данных
Концепция сетки данных, термин, примечаемый Zhamak Dehghani, охватывает данные, технологии, процессы и организацию. Концептуально это доступный подход к управлению данными, в которых различные домены используют собственные данные. Сетка данных оспаривает идею обычной централизации данных. Вместо того, чтобы рассматривать данные как один огромный репозиторий, сетка данных рассматривает декомпозицию независимых продуктов данных. Этот переход от централизованной к федеративной собственности поддерживается современной платформой данных самообслуживания, обычно разработанной с использованием облачных технологий.
При разбиении концепции сетки данных на составные блоки, рассмотрим некоторые ключевые моменты.
- Данные как продукт: Каждый организационный домен управляет своими данными от начала до конца. Подотчетность лежит у владельца данных в домене. Конвейеры становятся первоклассной проблемой самих доменов.
- федеративное управление вычислительными данными. Чтобы гарантировать, что каждый владелец данных может доверять другим и предоставлять общий доступ к своим продуктам данных, необходимо установить корпоративный орган управления данными. Орган управления реализует качество данных, центральную видимость владения данными, управление доступом к данным и политики конфиденциальности данных.
- Domain-Oriented владение данными: предприятие оптимально должно определять и моделировать каждый узел домена данных в сетевой структуре, применяя принципы дизайна, ориентированного на домены.
- Self-Serve платформа данных: Сеточная архитектура данных требует платформы данных с самообслуживанием, которая позволяет пользователям устранить технические сложности и сосредоточиться на своих индивидуальных вариантах использования данных.
Cloud-Scale Аналитика
Мышление типа 'данные как продукт' и модель платформы самообслуживания не новы для Microsoft. Корпорация Майкрософт следовала передовым практикам в области распределённых платформ, потоков данных между доменами, федеративной собственности и самодокументируемых данных на протяжении многих лет.
Woodgrove Bank может перейти на архитектуру Data Mesh, используя масштабируемую облачную аналитику. Аналитика в масштабе облака — это схема с открытым исходным кодом и предписательная схема для разработки и быстрого развертывания современных платформ данных. Он связан с рекомендациями Azure и принципами проектирования и соответствует Azure Well-Architected Framework. Аналитика в масштабе облака дает предприятиям 80 процентов предписанного представления, а остальные 20 процентов настраиваются.
Аналитика в масштабе облака предлагает предприятиям стратегический путь проектирования к сетке данных, и его можно использовать для быстрого настройки такой архитектуры. Он предлагает схему, включая основные службы платформы данных для управления данными.
На самом высоком уровне аналитика на уровне облака использует возможность управления данными, которая реализована через зону управления данными. Эта область отвечает за федеративное управление данными на платформе самообслуживания организации, а также за домены данных, которые формируют бизнес-ценность посредством продуктов данных. Преимуществом этого подхода является удаление технической сложности при соблюдении тех же стандартов. Это гарантирует отсутствие распространения технологий. Это также позволяет предприятиям начинать с модульного подхода и минимальными ресурсами, а затем расширяться со временем.
Зона управления данными, как видно на схеме ниже, окружает все области данных. Он объединяет все домены и обеспечивает тот уровень надзора, который требуется компании Woodgrove Bank.
Аналитика в масштабе облака также выступает за применение согласованного управления, которое использует общую архитектуру при распределении продуктов данных. Платформа обеспечивает прямую связь между доменами. Он остается под контролем, уделяя особое внимание централизованному каталогизации и классификации для защиты данных и предоставления группам возможности обнаружения данных. Он помещает зонтик на вершину вашего объекта данных.
Домены данных
При использовании облачной аналитики в качестве стратегического пути необходимо учитывать декомпозицию архитектуры и результирующей детализации. Сетка данных разлагает данные, не следуя границам технологий. Вместо этого он применяет принципы разработки на основе домена (DDD), подход к разработке программного обеспечения, который включает сложные системы для крупных организаций. DDD популярен из-за его влияния на современные методики разработки программного обеспечения и приложений, такие как микрослужбы.
Один из шаблонов из архитектуры на основе домена называется ограничивающим контекстом. Ограниченные контексты задают логические границы пространства решения домена, чтобы лучше управлять сложностью. Важно, чтобы команды понимали, какие аспекты, включая данные, они могут изменить, а какие являются общими зависимостями, требующими координации с другими. Сетка данных охватывает ограниченный контекст. Этот шаблон используется для описания того, как организации могут координировать домены данных и сосредоточиться на доставке данных в качестве продукта. Каждый домен данных владеет и управляет несколькими продуктами данных с собственным стеком технологий, который не зависит от других.
Продукты данных
При детальном рассмотрении внутренней архитектуры такого домена данных ожидается обнаружение в нем продуктов данных.
Продукты данных соответствуют определенной потребности в компаниях, использующих данные. Продукты данных управляют, упорядочивают и понимают данные в разных доменах, а затем представляют полученные им аналитические сведения. Продукт данных является результатом данных из одной или нескольких интеграций данных или других продуктов данных. Продукты данных тесно соответствуют доменам данных и наследуют тот же созданный, формализованный язык, согласованный заинтересованными лицами и конструкторами. Каждый домен, который создает данные, отвечает за предоставление этих продуктов данных другим доменам.
Чтобы быстро доставлять продукты данных, облачная аналитика предлагает шаблоны для распределения данных и шаблонов интеграции. Платформа предоставляет пакет данных, потоковую передачу и аналитику для решения потребностей различных потребителей.
Одним из замечательных моментов в облачной аналитике является то, как организованы домены и продукты данных. Каждый домен данных соответствует одной целевой зоне данных, которая представляет собой логическую конструкцию и единицу масштабирования в архитектуре облачной аналитики. Она позволяет сохранять данные и выполнять вычислительные задачи, которые приносят аналитические данные и ценность. Каждый продукт данных соответствует одной группе ресурсов в целевой зоне данных, а все целевые зоны и зоны управления данными соответствуют подпискам. Такой подход упрощает реализацию и управление.
Все шаблоны аналитики в масштабе облака наследуют тот же набор политик из посадочной зоны управления данными. Шаблоны автоматически предоставляют необходимые метаданные для обнаружения данных, управления, безопасности, управления затратами и повышения эффективности работы. Вы можете быстро подключить новые домены данных без необходимости сложного подключения, интеграции и тестирования.
На следующей схеме показано, как может выглядеть продукт данных:
Прагматичный подход к созданию продуктов из данных состоит в ориентации либо на источник, откуда данные происходят, либо на сценарий использования. В обоих случаях необходимо предоставить абстрактное представление базовой (сложной) модели данных приложения. Необходимо попытаться скрыть технические сведения и оптимизировать для интенсивного потребления данных. Представление Azure Synapse или файл Parquet, который логически группирует данные вместе, является примером совместного использования продукта данных в различных доменах данных.
Затем необходимо работать с возможностью обнаружения, происхождением, использованием и родословной данных. Проверенный подход — использовать службу управления данными, например Microsoft Purview, для регистрации всех данных. Интеграция данных в облачной аналитике идеально увязывает все воедино, позволяя создавать продукты данных, одновременно регистрируя метаданные.
Выравнивая домены данных и коллекции Microsoft Purview, вы автоматически записываете все источники данных, происхождение, сведения о качестве данных и сведения о потреблении из отдельных доменов. С помощью этого подхода можно подключить несколько доменов данных и продуктов к централизованному решению управления, в котором хранятся все метаданные из каждой среды. Преимущество заключается в том, что он централизованно интегрирует все метаданные и делает его легко доступным для различных потребителей. Эту архитектуру можно расширить для регистрации новых продуктов данных.
На следующей схеме показана архитектура сетки данных между доменами, использующая облачную аналитику.
Сетевая конструкция позволяет предоставлять доступ к продуктам данных между доменами с помощью минимальной стоимости и устранения единой точки сбоев и ограничений пропускной способности. Чтобы обеспечить безопасность, можно использовать модель безопасности безопасности Microsoft
С помощью управляемых удостоверений можно убедиться, что используется модель доступа к наименьшим привилегиям. Приложения и службы в этой модели имеют ограниченный доступ к продуктам данных. С помощью политик Azure и скоро вводимых политик данных обеспечивается самообслуживание и соблюдение требований к ресурсам во всех продуктах данных в широких масштабах. С помощью этой структуры вы можете иметь универсальный доступ к данным при полном контроле с помощью централизованного управления данными и аудита.
Эволюция в будущее
Аналитика в масштабе облака разработана с учетом сетки данных. Аналитика в масштабе облака обеспечивает проверенный подход, с помощью которого организации могут совместно использовать данные во многих доменах данных. Эта структура позволяет доменам иметь автономию для принятия решений и управляет архитектурой, защищая её с помощью служб управления данными.
При реализации сетки данных логически группируйте и упорядочивайте домены. Такой подход требует корпоративного представления и, скорее всего, является культурным сдвигом для вашей организации. Это смещение требует федерализацию владения данными между доменами данных и владельцами, которые несут ответственность за предоставление своих данных в качестве продуктов. Кроме того, команды должны следовать централизованным возможностям, предлагаемым зоной управления данными. Этот новый подход может потребовать от отдельных команд отказаться от своих нынешних мандатов, которые, скорее всего, будут генерировать сопротивление. Возможно, вам придется сделать определенный политический выбор и найти баланс между централизованным и децентрализованным подходами.
Вы можете масштабировать архитектуру сетки данных, добавив в архитектуру дополнительные целевые зоны для отдельных доменов. Эти зоны приземления используют виртуальный пиринг для подключения к зоне приземления управления данными и всем другим зонам приземления. Этот шаблон позволяет совместно использовать продукты данных и ресурсы между зонами. При разделении на отдельные зоны можно распределять рабочие нагрузки между подписками и ресурсами Azure. Такой подход позволяет органично реализовать сетку данных.
Подробнее
Ресурсы Майкрософт:
- шаблона целевой зоны управления данными
- шаблон целевой зоны данных
Статья основателя сетки данных Замака Дехгани: