Tipo
Manufacturing Data Engine (MDE) te ayuda a transformar una clase de mensajes fuente en registros de un tipo específico a través del análisis.
Los tipos son entidades de configuración que representan el destino de la operación de análisis y describen un conjunto de registros similares de forma estructural y semántica con un nivel de detalle común que, de manera opcional, comparten un contexto de metadatos específico.
Por ejemplo, puedes crear tipos de "estado de la máquina" y "lecturas del sensor de vibración". El primer tipo se podría usar para modelar eventos de cambio de estado de la máquina, como "En ejecución", "Inactivo", "Mantenimiento programado" y "Mantenimiento no programado", mientras que el segundo se podría usar para modelar un flujo de lecturas numéricas del sensor de vibración.
MDE se entrega con un conjunto de tipos predeterminados, pero puedes crear otros nuevos. Los tipos se definen según las siguientes características:
- Nombre: Es el nombre del tipo.
- Arquetipo: Es el nombre del arquetipo en el que se basa un tipo. Un tipo en MDE siempre está asociado a exactamente un arquetipo.
- Especificaciones de almacenamiento: Es una lista de parámetros de configuración por receptor de datos. Las especificaciones de almacenamiento permiten configurar si los registros se escriben en un receptor de datos y proporcionan más parámetros de configuración específicos del receptor.
- Parámetros de configuración opcionales, incluidos los siguientes:
- El esquema JSON del campo data (solo se aplica a los tipos de arquetipos discretos y continuos).
- Asociaciones de bucket de metadatos: Es una lista de buckets de metadatos para los que los registros del tipo deben proporcionar referencias de instancias.
Tipos y receptores de datos
Los receptores de datos habilitados para un tipo procesan el flujo de registros de un tipo determinado. Los receptores de datos se pueden activar (habilitar o inhabilitar) para los tipos. Por ejemplo, los registros de un tipo se pueden configurar para que se escriban en BigQuery, pero no en Cloud Storage.
Receptores de datos admitidos
MDE admite los siguientes receptores de datos:
- BigQuery
- API de Bigtable/Federation
- Cloud Storage
- Pub/Sub (JSON y Protobuf)
Receptor de datos de BigQuery
Cuando se crea un tipo nuevo, MDE crea automáticamente una tabla de tipos correspondiente en BigQuery en el conjunto de datos mde_data.
Los registros de cada tipo se escriben en la tabla de tipo correspondiente.
Receptor de datos de Cloud Storage
Los registros se almacenan en un bucket de Cloud Storage llamado <project_id>-gcs-ingestion en archivos AVRO con particiones de Hive que usan una ventana de 10 minutos y 10 particiones por ventana. Los registros se agrupan en carpetas por tipo.
Receptor de datos de Pub/Sub
El receptor de Pub/Sub publica registros en un tema dedicado. El esquema de mensajes de Pub/Sub se describe en el esquema de mensajes del receptor de Pub/Sub.
Materialización de metadatos
Cada receptor de datos de un tipo se puede configurar para materializar metadatos en registros. Si este parámetro de configuración está habilitado, las referencias de instancias de metadatos se resuelven en objetos de instancias de metadatos, y los objetos se incluyen en los registros. La forma precisa en que se conservan o generan los metadatos depende del receptor de datos.
En BigQuery, por ejemplo, los metadatos materializados se escriben en materialized_metadata_field con el siguiente esquema:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "object",
"additionalProperties": {
"type": "object",
"description": "Metadata instance"
}
}
Arquetipos
Los arquetipos representan una superclase de tipos, y cada arquetipo está diseñado para proporcionar un modelo óptimo de procesamiento y almacenamiento de registros. Los arquetipos definen los campos obligatorios principales que deben estar presentes en un registro de un tipo determinado que emite un analizador. MDE se entrega con un conjunto de seis arquetipos estándar y agrupados definidos por el sistema, que se agrupan en tres familias de arquetipos:
- Series de datos numéricos (NDS)
- Serie de datos discretos (DDS)
- Series de datos continuos (CDS)
Un tipo en MDE siempre se asocia con exactamente un arquetipo, y el arquetipo de un tipo se define en el momento de la creación.
Puedes usar tipos para definir más restricciones en los registros .proto que emiten los analizadores más allá de las que imponen los arquetipos. Por ejemplo, puedes especificar la forma del campo data para un tipo o definir que los registros de un tipo deben contextualizarse con metadatos específicos.
En resumen, el esquema de registros .proto es una combinación de lo siguiente:
- Esquema de arquetipo
- Esquema de tipo
Familias de arquetipos
Cada familia de arquetipos contiene dos tipos de arquetipos:
- Estándar
- Agrupado
La versión 1.3 de MDE introduce el concepto de arquetipos agrupados, que amplían la funcionalidad de los arquetipos estándar. Los arquetipos agrupados proporcionan cuatro campos genéricos que se pueden completar con valores en el analizador. Cada receptor de datos usa estos cuatro campos para proporcionar capacidades adicionales de acceso a los datos y de consulta:
- BigQuery: Las tablas de tipo agrupado en clústeres de BigQuery se agrupan en clústeres según los cuatro campos genéricos en orden. Esto te permite filtrar datos en BigQuery de manera eficiente en los campos agrupados.
- API de Bigtable Federation: La API de Federation usó los campos agrupados en clústeres para construir claves de filas en Bigtable, lo que habilitó nuevos patrones de acceso a los datos.
- Pub/Sub: Los mensajes de Pub/Sub pasan los campos como campos de primer nivel en el mensaje de Pub/Sub.
Familia de arquetipos numéricos
La familia de arquetipos numéricos está diseñada para servir como base para los tipos que modelan una serie de mensajes numéricos con marca de fecha y hora, por ejemplo, un sensor de temperatura que emite un flujo de lecturas.
Las versiones estándar y agrupadas del arquetipo definen los siguientes esquemas de registros básicos:
Estándar
| Campo | Tipo de datos | Obligatorio |
|---|---|---|
tagName |
String | Sí |
value |
Numérico | Sí |
eventTimestamp |
Número entero (con formato de milisegundos de época) | Sí |
Agrupado
| Campo | Tipo de datos | Obligatorio |
|---|---|---|
tagName |
String | Sí |
value |
Numérico | Sí |
eventTimestamp |
Número entero (con formato de milisegundos de época) | Sí |
clustered_column_1 |
String | No |
clustered_column_2 |
String | No |
clustered_column_3 |
String | No |
clustered_column_4 |
String | No |
Familia de arquetipos discretos
La familia de arquetipos discretos está diseñada para servir como base para los tipos que modelan eventos con marca de tiempo, por ejemplo, un cambio de parámetro controlado por el operador en una máquina o un proceso específicos.
Las versiones estándar y agrupadas del arquetipo definen los siguientes esquemas de registros básicos:
Estándar
| Campo | Tipo de datos | Obligatorio |
|---|---|---|
tagName |
String | Sí |
data |
Objeto JSON | Sí |
eventTimestamp |
Número entero (con formato de milisegundos de época) | Sí |
Agrupado
| Campo | Tipo de datos | Obligatorio |
|---|---|---|
tagName |
String | Sí |
data |
Objeto JSON | Sí |
eventTimestamp |
Número entero (con formato de milisegundos de época) | Sí |
clustered_column_1 |
String | No |
clustered_column_2 |
String | No |
clustered_column_3 |
String | No |
clustered_column_4 |
String | No |
Familia de arquetipos continua
La familia de arquetipos continuos está diseñada para servir como base para los tipos que modelan series de estados consecutivos definidos por una marca de tiempo de inicio y finalización, por ejemplo, el estado operativo de una máquina durante un período continuo.
Las versiones estándar y agrupadas del arquetipo definen los siguientes esquemas de registros básicos:
Estándar
| Campo | Tipo de datos | Obligatorio |
|---|---|---|
tagName |
String | Sí |
data |
Objeto JSON | Sí |
eventTimestampStart |
Número entero (con formato de milisegundos de época) | Sí |
eventTimestampEnd |
Número entero (con formato de milisegundos de época) | Sí |
Agrupado
| Campo | Tipo de datos | Obligatorio |
|---|---|---|
tagName |
String | Sí |
data |
Objeto JSON | Sí |
eventTimestampStart |
Número entero (con formato de milisegundos de época) | Sí |
eventTimestampEnd |
Número entero (con formato de milisegundos de época) | Sí |
clustered_column_1 |
String | No |
clustered_column_2 |
String | No |
clustered_column_3 |
String | No |
clustered_column_4 |
String | No |
Campo de datos
Los arquetipos de series de datos discretos y series de datos continuos aceptan un esquema JSON para el campo data. Si se define un esquema JSON para el campo, en el tiempo de ejecución, se valida el valor del campo data que contiene un registro emitido por un analizador en función del esquema. Por ejemplo, imagina que defines el siguiente esquema para un tipo de serie temporal discreta:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "object",
"properties": {
"eventName": {
"type": "string"
}
},
"required": ["eventName"]
}
Con el esquema anterior para un tipo de serie temporal discreta, el siguiente registro (parcial) de ese tipo que emite un analizador no es válido:
{
"data": {
"complex": {
"machineName": "example"
}
}
}
Si falla la validación de datos, los registros se transfieren a la cola de mensajes no entregados. Los registros de la cola de mensajes no entregados se pueden procesar manualmente más adelante.
Buckets de metadatos
Los tipos pueden hacer referencia a buckets de metadatos. Una referencia de bucket de metadatos en un tipo define si los registros pueden o deben (según el valor del atributo required) proporcionar una referencia a una instancia de bucket de metadatos.
Las referencias a bucket de metadatos en un tipo definen el contrato de metadatos para los registros de ese tipo. Por ejemplo, puedes definir que todos los registros de un tipo deben contextualizarse con metadatos del dispositivo (proporciona una referencia a una instancia de metadatos en un bucket de metadatos llamado device).
Si un bucket de metadatos está asociado a un tipo y la marca required está establecida en true, los registros de ese tipo que emite un analizador y que no proporcionan una referencia a una instancia de bucket de metadatos se mueven a la cola de mensajes no entregados. Para obtener más información, consulta Cómo volver a procesar mensajes.
Control de versiones de tipos
Existen diferentes tipos de versiones, y en las siguientes secciones se describe cada uno.
Creación de una nueva versión de tipo
Puedes crear versiones nuevas para un tipo específico. Cada versión nueva puede especificar asociaciones de bucket de metadatos adicionales o modificar el esquema del campo de datos. Sin embargo, para garantizar la coherencia de los datos durante la vida útil de un tipo, las nuevas versiones de tipos solo pueden evolucionar hacia adelante y deben cumplir con las reglas de control de versiones. Las versiones nuevas de un tipo pueden realizar los siguientes cambios:
Mayo:
- Agrega campos opcionales nuevos al esquema de datos.
- Marcar un campo obligatorio como opcional en el esquema de datos
- Agrega nuevas referencias de bucket de metadatos.
No se puede:
- Quita campos del esquema de datos.
- Cambia el tipo de datos de los campos existentes en el esquema de datos.
- Marcar un atributo opcional como obligatorio en el esquema de datos
- Quita las referencias de bucket de metadatos.
Edición de la versión de tipo existente
Las especificaciones y transformaciones de almacenamiento se pueden actualizar en una versión de tipo existente sin necesidad de crear una versión de tipo nueva.
Edición de tipo
La mayoría de las operaciones en tipos requieren crear una versión de tipo nueva o editar una existente. La única operación que se puede realizar en el tipo, independientemente de su versión, es habilitarlo o inhabilitarlo. Cuando se inhabilita un tipo, todas las versiones de ese tipo dejan de aceptar datos.
Restricciones de nombres para los tipos
Un nombre de tipo puede contener lo siguiente:
- Letras (mayúsculas y minúsculas), números y los caracteres especiales
-y_ - Puede tener hasta 255 caracteres.
Puedes usar la siguiente expresión regular para la validación: ^[a-z][a-z0-9\\-_]{1,255}$.
Si intentas crear una entidad que incumpla las restricciones de nomenclatura, recibirás un 400 error.