Registros e metadados de modelos

Este guia descreve como modelar registros e metadados no Manufacturing Data Engine (MDE).

Os registros capturam fatos sobre o processo de fabricação, como leituras de sensores e eventos. Os metadados ajudam a contextualizar esses fatos e permitem que você os analise por atributos de metadados. Os metadados também servem como fonte de dados originais de entidades de manufatura.

Se você usa o pacote completo do MDE (MDE em combinação com o Manufacturing Connect (MC)), pule esta seção sobre modelagem de dados, já que o MDE oferece um pacote para você começar rapidamente. No entanto, vale a pena ler se você estiver integrando outras fontes de dados.

Recomendações gerais

Antes de começar a modelagem de metadados, você precisa entender o seguinte:

• As necessidades de consumo de dados dos usuários downstream. Isso inclui entender quais dados eles precisam e como planejam usá-los. Para isso, converse com os usuários downstream e pergunte sobre os objetivos, indicadores principais de performance (KPIs), casos de uso, requisitos de análise e padrões de qualidade de dados.
• As realidades dos dados de origem subjacentes. Isso inclui entender a qualidade dos dados, a estrutura e a linhagem deles. Para isso, converse com especialistas em sistemas de origem e faça um perfil de dados de alto nível.
• Os requisitos técnicos de integração de dados. Isso inclui entender quais interfaces de integração de dados o MDE precisa oferecer suporte e quais requisitos técnicos precisam ser observados, incluindo convenções de nomenclatura.

Confira algumas ações específicas que você pode realizar para entender as necessidades de consumo dos usuários downstream:

• Reúna-se com usuários downstream para entender os objetivos deles:
  • O que eles estão tentando alcançar com os dados?
  • Quais são os KPIs?
• Pergunte aos usuários downstream sobre os casos de uso deles:
  • Como eles planejam usar os dados?
  • Quais relatórios eles querem gerar?
  • Que análise eles querem fazer?
• Entenda os requisitos de análise dos usuários downstream:
  • Que tipo de dados eles precisam analisar?
  • Com que frequência eles precisam analisar os dados?
• Pergunte aos usuários downstream sobre os padrões de qualidade de dados deles:
  • Qual nível de qualidade de dados é aceitável para eles?
  • Quais etapas precisam ser seguidas para garantir que os dados atendam aos padrões?

Confira algumas ações específicas que você pode realizar para entender a realidade dos dados de origem:

• Reúna-se com especialistas do sistema de origem:
  • Qual é a qualidade dos dados nos sistemas de origem?
  • Qual é a estrutura dos dados?
  • O que é linhagem de dados?
• Faça uma criação de perfil de dados de alto nível:
  • Isso ajuda a identificar possíveis problemas com os dados, como valores ausentes, registros duplicados ou tipos de dados inválidos.

Modelagem de metadados

Ao modelar metadados, você enfrenta três questões principais:

1. Quais metadados devem ser tratados como incorporados e quais devem ser tratados como metadados da nuvem?
2. Para metadados da nuvem, quais buckets criar?
3. Qual deve ser o esquema para buckets de metadados da nuvem?

Como decidir entre metadados incorporados e na nuvem

O principal critério de decisão a ser aplicado ao decidir se algumas informações contextuais devem ser modeladas como metadados incorporados ou metadados da nuvem é a taxa de mudança.

Os metadados incorporados são mais adequados para metadados que mudam rapidamente. Isso inclui metadados como IDs de transação ou contadores de incremento automático.

Em contraste, os metadados da nuvem são mais adequados para metadados que mudam em um ritmo mais lento, por exemplo, metadados de recursos. O MDE rastreia o histórico de instâncias de metadados por bucket e grava esses metadados em coletores que oferecem suporte a eles, como o BigQuery. Isso permite analisar o histórico de instâncias de metadados por chave natural e também que ferramentas de business intelligence (BI), como o Looker, obtenham uma lista exclusiva de valores de atributos sem percorrer toda a tabela de registros.

Como modelar buckets de metadados da nuvem

Os intervalos representam algum domínio contextual. Por exemplo, uma implementação de modelos de hierarquia de recursos ISA-95 modela a hierarquia de recursos físicos de uma empresa de manufatura. Você precisa modelar os agrupamentos de metadados ao longo dos limites dos domínios contextuais. Por exemplo, é possível modelar o contexto do recurso (conforme expresso por uma implementação ISA-95) em um bucket asset e o status da máquina em um bucket machine-status.

Considere também se é necessário contextualizar uma tag ou um grupo arbitrário de registros.

Os buckets de tag devem ser escolhidos para metadados relacionados a tags, enquanto os de registro devem ser escolhidos para qualquer outro tipo de metadado.

Em geral, é recomendável modelar metadados hierárquicos de domínio no mesmo bucket. Por exemplo, embora os atributos da máquina a que a tag pertence (por exemplo, o fabricante de um sensor instalado na máquina) possam ser modelados em dois buckets separados (bucket de tag e bucket de máquina), geralmente é melhor modelar essas relações hierárquicas em um único bucket.

