模型记录和元数据
本指南介绍了如何在 Manufacturing Data Engine (MDE) 中对记录和元数据进行建模。
记录可捕获有关制造过程的事实，例如传感器读数和事件，而元数据有助于将这些事实置于上下文中，并让您能够按元数据属性对这些事实进行“切分和细分”。元数据还可作为制造实体的原始数据源。
如果您使用完整的 MDE 套件（MDE 与 Manufacturing Connect (MC) 结合使用），则可以跳过有关数据建模的这一部分，因为 MDE 提供了一个软件包，可让您快速入门。不过，如果您要集成其他数据源，则不妨阅读一下。
一般建议
在开始进行元数据建模之前，您应了解以下内容：
- 下游用户的数据使用需求。这包括了解他们需要哪些数据以及他们打算如何使用这些数据。为此，您可以与下游用户会面，询问他们的目标、关键绩效指标 (KPI)、使用情形、分析要求和数据质量标准。
- 底层源数据的实际情况。这包括了解数据质量、数据结构和数据沿袭。为此，您可以与源系统专家会面，并进行高级别的数据分析。
- 技术数据集成要求。这包括了解 MDE 需要支持哪些数据集成接口，以及必须遵守哪些技术要求（包括命名惯例）。
以下是一些具体措施，可帮助您了解下游用户的消费需求：
- 与下游用户会面，了解他们的目标：
- 他们希望通过数据实现什么目标？
- 他们的 KPI 是什么？
- 询问下游用户其使用场景：
- 他们打算如何使用这些数据？
- 他们想运行哪些报告？
- 他们想要执行什么分析？
- 了解下游用户的数据分析要求：
- 他们需要分析哪类数据？
- 他们需要多久分析一次数据？
- 向下游用户询问他们的数据质量标准：
- 他们可接受的数据质量水平如何？
- 需要采取哪些步骤来确保数据符合其标准？
以下是一些具体措施，可帮助您了解底层源数据的实际情况：
- 与源系统专家会面：
- 源系统中的数据质量如何？
- 什么是数据结构？
- 什么是数据沿袭？
- 进行高级别数据分析：
- 这有助于您发现数据中的任何潜在问题，例如缺失值、重复记录或无效的数据类型。
元数据建模
在对元数据进行建模时，您会面临三个关键问题：
- 哪些元数据应视为嵌入式元数据，哪些元数据应视为云元数据？
- 对于云元数据，应创建哪些存储分区？
- 云元数据存储分区的架构应是什么？
决定使用嵌入式元数据还是云元数据
在决定是否应将某些情境信息建模为嵌入式元数据或云元数据时，应应用的关键决策标准是变化速度。
嵌入式元数据最适合快速变化的元数据。这包括交易 ID 或自动递增计数器等元数据。
相比之下，云元数据最适合用于变化速度较慢的元数据，例如媒体资源元数据。MDE 会跟踪每个存储桶的元数据实例历史记录，并将该元数据写入支持它的接收器（例如 BigQuery）。这样一来，您就可以按自然键探索元数据实例的历史记录，同时还允许 Looker 等商业智能 (BI) 工具获取唯一的属性值列表，而无需遍历整个记录表。
对云元数据存储分区进行建模
分桶用于对某些情境化网域进行建模。例如，ISA-95 资产层次结构的一种实现方式可对制造企业的实物资产层次结构进行建模。您应根据情境网域的边界来确定元数据分桶。例如，您可以在 asset 存储桶中对资产上下文（如 ISA-95 实现所表达的那样）进行建模，并在 machine-status 存储桶中对机器状态进行建模。
您还应考虑是否需要将标记或任意记录组置于上下文中。
对于与标记相关的元数据，应选择标记存储分区；对于任何其他类型的元数据，应选择记录存储分区。
一般建议在同一存储桶中对分层网域元数据进行建模。例如，虽然可以将 tag 所属机器的属性（例如，安装在机器中的传感器的制造商）分别归入两个不同的数据桶（标记数据桶和机器数据桶），但通常最好在一个数据桶中对这种分层关系进行建模。
将层次结构拆分为多个单独维度的合理原因是，能够以不同的粒度级别将记录与元数据相关联。例如，如果您要集成两个不同的数据源，其中一个以传感器级粒度发送数据，另一个以机器级粒度发送数据，则应将特定于机器的数据分离到自己的存储桶中。
配置云元数据存储桶架构
存储桶的架构决定了存储桶中元数据实例的允许结构。架构可提高数据质量，还可让您定义哪些字段可用于或必须用于描述给定数据桶所建模的实体。您应在分桶中允许或要求的字段很大程度上取决于来源提供的数据，以及您选择的分桶填充和记录关联策略。
如果您选择从边缘动态填充元数据桶，那么在定义架构时，您应主要考虑源消息中元数据的可用性。您还应考虑数据的一致性和提取的便捷性。元数据存储桶架构越具体，标记为必需的字段越多，生成的元数据实例就越一致。不过，这也对解析器提出了更高的要求，即需要解析器能够解决消息之间的任何结构性差异。
另一方面，存储桶架构越通用（例如，指定元数据属性可以是任何“对象”，而不是定义特定的对象属性），解析器中的元数据转换和协调要求就越低。不过，这可能会牺牲元数据的一致性和合规性。
设计分桶架构时，另一个需要考虑的重要因素是分桶的粒度。如果您是通过 API 创建元数据实例，请确保自然键的粒度不比您预期从边缘接收的数据更精细或更粗略。例如，如果您从边缘接收机器级接收状态事件，但您的资产桶包含传感器粒度的实例，您将无法将记录关联到此桶中的元数据实例。而是需要一个包含机器级粒度实例的存储桶。
记录建模
在对元数据进行建模时，您会遇到两个关键问题：
- 要创建哪些类型的广告？
- 应如何配置类型？
建模类型
类型用于描述在语义和结构上相似的记录，这些记录需要一起存储并使用一组通用元数据进行描述，并且您希望为这些记录的数据字段建立通用约束。
考虑到这一点，类型应以相同的粒度（详细程度）捕获记录。通常，这意味着围绕某些制造流程、操作或一组操作来构建类型。例如，您可以为“机器状态”记录创建一个类型，再为“传感器读数”记录创建另一个类型
我们还建议您以最精细的粒度持久保留数据，并在将数据发送到 MDE 之前避免预先汇总数据。这样一来，您就可以从原子数据构建任何汇总，从而获得最大的查询灵活性。
类型配置
配置类型时，需要考虑以下关键事项：
- 哪些元数据桶应描述某种类型的记录？是必需的还是可选的？
- 数据字段的架构应是什么？
类型的元数据配置
您可以将元数据存储桶版本与类型相关联。将存储桶版本与类型相关联意味着，该类型的记录在运行时可以或必须（取决于关联的 required 字段的值）与给定存储桶版本中的元数据实例相关联。
决定将哪些存储分区与某种类型相关联，以及关联是否应归类为 required，取决于多种考虑因素。您应考虑数据使用方的情境化要求、从边缘接收的情境、数据质量，以及在边缘数据源无法提供所需情境时对原始数据的访问权限。
在元数据存储桶关联中设置 required 标志可提高数据的一致性；不过，这也要求您考虑如何处理以下情况：边缘未能传送元数据，或者尚未为自然键创建元数据实例。在这种情况下，您可以让 MDE 拒绝该消息并将其移至死信队列，也可以在存储桶中创建一个通用 Not Available 元数据实例，以便在无法创建与完整情境化实例的链接时将记录链接到该实例。
类型的数据字段配置
通过在 DISCRETE_DATA_SERIES 和 CONTINUOUS_DATA_SERIES 上配置数据字段，您可以在数据字段中获得一致的对象结构。定义数据字段时，您应分析源数据，并确保解析器能够生成符合所定义架构的 proto 记录。