Rekaman dan metadata model

Panduan ini menjelaskan cara memodelkan data dan metadata di Manufacturing Data Engine (MDE).

Catatan merekam fakta tentang proses manufaktur, seperti pembacaan sensor dan peristiwa, serta metadata membantu mengontekstualisasikan fakta tersebut dan memungkinkan Anda 'mengelompokkan' fakta tersebut menurut atribut metadata. Metadata juga berfungsi sebagai sumber data asli entitas manufaktur.

Jika Anda menggunakan rangkaian MDE lengkap (MDE bersama dengan Manufacturing Connect (MC)), Anda dapat melewati bagian tentang pemodelan data ini karena MDE menyediakan paket untuk membantu Anda memulai dengan cepat. Namun, ada baiknya Anda membacanya jika Anda mengintegrasikan sumber data lain.

Rekomendasi umum

Sebelum memulai pemodelan metadata, Anda harus memahami hal berikut:

  • Kebutuhan konsumsi data pengguna hilir. Hal ini mencakup pemahaman tentang data yang mereka butuhkan dan cara mereka berencana menggunakannya. Anda dapat melakukannya dengan bertemu dengan pengguna hilir untuk menanyakan tujuan, indikator performa utama (KPI), kasus penggunaan, persyaratan analisis, dan standar kualitas data mereka.
  • Realitas data sumber pokok. Hal ini mencakup pemahaman tentang kualitas data, struktur data, dan silsilah data. Anda dapat melakukannya dengan bertemu dengan pakar sistem sumber dan melakukan pembuatan profil data tingkat tinggi.
  • Persyaratan integrasi data teknis. Hal ini mencakup pemahaman tentang antarmuka integrasi data yang perlu didukung MDE dan persyaratan teknis yang harus dipatuhi, termasuk konvensi penamaan.

Berikut beberapa hal spesifik yang dapat Anda lakukan untuk memahami kebutuhan konsumsi pengguna hilir:

  • Bertemu dengan pengguna hilir untuk memahami tujuan mereka:
    • Apa yang ingin mereka capai dengan data tersebut?
    • Apa KPI mereka?
  • Tanyakan kasus penggunaan kepada pengguna hilir:
    • Bagaimana rencana mereka menggunakan data tersebut?
    • Laporan apa yang ingin mereka jalankan?
    • Analisis apa yang ingin mereka lakukan?
  • Memahami persyaratan analisis pengguna hilir:
    • Jenis data apa yang perlu mereka analisis?
    • Seberapa sering mereka perlu menganalisis data?
  • Tanyakan kepada pengguna hilir tentang standar kualitas data mereka:
    • Tingkat kualitas data apa yang dapat diterima oleh mereka?
    • Langkah apa yang perlu dilakukan untuk memastikan bahwa data memenuhi standar mereka?

Berikut beberapa hal spesifik yang dapat Anda lakukan untuk memahami realitas data sumber pokok:

  • Bertemu dengan pakar sistem sumber:
    • Bagaimana kualitas data dalam sistem sumber?
    • Apa struktur datanya?
    • Apa yang dimaksud dengan silsilah data?
  • Lakukan pembuatan profil data tingkat tinggi:
    • Hal ini akan membantu Anda mengidentifikasi potensi masalah pada data, seperti nilai yang tidak ada, data duplikat, atau jenis data yang tidak valid.

Pemodelan metadata

Saat memodelkan metadata, Anda akan menghadapi tiga pertanyaan utama:

  1. Metadata apa yang harus diperlakukan sebagai metadata sematan dan metadata apa yang harus diperlakukan sebagai metadata cloud?
  2. Untuk metadata cloud, bucket apa yang harus dibuat?
  3. Apa yang harus menjadi skema untuk bucket metadata cloud?

Memutuskan antara metadata tersemat dan metadata cloud

Kriteria keputusan utama yang harus diterapkan saat memutuskan apakah beberapa informasi kontekstual harus dimodelkan sebagai metadata tersemat atau metadata cloud adalah kecepatan perubahan.

Metadata sematan paling cocok untuk metadata yang berubah dengan cepat. Hal ini mencakup metadata seperti ID transaksi atau penghitung yang di-increment otomatis.

Sebaliknya, metadata cloud paling baik digunakan untuk metadata yang berubah lebih lambat, misalnya, metadata aset. MDE melacak histori instance metadata per bucket dan menulis metadata tersebut ke tujuan yang mendukungnya, seperti BigQuery. Dengan begitu, Anda dapat menjelajahi histori instance metadata per kunci alami, sekaligus memungkinkan alat business intelligence (BI) seperti Looker mendapatkan daftar unik nilai atribut tanpa menjelajahi seluruh tabel rekaman.

Membuat model bucket metadata cloud

Bucket memodelkan beberapa domain kontekstual. Misalnya, penerapan model hierarki aset ISA-95 memodelkan hierarki aset fisik perusahaan manufaktur. Anda harus memodelkan bucket metadata di sepanjang batas domain kontekstual. Misalnya, Anda dapat memodelkan konteks aset (seperti yang dinyatakan oleh penerapan ISA-95) di bucket asset dan status mesin di bucket machine-status.

Anda juga harus mempertimbangkan apakah Anda perlu memberikan konteks pada tag atau grup rekaman arbitrer.

Kelompok tag harus dipilih untuk metadata terkait tag, sedangkan kelompok data harus dipilih untuk jenis metadata lainnya.

Sebaiknya modelkan metadata domain hierarkis dalam bucket yang sama. Misalnya, meskipun atribut mesin yang memiliki tag tersebut (misalnya, produsen sensor yang terpasang di mesin) dapat dimodelkan dalam dua bucket terpisah (bucket tag dan bucket mesin), umumnya lebih baik memodelkan hubungan hierarkis tersebut dalam satu bucket.

