Поделиться через


Контракты данных

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

  • Какие продукты данных используются.
  • Какие пользователи используют продукты данных.
  • Какая цель ведет пользователей к использованию определенных продуктов данных.

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

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

Принципы контрактов данных

Контракты данных похожи на контракты служб или контракты доставки данных.

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

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

Контракт данных гарантирует совместимость интерфейса и включает условия обслуживания и соглашение об уровне обслуживания (SLA). Условия обслуживания описывают, как можно использовать данные, например ограничить его использование только разработкой, тестированием или рабочей средой. Соглашения об уровне обслуживания описывают требуемое качество доставки и интерфейса данных. Сведения о качестве, которые можно указать в уровне обслуживания, включают:

  • Время работы
  • Частота ошибок
  • Availability
  • Устаревание
  • Стратегия развития
  • Номера версий

Вы можете поместить метаданные, которые записывают эти сведения в системе управления версиями, что позволяет автоматически запускать проверки и развертывания. Дополнительные сведения об управлении версиями см. в Фабрика данных Azure.

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

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

  • Выполнение конвейера
  • Создание продукта данных
  • Проверка типа данных
  • Схемы
  • Стандарты взаимодействия
  • Версии протокола
  • Правила по умолчанию для отсутствующих данных

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

Схема с контрактами данных.

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

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

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

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

Соглашения о совместном использовании данных

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

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

  • Качество функциональных данных
  • Историзация
  • Управление жизненным циклом данных
  • Дальнейшее распределение данных

Применение классификаций и условий, таких как метки конфиденциальности или условия фильтрации для защиты данных.

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

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

Использование контрактов данных

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

Ниже описан процесс реализации контрактов данных для вашей организации.

  1. Убедитесь, что конвейеры технических данных стабильны. Варианты использования не могут достичь рабочей среды, если конвейеры, которые они перемещаются через непредвиденные нарушения.
  2. Поместите простые и прагматичные процессы, когда вы начинаете использовать соглашения об обмене данными. Начните с разработки простой формы или шаблона в Microsoft Forms. Напишите понятный, краткий язык, который читатели могут легко понять. Фокусом этого первого этапа является культурный сдвиг и сбор требований. Убедитесь, что вы не слишком усложняете вещи; примите ручные процессы, ограничьте начальные требования к метаданным и итерацию до тех пор, пока эти требования не будут стабильными.
  3. После создания первых процессов на месте начните заменять формы вручную веб-приложением, базой данных и /или очередью сообщений. Ваша центральная группа управления данными по-прежнему должна отвечать за надзор на этом этапе. Степень детализации доступа к данным на этом этапе обычно является грубой, фокусируясь на папках или файлах. По возможности используйте REST API для автоматической подготовки политик доступа к данным или списков управления доступом к данным.
  4. Поместите владельцев данных или руководителей данных, отвечающих за надежный рабочий процесс для управления утверждениями. Ваша основная роль в управлении данными теперь должна наблюдать за утверждениями из второстепенной роли и регулярно пересматривать все контракты данных. На этом этапе у вас должен быть каталог данных, например Microsoft Purview, который успешно запускается и отображает все ваши готовые к использованию продукты данных. Улучшайте возможности принудительного применения данных и безопасности, позволяя детально выбирать и фильтровать, а также использовать такие методы, как динамическое маскирование данных, чтобы предотвратить дублирование данных.
  5. На последнем этапе реализации контракта данных все должно быть самообслуживанием и полностью автоматизировано. Автоматическое машинное обучение должно прогнозировать утверждения данных. Безопасные представления, например, автоматически развертываются после утверждения.

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

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

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