图形模型概述（预览版）

适用于：✅Microsoft Fabric✅Azure 数据资源管理器

注释

此功能目前处于公开预览状态。 正式发布之前，功能和语法可能会更改。

使用 Azure 数据资源管理器中的图形模型可以定义、管理和有效地查询数据库中的持久图形结构。 与使用 生成图形 运算符创建的暂时性图形不同，图形模型是可重复查询的表示形式，无需为每个查询重新生成图形，从而显著提高基于关系的复杂分析的性能。

概述

图形模型是一个数据库对象，表示 Azure 数据资源管理器中的标记属性图（LPG）。 它由节点（也称为顶点）和边缘组成，也称为关系。 节点和边缘可以具有描述它们的属性。 模型定义图形的架构，包括具有其属性的节点和边缘类型。 它还定义从 KQL 数据库表和表格表达式中存储的表格数据构造图形的过程。

主要特征

图形模型产品/服务：

• 元数据持久性：在数据库元数据中存储图形规范以提高持久性和可重用性
• 具体化快照：无需为每个查询重新生成图形，从而显著提高查询性能
• 架构定义：支持节点和边缘的可选但建议定义的架构，确保数据一致性
• 深度 KQL 集成：与图形语义无缝集成
• 优化遍历：包括用于高效图形遍历作的专用索引，使复杂的模式匹配和路径查找查询的速度更快

何时使用图形模型

与即席图形查询相比，图形模型为基于关系的分析提供了显著优势，但需要额外的设置。 请考虑在以下情况下使用图形模型：

• 性能至关重要：重复对同一基础数据运行图形查询，并需要优化性能
• 复杂关系数据：具有许多相互关联的关系的数据，这些关系受益于图形表示形式
• 稳定结构：图形结构相对稳定，定期更新但不变更新
• 高级图形作：需要对数据执行复杂的遍历、路径查找、模式匹配或社区检测
• 一致的架构：图形分析需要具有一致的节点和边缘类型的明确结构

对于对较小的数据集进行一次性图形分析， 生成图形 运算符可能更合适。

图形模型组件

图形模型由两个主要组件组成：

架构（可选）

架构定义图形模型中节点和边缘的结构和属性。 虽然是可选的，但架构有以下几个重要用途：

• 类型安全性：架构属性定义节点和边缘属性的预期数据类型，确保图形查询期间的类型一致性
• 属性验证：架构中定义的所有属性都将成为具有相应标签的节点/边缘的有效属性，无论这些属性是否出现在步骤查询列中
• 查询兼容性：架构属性可以在图形匹配查询中安全地引用，而不会与步骤查询列发生类型冲突

架构结构

• 节点：定义节点标签类型及其类型化属性（例如） "Person": {"Name": "string", "Age": "long"}
• 边缘：定义边缘标签类型及其类型化属性（例如） "WORKS_AT": {"StartDate": "datetime", "Position": "string"}

定义

定义指定如何通过一系列顺序作从表格数据生成图形。 本部分是图形模型的核心，因为它将关系数据转换为图形结构。

定义的关键特征：

• 顺序执行：按步骤在定义数组中显示的确切顺序执行。 此顺序至关重要，因为：

  • 通常在引用节点的边缘之前创建节点
  • 后续步骤可以基于或修改早期步骤的结果
  • 该序列会影响图形构造期间的性能和内存使用率

• 增量构造：每个步骤都会添加到正在生成的图形中，使你能够：

  • 合并来自多个表或源的数据
  • 对不同类型的节点或边缘应用不同的逻辑
  • 以增量方式生成复杂的图形结构

步骤类型：

• AddNodes：定义如何从表格数据创建节点的步骤

  • 可以多次用于添加不同类型的节点
  • 每个步骤都可以从不同的数据源拉取或应用不同的筛选器
  • 节点属性派生自查询结果中的列

• AddEdges：定义如何从表格数据创建边缘的步骤

  • 可以引用尚不存在的节点（系统将在稍后处理 AddNodes 步骤时创建占位符节点并更新它们）
  • 可以从相同或不同的 AddNodes 步骤创建节点之间的关系
  • Edge 属性派生自查询结果中的列
  • 虽然可以在节点之前添加边缘，但建议先添加节点以提高可读性和理解性

执行流示例：

Step 1 (AddNodes): Create Person nodes from Employees table
Step 2 (AddNodes): Create Company nodes from Organizations table  
Step 3 (AddEdges): Create WORKS_AT edges between Person and Company nodes
Step 4 (AddEdges): Create KNOWS edges between Person nodes

此顺序方法可确保当步骤 3 创建WORKS_AT边缘时，图形中已存在 Person 节点（来自步骤 1）和公司节点（来自步骤 2）。

图形模型中的标签

标签是对图形中的节点和边缘进行分类的关键标识符，可实现高效的筛选和模式匹配。 Azure 数据资源管理器图形模型支持两种类型的标签：

静态标签

