Record e metadati del modello

Questa guida descrive come modellare i record e i metadati in Manufacturing Data Engine (MDE).

I record acquisiscono fatti sul processo di produzione, come letture di sensori ed eventi, e i metadati aiutano a contestualizzare questi fatti e ti consentono di analizzarli in base agli attributi dei metadati. I metadati fungono anche da fonte dei dati originali delle entità di produzione.

Se utilizzi la suite MDE completa (MDE in combinazione con Manufacturing Connect (MC)), puoi saltare questa sezione sulla modellazione dei dati poiché MDE fornisce un pacchetto per iniziare rapidamente. Tuttavia, potrebbe valere la pena leggerlo se stai integrando altre origini dati.

Consigli generali

Prima di iniziare a modellare i metadati, devi comprendere quanto segue:

• Le esigenze di consumo dei dati degli utenti downstream. Ciò include la comprensione dei dati di cui hanno bisogno e di come intendono utilizzarli. Puoi farlo incontrando gli utenti downstream per chiedere informazioni su obiettivi, indicatori chiave di prestazione (KPI), casi d'uso, requisiti di analisi e standard di qualità dei dati.
• La realtà dei dati di origine sottostanti. Ciò include la comprensione della qualità dei dati, della struttura dei dati e della derivazione dei dati. Puoi farlo incontrando esperti del sistema di origine ed eseguendo la profilazione dei dati di alto livello.
• I requisiti di integrazione dei dati tecnici. Ciò include la comprensione delle interfacce di integrazione dei dati che MDE deve supportare e dei requisiti tecnici da rispettare, incluse le convenzioni di denominazione.

Di seguito sono riportate alcune azioni specifiche che puoi intraprendere per comprendere le esigenze di consumo degli utenti downstream:

• Incontra gli utenti downstream per comprendere i loro obiettivi:
  • Che cosa vogliono ottenere con i dati?
  • Quali sono i loro KPI?
• Chiedi agli utenti downstream i loro casi d'uso:
  • Come prevede di utilizzare i dati?
  • Quali report vogliono eseguire?
  • Quale analisi vogliono eseguire?
• Comprendere i requisiti di analisi degli utenti downstream:
  • Che tipo di dati devono analizzare?
  • Con quale frequenza devono analizzare i dati?
• Chiedi agli utenti downstream quali sono i loro standard di qualità dei dati:
  • Quale livello di qualità dei dati è accettabile per loro?
  • Quali passaggi devono essere eseguiti per garantire che i dati soddisfino i loro standard?

Ecco alcune cose specifiche che puoi fare per comprendere la realtà dei dati di origine sottostanti:

• Incontra gli esperti del sistema di origine:
  • Qual è la qualità dei dati nei sistemi di origine?
  • Qual è la struttura dei dati?
  • Che cos'è la derivazione dei dati?
• Esegui una profilazione dei dati di alto livello:
  • In questo modo potrai identificare eventuali problemi con i dati, ad esempio valori mancanti, record duplicati o tipi di dati non validi.

Modellazione dei metadati

Quando modelli i metadati, devi rispondere a tre domande chiave:

1. Quali metadati devono essere trattati come metadati incorporati e quali come metadati cloud?
2. Per i metadati cloud, quali bucket creare?
3. Quale deve essere lo schema per i bucket di metadati cloud?

Scegliere tra metadati incorporati e metadati cloud

Il criterio decisionale chiave da applicare per decidere se alcune informazioni contestuali debbano essere modellate come metadati incorporati o metadati cloud è la velocità di cambiamento.

I metadati incorporati sono più adatti a quelli che cambiano rapidamente. Ciò include metadati come ID transazione o contatori a incremento automatico.

Al contrario, i metadati cloud sono più adatti per i metadati che cambiano a un ritmo più lento, ad esempio i metadati delle risorse. MDE tiene traccia della cronologia delle istanze di metadati per bucket e scrive questi metadati nei sink che li supportano, come BigQuery. In questo modo puoi esplorare la cronologia delle istanze di metadati per chiave naturale e consentire a strumenti di business intelligence (BI) come Looker di ottenere un elenco univoco di valori degli attributi senza attraversare l'intera tabella dei record.

Modellazione dei bucket di metadati cloud

I bucket modellano alcuni domini contestuali. Ad esempio, un'implementazione dei modelli di gerarchia degli asset ISA-95 modella la gerarchia degli asset fisici di un'impresa manifatturiera. Devi modellare i bucket di metadati lungo i confini dei domini contestuali. Ad esempio, puoi modellare il contesto dell'asset (come espresso da un'implementazione ISA-95) in un bucket asset e lo stato della macchina in un bucket machine-status.

Devi anche valutare se è necessario contestualizzare un tag o un gruppo arbitrario di record.

I bucket dei tag devono essere scelti per i metadati correlati ai tag, mentre i bucket dei record devono essere scelti per qualsiasi altro tipo di metadati.

In genere è consigliabile modellare i metadati del dominio gerarchico nello stesso bucket. Ad esempio, mentre gli attributi della macchina a cui appartiene il tag (ad esempio, il produttore di un sensore installato nella macchina) potrebbero essere modellati in due bucket separati (bucket tag e bucket macchina), è in genere meglio modellare queste relazioni gerarchiche in un unico bucket.

