Registros y metadatos del modelo
En esta guía, se describe cómo modelar registros y metadatos en Manufacturing Data Engine (MDE).
Los registros capturan hechos sobre el proceso de fabricación, como lecturas de sensores y eventos, y los metadatos ayudan a contextualizar esos hechos y te permiten "segmentarlos" por atributos de metadatos. Los metadatos también sirven como fuente de datos originales de las entidades de fabricación.
Si usas el paquete completo de MDE (MDE en combinación con Manufacturing Connect [MC]), puedes omitir esta sección sobre el modelado de datos, ya que MDE proporciona un paquete para que comiences rápidamente. Sin embargo, puede valer la pena leerlo si integras otras fuentes de datos.
Recomendaciones generales
Antes de comenzar con el modelado de metadatos, debes comprender lo siguiente:
- Las necesidades de consumo de datos de los usuarios posteriores Esto incluye comprender qué datos necesitan y cómo planean usarlos. Para ello, puedes reunirte con los usuarios posteriores y preguntarles sobre sus objetivos, indicadores clave de rendimiento (KPI), casos de uso, requisitos de análisis y estándares de calidad de los datos.
- Las realidades de los datos de origen subyacentes. Esto incluye comprender la calidad de los datos, su estructura y su linaje. Para ello, puedes reunirte con expertos en sistemas de origen y realizar un análisis de perfil de datos de alto nivel.
- Los requisitos técnicos de integración de datos Esto incluye comprender qué interfaces de integración de datos debe admitir el MDE y qué requisitos técnicos se deben observar, incluidas las convenciones de nomenclatura.
A continuación, se indican algunas acciones específicas que puedes realizar para comprender las necesidades de consumo de los usuarios posteriores:
- Reúnete con los usuarios posteriores para comprender sus objetivos:
- ¿Qué pretenden lograr con los datos?
- ¿Cuáles son sus KPIs?
- Pregunta a los usuarios de nivel inferior sobre sus casos de uso:
- ¿Cómo planean usar los datos?
- ¿Qué informes quieren ejecutar?
- ¿Qué análisis quieren realizar?
- Comprende los requisitos de análisis de los usuarios posteriores:
- ¿Qué tipo de datos necesitan analizar?
- ¿Con qué frecuencia necesitan analizar los datos?
- Pregunta a los usuarios posteriores sobre sus estándares de calidad de los datos:
- ¿Qué nivel de calidad de los datos es aceptable para ellos?
- ¿Qué pasos se deben seguir para garantizar que los datos cumplan con sus estándares?
Estas son algunas acciones específicas que puedes realizar para comprender las realidades de los datos fuente subyacentes:
- Reúnete con expertos en sistemas de origen:
- ¿Cuál es la calidad de los datos en los sistemas fuente?
- ¿Cuál es la estructura de los datos?
- ¿Qué es el linaje de datos?
- Realiza una creación de perfiles de datos de alto nivel:
- Esto te ayudará a identificar cualquier problema potencial con los datos, como valores faltantes, registros duplicados o tipos de datos no válidos.
Modelado de metadatos
Cuando modelas metadatos, debes responder tres preguntas clave:
- ¿Qué metadatos se deben tratar como metadatos incorporados y cuáles como metadatos de la nube?
- ¿Qué buckets se deben crear para los metadatos de la nube?
- ¿Cuál debería ser el esquema para los buckets de metadatos de Cloud?
Cómo decidir entre metadatos integrados y metadatos en la nube
El criterio de decisión clave que se debe aplicar cuando se decide si cierta información contextual se debe modelar como metadatos incorporados o metadatos de la nube es el ritmo de cambio.
Los metadatos incorporados son más adecuados para los metadatos que cambian rápidamente. Esto incluye metadatos, como IDs de transacción o contadores de incremento automático.
En cambio, los metadatos de la nube son más adecuados para los metadatos que cambian a un ritmo más lento, por ejemplo, los metadatos de activos. MDE hace un seguimiento del historial de instancias de metadatos por bucket y escribe esos metadatos en receptores que los admiten, como BigQuery. Esto te permite explorar el historial de instancias de metadatos por clave natural y, al mismo tiempo, permite que las herramientas de inteligencia empresarial (IE), como Looker, obtengan una lista única de valores de atributos sin recorrer toda la tabla de registros.
Modelado de buckets de metadatos de Cloud
Los buckets modelan algún dominio contextual. Por ejemplo, una implementación de la jerarquía de activos de ISA-95 modela la jerarquía de activos físicos de una empresa de fabricación. Debes modelar los buckets de metadatos a lo largo de los límites de los dominios contextuales. Por ejemplo, puedes modelar el contexto del activo (como se expresa en una implementación de ISA-95) en un bucket asset y el estado de la máquina en un bucket machine-status.
También debes considerar si necesitas contextualizar una etiqueta o cualquier grupo arbitrario de registros.
Los buckets de etiquetas se deben elegir para los metadatos relacionados con las etiquetas, mientras que los buckets de registros se deben elegir para cualquier otro tipo de metadatos.
Por lo general, se recomienda modelar los metadatos jerárquicos del dominio en el mismo bucket. Por ejemplo, si bien los atributos de la máquina a la que pertenece la etiqueta (por ejemplo, el fabricante de un sensor instalado en la máquina) se podrían modelar en dos buckets separados (bucket de etiquetas y bucket de máquinas), generalmente es mejor modelar esas relaciones jerárquicas en un solo bucket.
Una buena razón para dividir una jerarquía en varias dimensiones separadas es permitir la asociación de registros con metadatos en diferentes niveles de detalle. Por ejemplo, si integras dos fuentes de datos diferentes, una de las cuales envía datos con un nivel de detalle del sensor y otra con un nivel de detalle de la máquina, debes separar los datos específicos de la máquina en su propio bucket.
Configura el esquema del bucket de metadatos de la nube
El esquema de un bucket determina la estructura permitida de las instancias de metadatos en un bucket. Los esquemas impulsan la calidad de los datos y también te permiten definir qué campos se pueden o deben usar para describir una entidad que modela un bucket determinado. Los campos que debes permitir o requerir en un bucket dependen en gran medida de los datos que proporcionan tus fuentes y de la estrategia de vinculación de registros y población del bucket que elijas.
Si decides completar los buckets de metadatos de forma dinámica desde el borde, tu principal consideración al definir un esquema debe ser la disponibilidad de metadatos en los mensajes fuente. También debes tener en cuenta la conformidad de los datos y la facilidad de la transferencia. Cuanto más específicos sean los esquemas de bucket de metadatos y más campos se marquen como obligatorios, más coherentes serán las instancias de metadatos resultantes. Sin embargo, esto también aumenta las exigencias del analizador para resolver cualquier diferencia estructural entre los mensajes.
Por otro lado, cuanto más genéricos sean los esquemas de tu bucket (por ejemplo, especificar que una propiedad de metadatos puede ser cualquier "objeto" en lugar de definir propiedades de objeto específicas), menores serán los requisitos de transformación y armonización de metadatos en el analizador. Sin embargo, esto puede afectar la coherencia y la conformidad de los metadatos.
Otro aspecto importante que se debe tener en cuenta al diseñar un esquema de bucket es la granularidad de la bucket. Si creas instancias de metadatos a través de la API, asegúrate de que la clave natural no sea más detallada ni más general que los datos que esperas recibir del borde. Por ejemplo, si recibes eventos de estado desde el borde a nivel de la máquina, pero tu bucket de recursos contiene instancias con una granularidad de sensor, no podrás vincular registros a instancias de metadatos en este bucket. En cambio, necesitas un bucket que contenga instancias con una granularidad a nivel de la máquina.
Modelado de registros
Cuando modelas metadatos, debes responder dos preguntas clave:
- ¿Qué tipos de datos crear?
- ¿Cómo se deben configurar los tipos?
Tipos de modelado
Los tipos describen registros semántica y estructuralmente similares que deseas almacenar juntos y describir con un conjunto común de metadatos, y para los que deseas establecer una restricción común en el campo de datos.
Teniendo esto en cuenta, los tipos deben capturar registros con el mismo nivel de detalle. Por lo general, esto significa estructurar los tipos en torno a algún proceso de fabricación, operación o conjunto de acciones. Por ejemplo, puedes crear un tipo para los registros de "estado de la máquina" y otro para los de "lecturas del sensor".
También recomendamos conservar los datos en el nivel más atómico y abstenerse de agregarlos previamente antes de enviarlos al MDE. Esto te permite beneficiarte de la mayor flexibilidad de las consultas, ya que puedes crear cualquier agregado a partir de datos atómicos.
Configuraciones de tipos
Las consideraciones clave a la hora de configurar tipos son las siguientes:
- ¿Qué buckets de metadatos deberían describir los registros de un tipo? ¿Son obligatorios u opcionales?
- ¿Cuál debería ser el esquema del campo de datos?
Configuración de metadatos para tipos
Puedes asociar versiones de bucket de metadatos con tipos. Asociar una versión de bucket a un tipo implica que los registros de ese tipo pueden o deben (según el valor del campo required en la asociación) vincularse a instancias de metadatos de la versión de bucket determinada en el tiempo de ejecución.
Decidir qué buckets asociar a un tipo y si la asociación debe clasificarse como required depende de varias consideraciones. Debes tener en cuenta los requisitos de contextualización de tus consumidores de datos, el contexto que recibes del borde, la calidad de los datos y el acceso a los datos originales si las fuentes de datos perimetrales no proporcionan el contexto requerido.
Establecer la marca required en una asociación de bucket de metadatos mejorará la coherencia de tus datos. Sin embargo, también requiere que pienses cómo controlar los casos en los que el borde no entrega metadatos o aún no se creó una instancia de metadatos para una clave natural. En esos casos, puedes permitir que el MDE rechace el mensaje y lo mueva a una cola de mensajes no entregados, o bien puedes crear una instancia de metadatos Not Available genérica en tu bucket para vincular registros a ella si no se puede crear un vínculo a una instancia contextualizada completa.
Configuración de campos de datos para tipos
Configurar el campo de datos en DISCRETE_DATA_SERIES y CONTINUOUS_DATA_SERIES te permite obtener una estructura de objeto coherente en el campo de datos. Cuando definas el campo de datos, debes perfilar tus datos de origen y asegurarte de que los analizadores puedan generar registros .proto que se validen según el esquema definido.