• 在图形模型的“架构”部分中显式定义
• 表示具有预定义属性的节点或边缘类型
• 为图形元素提供一致的架构
• 在 AddNodes 和 AddEdges 步骤的“标签”数组中引用
• 非常适合已知的稳定实体和关系类型

动态标签

• “架构”部分中未预定义
• 从基础表中的数据在运行时生成
• 在 AddNodes 或 AddEdges 步骤中使用“LabelsColumn”指定
• 可以是单个标签（字符串列）或多个标签（动态数组列）
• 允许更灵活的图形结构来适应数据
• 适用于节点/边缘类型随时间变化的系统

小窍门

可以将静态和动态标签组合在一起，以获得这两种方法的优势：核心实体类型的架构验证，同时保持改进分类的灵活性。

详细定义步骤

图形模型的“定义”部分包含定义如何从表格数据构造图形的步骤。 每个步骤都有特定参数，具体取决于其类型。

AddNodes 步骤

AddNodes 步骤定义如何从表格数据在图形中创建节点：

参数	必选	DESCRIPTION
种类	是的	必须设置为“AddNodes”
查询	是的	用于检索节点数据的 KQL 查询。 查询结果必须包含节点属性和标识符所需的所有列
NodeIdColumn	是的	用作每个节点的唯一标识符的查询结果中的列
标签	否	架构部分定义的静态标签名称数组，应用于这些节点
LabelsColumn	否	查询结果中的一列，为每个节点提供动态标签。 可以是字符串列（单个标签）或动态数组列（多个标签）

AddEdges 步骤

AddEdges 步骤定义如何在关系图中的节点之间创建关系：

参数	必选	DESCRIPTION
种类	是的	必须设置为“AddEdges”
查询	是的	用于检索边缘数据的 KQL 查询。 查询结果必须包含源节点和目标节点标识符以及任何边缘属性
来源列	是的	包含源节点标识符的查询结果中的列
TargetColumn	是的	包含目标节点标识符的查询结果中的列
标签	否	架构部分定义的静态标签名称数组，适用于这些边缘
LabelsColumn	否	查询结果中的一列，为每个边缘提供动态标签。 可以是字符串列（单个标签）或动态数组列（多个标签）

图形模型示例

包含静态标签和动态标签的基本示例

以下示例创建一个将静态架构定义与动态标记相结合的专业网络图模型：

.create-or-alter graph_model ProfessionalNetwork ```
{
  "Schema": {
    "Nodes": {
      "Person": {"Name": "string", "Age": "long", "Title": "string"},
      "Company": {"Name": "string", "Industry": "string", "FoundedYear": "int"}
    },
    "Edges": {
      "WORKS_AT": {"StartDate": "datetime", "Position": "string", "Department": "string"},
      "KNOWS": {"ConnectionDate": "datetime", "ConnectionStrength": "int"}
    }
  },
  "Definition": {
    "Steps": [
      {
        "Kind": "AddNodes",
        "Query": "Employees | project Id, Name, Age, Title, NodeType",
        "NodeIdColumn": "Id",
        "Labels": ["Person"],
        "LabelsColumn": "NodeType"
      },
      {
        "Kind": "AddNodes",
        "Query": "Organizations | project Id, Name, Industry, FoundedYear",
        "NodeIdColumn": "Id",
        "Labels": ["Company"]
      },
      {
        "Kind": "AddEdges",
        "Query": "EmploymentRecords | project EmployeeId, CompanyId, StartDate, Position, Department",
        "SourceColumn": "EmployeeId",
        "TargetColumn": "CompanyId",
        "Labels": ["WORKS_AT"]
      },
      {
        "Kind": "AddEdges",
        "Query": "Connections | project PersonA, PersonB, ConnectionDate, ConnectionType, ConnectionStrength",
        "SourceColumn": "PersonA",
        "TargetColumn": "PersonB",
        "Labels": ["KNOWS"],
        "LabelsColumn": "ConnectionType"
      }
    ]
  }
}
```

此模型将启用查询，例如查找通过多个程度的分离联系的同事、识别同一行业工作的人员或分析组织关系。

创建和管理 Graph 模型

Azure 数据资源管理器提供一组全面的管理命令，用于在整个生命周期内使用图形模型。

命令摘要

指令	目的	关键参数
.create-or-alter graph_model	创建新的图形模型或修改现有图形模型	数据库、名称、架构、定义
.drop graph_model	删除图形模型	数据库，名称
.show graph_models	列出可用的图形模型	数据库 [可选]

图形模型生命周期

用于管理图形模型的典型工作流涉及：

1. 开发 - 使用映射到数据的架构和定义创建初始图形模型
2. 验证 - 查询模型以验证正确的结构和预期结果
3. 维护 - 随着数据结构的发展，定期更新模型
4. 快照管理 - 创建和停用快照以平衡性能和新鲜度

小窍门

从图形模型开始时，请先从一小部分数据开始，在缩放到较大的数据集之前验证设计。