Um bom motivo para dividir uma hierarquia em várias dimensões separadas é permitir a associação de registros a metadados em diferentes níveis de granularidade. Por exemplo, se você estiver integrando duas fontes de dados diferentes, uma que envia dados com granularidade no nível do sensor e outra com granularidade no nível da máquina, separe os dados específicos da máquina em um bucket próprio.

Como configurar o esquema do bucket de metadados da nuvem

O esquema de um bucket determina a estrutura permitida de instâncias de metadados em um bucket. Os esquemas impulsionam a qualidade dos dados e permitem definir quais campos podem ou precisam ser usados para descrever uma entidade modelada por um determinado bucket. Os campos que você deve permitir ou exigir em um bucket dependem muito dos dados que suas fontes fornecem e da estratégia de vinculação de população e registros do bucket escolhida.

Se você optar por preencher os agrupamentos de metadados de forma dinâmica na borda, sua principal consideração ao definir um esquema será a disponibilidade de metadados nas mensagens de origem. Você também precisa considerar a conformidade dos dados e a facilidade de ingestão. Quanto mais específicos forem os esquemas de bucket de metadados e mais campos forem marcados como obrigatórios, mais consistentes serão as instâncias de metadados resultantes. No entanto, isso também aumenta as demandas do analisador para resolver quaisquer diferenças estruturais entre as mensagens.

Por outro lado, quanto mais genéricos forem os esquemas de agrupamento (por exemplo, especificar que uma propriedade de metadados pode ser qualquer "objeto" em vez de definir propriedades de objeto específicas), menores serão os requisitos de transformação e harmonização de metadados no analisador. No entanto, isso pode prejudicar a consistência e a conformidade dos metadados.

Outra consideração importante ao projetar um esquema de agrupamento é a granularidade do agrupamento. Se você estiver criando instâncias de metadados na API, verifique se a chave natural não é mais granular ou mais grosseira do que os dados que você espera receber da borda. Por exemplo, se você receber eventos de status da borda no nível da máquina, mas seu bucket de recursos tiver instâncias na granularidade do sensor, não será possível vincular registros a instâncias de metadados nesse bucket. Em vez disso, você precisa de um bucket que contenha instâncias com granularidade no nível da máquina.

Modelagem de registros

Ao modelar metadados, você precisa responder a duas perguntas principais:

1. Que tipos criar?
2. Como os tipos devem ser configurados?

Tipos de modelagem

Os tipos descrevem registros semanticamente e estruturalmente semelhantes que você quer armazenar juntos e descrever com um conjunto comum de metadados, e para os quais você quer estabelecer uma restrição comum no campo de dados.

Com isso em mente, os tipos precisam capturar registros no mesmo nível de granularidade (nível de detalhe). Normalmente, isso significa estruturar tipos em torno de algum processo de fabricação, operação ou conjunto de ações. Por exemplo, é possível criar um tipo para registros de "machine-state" e outro para "sensor-readings".

Também recomendamos manter os dados no nível mais atômico e evitar a pré-agregação antes de enviá-los ao MDE. Isso permite que você aproveite a maior flexibilidade de consulta, já que é possível criar qualquer agregação com dados atômicos.

Configurações de tipos

As principais considerações ao configurar tipos são as seguintes:

1. Quais intervalos de metadados devem descrever registros de um tipo? Eles são obrigatórios ou opcionais?
2. Qual deve ser o esquema do campo de dados?

Configuração de metadados para tipos

É possível associar versões de buckets de metadados a tipos. Associar uma versão de bucket a um tipo significa que os registros desse tipo podem ou precisam (dependendo do valor do campo required na associação) ser vinculados a instâncias de metadados da versão de bucket especificada durante a execução.

Decidir quais intervalos associar a um tipo e se a associação deve ser classificada como required depende de várias considerações. Considere os requisitos de contextualização dos seus consumidores de dados, o contexto que você recebe da borda, a qualidade dos dados e o acesso aos dados originais se as fontes de dados de borda não fornecerem o contexto necessário.

Definir a flag required em uma associação de bucket de metadados melhora a consistência dos dados. No entanto, também exige que você pense em como lidar com casos em que a borda não entrega metadados ou uma instância de metadados para uma chave natural ainda não foi criada. Nesses casos, você pode deixar o MDE rejeitar a mensagem e movê-la para uma fila de mensagens não entregues, ou criar uma instância de metadados Not Available genérica no bucket para vincular registros a ela se não for possível criar um link para uma instância contextualizada completa.

Configuração de campos de dados para tipos

Configurar o campo de dados em DISCRETE_DATA_SERIES e CONTINUOUS_DATA_SERIES permite ter uma estrutura de objeto consistente no campo de dados. Ao definir o campo de dados, crie um perfil dos dados de origem e verifique se os analisadores podem gerar registros proto que validam o esquema definido.