Compartir vía


¿Qué es un producto de datos?

Todas las aplicaciones crean y almacenan datos de forma temporal o permanente. Muchas aplicaciones también crean y guardan datos para la administración de operaciones, como el registro de errores y el seguimiento de estado. Para consumir y procesar los datos que producen estas aplicaciones, los equipos de datos centralizados utilizan 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 los de estado de las aplicaciones y los de supervisión del estado de los KPI.

Para la integración de datos, un enfoque tradicional en cascada en el que los equipos siguen un orden específico de las fases no es ideal. Puede dar lugar a lagunas 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 del correcto funcionamiento 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 pequeño cambio ascendente podría alterar drásticamente la tendencia de un KPI. Estos conflictos pueden afectar a su capacidad para 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 y equipos de aplicaciones tratan los datos como un producto completo del que son responsables, en lugar de como un subproducto del proceso de otro equipo. Tanto las aplicaciones como las tareas de servicio de datos analíticos se incluyen en las áreas de responsabilidad del dominio.

Los productos de datos se crean especialmente para el consumo analítico. Han determinado y acordado formas, interfaces de consumo, así como ciclos de actualización y mantenimiento, 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 los datos sin procesar para cumplir con los estándares de calidad acordados antes de ponerlos a disposición para su uso.

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

Características de los productos de datos

Asegúrese de que los productos de datos sean:

  • Detectables, comprensibles y confiables. Para proporcionar visibilidad 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. Comunique los cambios en los datos o en la forma a los consumidores intermedios de manera oportuna. Para garantizar la confiabilidad, las interfaces proporcionan compatibilidad con versiones anteriores limitadas en el tiempo para las formas de productos de datos.

  • Direccionables, accesibles de forma nativa y seguros. 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 según las diferentes tecnologías. Las interfaces de uso frecuente para productos de datos accesibles de forma nativa incluyen API, usuarios de base de datos, tablas o vistas y archivos con derechos de acceso obligatorios.

  • Interoperables, veraces y valiosos. 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 de cliente CustomerID en cada producto de datos, y sus datos siempre pueden ser un número entero. Los productos de datos proporcionan valor a los clientes y puede utilizarlos como fuentes ascendentes para nuevos productos de datos en el mismo dominio o en dominios diferentes. Pero no se puede llevar y copiar el mismo producto de datos en varios lugares. Cada producto de datos procedente de un producto de datos anterior debería aportar un valor nuevo e información a los consumidores de nivel inferior. Los productos de datos también deben proporcionar datos veraces y precisos.

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

Recomendaciones para el diseño de productos de datos

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

Para crear las aplicaciones de datos y producir o servir productos de datos, equipe completamente a sus equipos de aplicaciones de dominio. Sus equipos pueden usar una pila de tecnología conocida para crear productos de datos. También es posible que prefieran tener su propia instancia de Spark o motor de canalización. Por ejemplo, un dominio grande que atiende muchos productos de datos podría procesar y servir productos de datos desde su propia instancia de Azure Synapse Analytics. Las organizaciones más pequeñas y los dominios más pequeños de organizaciones grandes pueden desarrollar y ejecutar sus aplicaciones de datos en una plataforma compartida, como una instancia de Azure Data Factory, Azure Synapse Analytics o Azure Databricks ubicada centralmente.

Asegúrese de que los productos de datos tengan las características comunes que se describen en este artículo, que el repositorio de linaje refleje el linaje de la aplicación de datos y que controle 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.

Diagrama que muestra un posible diseño lógico de aplicación de datos en un dominio y una zona de aterrizaje.

Guía de aplicación de datos y productos de datos para Azure

Puede colocar enfoques para el entorno de aplicaciones de datos dentro de las zonas de aterrizaje de datos de Azure si los equipos de aplicaciones de dominio usan una plataforma compartida y un conjunto compartido de servicios.

Diagrama que muestra el grupo de recursos data-application-rg de Data Applications Context y el grupo de recursos shared-application-rg de Core Services Context.

Para obtener plantillas de patrón de aplicación de datos para zonas de aterrizaje de datos de Azure, consulte Aplicaciones de datos de ejemplo.

Paso siguiente