Alasan yang baik untuk memisahkan hierarki ke dalam beberapa dimensi terpisah adalah untuk memungkinkan pengaitan rekaman dengan metadata pada berbagai tingkat perincian. Misalnya, jika Anda mengintegrasikan dua sumber data yang berbeda, yang salah satunya mengirim data dengan perincian tingkat sensor dan yang lainnya dengan perincian tingkat mesin, Anda harus memisahkan data khusus mesin ke dalam bucket-nya sendiri.

Mengonfigurasi skema bucket metadata cloud

Skema bucket menentukan struktur yang diizinkan dari instance metadata dalam bucket. Skema mendorong kualitas data, dan juga memungkinkan Anda menentukan bidang yang dapat atau harus digunakan untuk mendeskripsikan entity yang dimodelkan oleh bucket tertentu. Kolom yang harus Anda izinkan atau wajibkan dalam bucket sebagian besar bergantung pada data yang dikirimkan sumber Anda dan strategi pengaitan rekaman dan populasi bucket yang Anda pilih.

Jika Anda memilih untuk mengisi bucket metadata secara dinamis dari edge, pertimbangan utama Anda saat menentukan skema adalah ketersediaan metadata dalam pesan sumber. Anda juga harus mempertimbangkan kesesuaian data dan kemudahan penyerapan. Makin spesifik skema bucket metadata Anda dan makin banyak kolom yang ditandai sebagai wajib diisi, makin konsisten instance metadata yang dihasilkan. Namun, hal ini juga meningkatkan tuntutan pada parser untuk menyelesaikan perbedaan struktural antara pesan.

Di sisi lain, semakin generik skema bucket Anda (misalnya, menentukan bahwa properti metadata dapat berupa 'objek' apa pun, bukan menentukan properti objek tertentu), semakin rendah persyaratan transformasi dan penyelarasan metadata di parser. Namun, hal ini dapat mengorbankan konsistensi dan kesesuaian metadata.

Pertimbangan penting lainnya saat mendesain skema bucket adalah perincian bucket. Jika Anda membuat instance metadata melalui API, pastikan kunci alami tidak lebih terperinci atau lebih kasar daripada data yang diharapkan untuk diterima dari edge. Misalnya, jika Anda menerima peristiwa status dari edge di tingkat mesin, tetapi bucket aset Anda berisi instance di perincian sensor, Anda tidak akan dapat menautkan rekaman ke instance metadata di bucket ini. Sebagai gantinya, Anda memerlukan bucket yang berisi instance dengan perincian tingkat mesin.

Pemodelan catatan

Saat memodelkan metadata, Anda akan menghadapi dua pertanyaan utama:

  1. Jenis apa yang akan dibuat?
  2. Bagaimana jenis harus dikonfigurasi?

Jenis pemodelan

Jenis menjelaskan rekaman yang serupa secara semantik dan struktural yang ingin Anda simpan bersama dan jelaskan dengan sekumpulan metadata umum, dan yang ingin Anda tetapkan batasan umum pada kolom data.

Dengan demikian, jenis harus merekam data pada tingkat perincian yang sama (tingkat detail). Biasanya, ini berarti menyusun jenis di sekitar beberapa proses manufaktur, operasi, atau serangkaian tindakan. Misalnya, Anda dapat membuat jenis untuk data 'status-mesin' dan jenis lain untuk 'pembacaan-sensor'

Sebaiknya juga pertahankan data di tingkat paling atomik dan hindari penggabungan data sebelum mengirimkannya ke MDE. Dengan begitu, Anda dapat memanfaatkan fleksibilitas kueri yang paling besar karena Anda dapat membuat agregat apa pun dari data atomik.

Konfigurasi jenis

Pertimbangan utama saat mengonfigurasi jenis adalah sebagai berikut:

  1. Bucket metadata apa yang harus mendeskripsikan rekaman jenis tertentu? Apakah wajib atau opsional?
  2. Seperti apa skema kolom data?
Konfigurasi metadata untuk jenis

Anda dapat mengaitkan versi bucket metadata dengan jenis. Mengaitkan versi bucket dengan jenis menyiratkan bahwa rekaman jenis tersebut dapat atau harus (bergantung pada nilai kolom required pada pengaitan) ditautkan ke instance metadata dari versi bucket tertentu saat runtime.

Keputusan untuk mengaitkan bucket mana dengan jenis tertentu dan apakah pengaitan tersebut harus diklasifikasikan sebagai required bergantung pada beberapa pertimbangan. Anda harus mempertimbangkan persyaratan kontekstualisasi konsumen data, konteks yang Anda terima dari edge, kualitas data, serta akses ke data asli jika sumber data edge tidak memberikan konteks yang diperlukan.

Menetapkan tanda required pada asosiasi bucket metadata akan meningkatkan konsistensi data Anda; namun, Anda juga perlu memikirkan cara menangani kasus saat edge gagal mengirimkan metadata atau instance metadata untuk kunci alami belum dibuat. Dalam kasus seperti itu, Anda dapat membiarkan MDE menolak pesan dan memindahkannya ke antrean pesan yang tidak terkirim, atau Anda dapat membuat instance metadata Not Available generik di bucket untuk menautkan data ke instance tersebut jika link ke instance yang dikontekstualisasi penuh tidak dapat dibuat.

Konfigurasi kolom data untuk jenis

Mengonfigurasi kolom data di DISCRETE_DATA_SERIES dan CONTINUOUS_DATA_SERIES memungkinkan Anda mendapatkan struktur objek yang konsisten di kolom data. Saat menentukan kolom data, Anda harus memprofilkan data sumber dan memastikan parser dapat membuat rekaman proto yang divalidasi terhadap skema yang ditentukan.