Контракты данных
Обязанности распределяются между доменами в федеративной архитектуре, что может затруднить надзор за зависимостями и получить аналитические сведения об использовании данных. Контракты данных помогают получить аналитические сведения об использовании данных, так как они предоставляют сведения о том, кто владеет каждым продуктом данных. Контракты данных помогают задавать стандарты и уверенно управлять конвейерами данных. Они необходимы для надежного управления данными, предоставляя сведения о:
- Какие продукты данных используются.
- Какие пользователи используют продукты данных.
- Какая цель ведет пользователей к использованию определенных продуктов данных.
Распределение и использование продуктов данных имеют два измерения: технические проблемы и бизнес-проблемы. Технические проблемы включают обработку конвейера данных и ожидания взаимной стабильности данных. Бизнес-проблемы включают соглашения о назначении общего доступа к данным, определяющие использование, конфиденциальность и цели назначения, включая любые ограничения.
Два измерения связаны с разными ролями. Как правило, следует полагаться на владельцев приложений или инженеров данных для технических проблем и владельцев продуктов или представителей бизнеса для бизнес-проблем.
Принципы контрактов данных
Контракты данных похожи на контракты служб или контракты доставки данных.
В более крупной или распределенной архитектуре может быть трудно контролировать изменения. Вы можете упростить надзор, реализуя управление версиями и управляя совместимостью всякий раз, когда у вас есть продукт данных, популярный и широко используемый.
Если приложения связаны, это означает высокую степень взаимозависимости между сопряженными приложениями. Приложения, которые получают доступ к данным или потребляют данные из других приложений, всегда страдают при сочетании. Любые изменения структуры данных, например, могут напрямую повлиять на другие приложения, которые обращаются к этим данным или потребляют эти данные. В ситуациях, когда у вас есть множество приложений, часто возникает каскадный эффект, когда небольшое изменение одного приложения влияет на многие другие приложения. Из-за повышенной вероятности непреднамеренных эффектов после даже незначительных изменений многие архитекторы и инженеры программного обеспечения избегают создания связанных архитектур.
Контракт данных гарантирует совместимость интерфейса и включает условия обслуживания и соглашение об уровне обслуживания (SLA). Условия обслуживания описывают, как можно использовать данные, например ограничить его использование только разработкой, тестированием или рабочей средой. Соглашения об уровне обслуживания описывают требуемое качество доставки и интерфейса данных. Сведения о качестве, которые можно указать в уровне обслуживания, включают:
- Время работы
- Частота ошибок
- Availability
- Устаревание
- Стратегия развития
- Номера версий
Вы можете поместить метаданные, которые записывают эти сведения в системе управления версиями, что позволяет автоматически запускать проверки и развертывания. Дополнительные сведения об управлении версиями см. в Фабрика данных Azure.
Контракты данных предоставляют представление о связи и зависимостях между доменами и приложениями. Контракт также позволяет тестировать контракты, что гарантирует, что все изменения приложения и интерфейса проверяются в соответствии с требованиями к данным потребителей. Вы можете определить, когда потоки данных становятся уязвимыми для изменений вышестоящего источника данных, обнаруживая смещение схемы. Дополнительные сведения см. в разделе Смещение схемы в потоке данных для сопоставления.
Контракты данных часто являются частью платформ приема метаданных. Контракты данных можно хранить в записях метаданных в централизованно управляемом хранилище метаданных. Из этой центральной точки контракты на данные играют важную роль в разных областях обработки данных, в том числе:
- Выполнение конвейера
- Создание продукта данных
- Проверка типа данных
- Схемы
- Стандарты взаимодействия
- Версии протокола
- Правила по умолчанию для отсутствующих данных
Контракты данных включают большое количество технических метаданных. Чтобы документировать конвейеры данных и продукты данных, необходимо четкое описание источников данных, все преобразования данных прошли и как вы в конечном итоге доставляете данные.
В распределенной архитектуре платформа конвейера данных распределяется по разным доменам, а домены соответствуют общему способу работы. Так как домены обрабатывают данные сами, контроль и ответственность остаются вместе с ними, в то время как платформа и метаданные остаются в центре управления.
При реализации федеративного метода запустите небольшое значение. Начните с основных принципов, таких как хранилище метаданных для проверки схемы, корпоративных идентификаторов и ссылок на другие наборы данных в общем репозитории метаданных. Добавьте поддержку происхождения данных, чтобы визуализировать перемещение данных. Инициируйте процессы и реализуйте меры контроля для проверки качества технических данных.
Все элементы управления должны быть частью процедур непрерывной интеграции. Захватить все сведения о среде выполнения, включая метрики и ведение журнала, и сделать такую информацию частью основы метаданных для получения аналитических сведений о стабильности конвейера данных. Эта настройка гарантирует наличие цикла обратной связи между доменами и кабиной центрального управления.
При стабилизации всего перемещения данных записываются атрибуты данных (например, таблицы и столбцы), в которых потребители данных используются и используют эту информацию для продолжения масштабирования. Эти сведения можно включить в централизованно управляемое хранилище метаданных. Сведения об использовании данных позволяют обнаруживать критические изменения и определять их влияние на производителей данных и потребителей. Если набор данных продукта данных не имеет потребителей, вы можете позволить ему столкнуться с разрушительными изменениями. Используйте управление версиями (например, Git), чтобы разрешить процесс подтверждения между поставщиками и потребителями данных.
Соглашения о совместном использовании данных
Соглашения о совместном доступе к данным — это расширение контрактов данных. Соглашения описывают использование данных, конфиденциальность и назначение, включая любые ограничения. Соглашения об обмене данными являются независимыми от интерфейса и предоставляют аналитические сведения о том, какие данные используются для определенной цели. Они также работают в качестве входных данных для элементов управления безопасностью данных. Вы можете использовать соглашение о совместном доступе к данным, чтобы определить, какие фильтры или средства защиты безопасности должны применяться к данным.
Соглашения о совместном доступе к данным также помогают предотвратить несогласие с использованием данных. Владельцы доменов должны обсуждать проблемы с общим доступом к данным и использованию данных перед предоставлением общего доступа к данным. Общее понимание имеет решающее значение для вашей способности регулировать данные и его использование и гарантировать, что вы можете обеспечить ценность для вашей организации. После того как все владельцы доменов достигают согласованного понимания, убедитесь, что они документируют его в соглашении о совместном использовании данных. В этом соглашении можно также обращаться к следующим областям:
- Качество функциональных данных
- Историзация
- Управление жизненным циклом данных
- Дальнейшее распределение данных
Применение классификаций и условий, таких как метки конфиденциальности или условия фильтрации для защиты данных.
На схеме предыдущего раздела показаны некоторые элементы, помеченные как боковая панель данных. Боковая машина данных — это компонент или слой для внедрения политик, таких как элементы управления доступом к данным или методы вывода данных. Это абстракция безопасности, которая использует контракты данных для обработки принудительного применения безопасности над данными домена. Вы можете создать боковик продукта данных из репозитория контрактов данных в виде списка управления доступом (ACL) или бессерверного представления или создать его с помощью дублированного набора данных, который вы выбираете и фильтруете для конкретного потребителя. В любом случае цель состоит в том, чтобы получать представления безопасности от контрактов данных полностью автоматически.
Подключите атрибуты контракта данных и документацию. Убедитесь, что вы предоставляете семантический контекст и связь с глоссарием, чтобы пользователи могли понять, как бизнес-требования преобразуются в фактическую реализацию. Если связь с бизнес-терминами важна для вашей организации, рассмотрите возможность реализации таких политик, как только разрешение на создание контрактов данных после того, как все атрибуты продукта данных связаны с бизнес-сущностями. Вы также можете применить этот тип политики к контекстным изменениям, таким как корректировки связи или определения.
Использование контрактов данных
Начинается медленно, когда начинается использование контрактов данных. Не вводите слишком много изменений одновременно; Контракты данных требуют культурной смены, и пользователям нужно время, чтобы ознакомиться с ними и понять важность владения данными. Кроме того, необходимо найти сладкую точку между слишком мало и слишком большим количеством атрибутов метаданных в контрактах данных.
Ниже описан процесс реализации контрактов данных для вашей организации.
- Убедитесь, что конвейеры технических данных стабильны. Варианты использования не могут достичь рабочей среды, если конвейеры, которые они перемещаются через непредвиденные нарушения.
- Поместите простые и прагматичные процессы, когда вы начинаете использовать соглашения об обмене данными. Начните с разработки простой формы или шаблона в Microsoft Forms. Напишите понятный, краткий язык, который читатели могут легко понять. Фокусом этого первого этапа является культурный сдвиг и сбор требований. Убедитесь, что вы не слишком усложняете вещи; примите ручные процессы, ограничьте начальные требования к метаданным и итерацию до тех пор, пока эти требования не будут стабильными.
- После создания первых процессов на месте начните заменять формы вручную веб-приложением, базой данных и /или очередью сообщений. Ваша центральная группа управления данными по-прежнему должна отвечать за надзор на этом этапе. Степень детализации доступа к данным на этом этапе обычно является грубой, фокусируясь на папках или файлах. По возможности используйте REST API для автоматической подготовки политик доступа к данным или списков управления доступом к данным.
- Поместите владельцев данных или руководителей данных, отвечающих за надежный рабочий процесс для управления утверждениями. Ваша основная роль в управлении данными теперь должна наблюдать за утверждениями из второстепенной роли и регулярно пересматривать все контракты данных. На этом этапе у вас должен быть каталог данных, например Microsoft Purview, который успешно запускается и отображает все ваши готовые к использованию продукты данных. Улучшайте возможности принудительного применения данных и безопасности, позволяя детально выбирать и фильтровать, а также использовать такие методы, как динамическое маскирование данных, чтобы предотвратить дублирование данных.
- На последнем этапе реализации контракта данных все должно быть самообслуживанием и полностью автоматизировано. Автоматическое машинное обучение должно прогнозировать утверждения данных. Безопасные представления, например, автоматически развертываются после утверждения.
Контракты данных являются относительно новым, но важным дополнением к архитектуре сетки данных, обеспечивая прозрачность использования данных и зависимостей. Сосредоточьтесь на технической стабильности и стандартизации, когда вы сначала начинаете использовать контракты данных, а затем итерируете процесс обучения на уроках. Медленно создавайте и автоматизируйте управление данными, чтобы не увеличивать затраты вашей организации.
В рамках документации по контракту данных также требуются условия обслуживания и соглашения об уровне обслуживания (SLA). Используйте соглашения об уровне обслуживания, чтобы определить требования к качеству доставки данных и интерфейсов, включая время простоя, частоту ошибок и доступность. Соглашения об уровне обслуживания также могут включать любые устаревшие требования, стратегии и номера версий, которые необходимо определить.