Что такое продукт данных?

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

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

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

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

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

В следующих разделах описаны общие характеристики хороших продуктов данных.

Характеристики продукта данных

Хорошо спроектированные продукты данных:

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

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

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

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

Рекомендации по проектированию продуктов данных

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

Полностью оснастите команды приложений предметной области для создания приложений для данных, а также для создания или обслуживания продуктов для работы с данными. Ваши команды могут создавать продукты данных с помощью знакомого технологического стека. Они также могут предпочесть собственный экземпляр Spark или подсистему конвейера, если это возможно. Например, крупный домен, который обслуживает множество продуктов данных, может решить обрабатывать и обслуживать продукты данных из собственного Azure Synapse Analytics. Небольшие организации и небольшие домены крупных предприятий могут решить разрабатывать и запускать свои приложения данных на общей платформе, такой как централизованно расположенные Фабрика данных Azure, Azure Synapse Analytics или Azure Databricks.

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

Схема, на которой показаны возможные логические схемы приложений данных в доменах и целевых зонах.

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

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

Схема: группа ресурсов data-application-rg из контекста приложений данных и группа ресурсов shared-application-rg из контекста основных служб.

Вы можете найти три разных шаблона приложений данных для целевых зон данных Azure в продуктах данных облачной аналитики в Azure — примеры приложений для работы с данными.

Дальнейшие действия