Рекомендации по проектированию для платформ данных самообслуживания

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

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

Аналитика в масштабах облака

Если вы хотите создать сетку данных с помощью Azure, рекомендуется внедрить облачную аналитику. Эта платформа является развертываемой эталонной архитектурой и поставляется с шаблонами с открытым исходным кодом и рекомендациями. Архитектура аналитики в масштабе облака имеет два основных стандартных блока, которые являются основными для всех вариантов развертывания:

• Целевая зона управления данными: основа архитектуры данных. Он содержит все критически важные возможности для управления данными, таких как каталог данных, происхождение данных, каталог API, управление главными данными и т. д.
• Целевые зоны данных: подписки, в которых размещаются решения аналитики и искусственного интеллекта. Они включают ключевые возможности для размещения платформы аналитики.

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

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

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

Одна целевая зона для данных

Самый простой шаблон развертывания для создания архитектуры сетки данных включает одну целевую зону управления данными и одну целевую зону. Архитектура данных в таком сценарии будет выглядеть следующим образом:

В этой модели все функциональные домены данных находятся в одной целевой зоне данных. Одна подписка содержит стандартный набор служб. Группы ресурсов отделяют разные домены данных и продукты данных. Стандартные службы данных, такие как Azure Data Lake Store, Azure Logic Apps и Azure Synapse Analytics, применяются ко всем доменам.

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

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

Выравнивание исходной системы и выравнивание целевых зон потребителей

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

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

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

Эти домены архитектуры соответствуют всем принципам сетки данных. Домены имеют права владения данными и могут напрямую распространять данные в другие домены.

Центры, универсальные и специальные целевые зоны данных

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

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

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

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

Функциональные и региональные целевые зоны данных

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

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

Дополнительные рекомендации и рекомендации можно найти в доменах данных.

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

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

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

Крупномасштабное предприятие, требующее различных зон управления данными

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

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

Заключение

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

Следующий шаг

• Платформа данных