图形快照

图形快照是表示特定时间点图形模型实例的数据库实体。 虽然图形模型定义了图形的结构和数据源，但快照是可以查询的实际具体化图形。

图形快照的关键方面：

• 每个快照都链接到特定的图形模型
• 单个图形模型可以有多个与之关联的快照
• 使用命令创建 .make graph_snapshot 快照
• 快照包括创建时间和源图模型等元数据
• 快照支持查询图，因为它在特定时间点存在

有关使用图形快照的更多详细信息，请参阅 图形快照概述。

查询图形模型

使用函数查询 graph() 图形模型，该函数提供对图形实体的访问权限。 此函数支持检索图形的最新快照，或者在查询时创建图形（如果快照不可用）。

基本查询结构

graph("GraphModelName")
| graph-match <pattern>
    where <filters>
    project <output fields>

查询示例

1. 基本节点边缘节点模式

// Find people who commented on posts by employees in the last week
graph("SocialNetwork") 
| graph-match (person)-[comments]->(post)<-[authored]-(employee)
    where person.age > 30 
      and comments.createTime > ago(7d)
    project person.name, post.title, employee.userName

2. 多个关系模式

// Find people who both work with and are friends with each other
graph("ProfessionalNetwork") 
| graph-match (p1)-[worksWith]->(p2)-[friendsWith]->(p1)
    where labels(worksWith) has "WORKS_WITH" and labels(friendsWith) has "FRIENDS_WITH" and
      labels(p1) has "Person" and labels(p2) has "Person"
    project p1.name, p2.name, p1.department

3. 可变长度路径

// Find potential influence paths up to 3 hops away
graph("InfluenceNetwork") 
| graph-match (influencer)-[influences*1..3]->(target)
    where influencer.id == "user123" and all(influences, labels() has "INFLUENCES")
    project influencePath = influences, 
         pathLength = array_length(influences), 
         target.name

该 graph() 函数提供一致的方式来访问图形数据，而无需为每个查询显式构造图形。

注释

有关图形查询语法和功能的完整参考，请参阅 Graph 运算符 。

常见问题解答

谁负责刷新图形？

用户或进程必须自行刷新图形。 最初，新图形实体不存在自动刷新策略。 但是，即使正在创建快照或尚未创建快照，图形仍可查询。

如何刷新图形？

刷新图形：

1. 使用异步作创建新快照 （.make graph_snapshot）
2. 创建后，传入的图形查询会自动使用新快照
3. 可选：删除旧快照以释放资源（.drop graph_snapshot）

如果不同的步骤创建重复边缘或节点，该怎么办？

定义步骤按顺序执行，并且节点和边缘之间的重复处理不同：

• 边缘：默认情况下，重复项保留为重复项，因为边缘没有唯一标识符。 如果多个步骤创建相同的源目标关系，则每个关系将成为图形中的单独边缘。 此行为是有意的，因为同一节点之间的多个关系可以表示随时间推移的不同交互或事件。

• 节点：“重复项”根据 NodeIdColumn 值自动合并 - 系统假定它们表示同一实体。 当多个步骤创建具有相同标识符的节点时：

  • 不同步骤中的所有属性都合并到单个节点中
  • 如果同一属性名称存在冲突的属性值，则执行最后一个步骤的值优先
  • 保留一个步骤中存在但不存在于另一个步骤中的属性

通过此合并行为，可以跨步骤以增量方式生成节点，例如在一个步骤中添加基本信息，并在后续步骤中使用其他属性进行扩充。

图形模型如何处理架构更改？

基础数据的架构发生更改时：

1. 使用 .create-or-alter graph_model 命令更改图形模型以更新其架构或定义
2. 若要具体化这些更改，请创建新的快照
3. 旧快照仍可访问，直到显式删除

是否可以跨多个图形模型进行查询？

是的，可以使用组合在单个查询中查询多个图形模型：

• 将一个运算符的输出用作另一 graph() 个 graph() 运算符的输入
• 在馈送到另一个图形查询之前处理和转换一个图形的结果
• 将多个图形作链接到跨域分析，而无需创建统一模型

示例：

// Query the first graph model
graph("EmployeeNetwork") 
| graph-match (person)-[manages]->(team)
    where labels(manages) has "MANAGES" and labels(person) has "Employee"
    project manager=person.name, teamId=team.id
// Use these results to query another graph model
| join (
	graph("ProjectNetwork")
	| graph-match (project)-[assignedTo]->(team)
        where labels(assignedTo) has "ASSIGNED_TO"
	    project projectName=project.name, teamId=team.id
) on teamId

标签和属性之间的区别是什么？

• 标签：对节点和边缘进行分类，以便进行结构模式匹配
• 属性：存储与节点和边缘关联的数据值（用于筛选和输出）

相关内容

• .create-or-alter graph_model
• .drop graph_model
• .show graph_models
• 重要注意事项
• 图形运算符
• 图形最佳做法