Что такое продукт данных?
Каждое приложение создает и сохраняет данные временно или постоянно. Многие приложения также создают и сохраняют данные для операционных целей управления, таких как ведение журнала ошибок и мониторинг работоспособности. Для использования и обработки данных, создаваемых этими приложениями, централизованные команды данных используют процессы извлечения, преобразования и загрузки (ETL). Команды операций приложений часто имеют другие потоки обработки данных для таких данных, как данные о работоспособности приложения и данные мониторинга состояния ключевого показателя эффективности.
Для интеграции данных традиционный каскадный подход, в котором команды следуют определенному порядку этапов, не идеально подходят. Это может привести к пробелам в знаниях, проблемам владения и конфликтам связи, которые влияют на качество, своевременность и ценность данных для пользователей. Команды приложений отвечают за производительность и успех приложения. При использовании каскадного подхода они вносят изменения в подчиненные процессы, принадлежащие другим командам. Иногда эти изменения могут повлиять на другие области. Например, незначительные изменения вышестоящего потока могут резко изменить тенденцию ключевого показателя эффективности. Эти конфликты могут повлиять на вашу способность принимать критические решения.
Данные как продукт
Чтобы предотвратить эти проблемы, подход сетки данных принимает концепцию данных в качестве продукта. Владельцы приложений и команды приложений рассматривают данные как полностью автономный продукт, за который они отвечают, а не за продукт процесса другой команды. Как приложения, так и аналитические задачи, обслуживающие данные, находятся в областях ответственности домена.
Продукты данных создаются специально для аналитического потребления. Они определили и согласовали фигуры, интерфейсы потребления и циклы обслуживания и обновления, все из которых документированы.
Продукты данных обрабатываются в ресурсах данных домена или наборах данных, которые можно совместно использовать с подчиненными процессами через интерфейсы в целевой цели уровня обслуживания. Если иное не требуется, следует обрабатывать, формировать, очищать, агрегировать и нормализовать необработанные данные, чтобы соответствовать согласованным стандартам качества, прежде чем сделать его доступным для использования.
В следующих разделах описаны общие характеристики хороших продуктов данных.
Характеристики продукта данных
Убедитесь, что ваши продукты данных:
Обнаруживаемые, понятные и надежные. Для обеспечения возможности обнаружения и ясности, совместного использования и обновления сведений о каждом продукте данных, его данных, его значении, формате фигуры данных и цикле обновления. Своевременное взаимодействие с изменениями данных или изменением фигуры для подчиненных потребителей. Чтобы обеспечить надежность, интерфейсы обеспечивают обратную совместимость с временем для фигур продуктов данных.
Адресная, собственная доступная и безопасная. Чтобы обеспечить адресность, создайте определенные процессы для поиска и получения доступа к каждому продукту данных. Реализуйте меры безопасности для различных требований к доступу. Переместите менталитет владельца домена данных с воротных данных на обслуживание данных с четко определенными мерами безопасности. Хорошо документированные интерфейсы доступа могут различаться в разных технологиях. Часто используемые интерфейсы для продуктов данных, доступных в собственном коде, включают API, пользователей базы данных, таблицы или представления и файлы с необходимыми правами доступа.
Взаимодействие, истинное и ценное. Чтобы обеспечить взаимодействие, убедитесь, что данные соответствуют определенным общим стандартам, таким как значения с одинаковым именем и типом данных. Например, можно назвать столбец, содержащий идентификатор клиента CustomerID в каждом продукте данных, и его данные всегда могут быть целым числом. Продукты данных предоставляют клиентам ценность, и их можно использовать в качестве источников вышестоящих данных для новых продуктов данных в одном домене или в разных доменах. Но вы не можете просто нести и копировать один и тот же продукт данных в нескольких местах. Каждый продукт данных, поступающий из предыдущего продукта данных, должен предоставлять новое значение и информацию для подчиненных потребителей. Продукты данных также должны предоставлять достоверные, точные данные.
Используйте хорошо разработанные, хорошо поддерживаемые продукты данных и их интерфейсы, чтобы избежать дублирования данных и создания собственного источника истины.
Рекомендации по проектированию продуктов данных
Чтобы выполнить требования к обслуживанию продуктов данных, ваши доменные команды должны получить новый набор навыков и использовать новые инструменты и платформы.
Чтобы создавать приложения данных и создавать или обслуживать продукты данных, полностью обустраивайте команды приложений домена. Ваши команды могут использовать знакомый стек технологий для создания продуктов данных. Кроме того, у них может быть собственный экземпляр Spark или подсистема конвейера. Например, большой домен, обслуживающий многие продукты данных, может обрабатывать и обслуживать продукты данных из собственного экземпляра Azure Synapse Analytics. Небольшие организации и небольшие домены крупных организаций могут разрабатывать и запускать свои приложения данных на общей платформе, например централизованно расположенные Фабрика данных Azure, Azure Synapse Analytics или экземпляр Azure Databricks.
Убедитесь, что ваши продукты данных имеют общие характеристики, описанные в этой статье, что репозиторий происхождения отражает происхождение приложения данных и управляет реализацией и доступом.
На следующей схеме показан пример логического макета приложения данных в домене и целевой зоне.
Руководство по продукту и приложению данных для Azure
Вы можете позиционировать подходы к среде приложения данных в целевых зонах данных Azure, если команды доменных приложений используют общую платформу и общий набор служб.
Шаблоны шаблонов приложений данных для целевых зон данных Azure см. в примерах приложений данных.