¿Qué es un producto de datos?

Cada aplicación crea y almacena datos temporalmente o permanentemente. Muchas aplicaciones también crean y guardan datos con fines de administración operativa, como el registro de errores y la supervisión del estado. Para consumir y procesar los datos que producen estas aplicaciones, los equipos de datos centralizados usan procesos de extracción, transformación y carga (ETL). Los equipos de operaciones de aplicaciones suelen tener otros flujos de procesamiento de datos para datos como datos de estado de la aplicación y datos de supervisión del estado de KPI.

Para la integración de datos, un enfoque tradicional de cascada, en el que los equipos siguen un orden específico de fases, no es ideal. Puede provocar brechas de conocimiento, problemas de propiedad y conflictos de comunicación que afectan a la calidad, la puntualidad y el valor de los datos para los usuarios. Los equipos de aplicaciones son responsables del rendimiento y el éxito de la aplicación. Cuando usan un enfoque en cascada, realizan cambios en los procesos de bajada que poseen otros equipos. A veces, estos cambios pueden afectar a otras áreas. Por ejemplo, un cambio ascendente menor podría modificar drásticamente la tendencia de un KPI. Estos conflictos pueden afectar a la capacidad de tomar decisiones críticas.

Datos como producto

Para evitar estos problemas, el enfoque de malla de datos adopta el concepto de datos como producto. Los propietarios de aplicaciones y los equipos de aplicaciones tratan los datos como un producto totalmente contenido por el que son responsables, en lugar de un producto derivado del proceso de otro equipo. Las aplicaciones y las tareas de servicio de datos analíticos se encuentran dentro de las áreas de responsabilidad del dominio.

Los productos de datos se crean específicamente para el consumo analítico. Han definido y acordado formas, interfaces de consumo y ciclos de mantenimiento y actualización, todos ellos documentados.

Los productos de datos son activos de datos de dominio procesados o conjuntos de datos que puede compartir con procesos de bajada a través de interfaces en un objetivo de nivel de servicio. A menos que se requiera lo contrario, debe procesar, dar forma, limpiar, agregar y normalizar sus datos brutos para cumplir con los estándares de calidad acordados antes de ponerlos a disposición para su uso.

En las secciones siguientes se describen las características comunes de los productos de datos adecuados.

Características del producto de datos

Asegúrese de que los productos de datos son:

• Reconocible, comprensible y confiable. Para proporcionar detectabilidad y claridad, comparta y actualice información sobre cada producto de datos, sus datos, su significado, el formato de forma de sus datos y su ciclo de actualización. Comunicar los cambios de datos o cambios en la estructura a los consumidores finales de manera oportuna. Para garantizar la confiabilidad, las interfaces proporcionan compatibilidad con versiones anteriores garantizada por un periodo de tiempo limitado para las estructuras de productos de datos.

• Direccionable, accesible de forma nativa y segura. Para proporcionar direccionabilidad, cree procesos definidos para localizar y obtener acceso a cada producto de datos. Implemente medidas de seguridad para varios requisitos de acceso. Cambie su mentalidad de propiedad de dominio de datos de control de acceso a servicio de datos con precauciones de seguridad bien definidas. Las interfaces de acceso bien documentadas pueden variar en diferentes tecnologías. Las interfaces usadas habitualmente para los productos de datos accesibles de forma nativa incluyen API, usuarios de base de datos, tablas o vistas y archivos con derechos de acceso necesarios.

• Interoperable, veraz y valiosa. Para proporcionar interoperabilidad, asegúrese de que los datos siguen los estándares comunes definidos, como los valores que tienen el mismo nombre y tipo de datos. Por ejemplo, puede asignar un nombre a una columna que contenga datos de identificación del cliente CustomerID en cada producto de datos y sus datos siempre pueden ser un entero. Los productos de datos proporcionan valor a los clientes y puede usarlos como orígenes ascendentes para nuevos productos de datos en el mismo dominio o dominios diferentes. Pero no se puede llevar y copiar el mismo producto de datos en varios lugares. Cada producto de datos que procede de un producto de datos anterior debe proporcionar nuevo valor e información a los consumidores de nivel inferior. Los productos de datos también deben proporcionar datos veraces y precisos.

Use productos de datos bien diseñados y bien mantenidos y sus interfaces para ayudar a evitar la duplicación de datos y crear una única fuente nativa de verdad.

Recomendaciones de diseño de productos de datos

Para cumplir los requisitos de servicio de productos de datos, los equipos de dominio deben adquirir un nuevo conjunto de aptitudes y usar nuevas herramientas y plataformas.

Para desarrollar las aplicaciones de datos y producir u ofrecer productos de datos, dote completamente a los equipos de aplicaciones de dominio. Los equipos pueden usar un stack tecnológico conocido para crear productos de datos. También es posible que prefieran tener su propia instancia de Spark o motor de canalización. Las organizaciones más pequeñas y los dominios más pequeños de grandes organizaciones pueden desarrollar y ejecutar sus aplicaciones de datos en una plataforma compartida, como una instancia de Azure Data Factory o Azure Databricks ubicada centralmente.

Asegúrese de que los productos de datos tienen las características comunes que se describen en este artículo, que el repositorio de linaje refleja el linaje de la aplicación de datos y que rige la implementación y el acceso.

En el diagrama siguiente se muestra un diseño lógico de aplicación de datos de ejemplo en un dominio y una zona de aterrizaje.

Paso siguiente

• Consideraciones de diseño para plataformas de datos de autoservicio