Un buon motivo per dividere una gerarchia in diverse dimensioni separate è quello di consentire l'associazione di record a metadati con diversi livelli di granularità. Ad esempio, se stai integrando due origini dati diverse, una delle quali invia dati con granularità a livello di sensore e l'altra con granularità a livello di macchina, devi separare i dati specifici della macchina nel proprio bucket.

Configurazione dello schema del bucket dei metadati cloud

Lo schema di un bucket determina la struttura consentita delle istanze di metadati in un bucket. Gli schemi migliorano la qualità dei dati e consentono anche di definire quali campi possono o devono essere utilizzati per descrivere un'entità modellata da un determinato bucket. I campi che devi consentire o richiedere in un bucket dipendono in gran parte dai dati forniti dalle origini e dalla strategia di collegamento di bucket e record che scegli.

Se scegli di compilare dinamicamente i bucket di metadati dall'edge, la tua considerazione principale quando definisci uno schema deve essere la disponibilità dei metadati nei messaggi di origine. Devi anche valutare la conformità dei dati e la facilità di importazione. Più specifici sono gli schemi dei bucket di metadati e più campi sono contrassegnati come obbligatori, più coerenti saranno le istanze di metadati risultanti. Tuttavia, ciò aumenta anche le esigenze del parser per risolvere eventuali differenze strutturali tra i messaggi.

D'altra parte, più generici sono gli schemi dei bucket (ad esempio, specificando che una proprietà dei metadati può essere qualsiasi "oggetto" anziché definire proprietà specifiche dell'oggetto), minori sono i requisiti di trasformazione e armonizzazione dei metadati nel parser. Tuttavia, ciò potrebbe avvenire a scapito della coerenza e della conformità dei metadati.

Un'altra considerazione importante nella progettazione di uno schema bucket è la granularità del bucket. Se stai creando istanze di metadati tramite l'API, assicurati che la chiave naturale non sia più granulare o più grossolana dei dati che prevedi di ricevere dall'edge. Ad esempio, se ricevi eventi di stato dal periferico a livello di macchina, ma il bucket asset contiene istanze a granularità del sensore, non potrai collegare i record alle istanze di metadati in questo bucket. Al contrario, hai bisogno di un bucket che contenga istanze con granularità a livello di macchina.

Modellazione dei record

Quando modelli i metadati, devi rispondere a due domande chiave:

1. Quali tipi creare?
2. Come devono essere configurati i tipi?

Tipi di modellazione

I tipi descrivono record semanticamente e strutturalmente simili che vuoi archiviare insieme e descrivere con un insieme comune di metadati e per i quali vuoi stabilire un vincolo comune sul campo di dati.

Tenendo presente questo aspetto, i tipi devono acquisire i record allo stesso livello di granularità (livello di dettaglio). In genere, ciò significa strutturare i tipi in base a un processo di produzione, a un'operazione o a un insieme di azioni. Ad esempio, puoi creare un tipo per i record "machine-state" e un altro per "sensor-readings".

Consigliamo inoltre di rendere persistenti i dati al livello più atomico e di astenersi dall'aggregare i dati prima di inviarli a MDE. In questo modo puoi usufruire della massima flessibilità delle query, in quanto puoi creare qualsiasi aggregazione a partire da dati atomici.

Configurazioni dei tipi

Le considerazioni chiave durante la configurazione dei tipi sono le seguenti:

1. Quali bucket di metadati devono descrivere i record di un tipo? Sono obbligatori o facoltativi?
2. Quale deve essere lo schema del campo di dati?

Configurazione dei metadati per i tipi

Puoi associare le versioni del bucket di metadati ai tipi. L'associazione di una versione del bucket a un tipo implica che i record di quel tipo possono o devono (a seconda del valore del campo required nell'associazione) essere collegati a istanze di metadati della versione del bucket specificata in fase di runtime.

La decisione di quali bucket associare a un tipo e se l'associazione deve essere classificata come required dipende da diverse considerazioni. Devi tenere conto dei requisiti di contestualizzazione dei consumatori di dati, del contesto che ricevi dall'edge, della qualità dei dati e dell'accesso ai dati originali se le origini dati edge non forniscono il contesto richiesto.

L'impostazione del flag required in un'associazione di bucket di metadati migliorerà la coerenza dei dati. Tuttavia, ti richiede anche di pensare a come gestire i casi in cui l'edge non riesce a fornire i metadati o non è ancora stata creata un'istanza di metadati per una chiave naturale. In questi casi, puoi consentire a MDE di rifiutare il messaggio e spostarlo in una coda di messaggi non recapitabili oppure puoi creare un'istanza di metadati Not Available generica nel tuo bucket per collegare i record se non è possibile creare un link a un'istanza contestualizzata completa.

Configurazione dei campi di dati per i tipi

La configurazione del campo dati su DISCRETE_DATA_SERIES e CONTINUOUS_DATA_SERIES consente di ottenere una struttura coerente degli oggetti nel campo dati. Quando definisci il campo dati, devi profilare i dati di origine e assicurarti che i parser siano in grado di generare record proto che convalidano lo schema definito.