モデルレコードとメタデータ
このガイドでは、Manufacturing Data Engine（MDE）でレコードとメタデータをモデル化する方法について説明します。
レコードは、センサーの読み取り値やイベントなどの製造プロセスに関する事実をキャプチャします。メタデータは、これらの事実をコンテキスト化し、メタデータ属性で「スライスとダイス」を行うのに役立ちます。メタデータは、製造エンティティの元データのソースとしても機能します。
MDE スイート全体（MDE と Manufacturing Connect（MC）の組み合わせ）を使用する場合は、MDE にすぐに使用できるパッケージが用意されているため、このデータ モデリングのセクションをスキップできます。ただし、他のデータソースを統合する場合は、読んでおくことをおすすめします。
一般的な推奨事項
メタデータ モデリングを開始する前に、次のことを理解しておく必要があります。
- ダウンストリーム ユーザーのデータ消費ニーズ。これには、必要なデータとその使用方法を理解することが含まれます。これを行うには、ダウンストリーム ユーザーとミーティングを行い、目標、主要業績評価指標（KPI）、ユースケース、分析要件、データ品質基準について尋ねます。
- 基盤となるソースデータの現実。これには、データの品質、データ構造、データ リネージの理解が含まれます。これを行うには、ソースシステムの専門家と面談し、データ プロファイリングの概要を把握します。
- 技術データの統合要件。これには、MDE がサポートする必要があるデータ統合インターフェースと、命名規則などの技術要件を理解することが含まれます。
ダウンストリーム ユーザーの消費ニーズを把握するためにできる具体的なことを以下に示します。
- ダウンストリーム ユーザーと面談して目標を把握する:
- データで何を達成しようとしているか。
- KPI は何か？
- ダウンストリーム ユーザーにユースケースについて尋ねる:
- データをどのように使用する予定ですか？
- どのようなレポートを作成したいですか？
- どのような分析を行いたいですか？
- ダウンストリーム ユーザーの分析要件を理解する:
- どのような種類のデータを分析する必要がありますか？
- データの分析が必要な頻度はどれくらいですか？
- 下流のユーザーにデータ品質基準について尋ねる:
- どの程度のデータ品質が許容されるか
- データを基準に適合させるには、どのような手順を踏む必要がありますか？
基盤となるソースデータの現実を把握するために、次のことを行うことができます。
- ソースシステムの専門家との打ち合わせ:
- ソースシステムのデータの品質はどの程度ですか？
- データ構造とは何ですか？
- データリネージとは何ですか？
- 大まかなデータ プロファイリングを行う:
- これにより、欠損値、重複レコード、無効なデータ型など、データに関する潜在的な問題を特定できます。
メタデータ モデリング
メタデータをモデリングする際には、次の 3 つの重要な質問に答える必要があります。
- どのメタデータを埋め込みメタデータとして扱い、どのメタデータをクラウド メタデータとして扱うべきですか？
- クラウド メタデータの場合、作成するバケットはどれですか？
- クラウド メタデータ バケットのスキーマは何にすべきですか？
埋め込みメタデータとクラウド メタデータのどちらを選択するか
コンテキスト情報を埋め込みメタデータとしてモデル化するか、クラウド メタデータとしてモデル化するかを決定する際に適用する主な基準は、変化のペースです。
埋め込みメタデータは、急速に変化するメタデータに最適です。これには、トランザクション ID や自動インクリメント カウンタなどのメタデータが含まれます。
一方、クラウド メタデータは、アセット メタデータなど、変化のペースが遅いメタデータに最適です。MDE は、バケットごとのメタデータ インスタンスの履歴を追跡し、そのメタデータを BigQuery などのサポートされているシンクに書き込みます。これにより、自然キーごとにメタデータ インスタンスの履歴を調べることができます。また、Looker などのビジネス インテリジェンス（BI）ツールで、レコード テーブル全体を走査せずに属性値の一意のリストを取得することもできます。
クラウド メタデータ バケットのモデリング
バケットは、コンテキスト上のドメインをモデル化します。たとえば、ISA-95 アセット階層モデルの実装では、製造企業の物理アセット階層をモデル化します。メタデータ バケットは、コンテキスト ドメインの境界に沿ってモデル化する必要があります。たとえば、アセット コンテキスト（ISA-95 実装で表現される）を asset バケットで、マシンステータスを machine-status バケットでモデル化できます。
タグや任意のレコード グループをコンテキスト化する必要があるかどうかも検討する必要があります。
タグ関連のメタデータにはタグバケットを選択し、その他のタイプのメタデータにはレコードバケットを選択する必要があります。
一般に、階層型ドメイン メタデータは同じバケットでモデル化することをおすすめします。たとえば、タグが属するマシンの属性（マシンにインストールされているセンサーのメーカーなど）は、2 つの別々のバケット（タグバケットとマシンバケット）でモデル化できますが、通常は、このような階層関係を 1 つのバケットでモデル化する方が適切です。
階層を複数の個別のディメンションに分割する理由としては、異なる粒度レベルでレコードをメタデータに関連付けることが可能になることが挙げられます。たとえば、2 つの異なるデータソースを統合する場合、一方のデータソースがセンサーレベルの粒度でデータを送信し、もう一方のデータソースがマシンレベルの粒度でデータを送信する場合は、マシン固有のデータを独自のバケットに分離する必要があります。
クラウド メタデータ バケット スキーマの構成
バケットのスキーマによって、バケット内のメタデータ インスタンスの許容構造が決まります。スキーマはデータ品質を向上させ、特定のバケットがモデル化するエンティティを記述するために使用できるフィールドまたは使用する必要があるフィールドを定義することもできます。バケットで許可または必須にするフィールドは、ソースが配信するデータと、選択したバケットの入力とレコードのリンク戦略によって大きく異なります。
エッジからメタデータ バケットを動的に入力する場合は、スキーマを定義する際に、ソース メッセージのメタデータの可用性を考慮する必要があります。データの適合性と取り込みやすさも考慮する必要があります。メタデータ バケット スキーマが具体的で、必須としてマークされているフィールドが多いほど、結果のメタデータ インスタンスの一貫性が高くなります。ただし、この方法では、メッセージ間の構造的な違いを解決するために、パーサーに対する要求も高まります。
一方、バケット スキーマがより一般的であるほど（特定のオブジェクト プロパティを定義するのではなく、メタデータ プロパティを任意の「オブジェクト」にできると指定するなど）、パーサーでのメタデータの変換と調和の要件は低くなります。ただし、メタデータの整合性と適合性が損なわれる可能性があります。
バケット スキーマを設計する際のもう 1 つの重要な考慮事項は、バケットの粒度です。API 経由でメタデータ インスタンスを作成する場合は、自然キーがエッジから受信するデータよりも詳細または粗くないことを確認してください。たとえば、エッジからマシンレベルでステータス イベントを受信しても、アセットバケットにセンサーの粒度でインスタンスが含まれている場合、このバケットのレコードをメタデータ インスタンスにリンクすることはできません。代わりに、マシンレベルの粒度でインスタンスを含むバケットが必要です。
レコードのモデリング
メタデータをモデリングする際には、次の 2 つの重要な疑問が生じます。
- 作成するタイプ
- タイプはどのように構成すればよいですか？
モデリング タイプ
タイプは、意味的にも構造的にも類似したレコードを記述します。これらのレコードは、共通のメタデータ セットで記述され、共通の制約がデータ フィールドに設定されます。
このことを踏まえると、型は同じ粒度（詳細レベル）のレコードをキャプチャする必要があります。通常、これは製造プロセス、オペレーション、一連のアクションを中心とした型の構造化を意味します。たとえば、machine-state レコードの型と sensor-readings の型を作成できます。
また、最もアトミックなレベルでデータを永続化し、MDE に送信する前にデータを事前集計しないことをおすすめします。アトミック データから任意の集計を構築できるため、クエリの柔軟性を最大限に活用できます。
タイプの設定
タイプを構成する際の主な考慮事項は次のとおりです。
- どのメタデータ バケットでレコードのタイプを記述する必要がありますか？必須か省略可能か。
- データ フィールドのスキーマはどうあるべきですか？
タイプのメタデータ構成
メタデータ バケットのバージョンをタイプに関連付けることができます。バケット バージョンを型に関連付けると、その型のレコードは、実行時に指定されたバケット バージョンのメタデータ インスタンスにリンクされる可能性があります（関連付けの required フィールドの値によって異なります）。
タイプに関連付けるバケットと、関連付けを required として分類するかどうかは、いくつかの考慮事項によって決まります。データ利用者のコンテキスト化の要件、エッジから受け取るコンテキスト、データ品質、エッジ データソースが必要なコンテキストを提供しない場合の元データへのアクセスを検討する必要があります。
メタデータ バケットの関連付けで required フラグを設定すると、データの整合性が向上しますが、エッジがメタデータを配信できない場合や、自然キーのメタデータ インスタンスがまだ作成されていない場合の処理方法も検討する必要があります。このような場合は、MDE でメッセージを拒否してデッドレター キューに移動させるか、完全なコンテキスト化されたインスタンスへのリンクを作成できない場合にレコードをリンクする汎用の Not Available メタデータ インスタンスをバケットに作成できます。
型のデータ フィールド構成
DISCRETE_DATA_SERIES と CONTINUOUS_DATA_SERIES でデータフィールドを構成すると、データフィールドで一貫したオブジェクト構造を取得できます。データフィールドを定義するときは、ソースデータをプロファイリングし、パーサーが定義されたスキーマに対して検証される proto レコードを生成できることを確認する必要があります。